From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BDF908A5 for ; Mon, 1 Aug 2016 13:38:36 +0000 (UTC) Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC001150 for ; Mon, 1 Aug 2016 13:38:35 +0000 (UTC) From: Laurent Pinchart To: Hans Verkuil Date: Mon, 01 Aug 2016 16:38:35 +0300 Message-ID: <7250118.B4sqDGlW1h@avalon> In-Reply-To: References: <9312614.JbNQVmRIQM@avalon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: ksummit-discuss@lists.linuxfoundation.org, Mauro Carvalho Chehab , "vegard.nossum@gmail.com" , "rafael.j.wysocki" , Marek Szyprowski , Valentin Rothberg Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Hans, On Monday 01 Aug 2016 15:35:31 Hans Verkuil wrote: > On 08/01/2016 03:26 PM, Laurent Pinchart wrote: > > On Monday 01 Aug 2016 15:21:49 Hans Verkuil wrote: > >> On 08/01/2016 03:09 PM, Laurent Pinchart wrote: > >>> On Friday 29 Jul 2016 12:13:03 Mark Brown wrote: > >>>> On Fri, Jul 29, 2016 at 09:45:55AM +0200, Hans Verkuil wrote: > >>>>> My main problem is not so much with deferred probe (esp. for cyclic > >>>>> dependencies it is a simple method of solving this, and simple is > >>>>> good). My main problem is that you can't tell the system that driver A > >>>>> needs to be probed after drivers B, C and D are probed first. > >>>>> > >>>>> That would allow us to get rid of v4l2-async.c which is a horrible > >>>>> hack. > >>>>> > >>>>> That code allows a bridge driver to wait until all dependent drivers > >>>>> are probed. This really should be core functionality. > >>>>> > >>>>> Do other subsystems do something similar like > >>>>> drivers/media/v4l2-core/v4l2-async.c? Does anyone know? > >>>> > >>>> ASoC does, it has an explicit card driver to join things together and > >>>> that just defers probe until everything it needs is present. This was > >>>> originally open coded in ASoC but once deferred probe was implemented > >>>> we converted to that. > >>> > >>> Asynchronous bindings of components, as done in ASoC, DRM and V4L2, is a > >>> problem largely solved (or rather hacked around), but I'm curious to > >>> know how ASoC handles device unbinding (due to device removal or manual > >>> unbinding through sysfs). With asynchronous binding we can more or less > >>> easily wait for all components to be present before creating circular > >>> dependencies, but breaking them to implement unbinding is an unsolved > >>> problem at least in V4L2. > >> > >> We need to prevent subdevice drivers from being unbound. It's easy enough > >> to do that (set suppress_bind_attrs to true), we just never did that. > >> It's been on my TODO list for ages to make a patch adding that flag... > >> > >> You can only unbind bridge drivers. Unbinding subdevs is pointless in > >> general and should be prohibited. Perhaps in the future with dynamically > >> reconfigurable video pipelines (FPGA) you want that, but then you need to > >> do a lot of additional work. For everything we have today we should just > >> set suppress_bind_attrs to true. > > > > If wish reality was so simple :-) In Project Ara our camera modules are > > hot-pluggable, and connect to a CSI-2 receiver on the SoC side. > > I assume that when a camera module is unplugged the CSI driver is informed > and it will then unregister the camera subdev. So this is controlled by the > CSI-2 driver. What you don't want is someone unbinding the camera driver > without the CSI-2 driver's knowledge. To prevent that you need to set that > flag in the subdev driver. The CSI-2 receiver is unaware of the modular nature of the system. The camera module unplug event is delivered by the Greybus [0] core directly to the camera module subdev driver. [0] https://lwn.net/Articles/648400/ (slightly outdated, but the overall architecture is there) -- Regards, Laurent Pinchart