[lkml]   [2018]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] media: intel-ipu3: cio2: register the mdev on v4l2 async notifier complete
On 09/03/2018 10:49 AM, Bing Bu Cao wrote:
> On 09/03/2018 03:35 PM, Javier Martinez Canillas wrote:
>> Hi,
>> Thanks a lot your feedback.
>> On 09/03/2018 09:25 AM, Bing Bu Cao wrote:
>>> On 08/31/2018 11:20 PM, Javier Martinez Canillas wrote:
>>>> Commit 9832e155f1ed ("[media] media-device: split media initialization and
>>>> registration") split the media_device_register() function in two, to avoid
>>>> a race condition that can happen when the media device node is accessed by
>>>> userpace before the pending subdevices have been asynchronously registered.
>>>> But the ipu3-cio2 driver calls the media_device_register() function right
>>>> after calling media_device_init() which defeats the purpose of having two
>>>> separate functions.
>>>> In that case, userspace could have a partial view of the media device if
>>>> it opened the media device node before all the pending devices have been
>>>> bound. So instead, only register the media device once all pending v4l2
>>>> subdevices have been registered.
>>> Javier, Thanks for your patch.
>>> IMHO, there are no big differences for registering the cio2 before and after all the subdevices are ready.
>>> User may see a partial view of media graph but it presents what it really is then.
>>> It indicate that device is not available currently not it is not there.
>> I disagree that there are no differences. The media graph shouldn't be exposed
>> until its complete. That's the reason why we have a v4l2 async notifier .bound
>> and .complete callbacks (otherwise the .bound would be enough).
>> It's also the reason why media register was split in _init and _register, as I
>> mentioned in the commit message.
> I revisit the commit 9832e155f1ed and understand and agree that.

Great. Does this mean the patch has your Reviewed-by / Acked-by ?

> Seems like there are some other drivers (such as rcar-vin and omap4iss) still have similar issues.

Yes it seems so. I don't have access to hardware with these IP blocks though,
I'm hesitant to attempt to fix them.

Best regards,
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

 \ /
  Last update: 2018-09-03 10:52    [W:0.059 / U:1.832 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site