linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Sakari Ailus <sakari.ailus@linux.intel.com>,
	"Qiu, Tian Shu" <tian.shu.qiu@intel.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>,
	Bing Bu Cao <bingbu.cao@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	"Zheng, Jian Xu" <jian.xu.zheng@intel.com>,
	"Zhi, Yong" <yong.zhi@intel.com>,
	"Cao, Bingbu" <bingbu.cao@intel.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH] media: intel-ipu3: cio2: register the mdev on v4l2 async notifier complete
Date: Thu, 27 Sep 2018 12:09:43 +0200	[thread overview]
Message-ID: <5c6944ec-ee1f-8be6-3eff-2c65fd888222@xs4all.nl> (raw)
In-Reply-To: <20180904064605.6prcawieb4ooxtyl@paasikivi.fi.intel.com>

On 09/04/2018 08:46 AM, Sakari Ailus wrote:
> Hi Javier, Tian Shu,
> 
> On Tue, Sep 04, 2018 at 05:01:56AM +0000, Qiu, Tian Shu wrote:
>> 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.
> 
> I'd prefer to keep the driver as-is.
> 
> Even if the media device is only created once all the sub-devices are
> around, the devices are still created one by one so there's no way to
> prevent the user space seeing a partially registered media device complex.
> 
> In general that doesn't happen as the sensors are typically registered
> early during system boot.
> 
> Javier is right in asking a way for the user to know whether everything is
> fully initialised. That should be added but I don't think it is in any way
> specific to the cio2 driver.
> 

Today we have no userspace mechanism to deal with partially initialized topologies.
Instead if parts fails to come up we shouldn't register any media device and
instead (once we discover that something is broken) tear everything down.

In fact, video/subdev/media devices shouldn't be registered until everything is
complete.

I know we want to allow for partial bring up as well, and I fully agree with that,
but in that case someone needs to write an RFC with a proposal how userspace should
handle this.

We've discussed this in the past, but I have not seen such an RFC.

So until we add support for partial bringup I think this patch does the right
thing since otherwise this is out-of-spec.

Regards,

	Hans

  parent reply	other threads:[~2018-09-27 10:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 15:20 [PATCH] media: intel-ipu3: cio2: register the mdev on v4l2 async notifier complete Javier Martinez Canillas
2018-09-03  7:25 ` Bing Bu Cao
2018-09-03  7:35   ` Javier Martinez Canillas
2018-09-03  8:49     ` Bing Bu Cao
2018-09-03  8:52       ` Javier Martinez Canillas
2018-09-04  5:01         ` Qiu, Tian Shu
2018-09-04  6:46           ` Sakari Ailus
2018-09-04  7:52             ` Javier Martinez Canillas
2018-09-27 10:09             ` Hans Verkuil [this message]
2018-09-27 11:04               ` Javier Martinez Canillas
2018-09-04  8:46           ` Javier Martinez Canillas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5c6944ec-ee1f-8be6-3eff-2c65fd888222@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=bingbu.cao@intel.com \
    --cc=bingbu.cao@linux.intel.com \
    --cc=javierm@redhat.com \
    --cc=jian.xu.zheng@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tian.shu.qiu@intel.com \
    --cc=yong.zhi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).