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

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

[Luis R. Rodriguez]

(first e-mail bounced)

Rafael has proposed has a set of patches to help deal with functional
dependencies between devices to help with power management. Mauro has
spoken briefly before over the media controller feature graph used to help
build relationship between complex dynamic dependencies. Dmitry has taken on
to help enable asynchronous probe, however for built-in devices this requires
very specific platform knowledge otherwise using async probe will blow up
your kernel -- if you get it right though, using async probe can help with
boot. Even if you sort things out well -- there are current limitations with
ordering semantics available, case in point the x86 IOMMUs already have a small
sort run which expand beyond the core init entries allowed, and on top of this
the you still have device driver dependencies which are implicitly setting
order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
AMD KFD, and AMD radeon. This has made us realize that at the module front the
current 2 levels of init calls limits our ordering semantics leaving only link
order as a last measure when things are built-in. Likewise I've recently have
had to look into dependency issues early in boot been due to differences
between paravirtualization and non-PV kernels, this lead to some current work
to help generalize custom section uses (linker tables) and then for us to
consider expanding x86 semantics early in boot to address some of the
shortcomings implicit by the some paravirtualized boot path.

The goal behind Rafael's work's goal is essentially to avoid code duplication
(as without doing that in the core many drivers potentially need to do the same
thing in the same way) and help to address the asynchronous system
suspend/resume case that cannot be addressed by any driver by itself anyway.
The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
however the patterns are very similar: addressing complex dependencies and
relationships at run time and available semantics for these.

This begs a few questions:

 o Are there generic issues here ?
 o Are there generic solutions possible ?
 o What advanced techniques are out there to deal with this and how
   are efforts in those domains going ?

As an example of taste for the last item, consider Vegard Nossum's involvement
with a SAT solver (picosat) for AFL fuzzing with ext4 on built-in kernels --
and the possibility to share some of the tools to address some of the
dependencies here. As it stands kconfig's semantics are a bit of a mess, and
in turn often tools have to do a bit of inference work due to some of this,
part if this problem is one reason why current kconfig-sat efforts are a bit
stalled.

Benefits for addressing some of these topics generally has quite a bit of
uses in different domains:

  o Speeding up boot time
  o Avoiding dead code, or correctness
  o Shrinking kernel size

This is a pretty generally broad topic, and it does cross subsystems,
I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
Mauro, and Rafael in February this year about a LPC microconference
about this sort of stuff as I thought that would have been a better venue --
however even early then (February !) it seems they were busy with existing LPC
microconferences. I recently poked them and they seem to agree discussing this
somehow at KS would be good. Due to existing time constraints at LPC, but given
most interested folks may be at KS or Plumbers, it'd be good to use shared time
at KS and LPC to get folks to organize ideas, problems, and solutions and in a
more adhoc manner, and then enable organically folks interested to organize and
discuss short term and long term roadmaps on respective work items. Its unclear
yet if there is a very CORE TOPIC here -- my guess would be that if there were
we'd find out at the next KS, but not this one. A workshop for this might
help.

Folks required to help with these topics:

  o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
  o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional dependencies)
  o Marek Szyprowski <m.szyprowski@samsung.com> (taking on some of
Rafael's previous work)
  o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
  o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
  o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
kconfig issues)

  Luis

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

On Wed, Jul 27, 2016 at 09:50:04AM -0700, Luis R. Rodriguez wrote:

> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has

This wasn't purely for PM, it should also help with probe ordering
(hopefully).

> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on

> to help enable asynchronous probe, however for built-in devices this requires
> very specific platform knowledge otherwise using async probe will blow up
> your kernel -- if you get it right though, using async probe can help with

I'm not sure what specific platform knowledge you're thinking of here?
We have coverage for most things in the form of deferred probe (messy
though it is).

> This begs a few questions:

>  o Are there generic issues here ?
>  o Are there generic solutions possible ?
>  o What advanced techniques are out there to deal with this and how
>    are efforts in those domains going ?

There's definitely a lot of overlap in the runtime PM and probe parts of
things, and the various composite devices (media controller, ASoC and so
on) also share a lot.

> Folks required to help with these topics:

>   o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
>   o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional dependencies)
>   o Marek Szyprowski <m.szyprowski@samsung.com> (taking on some of
> Rafael's previous work)
>   o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
>   o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
>   o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
> kconfig issues)

Probably worth me being involved as well, regulators seem to be among
the devices with most visible PM related ordering issues since they are
typically on slow buses and ASoC is all about composite devices.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Luis R. Rodriguez]

On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> > to help enable asynchronous probe, however for built-in devices this requires
> > very specific platform knowledge otherwise using async probe will blow up
> > your kernel -- if you get it right though, using async probe can help with
> 
> I'm not sure what specific platform knowledge you're thinking of here?
> We have coverage for most things in the form of deferred probe (messy
> though it is).

Deferred probe is a complete a hack and sub-optimal. Being able to address
ordering properly without much overhead would optimize this, to do this
properly though you really need to do a bit of kernel work, so in practice a
bit of delta carried. For instance, if using built-in you'd hope that all
your device ordering is already handled through the current set of init
levels of the kernel. As the kernel boots the later in boot gets the larger
the series of dependencies we can have and as such we end up running either
out of semantics for this, or knowing to to ensure proper link order is
in place. Some of this work is implicit, some explicit -- it depends on
the toolbox we use. The goal here is to evaluate the toolbox, if we should
grow it, and if so how.

> Probably worth me being involved as well, regulators seem to be among
> the devices with most visible PM related ordering issues since they are
> typically on slow buses and ASoC is all about composite devices.

Good to know thanks.

  Luis

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> > > to help enable asynchronous probe, however for built-in devices this requires
> > > very specific platform knowledge otherwise using async probe will blow up
> > > your kernel -- if you get it right though, using async probe can help with

> > I'm not sure what specific platform knowledge you're thinking of here?
> > We have coverage for most things in the form of deferred probe (messy
> > though it is).

> Deferred probe is a complete a hack and sub-optimal. Being able to address

Sure, I don't think anyone disagrees on that but it does mean we don't
actually blow up easily like we used to - it's messy but it does get
there safely.  I was specifically querying your statement that things
would blow up.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Luis R. Rodriguez]

On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> > > > to help enable asynchronous probe, however for built-in devices this requires
> > > > very specific platform knowledge otherwise using async probe will blow up
> > > > your kernel -- if you get it right though, using async probe can help with
> 
> > > I'm not sure what specific platform knowledge you're thinking of here?
> > > We have coverage for most things in the form of deferred probe (messy
> > > though it is).
> 
> > Deferred probe is a complete a hack and sub-optimal. Being able to address
> 
> Sure, I don't think anyone disagrees on that but it does mean we don't
> actually blow up easily like we used to - it's messy but it does get
> there safely.

Good point, without learning from the past we would otherwise expect
this is just a sloppy situation, so indeed deferred probe had its
merits, and we're at least now safe. The goal here is then how to
do this better, optimized and make it a non-hack.

> I was specifically querying your statement that things would blow up.

In practice this varies as it depends on the device driver or component,
but the general theme seems to be "relying on something which is not
yet available".

  Luis

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

[Rafael J. Wysocki]

On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
> > On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
> > > On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> > > > > to help enable asynchronous probe, however for built-in devices this requires
> > > > > very specific platform knowledge otherwise using async probe will blow up
> > > > > your kernel -- if you get it right though, using async probe can help with
> > 
> > > > I'm not sure what specific platform knowledge you're thinking of here?
> > > > We have coverage for most things in the form of deferred probe (messy
> > > > though it is).
> > 
> > > Deferred probe is a complete a hack and sub-optimal. Being able to address
> > 
> > Sure, I don't think anyone disagrees on that but it does mean we don't
> > actually blow up easily like we used to - it's messy but it does get
> > there safely.
> 
> Good point, without learning from the past we would otherwise expect
> this is just a sloppy situation, so indeed deferred probe had its
> merits, and we're at least now safe. The goal here is then how to
> do this better, optimized and make it a non-hack.

Well, my patchset uses deferred probing, so it won't help much here I guess.

> > I was specifically querying your statement that things would blow up.
> 
> In practice this varies as it depends on the device driver or component,
> but the general theme seems to be "relying on something which is not
> yet available".

Not only that.

There also is a "relying on something that is not a direct ancestor of the
device you care about" angle of that.

The device hierarchy as we know it is insufficient for representing dependencies
beyond parent-child and that really is part of the problem, and a significant
one IMO.

Thanks,
Rafael

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

[Laurent Pinchart]

On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
> On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
>> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
>>> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
>>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>>>> to help enable asynchronous probe, however for built-in devices
>>>>>> this requires very specific platform knowledge otherwise using
>>>>>> async probe will blow up your kernel -- if you get it right
>>>>>> though, using async probe can help with
>>>>>
>>>>> I'm not sure what specific platform knowledge you're thinking of
>>>>> here? We have coverage for most things in the form of deferred probe
>>>>> (messy though it is).
>>>> 
>>>> Deferred probe is a complete a hack and sub-optimal. Being able to
>>>> address
>>> 
>>> Sure, I don't think anyone disagrees on that but it does mean we don't
>>> actually blow up easily like we used to - it's messy but it does get
>>> there safely.
>> 
>> Good point, without learning from the past we would otherwise expect
>> this is just a sloppy situation, so indeed deferred probe had its
>> merits, and we're at least now safe. The goal here is then how to
>> do this better, optimized and make it a non-hack.

Let's not demonize deferred probing, I think it's a good safety net to be used 
as a last resort when everything else failed. The problem is that we're using 
it as our primary mean to order initialization, and that leads to all sorts of 
inefficient behaviours at boot time.

> Well, my patchset uses deferred probing, so it won't help much here I guess.
>
>>> I was specifically querying your statement that things would blow up.
>> 
>> In practice this varies as it depends on the device driver or component,
>> but the general theme seems to be "relying on something which is not
>> yet available".
> 
> Not only that.
> 
> There also is a "relying on something that is not a direct ancestor of the
> device you care about" angle of that.
> 
> The device hierarchy as we know it is insufficient for representing
> dependencies beyond parent-child and that really is part of the problem,
> and a significant one IMO.

That's the core of the issue.

Linux has traditionally represented the device hierarchy from a control bus 
point of view, both in the driver model and in DT. We know other dependencies 
exist (data bus access, clocks, regulators, power domains, ...), and we try to 
address them with various heuristics.

One problem with those other dependencies is that they can't always be 
expressed as a tree and may a graph instead. Worse, in some cases, the graph 
can be cyclic (I've recently been told about an external I2C-based PLL that 
takes an input clock and generates an output clock, with the input clock being 
produced by an on-SoC sound device and the output clock being used by the same 
sound device). Even when individual resource trees or graphs are not cyclic, 
combining them in a global dependency graph will often result in cycles. The 
challenge is to find a proper way to both express the dependency graph and 
break the cycles.

-- 
Regards,

Laurent Pinchart

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

[Hans Verkuil]

On 07/28/2016 12:41 PM, Laurent Pinchart wrote:
> On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
>> On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
>>> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
>>>> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
>>>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>>>>> to help enable asynchronous probe, however for built-in devices
>>>>>>> this requires very specific platform knowledge otherwise using
>>>>>>> async probe will blow up your kernel -- if you get it right
>>>>>>> though, using async probe can help with
>>>>>>
>>>>>> I'm not sure what specific platform knowledge you're thinking of
>>>>>> here? We have coverage for most things in the form of deferred probe
>>>>>> (messy though it is).
>>>>>
>>>>> Deferred probe is a complete a hack and sub-optimal. Being able to
>>>>> address
>>>>
>>>> Sure, I don't think anyone disagrees on that but it does mean we don't
>>>> actually blow up easily like we used to - it's messy but it does get
>>>> there safely.
>>>
>>> Good point, without learning from the past we would otherwise expect
>>> this is just a sloppy situation, so indeed deferred probe had its
>>> merits, and we're at least now safe. The goal here is then how to
>>> do this better, optimized and make it a non-hack.
> 
> Let's not demonize deferred probing, I think it's a good safety net to be used 
> as a last resort when everything else failed. The problem is that we're using 
> it as our primary mean to order initialization, and that leads to all sorts of 
> inefficient behaviours at boot time.
> 
>> Well, my patchset uses deferred probing, so it won't help much here I guess.
>>
>>>> I was specifically querying your statement that things would blow up.
>>>
>>> In practice this varies as it depends on the device driver or component,
>>> but the general theme seems to be "relying on something which is not
>>> yet available".
>>
>> Not only that.
>>
>> There also is a "relying on something that is not a direct ancestor of the
>> device you care about" angle of that.
>>
>> The device hierarchy as we know it is insufficient for representing
>> dependencies beyond parent-child and that really is part of the problem,
>> and a significant one IMO.
> 
> That's the core of the issue.
> 
> Linux has traditionally represented the device hierarchy from a control bus 
> point of view, both in the driver model and in DT. We know other dependencies 
> exist (data bus access, clocks, regulators, power domains, ...), and we try to 
> address them with various heuristics.
> 
> One problem with those other dependencies is that they can't always be 
> expressed as a tree and may a graph instead. Worse, in some cases, the graph 
> can be cyclic (I've recently been told about an external I2C-based PLL that 
> takes an input clock and generates an output clock, with the input clock being 
> produced by an on-SoC sound device and the output clock being used by the same 
> sound device). Even when individual resource trees or graphs are not cyclic, 
> combining them in a global dependency graph will often result in cycles. The 
> challenge is to find a proper way to both express the dependency graph and 
> break the cycles.
> 

Do we need to capture 100% of all the weird and wonderful dependencies? I think
(speaking for the media subsystem) that the vast majority of the dependencies
are pretty simple trees without cycles. Being able to capture that would be a
huge help. The remaining more complex devices could still fall back on deferred
probe, I'd say.

I'm never very keen on creating complex code to cater to a small percentage of
problem cases.

Regards,

	Hans

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

[Laurent Pinchart]

Hi Hans,

On Thursday 28 Jul 2016 12:54:47 Hans Verkuil wrote:
> On 07/28/2016 12:41 PM, Laurent Pinchart wrote:
> > On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
> >> On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
> >>> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
> >>>> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
> >>>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> >>>>>>> to help enable asynchronous probe, however for built-in devices
> >>>>>>> this requires very specific platform knowledge otherwise using
> >>>>>>> async probe will blow up your kernel -- if you get it right
> >>>>>>> though, using async probe can help with
> >>>>>> 
> >>>>>> I'm not sure what specific platform knowledge you're thinking of
> >>>>>> here? We have coverage for most things in the form of deferred probe
> >>>>>> (messy though it is).
> >>>>> 
> >>>>> Deferred probe is a complete a hack and sub-optimal. Being able to
> >>>>> address
> >>>> 
> >>>> Sure, I don't think anyone disagrees on that but it does mean we don't
> >>>> actually blow up easily like we used to - it's messy but it does get
> >>>> there safely.
> >>> 
> >>> Good point, without learning from the past we would otherwise expect
> >>> this is just a sloppy situation, so indeed deferred probe had its
> >>> merits, and we're at least now safe. The goal here is then how to
> >>> do this better, optimized and make it a non-hack.
> > 
> > Let's not demonize deferred probing, I think it's a good safety net to be
> > used as a last resort when everything else failed. The problem is that
> > we're using it as our primary mean to order initialization, and that
> > leads to all sorts of inefficient behaviours at boot time.
> > 
> >> Well, my patchset uses deferred probing, so it won't help much here I
> >> guess.
> >>
> >>>> I was specifically querying your statement that things would blow up.
> >>> 
> >>> In practice this varies as it depends on the device driver or component,
> >>> but the general theme seems to be "relying on something which is not
> >>> yet available".
> >> 
> >> Not only that.
> >> 
> >> There also is a "relying on something that is not a direct ancestor of
> >> the device you care about" angle of that.
> >> 
> >> The device hierarchy as we know it is insufficient for representing
> >> dependencies beyond parent-child and that really is part of the problem,
> >> and a significant one IMO.
> > 
> > That's the core of the issue.
> > 
> > Linux has traditionally represented the device hierarchy from a control
> > bus point of view, both in the driver model and in DT. We know other
> > dependencies exist (data bus access, clocks, regulators, power domains,
> > ...), and we try to address them with various heuristics.
> > 
> > One problem with those other dependencies is that they can't always be
> > expressed as a tree and may a graph instead. Worse, in some cases, the
> > graph can be cyclic (I've recently been told about an external I2C-based
> > PLL that takes an input clock and generates an output clock, with the
> > input clock being produced by an on-SoC sound device and the output clock
> > being used by the same sound device). Even when individual resource trees
> > or graphs are not cyclic, combining them in a global dependency graph
> > will often result in cycles. The challenge is to find a proper way to
> > both express the dependency graph and break the cycles.
> 
> Do we need to capture 100% of all the weird and wonderful dependencies? I
> think (speaking for the media subsystem) that the vast majority of the
> dependencies are pretty simple trees without cycles. Being able to capture
> that would be a huge help. The remaining more complex devices could still
> fall back on deferred probe, I'd say.

When dealing with a single type of resources dependency graphs are very rarely 
cyclic. However, when merging multiple resource dependency graphs, cycles 
become quite common.

One example is the camera device found in OMAP3 chips. The SoC-side camera 
controller can output a clock to the outside world (and is thus a CCF clock 
provider). In most hardware designs that clock is used by the external camera 
sensors, which in turn outputs a video data stream (with a clock and other 
synchronization signals) fed to the camera controller. We thus get a 
dependency loop. The situation is even worse on some Atmel platforms where 
part of the camera controller logic is clocked by the pixel clock received 
from the sensor. In that case the camera controller can't be software reset 
without a sensor providing a pixel clock. We can blame the hardware designers, 
but at the end of the day we need to support such systems. Whether such cases 
need to be supported by generic code is a discussion we can have, and I'm not 
pushing in either direction, but I want to make sure we will always have *a* 
solution.

> I'm never very keen on creating complex code to cater to a small percentage
> of problem cases.

-- 
Regards,

Laurent Pinchart

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

[Jan Kara]

Hi,

On Thu 28-07-16 14:03:46, Laurent Pinchart wrote:
> On Thursday 28 Jul 2016 12:54:47 Hans Verkuil wrote:
> > > One problem with those other dependencies is that they can't always be
> > > expressed as a tree and may a graph instead. Worse, in some cases, the
> > > graph can be cyclic (I've recently been told about an external I2C-based
> > > PLL that takes an input clock and generates an output clock, with the
> > > input clock being produced by an on-SoC sound device and the output clock
> > > being used by the same sound device). Even when individual resource trees
> > > or graphs are not cyclic, combining them in a global dependency graph
> > > will often result in cycles. The challenge is to find a proper way to
> > > both express the dependency graph and break the cycles.
> > 
> > Do we need to capture 100% of all the weird and wonderful dependencies? I
> > think (speaking for the media subsystem) that the vast majority of the
> > dependencies are pretty simple trees without cycles. Being able to capture
> > that would be a huge help. The remaining more complex devices could still
> > fall back on deferred probe, I'd say.
> 
> When dealing with a single type of resources dependency graphs are very rarely 
> cyclic. However, when merging multiple resource dependency graphs, cycles 
> become quite common.
> 
> One example is the camera device found in OMAP3 chips. The SoC-side camera 
> controller can output a clock to the outside world (and is thus a CCF clock 
> provider). In most hardware designs that clock is used by the external camera 
> sensors, which in turn outputs a video data stream (with a clock and other 
> synchronization signals) fed to the camera controller. We thus get a 
> dependency loop. The situation is even worse on some Atmel platforms where 
> part of the camera controller logic is clocked by the pixel clock received 
> from the sensor. In that case the camera controller can't be software reset 
> without a sensor providing a pixel clock. We can blame the hardware designers, 
> but at the end of the day we need to support such systems. Whether such cases 
> need to be supported by generic code is a discussion we can have, and I'm not 
> pushing in either direction, but I want to make sure we will always have *a* 
> solution.

So I'm complete outsider to media drivers so maybe my question is stupid
but I cannot resist: So how is the device bringup supposed to work for
devices where you have these cycles in the dependency graph? Do you just
bring up the controller and then the sensor and it works because the
controller doesn't need the clock from the sensor for startup?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Thu, Jul 28, 2016 at 01:46:24PM +0200, Jan Kara wrote:

> So I'm complete outsider to media drivers so maybe my question is stupid
> but I cannot resist: So how is the device bringup supposed to work for
> devices where you have these cycles in the dependency graph? Do you just
> bring up the controller and then the sensor and it works because the
> controller doesn't need the clock from the sensor for startup?

For audio you don't tend to actually bring the device up and start fully
using it until it's needed to perform some task and when you do that
there usually is some definite procedure that works at a more granualar
level than the full devices.  In order to enumerate everything for the
Linux device model you want to know about all the dependencies and
ideally verify that they'll be there when you need them but you don't
actually need to use them at that point.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laurent Pinchart]

Hi Jan,

On Thursday 28 Jul 2016 13:46:24 Jan Kara wrote:
> On Thu 28-07-16 14:03:46, Laurent Pinchart wrote:
> > On Thursday 28 Jul 2016 12:54:47 Hans Verkuil wrote:
> >>> One problem with those other dependencies is that they can't always be
> >>> expressed as a tree and may a graph instead. Worse, in some cases, the
> >>> graph can be cyclic (I've recently been told about an external
> >>> I2C-based PLL that takes an input clock and generates an output clock,
> >>> with the input clock being produced by an on-SoC sound device and the
> >>> output clock being used by the same sound device). Even when
> >>> individual resource trees or graphs are not cyclic, combining them in
> >>> a global dependency graph will often result in cycles. The challenge
> >>> is to find a proper way to both express the dependency graph and break
> >>> the cycles.
> >> 
> >> Do we need to capture 100% of all the weird and wonderful dependencies?
> >> I think (speaking for the media subsystem) that the vast majority of the
> >> dependencies are pretty simple trees without cycles. Being able to
> >> capture that would be a huge help. The remaining more complex devices
> >> could still fall back on deferred probe, I'd say.
> > 
> > When dealing with a single type of resources dependency graphs are very
> > rarely cyclic. However, when merging multiple resource dependency graphs,
> > cycles become quite common.
> > 
> > One example is the camera device found in OMAP3 chips. The SoC-side camera
> > controller can output a clock to the outside world (and is thus a CCF
> > clock provider). In most hardware designs that clock is used by the
> > external camera sensors, which in turn outputs a video data stream (with a
> > clock and other synchronization signals) fed to the camera controller. We
> > thus get a dependency loop. The situation is even worse on some Atmel
> > platforms where part of the camera controller logic is clocked by the
> > pixel clock received from the sensor. In that case the camera controller
> > can't be software reset without a sensor providing a pixel clock. We can
> > blame the hardware designers, but at the end of the day we need to
> > support such systems. Whether such cases need to be supported by generic
> > code is a discussion we can have, and I'm not pushing in either
> > direction, but I want to make sure we will always have *a* solution.
> 
> So I'm complete outsider to media drivers so maybe my question is stupid
> but I cannot resist: So how is the device bringup supposed to work for
> devices where you have these cycles in the dependency graph? Do you just
> bring up the controller and then the sensor and it works because the
> controller doesn't need the clock from the sensor for startup?

That's pretty much the idea, yes. We first probe the controller, and register 
a notifier to react to sensors being probed. The controller registers at probe 
time the clocks it provides, so the sensor can get hold of them when it gets 
probed. The controller is then notified that the sensor is available and 
proceeds normally.

We also have a suspend/resume ordering issue, where we have to stop the 
controller first (the hardware doesn't like when it loses the incoming video 
stream while running), but we can't stop the clock just yet before the sensor 
driver has a chance to suspend the sensor. We thus use the PM prepare and 
complete callbacks to stop/restart the controller, and the PM suspend and 
resume callbacks to stop/restart the clock. This is a hack that assumes that 
the sensor gets probed after the controller (which is guaranteed by the fact 
that the sensor needs a clock provided by the controller and thus probe will 
be deferred if the controller hasn't been probed yet) and that the sensor 
driver will use the PM suspend/resume callbacks, not the prepare/complete 
callbacks. Ugly, but for now it works.

In the case of the Atmel device I mentioned we just don't reset the hardware 
at probe time. We can still access the hardware registers we need without 
getting a pixel clock, so it's not such a big deal. It would have been worse 
if the hardware designers had decided to clock all registers with the pixel 
clock.

-- 
Regards,

Laurent Pinchart

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

[Jan Kara]

Hi Laurent!

On Thu 28-07-16 19:00:36, Laurent Pinchart wrote:
> On Thursday 28 Jul 2016 13:46:24 Jan Kara wrote:
> > On Thu 28-07-16 14:03:46, Laurent Pinchart wrote:
> > > On Thursday 28 Jul 2016 12:54:47 Hans Verkuil wrote:
> > >>> One problem with those other dependencies is that they can't always be
> > >>> expressed as a tree and may a graph instead. Worse, in some cases, the
> > >>> graph can be cyclic (I've recently been told about an external
> > >>> I2C-based PLL that takes an input clock and generates an output clock,
> > >>> with the input clock being produced by an on-SoC sound device and the
> > >>> output clock being used by the same sound device). Even when
> > >>> individual resource trees or graphs are not cyclic, combining them in
> > >>> a global dependency graph will often result in cycles. The challenge
> > >>> is to find a proper way to both express the dependency graph and break
> > >>> the cycles.
> > >> 
> > >> Do we need to capture 100% of all the weird and wonderful dependencies?
> > >> I think (speaking for the media subsystem) that the vast majority of the
> > >> dependencies are pretty simple trees without cycles. Being able to
> > >> capture that would be a huge help. The remaining more complex devices
> > >> could still fall back on deferred probe, I'd say.
> > > 
> > > When dealing with a single type of resources dependency graphs are very
> > > rarely cyclic. However, when merging multiple resource dependency graphs,
> > > cycles become quite common.
> > > 
> > > One example is the camera device found in OMAP3 chips. The SoC-side camera
> > > controller can output a clock to the outside world (and is thus a CCF
> > > clock provider). In most hardware designs that clock is used by the
> > > external camera sensors, which in turn outputs a video data stream (with a
> > > clock and other synchronization signals) fed to the camera controller. We
> > > thus get a dependency loop. The situation is even worse on some Atmel
> > > platforms where part of the camera controller logic is clocked by the
> > > pixel clock received from the sensor. In that case the camera controller
> > > can't be software reset without a sensor providing a pixel clock. We can
> > > blame the hardware designers, but at the end of the day we need to
> > > support such systems. Whether such cases need to be supported by generic
> > > code is a discussion we can have, and I'm not pushing in either
> > > direction, but I want to make sure we will always have *a* solution.
> > 
> > So I'm complete outsider to media drivers so maybe my question is stupid
> > but I cannot resist: So how is the device bringup supposed to work for
> > devices where you have these cycles in the dependency graph? Do you just
> > bring up the controller and then the sensor and it works because the
> > controller doesn't need the clock from the sensor for startup?
> 
> That's pretty much the idea, yes. We first probe the controller, and register 
> a notifier to react to sensors being probed. The controller registers at probe 
> time the clocks it provides, so the sensor can get hold of them when it gets 
> probed. The controller is then notified that the sensor is available and 
> proceeds normally.
> 
> We also have a suspend/resume ordering issue, where we have to stop the 
> controller first (the hardware doesn't like when it loses the incoming video 
> stream while running), but we can't stop the clock just yet before the sensor 
> driver has a chance to suspend the sensor. We thus use the PM prepare and 
> complete callbacks to stop/restart the controller, and the PM suspend and 
> resume callbacks to stop/restart the clock. This is a hack that assumes that 
> the sensor gets probed after the controller (which is guaranteed by the fact 
> that the sensor needs a clock provided by the controller and thus probe will 
> be deferred if the controller hasn't been probed yet) and that the sensor 
> driver will use the PM suspend/resume callbacks, not the prepare/complete 
> callbacks. Ugly, but for now it works.

Thanks for explanation. So from the explanation it seems to me that the
cycles in the directed graph of devices arise for two reasons:

1) Edges in the graph express different types of dependencies (i.e., boot
dependency graph is not necessarily the same as suspend dependency graph)
and thus cycles are created.

2) Some of the vertices in the graph currently express several separately
controllable entities which may possibly need to be brought up / suspended /
whatever at different times and this merging of vertices creates cycles.

So if we actually had several different graphs - one for each operation
(boot, suspend, I-don't-know-what-else-one-can-do-with-devices) -
expressing dependencies for that operation where vertices would correspond
to the smallest separately controllable entities for that operation, then
each of these graphs would be acyclic.

Now whether this would be a practical solution I don't know (one problem
may be the memory overhead, another may be number of different operations
one needs to track, and yet another whether one can easily determine
dependencies for each operation in advance). But it would be a theorically
clean one :)

								Honza 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Alexandre Belloni]

Hi,

On 28/07/2016 at 19:00:36 +0300, Laurent Pinchart wrote :
> > So I'm complete outsider to media drivers so maybe my question is stupid
> > but I cannot resist: So how is the device bringup supposed to work for
> > devices where you have these cycles in the dependency graph? Do you just
> > bring up the controller and then the sensor and it works because the
> > controller doesn't need the clock from the sensor for startup?
> 
> That's pretty much the idea, yes. We first probe the controller, and register 
> a notifier to react to sensors being probed. The controller registers at probe 
> time the clocks it provides, so the sensor can get hold of them when it gets 
> probed. The controller is then notified that the sensor is available and 
> proceeds normally.
> 
> We also have a suspend/resume ordering issue, where we have to stop the 
> controller first (the hardware doesn't like when it loses the incoming video 
> stream while running), but we can't stop the clock just yet before the sensor 
> driver has a chance to suspend the sensor. We thus use the PM prepare and 
> complete callbacks to stop/restart the controller, and the PM suspend and 
> resume callbacks to stop/restart the clock. This is a hack that assumes that 
> the sensor gets probed after the controller (which is guaranteed by the fact 
> that the sensor needs a clock provided by the controller and thus probe will 
> be deferred if the controller hasn't been probed yet) and that the sensor 
> driver will use the PM suspend/resume callbacks, not the prepare/complete 
> callbacks. Ugly, but for now it works.
> 
> In the case of the Atmel device I mentioned we just don't reset the hardware 
> at probe time. We can still access the hardware registers we need without 
> getting a pixel clock, so it's not such a big deal. It would have been worse 
> if the hardware designers had decided to clock all registers with the pixel 
> clock.
> 

Well, I'm starting to be more and more interested in that thread as I'm
currently working on getting the Atmel "Backup mode" (CPU/SoC off and
DDR in self refresh) working and this is a device (re)initialization
hell.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Steven Rostedt]

On Thu, 28 Jul 2016 13:46:24 +0200
Jan Kara <jack@suse.cz> wrote:


> So I'm complete outsider to media drivers so maybe my question is stupid
> but I cannot resist: So how is the device bringup supposed to work for
> devices where you have these cycles in the dependency graph? Do you just
> bring up the controller and then the sensor and it works because the
> controller doesn't need the clock from the sensor for startup?

Thanks for asking. I was wondering the exact same thing.

-- Steve

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

[Laurent Pinchart]

On Friday 29 Jul 2016 21:59:06 Steven Rostedt wrote:
> On Thu, 28 Jul 2016 13:46:24 +0200 Jan Kara wrote:
> > So I'm complete outsider to media drivers so maybe my question is stupid
> > but I cannot resist: So how is the device bringup supposed to work for
> > devices where you have these cycles in the dependency graph? Do you just
> > bring up the controller and then the sensor and it works because the
> > controller doesn't need the clock from the sensor for startup?
> 
> Thanks for asking. I was wondering the exact same thing.

If this doesn't get addressed during a tech session, I'd be glad to explain 
this for both V4L2 and DRM in the hallway track to anyone interested. If the 
crowd gets large then a room with a white board or a projector could help 
though.

-- 
Regards,

Laurent Pinchart

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

[Lars-Peter Clausen]

On 07/28/2016 01:03 PM, Laurent Pinchart wrote:
[...]
>> Do we need to capture 100% of all the weird and wonderful dependencies? I
>> think (speaking for the media subsystem) that the vast majority of the
>> dependencies are pretty simple trees without cycles. Being able to capture
>> that would be a huge help. The remaining more complex devices could still
>> fall back on deferred probe, I'd say.
> 
> When dealing with a single type of resources dependency graphs are very rarely 
> cyclic. However, when merging multiple resource dependency graphs, cycles 
> become quite common.

I've brought this up in my presentation about DAPM (Dynamic Audio Power
Management). I'd like to make DAPM, which is currently only available as
part of the ASoC framework, more generic and export concepts that have
been pioneered there to the general kernel
(http://events.linuxfoundation.org/sites/events/files/slides/dapm.pdf#page=45).
DAPM was designed to able to handle these kinds of dependencies since
they are very common in audio systems. This is done by splitting the
power management process into two phases. First phase is to compute what
needs to be powered up based on a dependency graph. The dependencies are
not expressed between devices, but device subblocks, so called widgets
in DAPM terminology. E.g. if you have a clock chip with multiple clock
output each would get their own widget. Phase 2 in DAPM consists of the
actual power-up/power-down sequencing. This is done in a order that
avoids glitching and ensures all dependencies are powered-up before and
powered-down after the dependent.

This is different to classical power and resource management where you
have reference counted enable/disable callbacks, where only when the
callback is invoked the driver calculates which other resources need to
be enabled and then potentially invokes another callback. E.g. a clock
might need a regulator. The clockchip driver would call
regulator_enable() from it's clk_prepare() callback. And then the
regulator chip driver might enable other resources from its
regulator_enable() callback. This approach easily can lead to cyclic
dependencies that can newer be turned back off again. Whereas DAPM can
resolve this.

One issue with this approach is that you need a power-sequence scheduler
which sits above all devices. E.g. there is no master device that tells
another device it now needs to turn its resources on, but all devices
are equal in the graph and might be both resource provider and resource
consumer. If there is only one scheduler the graph would contain all
devices and be quite big and you'd run into lock contention issues if
operations are performed on different subgraphs at the same time. If you
have multiple schedulers how do you decide which device is managed by
which scheduler as dependencies might be added and removed at runtime.

Also this obviously does not address the probe order issues, but there
is potential to use the same graph structures.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

On Thu, Jul 28, 2016 at 10:12:05PM +0200, Lars-Peter Clausen wrote:

> output each would get their own widget. Phase 2 in DAPM consists of the
> actual power-up/power-down sequencing. This is done in a order that
> avoids glitching and ensures all dependencies are powered-up before and
> powered-down after the dependent.

One fun thing here is that the power up/down sequences are somewhat
application specific however I think that's solvable in a general
environment (there was originally some provision for this in DAPM but it
died as we never found a need for it and the systems are only getting
simpler in this regard) and probably for the bulk of things we're
talking about there are fairly obvious orderings.

> One issue with this approach is that you need a power-sequence scheduler
> which sits above all devices. E.g. there is no master device that tells
> another device it now needs to turn its resources on, but all devices
> are equal in the graph and might be both resource provider and resource
> consumer. If there is only one scheduler the graph would contain all
> devices and be quite big and you'd run into lock contention issues if
> operations are performed on different subgraphs at the same time. If you
> have multiple schedulers how do you decide which device is managed by
> which scheduler as dependencies might be added and removed at runtime.

Lock contention and algorithm runtime are both indeed an issue, though
we've got a bunch of stuff which does a very good job of mitigating
against graph size in DAPM already which can most likely be lifted out
of it and there's doubtless inspiration to be drawn from runtime PM for
the locking.  The nature of ASoC is such that we've never really had to
worry about the locking, a single enormous lock really does make sense
for that specific problem domain.

It's certainly a very effective technique for mitigating against
dependency hell.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laurent Pinchart]

Hi Lars,

On Thursday 28 Jul 2016 22:12:05 Lars-Peter Clausen wrote:
> On 07/28/2016 01:03 PM, Laurent Pinchart wrote:
> [...]
> 
> >> Do we need to capture 100% of all the weird and wonderful dependencies? I
> >> think (speaking for the media subsystem) that the vast majority of the
> >> dependencies are pretty simple trees without cycles. Being able to
> >> capture that would be a huge help. The remaining more complex devices
> >> could still fall back on deferred probe, I'd say.
> > 
> > When dealing with a single type of resources dependency graphs are very
> > rarely cyclic. However, when merging multiple resource dependency graphs,
> > cycles become quite common.
> 
> I've brought this up in my presentation about DAPM (Dynamic Audio Power
> Management). I'd like to make DAPM, which is currently only available as
> part of the ASoC framework, more generic and export concepts that have
> been pioneered there to the general kernel
> (http://events.linuxfoundation.org/sites/events/files/slides/dapm.pdf#page=4
> 5). DAPM was designed to able to handle these kinds of dependencies since
> they are very common in audio systems. This is done by splitting the power
> management process into two phases. First phase is to compute what needs to
> be powered up based on a dependency graph. The dependencies are not
> expressed between devices, but device subblocks, so called widgets in DAPM
> terminology. E.g. if you have a clock chip with multiple clock output each
> would get their own widget. Phase 2 in DAPM consists of the actual
> power-up/power-down sequencing. This is done in a order that avoids
> glitching and ensures all dependencies are powered-up before and
> powered-down after the dependent.
> 
> This is different to classical power and resource management where you
> have reference counted enable/disable callbacks, where only when the
> callback is invoked the driver calculates which other resources need to
> be enabled and then potentially invokes another callback. E.g. a clock
> might need a regulator. The clockchip driver would call
> regulator_enable() from it's clk_prepare() callback. And then the
> regulator chip driver might enable other resources from its
> regulator_enable() callback. This approach easily can lead to cyclic
> dependencies that can newer be turned back off again. Whereas DAPM can
> resolve this.
> 
> One issue with this approach is that you need a power-sequence scheduler
> which sits above all devices. E.g. there is no master device that tells
> another device it now needs to turn its resources on, but all devices
> are equal in the graph and might be both resource provider and resource
> consumer. If there is only one scheduler the graph would contain all
> devices and be quite big and you'd run into lock contention issues if
> operations are performed on different subgraphs at the same time.

This is a problem I expect us to run into with the Media Controller framework 
due to both the tendency of graphs to get larger in recent devices, and the 
(currently unaddressed) need to update graphs dynamically, possibly from 
atomic contexts.

> If you have multiple schedulers how do you decide which device is managed by
> which scheduler as dependencies might be added and removed at runtime.
> 
> Also this obviously does not address the probe order issues, but there
> is potential to use the same graph structures.

-- 
Regards,

Laurent Pinchart

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

[Rafael J. Wysocki]

On Thursday, July 28, 2016 12:54:47 PM Hans Verkuil wrote:
> 
> On 07/28/2016 12:41 PM, Laurent Pinchart wrote:
> > On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
> >> On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
> >>> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
> >>>> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
> >>>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> >>>>>>> to help enable asynchronous probe, however for built-in devices
> >>>>>>> this requires very specific platform knowledge otherwise using
> >>>>>>> async probe will blow up your kernel -- if you get it right
> >>>>>>> though, using async probe can help with
> >>>>>>
> >>>>>> I'm not sure what specific platform knowledge you're thinking of
> >>>>>> here? We have coverage for most things in the form of deferred probe
> >>>>>> (messy though it is).
> >>>>>
> >>>>> Deferred probe is a complete a hack and sub-optimal. Being able to
> >>>>> address
> >>>>
> >>>> Sure, I don't think anyone disagrees on that but it does mean we don't
> >>>> actually blow up easily like we used to - it's messy but it does get
> >>>> there safely.
> >>>
> >>> Good point, without learning from the past we would otherwise expect
> >>> this is just a sloppy situation, so indeed deferred probe had its
> >>> merits, and we're at least now safe. The goal here is then how to
> >>> do this better, optimized and make it a non-hack.
> > 
> > Let's not demonize deferred probing, I think it's a good safety net to be used 
> > as a last resort when everything else failed. The problem is that we're using 
> > it as our primary mean to order initialization, and that leads to all sorts of 
> > inefficient behaviours at boot time.
> > 
> >> Well, my patchset uses deferred probing, so it won't help much here I guess.
> >>
> >>>> I was specifically querying your statement that things would blow up.
> >>>
> >>> In practice this varies as it depends on the device driver or component,
> >>> but the general theme seems to be "relying on something which is not
> >>> yet available".
> >>
> >> Not only that.
> >>
> >> There also is a "relying on something that is not a direct ancestor of the
> >> device you care about" angle of that.
> >>
> >> The device hierarchy as we know it is insufficient for representing
> >> dependencies beyond parent-child and that really is part of the problem,
> >> and a significant one IMO.
> > 
> > That's the core of the issue.
> > 
> > Linux has traditionally represented the device hierarchy from a control bus 
> > point of view, both in the driver model and in DT. We know other dependencies 
> > exist (data bus access, clocks, regulators, power domains, ...), and we try to 
> > address them with various heuristics.
> > 
> > One problem with those other dependencies is that they can't always be 
> > expressed as a tree and may a graph instead. Worse, in some cases, the graph 
> > can be cyclic (I've recently been told about an external I2C-based PLL that 
> > takes an input clock and generates an output clock, with the input clock being 
> > produced by an on-SoC sound device and the output clock being used by the same 
> > sound device). Even when individual resource trees or graphs are not cyclic, 
> > combining them in a global dependency graph will often result in cycles. The 
> > challenge is to find a proper way to both express the dependency graph and 
> > break the cycles.
> > 
> 
> Do we need to capture 100% of all the weird and wonderful dependencies? I think
> (speaking for the media subsystem) that the vast majority of the dependencies
> are pretty simple trees without cycles. Being able to capture that would be a
> huge help. The remaining more complex devices could still fall back on deferred
> probe, I'd say.
> 
> I'm never very keen on creating complex code to cater to a small percentage of
> problem cases.

The problem I'm interested in (and the patches posted are designed to help
address) is specifically when the dependency graph is not a tree.  However,
I don't think it is necessary to cover cycles in a generic way (as they should
be rare enough).

Thanks,
Rafael

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

[Hans Verkuil]

On 07/28/2016 12:41 PM, Laurent Pinchart wrote:
> On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
>> On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
>>> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
>>>> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
>>>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>>>>> to help enable asynchronous probe, however for built-in devices
>>>>>>> this requires very specific platform knowledge otherwise using
>>>>>>> async probe will blow up your kernel -- if you get it right
>>>>>>> though, using async probe can help with
>>>>>>
>>>>>> I'm not sure what specific platform knowledge you're thinking of
>>>>>> here? We have coverage for most things in the form of deferred probe
>>>>>> (messy though it is).
>>>>>
>>>>> Deferred probe is a complete a hack and sub-optimal. Being able to
>>>>> address
>>>>
>>>> Sure, I don't think anyone disagrees on that but it does mean we don't
>>>> actually blow up easily like we used to - it's messy but it does get
>>>> there safely.
>>>
>>> Good point, without learning from the past we would otherwise expect
>>> this is just a sloppy situation, so indeed deferred probe had its
>>> merits, and we're at least now safe. The goal here is then how to
>>> do this better, optimized and make it a non-hack.
> 
> Let's not demonize deferred probing, I think it's a good safety net to be used 
> as a last resort when everything else failed. The problem is that we're using 
> it as our primary mean to order initialization, and that leads to all sorts of 
> inefficient behaviours at boot time.
> 
>> Well, my patchset uses deferred probing, so it won't help much here I guess.
>>
>>>> I was specifically querying your statement that things would blow up.
>>>
>>> In practice this varies as it depends on the device driver or component,
>>> but the general theme seems to be "relying on something which is not
>>> yet available".
>>
>> Not only that.
>>
>> There also is a "relying on something that is not a direct ancestor of the
>> device you care about" angle of that.
>>
>> The device hierarchy as we know it is insufficient for representing
>> dependencies beyond parent-child and that really is part of the problem,
>> and a significant one IMO.
> 
> That's the core of the issue.
> 
> Linux has traditionally represented the device hierarchy from a control bus 
> point of view, both in the driver model and in DT. We know other dependencies 
> exist (data bus access, clocks, regulators, power domains, ...), and we try to 
> address them with various heuristics.
> 
> One problem with those other dependencies is that they can't always be 
> expressed as a tree and may a graph instead. Worse, in some cases, the graph 
> can be cyclic (I've recently been told about an external I2C-based PLL that 
> takes an input clock and generates an output clock, with the input clock being 
> produced by an on-SoC sound device and the output clock being used by the same 
> sound device). Even when individual resource trees or graphs are not cyclic, 
> combining them in a global dependency graph will often result in cycles. The 
> challenge is to find a proper way to both express the dependency graph and 
> break the cycles.
> 

I don't think this really matters when it comes to the probing order. At least in
the media subsystem there is always one driver that should be loaded last since
that is the controller driver (bridge driver) that hooks everything else together.

Being able to model that would allow us to get rid of the v4l2-async.c hack. We'd
never would have needed to make that if we could model proper probe dependencies.

I seriously dislike v4l2-async and anything we can do to get rid of that is very
welcome.

Regards.

	Hans

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

[Laurent Pinchart]

Hi Hans,

On Friday 29 Jul 2016 09:33:03 Hans Verkuil wrote:
> On 07/28/2016 12:41 PM, Laurent Pinchart wrote:
> > On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
> >> On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
> >>> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
> >>>> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
> >>>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> >>>>>>> to help enable asynchronous probe, however for built-in devices
> >>>>>>> this requires very specific platform knowledge otherwise using
> >>>>>>> async probe will blow up your kernel -- if you get it right
> >>>>>>> though, using async probe can help with
> >>>>>> 
> >>>>>> I'm not sure what specific platform knowledge you're thinking of
> >>>>>> here? We have coverage for most things in the form of deferred probe
> >>>>>> (messy though it is).
> >>>>> 
> >>>>> Deferred probe is a complete a hack and sub-optimal. Being able to
> >>>>> address
> >>>> 
> >>>> Sure, I don't think anyone disagrees on that but it does mean we don't
> >>>> actually blow up easily like we used to - it's messy but it does get
> >>>> there safely.
> >>> 
> >>> Good point, without learning from the past we would otherwise expect
> >>> this is just a sloppy situation, so indeed deferred probe had its
> >>> merits, and we're at least now safe. The goal here is then how to
> >>> do this better, optimized and make it a non-hack.
> > 
> > Let's not demonize deferred probing, I think it's a good safety net to be
> > used as a last resort when everything else failed. The problem is that
> > we're using it as our primary mean to order initialization, and that
> > leads to all sorts of inefficient behaviours at boot time.
> > 
> >> Well, my patchset uses deferred probing, so it won't help much here I
> >> guess.
> >>
> >>>> I was specifically querying your statement that things would blow up.
> >>> 
> >>> In practice this varies as it depends on the device driver or component,
> >>> but the general theme seems to be "relying on something which is not
> >>> yet available".
> >> 
> >> Not only that.
> >> 
> >> There also is a "relying on something that is not a direct ancestor of
> >> the device you care about" angle of that.
> >> 
> >> The device hierarchy as we know it is insufficient for representing
> >> dependencies beyond parent-child and that really is part of the problem,
> >> and a significant one IMO.
> > 
> > That's the core of the issue.
> > 
> > Linux has traditionally represented the device hierarchy from a control
> > bus point of view, both in the driver model and in DT. We know other
> > dependencies exist (data bus access, clocks, regulators, power domains,
> > ...), and we try to address them with various heuristics.
> > 
> > One problem with those other dependencies is that they can't always be
> > expressed as a tree and may a graph instead. Worse, in some cases, the
> > graph can be cyclic (I've recently been told about an external I2C-based
> > PLL that takes an input clock and generates an output clock, with the
> > input clock being produced by an on-SoC sound device and the output clock
> > being used by the same sound device). Even when individual resource trees
> > or graphs are not cyclic, combining them in a global dependency graph
> > will often result in cycles. The challenge is to find a proper way to
> > both express the dependency graph and break the cycles.
> 
> I don't think this really matters when it comes to the probing order. At
> least in the media subsystem there is always one driver that should be
> loaded last since that is the controller driver (bridge driver) that hooks
> everything else together.

Pedantic hat on: I assume that by driver loaded last you mean device being 
probed last.

> Being able to model that would allow us to get rid of the v4l2-async.c hack.

Which, for the reader unfamiliar with V4L2, is a framework similar to 
drivers/base/component.c that predates it.

> We'd never would have needed to make that if we could model proper probe
> dependencies.

In OMAP3-based systems the OMAP3 ISP need to be probed first, as it registers 
a clock that sensor drivers need at probe time. The sensor is then bound to 
the ISP through the v4l2-async framework.

> I seriously dislike v4l2-async and anything we can do to get rid of that is
> very welcome.

-- 
Regards,

Laurent Pinchart

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

[Hans Verkuil]

On 08/01/2016 03:03 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Friday 29 Jul 2016 09:33:03 Hans Verkuil wrote:
>> On 07/28/2016 12:41 PM, Laurent Pinchart wrote:
>>> On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
>>>> On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
>>>>> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
>>>>>> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
>>>>>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>>>>>>> to help enable asynchronous probe, however for built-in devices
>>>>>>>>> this requires very specific platform knowledge otherwise using
>>>>>>>>> async probe will blow up your kernel -- if you get it right
>>>>>>>>> though, using async probe can help with
>>>>>>>>
>>>>>>>> I'm not sure what specific platform knowledge you're thinking of
>>>>>>>> here? We have coverage for most things in the form of deferred probe
>>>>>>>> (messy though it is).
>>>>>>>
>>>>>>> Deferred probe is a complete a hack and sub-optimal. Being able to
>>>>>>> address
>>>>>>
>>>>>> Sure, I don't think anyone disagrees on that but it does mean we don't
>>>>>> actually blow up easily like we used to - it's messy but it does get
>>>>>> there safely.
>>>>>
>>>>> Good point, without learning from the past we would otherwise expect
>>>>> this is just a sloppy situation, so indeed deferred probe had its
>>>>> merits, and we're at least now safe. The goal here is then how to
>>>>> do this better, optimized and make it a non-hack.
>>>
>>> Let's not demonize deferred probing, I think it's a good safety net to be
>>> used as a last resort when everything else failed. The problem is that
>>> we're using it as our primary mean to order initialization, and that
>>> leads to all sorts of inefficient behaviours at boot time.
>>>
>>>> Well, my patchset uses deferred probing, so it won't help much here I
>>>> guess.
>>>>
>>>>>> I was specifically querying your statement that things would blow up.
>>>>>
>>>>> In practice this varies as it depends on the device driver or component,
>>>>> but the general theme seems to be "relying on something which is not
>>>>> yet available".
>>>>
>>>> Not only that.
>>>>
>>>> There also is a "relying on something that is not a direct ancestor of
>>>> the device you care about" angle of that.
>>>>
>>>> The device hierarchy as we know it is insufficient for representing
>>>> dependencies beyond parent-child and that really is part of the problem,
>>>> and a significant one IMO.
>>>
>>> That's the core of the issue.
>>>
>>> Linux has traditionally represented the device hierarchy from a control
>>> bus point of view, both in the driver model and in DT. We know other
>>> dependencies exist (data bus access, clocks, regulators, power domains,
>>> ...), and we try to address them with various heuristics.
>>>
>>> One problem with those other dependencies is that they can't always be
>>> expressed as a tree and may a graph instead. Worse, in some cases, the
>>> graph can be cyclic (I've recently been told about an external I2C-based
>>> PLL that takes an input clock and generates an output clock, with the
>>> input clock being produced by an on-SoC sound device and the output clock
>>> being used by the same sound device). Even when individual resource trees
>>> or graphs are not cyclic, combining them in a global dependency graph
>>> will often result in cycles. The challenge is to find a proper way to
>>> both express the dependency graph and break the cycles.
>>
>> I don't think this really matters when it comes to the probing order. At
>> least in the media subsystem there is always one driver that should be
>> loaded last since that is the controller driver (bridge driver) that hooks
>> everything else together.
> 
> Pedantic hat on: I assume that by driver loaded last you mean device being 
> probed last.

Yes and no, see below.

>> Being able to model that would allow us to get rid of the v4l2-async.c hack.
> 
> Which, for the reader unfamiliar with V4L2, is a framework similar to 
> drivers/base/component.c that predates it.
> 
>> We'd never would have needed to make that if we could model proper probe
>> dependencies.
> 
> In OMAP3-based systems the OMAP3 ISP need to be probed first, as it registers 
> a clock that sensor drivers need at probe time. The sensor is then bound to 
> the ISP through the v4l2-async framework.

Not quite. What I would like to see is that when the bridge driver is probed
all dependent other device drivers have been loaded and the device is either
bound or in the list of still unbound devices.

After the bridge driver creates the clocks etc, then it could trigger a final
probe round of the still unbound devices and that would be it.

It's the async part that I really don't like. In fact, if one of the dependent
resources doesn't appear, then the bridge driver's probe() would just sit there
forever. I'd love to have something more deterministic.

Regards,

	Hans

> 
>> I seriously dislike v4l2-async and anything we can do to get rid of that is
>> very welcome.
> 

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

[Jani Nikula]

On Thu, 28 Jul 2016, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Let's not demonize deferred probing, I think it's a good safety net to
> be used as a last resort when everything else failed. The problem is
> that we're using it as our primary mean to order initialization, and
> that leads to all sorts of inefficient behaviours at boot time.

One problem we have with deferred probing (and the reason we're not
using it to fix a bug we still have) is that it essentially requires you
to undo everything you've done before realizing you should return
-EPROBE_DEFER. In our case, we have maybe 90% of our initialization done
at that point, and this goes into the full module unload/reload
territory.

So I admit to being pretty clueless wrt the fine details of module
loading, but I'm wondering if there could be any way of the module being
loaded telling the kernel (via a call, not by returning from probe) to
hold its horses for a while, and keep loading other modules. Sort of
like deferred probe, but without the full cleanup-retry cycle. The call
would return to the module later (not unlike deferred probe retries the
probe), and you could try again whatever it was that made you realize
you need to defer.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

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

[Greg KH]

On Thu, Aug 04, 2016 at 11:22:23AM +0300, Jani Nikula wrote:
> So I admit to being pretty clueless wrt the fine details of module
> loading, but I'm wondering if there could be any way of the module being
> loaded telling the kernel (via a call, not by returning from probe) to
> hold its horses for a while, and keep loading other modules. Sort of
> like deferred probe, but without the full cleanup-retry cycle. The call
> would return to the module later (not unlike deferred probe retries the
> probe), and you could try again whatever it was that made you realize
> you need to defer.

Nope, it doesn't work that way, sorry.

Nice try, just unwind your initialization properly :)

greg k-h

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:

> Nope, it doesn't work that way, sorry.

> Nice try, just unwind your initialization properly :)

Deferred probe is probably the best thing that ever happened for the
quality of kernel error handling :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Jani Nikula]

On Thu, 04 Aug 2016, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:
>
>> Nope, it doesn't work that way, sorry.
>
>> Nice try, just unwind your initialization properly :)
>
> Deferred probe is probably the best thing that ever happened for the
> quality of kernel error handling :)

Heh, I know. All part of the reason we're not propagating deferred probe
from the depths of drm/i915 yet. But even if we were, it's grossly
inefficient for a driver of i915's complexity.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

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

[Rob Herring]

On Thu, Aug 4, 2016 at 5:20 AM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:
>
>> Nope, it doesn't work that way, sorry.
>
>> Nice try, just unwind your initialization properly :)
>
> Deferred probe is probably the best thing that ever happened for the
> quality of kernel error handling :)

Now we just need a way to force testing of the remove functions.

Rob

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

[Arnd Bergmann]

On Thursday, August 4, 2016 9:59:30 PM CEST Rob Herring wrote:
> On Thu, Aug 4, 2016 at 5:20 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:
> >
> >> Nope, it doesn't work that way, sorry.
> >
> >> Nice try, just unwind your initialization properly 
> >
> > Deferred probe is probably the best thing that ever happened for the
> > quality of kernel error handling 
> 
> Now we just need a way to force testing of the remove functions.

Hmm, instead of calling just 'probe', we might first call probe,
then remove, then probe again as a compile-time option.

What could possibly go wrong? ;-)

	Arnd

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

[Greg KH]

On Fri, Aug 05, 2016 at 11:01:43AM +0200, Arnd Bergmann wrote:
> On Thursday, August 4, 2016 9:59:30 PM CEST Rob Herring wrote:
> > On Thu, Aug 4, 2016 at 5:20 AM, Mark Brown <broonie@kernel.org> wrote:
> > > On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:
> > >
> > >> Nope, it doesn't work that way, sorry.
> > >
> > >> Nice try, just unwind your initialization properly 
> > >
> > > Deferred probe is probably the best thing that ever happened for the
> > > quality of kernel error handling 
> > 
> > Now we just need a way to force testing of the remove functions.
> 
> Hmm, instead of calling just 'probe', we might first call probe,
> then remove, then probe again as a compile-time option.
> 
> What could possibly go wrong? ;-)

Ooooh, that would be fun to see what blows up, anyone want to try it?

greg k-h

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

[Andrzej Hajda]

On 08/05/2016 12:54 PM, Greg KH wrote:
> On Fri, Aug 05, 2016 at 11:01:43AM +0200, Arnd Bergmann wrote:
>> On Thursday, August 4, 2016 9:59:30 PM CEST Rob Herring wrote:
>>> On Thu, Aug 4, 2016 at 5:20 AM, Mark Brown <broonie@kernel.org> wrote:
>>>> On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:
>>>>
>>>>> Nope, it doesn't work that way, sorry.
>>>>> Nice try, just unwind your initialization properly 
>>>> Deferred probe is probably the best thing that ever happened for the
>>>> quality of kernel error handling 
>>> Now we just need a way to force testing of the remove functions.
>> Hmm, instead of calling just 'probe', we might first call probe,
>> then remove, then probe again as a compile-time option.
>>
>> What could possibly go wrong? ;-)
> Ooooh, that would be fun to see what blows up, anyone want to try it?

There are already unbind/bind sysfs attributes which do the trick.

Regards
Andrzej

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Fri, Aug 05, 2016 at 01:31:18PM +0200, Andrzej Hajda wrote:
> On 08/05/2016 12:54 PM, Greg KH wrote:
> > On Fri, Aug 05, 2016 at 11:01:43AM +0200, Arnd Bergmann wrote:

> >> Hmm, instead of calling just 'probe', we might first call probe,
> >> then remove, then probe again as a compile-time option.

> >> What could possibly go wrong? ;-)

> > Ooooh, that would be fun to see what blows up, anyone want to try it?

> There are already unbind/bind sysfs attributes which do the trick.

Being able to manually trigger it isn't the same as having a test mode
that just does the bind/unbind/bind - it's much more cumbersome to use,
especially when dependencies come into play.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Greg KH]

On Fri, Aug 05, 2016 at 01:31:18PM +0200, Andrzej Hajda wrote:
> On 08/05/2016 12:54 PM, Greg KH wrote:
> > On Fri, Aug 05, 2016 at 11:01:43AM +0200, Arnd Bergmann wrote:
> >> On Thursday, August 4, 2016 9:59:30 PM CEST Rob Herring wrote:
> >>> On Thu, Aug 4, 2016 at 5:20 AM, Mark Brown <broonie@kernel.org> wrote:
> >>>> On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:
> >>>>
> >>>>> Nope, it doesn't work that way, sorry.
> >>>>> Nice try, just unwind your initialization properly 
> >>>> Deferred probe is probably the best thing that ever happened for the
> >>>> quality of kernel error handling 
> >>> Now we just need a way to force testing of the remove functions.
> >> Hmm, instead of calling just 'probe', we might first call probe,
> >> then remove, then probe again as a compile-time option.
> >>
> >> What could possibly go wrong? ;-)
> > Ooooh, that would be fun to see what blows up, anyone want to try it?
> 
> There are already unbind/bind sysfs attributes which do the trick.

Yes, but that doesn't work so well at boot time, when you want to
probe/remove/probe _all_ of your hardware drivers :)

greg k-h

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

[Rob Herring]

On Fri, Aug 5, 2016 at 5:54 AM, Greg KH <greg@kroah.com> wrote:
> On Fri, Aug 05, 2016 at 11:01:43AM +0200, Arnd Bergmann wrote:
>> On Thursday, August 4, 2016 9:59:30 PM CEST Rob Herring wrote:
>> > On Thu, Aug 4, 2016 at 5:20 AM, Mark Brown <broonie@kernel.org> wrote:
>> > > On Thu, Aug 04, 2016 at 11:50:49AM +0200, Greg KH wrote:
>> > >
>> > >> Nope, it doesn't work that way, sorry.
>> > >
>> > >> Nice try, just unwind your initialization properly
>> > >
>> > > Deferred probe is probably the best thing that ever happened for the
>> > > quality of kernel error handling
>> >
>> > Now we just need a way to force testing of the remove functions.
>>
>> Hmm, instead of calling just 'probe', we might first call probe,
>> then remove, then probe again as a compile-time option.
>>
>> What could possibly go wrong? ;-)
>
> Ooooh, that would be fun to see what blows up, anyone want to try it?

Well, I couldn't resist. Here's results from an x86 VM image.

There's some interesting side effects like this:

[    1.088470] input: QEMU Virtio Mouse as
/devices/pci0000:00/0000:00:07.0/virtio5/input/input2
[    1.089813] input: QEMU Virtio Mouse as
/devices/pci0000:00/0000:00:07.0/virtio5/input/input3
[    1.090945] input: QEMU Virtio Keyboard as
/devices/pci0000:00/0000:00:08.0/virtio6/input/input4
[    1.092275] input: QEMU Virtio Keyboard as
/devices/pci0000:00/0000:00:08.0/virtio6/input/input5

Then it blows up on the DRM driver which is virtio-gpu in this case.

[    1.277522] [drm] Initialized drm 1.1.0 20060810
[    1.277926] [drm] pci: virtio-gpu-pci detected
[    1.278389] [drm] virgl 3d acceleration enabled
[    1.278992] [drm] virtio vbuffers: 272 bufs, 192B each, 51kB total.
[    1.279487] [TTM] Zone  kernel: Available graphics memory: 506732 kiB
[    1.279931] [TTM] Initializing pool allocator
[    1.280247] [TTM] Initializing DMA pool allocator
[    1.280581] [drm] number of scanouts: 1
[    1.280847] [drm] number of cap sets: 1
[    1.281257] [drm] cap set 0: id 1, max-version 1, max-size 308
[    1.282451] virtio_gpu virtio4: fb0: virtiodrmfb frame buffer device
[    1.287125] [drm] Initialized virtio_gpu 0.0.1 0 on minor 0
[    1.291198] ------------[ cut here ]------------
[    1.291654] WARNING: CPU: 0 PID: 1 at
../drivers/gpu/drm/drm_mm.c:773 drm_mm_takedown+0x2a/0x30
[    1.292407] Memory manager not clean during takedown.
[    1.292752] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
4.7.0-rc7+ #17
[    1.293257] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
[    1.294047]  0000000000000000 ffff88003e247bc8 ffffffff8133a383
ffff88003e247c18
[    1.294579]  0000000000000000 ffff88003e247c08 ffffffff81056ca1
000003053e247c20
[    1.295110]  ffff88003da904d8 ffff88003da90078 0000000000000000
ffff88003d6b9740
[    1.295648] Call Trace:
[    1.295821]  [<ffffffff8133a383>] dump_stack+0x65/0x92
[    1.296169]  [<ffffffff81056ca1>] __warn+0xc1/0xe0
[    1.296494]  [<ffffffff81056d0a>] warn_slowpath_fmt+0x4a/0x50
[    1.296883]  [<ffffffff819560a9>] ? _raw_spin_unlock+0x9/0x10
[    1.297271]  [<ffffffff8133bed6>] ? ida_destroy+0x16/0x20
[    1.297637]  [<ffffffff8142ccaa>] drm_mm_takedown+0x2a/0x30
[    1.298016]  [<ffffffff8143d656>] drm_vma_offset_manager_destroy+0x16/0x30
[    1.298480]  [<ffffffff814475c6>] ttm_bo_device_release+0xf6/0x120
[    1.298898]  [<ffffffff815142b1>] virtio_gpu_ttm_fini+0x11/0x40
[    1.299298]  [<ffffffff81510700>] virtio_gpu_driver_unload+0x60/0xc0
[    1.299736]  [<ffffffff81429564>] drm_dev_unregister+0x24/0xa0
[    1.300132]  [<ffffffff814295fe>] drm_put_dev+0x1e/0x60
[    1.300487]  [<ffffffff8150fff0>] virtio_gpu_remove+0x10/0x20
[    1.300876]  [<ffffffff813ce1cb>] virtio_dev_remove+0x3b/0xa0
[    1.301265]  [<ffffffff8151dbc4>] driver_probe_device+0xf4/0x3b0
[    1.301671]  [<ffffffff8151df16>] __driver_attach+0x96/0xa0
[    1.302048]  [<ffffffff8151de80>] ? driver_probe_device+0x3b0/0x3b0
[    1.302471]  [<ffffffff8151be0f>] bus_for_each_dev+0x5f/0x90
[    1.302855]  [<ffffffff8151dff9>] driver_attach+0x19/0x20
[    1.303221]  [<ffffffff8151c8e0>] bus_add_driver+0x1a0/0x210
[    1.303618]  [<ffffffff81f8d605>] ?
trace_event_define_fields_switch_mm+0xb3/0xb3
[    1.304121]  [<ffffffff8151e83b>] driver_register+0x5b/0xd0
[    1.304499]  [<ffffffff81f8d605>] ?
trace_event_define_fields_switch_mm+0xb3/0xb3
[    1.305003]  [<ffffffff813ce6fb>] register_virtio_driver+0x1b/0x30
[    1.305421]  [<ffffffff81f8d615>] virtio_gpu_driver_init+0x10/0x12
[    1.305841]  [<ffffffff81f49007>] do_one_initcall+0x8a/0x11a
[    1.306225]  [<ffffffff81f491f8>] kernel_init_freeable+0x161/0x1ec
[    1.306643]  [<ffffffff81950319>] kernel_init+0x9/0x100
[    1.306997]  [<ffffffff8195647f>] ret_from_fork+0x1f/0x40
[    1.307364]  [<ffffffff81950310>] ? rest_init+0x90/0x90
[    1.307736] ---[ end trace 143836688e11e498 ]---
[    1.308060] [TTM] Finalizing pool allocator
[    1.308364] [TTM] Finalizing DMA pool allocator
[    1.308826] [TTM] Zone  kernel: Used memory at exit: 5153 kiB
[    1.309274] [drm] virtio_gpu: ttm finalized
[    1.309576] ------------[ cut here ]------------
[    1.309893] kernel BUG at ../mm/slub.c:3657!
[    1.310187] invalid opcode: 0000 [#1] PREEMPT SMP
[    1.310507] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W
4.7.0-rc7+ #17
[    1.311014] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
[    1.311873] task: ffff88003e258000 ti: ffff88003e244000 task.ti:
ffff88003e244000
[    1.312451] RIP: 0010:[<ffffffff81172c54>]  [<ffffffff81172c54>]
kfree+0x144/0x180
[    1.313023] RSP: 0000:ffff88003e247cc8  EFLAGS: 00010246
[    1.313424] RAX: ffff88003ffd67e0 RBX: ffff88003da90000 RCX: 000000000002b840
[    1.313956] RDX: 0000000000000000 RSI: ffff88003fa176c0 RDI: ffff88003ffd67df
[    1.314482] RBP: ffff88003e247ce0 R08: 00000000000176c0 R09: ffffffff81510744
[    1.315008] R10: ffffea0000f6a400 R11: 0000000000000600 R12: ffff88003da99250
[    1.315542] R13: ffffffff8151074c R14: ffff88003da99250 R15: ffff88003fa16340
[    1.316080] FS:  0000000000000000(0000) GS:ffff88003fa00000(0000)
knlGS:0000000000000000
[    1.316680] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    1.317108] CR2: 0000000000000000 CR3: 0000000001e07000 CR4: 00000000000006f0
[    1.317674] Stack:
[    1.317828]  ffff88003da99250 ffff88003da99250 ffff88003da90000
ffff88003e247d10
[    1.318407]  ffffffff8151074c ffff88003d479800 ffff88003d479800
ffff88003e379408
[    1.318997]  ffffffff81ea2480 ffff88003e247d38 ffffffff81429564
ffff88003d479800
[    1.319564] Call Trace:
[    1.319749]  [<ffffffff8151074c>] virtio_gpu_driver_unload+0xac/0xc0
[    1.320221]  [<ffffffff81429564>] drm_dev_unregister+0x24/0xa0
[    1.320650]  [<ffffffff814295fe>] drm_put_dev+0x1e/0x60
[    1.321069]  [<ffffffff8150fff0>] virtio_gpu_remove+0x10/0x20
[    1.321628]  [<ffffffff813ce1cb>] virtio_dev_remove+0x3b/0xa0
[    1.322236]  [<ffffffff8151dbc4>] driver_probe_device+0xf4/0x3b0
[    1.322879]  [<ffffffff8151df16>] __driver_attach+0x96/0xa0
[    1.323425]  [<ffffffff8151de80>] ? driver_probe_device+0x3b0/0x3b0
[    1.323969]  [<ffffffff8151be0f>] bus_for_each_dev+0x5f/0x90
[    1.324349]  [<ffffffff8151dff9>] driver_attach+0x19/0x20
[    1.324719]  [<ffffffff8151c8e0>] bus_add_driver+0x1a0/0x210
[    1.325100]  [<ffffffff81f8d605>] ?
trace_event_define_fields_switch_mm+0xb3/0xb3
[    1.325600]  [<ffffffff8151e83b>] driver_register+0x5b/0xd0
[    1.325974]  [<ffffffff81f8d605>] ?
trace_event_define_fields_switch_mm+0xb3/0xb3
[    1.326472]  [<ffffffff813ce6fb>] register_virtio_driver+0x1b/0x30
[    1.326886]  [<ffffffff81f8d615>] virtio_gpu_driver_init+0x10/0x12
[    1.327298]  [<ffffffff81f49007>] do_one_initcall+0x8a/0x11a
[    1.327688]  [<ffffffff81f491f8>] kernel_init_freeable+0x161/0x1ec
[    1.328104]  [<ffffffff81950319>] kernel_init+0x9/0x100
[    1.328455]  [<ffffffff8195647f>] ret_from_fork+0x1f/0x40
[    1.328816]  [<ffffffff81950310>] ? rest_init+0x90/0x90
[    1.329167] Code: c0 75 e6 65 ff 0d 5d 97 e9 7e 74 05 e9 eb fe ff
ff e8 d9 e3 e8 ff e9 e1 fe ff ff 49 8b 02 f6 c4 40 75 0a 49 8b 42 20
a8 01 75 02 <0f> 0b 49 8b 02 31 f6 f6 c4 40 74 04 41 8b 72 6c 4c 89 d7
e8 44
[    1.330960] RIP  [<ffffffff81172c54>] kfree+0x144/0x180
[    1.331318]  RSP <ffff88003e247cc8>
[    1.331592] ---[ end trace 143836688e11e499 ]---

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

[Daniel Vetter]

On Thu, Aug 4, 2016 at 11:50 AM, Greg KH <greg@kroah.com> wrote:
> On Thu, Aug 04, 2016 at 11:22:23AM +0300, Jani Nikula wrote:
>> So I admit to being pretty clueless wrt the fine details of module
>> loading, but I'm wondering if there could be any way of the module being
>> loaded telling the kernel (via a call, not by returning from probe) to
>> hold its horses for a while, and keep loading other modules. Sort of
>> like deferred probe, but without the full cleanup-retry cycle. The call
>> would return to the module later (not unlike deferred probe retries the
>> probe), and you could try again whatever it was that made you realize
>> you need to defer.
>
> Nope, it doesn't work that way, sorry.

Why? If I just postpone the entire driver load to an async worker and
then block if it's not there, that should work?

> Nice try, just unwind your initialization properly :)

There's a slight pratical problem of this being hard to test. Sure in
theory it's easy, but given how often we bomb normal module unload
already (and that's something our CI tests) practice disagrees.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Greg KH]

On Tue, Aug 09, 2016 at 10:08:07AM +0200, Daniel Vetter wrote:
> On Thu, Aug 4, 2016 at 11:50 AM, Greg KH <greg@kroah.com> wrote:
> > On Thu, Aug 04, 2016 at 11:22:23AM +0300, Jani Nikula wrote:
> >> So I admit to being pretty clueless wrt the fine details of module
> >> loading, but I'm wondering if there could be any way of the module being
> >> loaded telling the kernel (via a call, not by returning from probe) to
> >> hold its horses for a while, and keep loading other modules. Sort of
> >> like deferred probe, but without the full cleanup-retry cycle. The call
> >> would return to the module later (not unlike deferred probe retries the
> >> probe), and you could try again whatever it was that made you realize
> >> you need to defer.
> >
> > Nope, it doesn't work that way, sorry.
> 
> Why? If I just postpone the entire driver load to an async worker and
> then block if it's not there, that should work?

Maybe, but the code patch from probe() in the driver core, and module
loader, might be assuming that all is ok, only to have your async init
later on realize that things are not ok.  How you could propagate that
error back into the driver core might be difficult, if not impossible.

> > Nice try, just unwind your initialization properly :)
> 
> There's a slight pratical problem of this being hard to test. Sure in
> theory it's easy, but given how often we bomb normal module unload
> already (and that's something our CI tests) practice disagrees.

probe()/disconnect()/probe() in the driver core as an option might be a
fun way to stress this as others have pointed out here.

thanks,

greg k-h

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

[Daniel Vetter]

On Tue, Aug 9, 2016 at 10:17 AM, Greg KH <greg@kroah.com> wrote:
> On Tue, Aug 09, 2016 at 10:08:07AM +0200, Daniel Vetter wrote:
>> On Thu, Aug 4, 2016 at 11:50 AM, Greg KH <greg@kroah.com> wrote:
>> > On Thu, Aug 04, 2016 at 11:22:23AM +0300, Jani Nikula wrote:
>> >> So I admit to being pretty clueless wrt the fine details of module
>> >> loading, but I'm wondering if there could be any way of the module being
>> >> loaded telling the kernel (via a call, not by returning from probe) to
>> >> hold its horses for a while, and keep loading other modules. Sort of
>> >> like deferred probe, but without the full cleanup-retry cycle. The call
>> >> would return to the module later (not unlike deferred probe retries the
>> >> probe), and you could try again whatever it was that made you realize
>> >> you need to defer.
>> >
>> > Nope, it doesn't work that way, sorry.
>>
>> Why? If I just postpone the entire driver load to an async worker and
>> then block if it's not there, that should work?
>
> Maybe, but the code patch from probe() in the driver core, and module
> loader, might be assuming that all is ok, only to have your async init
> later on realize that things are not ok.  How you could propagate that
> error back into the driver core might be difficult, if not impossible.

Hm, I hoped we've made progress on that entire idea of async driver
load, and userspace no longer depending upon accurate driver load
error codes from modprobe.

>> > Nice try, just unwind your initialization properly :)
>>
>> There's a slight pratical problem of this being hard to test. Sure in
>> theory it's easy, but given how often we bomb normal module unload
>> already (and that's something our CI tests) practice disagrees.
>
> probe()/disconnect()/probe() in the driver core as an option might be a
> fun way to stress this as others have pointed out here.

I didn't mean "hard to test" as in "I don't know how" - we have a
testcase in CI for this. More as in, among the bazillion bugs I'm
fighting, making driver load perfectly race-free in the face of load
failures (or eventual unloading) isn't a terrible high priority.
Especially since with an on-chip gpu it's pretty hard for normal users
to be able to even hit those paths ;-) If instead we'd be able to just
stall until the thing we need shows up, that would fix the problem
without sending the validation complexity through the roof.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Geert Uytterhoeven]

On Wed, Jul 27, 2016 at 8:03 PM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>> > > to help enable asynchronous probe, however for built-in devices this requires
>> > > very specific platform knowledge otherwise using async probe will blow up
>> > > your kernel -- if you get it right though, using async probe can help with
>
>> > I'm not sure what specific platform knowledge you're thinking of here?
>> > We have coverage for most things in the form of deferred probe (messy
>> > though it is).
>
>> Deferred probe is a complete a hack and sub-optimal. Being able to address
>
> Sure, I don't think anyone disagrees on that but it does mean we don't
> actually blow up easily like we used to - it's messy but it does get
> there safely.  I was specifically querying your statement that things
> would blow up.

Some drivers/subsystems don't support deferred probing yet. Such failures
usually don't blow up, but cause subtle malfunctioning.

In the specific case I encountered, an Ethernet phy couldn't get its interrupt
in of_mdiobus_register_phy(), as the (non-primary) irqchip hadn't been probed
yet. It didn't really blow up, though, as the phy driver fell back to polling.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Thu, Aug 04, 2016 at 02:37:36PM +0200, Geert Uytterhoeven wrote:
> On Wed, Jul 27, 2016 at 8:03 PM, Mark Brown <broonie@kernel.org> wrote:

> > Sure, I don't think anyone disagrees on that but it does mean we don't
> > actually blow up easily like we used to - it's messy but it does get
> > there safely.  I was specifically querying your statement that things
> > would blow up.

> Some drivers/subsystems don't support deferred probing yet. Such failures
> usually don't blow up, but cause subtle malfunctioning.

Sure, but at this point these are pretty much just bugs - it's one of
the most common error patterns I see in probe routines but it does tend
to go along with poor "let's just ignore that error, it can't have been
important" practices which ought to be fixed anyway.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Lars-Peter Clausen]

On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>> to help enable asynchronous probe, however for built-in devices this requires
>>> very specific platform knowledge otherwise using async probe will blow up
>>> your kernel -- if you get it right though, using async probe can help with
>>
>> I'm not sure what specific platform knowledge you're thinking of here?
>> We have coverage for most things in the form of deferred probe (messy
>> though it is).
> 
> Deferred probe is a complete a hack and sub-optimal.

I fully agree. In the past though there were a few good attempts of
providing something better than probe deferral, but those were always
quickly shutdown by GregKH for failing to prove that probe deferral
really is insufficient.

This probably an issue of presentation, but for future attempts it
should be kept in mind that hard numbers on why this is better greatly
improve the chance of it being accepted.

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

[Greg KH]

On Thu, Jul 28, 2016 at 11:49:49PM +0200, Lars-Peter Clausen wrote:
> On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote:
> > On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> >>> to help enable asynchronous probe, however for built-in devices this requires
> >>> very specific platform knowledge otherwise using async probe will blow up
> >>> your kernel -- if you get it right though, using async probe can help with
> >>
> >> I'm not sure what specific platform knowledge you're thinking of here?
> >> We have coverage for most things in the form of deferred probe (messy
> >> though it is).
> > 
> > Deferred probe is a complete a hack and sub-optimal.

It's the best hack that people have come up with to solve the problem so
far.

> I fully agree. In the past though there were a few good attempts of
> providing something better than probe deferral, but those were always
> quickly shutdown by GregKH for failing to prove that probe deferral
> really is insufficient.
> 
> This probably an issue of presentation, but for future attempts it
> should be kept in mind that hard numbers on why this is better greatly
> improve the chance of it being accepted.

If you don't have such numbers, why should I ever accept any changes?
You need to show a benefit of code, otherwise you are just pointless
churning things for no reason.

And also, don't try presenting patches that force every driver or
subsystem to be changed for no good reason, that's one reason I have
shot down patches in this area as well.

good luck!

greg k-h

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

[Hans Verkuil]

On 07/28/2016 11:49 PM, Lars-Peter Clausen wrote:
> On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote:
>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>> to help enable asynchronous probe, however for built-in devices this requires
>>>> very specific platform knowledge otherwise using async probe will blow up
>>>> your kernel -- if you get it right though, using async probe can help with
>>>
>>> I'm not sure what specific platform knowledge you're thinking of here?
>>> We have coverage for most things in the form of deferred probe (messy
>>> though it is).
>>
>> Deferred probe is a complete a hack and sub-optimal.
> 
> I fully agree. In the past though there were a few good attempts of
> providing something better than probe deferral, but those were always
> quickly shutdown by GregKH for failing to prove that probe deferral
> really is insufficient.
> 
> This probably an issue of presentation, but for future attempts it
> should be kept in mind that hard numbers on why this is better greatly
> improve the chance of it being accepted.

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?

Regards,

	Hans

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

[Lars-Peter Clausen]

On 07/29/2016 09:45 AM, Hans Verkuil wrote:
> 
> 
> On 07/28/2016 11:49 PM, Lars-Peter Clausen wrote:
>> On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote:
>>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
>>>>> to help enable asynchronous probe, however for built-in devices this requires
>>>>> very specific platform knowledge otherwise using async probe will blow up
>>>>> your kernel -- if you get it right though, using async probe can help with
>>>>
>>>> I'm not sure what specific platform knowledge you're thinking of here?
>>>> We have coverage for most things in the form of deferred probe (messy
>>>> though it is).
>>>
>>> Deferred probe is a complete a hack and sub-optimal.
>>
>> I fully agree. In the past though there were a few good attempts of
>> providing something better than probe deferral, but those were always
>> quickly shutdown by GregKH for failing to prove that probe deferral
>> really is insufficient.
>>
>> This probably an issue of presentation, but for future attempts it
>> should be kept in mind that hard numbers on why this is better greatly
>> improve the chance of it being accepted.
> 
> 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?

drivers/base/component.c is a subsystem independent approach to the same
problem and is used by a few subsystems (primarily DRM).

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

[Laurent Pinchart]

On Friday 29 Jul 2016 09:55:58 Lars-Peter Clausen wrote:
> On 07/29/2016 09:45 AM, Hans Verkuil wrote:
> > On 07/28/2016 11:49 PM, Lars-Peter Clausen wrote:
> >> On 07/27/2016 07:58 PM, Luis R. Rodriguez wrote:
> >>> On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> >>>>> to help enable asynchronous probe, however for built-in devices this
> >>>>> requires very specific platform knowledge otherwise using async probe
> >>>>> will blow up your kernel -- if you get it right though, using async
> >>>>> probe can help with>>>> 
> >>>> I'm not sure what specific platform knowledge you're thinking of here?
> >>>> We have coverage for most things in the form of deferred probe (messy
> >>>> though it is).
> >>> 
> >>> Deferred probe is a complete a hack and sub-optimal.
> >> 
> >> I fully agree. In the past though there were a few good attempts of
> >> providing something better than probe deferral, but those were always
> >> quickly shutdown by GregKH for failing to prove that probe deferral
> >> really is insufficient.
> >> 
> >> This probably an issue of presentation, but for future attempts it
> >> should be kept in mind that hard numbers on why this is better greatly
> >> improve the chance of it being accepted.
> > 
> > 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?
> 
> drivers/base/component.c is a subsystem independent approach to the same
> problem and is used by a few subsystems (primarily DRM).

If we decide to keep v4l2-async (which is an issue to be discussed on its 
own), we should probably replace it with the component framework. That might 
require modifications to the component framework that could affect other 
subsystems though, last time I looked v4l2-async had a few additional features 
(but that was a while ago).

-- 
Regards,

Laurent Pinchart

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

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

[Lars-Peter Clausen]

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

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

[Laurent Pinchart]

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

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

[Hans Verkuil]

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.

Regards,

	Hans

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

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

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

[Hans Verkuil]

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.

Regards,

	Hans

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

[Laurent Pinchart]

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

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

[Hans Verkuil]

On 08/01/2016 03:38 PM, Laurent Pinchart wrote:
> 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.

1) Wouldn't it make more sense to inform the CSI-2 receiver about this?

2) If it goes to the subdev driver anyway, then shouldn't that call the parent
   CSI-2 receiver driver and inform it that the device has been unplugged?

It really should be the bridge driver that unbinds any hardware that disappeared,
and the subdev shouldn't just disappear. The same happens with USB devices that
are unplugged: the USB bridge driver gets the disconnect and there it knows what
it should do to gracefully release everything.

Regards,

	Hans

> 
> [0] https://lwn.net/Articles/648400/ (slightly outdated, but the overall 
> architecture is there)
> 

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

[Laurent Pinchart]

Hi Hans,

On Monday 01 Aug 2016 15:51:03 Hans Verkuil wrote:
> On 08/01/2016 03:38 PM, Laurent Pinchart wrote:
> > 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.
> 
> 1) Wouldn't it make more sense to inform the CSI-2 receiver about this?

The CSI-2 receiver has no knowledge about modularity, it's a standard SoC 
CSI-2 receiver. A particular Ara device will use a particular SoC, but 
different devices can be based on different SoCs, with different CSI-2 
receivers. One of the design goals was to not have to teach every CSI-2 
receiver about Ara.

> 2) If it goes to the subdev driver anyway, then shouldn't that call the
> parent CSI-2 receiver driver and inform it that the device has been
> unplugged?

So far V4L2 has always assumed that the driver handling the CSI-2 receiver is 
the master/bridge/host driver (I still don't like the name bridge in that 
context, but that's a separate story). This assumption isn't true with Ara 
anymore, the CSI-2 receiver (and the other video blocks downstream, if any) 
are resources the same way that the sensor is a resource. There is a driver 
that can act as a master in the design, but it's not the CSI-2 receiver 
driver.

> It really should be the bridge driver that unbinds any hardware that
> disappeared, and the subdev shouldn't just disappear. The same happens with
> USB devices that are unplugged: the USB bridge driver gets the disconnect
> and there it knows what it should do to gracefully release everything.

It's easier in that case as the driver that receives the disconnection even is 
also the one that has complete view over the device.

> > [0] https://lwn.net/Articles/648400/ (slightly outdated, but the overall
> > architecture is there)

-- 
Regards,

Laurent Pinchart

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

[Lars-Peter Clausen]

On 08/01/2016 03:21 PM, 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.

suppress_bind_attrs is the lazy solution and as you pointed out does not
work too well for all cases.

E.g. devicetree overlays is one case where devices, that are normally
static, can be removed at runtime. I'm not sure we can ensure that the
device for the complex/fabric is removed before the devices of the
individual components are removed. We certainly don't do at the moment. So
if you have a audio or video system on a cape and you want to remove that
cape at runtime there is a good chance that things will crash.

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

[Mauro Carvalho Chehab]

Em Mon, 1 Aug 2016 15:33:22 +0200
Lars-Peter Clausen <lars@metafoo.de> escreveu:

> On 08/01/2016 03:21 PM, 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.  
> 
> suppress_bind_attrs is the lazy solution and as you pointed out does not
> work too well for all cases.

Agreed. 

What we really need is a kind of "usage count" behavior to suppress
unbinds, e. g. a device driver can be unbound only if any other driver
using resources on it gets unbind first.

That will solve most of unbind issues at the media subsystem.

-- 
Thanks,
Mauro

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

[Lars-Peter Clausen]

On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 1 Aug 2016 15:33:22 +0200
> Lars-Peter Clausen <lars@metafoo.de> escreveu:
> 
>> On 08/01/2016 03:21 PM, 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.  
>>
>> suppress_bind_attrs is the lazy solution and as you pointed out does not
>> work too well for all cases.
> 
> Agreed. 
> 
> What we really need is a kind of "usage count" behavior to suppress
> unbinds, e. g. a device driver can be unbound only if any other driver
> using resources on it gets unbind first.
> 
> That will solve most of unbind issues at the media subsystem.

While that is a good idea for certain use cases, it still does not handle
the case of hot-unplug where we can't delay unbind since the physical device
is already gone.

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

[Andrzej Hajda]

On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 1 Aug 2016 15:33:22 +0200
> Lars-Peter Clausen <lars@metafoo.de> escreveu:
>
>> On 08/01/2016 03:21 PM, 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.  
>> suppress_bind_attrs is the lazy solution and as you pointed out does not
>> work too well for all cases.
> Agreed. 
>
> What we really need is a kind of "usage count" behavior to suppress
> unbinds, e. g. a device driver can be unbound only if any other driver
> using resources on it gets unbind first.
>
> That will solve most of unbind issues at the media subsystem.

When I was investigating issues with unbind sysfs attribute I have found
claim by Greg KH that unbind should be rather unavoidable, like in case
of hw removal - kernel is not able to prevent users from removing usb
device, even if it is in use.

Assuming the claim is still valid, the only solution I see are callbacks
notifying resource consumers about removal of the resources.

Regards
Andrzej

>

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

[Lars-Peter Clausen]

On 08/01/2016 04:44 PM, Andrzej Hajda wrote:
> On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
>> Em Mon, 1 Aug 2016 15:33:22 +0200
>> Lars-Peter Clausen <lars@metafoo.de> escreveu:
>>
>>> On 08/01/2016 03:21 PM, 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.  
>>> suppress_bind_attrs is the lazy solution and as you pointed out does not
>>> work too well for all cases.
>> Agreed. 
>>
>> What we really need is a kind of "usage count" behavior to suppress
>> unbinds, e. g. a device driver can be unbound only if any other driver
>> using resources on it gets unbind first.
>>
>> That will solve most of unbind issues at the media subsystem.
> 
> When I was investigating issues with unbind sysfs attribute I have found
> claim by Greg KH that unbind should be rather unavoidable, like in case
> of hw removal - kernel is not able to prevent users from removing usb
> device, even if it is in use.
> 
> Assuming the claim is still valid, the only solution I see are callbacks
> notifying resource consumers about removal of the resources.

There are multiple options.

One option, which I think is currently the most used option in the kernel,
is to unregister the resource when the provider is removed, but keep the
resource object alive as long as there are users. Any further operation on
such object will fail with an error. This works to the point where things
don't crash, but it wont function in any meaningful way. There is no way to
automatically recover if the resource reappears.

Other options are as you pointed out notifier callbacks that allows the
resource use to be aware that a resource has disappeared and it might adjust
and continue to function with limited functionality.

Another option is to teach the device core about critical resource
dependencies so that a consumer is automatically unbound by the core if any
of its resource dependencies are unregistered. The device can also
automatically be re-bound once the critical resources re-appear.

The most likely solution is probably a mixture of all of them.

- Lars

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Mon, Aug 01, 2016 at 04:54:46PM +0200, Lars-Peter Clausen wrote:

> Another option is to teach the device core about critical resource
> dependencies so that a consumer is automatically unbound by the core if any
> of its resource dependencies are unregistered. The device can also
> automatically be re-bound once the critical resources re-appear.

This one is what ASoC really wants to be able to do with the current
model it has - unbind the card and go back to waiting for the components
to reappear.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Andrzej Hajda]

On 08/01/2016 04:54 PM, Lars-Peter Clausen wrote:
> On 08/01/2016 04:44 PM, Andrzej Hajda wrote:
>> On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
>>> Em Mon, 1 Aug 2016 15:33:22 +0200
>>> Lars-Peter Clausen <lars@metafoo.de> escreveu:
>>>
>>>> On 08/01/2016 03:21 PM, 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.  
>>>> suppress_bind_attrs is the lazy solution and as you pointed out does not
>>>> work too well for all cases.
>>> Agreed. 
>>>
>>> What we really need is a kind of "usage count" behavior to suppress
>>> unbinds, e. g. a device driver can be unbound only if any other driver
>>> using resources on it gets unbind first.
>>>
>>> That will solve most of unbind issues at the media subsystem.
>> When I was investigating issues with unbind sysfs attribute I have found
>> claim by Greg KH that unbind should be rather unavoidable, like in case
>> of hw removal - kernel is not able to prevent users from removing usb
>> device, even if it is in use.
>>
>> Assuming the claim is still valid, the only solution I see are callbacks
>> notifying resource consumers about removal of the resources.
> There are multiple options.
>
> One option, which I think is currently the most used option in the kernel,
> is to unregister the resource when the provider is removed, but keep the
> resource object alive as long as there are users. Any further operation on
> such object will fail with an error. This works to the point where things
> don't crash, but it wont function in any meaningful way. There is no way to
> automatically recover if the resource reappears.

For me it is not a real solution, it is just dirty workaround to just avoid
invalid pointers. It 'works' only because unbinding is rarely used.
For example, how the device is supposed to work if its regulator or clock
disappeared?

>
> Other options are as you pointed out notifier callbacks that allows the
> resource use to be aware that a resource has disappeared and it might adjust
> and continue to function with limited functionality.
>
> Another option is to teach the device core about critical resource
> dependencies so that a consumer is automatically unbound by the core if any
> of its resource dependencies are unregistered. The device can also
> automatically be re-bound once the critical resources re-appear.

That would be OK only for critical resources.

>
> The most likely solution is probably a mixture of all of them.

If we implement callbacks, we do not need other two 'options'.

Regards
Andrzej

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

[Lars-Peter Clausen]

On 08/01/2016 05:34 PM, Andrzej Hajda wrote:
> On 08/01/2016 04:54 PM, Lars-Peter Clausen wrote:
>> On 08/01/2016 04:44 PM, Andrzej Hajda wrote:
>>> On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
>>>> Em Mon, 1 Aug 2016 15:33:22 +0200
>>>> Lars-Peter Clausen <lars@metafoo.de> escreveu:
>>>>
>>>>> On 08/01/2016 03:21 PM, 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.  
>>>>> suppress_bind_attrs is the lazy solution and as you pointed out does not
>>>>> work too well for all cases.
>>>> Agreed. 
>>>>
>>>> What we really need is a kind of "usage count" behavior to suppress
>>>> unbinds, e. g. a device driver can be unbound only if any other driver
>>>> using resources on it gets unbind first.
>>>>
>>>> That will solve most of unbind issues at the media subsystem.
>>> When I was investigating issues with unbind sysfs attribute I have found
>>> claim by Greg KH that unbind should be rather unavoidable, like in case
>>> of hw removal - kernel is not able to prevent users from removing usb
>>> device, even if it is in use.
>>>
>>> Assuming the claim is still valid, the only solution I see are callbacks
>>> notifying resource consumers about removal of the resources.
>> There are multiple options.
>>
>> One option, which I think is currently the most used option in the kernel,
>> is to unregister the resource when the provider is removed, but keep the
>> resource object alive as long as there are users. Any further operation on
>> such object will fail with an error. This works to the point where things
>> don't crash, but it wont function in any meaningful way. There is no way to
>> automatically recover if the resource reappears.
> 
> For me it is not a real solution, it is just dirty workaround to just avoid
> invalid pointers. It 'works' only because unbinding is rarely used.
> For example, how the device is supposed to work if its regulator or clock
> disappeared?
> 
>>
>> Other options are as you pointed out notifier callbacks that allows the
>> resource use to be aware that a resource has disappeared and it might adjust
>> and continue to function with limited functionality.
>>
>> Another option is to teach the device core about critical resource
>> dependencies so that a consumer is automatically unbound by the core if any
>> of its resource dependencies are unregistered. The device can also
>> automatically be re-bound once the critical resources re-appear.
> 
> That would be OK only for critical resources.
> 
>>
>> The most likely solution is probably a mixture of all of them.
> 
> If we implement callbacks, we do not need other two 'options'.

Having to manually register callbacks for every resource in every driver
will result in a massive amount of boilerplate code. I'd rather avoid that.
In addition to that doing resource tracking at the framework level will help
with probe ordering.

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

[Andrzej Hajda]

On 08/01/2016 05:43 PM, Lars-Peter Clausen wrote:
> On 08/01/2016 05:34 PM, Andrzej Hajda wrote:
>> On 08/01/2016 04:54 PM, Lars-Peter Clausen wrote:
>>> On 08/01/2016 04:44 PM, Andrzej Hajda wrote:
>>>> On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
>>>>> Em Mon, 1 Aug 2016 15:33:22 +0200
>>>>> Lars-Peter Clausen <lars@metafoo.de> escreveu:
>>>>>
>>>>>> On 08/01/2016 03:21 PM, 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.  
>>>>>> suppress_bind_attrs is the lazy solution and as you pointed out does not
>>>>>> work too well for all cases.
>>>>> Agreed. 
>>>>>
>>>>> What we really need is a kind of "usage count" behavior to suppress
>>>>> unbinds, e. g. a device driver can be unbound only if any other driver
>>>>> using resources on it gets unbind first.
>>>>>
>>>>> That will solve most of unbind issues at the media subsystem.
>>>> When I was investigating issues with unbind sysfs attribute I have found
>>>> claim by Greg KH that unbind should be rather unavoidable, like in case
>>>> of hw removal - kernel is not able to prevent users from removing usb
>>>> device, even if it is in use.
>>>>
>>>> Assuming the claim is still valid, the only solution I see are callbacks
>>>> notifying resource consumers about removal of the resources.
>>> There are multiple options.
>>>
>>> One option, which I think is currently the most used option in the kernel,
>>> is to unregister the resource when the provider is removed, but keep the
>>> resource object alive as long as there are users. Any further operation on
>>> such object will fail with an error. This works to the point where things
>>> don't crash, but it wont function in any meaningful way. There is no way to
>>> automatically recover if the resource reappears.
>> For me it is not a real solution, it is just dirty workaround to just avoid
>> invalid pointers. It 'works' only because unbinding is rarely used.
>> For example, how the device is supposed to work if its regulator or clock
>> disappeared?
>>
>>> Other options are as you pointed out notifier callbacks that allows the
>>> resource use to be aware that a resource has disappeared and it might adjust
>>> and continue to function with limited functionality.
>>>
>>> Another option is to teach the device core about critical resource
>>> dependencies so that a consumer is automatically unbound by the core if any
>>> of its resource dependencies are unregistered. The device can also
>>> automatically be re-bound once the critical resources re-appear.
>> That would be OK only for critical resources.
>>
>>> The most likely solution is probably a mixture of all of them.
>> If we implement callbacks, we do not need other two 'options'.
> Having to manually register callbacks for every resource in every driver
> will result in a massive amount of boilerplate code. I'd rather avoid that.

You can use helper to monitor multiple resources in one callback - it
should not increase the code significantly. As I wrote in other e-mail I
send already RFC in which the code in the driver was even shorter
than before. See [1].

[1]: http://www.spinics.net/lists/dri-devel/msg73500.html
> In addition to that doing resource tracking at the framework level will help
> with probe ordering.
>
>

Could you elaborate more?


Regards
Andrzej

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

On Mon, Aug 01, 2016 at 06:18:55PM +0200, Andrzej Hajda wrote:
> On 08/01/2016 05:43 PM, Lars-Peter Clausen wrote:
> > On 08/01/2016 05:34 PM, Andrzej Hajda wrote:
> >> On 08/01/2016 04:54 PM, Lars-Peter Clausen wrote:

> >>> One option, which I think is currently the most used option in the kernel,
> >>> is to unregister the resource when the provider is removed, but keep the
> >>> resource object alive as long as there are users. Any further operation on
> >>> such object will fail with an error. This works to the point where things
> >>> don't crash, but it wont function in any meaningful way. There is no way to
> >>> automatically recover if the resource reappears.

> >> For me it is not a real solution, it is just dirty workaround to just avoid
> >> invalid pointers. It 'works' only because unbinding is rarely used.
> >> For example, how the device is supposed to work if its regulator or clock
> >> disappeared?

The device isn't supposed to work, just not crash - this is mainly used
for things that are exposed to userspace where we need to keep returning
errors to userspace until they free their reference.  I'm not sure we
can get out of that one.

> >>> Other options are as you pointed out notifier callbacks that allows the
> >>> resource use to be aware that a resource has disappeared and it might adjust
> >>> and continue to function with limited functionality.

> >>> Another option is to teach the device core about critical resource
> >>> dependencies so that a consumer is automatically unbound by the core if any
> >>> of its resource dependencies are unregistered. The device can also
> >>> automatically be re-bound once the critical resources re-appear.

> >>> The most likely solution is probably a mixture of all of them.

> >> If we implement callbacks, we do not need other two 'options'.

> > Having to manually register callbacks for every resource in every driver
> > will result in a massive amount of boilerplate code. I'd rather avoid that.

> You can use helper to monitor multiple resources in one callback - it
> should not increase the code significantly. As I wrote in other e-mail I
> send already RFC in which the code in the driver was even shorter
> than before. See [1].

I think a lot of the difference between the two cases above is just
about where the default callback comes from and how it's presented to
users - having the driver core able to handle critical resources doesn't
seem hugely different to providing a list of resources and offsets into
driver_data in the struct driver and having a default callback that
calls probe() and remove() with an already allocated and initialized
driver_data.  That'd definitely cut down a lot on bolilerplate code, but
there's problems with the driver trying to clean up when removing (eg,
disabling things) when some of the resources it used are in the process
of being removed themselves.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Lars-Peter Clausen]

[-- Attachment #1: Type: text/plain, Size: 4712 bytes --]

On 08/01/2016 07:06 PM, Mark Brown wrote:
> On Mon, Aug 01, 2016 at 06:18:55PM +0200, Andrzej Hajda wrote:
>> On 08/01/2016 05:43 PM, Lars-Peter Clausen wrote:
>>> On 08/01/2016 05:34 PM, Andrzej Hajda wrote:
>>>> On 08/01/2016 04:54 PM, Lars-Peter Clausen wrote:
> 
>>>>> One option, which I think is currently the most used option in the kernel,
>>>>> is to unregister the resource when the provider is removed, but keep the
>>>>> resource object alive as long as there are users. Any further operation on
>>>>> such object will fail with an error. This works to the point where things
>>>>> don't crash, but it wont function in any meaningful way. There is no way to
>>>>> automatically recover if the resource reappears.
> 
>>>> For me it is not a real solution, it is just dirty workaround to just avoid
>>>> invalid pointers. It 'works' only because unbinding is rarely used.
>>>> For example, how the device is supposed to work if its regulator or clock
>>>> disappeared?
> 
> The device isn't supposed to work, just not crash - this is mainly used
> for things that are exposed to userspace where we need to keep returning
> errors to userspace until they free their reference.  I'm not sure we
> can get out of that one.
> 
>>>>> Other options are as you pointed out notifier callbacks that allows the
>>>>> resource use to be aware that a resource has disappeared and it might adjust
>>>>> and continue to function with limited functionality.
> 
>>>>> Another option is to teach the device core about critical resource
>>>>> dependencies so that a consumer is automatically unbound by the core if any
>>>>> of its resource dependencies are unregistered. The device can also
>>>>> automatically be re-bound once the critical resources re-appear.
> 
>>>>> The most likely solution is probably a mixture of all of them.
> 
>>>> If we implement callbacks, we do not need other two 'options'.
> 
>>> Having to manually register callbacks for every resource in every driver
>>> will result in a massive amount of boilerplate code. I'd rather avoid that.
> 
>> You can use helper to monitor multiple resources in one callback - it
>> should not increase the code significantly. As I wrote in other e-mail I
>> send already RFC in which the code in the driver was even shorter
>> than before. See [1].
> 
> I think a lot of the difference between the two cases above is just
> about where the default callback comes from and how it's presented to
> users - having the driver core able to handle critical resources doesn't
> seem hugely different to providing a list of resources and offsets into
> driver_data in the struct driver and having a default callback that
> calls probe() and remove() with an already allocated and initialized
> driver_data.  That'd definitely cut down a lot on bolilerplate code, but
> there's problems with the driver trying to clean up when removing (eg,
> disabling things) when some of the resources it used are in the process
> of being removed themselves.

Yes, when I read callbacks I though about having to have individual
callbacks for each resources and the driver needs to manually track which
are already available. Whereas this is has the tracking implemented in a
framework which is closer to what I meant by the core tracking option. In
the end probe() is also just a callback.

The question is just about what level of integration into the device driver
core do we want.

What restrack effectively does is split to split probe() into a top and a
bottom half. The top half establishes the dependencies and the bottom half
runs once all the dependencies are met. In this particular implementation th
bottom half runs outside the scope of the device driver core. Which means
the device driver core assumes that the device has successfully probed once
the top half (the real probe() callback) finishes.

Another place where ordering is important is suspend and resume. We want to
avoid suspending a resource provider before the consumer. The default
suspend/resume order that is established by the device driver core depends
on the probe order of the devices. Suspend runs in the opposite oder, resume
in the same. Together with EPROBE_DEFER this makes sure that a consumer is
suspended before any providers it might depend on. Not waiting for the
resources to become available before probe() succeeds will break this. So
this is something that needs to be addressed by either by integrating pm
support directly in restrack or extending the device driver core to natively
support two stage probe with the device only being considered fully probed
once the second stage has completed.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Andrzej Hajda]

On 08/01/2016 08:21 PM, Lars-Peter Clausen wrote:
> On 08/01/2016 07:06 PM, Mark Brown wrote:
>> On Mon, Aug 01, 2016 at 06:18:55PM +0200, Andrzej Hajda wrote:
>>> On 08/01/2016 05:43 PM, Lars-Peter Clausen wrote:
>>>> On 08/01/2016 05:34 PM, Andrzej Hajda wrote:
>>>>> On 08/01/2016 04:54 PM, Lars-Peter Clausen wrote:
>>>>>> One option, which I think is currently the most used option in the kernel,
>>>>>> is to unregister the resource when the provider is removed, but keep the
>>>>>> resource object alive as long as there are users. Any further operation on
>>>>>> such object will fail with an error. This works to the point where things
>>>>>> don't crash, but it wont function in any meaningful way. There is no way to
>>>>>> automatically recover if the resource reappears.
>>>>> For me it is not a real solution, it is just dirty workaround to just avoid
>>>>> invalid pointers. It 'works' only because unbinding is rarely used.
>>>>> For example, how the device is supposed to work if its regulator or clock
>>>>> disappeared?
>> The device isn't supposed to work, just not crash - this is mainly used
>> for things that are exposed to userspace where we need to keep returning
>> errors to userspace until they free their reference.  I'm not sure we
>> can get out of that one.
>>
>>>>>> Other options are as you pointed out notifier callbacks that allows the
>>>>>> resource use to be aware that a resource has disappeared and it might adjust
>>>>>> and continue to function with limited functionality.
>>>>>> Another option is to teach the device core about critical resource
>>>>>> dependencies so that a consumer is automatically unbound by the core if any
>>>>>> of its resource dependencies are unregistered. The device can also
>>>>>> automatically be re-bound once the critical resources re-appear.
>>>>>> The most likely solution is probably a mixture of all of them.
>>>>> If we implement callbacks, we do not need other two 'options'.
>>>> Having to manually register callbacks for every resource in every driver
>>>> will result in a massive amount of boilerplate code. I'd rather avoid that.
>>> You can use helper to monitor multiple resources in one callback - it
>>> should not increase the code significantly. As I wrote in other e-mail I
>>> send already RFC in which the code in the driver was even shorter
>>> than before. See [1].
>> I think a lot of the difference between the two cases above is just
>> about where the default callback comes from and how it's presented to
>> users - having the driver core able to handle critical resources doesn't
>> seem hugely different to providing a list of resources and offsets into
>> driver_data in the struct driver and having a default callback that
>> calls probe() and remove() with an already allocated and initialized
>> driver_data.  That'd definitely cut down a lot on bolilerplate code, but
>> there's problems with the driver trying to clean up when removing (eg,
>> disabling things) when some of the resources it used are in the process
>> of being removed themselves.
> Yes, when I read callbacks I though about having to have individual
> callbacks for each resources and the driver needs to manually track which
> are already available. Whereas this is has the tracking implemented in a
> framework which is closer to what I meant by the core tracking option. In
> the end probe() is also just a callback.
>
> The question is just about what level of integration into the device driver
> core do we want.
>
> What restrack effectively does is split to split probe() into a top and a
> bottom half. The top half establishes the dependencies and the bottom half
> runs once all the dependencies are met. In this particular implementation th
> bottom half runs outside the scope of the device driver core. Which means
> the device driver core assumes that the device has successfully probed once
> the top half (the real probe() callback) finishes.
>
> Another place where ordering is important is suspend and resume. We want to
> avoid suspending a resource provider before the consumer. The default
> suspend/resume order that is established by the device driver core depends
> on the probe order of the devices. Suspend runs in the opposite oder, resume
> in the same. Together with EPROBE_DEFER this makes sure that a consumer is
> suspended before any providers it might depend on. Not waiting for the
> resources to become available before probe() succeeds will break this. So
> this is something that needs to be addressed by either by integrating pm
> support directly in restrack or extending the device driver core to natively
> support two stage probe with the device only being considered fully probed
> once the second stage has completed.
>

I guess integrating suspend/resume into restrack should be quite
straightforward.
Just another callback, or the same with some parameter, called before
entering suspend and after resuming of resource provider.

Regards
Andrzej

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

[Andrzej Hajda]

On 08/01/2016 07:06 PM, Mark Brown wrote:
> On Mon, Aug 01, 2016 at 06:18:55PM +0200, Andrzej Hajda wrote:
>> On 08/01/2016 05:43 PM, Lars-Peter Clausen wrote:
>>> On 08/01/2016 05:34 PM, Andrzej Hajda wrote:
>>>> On 08/01/2016 04:54 PM, Lars-Peter Clausen wrote:
>>>>> One option, which I think is currently the most used option in the kernel,
>>>>> is to unregister the resource when the provider is removed, but keep the
>>>>> resource object alive as long as there are users. Any further operation on
>>>>> such object will fail with an error. This works to the point where things
>>>>> don't crash, but it wont function in any meaningful way. There is no way to
>>>>> automatically recover if the resource reappears.
>>>> For me it is not a real solution, it is just dirty workaround to just avoid
>>>> invalid pointers. It 'works' only because unbinding is rarely used.
>>>> For example, how the device is supposed to work if its regulator or clock
>>>> disappeared?
> The device isn't supposed to work, just not crash - this is mainly used
> for things that are exposed to userspace where we need to keep returning
> errors to userspace until they free their reference.  I'm not sure we
> can get out of that one.

Could you give some examples? I suppose this is slightly different issue
than unbinding provider of working resource.

>
>>>>> Other options are as you pointed out notifier callbacks that allows the
>>>>> resource use to be aware that a resource has disappeared and it might adjust
>>>>> and continue to function with limited functionality.
>>>>> Another option is to teach the device core about critical resource
>>>>> dependencies so that a consumer is automatically unbound by the core if any
>>>>> of its resource dependencies are unregistered. The device can also
>>>>> automatically be re-bound once the critical resources re-appear.
>>>>> The most likely solution is probably a mixture of all of them.
>>>> If we implement callbacks, we do not need other two 'options'.
>>> Having to manually register callbacks for every resource in every driver
>>> will result in a massive amount of boilerplate code. I'd rather avoid that.
>> You can use helper to monitor multiple resources in one callback - it
>> should not increase the code significantly. As I wrote in other e-mail I
>> send already RFC in which the code in the driver was even shorter
>> than before. See [1].
> I think a lot of the difference between the two cases above is just
> about where the default callback comes from and how it's presented to
> users - having the driver core able to handle critical resources doesn't
> seem hugely different to providing a list of resources and offsets into
> driver_data in the struct driver and having a default callback that
> calls probe() and remove() with an already allocated and initialized
> driver_data.  That'd definitely cut down a lot on bolilerplate code,

If you want to driver core handle critical resources you should teach
it how to get description of these resources (DT/ACPI properties, platform
data in case of older systems, ...anything else?) and to distinguish
between critical and optional resources (this info is not available in DT).
If you leave this task to the device driver it has already this knowledge,
so you just need to create some helpers.

> but
> there's problems with the driver trying to clean up when removing (eg,
> disabling things) when some of the resources it used are in the process
> of being removed themselves.
Serialization of this process should solve it (as I proposed in RFC),
ie. all tasks below:
- registering callback monitoring given resource,
- unregistering the callback,
- registering the resource,
- unregistering the resource,
should be serialized.
There is still a question about granulation of serialization:
it could be done at framework level but it could be done
also per resource.

Regards
Andrzej

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

On Mon, Aug 01, 2016 at 08:33:55PM +0200, Andrzej Hajda wrote:
> On 08/01/2016 07:06 PM, Mark Brown wrote:

> > The device isn't supposed to work, just not crash - this is mainly used
> > for things that are exposed to userspace where we need to keep returning
> > errors to userspace until they free their reference.  I'm not sure we
> > can get out of that one.

> Could you give some examples? I suppose this is slightly different issue
> than unbinding provider of working resource.

Anything where you have a resource open from userspace pretty much - a
file stored on media that got removed for example.  The struct
representing the open file handle needs to be valid as long as the file
is open.

> > I think a lot of the difference between the two cases above is just
> > about where the default callback comes from and how it's presented to
> > users - having the driver core able to handle critical resources doesn't
> > seem hugely different to providing a list of resources and offsets into
> > driver_data in the struct driver and having a default callback that
> > calls probe() and remove() with an already allocated and initialized
> > driver_data.  That'd definitely cut down a lot on bolilerplate code,

> If you want to driver core handle critical resources you should teach
> it how to get description of these resources (DT/ACPI properties, platform
> data in case of older systems, ...anything else?) and to distinguish
> between critical and optional resources (this info is not available in DT).
> If you leave this task to the device driver it has already this knowledge,
> so you just need to create some helpers.

You don't need to do one or the other, you can do both (though as Lars
pointed out if there's things the core doesn't know about that means it
can do less, like with suspend/resume).

> > but
> > there's problems with the driver trying to clean up when removing (eg,
> > disabling things) when some of the resources it used are in the process
> > of being removed themselves.

> Serialization of this process should solve it (as I proposed in RFC),
> ie. all tasks below:
> - registering callback monitoring given resource,
> - unregistering the callback,
> - registering the resource,
> - unregistering the resource,
> should be serialized.

> There is still a question about granulation of serialization:
> it could be done at framework level but it could be done
> also per resource.

Serialization doesn't help here.  If a resource is unregistering and a
callback is called it's likely that the callback will want to do
something like disable the thing that's trying to free itself which is
potentially messy.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Andrzej Hajda]

On 08/01/2016 08:48 PM, Mark Brown wrote:
> On Mon, Aug 01, 2016 at 08:33:55PM +0200, Andrzej Hajda wrote:
>> On 08/01/2016 07:06 PM, Mark Brown wrote:
>>> The device isn't supposed to work, just not crash - this is mainly used
>>> for things that are exposed to userspace where we need to keep returning
>>> errors to userspace until they free their reference.  I'm not sure we
>>> can get out of that one.
>> Could you give some examples? I suppose this is slightly different issue
>> than unbinding provider of working resource.
> Anything where you have a resource open from userspace pretty much - a
> file stored on media that got removed for example.  The struct
> representing the open file handle needs to be valid as long as the file
> is open.

It seems to be not related directly to the subject - file handle is
something
created/controlled by userspace, as well as it's life-time.
I see no real device dependency here. I guess Lars though rather about
ghost resources like in clock framework, when after removing provider,
clock ops are replaced by phony ops.

>
>>> I think a lot of the difference between the two cases above is just
>>> about where the default callback comes from and how it's presented to
>>> users - having the driver core able to handle critical resources doesn't
>>> seem hugely different to providing a list of resources and offsets into
>>> driver_data in the struct driver and having a default callback that
>>> calls probe() and remove() with an already allocated and initialized
>>> driver_data.  That'd definitely cut down a lot on bolilerplate code,
>> If you want to driver core handle critical resources you should teach
>> it how to get description of these resources (DT/ACPI properties, platform
>> data in case of older systems, ...anything else?) and to distinguish
>> between critical and optional resources (this info is not available in DT).
>> If you leave this task to the device driver it has already this knowledge,
>> so you just need to create some helpers.
> You don't need to do one or the other, you can do both (though as Lars
> pointed out if there's things the core doesn't know about that means it
> can do less, like with suspend/resume).
>
>>> but
>>> there's problems with the driver trying to clean up when removing (eg,
>>> disabling things) when some of the resources it used are in the process
>>> of being removed themselves.
>> Serialization of this process should solve it (as I proposed in RFC),
>> ie. all tasks below:
>> - registering callback monitoring given resource,
>> - unregistering the callback,
>> - registering the resource,
>> - unregistering the resource,
>> should be serialized.
>> There is still a question about granulation of serialization:
>> it could be done at framework level but it could be done
>> also per resource.
> Serialization doesn't help here.  If a resource is unregistering and a
> callback is called it's likely that the callback will want to do
> something like disable the thing that's trying to free itself which is
> potentially messy.

No, callback is called always when resource is available:
- just after registering resource,
- just before unregistering resource,
so consumer can do anything with the resource in the callback.

And due to serialization resource removal cannot start until callback
finishes.

Regards
Andrzej

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

[Lars-Peter Clausen]

On 08/01/2016 09:42 PM, Andrzej Hajda wrote:
> On 08/01/2016 08:48 PM, Mark Brown wrote:
>> On Mon, Aug 01, 2016 at 08:33:55PM +0200, Andrzej Hajda wrote:
>>> On 08/01/2016 07:06 PM, Mark Brown wrote:
>>>> The device isn't supposed to work, just not crash - this is mainly used
>>>> for things that are exposed to userspace where we need to keep returning
>>>> errors to userspace until they free their reference.  I'm not sure we
>>>> can get out of that one.
>>> Could you give some examples? I suppose this is slightly different issue
>>> than unbinding provider of working resource.
>> Anything where you have a resource open from userspace pretty much - a
>> file stored on media that got removed for example.  The struct
>> representing the open file handle needs to be valid as long as the file
>> is open.
> 
> It seems to be not related directly to the subject - file handle is
> something
> created/controlled by userspace, as well as it's life-time.
> I see no real device dependency here. I guess Lars though rather about
> ghost resources like in clock framework, when after removing provider,
> clock ops are replaced by phony ops.

Both really. In the end they both boil down to the same problem. You have
provider and a consumer and the provider disappears while the consumer still
uses it. In this case the kernel is the provider and userspace the consumer.

We should try to address both issue within the same framework, especially
since there is a dependency chain. Lets say a audio device uses a clock and
the clock becomes unavailable this means the the audio device is no longer
usable for a userspace application.

When I meant there are multiple options I did not mean that we must choose
one of these options and always use it and never use the others. A solution
will most likely involve multiple of them at different levels in the stack.

There have been attempts or ideas in the past to push the handling of
keeping the file descriptor alive while having operations return errors
directly into the fs layer so that individual frameworks don't have to deal
with it. See https://lwn.net/Articles/546537/

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

[Takashi Iwai]

On Mon, 01 Aug 2016 22:05:49 +0200,
Lars-Peter Clausen wrote:
> 
> On 08/01/2016 09:42 PM, Andrzej Hajda wrote:
> > On 08/01/2016 08:48 PM, Mark Brown wrote:
> >> On Mon, Aug 01, 2016 at 08:33:55PM +0200, Andrzej Hajda wrote:
> >>> On 08/01/2016 07:06 PM, Mark Brown wrote:
> >>>> The device isn't supposed to work, just not crash - this is mainly used
> >>>> for things that are exposed to userspace where we need to keep returning
> >>>> errors to userspace until they free their reference.  I'm not sure we
> >>>> can get out of that one.
> >>> Could you give some examples? I suppose this is slightly different issue
> >>> than unbinding provider of working resource.
> >> Anything where you have a resource open from userspace pretty much - a
> >> file stored on media that got removed for example.  The struct
> >> representing the open file handle needs to be valid as long as the file
> >> is open.
> > 
> > It seems to be not related directly to the subject - file handle is
> > something
> > created/controlled by userspace, as well as it's life-time.
> > I see no real device dependency here. I guess Lars though rather about
> > ghost resources like in clock framework, when after removing provider,
> > clock ops are replaced by phony ops.
> 
> Both really. In the end they both boil down to the same problem. You have
> provider and a consumer and the provider disappears while the consumer still
> uses it. In this case the kernel is the provider and userspace the consumer.
> 
> We should try to address both issue within the same framework, especially
> since there is a dependency chain. Lets say a audio device uses a clock and
> the clock becomes unavailable this means the the audio device is no longer
> usable for a userspace application.
> 
> When I meant there are multiple options I did not mean that we must choose
> one of these options and always use it and never use the others. A solution
> will most likely involve multiple of them at different levels in the stack.
> 
> There have been attempts or ideas in the past to push the handling of
> keeping the file descriptor alive while having operations return errors
> directly into the fs layer so that individual frameworks don't have to deal
> with it. See https://lwn.net/Articles/546537/

FWIW, ALSA core code does a similar workaround already, and it's
proven to work fine for over a decade.


Takashi

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

[Laurent Pinchart]

Hi Lars,

On Monday 01 Aug 2016 16:54:46 Lars-Peter Clausen wrote:
> On 08/01/2016 04:44 PM, Andrzej Hajda wrote:
> > On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
> >> Em Mon, 1 Aug 2016 15:33:22 +0200 Lars-Peter Clausen escreveu:
> >>> On 08/01/2016 03:21 PM, 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.
> >>> 
> >>> suppress_bind_attrs is the lazy solution and as you pointed out does not
> >>> work too well for all cases.
> >> 
> >> Agreed.
> >> 
> >> What we really need is a kind of "usage count" behavior to suppress
> >> unbinds, e. g. a device driver can be unbound only if any other driver
> >> using resources on it gets unbind first.
> >> 
> >> That will solve most of unbind issues at the media subsystem.
> > 
> > When I was investigating issues with unbind sysfs attribute I have found
> > claim by Greg KH that unbind should be rather unavoidable, like in case
> > of hw removal - kernel is not able to prevent users from removing usb
> > device, even if it is in use.
> > 
> > Assuming the claim is still valid, the only solution I see are callbacks
> > notifying resource consumers about removal of the resources.
> 
> There are multiple options.
> 
> One option, which I think is currently the most used option in the kernel,
> is to unregister the resource when the provider is removed, but keep the
> resource object alive as long as there are users. Any further operation on
> such object will fail with an error. This works to the point where things
> don't crash, but it wont function in any meaningful way. There is no way to
> automatically recover if the resource reappears.

As Mark mentioned, I don't think we can do anything else than this when it 
comes to userspace-facing interfaces. We need to keep objects alive until they 
can't be accessed by userspace anymore, otherwise we'll oops. The device will 
obviously stop working if it loses mandatory resources, this is all about 
failing gracefully.

One a side note, this is actually very difficult to get right in drivers in a 
race-free way. I'm not sure how core frameworks could help, but if they can, 
they should. And I'm afraid that devm_kzalloc() worsened the situation as many 
drivers use it to allocate the driver-specific data structure that can be 
accessed through userspace API calls. The memory is then freed at unbind time 
without any reference counting.

> Other options are as you pointed out notifier callbacks that allows the
> resource use to be aware that a resource has disappeared and it might adjust
> and continue to function with limited functionality.

That's especially important for optional resources, when the consumer can 
still work, possibly in a degraded mode, when the resource isn't available. I 
don't think such a callback could replace the reference counting used in the 
above option though. Callbacks can be racy, and make locking tricky. Keeping 
pointers valid until the last user goes away should simplify the 
implementation and be our lowest level safety net.

Note that option resources here has a very specific meaning. For instance, a 
reset GPIO might be optional in the sense that if the reset pin of the device 
is tied to a power rail, the driver doesn't need to control the reset signal. 
If the GPIO is available though, and then disappears, it might get pulled back 
to the reset state due to the GPIO controller being unbound, which would 
prevent the device from working properly.

> Another option is to teach the device core about critical resource
> dependencies so that a consumer is automatically unbound by the core if any
> of its resource dependencies are unregistered. The device can also
> automatically be re-bound once the critical resources re-appear.

That could be an interesting shortcut, I'd be curious to see how it could be 
implemented.

> The most likely solution is probably a mixture of all of them.

-- 
Regards,

Laurent Pinchart

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

[Greg KH]

On Mon, Aug 01, 2016 at 04:44:25PM +0200, Andrzej Hajda wrote:
> On 08/01/2016 03:55 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 1 Aug 2016 15:33:22 +0200
> > Lars-Peter Clausen <lars@metafoo.de> escreveu:
> >
> >> On 08/01/2016 03:21 PM, 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.  
> >> suppress_bind_attrs is the lazy solution and as you pointed out does not
> >> work too well for all cases.
> > Agreed. 
> >
> > What we really need is a kind of "usage count" behavior to suppress
> > unbinds, e. g. a device driver can be unbound only if any other driver
> > using resources on it gets unbind first.
> >
> > That will solve most of unbind issues at the media subsystem.
> 
> When I was investigating issues with unbind sysfs attribute I have found
> claim by Greg KH that unbind should be rather unavoidable, like in case
> of hw removal - kernel is not able to prevent users from removing usb
> device, even if it is in use.
> 
> Assuming the claim is still valid, the only solution I see are callbacks
> notifying resource consumers about removal of the resources.

Yes, you have to do that as the hardware might now be gone, and you have
no control over that.

thanks,

greg k-h

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

[Luis R. Rodriguez]

On Fri, Jul 29, 2016 at 12:13:03PM +0100, 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.

I'd like to understand the requirement for this a bit better, so someone explaining
this would be good if this moves forward as a tech session.

> > 
> > 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.

OK that's 2.

Another piece of code that deals with complex dependencies I've recently
ventured into was the x86 IOMMU stuff. The complexities here are both at
the built-in init level and also later at probe.

For the built-in code we have a code run time sort where based on a simple set
of semantics used to declare dependencies final code that was compiled in is
sorted out so that the code that needs to initialize first triggers first. hpa
had suggested long ago that generalizing this was desirable, so I've taken that
task and have some basic building blocks which are now being proposed in their
RFC v3 series [0]. If it seems that the run time sort mechanism is left out,
its correct, upon review with Andy on RFC v2 we don't *yet* need a run time
sort, even though I expanded on the existing one for IOMMU and strengthened the
semantics there, its still available on the userspace mockup solution for
linker tables though [1]. I should note that I did at least determine that
generalizing a sort for dependency maps which shuffles code at run time
did not make sense due to the fact that you'd either need to generalize the
building blocks used for defining a dependency map. If you move one item used
for init from the end to the front, your iteration function must use the same
structure in the same way. Run time sorts for code sections then are left up
to each subsystem to implement. On x86, I evaluated sorting out dependencies
further, for instance on setup_arch() -- however it just seemed not needed
at this point. For other subsystems this may make more sense.

At the probe level IOMMUs face another issue when dealing with GPU drivers.
The kernel has 7 levels of initialization possible (pure_initcall() == 0,
core_initcall() == 1, ..., fs_initcall() == 5, device_initcall() == 6,
late_initcall() == 7), module_init() maps to device_initcall(), but modules may
also use late_initcall() if they know a driver built-in needs to definitely run
very late. Naturally if you're not a piece of code running very early on, and
you want the option to be a module as well (device_initcall == 6) then you
really only have at your disposal two levels available before you get to an end
device driver. It turns out that for GPU drivers this is not enough to map out
enough dependencies at the higher level, so the only next best solution
available is to implicitly rely on linker order. This is the case for ordering
logistics between AMD IOMMU v1, AMD IOMMUv2 (depends on AMD IOMMU v1), and
AMD KFD driver, and the AMD radeon driver:

0. AMD IOMMUv1:    arch/x86/kernel/pci-dma.c
1. AMD IOMMUv2:    drivers/iommu/amd_iommu_v2.c
2. AMD KFD:        drivers/gpu/drm/amd/amdkfd/kfd_module.c
3. AMD Radeon:     drivers/gpu/drm/radeon/radeon_drv.c

For details refer to a recent discussion on this [2].

Using linker tables for initialization should enable us to scale initialization
levels well beyond 7 levels, in fact this could be however long an ASCII string
is acceptable in C as the order level is stored as a string (part of the section
name) and also enable each subsystem to have its own set of levels / heuristics
for initialization as well. Ordering would actually be done at link time, so
the code is already ordered *iff* all dependency heuristics are available at
compilation time. If dependency information can only be available at run time,
a run time sort is optional but using the existing x86 IOMMU code as an example
and precedent (and considering my expanded stricter semantics) -- in the future
this can be an option for any subsystem as well as a supplement.

My interest in the media controller and the SAT solver is I consider the run
time sort nothing but a sloppy hack (see my userspace tree for tons of
semantics fixes), and formalizing this to something more concrete that can be
generic should be more useful to other parts of the kernel. This is why I
wanted to discuss these things. Is there a generic common goal here and
can we share code ? If so what would that look like ?

My impression at first is that linker-time dependencies should suffice to cover
a lot cases, but that should still mean then that binutils ld SORT() could
potentially be enhanced further in the future, specially if a simple dependency
map could be expressed. For instance can we make it run faster, or would
having it interpret certain other criteria enable us to use a SAT solver
to optimize dependency resolution / ordering. Then there is run time sorting
and optimization -- but the same questions apply here.

I think a fruitful session would be to:

  o review / explain each of the complex ordering problems from different
    kernel subsystems
  o review / explain existing solutions to these problems
  o finally try to figure out if a common solution is possible, both
    short term and long term

[0] https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcgrof@kernel.org
[1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/
[2] https://lkml.kernel.org/r/1464311916-10065-1-git-send-email-mcgrof@kernel.org

  Luis

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

[Rafael J. Wysocki]

On Monday, August 01, 2016 09:03:09 PM Luis R. Rodriguez wrote:
> On Fri, Jul 29, 2016 at 12:13:03PM +0100, 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.
> 
> I'd like to understand the requirement for this a bit better, so someone explaining
> this would be good if this moves forward as a tech session.

One case I'm familiar with is when a device has two (or more) device IDs, where
one is more specific than the other.  The idea being that if the OS has a driver
for that particular device, it will use the more specific device ID (say A) to
look for it, but otherwise it will use the other "generic" ID (say B) to match
against a "generic" driver.

Of course, that only works if the driver for A is probed before the driver for B.

> > > 
> > > 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.
> 
> OK that's 2.
> 
> Another piece of code that deals with complex dependencies I've recently
> ventured into was the x86 IOMMU stuff. The complexities here are both at
> the built-in init level and also later at probe.
> 
> For the built-in code we have a code run time sort where based on a simple set
> of semantics used to declare dependencies final code that was compiled in is
> sorted out so that the code that needs to initialize first triggers first. hpa
> had suggested long ago that generalizing this was desirable, so I've taken that
> task and have some basic building blocks which are now being proposed in their
> RFC v3 series [0]. If it seems that the run time sort mechanism is left out,
> its correct, upon review with Andy on RFC v2 we don't *yet* need a run time
> sort, even though I expanded on the existing one for IOMMU and strengthened the
> semantics there, its still available on the userspace mockup solution for
> linker tables though [1]. I should note that I did at least determine that
> generalizing a sort for dependency maps which shuffles code at run time
> did not make sense due to the fact that you'd either need to generalize the
> building blocks used for defining a dependency map. If you move one item used
> for init from the end to the front, your iteration function must use the same
> structure in the same way. Run time sorts for code sections then are left up
> to each subsystem to implement. On x86, I evaluated sorting out dependencies
> further, for instance on setup_arch() -- however it just seemed not needed
> at this point. For other subsystems this may make more sense.
> 
> At the probe level IOMMUs face another issue when dealing with GPU drivers.
> The kernel has 7 levels of initialization possible (pure_initcall() == 0,
> core_initcall() == 1, ..., fs_initcall() == 5, device_initcall() == 6,
> late_initcall() == 7), module_init() maps to device_initcall(), but modules may
> also use late_initcall() if they know a driver built-in needs to definitely run
> very late. Naturally if you're not a piece of code running very early on, and
> you want the option to be a module as well (device_initcall == 6) then you
> really only have at your disposal two levels available before you get to an end
> device driver. It turns out that for GPU drivers this is not enough to map out
> enough dependencies at the higher level, so the only next best solution
> available is to implicitly rely on linker order. This is the case for ordering
> logistics between AMD IOMMU v1, AMD IOMMUv2 (depends on AMD IOMMU v1), and
> AMD KFD driver, and the AMD radeon driver:
> 
> 0. AMD IOMMUv1:    arch/x86/kernel/pci-dma.c
> 1. AMD IOMMUv2:    drivers/iommu/amd_iommu_v2.c
> 2. AMD KFD:        drivers/gpu/drm/amd/amdkfd/kfd_module.c
> 3. AMD Radeon:     drivers/gpu/drm/radeon/radeon_drv.c
> 
> For details refer to a recent discussion on this [2].
> 
> Using linker tables for initialization should enable us to scale initialization
> levels well beyond 7 levels, in fact this could be however long an ASCII string
> is acceptable in C as the order level is stored as a string (part of the section
> name) and also enable each subsystem to have its own set of levels / heuristics
> for initialization as well. Ordering would actually be done at link time, so
> the code is already ordered *iff* all dependency heuristics are available at
> compilation time. If dependency information can only be available at run time,
> a run time sort is optional but using the existing x86 IOMMU code as an example
> and precedent (and considering my expanded stricter semantics) -- in the future
> this can be an option for any subsystem as well as a supplement.
> 
> My interest in the media controller and the SAT solver is I consider the run
> time sort nothing but a sloppy hack (see my userspace tree for tons of
> semantics fixes), and formalizing this to something more concrete that can be
> generic should be more useful to other parts of the kernel. This is why I
> wanted to discuss these things. Is there a generic common goal here and
> can we share code ? If so what would that look like ?
> 
> My impression at first is that linker-time dependencies should suffice to cover
> a lot cases, but that should still mean then that binutils ld SORT() could
> potentially be enhanced further in the future, specially if a simple dependency
> map could be expressed. For instance can we make it run faster, or would
> having it interpret certain other criteria enable us to use a SAT solver
> to optimize dependency resolution / ordering. Then there is run time sorting
> and optimization -- but the same questions apply here.
> 
> I think a fruitful session would be to:
> 
>   o review / explain each of the complex ordering problems from different
>     kernel subsystems
>   o review / explain existing solutions to these problems
>   o finally try to figure out if a common solution is possible, both
>     short term and long term
> 
> [0] https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcgrof@kernel.org
> [1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/
> [2] https://lkml.kernel.org/r/1464311916-10065-1-git-send-email-mcgrof@kernel.org

I'm still wondering why probe ordering is special and suspend-resume and runtime
PM ordering isn't (and shutdown ordering too, for that matter).

In the majority of cases when probe ordering matters, suspend/resume and runtime
PM ordering matters too, so considering one of them alone doesn't seem very
useful to me.

Now, even if you can address probe ordering issues by using some link-time
methods and similar, runtime PM is async by nature and suspend/resume is
async for many devices too (for efficiency reasons) and the only approach
that works here is to have the dependencies represented as data somehow
and use those when you need to carry out the operation.

Thanks,
Rafael

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

[Luis R. Rodriguez]

On Tue, Aug 02, 2016 at 02:01:56AM +0200, Rafael J. Wysocki wrote:
> On Monday, August 01, 2016 09:03:09 PM Luis R. Rodriguez wrote:
> > On Fri, Jul 29, 2016 at 12:13:03PM +0100, 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.
> > 
> > I'd like to understand the requirement for this a bit better, so someone explaining
> > this would be good if this moves forward as a tech session.
> 
> One case I'm familiar with is when a device has two (or more) device IDs, where
> one is more specific than the other.  The idea being that if the OS has a driver
> for that particular device, it will use the more specific device ID (say A) to
> look for it, but otherwise it will use the other "generic" ID (say B) to match
> against a "generic" driver.
> 
> Of course, that only works if the driver for A is probed before the driver for B.

That's a good case to keep in mind which is indeed complex.

> > > > 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.
> > 
> > OK that's 2.
> > 
> > Another piece of code that deals with complex dependencies I've recently
> > ventured into was the x86 IOMMU stuff. The complexities here are both at
> > the built-in init level and also later at probe.
> > 
> > For the built-in code we have a code run time sort where based on a simple set
> > of semantics used to declare dependencies final code that was compiled in is
> > sorted out so that the code that needs to initialize first triggers first. hpa
> > had suggested long ago that generalizing this was desirable, so I've taken that
> > task and have some basic building blocks which are now being proposed in their
> > RFC v3 series [0]. If it seems that the run time sort mechanism is left out,
> > its correct, upon review with Andy on RFC v2 we don't *yet* need a run time
> > sort, even though I expanded on the existing one for IOMMU and strengthened the
> > semantics there, its still available on the userspace mockup solution for
> > linker tables though [1]. I should note that I did at least determine that
> > generalizing a sort for dependency maps which shuffles code at run time
> > did not make sense due to the fact that you'd either need to generalize the
> > building blocks used for defining a dependency map. If you move one item used
> > for init from the end to the front, your iteration function must use the same
> > structure in the same way. Run time sorts for code sections then are left up
> > to each subsystem to implement. On x86, I evaluated sorting out dependencies
> > further, for instance on setup_arch() -- however it just seemed not needed
> > at this point. For other subsystems this may make more sense.
> > 
> > At the probe level IOMMUs face another issue when dealing with GPU drivers.
> > The kernel has 7 levels of initialization possible (pure_initcall() == 0,
> > core_initcall() == 1, ..., fs_initcall() == 5, device_initcall() == 6,
> > late_initcall() == 7), module_init() maps to device_initcall(), but modules may
> > also use late_initcall() if they know a driver built-in needs to definitely run
> > very late. Naturally if you're not a piece of code running very early on, and
> > you want the option to be a module as well (device_initcall == 6) then you
> > really only have at your disposal two levels available before you get to an end
> > device driver. It turns out that for GPU drivers this is not enough to map out
> > enough dependencies at the higher level, so the only next best solution
> > available is to implicitly rely on linker order. This is the case for ordering
> > logistics between AMD IOMMU v1, AMD IOMMUv2 (depends on AMD IOMMU v1), and
> > AMD KFD driver, and the AMD radeon driver:
> > 
> > 0. AMD IOMMUv1:    arch/x86/kernel/pci-dma.c
> > 1. AMD IOMMUv2:    drivers/iommu/amd_iommu_v2.c
> > 2. AMD KFD:        drivers/gpu/drm/amd/amdkfd/kfd_module.c
> > 3. AMD Radeon:     drivers/gpu/drm/radeon/radeon_drv.c
> > 
> > For details refer to a recent discussion on this [2].
> > 
> > Using linker tables for initialization should enable us to scale initialization
> > levels well beyond 7 levels, in fact this could be however long an ASCII string
> > is acceptable in C as the order level is stored as a string (part of the section
> > name) and also enable each subsystem to have its own set of levels / heuristics
> > for initialization as well. Ordering would actually be done at link time, so
> > the code is already ordered *iff* all dependency heuristics are available at
> > compilation time. If dependency information can only be available at run time,
> > a run time sort is optional but using the existing x86 IOMMU code as an example
> > and precedent (and considering my expanded stricter semantics) -- in the future
> > this can be an option for any subsystem as well as a supplement.
> > 
> > My interest in the media controller and the SAT solver is I consider the run
> > time sort nothing but a sloppy hack (see my userspace tree for tons of
> > semantics fixes), and formalizing this to something more concrete that can be
> > generic should be more useful to other parts of the kernel. This is why I
> > wanted to discuss these things. Is there a generic common goal here and
> > can we share code ? If so what would that look like ?
> > 
> > My impression at first is that linker-time dependencies should suffice to cover
> > a lot cases, but that should still mean then that binutils ld SORT() could
> > potentially be enhanced further in the future, specially if a simple dependency
> > map could be expressed. For instance can we make it run faster, or would
> > having it interpret certain other criteria enable us to use a SAT solver
> > to optimize dependency resolution / ordering. Then there is run time sorting
> > and optimization -- but the same questions apply here.
> > 
> > I think a fruitful session would be to:
> > 
> >   o review / explain each of the complex ordering problems from different
> >     kernel subsystems
> >   o review / explain existing solutions to these problems
> >   o finally try to figure out if a common solution is possible, both
> >     short term and long term
> > 
> > [0] https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcgrof@kernel.org
> > [1] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linker-tables.git/
> > [2] https://lkml.kernel.org/r/1464311916-10065-1-git-send-email-mcgrof@kernel.org
> 
> I'm still wondering why probe ordering is special and suspend-resume and runtime
> PM ordering isn't (and shutdown ordering too, for that matter).
> 
> In the majority of cases when probe ordering matters, suspend/resume and runtime
> PM ordering matters too, so considering one of them alone doesn't seem very
> useful to me.
> 
> Now, even if you can address probe ordering issues by using some link-time
> methods and similar, runtime PM is async by nature and suspend/resume is
> async for many devices too (for efficiency reasons) and the only approach
> that works here is to have the dependencies represented as data somehow
> and use those when you need to carry out the operation.

Apologies, its why I Cc'd you -- I did mean to implicate both, given that as
I also had reviewed your work, I figured similar issues were being dealt with
there. So indeed, what I am suggesting is perhaps we can knock a few birds with
one stone here.

  Luis

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

[Dmitry Torokhov]

On Mon, Aug 1, 2016 at 5:56 PM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> On Tue, Aug 02, 2016 at 02:01:56AM +0200, Rafael J. Wysocki wrote:
>> On Monday, August 01, 2016 09:03:09 PM Luis R. Rodriguez wrote:
>> > On Fri, Jul 29, 2016 at 12:13:03PM +0100, 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.
>> >
>> > I'd like to understand the requirement for this a bit better, so someone explaining
>> > this would be good if this moves forward as a tech session.
>>
>> One case I'm familiar with is when a device has two (or more) device IDs, where
>> one is more specific than the other.  The idea being that if the OS has a driver
>> for that particular device, it will use the more specific device ID (say A) to
>> look for it, but otherwise it will use the other "generic" ID (say B) to match
>> against a "generic" driver.
>>
>> Of course, that only works if the driver for A is probed before the driver for B.
>
> That's a good case to keep in mind which is indeed complex.

HID would definitely benefit from specific/generic support. Rigth now
there are somewhat long tables of devices generic hid driver ignores
so that specific drivers have a chance to bind.

Thanks.

-- 
Dmitry

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

[Jiri Kosina]

On Mon, 1 Aug 2016, Dmitry Torokhov wrote:

> HID would definitely benefit from specific/generic support. Rigth now 
> there are somewhat long tables of devices generic hid driver ignores so 
> that specific drivers have a chance to bind.

Agreed, that's an excellent use-case for this proposal. Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Hannes Reinecke]

On 08/02/2016 02:56 AM, Luis R. Rodriguez wrote:
> On Tue, Aug 02, 2016 at 02:01:56AM +0200, Rafael J. Wysocki wrote:
>> On Monday, August 01, 2016 09:03:09 PM Luis R. Rodriguez wrote:
>>> On Fri, Jul 29, 2016 at 12:13:03PM +0100, 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.
>>>
>>> I'd like to understand the requirement for this a bit better, so someone explaining
>>> this would be good if this moves forward as a tech session.
>>
>> One case I'm familiar with is when a device has two (or more) device IDs, where
>> one is more specific than the other.  The idea being that if the OS has a driver
>> for that particular device, it will use the more specific device ID (say A) to
>> look for it, but otherwise it will use the other "generic" ID (say B) to match
>> against a "generic" driver.
>>
>> Of course, that only works if the driver for A is probed before the driver for B.
> 
> That's a good case to keep in mind which is indeed complex.
> 
We actually have been discussing such a scenario when running under
UEFI; there you could implement a generic UEFI network driver, which
then later might get superseded by the 'real' network driver.

Which would require to
a) be able to properly formulate the probing order
and
b) establish proper rules on how to 're-bind' a device to a different
driver.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.com			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

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

[Jiri Kosina]

On Tue, 2 Aug 2016, Hannes Reinecke wrote:

> We actually have been discussing such a scenario when running under 
> UEFI; there you could implement a generic UEFI network driver, which 
> then later might get superseded by the 'real' network driver.
> 
> Which would require to
> a) be able to properly formulate the probing order
> and
> b) establish proper rules on how to 're-bind' a device to a different
> driver.

Similar use-case for HID.

There is a lot of hardware for which hid-generic driver 'sort of works' 
(and it makes sense to have that one included in the initrd), but then 
there are specific drivers fully exploiting all the capabilities of 
particular device (and it doesn't make sense to include all of those in 
initrd).

Currently, the hid-generic doesn't bind to such devices at all, because it 
has a large list of device IDs for which specific drivers exist, and 
expects those to be bound. Which doesn't really provide the best user 
experience.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Takashi Iwai]

On Tue, 02 Aug 2016 11:48:03 +0200,
Jiri Kosina wrote:
> 
> On Tue, 2 Aug 2016, Hannes Reinecke wrote:
> 
> > We actually have been discussing such a scenario when running under 
> > UEFI; there you could implement a generic UEFI network driver, which 
> > then later might get superseded by the 'real' network driver.
> > 
> > Which would require to
> > a) be able to properly formulate the probing order
> > and
> > b) establish proper rules on how to 're-bind' a device to a different
> > driver.
> 
> Similar use-case for HID.
> 
> There is a lot of hardware for which hid-generic driver 'sort of works' 
> (and it makes sense to have that one included in the initrd), but then 
> there are specific drivers fully exploiting all the capabilities of 
> particular device (and it doesn't make sense to include all of those in 
> initrd).
> 
> Currently, the hid-generic doesn't bind to such devices at all, because it 
> has a large list of device IDs for which specific drivers exist, and 
> expects those to be bound. Which doesn't really provide the best user 
> experience.

Another "me too": a similar requirement for HD-audio.

We provide a generic HD-audio codec driver and codec-specific drivers.
Currently, the prioritized binding is done by the special binder code
in HD-audio controller driver, since we have no standard established
fallback bind mechanism, so far.


Takashi

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

[Jörg Rödel]

On Mon, Aug 01, 2016 at 09:03:09PM +0200, Luis R. Rodriguez wrote:
> Another piece of code that deals with complex dependencies I've recently
> ventured into was the x86 IOMMU stuff. The complexities here are both at
> the built-in init level and also later at probe.

Yeah, everything is fine when both, AMD-KFD and the IOMMUv2 driver are
built as modules, as the order of loading these modules is
preserved by symbol dependencies. But when they are built-in these
modules also need to be initialized in the right order, otherwise the
KFD-driver will call into an uninialized IOMMU driver and crashes the
system. Long-term this will be fixed by always build-in the IOMMU-parts
(when they are merged with the Intel-SVM support), but in general not
being able to express dependencies between build-in modules remains to
be a problem.

I have spent spent some thoughts on how this could be solved, and one
idea I had was to rework the way build-in modules work. If they are not
linked into the kernel at compile-time, but at boot-time, this problem
would be solved. On the other hand this slows down boot (is this important
when distro-kernels build everything as modules anyway?) and probably
doesn't solve the dependency problems for power-management or elsewhere
in kernel.

So I'd like to participate if this is going to be discussed.


Thanks,

	Joerg

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

[James Bottomley]

On Tue, 2016-08-09 at 11:57 +0200, Jörg Rödel wrote:
> On Mon, Aug 01, 2016 at 09:03:09PM +0200, Luis R. Rodriguez wrote:
> > Another piece of code that deals with complex dependencies I've
> > recently
> > ventured into was the x86 IOMMU stuff. The complexities here are
> > both at
> > the built-in init level and also later at probe.
> 
> Yeah, everything is fine when both, AMD-KFD and the IOMMUv2 driver 
> are built as modules, as the order of loading these modules is
> preserved by symbol dependencies. But when they are built-in these
> modules also need to be initialized in the right order, otherwise the
> KFD-driver will call into an uninialized IOMMU driver and crashes the
> system. Long-term this will be fixed by always build-in the IOMMU
> -parts (when they are merged with the Intel-SVM support), but in 
> general not being able to express dependencies between build-in 
> modules remains to be a problem.

Have you considered using transport templates or attribute containers? 
 That's how we manage the complex hierarchies in ATA/SCSI.  If you look
we have a complex dependency

ata_dev->transport->ata->scsi (or in SCSI dev->transport->scsi)

Our chains are much more complex than this because I've stopped before
probing begins, which is async.

The basic way we cope is that both ata and scsi use subsystem_init for
their exclusive resources, meaning they're order independent. The
probes a kicked off by the hardware modules, so they're done by
module_init (meaning after subsystem_init) again, order independent. 
 The rest of the dependent initialisations is done within the
transport/attribute code, meaning not until a consumer is actually
instantiated.

The way attributes/transport classes work is that they're actually
attached to the devices that you instantiate

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

[James Bottomley]

On Tue, 2016-08-09 at 09:08 -0700, James Bottomley wrote:
> On Tue, 2016-08-09 at 11:57 +0200, Jörg Rödel wrote:
> > On Mon, Aug 01, 2016 at 09:03:09PM +0200, Luis R. Rodriguez wrote:
> > > Another piece of code that deals with complex dependencies I've
> > > recently
> > > ventured into was the x86 IOMMU stuff. The complexities here are
> > > both at
> > > the built-in init level and also later at probe.
> > 
> > Yeah, everything is fine when both, AMD-KFD and the IOMMUv2 driver 
> > are built as modules, as the order of loading these modules is
> > preserved by symbol dependencies. But when they are built-in these
> > modules also need to be initialized in the right order, otherwise
> > the
> > KFD-driver will call into an uninialized IOMMU driver and crashes
> > the
> > system. Long-term this will be fixed by always build-in the IOMMU
> > -parts (when they are merged with the Intel-SVM support), but in 
> > general not being able to express dependencies between build-in 
> > modules remains to be a problem.
> 
> Have you considered using transport templates or attribute 
> containers?  That's how we manage the complex hierarchies in 
> ATA/SCSI.  If you look we have a complex dependency
> 
> ata_dev->transport->ata->scsi (or in SCSI dev->transport->scsi)
> 
> Our chains are much more complex than this because I've stopped 
> before probing begins, which is async.
> 
> The basic way we cope is that both ata and scsi use subsystem_init 
> for their exclusive resources, meaning they're order independent. The
> probes a kicked off by the hardware modules, so they're done by
> module_init (meaning after subsystem_init) again, order independent. 
>  The rest of the dependent initialisations is done within the
> transport/attribute code, meaning not until a consumer is actually
> instantiated.
> 
> The way attributes/transport classes work is that they're actually
> attached to the devices that you instantiate

Hmm, pressed send to early.  However, the basic point is that you can
finesse most of the "dependency" issues by separating the
initalisations into a subsystem part (which is guaranteed before any
device is probed) and a device part, which can be done at device
instantiation time.

James

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

[Luis R. Rodriguez]

On Tue, Aug 09, 2016 at 09:11:00AM -0700, James Bottomley wrote:
> On Tue, 2016-08-09 at 09:08 -0700, James Bottomley wrote:
> > On Tue, 2016-08-09 at 11:57 +0200, Jörg Rödel wrote:
> > > On Mon, Aug 01, 2016 at 09:03:09PM +0200, Luis R. Rodriguez wrote:
> > > > Another piece of code that deals with complex dependencies I've
> > > > recently
> > > > ventured into was the x86 IOMMU stuff. The complexities here are
> > > > both at
> > > > the built-in init level and also later at probe.
> > > 
> > > Yeah, everything is fine when both, AMD-KFD and the IOMMUv2 driver 
> > > are built as modules, as the order of loading these modules is
> > > preserved by symbol dependencies. But when they are built-in these
> > > modules also need to be initialized in the right order, otherwise
> > > the
> > > KFD-driver will call into an uninialized IOMMU driver and crashes
> > > the
> > > system. Long-term this will be fixed by always build-in the IOMMU
> > > -parts (when they are merged with the Intel-SVM support), but in 
> > > general not being able to express dependencies between build-in 
> > > modules remains to be a problem.
> > 
> > Have you considered using transport templates or attribute 
> > containers?  That's how we manage the complex hierarchies in 
> > ATA/SCSI.  If you look we have a complex dependency
> > 
> > ata_dev->transport->ata->scsi (or in SCSI dev->transport->scsi)
> > 
> > Our chains are much more complex than this because I've stopped 
> > before probing begins, which is async.
> > 
> > The basic way we cope is that both ata and scsi use subsystem_init 
> > for their exclusive resources, meaning they're order independent. The
> > probes a kicked off by the hardware modules, so they're done by
> > module_init (meaning after subsystem_init) again, order independent. 
> >  The rest of the dependent initialisations is done within the
> > transport/attribute code, meaning not until a consumer is actually
> > instantiated.
> > 
> > The way attributes/transport classes work is that they're actually
> > attached to the devices that you instantiate
> 
> Hmm, pressed send to early.  However, the basic point is that you can
> finesse most of the "dependency" issues by separating the
> initalisations into a subsystem part (which is guaranteed before any
> device is probed) and a device part, which can be done at device
> instantiation time.

This sounds pretty great, what other subsystems use it and most
importantly, why haven't others picked this up yet ?

  Luis

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

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Tue, 2016-08-09 at 18:51 +0200, Luis R. Rodriguez wrote:
> 
> > Hmm, pressed send to early.  However, the basic point is that you can
> > finesse most of the "dependency" issues by separating the
> > initalisations into a subsystem part (which is guaranteed before any
> > device is probed) and a device part, which can be done at device
> > instantiation time.
> 
> This sounds pretty great, what other subsystems use it and most
> importantly, why haven't others picked this up yet ?

Most subsystems use it; it's fairly ubiquitous.

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5760 bytes --]

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

[James Bottomley]

On Tue, 2016-08-09 at 18:51 +0200, Luis R. Rodriguez wrote:
> On Tue, Aug 09, 2016 at 09:11:00AM -0700, James Bottomley wrote:
> > On Tue, 2016-08-09 at 09:08 -0700, James Bottomley wrote:
> > > On Tue, 2016-08-09 at 11:57 +0200, Jörg Rödel wrote:
> > > > On Mon, Aug 01, 2016 at 09:03:09PM +0200, Luis R. Rodriguez
> > > > wrote:
> > > > > Another piece of code that deals with complex dependencies 
> > > > > I've recently ventured into was the x86 IOMMU stuff. The 
> > > > > complexities here are both at the built-in init level and
> > > > > also later at probe.
> > > > 
> > > > Yeah, everything is fine when both, AMD-KFD and the IOMMUv2 
> > > > driver are built as modules, as the order of loading these 
> > > > modules is preserved by symbol dependencies. But when they are 
> > > > built-in these modules also need to be initialized in the right 
> > > > order, otherwise the KFD-driver will call into an uninialized 
> > > > IOMMU driver and crashes the system. Long-term this will be 
> > > > fixed by always build-in the IOMMU-parts (when they are merged 
> > > > with the Intel-SVM support), but in general not being able to 
> > > > express dependencies between build-in modules remains to be a
> > > > problem.
> > > 
> > > Have you considered using transport templates or attribute 
> > > containers?  That's how we manage the complex hierarchies in 
> > > ATA/SCSI.  If you look we have a complex dependency
> > > 
> > > ata_dev->transport->ata->scsi (or in SCSI dev->transport->scsi)
> > > 
> > > Our chains are much more complex than this because I've stopped 
> > > before probing begins, which is async.
> > > 
> > > The basic way we cope is that both ata and scsi use 
> > > subsystem_init for their exclusive resources, meaning they're 
> > > order independent. The probes a kicked off by the hardware 
> > > modules, so they're done by module_init (meaning after 
> > > subsystem_init) again, order independent.  The rest of the 
> > > dependent initialisations is done within the transport/attribute 
> > > code, meaning not until a consumer is actually instantiated.
> > > 
> > > The way attributes/transport classes work is that they're 
> > > actually attached to the devices that you instantiate
> > 
> > Hmm, pressed send to early.  However, the basic point is that you 
> > can finesse most of the "dependency" issues by separating the
> > initalisations into a subsystem part (which is guaranteed before 
> > any device is probed) and a device part, which can be done at 
> > device instantiation time.
> 
> This sounds pretty great, what other subsystems use it and most
> importantly, why haven't others picked this up yet ?

The transport classes? Only SCSI and its dependent subsystems, as far
as I'm aware.  It's been around for ages (2004, I think; there's an OLS
paper on it) but hitherto only we had the complex dependency problem,
particularly with the driver/transport separation that this was
designed for.

However, there may be many other subsystems that use the technique in a
different way.  The basics are the theorem of separability: any set of
separable problems can be made arbitrarily complex if you look at them
in the wrong way.  The corollary being that any hugely complex
interdependency may be rendered unnecessary by simply viewing the
problem in a different way.  It turns out that most of our complex
dependency issues can be made to go away if we look at stuff in the
right way.

James

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

[Jörg Rödel]

On Tue, Aug 09, 2016 at 09:11:00AM -0700, James Bottomley wrote:
> 
> Hmm, pressed send to early.  However, the basic point is that you can
> finesse most of the "dependency" issues by separating the
> initalisations into a subsystem part (which is guaranteed before any
> device is probed) and a device part, which can be done at device
> instantiation time.

Yeah, that's true, the problem can be solved with this pattern too, and
this sounds a lot more stable than the current solution for this problem
on the IOMMU side. Currently this is 'solved' by making sure the iommu
driver is linked in before the KFD driver is, which affects the order of
the initcalls.

Anyway, it would be good to have a solution which removes the
differences between whether something is compiled-in or as a module,
because this reduces the testing matrix and makes everyones life easier.
For me it would be nice to know that if something works as a module, it
will still work when compiled in.



	Joerg

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

[Luis R. Rodriguez]

On Tue, Aug 09, 2016 at 11:57:28AM +0200, Jörg Rödel wrote:
> On Mon, Aug 01, 2016 at 09:03:09PM +0200, Luis R. Rodriguez wrote:
> > Another piece of code that deals with complex dependencies I've recently
> > ventured into was the x86 IOMMU stuff. The complexities here are both at
> > the built-in init level and also later at probe.
> 
> Yeah, everything is fine when both, AMD-KFD and the IOMMUv2 driver are
> built as modules, as the order of loading these modules is
> preserved by symbol dependencies. But when they are built-in these
> modules also need to be initialized in the right order, otherwise the
> KFD-driver will call into an uninialized IOMMU driver and crashes the
> system. Long-term this will be fixed by always build-in the IOMMU-parts
> (when they are merged with the Intel-SVM support), but in general not
> being able to express dependencies between build-in modules remains to
> be a problem.
> 
> I have spent spent some thoughts on how this could be solved, and one
> idea I had was to rework the way build-in modules work. If they are not
> linked into the kernel at compile-time, but at boot-time, this problem
> would be solved.

If the semantics of order would be in place at compile time linker tables
could be used to link at compile time in such a way that order is respected
so linking at compile time is possible, you however would need an explicit
order mentioned, which IMHO would be good.

How would linking the kernel at boot time happen so that it can
enable proper ordering ?

> On the other hand this slows down boot (is this important
> when distro-kernels build everything as modules anyway?)

If done once I think this is reasonable, but again, if you can do this
arrangement at compile time, why not?

The one issue with this solution however is it does not address
specialized ordering with information only attainable at run time.
For this later issue a run time sort is still possible and we have
precedents for such things in the x86 IOMMU PCI initialization code,
however note that that code can be replaced by compile time sort given
the dependencies can be attained also at link order. Nevertheless, its
precedent shows a demo of how a run time sort is possible if you don't
all ordering information at compile time.

  Luis

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

[Jörg Rödel]

On Tue, Aug 09, 2016 at 08:06:52PM +0200, Luis R. Rodriguez wrote:
> If the semantics of order would be in place at compile time linker tables
> could be used to link at compile time in such a way that order is respected
> so linking at compile time is possible, you however would need an explicit
> order mentioned, which IMHO would be good.
> 
> How would linking the kernel at boot time happen so that it can
> enable proper ordering ?

The idea was basically to compile module stuff always as a module and
put the modules that should be 'built-in' into the kernel-image and let
the module-code link them into the kernel at boot time automatically in
the right order, as the required symbols become visible.

But thats a rather intrusive change and I am not sure the benefits
outweight the conversion cost.



	Joerg

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

[Luis R. Rodriguez]

On Wed, Aug 10, 2016 at 05:21:24PM +0200, Jörg Rödel wrote:
> On Tue, Aug 09, 2016 at 08:06:52PM +0200, Luis R. Rodriguez wrote:
> > If the semantics of order would be in place at compile time linker tables
> > could be used to link at compile time in such a way that order is respected
> > so linking at compile time is possible, you however would need an explicit
> > order mentioned, which IMHO would be good.
> > 
> > How would linking the kernel at boot time happen so that it can
> > enable proper ordering ?
> 
> The idea was basically to compile module stuff always as a module and
> put the modules that should be 'built-in' into the kernel-image and let
> the module-code link them into the kernel at boot time automatically in
> the right order, as the required symbols become visible.
> 
> But thats a rather intrusive change and I am not sure the benefits
> outweight the conversion cost.

Yeah linking at boot sounds intrusive but the logic of re-using the module
ordering scheme for delaying selective built-in inits does not sound so bad to
me. I believe you are right that if the existing simple module ordering scheme
suffices for module_init() order, it should also be possible to delay such
built-in init so long as the same module ordering is followed. With a bit of
stuffing the driver symbol dep map stuff into built-in, it should be in theory
possible to have something similar and simple for built-in, with already well
tested coverage. Also, if there are flaws with module order, or simply we know
we want something better / different for built-in it begs the question if we
can borrow similar logic for modules as well.

I'd be surprised if no one had thought of this or tried this before though --
have we not ?

  Luis

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

[Jörg Rödel]

On Wed, Aug 10, 2016 at 06:42:22PM +0200, Luis R. Rodriguez wrote:
> Yeah linking at boot sounds intrusive but the logic of re-using the module
> ordering scheme for delaying selective built-in inits does not sound so bad to
> me. I believe you are right that if the existing simple module ordering scheme
> suffices for module_init() order, it should also be possible to delay such
> built-in init so long as the same module ordering is followed. With a bit of
> stuffing the driver symbol dep map stuff into built-in, it should be in theory
> possible to have something similar and simple for built-in, with already well
> tested coverage. Also, if there are flaws with module order, or simply we know
> we want something better / different for built-in it begs the question if we
> can borrow similar logic for modules as well.

Hmm, that might indeed work, with some changes to the build system, I
think. The problem is that on a vmlinux file the module boundaries went
away (you can't tell anymore which symbol belongs to which module, if at
all). So we need to work on the .o files to find out the correct order
(with some depmod-like tool) and sort the initcall-table accordingly in
an additional linker step.


	Joerg

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

[Linus Walleij]

On Tue, Aug 9, 2016 at 11:57 AM, Jörg Rödel <jroedel@suse.de> wrote:

> one
> idea I had was to rework the way build-in modules work. If they are not
> linked into the kernel at compile-time, but at boot-time, this problem
> would be solved. On the other hand this slows down boot (is this important
> when distro-kernels build everything as modules anyway?)

I don't know what you mean by "distro-kernels" but the vast majority if
not all Android kernels are coming with most stuff built-in, not as modules,
which means that you would slow down all Android tablets and phones on
the planet if this becomes slower. So it needs to be as quick or faster :)

Yours,
Linus Walleij

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

[Dmitry Torokhov]

On Wed, Jul 27, 2016 at 9:50 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> (first e-mail bounced)
>
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on
> to help enable asynchronous probe, however for built-in devices this requires
> very specific platform knowledge otherwise using async probe will blow up
> your kernel -- if you get it right though, using async probe can help with
> boot. Even if you sort things out well -- there are current limitations with
> ordering semantics available, case in point the x86 IOMMUs already have a small
> sort run which expand beyond the core init entries allowed, and on top of this
> the you still have device driver dependencies which are implicitly setting
> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
> AMD KFD, and AMD radeon. This has made us realize that at the module front the
> current 2 levels of init calls limits our ordering semantics leaving only link
> order as a last measure when things are built-in. Likewise I've recently have
> had to look into dependency issues early in boot been due to differences
> between paravirtualization and non-PV kernels, this lead to some current work
> to help generalize custom section uses (linker tables) and then for us to
> consider expanding x86 semantics early in boot to address some of the
> shortcomings implicit by the some paravirtualized boot path.
>
> The goal behind Rafael's work's goal is essentially to avoid code duplication
> (as without doing that in the core many drivers potentially need to do the same
> thing in the same way) and help to address the asynchronous system
> suspend/resume case that cannot be addressed by any driver by itself anyway.
> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
> however the patterns are very similar: addressing complex dependencies and
> relationships at run time and available semantics for these.
>
> This begs a few questions:
>
>  o Are there generic issues here ?
>  o Are there generic solutions possible ?
>  o What advanced techniques are out there to deal with this and how
>    are efforts in those domains going ?
>
> As an example of taste for the last item, consider Vegard Nossum's involvement
> with a SAT solver (picosat) for AFL fuzzing with ext4 on built-in kernels --
> and the possibility to share some of the tools to address some of the
> dependencies here. As it stands kconfig's semantics are a bit of a mess, and
> in turn often tools have to do a bit of inference work due to some of this,
> part if this problem is one reason why current kconfig-sat efforts are a bit
> stalled.
>
> Benefits for addressing some of these topics generally has quite a bit of
> uses in different domains:
>
>   o Speeding up boot time
>   o Avoiding dead code, or correctness
>   o Shrinking kernel size
>
> This is a pretty generally broad topic, and it does cross subsystems,
> I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
> Mauro, and Rafael in February this year about a LPC microconference
> about this sort of stuff as I thought that would have been a better venue --
> however even early then (February !) it seems they were busy with existing LPC
> microconferences. I recently poked them and they seem to agree discussing this
> somehow at KS would be good. Due to existing time constraints at LPC, but given
> most interested folks may be at KS or Plumbers, it'd be good to use shared time
> at KS and LPC to get folks to organize ideas, problems, and solutions and in a
> more adhoc manner, and then enable organically folks interested to organize and
> discuss short term and long term roadmaps on respective work items. Its unclear
> yet if there is a very CORE TOPIC here -- my guess would be that if there were
> we'd find out at the next KS, but not this one. A workshop for this might
> help.
>
> Folks required to help with these topics:
>
>   o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
>   o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional dependencies)
>   o Marek Szyprowski <m.szyprowski@samsung.com> (taking on some of
> Rafael's previous work)
>   o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
>   o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
>   o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
> kconfig issues)
>

Also Tomeu was looking into probe ordering (tomeu.vizoso@collabora.com).

-- 
Dmitry

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

[Marc Zyngier]

On 27/07/16 17:50, Luis R. Rodriguez wrote:
> (first e-mail bounced)
> 
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on
> to help enable asynchronous probe, however for built-in devices this requires
> very specific platform knowledge otherwise using async probe will blow up
> your kernel -- if you get it right though, using async probe can help with
> boot. Even if you sort things out well -- there are current limitations with
> ordering semantics available, case in point the x86 IOMMUs already have a small
> sort run which expand beyond the core init entries allowed, and on top of this
> the you still have device driver dependencies which are implicitly setting
> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
> AMD KFD, and AMD radeon. This has made us realize that at the module front the
> current 2 levels of init calls limits our ordering semantics leaving only link
> order as a last measure when things are built-in. Likewise I've recently have
> had to look into dependency issues early in boot been due to differences
> between paravirtualization and non-PV kernels, this lead to some current work
> to help generalize custom section uses (linker tables) and then for us to
> consider expanding x86 semantics early in boot to address some of the
> shortcomings implicit by the some paravirtualized boot path.
> 
> The goal behind Rafael's work's goal is essentially to avoid code duplication
> (as without doing that in the core many drivers potentially need to do the same
> thing in the same way) and help to address the asynchronous system
> suspend/resume case that cannot be addressed by any driver by itself anyway.
> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
> however the patterns are very similar: addressing complex dependencies and
> relationships at run time and available semantics for these.
> 
> This begs a few questions:
> 
>  o Are there generic issues here ?
>  o Are there generic solutions possible ?
>  o What advanced techniques are out there to deal with this and how
>    are efforts in those domains going ?
> 
> As an example of taste for the last item, consider Vegard Nossum's involvement
> with a SAT solver (picosat) for AFL fuzzing with ext4 on built-in kernels --
> and the possibility to share some of the tools to address some of the
> dependencies here. As it stands kconfig's semantics are a bit of a mess, and
> in turn often tools have to do a bit of inference work due to some of this,
> part if this problem is one reason why current kconfig-sat efforts are a bit
> stalled.
> 
> Benefits for addressing some of these topics generally has quite a bit of
> uses in different domains:
> 
>   o Speeding up boot time
>   o Avoiding dead code, or correctness
>   o Shrinking kernel size
> 
> This is a pretty generally broad topic, and it does cross subsystems,
> I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
> Mauro, and Rafael in February this year about a LPC microconference
> about this sort of stuff as I thought that would have been a better venue --
> however even early then (February !) it seems they were busy with existing LPC
> microconferences. I recently poked them and they seem to agree discussing this
> somehow at KS would be good. Due to existing time constraints at LPC, but given
> most interested folks may be at KS or Plumbers, it'd be good to use shared time
> at KS and LPC to get folks to organize ideas, problems, and solutions and in a
> more adhoc manner, and then enable organically folks interested to organize and
> discuss short term and long term roadmaps on respective work items. Its unclear
> yet if there is a very CORE TOPIC here -- my guess would be that if there were
> we'd find out at the next KS, but not this one. A workshop for this might
> help.
> 
> Folks required to help with these topics:
> 
>   o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
>   o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional dependencies)
>   o Marek Szyprowski <m.szyprowski@samsung.com> (taking on some of
> Rafael's previous work)
>   o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
>   o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
>   o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
> kconfig issues)

I'm interested in part-taking in this, and have a vested interest in
looking at improving what we do in the early boot phase with things like
interrupt controllers and timers that we currently do not represent as
devices (and yet have obvious dependencies on).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

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

[Laurent Pinchart]

Hi Luis,

On Wednesday 27 Jul 2016 09:50:04 Luis R. Rodriguez wrote:
> (first e-mail bounced)
> 
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on
> to help enable asynchronous probe, however for built-in devices this
> requires very specific platform knowledge otherwise using async probe will
> blow up your kernel -- if you get it right though, using async probe can
> help with boot. Even if you sort things out well -- there are current
> limitations with ordering semantics available, case in point the x86 IOMMUs
> already have a small sort run which expand beyond the core init entries
> allowed, and on top of this the you still have device driver dependencies
> which are implicitly setting order via link order: consider the ordering
> between AMD IOMMUv1, AMD IOMMUv2, AMD KFD, and AMD radeon. This has made us
> realize that at the module front the current 2 levels of init calls limits
> our ordering semantics leaving only link order as a last measure when
> things are built-in. Likewise I've recently have had to look into
> dependency issues early in boot been due to differences between
> paravirtualization and non-PV kernels, this lead to some current work to
> help generalize custom section uses (linker tables) and then for us to
> consider expanding x86 semantics early in boot to address some of the
> shortcomings implicit by the some paravirtualized boot path.
> 
> The goal behind Rafael's work's goal is essentially to avoid code
> duplication (as without doing that in the core many drivers potentially
> need to do the same thing in the same way) and help to address the
> asynchronous system suspend/resume case that cannot be addressed by any
> driver by itself anyway. The effort behind Rafael's, Mauro's, Dmitry's and
> my work are all independent however the patterns are very similar:
> addressing complex dependencies and relationships at run time and available
> semantics for these.
> 
> This begs a few questions:
> 
>  o Are there generic issues here ?
>  o Are there generic solutions possible ?
>  o What advanced techniques are out there to deal with this and how
>    are efforts in those domains going ?
> 
> As an example of taste for the last item, consider Vegard Nossum's
> involvement with a SAT solver (picosat) for AFL fuzzing with ext4 on
> built-in kernels -- and the possibility to share some of the tools to
> address some of the dependencies here. As it stands kconfig's semantics are
> a bit of a mess, and in turn often tools have to do a bit of inference work
> due to some of this, part if this problem is one reason why current
> kconfig-sat efforts are a bit stalled.
> 
> Benefits for addressing some of these topics generally has quite a bit of
> uses in different domains:
> 
>   o Speeding up boot time
>   o Avoiding dead code, or correctness
>   o Shrinking kernel size
> 
> This is a pretty generally broad topic, and it does cross subsystems,
> I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
> Mauro, and Rafael in February this year about a LPC microconference
> about this sort of stuff as I thought that would have been a better venue --
> however even early then (February !) it seems they were busy with existing
> LPC microconferences. I recently poked them and they seem to agree
> discussing this somehow at KS would be good. Due to existing time
> constraints at LPC, but given most interested folks may be at KS or
> Plumbers, it'd be good to use shared time at KS and LPC to get folks to
> organize ideas, problems, and solutions and in a more adhoc manner, and
> then enable organically folks interested to organize and discuss short term
> and long term roadmaps on respective work items. Its unclear yet if there
> is a very CORE TOPIC here -- my guess would be that if there were we'd find
> out at the next KS, but not this one. A workshop for this might help.
> 
> Folks required to help with these topics:
> 
>   o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
>   o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional
>     dependencies)
>   o Marek Szyprowski <m.szyprowski@samsung.com> (taking on some
>     of Rafael's previous work)
>   o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)

As the co-author of the media controller code (along with Sakari Ailus, based 
on a draft proposal from Hans Verkuil), I don't think MC will help here. It 
addresses very different problems, its purpose is to expose the topology of 
data flows inside a media device to userspace. The scope has recently been 
expanded slightly to also expose relationships between the hardware blocks and 
the kernel to userspace interfaces used to control them, but that's about it.

We do have a fair share of probe ordering issues with media devices, 
especially in the embedded world where a device is made of many independent 
hardware pieces each represented by a struct device and bound to a driver, but 
MC only kicks in after probe to expose the device topology to userspace (and 
to some extent to control it when routing can be dynamic).

This being said I'd be very interested in discussing asynchronous probing and 
probe ordering. I can also certainly bring media controller knowledge to the 
discussion, but I don't think that part would be very useful (apart possibly 
for saving everybody's time by explaining why MC isn't a solution to address 
those problems :-)). 

>   o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
>   o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
> kconfig issues)

-- 
Regards,

Laurent Pinchart

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

[Luis R. Rodriguez]

On Thu, Jul 28, 2016 at 01:51:02PM +0300, Laurent Pinchart wrote:
> As the co-author of the media controller code (along with Sakari Ailus, based 
> on a draft proposal from Hans Verkuil), I don't think MC will help here. It 
> addresses very different problems, its purpose is to expose the topology of 
> data flows inside a media device to userspace.

This is the key that interest me. Not the exact code -- but how it accomplishes
this and lessons learned.

> This being said I'd be very interested in discussing asynchronous probing and 
> probe ordering. I can also certainly bring media controller knowledge to the 
> discussion, but I don't think that part would be very useful (apart possibly 
> for saving everybody's time by explaining why MC isn't a solution to address 
> those problems :-)). 

Its not that MC would solve the issues, its what lessons were learned on the
way we can re-use. Also, if we can use some bells and whistles for a generic
solution, could the MC leverage off of that? This proposal is of course very
abstract, so bear with me.

  Luis

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

[Laurent Pinchart]

Hi Luis,

On Friday 29 Jul 2016 01:43:14 Luis R. Rodriguez wrote:
> On Thu, Jul 28, 2016 at 01:51:02PM +0300, Laurent Pinchart wrote:
> > As the co-author of the media controller code (along with Sakari Ailus,
> > based on a draft proposal from Hans Verkuil), I don't think MC will help
> > here. It addresses very different problems, its purpose is to expose the
> > topology of data flows inside a media device to userspace.
> 
> This is the key that interest me. Not the exact code -- but how it
> accomplishes this and lessons learned.
> 
> > This being said I'd be very interested in discussing asynchronous probing
> > and probe ordering. I can also certainly bring media controller knowledge
> > to the discussion, but I don't think that part would be very useful
> > (apart possibly for saving everybody's time by explaining why MC isn't a
> > solution to address those problems :-)).
> 
> Its not that MC would solve the issues, its what lessons were learned on the
> way we can re-use. Also, if we can use some bells and whistles for a
> generic solution, could the MC leverage off of that? This proposal is of
> course very abstract, so bear with me.

One problem I expect to have to solve in the future in MC is related to 
locking. We currently have a single graph-wide mutex that serializes all 
operations on the graph. With graphs getting larger (especially with recent 
SoCs that have deep hardware pipelines between camera and display devices, 
making lots of IP cores part of the same data graph) locking contention might 
become an issue. Throw dynamic graph updates in the mix (the ability to add or 
remove nodes as a consequence of device hotplug) and this will call for a 
rework of the locking scheme. Learning from similar experiences elsewhere in 
the kernel would be highly beneficial for us.

-- 
Regards,

Laurent Pinchart

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

[Mauro Carvalho Chehab]

Em Wed, 27 Jul 2016 09:50:04 -0700
"Luis R. Rodriguez" <mcgrof@suse.com> escreveu:

> (first e-mail bounced)
> 
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. 

Actually, there are two separate at the media subsystem:

1) the complex dependencies at the build system, required by the media
devices, as almost all media hardware require multiple drivers in order to
work. The media controller is unrelated to it.

We have right now a very complex Kconfig setup, as we try to map what
user wants (a driver for the board "foo") with the requirements that
such "foo" device requires (e. g. tuner "bar", demod "foobar", 
main driver "foodriver", etc).

2) the complexity of setting up pipelines using the media controller.

The media controller reflects the complexity of the media devices,
showing their internal topology and allowing userspace to dynamically
re-route the pipelines. There are several such pipeline examples,
obtained from real hardware at:
	https://mchehab.fedorapeople.org/mc-next-gen/

Internally, the media controller has a logic to do graph traversal,
in order to setup such pipelines. As the idea is to use SAT for the
build system, eventually we could re-use its code inside the media
controller, in order to improve the media controller logic, if such
code find its way into the Kernel itself.

So, I'm very interested on this topic.

Thanks,
Mauro

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

[Laurent Pinchart]

On Thursday 28 Jul 2016 08:18:08 Mauro Carvalho Chehab wrote:
> Em Wed, 27 Jul 2016 09:50:04 -0700 Luis R. Rodriguez escreveu:
> > (first e-mail bounced)
> > 
> > Rafael has proposed has a set of patches to help deal with functional
> > dependencies between devices to help with power management. Mauro has
> > spoken briefly before over the media controller feature graph used to help
> > build relationship between complex dynamic dependencies.
> 
> Actually, there are two separate at the media subsystem:
> 
> 1) the complex dependencies at the build system, required by the media
> devices, as almost all media hardware require multiple drivers in order to
> work. The media controller is unrelated to it.
> 
> We have right now a very complex Kconfig setup, as we try to map what
> user wants (a driver for the board "foo") with the requirements that
> such "foo" device requires (e. g. tuner "bar", demod "foobar",
> main driver "foodriver", etc).
> 
> 2) the complexity of setting up pipelines using the media controller.
> 
> The media controller reflects the complexity of the media devices,
> showing their internal topology and allowing userspace to dynamically
> re-route the pipelines. There are several such pipeline examples,
> obtained from real hardware at:
> 	https://mchehab.fedorapeople.org/mc-next-gen/
> 
> Internally, the media controller has a logic to do graph traversal,
> in order to setup such pipelines. As the idea is to use SAT for the
> build system, eventually we could re-use its code inside the media
> controller, in order to improve the media controller logic, if such
> code find its way into the Kernel itself.

I'm not sure to follow you there. How would an SAT solver help the media 
controller ?

> So, I'm very interested on this topic.

-- 
Regards,

Laurent Pinchart

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

[Mauro Carvalho Chehab]

Em Thu, 28 Jul 2016 14:24:49 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> On Thursday 28 Jul 2016 08:18:08 Mauro Carvalho Chehab wrote:
> > Em Wed, 27 Jul 2016 09:50:04 -0700 Luis R. Rodriguez escreveu:  
> > > (first e-mail bounced)
> > > 
> > > Rafael has proposed has a set of patches to help deal with functional
> > > dependencies between devices to help with power management. Mauro has
> > > spoken briefly before over the media controller feature graph used to help
> > > build relationship between complex dynamic dependencies.  
> > 
> > Actually, there are two separate at the media subsystem:
> > 
> > 1) the complex dependencies at the build system, required by the media
> > devices, as almost all media hardware require multiple drivers in order to
> > work. The media controller is unrelated to it.
> > 
> > We have right now a very complex Kconfig setup, as we try to map what
> > user wants (a driver for the board "foo") with the requirements that
> > such "foo" device requires (e. g. tuner "bar", demod "foobar",
> > main driver "foodriver", etc).
> > 
> > 2) the complexity of setting up pipelines using the media controller.
> > 
> > The media controller reflects the complexity of the media devices,
> > showing their internal topology and allowing userspace to dynamically
> > re-route the pipelines. There are several such pipeline examples,
> > obtained from real hardware at:
> > 	https://mchehab.fedorapeople.org/mc-next-gen/
> > 
> > Internally, the media controller has a logic to do graph traversal,
> > in order to setup such pipelines. As the idea is to use SAT for the
> > build system, eventually we could re-use its code inside the media
> > controller, in order to improve the media controller logic, if such
> > code find its way into the Kernel itself.  
> 
> I'm not sure to follow you there. How would an SAT solver help the media 
> controller ?

As you know, there are two types or V4L2 devices. Let me enumerate them
to help the others to follow the discussions.

The vast majority of the V4L2 devices use only the /dev/video?,
/dev/radio? /dev/vbi? device drivers to provide userspace interface.
On such devices, the hardware pipelines are dynamically created by the
Kernel. Let's call them as "device-centric" device drivers.

The V4L2 drivers meant for embedded usage typically also provide a
per-subdevice device node, via the V4L2 sub-device API extension:
	https://linuxtv.org/downloads/v4l-dvb-apis-new/media/uapi/v4l/dev-subdev.html
Also, on such drivers, the pipelines are explicitly created via userspace.
Let's call them as "media-controller-centric" device drivers.

Right now, all DVB devices are also device-centric, as we don't have
yet any sub-device API, and the DVB API currently assumes dynamic
pipeline setup.

It should also be said that the generic media applications (xawtv,
tvtime, kaffeine, MythTV, camorama, Skype, etc) assume that the pipelines
will be set automatically by the Kernel. We currently lack a generic
application that would automatically setup the required pipelines
that would work for all media-controller-centric devices,
as the pipeline settings are device-specific.

For the device-centric media devices, the pipelines should be created by
the Kernel, and not via userspace. On such cases, a SAT solver could help
to setup the hardware pipelines.

> 
> > So, I'm very interested on this topic.  
> 


-- 
Thanks,
Mauro

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

[Laurent Pinchart]

Hi Mauro,

On Thursday 28 Jul 2016 09:25:58 Mauro Carvalho Chehab wrote:
> Em Thu, 28 Jul 2016 14:24:49 +0300 Laurent Pinchart escreveu:
> > On Thursday 28 Jul 2016 08:18:08 Mauro Carvalho Chehab wrote:
> > > Em Wed, 27 Jul 2016 09:50:04 -0700 Luis R. Rodriguez escreveu:
> > > > (first e-mail bounced)
> > > > 
> > > > Rafael has proposed has a set of patches to help deal with functional
> > > > dependencies between devices to help with power management. Mauro has
> > > > spoken briefly before over the media controller feature graph used to
> > > > help build relationship between complex dynamic dependencies.
> > > 
> > > Actually, there are two separate at the media subsystem:
> > > 
> > > 1) the complex dependencies at the build system, required by the media
> > > devices, as almost all media hardware require multiple drivers in order
> > > to work. The media controller is unrelated to it.
> > > 
> > > We have right now a very complex Kconfig setup, as we try to map what
> > > user wants (a driver for the board "foo") with the requirements that
> > > such "foo" device requires (e. g. tuner "bar", demod "foobar",
> > > main driver "foodriver", etc).
> > > 
> > > 2) the complexity of setting up pipelines using the media controller.
> > > 
> > > The media controller reflects the complexity of the media devices,
> > > showing their internal topology and allowing userspace to dynamically
> > > re-route the pipelines. There are several such pipeline examples,
> > > 
> > > obtained from real hardware at:
> > > 	https://mchehab.fedorapeople.org/mc-next-gen/
> > > 
> > > Internally, the media controller has a logic to do graph traversal,
> > > in order to setup such pipelines. As the idea is to use SAT for the
> > > build system, eventually we could re-use its code inside the media
> > > controller, in order to improve the media controller logic, if such
> > > code find its way into the Kernel itself.
> > 
> > I'm not sure to follow you there. How would an SAT solver help the media
> > controller ?
> 
> As you know, there are two types or V4L2 devices. Let me enumerate them
> to help the others to follow the discussions.
> 
> The vast majority of the V4L2 devices use only the /dev/video?,
> /dev/radio? /dev/vbi? device drivers to provide userspace interface.
> On such devices, the hardware pipelines are dynamically created by the
> Kernel. Let's call them as "device-centric" device drivers.
> 
> The V4L2 drivers meant for embedded usage typically also provide a
> per-subdevice device node, via the V4L2 sub-device API extension:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/uapi/v4l/dev-> subdev.html
> Also, on such drivers, the pipelines are explicitly created via
> userspace. Let's call them as "media-controller-centric" device drivers.

Nitpicking, the pipelines are not created by userspace, they're controlled by 
userspace. I think we agree on this, it's just a matter of terminology.

> Right now, all DVB devices are also device-centric, as we don't have
> yet any sub-device API, and the DVB API currently assumes dynamic
> pipeline setup.
> 
> It should also be said that the generic media applications (xawtv,
> tvtime, kaffeine, MythTV, camorama, Skype, etc) assume that the pipelines
> will be set automatically by the Kernel. We currently lack a generic
> application that would automatically setup the required pipelines
> that would work for all media-controller-centric devices,
> as the pipeline settings are device-specific.
> 
> For the device-centric media devices, the pipelines should be created by
> the Kernel, and not via userspace. On such cases, a SAT solver could help
> to setup the hardware pipelines.

That's the part I don't get. How is SAT related to that ?

> > > So, I'm very interested on this topic.

-- 
Regards,

Laurent Pinchart

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

[Luis R. Rodriguez]

On Thu, Jul 28, 2016 at 07:04:49PM +0300, Laurent Pinchart wrote:
> On Thursday 28 Jul 2016 09:25:58 Mauro Carvalho Chehab wrote:
> > 
> > For the device-centric media devices, the pipelines should be created by
> > the Kernel, and not via userspace. On such cases, a SAT solver could help
> > to setup the hardware pipelines.
> 
> That's the part I don't get. How is SAT related to that ?

Provided you have figured out how to generalize how describe items and
dependencies, you should be able to use a SAT solver to find optimal dependency
maps.  For instance SAT solvers have been used in challenges to help address
Linux distribution package dependency issues, helping improve the not only if a
request is satisfiable but also help with the most optimal solution.

A SAT solver therefore in theory could be used to help optimal dependency maps
as well for other things, which are kernel-related. For instance we'll baby
step testing this with kconfig [0], if that proves useful we'll have to find
timing / limitations, but it should at least give us a lower order resolution
time, and depending on your requirements it may suffice for some needs.
Furthermore, say you were not time constrained (linker or compiler) and could
order things in code prior to execution, you could sort things out pre-runtime
for a few situations.

This naturally then varies depending on the problem at hand. I've jotted down a
few ideas on the wiki but its really all just scrapbook notes at this point [1]
with an eye towards the long term here, and projecting work on kconfig gets
done.

[0] https://kernelnewbies.org/KernelProjects/kconfig-sat
[1] https://kernelnewbies.org/KernelProjects/linux-sat

  Luis

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

[Laurent Pinchart]

Hi Luis,

On Friday 29 Jul 2016 02:00:55 Luis R. Rodriguez wrote:
> On Thu, Jul 28, 2016 at 07:04:49PM +0300, Laurent Pinchart wrote:
> > On Thursday 28 Jul 2016 09:25:58 Mauro Carvalho Chehab wrote:
> >> For the device-centric media devices, the pipelines should be created by
> >> the Kernel, and not via userspace. On such cases, a SAT solver could
> >> help to setup the hardware pipelines.
> > 
> > That's the part I don't get. How is SAT related to that ?
> 
> Provided you have figured out how to generalize how describe items and
> dependencies, you should be able to use a SAT solver to find optimal
> dependency maps.  For instance SAT solvers have been used in challenges to
> help address Linux distribution package dependency issues, helping improve
> the not only if a request is satisfiable but also help with the most
> optimal solution.

Thanks for the clarification, this matches my understanding. My question 
originated from the fact the we don't really have dependency problems to solve 
in MC, at least in kernelspace. While I can't rule out a change in the future 
there, at the moment our dependency issues in V4L2 are related to probe 
ordering and suspend/resume (and to some extent to device removal, but that 
has been a second-class citizen so far). Improvements there would be welcome, 
but that's unrelated to MC.

The various directions in which this discussion is going leads me to believe 
that the topic would be good to discuss during the Kernel Summit, if only to 
get everybody aware of related developments happening through the kernel and 
foster collaboration in those areas.

> A SAT solver therefore in theory could be used to help optimal dependency
> maps as well for other things, which are kernel-related. For instance we'll
> baby step testing this with kconfig [0], if that proves useful we'll have
> to find timing / limitations, but it should at least give us a lower order
> resolution time, and depending on your requirements it may suffice for some
> needs. Furthermore, say you were not time constrained (linker or compiler)
> and could order things in code prior to execution, you could sort things
> out pre-runtime for a few situations.
> 
> This naturally then varies depending on the problem at hand. I've jotted
> down a few ideas on the wiki but its really all just scrapbook notes at
> this point [1] with an eye towards the long term here, and projecting work
> on kconfig gets done.
> 
> [0] https://kernelnewbies.org/KernelProjects/kconfig-sat
> [1] https://kernelnewbies.org/KernelProjects/linux-sat

-- 
Regards,

Laurent Pinchart

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

[Luis R. Rodriguez]

On Mon, Aug 01, 2016 at 03:50:37PM +0300, Laurent Pinchart wrote:
> Hi Luis,
> 
> On Friday 29 Jul 2016 02:00:55 Luis R. Rodriguez wrote:
> > On Thu, Jul 28, 2016 at 07:04:49PM +0300, Laurent Pinchart wrote:
> > > On Thursday 28 Jul 2016 09:25:58 Mauro Carvalho Chehab wrote:
> > >> For the device-centric media devices, the pipelines should be created by
> > >> the Kernel, and not via userspace. On such cases, a SAT solver could
> > >> help to setup the hardware pipelines.
> > > 
> > > That's the part I don't get. How is SAT related to that ?
> > 
> > Provided you have figured out how to generalize how describe items and
> > dependencies, you should be able to use a SAT solver to find optimal
> > dependency maps.  For instance SAT solvers have been used in challenges to
> > help address Linux distribution package dependency issues, helping improve
> > the not only if a request is satisfiable but also help with the most
> > optimal solution.
> 
> Thanks for the clarification, this matches my understanding. My question 
> originated from the fact the we don't really have dependency problems to solve 
> in MC, at least in kernelspace.

If I understood what Mauro was explaining correctly, it would seems that in
future this may change and that kernel dependency resolution may be a thing
to address in the future. Is this correct ?

Even so -- if you have a dependency problem in userspace and have a solution
for it I'd like to take time for this session to understand it and see what
further optimizations might be possible. Since its in userspace it may
in fact be easier to toy with certain test concepts faster and more easily.

> While I can't rule out a change in the future 
> there, at the moment our dependency issues in V4L2 are related to probe 
> ordering and suspend/resume (and to some extent to device removal, but that 
> has been a second-class citizen so far). Improvements there would be welcome, 
> but that's unrelated to MC.

OK so what you describe here is the dependency issues with respect to the
kernel only, is that right ?

> The various directions in which this discussion is going leads me to believe 
> that the topic would be good to discuss during the Kernel Summit, if only to 
> get everybody aware of related developments happening through the kernel and 
> foster collaboration in those areas.

Great.

  Luis

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

[Andrzej Hajda]

On 07/27/2016 06:50 PM, Luis R. Rodriguez wrote:
> (first e-mail bounced)
>
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on
> to help enable asynchronous probe, however for built-in devices this requires
> very specific platform knowledge otherwise using async probe will blow up
> your kernel -- if you get it right though, using async probe can help with
> boot. Even if you sort things out well -- there are current limitations with
> ordering semantics available, case in point the x86 IOMMUs already have a small
> sort run which expand beyond the core init entries allowed, and on top of this
> the you still have device driver dependencies which are implicitly setting
> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
> AMD KFD, and AMD radeon. This has made us realize that at the module front the
> current 2 levels of init calls limits our ordering semantics leaving only link
> order as a last measure when things are built-in. Likewise I've recently have
> had to look into dependency issues early in boot been due to differences
> between paravirtualization and non-PV kernels, this lead to some current work
> to help generalize custom section uses (linker tables) and then for us to
> consider expanding x86 semantics early in boot to address some of the
> shortcomings implicit by the some paravirtualized boot path.
>
> The goal behind Rafael's work's goal is essentially to avoid code duplication
> (as without doing that in the core many drivers potentially need to do the same
> thing in the same way) and help to address the asynchronous system
> suspend/resume case that cannot be addressed by any driver by itself anyway.
> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
> however the patterns are very similar: addressing complex dependencies and
> relationships at run time and available semantics for these.

I am also interested in this  topic. I have sent some times ago few
early RFCs
proposing solution for 'resource' life-time tracking:
In short it allows to:
- eliminate deferred probe and resulting late_initcall - consumer just
registers
callback informing when given resource(s) (clock, regulator, ...) becomes
available/unavailable,
- properly handle resource disappearance (due to driver unbind, hw
removal,...),
- track resources which are not vital to the device, but their presence
can influence
device's behavior,
- as a bonus it offers simplified resource allocation,

More info can be found on LWN [1].

The framework can be easily expanded to help with power management, as I
proposed in
Rafael's thread[2].

[1]: https://lwn.net/Articles/625454/
[2]: http://permalink.gmane.org/gmane.linux.kernel/2087152

Regards
Andrzej

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

[Kevin Hilman]

Andrzej Hajda <a.hajda@samsung.com> writes:

> On 07/27/2016 06:50 PM, Luis R. Rodriguez wrote:
>> (first e-mail bounced)
>>
>> Rafael has proposed has a set of patches to help deal with functional
>> dependencies between devices to help with power management. Mauro has
>> spoken briefly before over the media controller feature graph used to help
>> build relationship between complex dynamic dependencies. Dmitry has taken on
>> to help enable asynchronous probe, however for built-in devices this requires
>> very specific platform knowledge otherwise using async probe will blow up
>> your kernel -- if you get it right though, using async probe can help with
>> boot. Even if you sort things out well -- there are current limitations with
>> ordering semantics available, case in point the x86 IOMMUs already have a small
>> sort run which expand beyond the core init entries allowed, and on top of this
>> the you still have device driver dependencies which are implicitly setting
>> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
>> AMD KFD, and AMD radeon. This has made us realize that at the module front the
>> current 2 levels of init calls limits our ordering semantics leaving only link
>> order as a last measure when things are built-in. Likewise I've recently have
>> had to look into dependency issues early in boot been due to differences
>> between paravirtualization and non-PV kernels, this lead to some current work
>> to help generalize custom section uses (linker tables) and then for us to
>> consider expanding x86 semantics early in boot to address some of the
>> shortcomings implicit by the some paravirtualized boot path.
>>
>> The goal behind Rafael's work's goal is essentially to avoid code duplication
>> (as without doing that in the core many drivers potentially need to do the same
>> thing in the same way) and help to address the asynchronous system
>> suspend/resume case that cannot be addressed by any driver by itself anyway.
>> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
>> however the patterns are very similar: addressing complex dependencies and
>> relationships at run time and available semantics for these.
>
> I am also interested in this topic. I have sent some times ago few
> early RFCs proposing solution for 'resource' life-time tracking:

[...]

> The framework can be easily expanded to help with power management

[sorry to be late to the party, catching up on this after some holidays]

I'm also interested in the PM / performance aspects of this topic.

Specifically, I'm working on QoS/performance/PM issues where we need a
way to "link" one device to another, where that link also includes any
busses, IOMMUs etc. that are on the path between the two endpoints.

Because the busses involved have dynamic voltage and frequency scaling
(DVFS) capabilities, the goal is to have dynamic QoS for the whole
link/path so that the busses on that path can aggregate QoS requirements
and do DVFS in order to meet the bandwidth/throughput requirements, but
also to scale back when performance is not needed to save power.

We can do much of this today using per-device pm_qos and runtime
PM/genpd for individual devices, but I'm looking for a way to do similar
for a "path" that has 2 endpoint devices, and some busses in between,
especially when these paths are not represented in the parent-child
relationships.

I had a brief look at Rafael's and your patches, but I need to look
closer at them to see if/how they might be used for this.

Kevin

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

[Marek Szyprowski]

Dear All,


On 2016-07-27 18:50, Luis R. Rodriguez wrote:
> (first e-mail bounced)
>
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on
> to help enable asynchronous probe, however for built-in devices this requires
> very specific platform knowledge otherwise using async probe will blow up
> your kernel -- if you get it right though, using async probe can help with
> boot. Even if you sort things out well -- there are current limitations with
> ordering semantics available, case in point the x86 IOMMUs already have a small
> sort run which expand beyond the core init entries allowed, and on top of this
> the you still have device driver dependencies which are implicitly setting
> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
> AMD KFD, and AMD radeon. This has made us realize that at the module front the
> current 2 levels of init calls limits our ordering semantics leaving only link
> order as a last measure when things are built-in. Likewise I've recently have
> had to look into dependency issues early in boot been due to differences
> between paravirtualization and non-PV kernels, this lead to some current work
> to help generalize custom section uses (linker tables) and then for us to
> consider expanding x86 semantics early in boot to address some of the
> shortcomings implicit by the some paravirtualized boot path.
>
> The goal behind Rafael's work's goal is essentially to avoid code duplication
> (as without doing that in the core many drivers potentially need to do the same
> thing in the same way) and help to address the asynchronous system
> suspend/resume case that cannot be addressed by any driver by itself anyway.
> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
> however the patterns are very similar: addressing complex dependencies and
> relationships at run time and available semantics for these.
>
> This begs a few questions:
>
>   o Are there generic issues here ?
>   o Are there generic solutions possible ?
>   o What advanced techniques are out there to deal with this and how
>     are efforts in those domains going ?
>
> As an example of taste for the last item, consider Vegard Nossum's involvement
> with a SAT solver (picosat) for AFL fuzzing with ext4 on built-in kernels --
> and the possibility to share some of the tools to address some of the
> dependencies here. As it stands kconfig's semantics are a bit of a mess, and
> in turn often tools have to do a bit of inference work due to some of this,
> part if this problem is one reason why current kconfig-sat efforts are a bit
> stalled.
>
> Benefits for addressing some of these topics generally has quite a bit of
> uses in different domains:
>
>    o Speeding up boot time
>    o Avoiding dead code, or correctness
>    o Shrinking kernel size
>
> This is a pretty generally broad topic, and it does cross subsystems,
> I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
> Mauro, and Rafael in February this year about a LPC microconference
> about this sort of stuff as I thought that would have been a better venue --
> however even early then (February !) it seems they were busy with existing LPC
> microconferences. I recently poked them and they seem to agree discussing this
> somehow at KS would be good. Due to existing time constraints at LPC, but given
> most interested folks may be at KS or Plumbers, it'd be good to use shared time
> at KS and LPC to get folks to organize ideas, problems, and solutions and in a
> more adhoc manner, and then enable organically folks interested to organize and
> discuss short term and long term roadmaps on respective work items. Its unclear
> yet if there is a very CORE TOPIC here -- my guess would be that if there were
> we'd find out at the next KS, but not this one. A workshop for this might
> help.
>
> Folks required to help with these topics:
>
>    o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
>    o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional dependencies)
>    o Marek Szyprowski <m.szyprowski@samsung.com> (taking on some of
> Rafael's previous work)
>    o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
>    o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
>    o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
> kconfig issues)

I really wonder if all those 3 topics I identified are really connected 
enough to
be discussed together. I see the following topics:
1. functional dependencies between devices in pm and runtime pm
2. the device probe order (and how to avoid deferred probe)
3. SAT solver for Kconfig and others

Rafaels patches (which I already used for solving the problem of runtime 
pm for
Exynos IOMMU) are just providing infrastructure to create dependencies 
for power
management (both for system/resume and runtime pm). They don't solve any 
probe
dependencies and all devices, which are a part of the dependency have to
explicitly register for it. I would like to help resolving all the 
issues with
those patches and get them merged, because they implement a feature that we
had to workaround in the internal trees for at least last 3 years.

Solving probe order problem might use the dependency links 
infrastructure, but
I still don't get why we would need to have SAT solver for it.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

[Laurent Pinchart]

Hi Marek,

On Monday 01 Aug 2016 16:03:42 Marek Szyprowski wrote:
> On 2016-07-27 18:50, Luis R. Rodriguez wrote:
> > (first e-mail bounced)
> > 
> > Rafael has proposed has a set of patches to help deal with functional
> > dependencies between devices to help with power management. Mauro has
> > spoken briefly before over the media controller feature graph used to help
> > build relationship between complex dynamic dependencies. Dmitry has taken
> > on to help enable asynchronous probe, however for built-in devices this
> > requires very specific platform knowledge otherwise using async probe
> > will blow up your kernel -- if you get it right though, using async probe
> > can help with boot. Even if you sort things out well -- there are current
> > limitations with ordering semantics available, case in point the x86
> > IOMMUs already have a small sort run which expand beyond the core init
> > entries allowed, and on top of this the you still have device driver
> > dependencies which are implicitly setting order via link order: consider
> > the ordering between AMD IOMMUv1, AMD IOMMUv2, AMD KFD, and AMD radeon.
> > This has made us realize that at the module front the current 2 levels of
> > init calls limits our ordering semantics leaving only link order as a
> > last measure when things are built-in. Likewise I've recently have had to
> > look into dependency issues early in boot been due to differences between
> > paravirtualization and non-PV kernels, this lead to some current work to
> > help generalize custom section uses (linker tables) and then for us to
> > consider expanding x86 semantics early in boot to address some of the
> > shortcomings implicit by the some paravirtualized boot path.
> > 
> > The goal behind Rafael's work's goal is essentially to avoid code
> > duplication (as without doing that in the core many drivers potentially
> > need to do the same thing in the same way) and help to address the
> > asynchronous system suspend/resume case that cannot be addressed by any
> > driver by itself anyway. The effort behind Rafael's, Mauro's, Dmitry's
> > and my work are all independent however the patterns are very similar:
> > addressing complex dependencies and relationships at run time and
> > available semantics for these.
> > 
> > This begs a few questions:
> >   o Are there generic issues here ?
> >   o Are there generic solutions possible ?
> >   o What advanced techniques are out there to deal with this and how
> >   
> >     are efforts in those domains going ?
> > 
> > As an example of taste for the last item, consider Vegard Nossum's
> > involvement with a SAT solver (picosat) for AFL fuzzing with ext4 on
> > built-in kernels -- and the possibility to share some of the tools to
> > address some of the dependencies here. As it stands kconfig's semantics
> > are a bit of a mess, and in turn often tools have to do a bit of
> > inference work due to some of this, part if this problem is one reason
> > why current kconfig-sat efforts are a bit stalled.
> > 
> > Benefits for addressing some of these topics generally has quite a bit of
> > 
> > uses in different domains:
> >    o Speeding up boot time
> >    o Avoiding dead code, or correctness
> >    o Shrinking kernel size
> > 
> > This is a pretty generally broad topic, and it does cross subsystems,
> > I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
> > Mauro, and Rafael in February this year about a LPC microconference
> > about this sort of stuff as I thought that would have been a better venue
> > -- however even early then (February !) it seems they were busy with
> > existing LPC microconferences. I recently poked them and they seem to
> > agree discussing this somehow at KS would be good. Due to existing time
> > constraints at LPC, but given most interested folks may be at KS or
> > Plumbers, it'd be good to use shared time at KS and LPC to get folks to
> > organize ideas, problems, and solutions and in a more adhoc manner, and
> > then enable organically folks interested to organize and discuss short
> > term and long term roadmaps on respective work items. Its unclear yet if
> > there is a very CORE TOPIC here -- my guess would be that if there were
> > we'd find out at the next KS, but not this one. A workshop for this might
> > help.
> > 
> > Folks required to help with these topics:
> >    o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
> >    o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional
> >    dependencies) o Marek Szyprowski <m.szyprowski@samsung.com> (taking on
> >    some of
> > 
> > Rafael's previous work)
> > 
> >    o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
> >    o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
> >    o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
> > 
> > kconfig issues)
> 
> I really wonder if all those 3 topics I identified are really connected
> enough to be discussed together. I see the following topics:
> 1. functional dependencies between devices in pm and runtime pm
> 2. the device probe order (and how to avoid deferred probe)
> 3. SAT solver for Kconfig and others
> 
> Rafaels patches (which I already used for solving the problem of runtime
> pm for Exynos IOMMU)

Rafael's patches don't address creation of the dependencies. One 
straightforward solution for this problem is to manually create them in driver 
code. This isn't well suited for dependencies on IOMMUs though, as IOMMUs are 
often handled transparently in the DMA mapping implementation and drivers are 
not supposed to care about them. Could you briefly explain how you solve that 
in the Exynos case ?

> are just providing infrastructure to create dependencies for power
> management (both for system/resume and runtime pm). They don't solve any
> probe dependencies and all devices, which are a part of the dependency have
> to explicitly register for it. I would like to help resolving all the
> issues with those patches and get them merged, because they implement a
> feature that we had to workaround in the internal trees for at least last 3
> years.
> 
> Solving probe order problem might use the dependency links infrastructure,
> but I still don't get why we would need to have SAT solver for it.

-- 
Regards,

Laurent Pinchart

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

[Marek Szyprowski]

Hi Laurent


On 2016-11-03 19:43, Laurent Pinchart wrote:
> On Monday 01 Aug 2016 16:03:42 Marek Szyprowski wrote:
>> On 2016-07-27 18:50, Luis R. Rodriguez wrote:
>>> (first e-mail bounced)
>>>
>>> Rafael has proposed has a set of patches to help deal with functional
>>> dependencies between devices to help with power management. Mauro has
>>> spoken briefly before over the media controller feature graph used to help
>>> build relationship between complex dynamic dependencies. Dmitry has taken
>>> on to help enable asynchronous probe, however for built-in devices this
>>> requires very specific platform knowledge otherwise using async probe
>>> will blow up your kernel -- if you get it right though, using async probe
>>> can help with boot. Even if you sort things out well -- there are current
>>> limitations with ordering semantics available, case in point the x86
>>> IOMMUs already have a small sort run which expand beyond the core init
>>> entries allowed, and on top of this the you still have device driver
>>> dependencies which are implicitly setting order via link order: consider
>>> the ordering between AMD IOMMUv1, AMD IOMMUv2, AMD KFD, and AMD radeon.
>>> This has made us realize that at the module front the current 2 levels of
>>> init calls limits our ordering semantics leaving only link order as a
>>> last measure when things are built-in. Likewise I've recently have had to
>>> look into dependency issues early in boot been due to differences between
>>> paravirtualization and non-PV kernels, this lead to some current work to
>>> help generalize custom section uses (linker tables) and then for us to
>>> consider expanding x86 semantics early in boot to address some of the
>>> shortcomings implicit by the some paravirtualized boot path.
>>>
>>> The goal behind Rafael's work's goal is essentially to avoid code
>>> duplication (as without doing that in the core many drivers potentially
>>> need to do the same thing in the same way) and help to address the
>>> asynchronous system suspend/resume case that cannot be addressed by any
>>> driver by itself anyway. The effort behind Rafael's, Mauro's, Dmitry's
>>> and my work are all independent however the patterns are very similar:
>>> addressing complex dependencies and relationships at run time and
>>> available semantics for these.
>>>
>>> This begs a few questions:
>>>    o Are there generic issues here ?
>>>    o Are there generic solutions possible ?
>>>    o What advanced techniques are out there to deal with this and how
>>>    
>>>      are efforts in those domains going ?
>>>
>>> As an example of taste for the last item, consider Vegard Nossum's
>>> involvement with a SAT solver (picosat) for AFL fuzzing with ext4 on
>>> built-in kernels -- and the possibility to share some of the tools to
>>> address some of the dependencies here. As it stands kconfig's semantics
>>> are a bit of a mess, and in turn often tools have to do a bit of
>>> inference work due to some of this, part if this problem is one reason
>>> why current kconfig-sat efforts are a bit stalled.
>>>
>>> Benefits for addressing some of these topics generally has quite a bit of
>>>
>>> uses in different domains:
>>>     o Speeding up boot time
>>>     o Avoiding dead code, or correctness
>>>     o Shrinking kernel size
>>>
>>> This is a pretty generally broad topic, and it does cross subsystems,
>>> I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
>>> Mauro, and Rafael in February this year about a LPC microconference
>>> about this sort of stuff as I thought that would have been a better venue
>>> -- however even early then (February !) it seems they were busy with
>>> existing LPC microconferences. I recently poked them and they seem to
>>> agree discussing this somehow at KS would be good. Due to existing time
>>> constraints at LPC, but given most interested folks may be at KS or
>>> Plumbers, it'd be good to use shared time at KS and LPC to get folks to
>>> organize ideas, problems, and solutions and in a more adhoc manner, and
>>> then enable organically folks interested to organize and discuss short
>>> term and long term roadmaps on respective work items. Its unclear yet if
>>> there is a very CORE TOPIC here -- my guess would be that if there were
>>> we'd find out at the next KS, but not this one. A workshop for this might
>>> help.
>>>
>>> Folks required to help with these topics:
>>>     o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
>>>     o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional
>>>     dependencies) o Marek Szyprowski <m.szyprowski@samsung.com> (taking on
>>>     some of
>>>
>>> Rafael's previous work)
>>>
>>>     o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
>>>     o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
>>>     o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
>>>
>>> kconfig issues)
>> I really wonder if all those 3 topics I identified are really connected
>> enough to be discussed together. I see the following topics:
>> 1. functional dependencies between devices in pm and runtime pm
>> 2. the device probe order (and how to avoid deferred probe)
>> 3. SAT solver for Kconfig and others
>>
>> Rafaels patches (which I already used for solving the problem of runtime
>> pm for Exynos IOMMU)
> Rafael's patches don't address creation of the dependencies. One
> straightforward solution for this problem is to manually create them in driver
> code. This isn't well suited for dependencies on IOMMUs though, as IOMMUs are
> often handled transparently in the DMA mapping implementation and drivers are
> not supposed to care about them. Could you briefly explain how you solve that
> in the Exynos case ?

I just create links on the IOMMU initialization (in of_xlate callback, 
because
add_device called too late on arm), so links are already created when master
device (the one for which IOMMU does its job) is being probed. Please 
note that
links can be created for devices even when no drivers has been bound yet to
them.

Just take a look at my Exynos IOMMU runtime PM patches:
https://git.linaro.org/people/marek.szyprowski/linux-srpol.git/commit/?h=v4.9-iommu-pm-v5
https://patchwork.kernel.org/patch/9386073/
https://lkml.org/lkml/2016/10/20/70
(sadly, for unknown reason those patches were not indexed by lkml or 
spinics).

[....]

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

[Frank Rowand]

On 07/27/16 09:50, Luis R. Rodriguez wrote:
> (first e-mail bounced)
> 
> Rafael has proposed has a set of patches to help deal with functional
> dependencies between devices to help with power management. Mauro has
> spoken briefly before over the media controller feature graph used to help
> build relationship between complex dynamic dependencies. Dmitry has taken on
> to help enable asynchronous probe, however for built-in devices this requires
> very specific platform knowledge otherwise using async probe will blow up
> your kernel -- if you get it right though, using async probe can help with
> boot. Even if you sort things out well -- there are current limitations with
> ordering semantics available, case in point the x86 IOMMUs already have a small
> sort run which expand beyond the core init entries allowed, and on top of this
> the you still have device driver dependencies which are implicitly setting
> order via link order: consider the ordering between AMD IOMMUv1, AMD IOMMUv2,
> AMD KFD, and AMD radeon. This has made us realize that at the module front the
> current 2 levels of init calls limits our ordering semantics leaving only link
> order as a last measure when things are built-in. Likewise I've recently have
> had to look into dependency issues early in boot been due to differences
> between paravirtualization and non-PV kernels, this lead to some current work
> to help generalize custom section uses (linker tables) and then for us to
> consider expanding x86 semantics early in boot to address some of the
> shortcomings implicit by the some paravirtualized boot path.
> 
> The goal behind Rafael's work's goal is essentially to avoid code duplication
> (as without doing that in the core many drivers potentially need to do the same
> thing in the same way) and help to address the asynchronous system
> suspend/resume case that cannot be addressed by any driver by itself anyway.
> The effort behind Rafael's, Mauro's, Dmitry's and my work are all independent
> however the patterns are very similar: addressing complex dependencies and
> relationships at run time and available semantics for these.
> 
> This begs a few questions:
> 
>  o Are there generic issues here ?
>  o Are there generic solutions possible ?
>  o What advanced techniques are out there to deal with this and how
>    are efforts in those domains going ?
> 
> As an example of taste for the last item, consider Vegard Nossum's involvement
> with a SAT solver (picosat) for AFL fuzzing with ext4 on built-in kernels --
> and the possibility to share some of the tools to address some of the
> dependencies here. As it stands kconfig's semantics are a bit of a mess, and
> in turn often tools have to do a bit of inference work due to some of this,
> part if this problem is one reason why current kconfig-sat efforts are a bit
> stalled.
> 
> Benefits for addressing some of these topics generally has quite a bit of
> uses in different domains:
> 
>   o Speeding up boot time
>   o Avoiding dead code, or correctness
>   o Shrinking kernel size
> 
> This is a pretty generally broad topic, and it does cross subsystems,
> I'm proposing it as a TECH TOPIC given that I had already poked Dmitry,
> Mauro, and Rafael in February this year about a LPC microconference
> about this sort of stuff as I thought that would have been a better venue --
> however even early then (February !) it seems they were busy with existing LPC
> microconferences. I recently poked them and they seem to agree discussing this
> somehow at KS would be good. Due to existing time constraints at LPC, but given
> most interested folks may be at KS or Plumbers, it'd be good to use shared time
> at KS and LPC to get folks to organize ideas, problems, and solutions and in a
> more adhoc manner, and then enable organically folks interested to organize and
> discuss short term and long term roadmaps on respective work items. Its unclear
> yet if there is a very CORE TOPIC here -- my guess would be that if there were
> we'd find out at the next KS, but not this one. A workshop for this might
> help.
> 
> Folks required to help with these topics:
> 
>   o Dmitry Torokhov <dmitry.torokhov@gmail.com> (async probe)
>   o "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> (functional dependencies)
>   o Marek Szyprowski <m.szyprowski@samsung.com> (taking on some of
> Rafael's previous work)
>   o Mauro Carvalho Chehab <mchehab@osg.samsung.com> (feature graph)
>   o Vegard Nossum <vegard.nossum@gmail.com> (SAT)
>   o Valentin Rothberg <valentinrothberg@gmail.com>  (wary of some
> kconfig issues)

I am also interested in this topic since Device Tree seems to often get
dragged into this topic.

I have not requested an invitation to the kernel summit, but I will be in
town and available all week since I will be at Plumbers.

-Frank Rowand