[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F4B393EC1A37C8418714AECDAAEF72A93C9A39FC@shsmsx102.ccr.corp.intel.com>
Date: Tue, 4 Sep 2018 05:01:56 +0000
From: "Qiu, Tian Shu" <tian.shu.qiu@...el.com>
To: Javier Martinez Canillas <javierm@...hat.com>,
Bing Bu Cao <bingbu.cao@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Mauro Carvalho Chehab <mchehab@...nel.org>,
"Zheng, Jian Xu" <jian.xu.zheng@...el.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
"Zhi, Yong" <yong.zhi@...el.com>,
"Cao, Bingbu" <bingbu.cao@...el.com>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: RE: [PATCH] media: intel-ipu3: cio2: register the mdev on v4l2
async notifier complete
Hi,
Raise my point.
The case here is that we have multiple sensors connected to CIO2. The sensors work independently. So failure on one sensor should not block the function of the other.
That is, we should not rely on that all sensors are ready before allowing user to operate on the ready cameras.
Sometimes due to hardware issues or incompleteness, we did met the case that one sensor is not probing properly. And in this case, the current implementation blocks us using the working one.
What I can think now to solve this are:
1. Register multiple media devices. One for each sensor path. This will increase media device count.
2. Use .bound callback to create the link and register the subdev node for each sensor. Leave .complete empty.
Not sure if this breaks the rule of media framework. And also have not found an API to register one single subdev node.
Thanks
Tianshu Qiu
> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javierm@...hat.com]
> Sent: Monday, September 3, 2018 4:52 PM
> To: Bing Bu Cao <bingbu.cao@...ux.intel.com>; linux-kernel@...r.kernel.org
> Cc: Mauro Carvalho Chehab <mchehab@...nel.org>; Qiu, Tian Shu <tian.shu.qiu@...el.com>; Zheng, Jian Xu
> <jian.xu.zheng@...el.com>; Sakari Ailus <sakari.ailus@...ux.intel.com>; Zhi, Yong <yong.zhi@...el.com>; Cao, Bingbu
> <bingbu.cao@...el.com>; linux-media@...r.kernel.org
> Subject: Re: [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
Powered by blists - more mailing lists