[Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

Laurent Pinchart laurent.pinchart at ideasonboard.com
Mon Aug 1 13:19:50 UTC 2016


Hi Lars,

On Monday 01 Aug 2016 15:14:00 Lars-Peter Clausen 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.
>
> ASoC does not handle it at the moment. It will just crash when you do that
> :(
> 
> For a recent discussion on this see
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-July/110440.html

Quoting you,

"The reason why we don't support hot-unplug in ASoC at the moment is
because it is not trivial to implement and nobody has cared enough yet."

s/ASoC/V4L2/ and you get another very valid statement. We should solve both of 
them together (and possibly add DRM/KMS to the mix too).

-- 
Regards,

Laurent Pinchart



More information about the Ksummit-discuss mailing list