Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote: > On Tue, 20 Oct 2015, Mark Brown wrote: > > > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > > > Furthermore, that applies only to devices that use synchronous suspend. > > > Async suspend is becoming common, and there the only restrictions are > > > parent-child relations plus whatever explicit requirements that drivers > > > impose by calling device_pm_wait_for_dev(). > > > > Hrm, this is the first I'd noticed that feature though I see the initial > > commit dates from January. > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > not 2015! > > > It looks like most of the users are PCs at > > the minute but we should be using it more widely for embedded things, > > there's definitely some cases I'm aware of where it will allow us to > > remove some open coding. > > > > It does seem like we want to be feeding dependency information we > > discover for probing way into the suspend dependencies... > > Rafael has been thinking about a way to do this systematically. > Nothing concrete has emerged yet. Well, good point. :-) I've been kind of struggling with finding time to work on the patches lately and some aspects of the design are still not finalized. It seems, though, that it can be beneficial to discuss the approach in general, so let me start a new thread for that. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing >> >> here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. Do you mean the kernel link time or something else? At least in some cases the dependency information won't be known at that time, so we need a way to record a dependency at the time it becomes visible to us anyway. > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. That's only practical if you build the kernel for a specific device. If you want a generic binary that can work with multiple different devices, that graph may very well be different for each of them. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 26 October 2015 at 11:51, Michael Turquette wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing >> >> here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. > > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. Alexander Holler has been looking at that for some time already. Regards, Tomeu > Regards, > Mike > >> >> If the dependency could only be discovered at the probe time, the >> order of things might be changed in response to letting the driver >> core know about it rather than "just in case", which should be more >> efficient. >> >> Thanks, >> Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: > > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > > > >> Well, I'm not quite sure why exactly everyone is so focused on probing > >> here. > > > > Probe deferral is really noisy even if it's working fine on a given > > system so it's constantly being highlighted to people in a way that > > other issues aren't if you're not directly having problems. > > > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). > > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. Taking it a step further, if functional dependencies were understood at link-time then we could optimize link order as well. There are probably lots of optimizations if we only made the effort to understand these dependencies earlier. Constructing the device/resource dependency graph before the device ever boots sounds interesting to me. Regards, Mike > > If the dependency could only be discovered at the probe time, the > order of things might be changed in response to letting the driver > core know about it rather than "just in case", which should be more > efficient. > > Thanks, > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brownwrote: > > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > > > >> Well, I'm not quite sure why exactly everyone is so focused on probing > >> here. > > > > Probe deferral is really noisy even if it's working fine on a given > > system so it's constantly being highlighted to people in a way that > > other issues aren't if you're not directly having problems. > > > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). > > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. Taking it a step further, if functional dependencies were understood at link-time then we could optimize link order as well. There are probably lots of optimizations if we only made the effort to understand these dependencies earlier. Constructing the device/resource dependency graph before the device ever boots sounds interesting to me. Regards, Mike > > If the dependency could only be discovered at the probe time, the > order of things might be changed in response to letting the driver > core know about it rather than "just in case", which should be more > efficient. > > Thanks, > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquettewrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing >> >> here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. Do you mean the kernel link time or something else? At least in some cases the dependency information won't be known at that time, so we need a way to record a dependency at the time it becomes visible to us anyway. > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. That's only practical if you build the kernel for a specific device. If you want a generic binary that can work with multiple different devices, that graph may very well be different for each of them. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote: > On Tue, 20 Oct 2015, Mark Brown wrote: > > > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > > > Furthermore, that applies only to devices that use synchronous suspend. > > > Async suspend is becoming common, and there the only restrictions are > > > parent-child relations plus whatever explicit requirements that drivers > > > impose by calling device_pm_wait_for_dev(). > > > > Hrm, this is the first I'd noticed that feature though I see the initial > > commit dates from January. > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > not 2015! > > > It looks like most of the users are PCs at > > the minute but we should be using it more widely for embedded things, > > there's definitely some cases I'm aware of where it will allow us to > > remove some open coding. > > > > It does seem like we want to be feeding dependency information we > > discover for probing way into the suspend dependencies... > > Rafael has been thinking about a way to do this systematically. > Nothing concrete has emerged yet. Well, good point. :-) I've been kind of struggling with finding time to work on the patches lately and some aspects of the design are still not finalized. It seems, though, that it can be beneficial to discuss the approach in general, so let me start a new thread for that. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 26 October 2015 at 11:51, Michael Turquettewrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing >> >> here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. > > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. Alexander Holler has been looking at that for some time already. Regards, Tomeu > Regards, > Mike > >> >> If the dependency could only be discovered at the probe time, the >> order of things might be changed in response to letting the driver >> core know about it rather than "just in case", which should be more >> efficient. >> >> Thanks, >> Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote: > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). Yeah, people seem to have that impression though. :( > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. This links back to the idea of having generic support for pre-probe actions which is also generally useful (the ability to do things like power on regulators for devices on enumerable buses so they can be enumerated as standard). signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On 10/23/2015 10:45 AM, Tim Bird wrote: I've been worried about DT overhead adding to boot time for a while. And IMHO probe deferral is just about the lamest way to solve boot order dependencies I can imagine, from a computer science perspective. (Well, there's a certain elegance to it, but it's a stupid "make everything re-doable, back up and start over, time-wasting" elegance.) It has a bogosort kind of elegance. :) Also this might be a silly question (I haven't been following this issue for very long), but as the only place that can really know what devices depend on each other, in a generic kernel, is the DT (or whatever abstraction) will we not eventually need to solve this issue there? Could we just add a "depends-on = <>;" to nodes when we know they are needed for our board? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote: > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > Probe deferral is really noisy even if it's working fine on a given > system so it's constantly being highlighted to people in a way that > other issues aren't if you're not directly having problems. > > There's also the understanding people had that the order things get > bound changes the ordering for some of the other cases (perhaps it's a > good idea to do that, it seems likely to be sensible?). But it really doesn't do that. Also making it do so doesn't help much in the cases where things can happen asynchronously (system suspend/resume, runtime PM). If, instead, there was a way to specify a functional dependency at the device registration time, it might be used to change the order of everything relevant, including probe. That should help to reduce the noise you're referring to. If the dependency could only be discovered at the probe time, the order of things might be changed in response to letting the driver core know about it rather than "just in case", which should be more efficient. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brownwrote: > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > >> Well, I'm not quite sure why exactly everyone is so focused on probing here. > > Probe deferral is really noisy even if it's working fine on a given > system so it's constantly being highlighted to people in a way that > other issues aren't if you're not directly having problems. > > There's also the understanding people had that the order things get > bound changes the ordering for some of the other cases (perhaps it's a > good idea to do that, it seems likely to be sensible?). But it really doesn't do that. Also making it do so doesn't help much in the cases where things can happen asynchronously (system suspend/resume, runtime PM). If, instead, there was a way to specify a functional dependency at the device registration time, it might be used to change the order of everything relevant, including probe. That should help to reduce the noise you're referring to. If the dependency could only be discovered at the probe time, the order of things might be changed in response to letting the driver core know about it rather than "just in case", which should be more efficient. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote: > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brownwrote: > > There's also the understanding people had that the order things get > > bound changes the ordering for some of the other cases (perhaps it's a > > good idea to do that, it seems likely to be sensible?). > But it really doesn't do that. Also making it do so doesn't help much > in the cases where things can happen asynchronously (system > suspend/resume, runtime PM). Yeah, people seem to have that impression though. :( > If, instead, there was a way to specify a functional dependency at the > device registration time, it might be used to change the order of > everything relevant, including probe. That should help to reduce the > noise you're referring to. This links back to the idea of having generic support for pre-probe actions which is also generally useful (the ability to do things like power on regulators for devices on enumerable buses so they can be enumerated as standard). signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On 10/23/2015 10:45 AM, Tim Bird wrote: I've been worried about DT overhead adding to boot time for a while. And IMHO probe deferral is just about the lamest way to solve boot order dependencies I can imagine, from a computer science perspective. (Well, there's a certain elegance to it, but it's a stupid "make everything re-doable, back up and start over, time-wasting" elegance.) It has a bogosort kind of elegance. :) Also this might be a silly question (I haven't been following this issue for very long), but as the only place that can really know what devices depend on each other, in a generic kernel, is the DT (or whatever abstraction) will we not eventually need to solve this issue there? Could we just add a "depends-on = <>;" to nodes when we know they are needed for our board? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > Well, I'm not quite sure why exactly everyone is so focused on probing here. Probe deferral is really noisy even if it's working fine on a given system so it's constantly being highlighted to people in a way that other issues aren't if you're not directly having problems. There's also the understanding people had that the order things get bound changes the ordering for some of the other cases (perhaps it's a good idea to do that, it seems likely to be sensible?). signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand wrote: > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) Yep, once in a while people still stumble on obscure subsystems and drivers not supporting probe deferral. Usually they don't fail with a big bang, so everything seems fine. E.g. last week's "of_mdiobus_register_phy() and deferred probe" (https://lkml.org/lkml/2015/10/22/377). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote: > On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird wrote: > > On 10/22/2015 11:53 AM, Frank Rowand wrote: > >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > >>> > >>> > >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > But that's moot currently because Greg believes that the time spent > probing devices at boot time could be reduced enough so that the order > in which devices are probed becomes irrelevant. IME that would have to > be under 200ms so that the user doesn't notice and that's unicorn-far > from any bootlog I have ever seen. > >>> > >>> But as no one has actually produced a bootlog, how do you know that? > >>> Where exactly is your time being spent? What driver is causing long > >>> delays? Why is the long-delay-drivers not being done in their own > >>> thread? And most importantly, why are you ignoring the work that people > >>> did back in 2008 to solve the issue on other hardware platforms? > >>> > Given that downstreams are already carrying as many hacks as they > could think of to speed total boot up, I think this is effectively > telling them to go away. > >>> > >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > >>> solve-the-random-issue-i'm-having type patch by putting random calls in > >>> semi-random subsystems all over the kernel. > >>> > >>> And when I ask for real data, you respond with the fact that you aren't > >>> trying to speed up boot time here at all, so what am I supposed to think > >> > >> I also had the understanding that this patch series was about improving > >> boot time. But I was kindly corrected that the behavior change was > >> getting the panel displaying stuff at an earlier point in the boot > >> sequence, > >> _not_ completing the entire boot faster. > >> > >> The claim for the current series, in patch 0 in v7 is: > >> > >>With this series I get the kernel to output to the panel in 0.5s, > >>instead of 2.8s. > > > > It's very common to want to get the display up before the > > rest of the system. So wanting to accelerate one part of the boot > > at the expense to the rest of the system is a valid use case. > > Deferred initcalls, which is out of tree primarily because it requires > > the type of manual tweaking that Tomeu describes, specifically > > addressed this issue. > > Agreed and other folks will want other things up first. But it seems > we are getting lucky with link order with the speed ups in this case. > We need a way to specify priority of probing devices. If we have that > piece, then all this plumbing can be used. A simple solution would be > looking at stdout-path to get the console device to probe. That would > be trivial to add on top of this. That may work for the display too, > but you may not want the console on the display. That wouldn't work > for CAN bus either, but then I'm not sure there is a generic solution > for its requirements (respond within 50ms IIRC). Well, I'm not quite sure why exactly everyone is so focused on probing here. Probing is just one aspect of the fact that we need functional dependencies to be tracked somehow and acted on when necessary. And this is not limited to probing, as I have already said for a few times. Other cases include: system shutdown, system suspend/resume, runtime PM, unbinding of drivers. If there is a functional dependency between two devices (say, B requires A to be present and functional, meaning that the driver of A has to be present and working for the driver of B to be working), all of the above need to be done in a specific order. Today, however, the driver core only knows about structural dependencies and only in the specific parent-child case. So perhaps it's better to start discussing about a solution for the general issue? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote: > On Fri, Oct 23, 2015 at 10:45 AM, Tim Birdwrote: > > On 10/22/2015 11:53 AM, Frank Rowand wrote: > >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > >>> > >>> > >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > But that's moot currently because Greg believes that the time spent > probing devices at boot time could be reduced enough so that the order > in which devices are probed becomes irrelevant. IME that would have to > be under 200ms so that the user doesn't notice and that's unicorn-far > from any bootlog I have ever seen. > >>> > >>> But as no one has actually produced a bootlog, how do you know that? > >>> Where exactly is your time being spent? What driver is causing long > >>> delays? Why is the long-delay-drivers not being done in their own > >>> thread? And most importantly, why are you ignoring the work that people > >>> did back in 2008 to solve the issue on other hardware platforms? > >>> > Given that downstreams are already carrying as many hacks as they > could think of to speed total boot up, I think this is effectively > telling them to go away. > >>> > >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > >>> solve-the-random-issue-i'm-having type patch by putting random calls in > >>> semi-random subsystems all over the kernel. > >>> > >>> And when I ask for real data, you respond with the fact that you aren't > >>> trying to speed up boot time here at all, so what am I supposed to think > >> > >> I also had the understanding that this patch series was about improving > >> boot time. But I was kindly corrected that the behavior change was > >> getting the panel displaying stuff at an earlier point in the boot > >> sequence, > >> _not_ completing the entire boot faster. > >> > >> The claim for the current series, in patch 0 in v7 is: > >> > >>With this series I get the kernel to output to the panel in 0.5s, > >>instead of 2.8s. > > > > It's very common to want to get the display up before the > > rest of the system. So wanting to accelerate one part of the boot > > at the expense to the rest of the system is a valid use case. > > Deferred initcalls, which is out of tree primarily because it requires > > the type of manual tweaking that Tomeu describes, specifically > > addressed this issue. > > Agreed and other folks will want other things up first. But it seems > we are getting lucky with link order with the speed ups in this case. > We need a way to specify priority of probing devices. If we have that > piece, then all this plumbing can be used. A simple solution would be > looking at stdout-path to get the console device to probe. That would > be trivial to add on top of this. That may work for the display too, > but you may not want the console on the display. That wouldn't work > for CAN bus either, but then I'm not sure there is a generic solution > for its requirements (respond within 50ms IIRC). Well, I'm not quite sure why exactly everyone is so focused on probing here. Probing is just one aspect of the fact that we need functional dependencies to be tracked somehow and acted on when necessary. And this is not limited to probing, as I have already said for a few times. Other cases include: system shutdown, system suspend/resume, runtime PM, unbinding of drivers. If there is a functional dependency between two devices (say, B requires A to be present and functional, meaning that the driver of A has to be present and working for the driver of B to be working), all of the above need to be done in a specific order. Today, however, the driver core only knows about structural dependencies and only in the specific parent-child case. So perhaps it's better to start discussing about a solution for the general issue? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowandwrote: > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) Yep, once in a while people still stumble on obscure subsystems and drivers not supporting probe deferral. Usually they don't fail with a big bang, so everything seems fine. E.g. last week's "of_mdiobus_register_phy() and deferred probe" (https://lkml.org/lkml/2015/10/22/377). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: > Well, I'm not quite sure why exactly everyone is so focused on probing here. Probe deferral is really noisy even if it's working fine on a given system so it's constantly being highlighted to people in a way that other issues aren't if you're not directly having problems. There's also the understanding people had that the order things get bound changes the ordering for some of the other cases (perhaps it's a good idea to do that, it seems likely to be sensible?). signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird wrote: > On 10/22/2015 11:53 AM, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>> >>> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. >>> >>> But as no one has actually produced a bootlog, how do you know that? >>> Where exactly is your time being spent? What driver is causing long >>> delays? Why is the long-delay-drivers not being done in their own >>> thread? And most importantly, why are you ignoring the work that people >>> did back in 2008 to solve the issue on other hardware platforms? >>> Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. >>> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >>> solve-the-random-issue-i'm-having type patch by putting random calls in >>> semi-random subsystems all over the kernel. >>> >>> And when I ask for real data, you respond with the fact that you aren't >>> trying to speed up boot time here at all, so what am I supposed to think >> >> I also had the understanding that this patch series was about improving >> boot time. But I was kindly corrected that the behavior change was >> getting the panel displaying stuff at an earlier point in the boot sequence, >> _not_ completing the entire boot faster. >> >> The claim for the current series, in patch 0 in v7 is: >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. > > It's very common to want to get the display up before the > rest of the system. So wanting to accelerate one part of the boot > at the expense to the rest of the system is a valid use case. > Deferred initcalls, which is out of tree primarily because it requires > the type of manual tweaking that Tomeu describes, specifically > addressed this issue. Agreed and other folks will want other things up first. But it seems we are getting lucky with link order with the speed ups in this case. We need a way to specify priority of probing devices. If we have that piece, then all this plumbing can be used. A simple solution would be looking at stdout-path to get the console device to probe. That would be trivial to add on top of this. That may work for the display too, but you may not want the console on the display. That wouldn't work for CAN bus either, but then I'm not sure there is a generic solution for its requirements (respond within 50ms IIRC). >> Just to get side-tracked, one other approach at ordering to reduce >> deferrals reported a modest boot time reduction for four boards and a >> very slight boot time increase for one other board.) The report of boot >> times with that approach was in: >> >> http://article.gmane.org/gmane.linux.drivers.devicetree/133010 >> >> from Alexander Holler. >> >> I have not searched further to see if there is more data of boot time >> reductions from any of the other attempts to change driver binding >> order to move dependencies before use of a resource. But whether >> there is a performance improvement or not, there continues to be >> a stream of developers creatively impacting the binding order for >> their specific driver(s) or board. So it seems that maybe there >> is an underlying problem, or we don't have adequate documentation >> explaining how to avoid a need to order bindings, or the >> documentation exists and is not being read. > > Well, I have probe order problems unrelated to boot time, that > I solved by resorting to putting stuff into modules and loading > them post-boot. So I'd be interested in easy solutions to managing > boot order in mainline. I take it that this series doesn't help those problems? >> I have been defaulting to the position that has been asserted by >> the device tree maintainters, that probe deferrals work just fine >> for at least the majority of cases (and is the message I have been >> sharing in my conference presentations about device tree). But I >> suspect that there is at least a small minority of cases that are not >> well served by probe deferral. (Not to be read as an endorsement of >> this specific patch series, just a generic observation.) > > I've been worried about DT overhead adding to boot time for a while. Always beating up DT... ;) Yes, I'm sure there is some overhead, but looking at bootgraph there's much longer items not related to DT (USB, MMC and anything over I2C seem to be typical). With DT we lost most control of the order, and at the same time we added a load of new subsystems that are dependencies. > And IMHO probe deferral is just
Re: [GIT PULL] On-demand device probing
On 10/22/2015 11:53 AM, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >> >> >> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >>> But that's moot currently because Greg believes that the time spent >>> probing devices at boot time could be reduced enough so that the order >>> in which devices are probed becomes irrelevant. IME that would have to >>> be under 200ms so that the user doesn't notice and that's unicorn-far >>> from any bootlog I have ever seen. >> >> But as no one has actually produced a bootlog, how do you know that? >> Where exactly is your time being spent? What driver is causing long >> delays? Why is the long-delay-drivers not being done in their own >> thread? And most importantly, why are you ignoring the work that people >> did back in 2008 to solve the issue on other hardware platforms? >> >>> Given that downstreams are already carrying as many hacks as they >>> could think of to speed total boot up, I think this is effectively >>> telling them to go away. >> >> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >> solve-the-random-issue-i'm-having type patch by putting random calls in >> semi-random subsystems all over the kernel. >> >> And when I ask for real data, you respond with the fact that you aren't >> trying to speed up boot time here at all, so what am I supposed to think > > I also had the understanding that this patch series was about improving > boot time. But I was kindly corrected that the behavior change was > getting the panel displaying stuff at an earlier point in the boot sequence, > _not_ completing the entire boot faster. > > The claim for the current series, in patch 0 in v7 is: > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. It's very common to want to get the display up before the rest of the system. So wanting to accelerate one part of the boot at the expense to the rest of the system is a valid use case. Deferred initcalls, which is out of tree primarily because it requires the type of manual tweaking that Tomeu describes, specifically addressed this issue. > > Just to get side-tracked, one other approach at ordering to reduce > deferrals reported a modest boot time reduction for four boards and a > very slight boot time increase for one other board.) The report of boot > times with that approach was in: > > http://article.gmane.org/gmane.linux.drivers.devicetree/133010 > > from Alexander Holler. > > I have not searched further to see if there is more data of boot time > reductions from any of the other attempts to change driver binding > order to move dependencies before use of a resource. But whether > there is a performance improvement or not, there continues to be > a stream of developers creatively impacting the binding order for > their specific driver(s) or board. So it seems that maybe there > is an underlying problem, or we don't have adequate documentation > explaining how to avoid a need to order bindings, or the > documentation exists and is not being read. Well, I have probe order problems unrelated to boot time, that I solved by resorting to putting stuff into modules and loading them post-boot. So I'd be interested in easy solutions to managing boot order in mainline. > > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) I've been worried about DT overhead adding to boot time for a while. And IMHO probe deferral is just about the lamest way to solve boot order dependencies I can imagine, from a computer science perspective. (Well, there's a certain elegance to it, but it's a stupid "make everything re-doable, back up and start over, time-wasting" elegance.) However, when Android takes 35 seconds to boot, and most people almost never cold-boot your product, a few seconds of kernel time-wasting on cold-boot seem less important. Alas, when I started working on mobile phones I stopped caring much about boot time. Thus, I've never worried about the DT overhead enough to actually measure it, as requested by Greg. So I'll just shut up now. :-) -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote: > On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>> >>> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. >>> >>> But as no one has actually produced a bootlog, how do you know that? >>> Where exactly is your time being spent? What driver is causing long >>> delays? Why is the long-delay-drivers not being done in their own >>> thread? And most importantly, why are you ignoring the work that people >>> did back in 2008 to solve the issue on other hardware platforms? >>> Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. >>> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >>> solve-the-random-issue-i'm-having type patch by putting random calls in >>> semi-random subsystems all over the kernel. >>> >>> And when I ask for real data, you respond with the fact that you aren't >>> trying to speed up boot time here at all, so what am I supposed to think >> >> I also had the understanding that this patch series was about improving >> boot time. But I was kindly corrected that the behavior change was >> getting the panel displaying stuff at an earlier point in the boot sequence, >> _not_ completing the entire boot faster. >> >> The claim for the current series, in patch 0 in v7 is: >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. >> >> Just to get side-tracked, one other approach at ordering to reduce >> deferrals reported a modest boot time reduction for four boards and a >> very slight boot time increase for one other board.) The report of boot >> times with that approach was in: >> >> http://article.gmane.org/gmane.linux.drivers.devicetree/133010 >> >> from Alexander Holler. >> >> I have not searched further to see if there is more data of boot time >> reductions from any of the other attempts to change driver binding >> order to move dependencies before use of a resource. But whether >> there is a performance improvement or not, there continues to be >> a stream of developers creatively impacting the binding order for >> their specific driver(s) or board. So it seems that maybe there >> is an underlying problem, or we don't have adequate documentation >> explaining how to avoid a need to order bindings, or the >> documentation exists and is not being read. >> >> I have been defaulting to the position that has been asserted by >> the device tree maintainters, that probe deferrals work just fine >> for at least the majority of cases (and is the message I have been >> sharing in my conference presentations about device tree). But I >> suspect that there is at least a small minority of cases that are not >> well served by probe deferral. (Not to be read as an endorsement of >> this specific patch series, just a generic observation.) > > I agree, there might be some small numbers that this is a problem for, > and if so, great, show us the boot logs where things are taking up all > of the time, and we can work on resolving those issues. > > But without hard numbers / details, this all is just random hand-waving, > and I don't like making core kernel changes on that basis. And no one > else should ever want us to do that either. Hi, have found the board in which Stéphane had the original issue on (exynos5250-snow), and I'm attaching the bootlog of next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c. As can be seen, 145b.dp-controller is tried reasonably early (at 0.25s), but is deferred and only retried at 0.9s, with the display finally coming up at 1.35s. But I'm not sure what's the point in discussing this further if you have already said that it's fine if downstreams have to change the probing order by moving files around in the makefiles and by fiddling with initcall levels. To give a better understanding of what's going on here, I wasn't involved in the bringup of this board, but was tasked with fixing this issue in mainline so it doesn't have to be worked around in every product. Regards, Tomeu > thanks, > > greg k-h > [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.3.0-rc5-next-20151013-dirty (tomeu@cizrna) (gcc version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #3491 SMP PREEMPT Fri Oct 23 11:17:16 CEST 2015 [0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [
Re: [GIT PULL] On-demand device probing
On 10/22/2015 09:26 PM, Greg Kroah-Hartman wrote: > On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>>>>> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. >>> >>> But as no one has actually produced a bootlog, how do you know that? >>> Where exactly is your time being spent? What driver is causing long >>> delays? Why is the long-delay-drivers not being done in their own >>> thread? And most importantly, why are you ignoring the work that people >>> did back in 2008 to solve the issue on other hardware platforms? >>> Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. >>> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >>> solve-the-random-issue-i'm-having type patch by putting random calls in >>> semi-random subsystems all over the kernel. >>> >>> And when I ask for real data, you respond with the fact that you aren't >>> trying to speed up boot time here at all, so what am I supposed to think >> >> I also had the understanding that this patch series was about improving >> boot time. But I was kindly corrected that the behavior change was >> getting the panel displaying stuff at an earlier point in the boot sequence, >> _not_ completing the entire boot faster. >> >> The claim for the current series, in patch 0 in v7 is: >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. >> >> Just to get side-tracked, one other approach at ordering to reduce >> deferrals reported a modest boot time reduction for four boards and a >> very slight boot time increase for one other board.) The report of boot >> times with that approach was in: >> >> http://article.gmane.org/gmane.linux.drivers.devicetree/133010 >> >> from Alexander Holler. >> >> I have not searched further to see if there is more data of boot time >> reductions from any of the other attempts to change driver binding >> order to move dependencies before use of a resource. But whether >> there is a performance improvement or not, there continues to be >> a stream of developers creatively impacting the binding order for >> their specific driver(s) or board. So it seems that maybe there >> is an underlying problem, or we don't have adequate documentation >> explaining how to avoid a need to order bindings, or the >> documentation exists and is not being read. >> >> I have been defaulting to the position that has been asserted by >> the device tree maintainters, that probe deferrals work just fine >> for at least the majority of cases (and is the message I have been >> sharing in my conference presentations about device tree). But I >> suspect that there is at least a small minority of cases that are not >> well served by probe deferral. (Not to be read as an endorsement of >> this specific patch series, just a generic observation.) > > I agree, there might be some small numbers that this is a problem for, > and if so, great, show us the boot logs where things are taking up all > of the time, and we can work on resolving those issues. > > But without hard numbers / details, this all is just random hand-waving, > and I don't like making core kernel changes on that basis. And no one > else should ever want us to do that either. Hi, have found the board in which Stéphane had the original issue on (exynos5250-snow), and I'm attaching the bootlog of next-20151013+exynos_defconfig with initcall_debug and DEBUG in dd.c. As can be seen, 145b.dp-controller is tried reasonably early (at 0.25s), but is deferred and only retried at 0.9s, with the display finally coming up at 1.35s. But I'm not sure what's the point in discussing this further if you have already said that it's fine if downstreams have to change the probing order by moving files around in the makefiles and by fiddling with initcall levels. To give a better understanding of what's going on here, I wasn't involved in the bringup of this board, but was tasked with fixing this issue in mainline so it doesn't have to be worked around in every product. Regards, Tomeu > thanks, > > greg k-h > [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.3.0-rc5-next-20151013-dirty (tomeu@cizrna) (gcc version 5.2.1 20150716 (Red Hat Cross 5.2.1-3) (GCC) ) #3491 SMP PREEMPT Fri Oct 23 11:17:16 CEST 2015 [0.00] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT
Re: [GIT PULL] On-demand device probing
On 10/22/2015 11:53 AM, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>>> >> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >>> But that's moot currently because Greg believes that the time spent >>> probing devices at boot time could be reduced enough so that the order >>> in which devices are probed becomes irrelevant. IME that would have to >>> be under 200ms so that the user doesn't notice and that's unicorn-far >>> from any bootlog I have ever seen. >> >> But as no one has actually produced a bootlog, how do you know that? >> Where exactly is your time being spent? What driver is causing long >> delays? Why is the long-delay-drivers not being done in their own >> thread? And most importantly, why are you ignoring the work that people >> did back in 2008 to solve the issue on other hardware platforms? >> >>> Given that downstreams are already carrying as many hacks as they >>> could think of to speed total boot up, I think this is effectively >>> telling them to go away. >> >> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >> solve-the-random-issue-i'm-having type patch by putting random calls in >> semi-random subsystems all over the kernel. >> >> And when I ask for real data, you respond with the fact that you aren't >> trying to speed up boot time here at all, so what am I supposed to think > > I also had the understanding that this patch series was about improving > boot time. But I was kindly corrected that the behavior change was > getting the panel displaying stuff at an earlier point in the boot sequence, > _not_ completing the entire boot faster. > > The claim for the current series, in patch 0 in v7 is: > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. It's very common to want to get the display up before the rest of the system. So wanting to accelerate one part of the boot at the expense to the rest of the system is a valid use case. Deferred initcalls, which is out of tree primarily because it requires the type of manual tweaking that Tomeu describes, specifically addressed this issue. > > Just to get side-tracked, one other approach at ordering to reduce > deferrals reported a modest boot time reduction for four boards and a > very slight boot time increase for one other board.) The report of boot > times with that approach was in: > > http://article.gmane.org/gmane.linux.drivers.devicetree/133010 > > from Alexander Holler. > > I have not searched further to see if there is more data of boot time > reductions from any of the other attempts to change driver binding > order to move dependencies before use of a resource. But whether > there is a performance improvement or not, there continues to be > a stream of developers creatively impacting the binding order for > their specific driver(s) or board. So it seems that maybe there > is an underlying problem, or we don't have adequate documentation > explaining how to avoid a need to order bindings, or the > documentation exists and is not being read. Well, I have probe order problems unrelated to boot time, that I solved by resorting to putting stuff into modules and loading them post-boot. So I'd be interested in easy solutions to managing boot order in mainline. > > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) I've been worried about DT overhead adding to boot time for a while. And IMHO probe deferral is just about the lamest way to solve boot order dependencies I can imagine, from a computer science perspective. (Well, there's a certain elegance to it, but it's a stupid "make everything re-doable, back up and start over, time-wasting" elegance.) However, when Android takes 35 seconds to boot, and most people almost never cold-boot your product, a few seconds of kernel time-wasting on cold-boot seem less important. Alas, when I started working on mobile phones I stopped caring much about boot time. Thus, I've never worried about the DT overhead enough to actually measure it, as requested by Greg. So I'll just shut up now. :-) -- Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Fri, Oct 23, 2015 at 10:45 AM, Tim Birdwrote: > On 10/22/2015 11:53 AM, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>> >>> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. >>> >>> But as no one has actually produced a bootlog, how do you know that? >>> Where exactly is your time being spent? What driver is causing long >>> delays? Why is the long-delay-drivers not being done in their own >>> thread? And most importantly, why are you ignoring the work that people >>> did back in 2008 to solve the issue on other hardware platforms? >>> Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. >>> >>> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to >>> solve-the-random-issue-i'm-having type patch by putting random calls in >>> semi-random subsystems all over the kernel. >>> >>> And when I ask for real data, you respond with the fact that you aren't >>> trying to speed up boot time here at all, so what am I supposed to think >> >> I also had the understanding that this patch series was about improving >> boot time. But I was kindly corrected that the behavior change was >> getting the panel displaying stuff at an earlier point in the boot sequence, >> _not_ completing the entire boot faster. >> >> The claim for the current series, in patch 0 in v7 is: >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. > > It's very common to want to get the display up before the > rest of the system. So wanting to accelerate one part of the boot > at the expense to the rest of the system is a valid use case. > Deferred initcalls, which is out of tree primarily because it requires > the type of manual tweaking that Tomeu describes, specifically > addressed this issue. Agreed and other folks will want other things up first. But it seems we are getting lucky with link order with the speed ups in this case. We need a way to specify priority of probing devices. If we have that piece, then all this plumbing can be used. A simple solution would be looking at stdout-path to get the console device to probe. That would be trivial to add on top of this. That may work for the display too, but you may not want the console on the display. That wouldn't work for CAN bus either, but then I'm not sure there is a generic solution for its requirements (respond within 50ms IIRC). >> Just to get side-tracked, one other approach at ordering to reduce >> deferrals reported a modest boot time reduction for four boards and a >> very slight boot time increase for one other board.) The report of boot >> times with that approach was in: >> >> http://article.gmane.org/gmane.linux.drivers.devicetree/133010 >> >> from Alexander Holler. >> >> I have not searched further to see if there is more data of boot time >> reductions from any of the other attempts to change driver binding >> order to move dependencies before use of a resource. But whether >> there is a performance improvement or not, there continues to be >> a stream of developers creatively impacting the binding order for >> their specific driver(s) or board. So it seems that maybe there >> is an underlying problem, or we don't have adequate documentation >> explaining how to avoid a need to order bindings, or the >> documentation exists and is not being read. > > Well, I have probe order problems unrelated to boot time, that > I solved by resorting to putting stuff into modules and loading > them post-boot. So I'd be interested in easy solutions to managing > boot order in mainline. I take it that this series doesn't help those problems? >> I have been defaulting to the position that has been asserted by >> the device tree maintainters, that probe deferrals work just fine >> for at least the majority of cases (and is the message I have been >> sharing in my conference presentations about device tree). But I >> suspect that there is at least a small minority of cases that are not >> well served by probe deferral. (Not to be read as an endorsement of >> this specific patch series, just a generic observation.) > > I've been worried about DT overhead adding to boot time for a while. Always beating up DT... ;) Yes, I'm sure there is some overhead, but looking at bootgraph there's much longer items not related to DT (USB, MMC and anything over I2C seem to be typical). With DT we lost most control of the order, and at the same time we added a load of new subsystems that are
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote: > If it was such a problem, then in the _eight_ days that this has been > discussed so far, _someone_ would have sent some data showing the > problem. I think the fact is, there is no data. > Someone prove me wrong. Someone post the verifiable data showing that > there is a problem to be solved here. > Someone show what the specific failure cases are that are hampering > vendors moving forwards. Someone show the long boot times by way of > kernel message log. Someone show some evidence of the problems that > have been alluded to. > If no one can show some evidence, there isn't a problem here. :) Yeah, I'm not convinced the timing is *such* a big deal either - I do think that the log spam is a real problem but I think something much less invasive like the interface you proposed is good for addressing that. signature.asc Description: PGP signature
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote: > Something like this. I haven't put a lot of effort into it to change all > the places which return an -EPROBE_DEFER, and it also looks like we need > some helpers to report when we have only an device_node (or should that > be fwnode?) See the commented out of_warn_deferred() in > drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching > for resources should make debugging why things are getting deferred easier. Yeah, plus I'd expect it to also result in better error reporting overall if the subsystems are able to report when they fail to get something rather than just returning an error to the driver. > +/** > + * dev_warn_deferred() - report why a probe has been deferred > + */ > +void dev_warn_deferred(struct device *dev, const char *fmt, ...) > +{ > + if (driver_deferred_probe_report) { > + struct va_format vaf; > + va_list ap; > + > + va_start(ap, fmt); > + vaf.fmt = fmt; > + vaf.va = > + > + dev_warn(dev, "deferring probe: %pV", ); > + va_end(ap); > + } > +} > +EXPORT_SYMBOL_GPL(dev_warn_deferred); I'm not currently able to think of a nice way of writing this but I think what I'd really like to see from a driver point of view is something which decays into dev_err() if it's a non-deferral error. That way drivers can have minimal log and return error handling code and we will still get the output sensibly. The best I can think of is something like void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...) which requires the caller to pass in err twice to get it logged. That's not a thing of beauty but it gets the job done... but perhaps your original interface is better, it's a bit cleaner. signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > > > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > >> But that's moot currently because Greg believes that the time spent > >> probing devices at boot time could be reduced enough so that the order > >> in which devices are probed becomes irrelevant. IME that would have to > >> be under 200ms so that the user doesn't notice and that's unicorn-far > >> from any bootlog I have ever seen. > > > > But as no one has actually produced a bootlog, how do you know that? > > Where exactly is your time being spent? What driver is causing long > > delays? Why is the long-delay-drivers not being done in their own > > thread? And most importantly, why are you ignoring the work that people > > did back in 2008 to solve the issue on other hardware platforms? > > > >> Given that downstreams are already carrying as many hacks as they > >> could think of to speed total boot up, I think this is effectively > >> telling them to go away. > > > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > > solve-the-random-issue-i'm-having type patch by putting random calls in > > semi-random subsystems all over the kernel. > > > > And when I ask for real data, you respond with the fact that you aren't > > trying to speed up boot time here at all, so what am I supposed to think > > I also had the understanding that this patch series was about improving > boot time. But I was kindly corrected that the behavior change was > getting the panel displaying stuff at an earlier point in the boot sequence, > _not_ completing the entire boot faster. > > The claim for the current series, in patch 0 in v7 is: > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. > > Just to get side-tracked, one other approach at ordering to reduce > deferrals reported a modest boot time reduction for four boards and a > very slight boot time increase for one other board.) The report of boot > times with that approach was in: > > http://article.gmane.org/gmane.linux.drivers.devicetree/133010 > > from Alexander Holler. > > I have not searched further to see if there is more data of boot time > reductions from any of the other attempts to change driver binding > order to move dependencies before use of a resource. But whether > there is a performance improvement or not, there continues to be > a stream of developers creatively impacting the binding order for > their specific driver(s) or board. So it seems that maybe there > is an underlying problem, or we don't have adequate documentation > explaining how to avoid a need to order bindings, or the > documentation exists and is not being read. > > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) I agree, there might be some small numbers that this is a problem for, and if so, great, show us the boot logs where things are taking up all of the time, and we can work on resolving those issues. But without hard numbers / details, this all is just random hand-waving, and I don't like making core kernel changes on that basis. And no one else should ever want us to do that either. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >> But that's moot currently because Greg believes that the time spent >> probing devices at boot time could be reduced enough so that the order >> in which devices are probed becomes irrelevant. IME that would have to >> be under 200ms so that the user doesn't notice and that's unicorn-far >> from any bootlog I have ever seen. > > But as no one has actually produced a bootlog, how do you know that? > Where exactly is your time being spent? What driver is causing long > delays? Why is the long-delay-drivers not being done in their own > thread? And most importantly, why are you ignoring the work that people > did back in 2008 to solve the issue on other hardware platforms? > >> Given that downstreams are already carrying as many hacks as they >> could think of to speed total boot up, I think this is effectively >> telling them to go away. > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > solve-the-random-issue-i'm-having type patch by putting random calls in > semi-random subsystems all over the kernel. > > And when I ask for real data, you respond with the fact that you aren't > trying to speed up boot time here at all, so what am I supposed to think I also had the understanding that this patch series was about improving boot time. But I was kindly corrected that the behavior change was getting the panel displaying stuff at an earlier point in the boot sequence, _not_ completing the entire boot faster. The claim for the current series, in patch 0 in v7 is: With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Just to get side-tracked, one other approach at ordering to reduce deferrals reported a modest boot time reduction for four boards and a very slight boot time increase for one other board.) The report of boot times with that approach was in: http://article.gmane.org/gmane.linux.drivers.devicetree/133010 from Alexander Holler. I have not searched further to see if there is more data of boot time reductions from any of the other attempts to change driver binding order to move dependencies before use of a resource. But whether there is a performance improvement or not, there continues to be a stream of developers creatively impacting the binding order for their specific driver(s) or board. So it seems that maybe there is an underlying problem, or we don't have adequate documentation explaining how to avoid a need to order bindings, or the documentation exists and is not being read. I have been defaulting to the position that has been asserted by the device tree maintainters, that probe deferrals work just fine for at least the majority of cases (and is the message I have been sharing in my conference presentations about device tree). But I suspect that there is at least a small minority of cases that are not well served by probe deferral. (Not to be read as an endorsement of this specific patch series, just a generic observation.) -Frank > other than that you don't care enough to do the real work and are trying > to hack the driver core up instead. > >> Sorry for the rant, > > No apologies needed, it's cathartic at times :) > > thanks, > > greg k-h > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote: > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > > Given that downstreams are already carrying as many hacks as they > > could think of to speed total boot up, I think this is effectively > > telling them to go away. > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > solve-the-random-issue-i'm-having type patch by putting random calls in > semi-random subsystems all over the kernel. +1000, fully agree. There's too much verbal diarrhoea going on in this thread and no facts. I've been waiting for real data too, and there's not one shred of it, or even a hint that it might appear. So, the conclusion I'm coming to is that there isn't any data to back up the claims made in this thread. If it was such a problem, then in the _eight_ days that this has been discussed so far, _someone_ would have sent some data showing the problem. I think the fact is, there is no data. Someone prove me wrong. Someone post the verifiable data showing that there is a problem to be solved here. Someone show what the specific failure cases are that are hampering vendors moving forwards. Someone show the long boot times by way of kernel message log. Someone show some evidence of the problems that have been alluded to. If no one can show some evidence, there isn't a problem here. :) -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > But that's moot currently because Greg believes that the time spent > probing devices at boot time could be reduced enough so that the order > in which devices are probed becomes irrelevant. IME that would have to > be under 200ms so that the user doesn't notice and that's unicorn-far > from any bootlog I have ever seen. But as no one has actually produced a bootlog, how do you know that? Where exactly is your time being spent? What driver is causing long delays? Why is the long-delay-drivers not being done in their own thread? And most importantly, why are you ignoring the work that people did back in 2008 to solve the issue on other hardware platforms? > Given that downstreams are already carrying as many hacks as they > could think of to speed total boot up, I think this is effectively > telling them to go away. No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to solve-the-random-issue-i'm-having type patch by putting random calls in semi-random subsystems all over the kernel. And when I ask for real data, you respond with the fact that you aren't trying to speed up boot time here at all, so what am I supposed to think other than that you don't care enough to do the real work and are trying to hack the driver core up instead. > Sorry for the rant, No apologies needed, it's cathartic at times :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > On 21 October 2015 at 23:50, Frank Rowand wrote: > > On 10/21/2015 2:12 PM, Rob Herring wrote: > >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand > >> wrote: > >>> On 10/21/2015 9:27 AM, Mark Brown wrote: > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > > >> To be clear, I was saying that this series should NOT affect total > >> boot times much. > > > I'm confused. If I understood correctly, improving boot time was > > the key justification for accepting this patch set. For example, > > from "[PATCH v7 0/20] On-demand device probing": > > > >I have a problem with the panel on my Tegra Chromebook taking longer > >than expected to be ready during boot (Stéphane Marchesin reported > > what > >is basically the same issue in [0]), and have looked into ordered > >probing as a better way of solving this than moving nodes around in > > the > >DT or playing with initcall levels and linking order. > > > >... > > > >With this series I get the kernel to output to the panel in 0.5s, > >instead of 2.8s. > > Overall boot time and time to get some individual built in component up > and running aren't the same thing - what this'll do is get things up > more in the link order of the leaf consumers rather than deferring those > leaf consumers when their dependencies aren't ready yet. > >>> > >>> Thanks! I read too much into what was being improved. > >>> > >>> So this patch series, which on other merits may be a good idea, is as > >>> a by product solving a specific ordering issue, moving successful panel > >>> initialization to an earlier point in the boot sequence, if I now > >>> understand more correctly. > >>> > >>> In that context, this seems like yet another ad hoc way of causing the > >>> probe order to change in a way to solves one specific issue? Could > >>> it just as likely move the boot order of some other driver on some > >>> other board later, to the detriment of somebody else? > >> > >> Time to display on is important for many products. Having the console > >> up as early as possible is another case. CAN bus is another. This is a > >> real problem that is not just bad drivers. > > > > Yes, I agree. > > > > What I am seeing is that there continues to be a need for the ability > > to explicitly order at least some driver initialization (at some > > granularity), despite the push back against explicit ordering that > > has been present in the past. > > The important point that I have struggled to explain is that right now > for downstreams to influence the order in which devices are probed, > they have to carry a substantial amount of patches that cannot be ever > upstreamed. This fiddling with initcall levels and link order means > changing files that are very frequently changing, increasing the > amount of work when rebasing and increasing the probability of > regressions after a rebase. > > This just adds up to other shortcomings of mainline and ends up with > the net result of vendors getting stuck with 3.4 kernels on SoCs that > start production in 2015. Another consequence is that vendors don't > have a chance to upstream their stuff even if they cared. The > overarching goal of the project I'm in is to reduce those shortcomings > that downstreams have to workaround, to facilitate their involvement > upstream. The init order of drivers has no influence at all on the ability for companies to have their individual drivers merged upstream, please don't be so dramatic about this. Worst case, a vendor keeps a single patch to drivers/Makefile in their tree that reorders things, yes it will get conflicts on every release, but really, it's trivial to maintain if they wish to keep doing this type of thing. Again, it is _not_ the reason that we are living with 2million+ lines of code in vendor kernels. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 22 October 2015 at 02:54, Rafael J. Wysocki wrote: > On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: >> On 20 October 2015 at 18:04, Alan Stern wrote: >> > On Tue, 20 Oct 2015, Mark Brown wrote: >> > >> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: >> >> >> >> > Furthermore, that applies only to devices that use synchronous suspend. >> >> > Async suspend is becoming common, and there the only restrictions are >> >> > parent-child relations plus whatever explicit requirements that drivers >> >> > impose by calling device_pm_wait_for_dev(). >> >> >> >> Hrm, this is the first I'd noticed that feature though I see the initial >> >> commit dates from January. >> > >> > Async suspend and device_pm_wait_for_dev() were added in January 2010, >> > not 2015! >> > >> >> It looks like most of the users are PCs at >> >> the minute but we should be using it more widely for embedded things, >> >> there's definitely some cases I'm aware of where it will allow us to >> >> remove some open coding. >> >> >> >> It does seem like we want to be feeding dependency information we >> >> discover for probing way into the suspend dependencies... >> > >> > Rafael has been thinking about a way to do this systematically. >> > Nothing concrete has emerged yet. >> >> This iteration of the series would make this quite easy, as >> dependencies are calculated before probes are attempted: >> >> https://lkml.org/lkml/2015/6/17/311 > > Well, if you know how to represent "links" between devices, the mechanism > introduced here doesn't really add much value, because in that case the > core knows what the dependencies are in the first place and can only > defer the probes that have to be deferred. By "here" you mean what you are proposing for ordering device suspends, or on-demand probing? If you meant that probing on-demand is unneeded if we already have dependency information, I agree with you and that's why I only pushed forward on-demand, as the approach linked above introduced some duplication when inferring the dependencies. Maybe that could be avoided without too much refactoring. In any case, Thierry mentioned the other day in #tegra that one could also collect dependency information as a follow up to the on-demand series by calling device_depend() or such instead of of_device_probe(). Regards, Tomeu > Thanks, > Rafael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 21 October 2015 at 23:50, Frank Rowand wrote: > On 10/21/2015 2:12 PM, Rob Herring wrote: >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand wrote: >>> On 10/21/2015 9:27 AM, Mark Brown wrote: On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >> To be clear, I was saying that this series should NOT affect total >> boot times much. > I'm confused. If I understood correctly, improving boot time was > the key justification for accepting this patch set. For example, > from "[PATCH v7 0/20] On-demand device probing": > >I have a problem with the panel on my Tegra Chromebook taking longer >than expected to be ready during boot (Stéphane Marchesin reported what >is basically the same issue in [0]), and have looked into ordered >probing as a better way of solving this than moving nodes around in the >DT or playing with initcall levels and linking order. > >... > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. Overall boot time and time to get some individual built in component up and running aren't the same thing - what this'll do is get things up more in the link order of the leaf consumers rather than deferring those leaf consumers when their dependencies aren't ready yet. >>> >>> Thanks! I read too much into what was being improved. >>> >>> So this patch series, which on other merits may be a good idea, is as >>> a by product solving a specific ordering issue, moving successful panel >>> initialization to an earlier point in the boot sequence, if I now >>> understand more correctly. >>> >>> In that context, this seems like yet another ad hoc way of causing the >>> probe order to change in a way to solves one specific issue? Could >>> it just as likely move the boot order of some other driver on some >>> other board later, to the detriment of somebody else? >> >> Time to display on is important for many products. Having the console >> up as early as possible is another case. CAN bus is another. This is a >> real problem that is not just bad drivers. > > Yes, I agree. > > What I am seeing is that there continues to be a need for the ability > to explicitly order at least some driver initialization (at some > granularity), despite the push back against explicit ordering that > has been present in the past. The important point that I have struggled to explain is that right now for downstreams to influence the order in which devices are probed, they have to carry a substantial amount of patches that cannot be ever upstreamed. This fiddling with initcall levels and link order means changing files that are very frequently changing, increasing the amount of work when rebasing and increasing the probability of regressions after a rebase. This just adds up to other shortcomings of mainline and ends up with the net result of vendors getting stuck with 3.4 kernels on SoCs that start production in 2015. Another consequence is that vendors don't have a chance to upstream their stuff even if they cared. The overarching goal of the project I'm in is to reduce those shortcomings that downstreams have to workaround, to facilitate their involvement upstream. With this series, the order in which devices are probed becomes the order in which they were registered, which is the order in which the devices appear in the FW description of the hw or in the board files (much more predictable, which makes for a more robust process). For DT and board files, which cover a good part of the consumer devices shipped today with Linux, the downstream could just change the order of device nodes and get their display or whatever to probe before any other devices. And even if downstream's hw has a SoC .dtsi that exists in mainline, they could add a step to their build process that automatically reorders the nodes to avoid carrying changes to that DT fragment. But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. Sorry for the rant, Tomeu >> I don't think it is completely ad hoc. Given all devices are >> registered after drivers, drivers will still probe first in initcall >> level order and then link order AFAIK. We may not take (more) initcall >> level tweak hacks, but that is a much more simple change for >> downstream. Don't get me wrong, I'd really like to see a way to >> control order independent of initcall level. >> >> Rob > > Yep, it is not directly ad hoc, just a fortunate side effect
Re: [GIT PULL] On-demand device probing
On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >> > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >> But that's moot currently because Greg believes that the time spent >> probing devices at boot time could be reduced enough so that the order >> in which devices are probed becomes irrelevant. IME that would have to >> be under 200ms so that the user doesn't notice and that's unicorn-far >> from any bootlog I have ever seen. > > But as no one has actually produced a bootlog, how do you know that? > Where exactly is your time being spent? What driver is causing long > delays? Why is the long-delay-drivers not being done in their own > thread? And most importantly, why are you ignoring the work that people > did back in 2008 to solve the issue on other hardware platforms? > >> Given that downstreams are already carrying as many hacks as they >> could think of to speed total boot up, I think this is effectively >> telling them to go away. > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > solve-the-random-issue-i'm-having type patch by putting random calls in > semi-random subsystems all over the kernel. > > And when I ask for real data, you respond with the fact that you aren't > trying to speed up boot time here at all, so what am I supposed to think I also had the understanding that this patch series was about improving boot time. But I was kindly corrected that the behavior change was getting the panel displaying stuff at an earlier point in the boot sequence, _not_ completing the entire boot faster. The claim for the current series, in patch 0 in v7 is: With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Just to get side-tracked, one other approach at ordering to reduce deferrals reported a modest boot time reduction for four boards and a very slight boot time increase for one other board.) The report of boot times with that approach was in: http://article.gmane.org/gmane.linux.drivers.devicetree/133010 from Alexander Holler. I have not searched further to see if there is more data of boot time reductions from any of the other attempts to change driver binding order to move dependencies before use of a resource. But whether there is a performance improvement or not, there continues to be a stream of developers creatively impacting the binding order for their specific driver(s) or board. So it seems that maybe there is an underlying problem, or we don't have adequate documentation explaining how to avoid a need to order bindings, or the documentation exists and is not being read. I have been defaulting to the position that has been asserted by the device tree maintainters, that probe deferrals work just fine for at least the majority of cases (and is the message I have been sharing in my conference presentations about device tree). But I suspect that there is at least a small minority of cases that are not well served by probe deferral. (Not to be read as an endorsement of this specific patch series, just a generic observation.) -Frank > other than that you don't care enough to do the real work and are trying > to hack the driver core up instead. > >> Sorry for the rant, > > No apologies needed, it's cathartic at times :) > > thanks, > > greg k-h > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > >> > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > >> But that's moot currently because Greg believes that the time spent > >> probing devices at boot time could be reduced enough so that the order > >> in which devices are probed becomes irrelevant. IME that would have to > >> be under 200ms so that the user doesn't notice and that's unicorn-far > >> from any bootlog I have ever seen. > > > > But as no one has actually produced a bootlog, how do you know that? > > Where exactly is your time being spent? What driver is causing long > > delays? Why is the long-delay-drivers not being done in their own > > thread? And most importantly, why are you ignoring the work that people > > did back in 2008 to solve the issue on other hardware platforms? > > > >> Given that downstreams are already carrying as many hacks as they > >> could think of to speed total boot up, I think this is effectively > >> telling them to go away. > > > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > > solve-the-random-issue-i'm-having type patch by putting random calls in > > semi-random subsystems all over the kernel. > > > > And when I ask for real data, you respond with the fact that you aren't > > trying to speed up boot time here at all, so what am I supposed to think > > I also had the understanding that this patch series was about improving > boot time. But I was kindly corrected that the behavior change was > getting the panel displaying stuff at an earlier point in the boot sequence, > _not_ completing the entire boot faster. > > The claim for the current series, in patch 0 in v7 is: > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. > > Just to get side-tracked, one other approach at ordering to reduce > deferrals reported a modest boot time reduction for four boards and a > very slight boot time increase for one other board.) The report of boot > times with that approach was in: > > http://article.gmane.org/gmane.linux.drivers.devicetree/133010 > > from Alexander Holler. > > I have not searched further to see if there is more data of boot time > reductions from any of the other attempts to change driver binding > order to move dependencies before use of a resource. But whether > there is a performance improvement or not, there continues to be > a stream of developers creatively impacting the binding order for > their specific driver(s) or board. So it seems that maybe there > is an underlying problem, or we don't have adequate documentation > explaining how to avoid a need to order bindings, or the > documentation exists and is not being read. > > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) I agree, there might be some small numbers that this is a problem for, and if so, great, show us the boot logs where things are taking up all of the time, and we can work on resolving those issues. But without hard numbers / details, this all is just random hand-waving, and I don't like making core kernel changes on that basis. And no one else should ever want us to do that either. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 22 October 2015 at 02:54, Rafael J. Wysockiwrote: > On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: >> On 20 October 2015 at 18:04, Alan Stern wrote: >> > On Tue, 20 Oct 2015, Mark Brown wrote: >> > >> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: >> >> >> >> > Furthermore, that applies only to devices that use synchronous suspend. >> >> > Async suspend is becoming common, and there the only restrictions are >> >> > parent-child relations plus whatever explicit requirements that drivers >> >> > impose by calling device_pm_wait_for_dev(). >> >> >> >> Hrm, this is the first I'd noticed that feature though I see the initial >> >> commit dates from January. >> > >> > Async suspend and device_pm_wait_for_dev() were added in January 2010, >> > not 2015! >> > >> >> It looks like most of the users are PCs at >> >> the minute but we should be using it more widely for embedded things, >> >> there's definitely some cases I'm aware of where it will allow us to >> >> remove some open coding. >> >> >> >> It does seem like we want to be feeding dependency information we >> >> discover for probing way into the suspend dependencies... >> > >> > Rafael has been thinking about a way to do this systematically. >> > Nothing concrete has emerged yet. >> >> This iteration of the series would make this quite easy, as >> dependencies are calculated before probes are attempted: >> >> https://lkml.org/lkml/2015/6/17/311 > > Well, if you know how to represent "links" between devices, the mechanism > introduced here doesn't really add much value, because in that case the > core knows what the dependencies are in the first place and can only > defer the probes that have to be deferred. By "here" you mean what you are proposing for ordering device suspends, or on-demand probing? If you meant that probing on-demand is unneeded if we already have dependency information, I agree with you and that's why I only pushed forward on-demand, as the approach linked above introduced some duplication when inferring the dependencies. Maybe that could be avoided without too much refactoring. In any case, Thierry mentioned the other day in #tegra that one could also collect dependency information as a follow up to the on-demand series by calling device_depend() or such instead of of_device_probe(). Regards, Tomeu > Thanks, > Rafael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote: > Something like this. I haven't put a lot of effort into it to change all > the places which return an -EPROBE_DEFER, and it also looks like we need > some helpers to report when we have only an device_node (or should that > be fwnode?) See the commented out of_warn_deferred() in > drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching > for resources should make debugging why things are getting deferred easier. Yeah, plus I'd expect it to also result in better error reporting overall if the subsystems are able to report when they fail to get something rather than just returning an error to the driver. > +/** > + * dev_warn_deferred() - report why a probe has been deferred > + */ > +void dev_warn_deferred(struct device *dev, const char *fmt, ...) > +{ > + if (driver_deferred_probe_report) { > + struct va_format vaf; > + va_list ap; > + > + va_start(ap, fmt); > + vaf.fmt = fmt; > + vaf.va = > + > + dev_warn(dev, "deferring probe: %pV", ); > + va_end(ap); > + } > +} > +EXPORT_SYMBOL_GPL(dev_warn_deferred); I'm not currently able to think of a nice way of writing this but I think what I'd really like to see from a driver point of view is something which decays into dev_err() if it's a non-deferral error. That way drivers can have minimal log and return error handling code and we will still get the output sensibly. The best I can think of is something like void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...) which requires the caller to pass in err twice to get it logged. That's not a thing of beauty but it gets the job done... but perhaps your original interface is better, it's a bit cleaner. signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote: > If it was such a problem, then in the _eight_ days that this has been > discussed so far, _someone_ would have sent some data showing the > problem. I think the fact is, there is no data. > Someone prove me wrong. Someone post the verifiable data showing that > there is a problem to be solved here. > Someone show what the specific failure cases are that are hampering > vendors moving forwards. Someone show the long boot times by way of > kernel message log. Someone show some evidence of the problems that > have been alluded to. > If no one can show some evidence, there isn't a problem here. :) Yeah, I'm not convinced the timing is *such* a big deal either - I do think that the log spam is a real problem but I think something much less invasive like the interface you proposed is good for addressing that. signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On 21 October 2015 at 23:50, Frank Rowandwrote: > On 10/21/2015 2:12 PM, Rob Herring wrote: >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand wrote: >>> On 10/21/2015 9:27 AM, Mark Brown wrote: On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >> To be clear, I was saying that this series should NOT affect total >> boot times much. > I'm confused. If I understood correctly, improving boot time was > the key justification for accepting this patch set. For example, > from "[PATCH v7 0/20] On-demand device probing": > >I have a problem with the panel on my Tegra Chromebook taking longer >than expected to be ready during boot (Stéphane Marchesin reported what >is basically the same issue in [0]), and have looked into ordered >probing as a better way of solving this than moving nodes around in the >DT or playing with initcall levels and linking order. > >... > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. Overall boot time and time to get some individual built in component up and running aren't the same thing - what this'll do is get things up more in the link order of the leaf consumers rather than deferring those leaf consumers when their dependencies aren't ready yet. >>> >>> Thanks! I read too much into what was being improved. >>> >>> So this patch series, which on other merits may be a good idea, is as >>> a by product solving a specific ordering issue, moving successful panel >>> initialization to an earlier point in the boot sequence, if I now >>> understand more correctly. >>> >>> In that context, this seems like yet another ad hoc way of causing the >>> probe order to change in a way to solves one specific issue? Could >>> it just as likely move the boot order of some other driver on some >>> other board later, to the detriment of somebody else? >> >> Time to display on is important for many products. Having the console >> up as early as possible is another case. CAN bus is another. This is a >> real problem that is not just bad drivers. > > Yes, I agree. > > What I am seeing is that there continues to be a need for the ability > to explicitly order at least some driver initialization (at some > granularity), despite the push back against explicit ordering that > has been present in the past. The important point that I have struggled to explain is that right now for downstreams to influence the order in which devices are probed, they have to carry a substantial amount of patches that cannot be ever upstreamed. This fiddling with initcall levels and link order means changing files that are very frequently changing, increasing the amount of work when rebasing and increasing the probability of regressions after a rebase. This just adds up to other shortcomings of mainline and ends up with the net result of vendors getting stuck with 3.4 kernels on SoCs that start production in 2015. Another consequence is that vendors don't have a chance to upstream their stuff even if they cared. The overarching goal of the project I'm in is to reduce those shortcomings that downstreams have to workaround, to facilitate their involvement upstream. With this series, the order in which devices are probed becomes the order in which they were registered, which is the order in which the devices appear in the FW description of the hw or in the board files (much more predictable, which makes for a more robust process). For DT and board files, which cover a good part of the consumer devices shipped today with Linux, the downstream could just change the order of device nodes and get their display or whatever to probe before any other devices. And even if downstream's hw has a SoC .dtsi that exists in mainline, they could add a step to their build process that automatically reorders the nodes to avoid carrying changes to that DT fragment. But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. Sorry for the rant, Tomeu >> I don't think it is completely ad hoc. Given all devices are >> registered after drivers, drivers will still probe first in initcall >> level order and then link order AFAIK. We may not take (more) initcall >> level tweak hacks, but that is a much more simple change for >> downstream. Don't get me wrong, I'd really like to see a way to >> control order independent of initcall level. >> >> Rob > > Yep, it is
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > But that's moot currently because Greg believes that the time spent > probing devices at boot time could be reduced enough so that the order > in which devices are probed becomes irrelevant. IME that would have to > be under 200ms so that the user doesn't notice and that's unicorn-far > from any bootlog I have ever seen. But as no one has actually produced a bootlog, how do you know that? Where exactly is your time being spent? What driver is causing long delays? Why is the long-delay-drivers not being done in their own thread? And most importantly, why are you ignoring the work that people did back in 2008 to solve the issue on other hardware platforms? > Given that downstreams are already carrying as many hacks as they > could think of to speed total boot up, I think this is effectively > telling them to go away. No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to solve-the-random-issue-i'm-having type patch by putting random calls in semi-random subsystems all over the kernel. And when I ask for real data, you respond with the fact that you aren't trying to speed up boot time here at all, so what am I supposed to think other than that you don't care enough to do the real work and are trying to hack the driver core up instead. > Sorry for the rant, No apologies needed, it's cathartic at times :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > On 21 October 2015 at 23:50, Frank Rowandwrote: > > On 10/21/2015 2:12 PM, Rob Herring wrote: > >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand > >> wrote: > >>> On 10/21/2015 9:27 AM, Mark Brown wrote: > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > > >> To be clear, I was saying that this series should NOT affect total > >> boot times much. > > > I'm confused. If I understood correctly, improving boot time was > > the key justification for accepting this patch set. For example, > > from "[PATCH v7 0/20] On-demand device probing": > > > >I have a problem with the panel on my Tegra Chromebook taking longer > >than expected to be ready during boot (Stéphane Marchesin reported > > what > >is basically the same issue in [0]), and have looked into ordered > >probing as a better way of solving this than moving nodes around in > > the > >DT or playing with initcall levels and linking order. > > > >... > > > >With this series I get the kernel to output to the panel in 0.5s, > >instead of 2.8s. > > Overall boot time and time to get some individual built in component up > and running aren't the same thing - what this'll do is get things up > more in the link order of the leaf consumers rather than deferring those > leaf consumers when their dependencies aren't ready yet. > >>> > >>> Thanks! I read too much into what was being improved. > >>> > >>> So this patch series, which on other merits may be a good idea, is as > >>> a by product solving a specific ordering issue, moving successful panel > >>> initialization to an earlier point in the boot sequence, if I now > >>> understand more correctly. > >>> > >>> In that context, this seems like yet another ad hoc way of causing the > >>> probe order to change in a way to solves one specific issue? Could > >>> it just as likely move the boot order of some other driver on some > >>> other board later, to the detriment of somebody else? > >> > >> Time to display on is important for many products. Having the console > >> up as early as possible is another case. CAN bus is another. This is a > >> real problem that is not just bad drivers. > > > > Yes, I agree. > > > > What I am seeing is that there continues to be a need for the ability > > to explicitly order at least some driver initialization (at some > > granularity), despite the push back against explicit ordering that > > has been present in the past. > > The important point that I have struggled to explain is that right now > for downstreams to influence the order in which devices are probed, > they have to carry a substantial amount of patches that cannot be ever > upstreamed. This fiddling with initcall levels and link order means > changing files that are very frequently changing, increasing the > amount of work when rebasing and increasing the probability of > regressions after a rebase. > > This just adds up to other shortcomings of mainline and ends up with > the net result of vendors getting stuck with 3.4 kernels on SoCs that > start production in 2015. Another consequence is that vendors don't > have a chance to upstream their stuff even if they cared. The > overarching goal of the project I'm in is to reduce those shortcomings > that downstreams have to workaround, to facilitate their involvement > upstream. The init order of drivers has no influence at all on the ability for companies to have their individual drivers merged upstream, please don't be so dramatic about this. Worst case, a vendor keeps a single patch to drivers/Makefile in their tree that reorders things, yes it will get conflicts on every release, but really, it's trivial to maintain if they wish to keep doing this type of thing. Again, it is _not_ the reason that we are living with 2million+ lines of code in vendor kernels. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote: >> > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > > Given that downstreams are already carrying as many hacks as they > > could think of to speed total boot up, I think this is effectively > > telling them to go away. > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > solve-the-random-issue-i'm-having type patch by putting random calls in > semi-random subsystems all over the kernel. +1000, fully agree. There's too much verbal diarrhoea going on in this thread and no facts. I've been waiting for real data too, and there's not one shred of it, or even a hint that it might appear. So, the conclusion I'm coming to is that there isn't any data to back up the claims made in this thread. If it was such a problem, then in the _eight_ days that this has been discussed so far, _someone_ would have sent some data showing the problem. I think the fact is, there is no data. Someone prove me wrong. Someone post the verifiable data showing that there is a problem to be solved here. Someone show what the specific failure cases are that are hampering vendors moving forwards. Someone show the long boot times by way of kernel message log. Someone show some evidence of the problems that have been alluded to. If no one can show some evidence, there isn't a problem here. :) -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Stern wrote: > > On Tue, 20 Oct 2015, Mark Brown wrote: > > > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > >> > >> > Furthermore, that applies only to devices that use synchronous suspend. > >> > Async suspend is becoming common, and there the only restrictions are > >> > parent-child relations plus whatever explicit requirements that drivers > >> > impose by calling device_pm_wait_for_dev(). > >> > >> Hrm, this is the first I'd noticed that feature though I see the initial > >> commit dates from January. > > > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > > not 2015! > > > >> It looks like most of the users are PCs at > >> the minute but we should be using it more widely for embedded things, > >> there's definitely some cases I'm aware of where it will allow us to > >> remove some open coding. > >> > >> It does seem like we want to be feeding dependency information we > >> discover for probing way into the suspend dependencies... > > > > Rafael has been thinking about a way to do this systematically. > > Nothing concrete has emerged yet. > > This iteration of the series would make this quite easy, as > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 Well, if you know how to represent "links" between devices, the mechanism introduced here doesn't really add much value, because in that case the core knows what the dependencies are in the first place and can only defer the probes that have to be deferred. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki wrote: > > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki > >> wrote: > >> > ACPI uses platform devices too. In fact, ACPI device objects are > >> > enumerated as > >> > platform devices by default now. > >> > >> Okay, I should have grepped for that: > >> drivers/base/platform.c:ACPI_COMPANION_SET(>dev, > >> NULL); > >> drivers/base/platform.c:len = acpi_device_modalias(dev, buf, > >> PAGE_SIZE -1); > >> drivers/base/platform.c:rc = acpi_device_uevent_modalias(dev, env); > >> drivers/base/platform.c:/* Then try ACPI style match */ > >> drivers/base/platform.c:if (acpi_driver_match_device(dev, drv)) > >> > >> These are all cases which have DT version as well, so we're not really > >> all that different here. There's a few more for DT, but that probably > >> means you have just not hit the problems we have yet. For example, > >> what happens if you have an interrupt line in which the controller is > >> probed after the device connected to the interrupt line? That required > >> resolving irqs in platform_get_irq rather than using static resources > >> to support deferred probe. > > > > We don't have this particular problem, because the IRQ controllers are > > enumerated in a special way. > > What does "in a special way" mean? Can you please be more specific? > > Can you have interrupt controllers that depend on clocks, pin controllers, > and PM domains? Currently, there's no native way to represent those dependencies in ACPI. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 10/21/2015 2:12 PM, Rob Herring wrote: > On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand wrote: >> On 10/21/2015 9:27 AM, Mark Brown wrote: >>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >>> > To be clear, I was saying that this series should NOT affect total > boot times much. >>> I'm confused. If I understood correctly, improving boot time was the key justification for accepting this patch set. For example, from "[PATCH v7 0/20] On-demand device probing": I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels and linking order. ... With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. >>> >>> Overall boot time and time to get some individual built in component up >>> and running aren't the same thing - what this'll do is get things up >>> more in the link order of the leaf consumers rather than deferring those >>> leaf consumers when their dependencies aren't ready yet. >> >> Thanks! I read too much into what was being improved. >> >> So this patch series, which on other merits may be a good idea, is as >> a by product solving a specific ordering issue, moving successful panel >> initialization to an earlier point in the boot sequence, if I now >> understand more correctly. >> >> In that context, this seems like yet another ad hoc way of causing the >> probe order to change in a way to solves one specific issue? Could >> it just as likely move the boot order of some other driver on some >> other board later, to the detriment of somebody else? > > Time to display on is important for many products. Having the console > up as early as possible is another case. CAN bus is another. This is a > real problem that is not just bad drivers. Yes, I agree. What I am seeing is that there continues to be a need for the ability to explicitly order at least some driver initialization (at some granularity), despite the push back against explicit ordering that has been present in the past. > I don't think it is completely ad hoc. Given all devices are > registered after drivers, drivers will still probe first in initcall > level order and then link order AFAIK. We may not take (more) initcall > level tweak hacks, but that is a much more simple change for > downstream. Don't get me wrong, I'd really like to see a way to > control order independent of initcall level. > > Rob Yep, it is not directly ad hoc, just a fortunate side effect in this case. So just accidently ad hoc. :-) -Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: >> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >> To be clear, I was saying that this series should NOT affect total boot times much. >> >>> I'm confused. If I understood correctly, improving boot time was >>> the key justification for accepting this patch set. For example, >>> from "[PATCH v7 0/20] On-demand device probing": >>> >>>I have a problem with the panel on my Tegra Chromebook taking longer >>>than expected to be ready during boot (Stéphane Marchesin reported what >>>is basically the same issue in [0]), and have looked into ordered >>>probing as a better way of solving this than moving nodes around in the >>>DT or playing with initcall levels and linking order. >>> >>>... >>> >>>With this series I get the kernel to output to the panel in 0.5s, >>>instead of 2.8s. >> >> Overall boot time and time to get some individual built in component up >> and running aren't the same thing - what this'll do is get things up >> more in the link order of the leaf consumers rather than deferring those >> leaf consumers when their dependencies aren't ready yet. > > Thanks! I read too much into what was being improved. > > So this patch series, which on other merits may be a good idea, is as > a by product solving a specific ordering issue, moving successful panel > initialization to an earlier point in the boot sequence, if I now > understand more correctly. > > In that context, this seems like yet another ad hoc way of causing the > probe order to change in a way to solves one specific issue? Could > it just as likely move the boot order of some other driver on some > other board later, to the detriment of somebody else? Time to display on is important for many products. Having the console up as early as possible is another case. CAN bus is another. This is a real problem that is not just bad drivers. I don't think it is completely ad hoc. Given all devices are registered after drivers, drivers will still probe first in initcall level order and then link order AFAIK. We may not take (more) initcall level tweak hacks, but that is a much more simple change for downstream. Don't get me wrong, I'd really like to see a way to control order independent of initcall level. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: > > Overall boot time and time to get some individual built in component up > > and running aren't the same thing - what this'll do is get things up > > more in the link order of the leaf consumers rather than deferring those > > leaf consumers when their dependencies aren't ready yet. > Thanks! I read too much into what was being improved. > So this patch series, which on other merits may be a good idea, is as > a by product solving a specific ordering issue, moving successful panel > initialization to an earlier point in the boot sequence, if I now > understand more correctly. Yeah, that's my understanding. > In that context, this seems like yet another ad hoc way of causing the > probe order to change in a way to solves one specific issue? Could > it just as likely move the boot order of some other driver on some > other board later, to the detriment of somebody else? Indeed. My general feeling is that it does make the link order stuff more predictable and easier to work with and it does have other merits (in terms of the error reporting, though there's other ways to address that like the one Russell is proposing). signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On 10/21/2015 9:27 AM, Mark Brown wrote: > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > >>> To be clear, I was saying that this series should NOT affect total >>> boot times much. > >> I'm confused. If I understood correctly, improving boot time was >> the key justification for accepting this patch set. For example, >> from "[PATCH v7 0/20] On-demand device probing": >> >>I have a problem with the panel on my Tegra Chromebook taking longer >>than expected to be ready during boot (Stéphane Marchesin reported what >>is basically the same issue in [0]), and have looked into ordered >>probing as a better way of solving this than moving nodes around in the >>DT or playing with initcall levels and linking order. >> >>... >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. > > Overall boot time and time to get some individual built in component up > and running aren't the same thing - what this'll do is get things up > more in the link order of the leaf consumers rather than deferring those > leaf consumers when their dependencies aren't ready yet. Thanks! I read too much into what was being improved. So this patch series, which on other merits may be a good idea, is as a by product solving a specific ordering issue, moving successful panel initialization to an earlier point in the boot sequence, if I now understand more correctly. In that context, this seems like yet another ad hoc way of causing the probe order to change in a way to solves one specific issue? Could it just as likely move the boot order of some other driver on some other board later, to the detriment of somebody else? > >> While not as dramatic as your results, they are somewhat supportive. >> What has changed your assessment that the on-demand device probing >> patches will give a big boot performance increase? Do you have >> new data or analysis? > > See above, my understanding was that the performance improvements were > more around improved control/predictability/handwave of the boot > ordering rather than total time. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > > To be clear, I was saying that this series should NOT affect total > > boot times much. > I'm confused. If I understood correctly, improving boot time was > the key justification for accepting this patch set. For example, > from "[PATCH v7 0/20] On-demand device probing": > >I have a problem with the panel on my Tegra Chromebook taking longer >than expected to be ready during boot (Stéphane Marchesin reported what >is basically the same issue in [0]), and have looked into ordered >probing as a better way of solving this than moving nodes around in the >DT or playing with initcall levels and linking order. > >... > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. Overall boot time and time to get some individual built in component up and running aren't the same thing - what this'll do is get things up more in the link order of the leaf consumers rather than deferring those leaf consumers when their dependencies aren't ready yet. > While not as dramatic as your results, they are somewhat supportive. > What has changed your assessment that the on-demand device probing > patches will give a big boot performance increase? Do you have > new data or analysis? See above, my understanding was that the performance improvements were more around improved control/predictability/handwave of the boot ordering rather than total time. signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > On 18 October 2015 at 21:53, Mark Brown wrote: >> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote: >>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote: On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: < snip > > hope you don't mind I summarize the points taken instead of replying > to the individual emails. I tried to address all the concerns that > have been raised again in the cover letter, but I guess I did a bad > job at explaining myself, so here's another (more in-depth) go at it. < snip > > 3) Regarding total boot time, I don't expect this series to make much > of a difference because though we would save a lot of matching and > querying for resources, that's little time compared with how long we > wait for hardware to react during probing. Async probing is more > likely to help with drivers that take a long time to probe. And then in your reply to Russell's reply to your email you say: > To be clear, I was saying that this series should NOT affect total > boot times much. I'm confused. If I understood correctly, improving boot time was the key justification for accepting this patch set. For example, from "[PATCH v7 0/20] On-demand device probing": I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels and linking order. ... With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Alexander Holler reported improved boot times for his patch set in August, which is another approach to ordering probes (http://article.gmane.org/gmane.linux.drivers.devicetree/133010). His results for 5 boards was four booted faster, one slightly slower: Some numbers (5 boots on each board, without and with ordering drivers), all times are seconds. Kirkwood (dockstar, armv5): Boot to "Freeing unused kernel memory" (includes mounting the rootfs), unordered: 4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222) ordered: 3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988) Time needed to sort (of_init_build_order()): 0.003024 Time needed to match drivers to the order (without calling them): 0.002884 Beagleboard (rev C4, armv7): unordered: 6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465) ordered: 5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096) sorting: 0.021209 matching: 0.006165 Beaglebone Black (rev A5, armv7): unordered: 3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076) ordered: 2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446) sorting: 0.004769 matching: 0.004860 imx6q (armv7): unordered: 3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568) ordered: 3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134) sorting: 0.004622 matching: 0.003868 While not as dramatic as your results, they are somewhat supportive. What has changed your assessment that the on-demand device probing patches will give a big boot performance increase? Do you have new data or analysis? -Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Hi Rafael, On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki wrote: > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki >> wrote: >> > ACPI uses platform devices too. In fact, ACPI device objects are >> > enumerated as >> > platform devices by default now. >> >> Okay, I should have grepped for that: >> drivers/base/platform.c:ACPI_COMPANION_SET(>dev, NULL); >> drivers/base/platform.c:len = acpi_device_modalias(dev, buf, >> PAGE_SIZE -1); >> drivers/base/platform.c:rc = acpi_device_uevent_modalias(dev, env); >> drivers/base/platform.c:/* Then try ACPI style match */ >> drivers/base/platform.c:if (acpi_driver_match_device(dev, drv)) >> >> These are all cases which have DT version as well, so we're not really >> all that different here. There's a few more for DT, but that probably >> means you have just not hit the problems we have yet. For example, >> what happens if you have an interrupt line in which the controller is >> probed after the device connected to the interrupt line? That required >> resolving irqs in platform_get_irq rather than using static resources >> to support deferred probe. > > We don't have this particular problem, because the IRQ controllers are > enumerated in a special way. What does "in a special way" mean? Can you please be more specific? Can you have interrupt controllers that depend on clocks, pin controllers, and PM domains? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Sorry to enter this thread a bit late. About the number of probe deferred messages, I proposed a simple patch to reduce them: https://lkml.org/lkml/2013/8/20/218 I was wondering how many messages this patch could save... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > > To be clear, I was saying that this series should NOT affect total > > boot times much. > I'm confused. If I understood correctly, improving boot time was > the key justification for accepting this patch set. For example, > from "[PATCH v7 0/20] On-demand device probing": > >I have a problem with the panel on my Tegra Chromebook taking longer >than expected to be ready during boot (Stéphane Marchesin reported what >is basically the same issue in [0]), and have looked into ordered >probing as a better way of solving this than moving nodes around in the >DT or playing with initcall levels and linking order. > >... > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. Overall boot time and time to get some individual built in component up and running aren't the same thing - what this'll do is get things up more in the link order of the leaf consumers rather than deferring those leaf consumers when their dependencies aren't ready yet. > While not as dramatic as your results, they are somewhat supportive. > What has changed your assessment that the on-demand device probing > patches will give a big boot performance increase? Do you have > new data or analysis? See above, my understanding was that the performance improvements were more around improved control/predictability/handwave of the boot ordering rather than total time. signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > On 18 October 2015 at 21:53, Mark Brownwrote: >> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote: >>> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote: On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: < snip > > hope you don't mind I summarize the points taken instead of replying > to the individual emails. I tried to address all the concerns that > have been raised again in the cover letter, but I guess I did a bad > job at explaining myself, so here's another (more in-depth) go at it. < snip > > 3) Regarding total boot time, I don't expect this series to make much > of a difference because though we would save a lot of matching and > querying for resources, that's little time compared with how long we > wait for hardware to react during probing. Async probing is more > likely to help with drivers that take a long time to probe. And then in your reply to Russell's reply to your email you say: > To be clear, I was saying that this series should NOT affect total > boot times much. I'm confused. If I understood correctly, improving boot time was the key justification for accepting this patch set. For example, from "[PATCH v7 0/20] On-demand device probing": I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels and linking order. ... With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Alexander Holler reported improved boot times for his patch set in August, which is another approach to ordering probes (http://article.gmane.org/gmane.linux.drivers.devicetree/133010). His results for 5 boards was four booted faster, one slightly slower: Some numbers (5 boots on each board, without and with ordering drivers), all times are seconds. Kirkwood (dockstar, armv5): Boot to "Freeing unused kernel memory" (includes mounting the rootfs), unordered: 4.456016 3.937801 4.114788 4.114526 3.949480 (average 4.1145222) ordered: 3.173054 3.164045 3.141418 3.480679 3.459298 (3.2836988) Time needed to sort (of_init_build_order()): 0.003024 Time needed to match drivers to the order (without calling them): 0.002884 Beagleboard (rev C4, armv7): unordered: 6.706024 6.821746 6.696014 6.673675 6.769866 (6.733465) ordered: 5.544860 5.514160 5.505859 5.527374 5.496795 (5.5178096) sorting: 0.021209 matching: 0.006165 Beaglebone Black (rev A5, armv7): unordered: 3.826531 3.825662 3.826648 3.825434 3.825263 (3.8259076) ordered: 2.838554 2.838322 2.839459 2.838467 2.838421 (2.8386446) sorting: 0.004769 matching: 0.004860 imx6q (armv7): unordered: 3.451998 3.418864 3.446952 3.429974 3.440996 (3.4377568) ordered: 3.538312 3.549019 3.538105 3.515916 3.555715 (3.5394134) sorting: 0.004622 matching: 0.003868 While not as dramatic as your results, they are somewhat supportive. What has changed your assessment that the on-demand device probing patches will give a big boot performance increase? Do you have new data or analysis? -Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 10/21/2015 9:27 AM, Mark Brown wrote: > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > >>> To be clear, I was saying that this series should NOT affect total >>> boot times much. > >> I'm confused. If I understood correctly, improving boot time was >> the key justification for accepting this patch set. For example, >> from "[PATCH v7 0/20] On-demand device probing": >> >>I have a problem with the panel on my Tegra Chromebook taking longer >>than expected to be ready during boot (Stéphane Marchesin reported what >>is basically the same issue in [0]), and have looked into ordered >>probing as a better way of solving this than moving nodes around in the >>DT or playing with initcall levels and linking order. >> >>... >> >>With this series I get the kernel to output to the panel in 0.5s, >>instead of 2.8s. > > Overall boot time and time to get some individual built in component up > and running aren't the same thing - what this'll do is get things up > more in the link order of the leaf consumers rather than deferring those > leaf consumers when their dependencies aren't ready yet. Thanks! I read too much into what was being improved. So this patch series, which on other merits may be a good idea, is as a by product solving a specific ordering issue, moving successful panel initialization to an earlier point in the boot sequence, if I now understand more correctly. In that context, this seems like yet another ad hoc way of causing the probe order to change in a way to solves one specific issue? Could it just as likely move the boot order of some other driver on some other board later, to the detriment of somebody else? > >> While not as dramatic as your results, they are somewhat supportive. >> What has changed your assessment that the on-demand device probing >> patches will give a big boot performance increase? Do you have >> new data or analysis? > > See above, my understanding was that the performance improvements were > more around improved control/predictability/handwave of the boot > ordering rather than total time. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: > > Overall boot time and time to get some individual built in component up > > and running aren't the same thing - what this'll do is get things up > > more in the link order of the leaf consumers rather than deferring those > > leaf consumers when their dependencies aren't ready yet. > Thanks! I read too much into what was being improved. > So this patch series, which on other merits may be a good idea, is as > a by product solving a specific ordering issue, moving successful panel > initialization to an earlier point in the boot sequence, if I now > understand more correctly. Yeah, that's my understanding. > In that context, this seems like yet another ad hoc way of causing the > probe order to change in a way to solves one specific issue? Could > it just as likely move the boot order of some other driver on some > other board later, to the detriment of somebody else? Indeed. My general feeling is that it does make the link order stuff more predictable and easier to work with and it does have other merits (in terms of the error reporting, though there's other ways to address that like the one Russell is proposing). signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowandwrote: > On 10/21/2015 9:27 AM, Mark Brown wrote: >> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: >>> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >> To be clear, I was saying that this series should NOT affect total boot times much. >> >>> I'm confused. If I understood correctly, improving boot time was >>> the key justification for accepting this patch set. For example, >>> from "[PATCH v7 0/20] On-demand device probing": >>> >>>I have a problem with the panel on my Tegra Chromebook taking longer >>>than expected to be ready during boot (Stéphane Marchesin reported what >>>is basically the same issue in [0]), and have looked into ordered >>>probing as a better way of solving this than moving nodes around in the >>>DT or playing with initcall levels and linking order. >>> >>>... >>> >>>With this series I get the kernel to output to the panel in 0.5s, >>>instead of 2.8s. >> >> Overall boot time and time to get some individual built in component up >> and running aren't the same thing - what this'll do is get things up >> more in the link order of the leaf consumers rather than deferring those >> leaf consumers when their dependencies aren't ready yet. > > Thanks! I read too much into what was being improved. > > So this patch series, which on other merits may be a good idea, is as > a by product solving a specific ordering issue, moving successful panel > initialization to an earlier point in the boot sequence, if I now > understand more correctly. > > In that context, this seems like yet another ad hoc way of causing the > probe order to change in a way to solves one specific issue? Could > it just as likely move the boot order of some other driver on some > other board later, to the detriment of somebody else? Time to display on is important for many products. Having the console up as early as possible is another case. CAN bus is another. This is a real problem that is not just bad drivers. I don't think it is completely ad hoc. Given all devices are registered after drivers, drivers will still probe first in initcall level order and then link order AFAIK. We may not take (more) initcall level tweak hacks, but that is a much more simple change for downstream. Don't get me wrong, I'd really like to see a way to control order independent of initcall level. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 10/21/2015 2:12 PM, Rob Herring wrote: > On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowandwrote: >> On 10/21/2015 9:27 AM, Mark Brown wrote: >>> On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >>> > To be clear, I was saying that this series should NOT affect total > boot times much. >>> I'm confused. If I understood correctly, improving boot time was the key justification for accepting this patch set. For example, from "[PATCH v7 0/20] On-demand device probing": I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels and linking order. ... With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. >>> >>> Overall boot time and time to get some individual built in component up >>> and running aren't the same thing - what this'll do is get things up >>> more in the link order of the leaf consumers rather than deferring those >>> leaf consumers when their dependencies aren't ready yet. >> >> Thanks! I read too much into what was being improved. >> >> So this patch series, which on other merits may be a good idea, is as >> a by product solving a specific ordering issue, moving successful panel >> initialization to an earlier point in the boot sequence, if I now >> understand more correctly. >> >> In that context, this seems like yet another ad hoc way of causing the >> probe order to change in a way to solves one specific issue? Could >> it just as likely move the boot order of some other driver on some >> other board later, to the detriment of somebody else? > > Time to display on is important for many products. Having the console > up as early as possible is another case. CAN bus is another. This is a > real problem that is not just bad drivers. Yes, I agree. What I am seeing is that there continues to be a need for the ability to explicitly order at least some driver initialization (at some granularity), despite the push back against explicit ordering that has been present in the past. > I don't think it is completely ad hoc. Given all devices are > registered after drivers, drivers will still probe first in initcall > level order and then link order AFAIK. We may not take (more) initcall > level tweak hacks, but that is a much more simple change for > downstream. Don't get me wrong, I'd really like to see a way to > control order independent of initcall level. > > Rob Yep, it is not directly ad hoc, just a fortunate side effect in this case. So just accidently ad hoc. :-) -Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysockiwrote: > > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki > >> wrote: > >> > ACPI uses platform devices too. In fact, ACPI device objects are > >> > enumerated as > >> > platform devices by default now. > >> > >> Okay, I should have grepped for that: > >> drivers/base/platform.c:ACPI_COMPANION_SET(>dev, > >> NULL); > >> drivers/base/platform.c:len = acpi_device_modalias(dev, buf, > >> PAGE_SIZE -1); > >> drivers/base/platform.c:rc = acpi_device_uevent_modalias(dev, env); > >> drivers/base/platform.c:/* Then try ACPI style match */ > >> drivers/base/platform.c:if (acpi_driver_match_device(dev, drv)) > >> > >> These are all cases which have DT version as well, so we're not really > >> all that different here. There's a few more for DT, but that probably > >> means you have just not hit the problems we have yet. For example, > >> what happens if you have an interrupt line in which the controller is > >> probed after the device connected to the interrupt line? That required > >> resolving irqs in platform_get_irq rather than using static resources > >> to support deferred probe. > > > > We don't have this particular problem, because the IRQ controllers are > > enumerated in a special way. > > What does "in a special way" mean? Can you please be more specific? > > Can you have interrupt controllers that depend on clocks, pin controllers, > and PM domains? Currently, there's no native way to represent those dependencies in ACPI. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Sternwrote: > > On Tue, 20 Oct 2015, Mark Brown wrote: > > > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > >> > >> > Furthermore, that applies only to devices that use synchronous suspend. > >> > Async suspend is becoming common, and there the only restrictions are > >> > parent-child relations plus whatever explicit requirements that drivers > >> > impose by calling device_pm_wait_for_dev(). > >> > >> Hrm, this is the first I'd noticed that feature though I see the initial > >> commit dates from January. > > > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > > not 2015! > > > >> It looks like most of the users are PCs at > >> the minute but we should be using it more widely for embedded things, > >> there's definitely some cases I'm aware of where it will allow us to > >> remove some open coding. > >> > >> It does seem like we want to be feeding dependency information we > >> discover for probing way into the suspend dependencies... > > > > Rafael has been thinking about a way to do this systematically. > > Nothing concrete has emerged yet. > > This iteration of the series would make this quite easy, as > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 Well, if you know how to represent "links" between devices, the mechanism introduced here doesn't really add much value, because in that case the core knows what the dependencies are in the first place and can only defer the probes that have to be deferred. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Sorry to enter this thread a bit late. About the number of probe deferred messages, I proposed a simple patch to reduce them: https://lkml.org/lkml/2013/8/20/218 I was wondering how many messages this patch could save... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Hi Rafael, On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysockiwrote: > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki >> wrote: >> > ACPI uses platform devices too. In fact, ACPI device objects are >> > enumerated as >> > platform devices by default now. >> >> Okay, I should have grepped for that: >> drivers/base/platform.c:ACPI_COMPANION_SET(>dev, NULL); >> drivers/base/platform.c:len = acpi_device_modalias(dev, buf, >> PAGE_SIZE -1); >> drivers/base/platform.c:rc = acpi_device_uevent_modalias(dev, env); >> drivers/base/platform.c:/* Then try ACPI style match */ >> drivers/base/platform.c:if (acpi_driver_match_device(dev, drv)) >> >> These are all cases which have DT version as well, so we're not really >> all that different here. There's a few more for DT, but that probably >> means you have just not hit the problems we have yet. For example, >> what happens if you have an interrupt line in which the controller is >> probed after the device connected to the interrupt line? That required >> resolving irqs in platform_get_irq rather than using static resources >> to support deferred probe. > > We don't have this particular problem, because the IRQ controllers are > enumerated in a special way. What does "in a special way" mean? Can you please be more specific? Can you have interrupt controllers that depend on clocks, pin controllers, and PM domains? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote: > > --7fVr/IRGAG9sAW4J > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote: > > On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > > > > This iteration of the series would make this quite easy, as > > > dependencies are calculated before probes are attempted: > > > > https://lkml.org/lkml/2015/6/17/311 > > > But what Rafael is proposing is quite general; it would apply to _all_ > > dependencies as opposed to just those present in DT drivers or those=20 > > affecting platform_devices. > > We'll still need most of the DT bits that are there at the minute (the > ones strewn around the subsystems) AFAICT since it's at the point where > we parse the DT and work out what the dependencies are which we probably > want to do prior to getting the drivers up and will be different for > ACPI. I think the level of DT dependency here looks a lot larger than > it actually is due to the fact that a lot of what's being modified is DT > parsing code. Right, something will have to register the dependency, or a "link" between devices, with the core once we find out that the dependency is there. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki wrote: > > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote: > >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki > >> wrote: > >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse > >> >> wrote: > >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > >> >> >> > But the point I'm making is that we are working towards *fixing* > >> >> >> > that, > >> >> >> > and *not* using DT-specific code in places where we should be > >> >> >> > using the > >> >> >> > generic APIs. > >> >> >> > >> >> >> What is the plan for fixing things here? It's not obvious (at least > >> >> >> to > >> >> >> me) that we don't want to have the subsystems having knowledge of how > >> >> >> they are bound to a specific firmware which is what you seem to imply > >> >> >> here. > >> >> > > >> >> > I don't know that there *is* a coherent plan here to address it all. > >> >> > > >> >> > Certainly, we *will* need subsystems to have firmware-specific > >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > >> >> > describe GPIO, and properties which reference GPIO pins are intended > >> >> > to > >> >> > work through that — while in DT, properties which reference GPIO pins > >> >> > will have different contents. They'll be compatible at the driver > >> >> > level, in the sense that there's a call to get a given GPIO given the > >> >> > property name, but the subsystems *will* be doing different things > >> >> > behind the scenes. > >> >> > > >> >> > My plan, such as it is, is to go through the leaf-node drivers which > >> >> > almost definitely *should* be firmware-agnostic, and convert those. > >> >> > And > >> >> > then take stock of what we have left, and work out what, if anything, > >> >> > still needs to be done. > >> >> > >> >> Many cases are already agnostic in the drivers in terms of the *_get() > >> >> functions. Some are DT specific, but probably because those subsystems > >> >> are new and DT only. In any case, I don't think these 1 line changes > >> >> do anything to make doing conversions here harder. > >> >> > >> >> >> It seems like we're going to have to refactor these bits of code when > >> >> >> they get generalised anyway so I'm not sure that the additional cost > >> >> >> here is that big. > >> >> > > >> >> > That's an acceptable answer — "we're adding legacy code here but we > >> >> > know it's going to be refactored anyway". If that's true, all it takes > >> >> > is a note in the commit comment to that effect. That's different from > >> >> > having not thought about it :) > >> >> > >> >> Considering at one point we did create a fwnode based API, we did > >> >> think about it. Plus there was little input from ACPI folks as to > >> >> whether the change was even useful for ACPI case. > >> > > >> > Well, sorry, but who was asking whom, specifically? > >> > >> You and linux-acpi have been copied on v2 and later of the entire > >> series I think. > > > > Yes, but it wasn't like a direct request, say "We need your input, so can > > you > > please have a look and BTW we want this in 4.4, so please do it ASAP". In > > which case I'd prioritize that before other things I needed to take care of. > > Fair enough. Can you please review and comment on v7 of the series? We > can discuss at KS as well. I'll do that. I'm in the middle of travel right now and speaking at a conference tomorrow, so I may not be able to get to that for a couple of days, but will do my best to do it as soon as I possibly can. > >> > The underlying problem is present in ACPI too and we don't really have a > >> > good > >> > solution for it. We might benefit from a common one if it existed. > >> > >> The problem for DT is we don't generically know what are the > >> dependencies at a core level. We could know some or most dependencies > >> if phandles (links to other nodes) were typed, but they are not. If > >> the core had this information, we could simply control the device > >> creation to order probing. Instead, this information is encoded into > >> the bindings and binding parsing resides in the subsystems. That > >> parsing happens during probe of the client side and is done by the > >> subsystems (for common bindings). Since we already do the parsing at > >> this point, it is a convenient place to trigger the probe of the > >> dependency. Is ACPI going to be similar in this regard? > > > > It is similar in some ways. For example, if a device's functionality > > depends > > on an I2C resource (connection), the core doesn't know that at the device > > creation time at least in some cases. Same for GPIO, SPI, DMA engines etc. > > So you will need to create devices, defer their probing and then probe > on demand as well unless you have other ideas how you would do it. Right. > > There is a _DEP object in ACPI
Re: [GIT PULL] On-demand device probing
On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote: > On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > > This iteration of the series would make this quite easy, as > > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 > But what Rafael is proposing is quite general; it would apply to _all_ > dependencies as opposed to just those present in DT drivers or those > affecting platform_devices. We'll still need most of the DT bits that are there at the minute (the ones strewn around the subsystems) AFAICT since it's at the point where we parse the DT and work out what the dependencies are which we probably want to do prior to getting the drivers up and will be different for ACPI. I think the level of DT dependency here looks a lot larger than it actually is due to the fact that a lot of what's being modified is DT parsing code. signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Stern wrote: > > On Tue, 20 Oct 2015, Mark Brown wrote: > > > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > >> > >> > Furthermore, that applies only to devices that use synchronous suspend. > >> > Async suspend is becoming common, and there the only restrictions are > >> > parent-child relations plus whatever explicit requirements that drivers > >> > impose by calling device_pm_wait_for_dev(). > >> > >> Hrm, this is the first I'd noticed that feature though I see the initial > >> commit dates from January. > > > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > > not 2015! > > > >> It looks like most of the users are PCs at > >> the minute but we should be using it more widely for embedded things, > >> there's definitely some cases I'm aware of where it will allow us to > >> remove some open coding. > >> > >> It does seem like we want to be feeding dependency information we > >> discover for probing way into the suspend dependencies... > > > > Rafael has been thinking about a way to do this systematically. > > Nothing concrete has emerged yet. > > This iteration of the series would make this quite easy, as > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 But what Rafael is proposing is quite general; it would apply to _all_ dependencies as opposed to just those present in DT drivers or those affecting platform_devices. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On 20 October 2015 at 18:04, Alan Stern wrote: > On Tue, 20 Oct 2015, Mark Brown wrote: > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: >> >> > Furthermore, that applies only to devices that use synchronous suspend. >> > Async suspend is becoming common, and there the only restrictions are >> > parent-child relations plus whatever explicit requirements that drivers >> > impose by calling device_pm_wait_for_dev(). >> >> Hrm, this is the first I'd noticed that feature though I see the initial >> commit dates from January. > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > not 2015! > >> It looks like most of the users are PCs at >> the minute but we should be using it more widely for embedded things, >> there's definitely some cases I'm aware of where it will allow us to >> remove some open coding. >> >> It does seem like we want to be feeding dependency information we >> discover for probing way into the suspend dependencies... > > Rafael has been thinking about a way to do this systematically. > Nothing concrete has emerged yet. This iteration of the series would make this quite easy, as dependencies are calculated before probes are attempted: https://lkml.org/lkml/2015/6/17/311 Regards, Tomeu > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tue, 20 Oct 2015, Mark Brown wrote: > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > Furthermore, that applies only to devices that use synchronous suspend. > > Async suspend is becoming common, and there the only restrictions are > > parent-child relations plus whatever explicit requirements that drivers > > impose by calling device_pm_wait_for_dev(). > > Hrm, this is the first I'd noticed that feature though I see the initial > commit dates from January. Async suspend and device_pm_wait_for_dev() were added in January 2010, not 2015! > It looks like most of the users are PCs at > the minute but we should be using it more widely for embedded things, > there's definitely some cases I'm aware of where it will allow us to > remove some open coding. > > It does seem like we want to be feeding dependency information we > discover for probing way into the suspend dependencies... Rafael has been thinking about a way to do this systematically. Nothing concrete has emerged yet. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux > wrote: > >> > What you can do is print those devices which have failed to probe at > >> > late_initcall() time - possibly augmenting that with reports from > >> > subsystems showing what resources are not available, but that's only > >> > a guide, because of the "it might or might not be in a kernel module" > >> > problem. > >> > >> Well, adding those reports would give you a changelog similar to the > >> one in this series... > > > > I'm not sure about that, because what I was thinking of is adding > > a flag which would be set at late_initcall() time prior to running > > a final round of deferred device probing. > > Which round is the final round? > That's the one which didn't manage to bind any new devices to drivers, > which is something you only know _after_ the round has been run. > > So I think we need one extra round to handle this. > > > This flag would then be used in a deferred_warn() printk function > > which would normally be silent, but when this flag is set, it would > > print the reason for the deferral - and this would replace (or be > > added) to the subsystems and drivers which return -EPROBE_DEFER. > > > > That has the effect of hiding all the deferrals up until just before > > launching into userspace, which should then acomplish two things - > > firstly, getting rid of the rather useless deferred messages up to > > that point, and secondly printing the reason why the remaining > > deferrals are happening. > > > > That should be a small number of new lines plus a one-line change > > in subsystems and drivers. > > Apart from the extra round we probably can't get rid of, that sounds OK to me. Something like this. I haven't put a lot of effort into it to change all the places which return an -EPROBE_DEFER, and it also looks like we need some helpers to report when we have only an device_node (or should that be fwnode?) See the commented out of_warn_deferred() in drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching for resources should make debugging why things are getting deferred easier. We could make driver_deferred_probe_report something that can be deactivated again after the last deferred probe run, and provide the user with a knob that they can turn it back on again. I've tried this out on two of my platforms, including forcing driver_deferred_probe_report to be enabled, and I get exactly one deferred probe, so not a particularly good test. The patch won't apply as-is to mainline for all files; it's based on my tree which has some 360 additional patches (which seems to be about normal for my tree now.) drivers/base/dd.c | 29 + drivers/base/power/domain.c | 7 +-- drivers/clk/clkdev.c| 9 - drivers/gpio/gpiolib-of.c | 5 + drivers/gpu/drm/bridge/dw_hdmi.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/imx/imx-ldb.c | 5 +++-- drivers/gpu/drm/msm/dsi/dsi.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 3 ++- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 ++- drivers/of/irq.c| 5 - drivers/pci/host/pci-mvebu.c| 1 + drivers/pinctrl/core.c | 5 +++-- drivers/pinctrl/devicetree.c| 4 ++-- drivers/regulator/core.c| 5 +++-- include/linux/device.h | 1 + 16 files changed, 71 insertions(+), 17 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index be0eb4639128..bb12224f2901 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev) mutex_unlock(_probe_mutex); } +static bool driver_deferred_probe_report; + +/** + * dev_warn_deferred() - report why a probe has been deferred + */ +void dev_warn_deferred(struct device *dev, const char *fmt, ...) +{ + if (driver_deferred_probe_report) { + struct va_format vaf; + va_list ap; + + va_start(ap, fmt); + vaf.fmt = fmt; + vaf.va = + + dev_warn(dev, "deferring probe: %pV", ); + va_end(ap); + } +} +EXPORT_SYMBOL_GPL(dev_warn_deferred); + static bool driver_deferred_probe_enable = false; + /** * driver_deferred_probe_trigger() - Kick off re-probing deferred devices * @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void) driver_deferred_probe_trigger(); /* Sort as many dependencies as possible before exiting initcalls */ flush_workqueue(deferred_wq); + + /* Now one final round, reporting any devices that remain deferred */ + driver_deferred_probe_report = true; + driver_deferred_probe_trigger(); + /* Sort as many dependencies as
Re: [GIT PULL] On-demand device probing
On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > Furthermore, that applies only to devices that use synchronous suspend. > Async suspend is becoming common, and there the only restrictions are > parent-child relations plus whatever explicit requirements that drivers > impose by calling device_pm_wait_for_dev(). Hrm, this is the first I'd noticed that feature though I see the initial commit dates from January. It looks like most of the users are PCs at the minute but we should be using it more widely for embedded things, there's definitely some cases I'm aware of where it will allow us to remove some open coding. It does seem like we want to be feeding dependency information we discover for probing way into the suspend dependencies... signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Tue, 20 Oct 2015, Rob Herring wrote: > > The probe ordering is not the entire picture, though. > > > > Even if you get the probe ordering right, the problem is going to show up in > > multiple other places: system suspend/resume, runtime PM, system shutdown, > > unbinding of drivers. In all of those cases it is necessary to handle > > things > > in a specific order if there is a dependency. > > My understanding was with deferred probe that it also solves suspend > ordering problems because things are suspended in reverse order of > probing. Devices are suspended in reverse order of _registration_. Not of probing. Furthermore, that applies only to devices that use synchronous suspend. Async suspend is becoming common, and there the only restrictions are parent-child relations plus whatever explicit requirements that drivers impose by calling device_pm_wait_for_dev(). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki wrote: > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote: >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki >> wrote: >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse >> >> wrote: >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: >> >> >> > But the point I'm making is that we are working towards *fixing* >> >> >> > that, >> >> >> > and *not* using DT-specific code in places where we should be using >> >> >> > the >> >> >> > generic APIs. >> >> >> >> >> >> What is the plan for fixing things here? It's not obvious (at least to >> >> >> me) that we don't want to have the subsystems having knowledge of how >> >> >> they are bound to a specific firmware which is what you seem to imply >> >> >> here. >> >> > >> >> > I don't know that there *is* a coherent plan here to address it all. >> >> > >> >> > Certainly, we *will* need subsystems to have firmware-specific >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to >> >> > describe GPIO, and properties which reference GPIO pins are intended to >> >> > work through that — while in DT, properties which reference GPIO pins >> >> > will have different contents. They'll be compatible at the driver >> >> > level, in the sense that there's a call to get a given GPIO given the >> >> > property name, but the subsystems *will* be doing different things >> >> > behind the scenes. >> >> > >> >> > My plan, such as it is, is to go through the leaf-node drivers which >> >> > almost definitely *should* be firmware-agnostic, and convert those. And >> >> > then take stock of what we have left, and work out what, if anything, >> >> > still needs to be done. >> >> >> >> Many cases are already agnostic in the drivers in terms of the *_get() >> >> functions. Some are DT specific, but probably because those subsystems >> >> are new and DT only. In any case, I don't think these 1 line changes >> >> do anything to make doing conversions here harder. >> >> >> >> >> It seems like we're going to have to refactor these bits of code when >> >> >> they get generalised anyway so I'm not sure that the additional cost >> >> >> here is that big. >> >> > >> >> > That's an acceptable answer — "we're adding legacy code here but we >> >> > know it's going to be refactored anyway". If that's true, all it takes >> >> > is a note in the commit comment to that effect. That's different from >> >> > having not thought about it :) >> >> >> >> Considering at one point we did create a fwnode based API, we did >> >> think about it. Plus there was little input from ACPI folks as to >> >> whether the change was even useful for ACPI case. >> > >> > Well, sorry, but who was asking whom, specifically? >> >> You and linux-acpi have been copied on v2 and later of the entire >> series I think. > > Yes, but it wasn't like a direct request, say "We need your input, so can you > please have a look and BTW we want this in 4.4, so please do it ASAP". In > which case I'd prioritize that before other things I needed to take care of. Fair enough. Can you please review and comment on v7 of the series? We can discuss at KS as well. >> > The underlying problem is present in ACPI too and we don't really have a >> > good >> > solution for it. We might benefit from a common one if it existed. >> >> The problem for DT is we don't generically know what are the >> dependencies at a core level. We could know some or most dependencies >> if phandles (links to other nodes) were typed, but they are not. If >> the core had this information, we could simply control the device >> creation to order probing. Instead, this information is encoded into >> the bindings and binding parsing resides in the subsystems. That >> parsing happens during probe of the client side and is done by the >> subsystems (for common bindings). Since we already do the parsing at >> this point, it is a convenient place to trigger the probe of the >> dependency. Is ACPI going to be similar in this regard? > > It is similar in some ways. For example, if a device's functionality depends > on an I2C resource (connection), the core doesn't know that at the device > creation time at least in some cases. Same for GPIO, SPI, DMA engines etc. So you will need to create devices, defer their probing and then probe on demand as well unless you have other ideas how you would do it. > There is a _DEP object in ACPI that can be used by firmware to tell the OS > about those dependencies, but there's no way in the driver core to use that > information anyway today. I would think that the equivalent function for ACPI to of_device_probe could process these if they are generic and you can associate the dependency to a struct device. >> Fundamentally, it is a question of probe devices when their >> dependencies are present or drivers ensure their dependencies are >> ready. IIRC, init systems went thru
Re: [GIT PULL] On-demand device probing
On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote: > > I don't know that there *is* a coherent plan here to address it > > all. > > > > Certainly, we *will* need subsystems to have firmware-specific > > knowledge in some cases. Take GPIO as an example; ACPI *has* a way > > to > > describe GPIO, and properties which reference GPIO pins are > > intended to > > work through that — while in DT, properties which reference GPIO > > pins > > will have different contents. They'll be compatible at the driver > > level, in the sense that there's a call to get a given GPIO given > > the > > property name, but the subsystems *will* be doing different things > > behind the scenes. > > It's a bit ironic that you've chosen GPIO as an example there. The > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the > gpio descriptor. There's no of_* method. I think that part is already being worked on, but... > If ACPI already handles GPIOs internally, then I'm left wondering > why GPIO descriptor stuff went down the fwnode route at all - it > seems rather pointless in this case, ACPI already had a way for a given device to say that it uses certain other GPIOs. But until we had device properties in ACPI, it could say *what* it used them for. So sure, we could say that we used GPIO#15 from controller and GPIOs #27 and #31 from controller. But there was no way to say that the former was the shotdown pin and the latter was the reset pin. While a GPIO property in DT will contain a phandle and basically be a complete reference to find the pin you're after, the same property represented in ACPI will just be an index into the resources that ACPI could already refer to. So referring to the example in Documentation/acpi/gpio-properties.txt: Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} }) That part, ACPI already had. But.. Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }}, Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }}, } }) ...this part is new, and allows us the full flexibility of device properties. And the appropriate gpiod_get* function is supposed to transparently work on either DT or ACPI. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [GIT PULL] On-demand device probing
On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote: > On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki wrote: > > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse > >> wrote: > >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > >> >> > But the point I'm making is that we are working towards *fixing* that, > >> >> > and *not* using DT-specific code in places where we should be using > >> >> > the > >> >> > generic APIs. > >> >> > >> >> What is the plan for fixing things here? It's not obvious (at least to > >> >> me) that we don't want to have the subsystems having knowledge of how > >> >> they are bound to a specific firmware which is what you seem to imply > >> >> here. > >> > > >> > I don't know that there *is* a coherent plan here to address it all. > >> > > >> > Certainly, we *will* need subsystems to have firmware-specific > >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > >> > describe GPIO, and properties which reference GPIO pins are intended to > >> > work through that — while in DT, properties which reference GPIO pins > >> > will have different contents. They'll be compatible at the driver > >> > level, in the sense that there's a call to get a given GPIO given the > >> > property name, but the subsystems *will* be doing different things > >> > behind the scenes. > >> > > >> > My plan, such as it is, is to go through the leaf-node drivers which > >> > almost definitely *should* be firmware-agnostic, and convert those. And > >> > then take stock of what we have left, and work out what, if anything, > >> > still needs to be done. > >> > >> Many cases are already agnostic in the drivers in terms of the *_get() > >> functions. Some are DT specific, but probably because those subsystems > >> are new and DT only. In any case, I don't think these 1 line changes > >> do anything to make doing conversions here harder. > >> > >> >> It seems like we're going to have to refactor these bits of code when > >> >> they get generalised anyway so I'm not sure that the additional cost > >> >> here is that big. > >> > > >> > That's an acceptable answer — "we're adding legacy code here but we > >> > know it's going to be refactored anyway". If that's true, all it takes > >> > is a note in the commit comment to that effect. That's different from > >> > having not thought about it :) > >> > >> Considering at one point we did create a fwnode based API, we did > >> think about it. Plus there was little input from ACPI folks as to > >> whether the change was even useful for ACPI case. > > > > Well, sorry, but who was asking whom, specifically? > > You and linux-acpi have been copied on v2 and later of the entire > series I think. Yes, but it wasn't like a direct request, say "We need your input, so can you please have a look and BTW we want this in 4.4, so please do it ASAP". In which case I'd prioritize that before other things I needed to take care of. > > The underlying problem is present in ACPI too and we don't really have a > > good > > solution for it. We might benefit from a common one if it existed. > > The problem for DT is we don't generically know what are the > dependencies at a core level. We could know some or most dependencies > if phandles (links to other nodes) were typed, but they are not. If > the core had this information, we could simply control the device > creation to order probing. Instead, this information is encoded into > the bindings and binding parsing resides in the subsystems. That > parsing happens during probe of the client side and is done by the > subsystems (for common bindings). Since we already do the parsing at > this point, it is a convenient place to trigger the probe of the > dependency. Is ACPI going to be similar in this regard? It is similar in some ways. For example, if a device's functionality depends on an I2C resource (connection), the core doesn't know that at the device creation time at least in some cases. Same for GPIO, SPI, DMA engines etc. There is a _DEP object in ACPI that can be used by firmware to tell the OS about those dependencies, but there's no way in the driver core to use that information anyway today. > Fundamentally, it is a question of probe devices when their > dependencies are present or drivers ensure their dependencies are > ready. IIRC, init systems went thru a similar debate for service > dependencies. The probe ordering is not the entire picture, though. Even if you get the probe ordering right, the problem is going to show up in multiple other places: system suspend/resume, runtime PM, system shutdown, unbinding of drivers. In all of those cases it is necessary to handle things in a specific order if there is a dependency. > >> In any case, we're talking about adding 1 line. > > > > But also about making the driver core slighly OF-centric. > > How so? The one line is in DT binding parsing code in subsystems, not
Re: gpiod API considerations [Was: [GIT PULL] On-demand device probing]
Hello, [trimming list of recipients considerably because of changed topic] On Tue, Oct 20, 2015 at 08:47:21AM +0900, Alexandre Courbot wrote: > On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux > wrote: > > On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote: > >> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote: > >> > It's a bit ironic that you've chosen GPIO as an example there. The > >> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the > >> > gpio descriptor. There's no of_* method. > >> > >> Without following all that fwnode discussion: > >> gpiod_get et al. should work for you here, doesn't it? It just takes a > >> struct device * and I'm happy with it. > > > > What if you don't have a struct device? I had that problem recently > > when modifying the mvebu PCIe code. The 'struct device' node doesn't > > contain the GPIOs, it's the PCIe controller. Individual ports on the > > controller are described in DT as sub-nodes, and the sub-nodes can > > have a GPIO for card reset purposes. These sub-nodes don't have a > > struct device. > > > > Right now, I'm having to do this to work around this issue: > > > > reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, > > ); > > if (reset_gpio == -EPROBE_DEFER) { > > ret = reset_gpio; > > goto err; > > } > > > > if (gpio_is_valid(reset_gpio)) { > > unsigned long gpio_flags; > > > > port->reset_name = devm_kasprintf(dev, GFP_KERNEL, > > "%s-reset", > > port->name); > > if (!port->reset_name) { > > ret = -ENOMEM; > > goto err; > > } > > > > if (flags & OF_GPIO_ACTIVE_LOW) { > > dev_info(dev, "%s: reset gpio is active low\n", > > of_node_full_name(child)); > > gpio_flags = GPIOF_ACTIVE_LOW | > > GPIOF_OUT_INIT_LOW; > > } else { > > gpio_flags = GPIOF_OUT_INIT_HIGH; > > } > > > > ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags, > > port->reset_name); > > if (ret) { > > if (ret == -EPROBE_DEFER) > > goto err; > > goto skip; > > } > > > > port->reset_gpio = gpio_to_desc(reset_gpio); > > } > > > > Not nice, is it? Not nice to have that in lots of drivers either. > > > > However, switching to use any of_* or fwnode_* thing also carries with > > it another problem: you can't control the name appearing in the > > allocation, so you end up with a bunch of GPIOs requested with a "reset" > > name - meaning you lose any identification of which port the GPIO was > > bound to. > > There are a few holes in the gpiod API. I see two solutions here: > > 1) extend devm_get_gpiod_from_child() to take an optional name argument > 2) add a function to explicitly change a GPIO's name > > 2) seems to be the most generic solution, would that do the trick? I would prefer 1) without "optional". A third alternative is to add at least dev_name(dev) and maybe index to the name where applicable. Also note that gpiod_request is called with label=NULL (in fwnode_get_named_gpiod which is used in devm_get_gpiod_from_child), so /sys/kernel/debug/gpio doesn't even contain "reset". I only see question marks (using v4.3-rc5). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: gpiod API considerations [Was: [GIT PULL] On-demand device probing]
Hello, [trimming list of recipients considerably because of changed topic] On Tue, Oct 20, 2015 at 08:47:21AM +0900, Alexandre Courbot wrote: > On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux >wrote: > > On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote: > >> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote: > >> > It's a bit ironic that you've chosen GPIO as an example there. The > >> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the > >> > gpio descriptor. There's no of_* method. > >> > >> Without following all that fwnode discussion: > >> gpiod_get et al. should work for you here, doesn't it? It just takes a > >> struct device * and I'm happy with it. > > > > What if you don't have a struct device? I had that problem recently > > when modifying the mvebu PCIe code. The 'struct device' node doesn't > > contain the GPIOs, it's the PCIe controller. Individual ports on the > > controller are described in DT as sub-nodes, and the sub-nodes can > > have a GPIO for card reset purposes. These sub-nodes don't have a > > struct device. > > > > Right now, I'm having to do this to work around this issue: > > > > reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, > > ); > > if (reset_gpio == -EPROBE_DEFER) { > > ret = reset_gpio; > > goto err; > > } > > > > if (gpio_is_valid(reset_gpio)) { > > unsigned long gpio_flags; > > > > port->reset_name = devm_kasprintf(dev, GFP_KERNEL, > > "%s-reset", > > port->name); > > if (!port->reset_name) { > > ret = -ENOMEM; > > goto err; > > } > > > > if (flags & OF_GPIO_ACTIVE_LOW) { > > dev_info(dev, "%s: reset gpio is active low\n", > > of_node_full_name(child)); > > gpio_flags = GPIOF_ACTIVE_LOW | > > GPIOF_OUT_INIT_LOW; > > } else { > > gpio_flags = GPIOF_OUT_INIT_HIGH; > > } > > > > ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags, > > port->reset_name); > > if (ret) { > > if (ret == -EPROBE_DEFER) > > goto err; > > goto skip; > > } > > > > port->reset_gpio = gpio_to_desc(reset_gpio); > > } > > > > Not nice, is it? Not nice to have that in lots of drivers either. > > > > However, switching to use any of_* or fwnode_* thing also carries with > > it another problem: you can't control the name appearing in the > > allocation, so you end up with a bunch of GPIOs requested with a "reset" > > name - meaning you lose any identification of which port the GPIO was > > bound to. > > There are a few holes in the gpiod API. I see two solutions here: > > 1) extend devm_get_gpiod_from_child() to take an optional name argument > 2) add a function to explicitly change a GPIO's name > > 2) seems to be the most generic solution, would that do the trick? I would prefer 1) without "optional". A third alternative is to add at least dev_name(dev) and maybe index to the name where applicable. Also note that gpiod_request is called with label=NULL (in fwnode_get_named_gpiod which is used in devm_get_gpiod_from_child), so /sys/kernel/debug/gpio doesn't even contain "reset". I only see question marks (using v4.3-rc5). Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote: > On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysockiwrote: > > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse > >> wrote: > >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > >> >> > But the point I'm making is that we are working towards *fixing* that, > >> >> > and *not* using DT-specific code in places where we should be using > >> >> > the > >> >> > generic APIs. > >> >> > >> >> What is the plan for fixing things here? It's not obvious (at least to > >> >> me) that we don't want to have the subsystems having knowledge of how > >> >> they are bound to a specific firmware which is what you seem to imply > >> >> here. > >> > > >> > I don't know that there *is* a coherent plan here to address it all. > >> > > >> > Certainly, we *will* need subsystems to have firmware-specific > >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > >> > describe GPIO, and properties which reference GPIO pins are intended to > >> > work through that — while in DT, properties which reference GPIO pins > >> > will have different contents. They'll be compatible at the driver > >> > level, in the sense that there's a call to get a given GPIO given the > >> > property name, but the subsystems *will* be doing different things > >> > behind the scenes. > >> > > >> > My plan, such as it is, is to go through the leaf-node drivers which > >> > almost definitely *should* be firmware-agnostic, and convert those. And > >> > then take stock of what we have left, and work out what, if anything, > >> > still needs to be done. > >> > >> Many cases are already agnostic in the drivers in terms of the *_get() > >> functions. Some are DT specific, but probably because those subsystems > >> are new and DT only. In any case, I don't think these 1 line changes > >> do anything to make doing conversions here harder. > >> > >> >> It seems like we're going to have to refactor these bits of code when > >> >> they get generalised anyway so I'm not sure that the additional cost > >> >> here is that big. > >> > > >> > That's an acceptable answer — "we're adding legacy code here but we > >> > know it's going to be refactored anyway". If that's true, all it takes > >> > is a note in the commit comment to that effect. That's different from > >> > having not thought about it :) > >> > >> Considering at one point we did create a fwnode based API, we did > >> think about it. Plus there was little input from ACPI folks as to > >> whether the change was even useful for ACPI case. > > > > Well, sorry, but who was asking whom, specifically? > > You and linux-acpi have been copied on v2 and later of the entire > series I think. Yes, but it wasn't like a direct request, say "We need your input, so can you please have a look and BTW we want this in 4.4, so please do it ASAP". In which case I'd prioritize that before other things I needed to take care of. > > The underlying problem is present in ACPI too and we don't really have a > > good > > solution for it. We might benefit from a common one if it existed. > > The problem for DT is we don't generically know what are the > dependencies at a core level. We could know some or most dependencies > if phandles (links to other nodes) were typed, but they are not. If > the core had this information, we could simply control the device > creation to order probing. Instead, this information is encoded into > the bindings and binding parsing resides in the subsystems. That > parsing happens during probe of the client side and is done by the > subsystems (for common bindings). Since we already do the parsing at > this point, it is a convenient place to trigger the probe of the > dependency. Is ACPI going to be similar in this regard? It is similar in some ways. For example, if a device's functionality depends on an I2C resource (connection), the core doesn't know that at the device creation time at least in some cases. Same for GPIO, SPI, DMA engines etc. There is a _DEP object in ACPI that can be used by firmware to tell the OS about those dependencies, but there's no way in the driver core to use that information anyway today. > Fundamentally, it is a question of probe devices when their > dependencies are present or drivers ensure their dependencies are > ready. IIRC, init systems went thru a similar debate for service > dependencies. The probe ordering is not the entire picture, though. Even if you get the probe ordering right, the problem is going to show up in multiple other places: system suspend/resume, runtime PM, system shutdown, unbinding of drivers. In all of those cases it is necessary to handle things in a specific order if there is a dependency. > >> In any case, we're talking about adding 1 line. > > > > But also about making the driver core slighly OF-centric. > > How so? The one line is in DT
Re: [GIT PULL] On-demand device probing
On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote: > > I don't know that there *is* a coherent plan here to address it > > all. > > > > Certainly, we *will* need subsystems to have firmware-specific > > knowledge in some cases. Take GPIO as an example; ACPI *has* a way > > to > > describe GPIO, and properties which reference GPIO pins are > > intended to > > work through that — while in DT, properties which reference GPIO > > pins > > will have different contents. They'll be compatible at the driver > > level, in the sense that there's a call to get a given GPIO given > > the > > property name, but the subsystems *will* be doing different things > > behind the scenes. > > It's a bit ironic that you've chosen GPIO as an example there. The > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the > gpio descriptor. There's no of_* method. I think that part is already being worked on, but... > If ACPI already handles GPIOs internally, then I'm left wondering > why GPIO descriptor stuff went down the fwnode route at all - it > seems rather pointless in this case, ACPI already had a way for a given device to say that it uses certain other GPIOs. But until we had device properties in ACPI, it could say *what* it used them for. So sure, we could say that we used GPIO#15 from controller and GPIOs #27 and #31 from controller. But there was no way to say that the former was the shotdown pin and the latter was the reset pin. While a GPIO property in DT will contain a phandle and basically be a complete reference to find the pin you're after, the same property represented in ACPI will just be an index into the resources that ACPI could already refer to. So referring to the example in Documentation/acpi/gpio-properties.txt: Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} }) That part, ACPI already had. But.. Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }}, Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }}, } }) ...this part is new, and allows us the full flexibility of device properties. And the appropriate gpiod_get* function is supposed to transparently work on either DT or ACPI. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: [GIT PULL] On-demand device probing
On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysockiwrote: > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote: >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki >> wrote: >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse >> >> wrote: >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: >> >> >> > But the point I'm making is that we are working towards *fixing* >> >> >> > that, >> >> >> > and *not* using DT-specific code in places where we should be using >> >> >> > the >> >> >> > generic APIs. >> >> >> >> >> >> What is the plan for fixing things here? It's not obvious (at least to >> >> >> me) that we don't want to have the subsystems having knowledge of how >> >> >> they are bound to a specific firmware which is what you seem to imply >> >> >> here. >> >> > >> >> > I don't know that there *is* a coherent plan here to address it all. >> >> > >> >> > Certainly, we *will* need subsystems to have firmware-specific >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to >> >> > describe GPIO, and properties which reference GPIO pins are intended to >> >> > work through that — while in DT, properties which reference GPIO pins >> >> > will have different contents. They'll be compatible at the driver >> >> > level, in the sense that there's a call to get a given GPIO given the >> >> > property name, but the subsystems *will* be doing different things >> >> > behind the scenes. >> >> > >> >> > My plan, such as it is, is to go through the leaf-node drivers which >> >> > almost definitely *should* be firmware-agnostic, and convert those. And >> >> > then take stock of what we have left, and work out what, if anything, >> >> > still needs to be done. >> >> >> >> Many cases are already agnostic in the drivers in terms of the *_get() >> >> functions. Some are DT specific, but probably because those subsystems >> >> are new and DT only. In any case, I don't think these 1 line changes >> >> do anything to make doing conversions here harder. >> >> >> >> >> It seems like we're going to have to refactor these bits of code when >> >> >> they get generalised anyway so I'm not sure that the additional cost >> >> >> here is that big. >> >> > >> >> > That's an acceptable answer — "we're adding legacy code here but we >> >> > know it's going to be refactored anyway". If that's true, all it takes >> >> > is a note in the commit comment to that effect. That's different from >> >> > having not thought about it :) >> >> >> >> Considering at one point we did create a fwnode based API, we did >> >> think about it. Plus there was little input from ACPI folks as to >> >> whether the change was even useful for ACPI case. >> > >> > Well, sorry, but who was asking whom, specifically? >> >> You and linux-acpi have been copied on v2 and later of the entire >> series I think. > > Yes, but it wasn't like a direct request, say "We need your input, so can you > please have a look and BTW we want this in 4.4, so please do it ASAP". In > which case I'd prioritize that before other things I needed to take care of. Fair enough. Can you please review and comment on v7 of the series? We can discuss at KS as well. >> > The underlying problem is present in ACPI too and we don't really have a >> > good >> > solution for it. We might benefit from a common one if it existed. >> >> The problem for DT is we don't generically know what are the >> dependencies at a core level. We could know some or most dependencies >> if phandles (links to other nodes) were typed, but they are not. If >> the core had this information, we could simply control the device >> creation to order probing. Instead, this information is encoded into >> the bindings and binding parsing resides in the subsystems. That >> parsing happens during probe of the client side and is done by the >> subsystems (for common bindings). Since we already do the parsing at >> this point, it is a convenient place to trigger the probe of the >> dependency. Is ACPI going to be similar in this regard? > > It is similar in some ways. For example, if a device's functionality depends > on an I2C resource (connection), the core doesn't know that at the device > creation time at least in some cases. Same for GPIO, SPI, DMA engines etc. So you will need to create devices, defer their probing and then probe on demand as well unless you have other ideas how you would do it. > There is a _DEP object in ACPI that can be used by firmware to tell the OS > about those dependencies, but there's no way in the driver core to use that > information anyway today. I would think that the equivalent function for ACPI to of_device_probe could process these if they are generic and you can associate the dependency to a struct device. >> Fundamentally, it is a question of probe devices when their >> dependencies are present or drivers ensure
Re: [GIT PULL] On-demand device probing
On Tue, 20 Oct 2015, Rob Herring wrote: > > The probe ordering is not the entire picture, though. > > > > Even if you get the probe ordering right, the problem is going to show up in > > multiple other places: system suspend/resume, runtime PM, system shutdown, > > unbinding of drivers. In all of those cases it is necessary to handle > > things > > in a specific order if there is a dependency. > > My understanding was with deferred probe that it also solves suspend > ordering problems because things are suspended in reverse order of > probing. Devices are suspended in reverse order of _registration_. Not of probing. Furthermore, that applies only to devices that use synchronous suspend. Async suspend is becoming common, and there the only restrictions are parent-child relations plus whatever explicit requirements that drivers impose by calling device_pm_wait_for_dev(). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote: > On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > > This iteration of the series would make this quite easy, as > > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 > But what Rafael is proposing is quite general; it would apply to _all_ > dependencies as opposed to just those present in DT drivers or those > affecting platform_devices. We'll still need most of the DT bits that are there at the minute (the ones strewn around the subsystems) AFAICT since it's at the point where we parse the DT and work out what the dependencies are which we probably want to do prior to getting the drivers up and will be different for ACPI. I think the level of DT dependency here looks a lot larger than it actually is due to the fact that a lot of what's being modified is DT parsing code. signature.asc Description: PGP signature
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux >wrote: > >> > What you can do is print those devices which have failed to probe at > >> > late_initcall() time - possibly augmenting that with reports from > >> > subsystems showing what resources are not available, but that's only > >> > a guide, because of the "it might or might not be in a kernel module" > >> > problem. > >> > >> Well, adding those reports would give you a changelog similar to the > >> one in this series... > > > > I'm not sure about that, because what I was thinking of is adding > > a flag which would be set at late_initcall() time prior to running > > a final round of deferred device probing. > > Which round is the final round? > That's the one which didn't manage to bind any new devices to drivers, > which is something you only know _after_ the round has been run. > > So I think we need one extra round to handle this. > > > This flag would then be used in a deferred_warn() printk function > > which would normally be silent, but when this flag is set, it would > > print the reason for the deferral - and this would replace (or be > > added) to the subsystems and drivers which return -EPROBE_DEFER. > > > > That has the effect of hiding all the deferrals up until just before > > launching into userspace, which should then acomplish two things - > > firstly, getting rid of the rather useless deferred messages up to > > that point, and secondly printing the reason why the remaining > > deferrals are happening. > > > > That should be a small number of new lines plus a one-line change > > in subsystems and drivers. > > Apart from the extra round we probably can't get rid of, that sounds OK to me. Something like this. I haven't put a lot of effort into it to change all the places which return an -EPROBE_DEFER, and it also looks like we need some helpers to report when we have only an device_node (or should that be fwnode?) See the commented out of_warn_deferred() in drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching for resources should make debugging why things are getting deferred easier. We could make driver_deferred_probe_report something that can be deactivated again after the last deferred probe run, and provide the user with a knob that they can turn it back on again. I've tried this out on two of my platforms, including forcing driver_deferred_probe_report to be enabled, and I get exactly one deferred probe, so not a particularly good test. The patch won't apply as-is to mainline for all files; it's based on my tree which has some 360 additional patches (which seems to be about normal for my tree now.) drivers/base/dd.c | 29 + drivers/base/power/domain.c | 7 +-- drivers/clk/clkdev.c| 9 - drivers/gpio/gpiolib-of.c | 5 + drivers/gpu/drm/bridge/dw_hdmi.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- drivers/gpu/drm/imx/imx-ldb.c | 5 +++-- drivers/gpu/drm/msm/dsi/dsi.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 3 ++- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 ++- drivers/of/irq.c| 5 - drivers/pci/host/pci-mvebu.c| 1 + drivers/pinctrl/core.c | 5 +++-- drivers/pinctrl/devicetree.c| 4 ++-- drivers/regulator/core.c| 5 +++-- include/linux/device.h | 1 + 16 files changed, 71 insertions(+), 17 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index be0eb4639128..bb12224f2901 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -129,7 +129,29 @@ void driver_deferred_probe_del(struct device *dev) mutex_unlock(_probe_mutex); } +static bool driver_deferred_probe_report; + +/** + * dev_warn_deferred() - report why a probe has been deferred + */ +void dev_warn_deferred(struct device *dev, const char *fmt, ...) +{ + if (driver_deferred_probe_report) { + struct va_format vaf; + va_list ap; + + va_start(ap, fmt); + vaf.fmt = fmt; + vaf.va = + + dev_warn(dev, "deferring probe: %pV", ); + va_end(ap); + } +} +EXPORT_SYMBOL_GPL(dev_warn_deferred); + static bool driver_deferred_probe_enable = false; + /** * driver_deferred_probe_trigger() - Kick off re-probing deferred devices * @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void) driver_deferred_probe_trigger(); /* Sort as many dependencies as possible before exiting initcalls */ flush_workqueue(deferred_wq); + + /* Now one final round, reporting any devices that remain deferred */ + driver_deferred_probe_report = true; + driver_deferred_probe_trigger(); + /* Sort as many
Re: [GIT PULL] On-demand device probing
On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > Furthermore, that applies only to devices that use synchronous suspend. > Async suspend is becoming common, and there the only restrictions are > parent-child relations plus whatever explicit requirements that drivers > impose by calling device_pm_wait_for_dev(). Hrm, this is the first I'd noticed that feature though I see the initial commit dates from January. It looks like most of the users are PCs at the minute but we should be using it more widely for embedded things, there's definitely some cases I'm aware of where it will allow us to remove some open coding. It does seem like we want to be feeding dependency information we discover for probing way into the suspend dependencies... signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On 20 October 2015 at 18:04, Alan Sternwrote: > On Tue, 20 Oct 2015, Mark Brown wrote: > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: >> >> > Furthermore, that applies only to devices that use synchronous suspend. >> > Async suspend is becoming common, and there the only restrictions are >> > parent-child relations plus whatever explicit requirements that drivers >> > impose by calling device_pm_wait_for_dev(). >> >> Hrm, this is the first I'd noticed that feature though I see the initial >> commit dates from January. > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > not 2015! > >> It looks like most of the users are PCs at >> the minute but we should be using it more widely for embedded things, >> there's definitely some cases I'm aware of where it will allow us to >> remove some open coding. >> >> It does seem like we want to be feeding dependency information we >> discover for probing way into the suspend dependencies... > > Rafael has been thinking about a way to do this systematically. > Nothing concrete has emerged yet. This iteration of the series would make this quite easy, as dependencies are calculated before probes are attempted: https://lkml.org/lkml/2015/6/17/311 Regards, Tomeu > Alan Stern > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Sternwrote: > > On Tue, 20 Oct 2015, Mark Brown wrote: > > > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > >> > >> > Furthermore, that applies only to devices that use synchronous suspend. > >> > Async suspend is becoming common, and there the only restrictions are > >> > parent-child relations plus whatever explicit requirements that drivers > >> > impose by calling device_pm_wait_for_dev(). > >> > >> Hrm, this is the first I'd noticed that feature though I see the initial > >> commit dates from January. > > > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > > not 2015! > > > >> It looks like most of the users are PCs at > >> the minute but we should be using it more widely for embedded things, > >> there's definitely some cases I'm aware of where it will allow us to > >> remove some open coding. > >> > >> It does seem like we want to be feeding dependency information we > >> discover for probing way into the suspend dependencies... > > > > Rafael has been thinking about a way to do this systematically. > > Nothing concrete has emerged yet. > > This iteration of the series would make this quite easy, as > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 But what Rafael is proposing is quite general; it would apply to _all_ dependencies as opposed to just those present in DT drivers or those affecting platform_devices. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tue, 20 Oct 2015, Mark Brown wrote: > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > Furthermore, that applies only to devices that use synchronous suspend. > > Async suspend is becoming common, and there the only restrictions are > > parent-child relations plus whatever explicit requirements that drivers > > impose by calling device_pm_wait_for_dev(). > > Hrm, this is the first I'd noticed that feature though I see the initial > commit dates from January. Async suspend and device_pm_wait_for_dev() were added in January 2010, not 2015! > It looks like most of the users are PCs at > the minute but we should be using it more widely for embedded things, > there's definitely some cases I'm aware of where it will allow us to > remove some open coding. > > It does seem like we want to be feeding dependency information we > discover for probing way into the suspend dependencies... Rafael has been thinking about a way to do this systematically. Nothing concrete has emerged yet. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysockiwrote: > > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote: > >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki > >> wrote: > >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse > >> >> wrote: > >> >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > >> >> >> > But the point I'm making is that we are working towards *fixing* > >> >> >> > that, > >> >> >> > and *not* using DT-specific code in places where we should be > >> >> >> > using the > >> >> >> > generic APIs. > >> >> >> > >> >> >> What is the plan for fixing things here? It's not obvious (at least > >> >> >> to > >> >> >> me) that we don't want to have the subsystems having knowledge of how > >> >> >> they are bound to a specific firmware which is what you seem to imply > >> >> >> here. > >> >> > > >> >> > I don't know that there *is* a coherent plan here to address it all. > >> >> > > >> >> > Certainly, we *will* need subsystems to have firmware-specific > >> >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > >> >> > describe GPIO, and properties which reference GPIO pins are intended > >> >> > to > >> >> > work through that — while in DT, properties which reference GPIO pins > >> >> > will have different contents. They'll be compatible at the driver > >> >> > level, in the sense that there's a call to get a given GPIO given the > >> >> > property name, but the subsystems *will* be doing different things > >> >> > behind the scenes. > >> >> > > >> >> > My plan, such as it is, is to go through the leaf-node drivers which > >> >> > almost definitely *should* be firmware-agnostic, and convert those. > >> >> > And > >> >> > then take stock of what we have left, and work out what, if anything, > >> >> > still needs to be done. > >> >> > >> >> Many cases are already agnostic in the drivers in terms of the *_get() > >> >> functions. Some are DT specific, but probably because those subsystems > >> >> are new and DT only. In any case, I don't think these 1 line changes > >> >> do anything to make doing conversions here harder. > >> >> > >> >> >> It seems like we're going to have to refactor these bits of code when > >> >> >> they get generalised anyway so I'm not sure that the additional cost > >> >> >> here is that big. > >> >> > > >> >> > That's an acceptable answer — "we're adding legacy code here but we > >> >> > know it's going to be refactored anyway". If that's true, all it takes > >> >> > is a note in the commit comment to that effect. That's different from > >> >> > having not thought about it :) > >> >> > >> >> Considering at one point we did create a fwnode based API, we did > >> >> think about it. Plus there was little input from ACPI folks as to > >> >> whether the change was even useful for ACPI case. > >> > > >> > Well, sorry, but who was asking whom, specifically? > >> > >> You and linux-acpi have been copied on v2 and later of the entire > >> series I think. > > > > Yes, but it wasn't like a direct request, say "We need your input, so can > > you > > please have a look and BTW we want this in 4.4, so please do it ASAP". In > > which case I'd prioritize that before other things I needed to take care of. > > Fair enough. Can you please review and comment on v7 of the series? We > can discuss at KS as well. I'll do that. I'm in the middle of travel right now and speaking at a conference tomorrow, so I may not be able to get to that for a couple of days, but will do my best to do it as soon as I possibly can. > >> > The underlying problem is present in ACPI too and we don't really have a > >> > good > >> > solution for it. We might benefit from a common one if it existed. > >> > >> The problem for DT is we don't generically know what are the > >> dependencies at a core level. We could know some or most dependencies > >> if phandles (links to other nodes) were typed, but they are not. If > >> the core had this information, we could simply control the device > >> creation to order probing. Instead, this information is encoded into > >> the bindings and binding parsing resides in the subsystems. That > >> parsing happens during probe of the client side and is done by the > >> subsystems (for common bindings). Since we already do the parsing at > >> this point, it is a convenient place to trigger the probe of the > >> dependency. Is ACPI going to be similar in this regard? > > > > It is similar in some ways. For example, if a device's functionality > > depends > > on an I2C resource (connection), the core doesn't know that at the device > > creation time at least in some cases. Same for GPIO, SPI, DMA engines etc. > > So you will need to create devices, defer their probing and then probe > on demand as well unless you have other ideas how
Re: [GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote: > > --7fVr/IRGAG9sAW4J > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote: > > On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > > > > This iteration of the series would make this quite easy, as > > > dependencies are calculated before probes are attempted: > > > > https://lkml.org/lkml/2015/6/17/311 > > > But what Rafael is proposing is quite general; it would apply to _all_ > > dependencies as opposed to just those present in DT drivers or those=20 > > affecting platform_devices. > > We'll still need most of the DT bits that are there at the minute (the > ones strewn around the subsystems) AFAICT since it's at the point where > we parse the DT and work out what the dependencies are which we probably > want to do prior to getting the drivers up and will be different for > ACPI. I think the level of DT dependency here looks a lot larger than > it actually is due to the fact that a lot of what's being modified is DT > parsing code. Right, something will have to register the dependency, or a "link" between devices, with the core once we find out that the dependency is there. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux wrote: > On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote: >> Hello, >> >> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote: >> > It's a bit ironic that you've chosen GPIO as an example there. The >> > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the >> > gpio descriptor. There's no of_* method. >> >> Without following all that fwnode discussion: >> gpiod_get et al. should work for you here, doesn't it? It just takes a >> struct device * and I'm happy with it. > > What if you don't have a struct device? I had that problem recently > when modifying the mvebu PCIe code. The 'struct device' node doesn't > contain the GPIOs, it's the PCIe controller. Individual ports on the > controller are described in DT as sub-nodes, and the sub-nodes can > have a GPIO for card reset purposes. These sub-nodes don't have a > struct device. > > Right now, I'm having to do this to work around this issue: > > reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, ); > if (reset_gpio == -EPROBE_DEFER) { > ret = reset_gpio; > goto err; > } > > if (gpio_is_valid(reset_gpio)) { > unsigned long gpio_flags; > > port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset", > port->name); > if (!port->reset_name) { > ret = -ENOMEM; > goto err; > } > > if (flags & OF_GPIO_ACTIVE_LOW) { > dev_info(dev, "%s: reset gpio is active low\n", > of_node_full_name(child)); > gpio_flags = GPIOF_ACTIVE_LOW | > GPIOF_OUT_INIT_LOW; > } else { > gpio_flags = GPIOF_OUT_INIT_HIGH; > } > > ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags, > port->reset_name); > if (ret) { > if (ret == -EPROBE_DEFER) > goto err; > goto skip; > } > > port->reset_gpio = gpio_to_desc(reset_gpio); > } > > Not nice, is it? Not nice to have that in lots of drivers either. > > However, switching to use any of_* or fwnode_* thing also carries with > it another problem: you can't control the name appearing in the > allocation, so you end up with a bunch of GPIOs requested with a "reset" > name - meaning you lose any identification of which port the GPIO was > bound to. There are a few holes in the gpiod API. I see two solutions here: 1) extend devm_get_gpiod_from_child() to take an optional name argument 2) add a function to explicitly change a GPIO's name 2) seems to be the most generic solution, would that do the trick? (sorry for the off-topic) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki wrote: > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse >> wrote: >> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: >> >> > But the point I'm making is that we are working towards *fixing* that, >> >> > and *not* using DT-specific code in places where we should be using the >> >> > generic APIs. >> >> >> >> What is the plan for fixing things here? It's not obvious (at least to >> >> me) that we don't want to have the subsystems having knowledge of how >> >> they are bound to a specific firmware which is what you seem to imply >> >> here. >> > >> > I don't know that there *is* a coherent plan here to address it all. >> > >> > Certainly, we *will* need subsystems to have firmware-specific >> > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to >> > describe GPIO, and properties which reference GPIO pins are intended to >> > work through that — while in DT, properties which reference GPIO pins >> > will have different contents. They'll be compatible at the driver >> > level, in the sense that there's a call to get a given GPIO given the >> > property name, but the subsystems *will* be doing different things >> > behind the scenes. >> > >> > My plan, such as it is, is to go through the leaf-node drivers which >> > almost definitely *should* be firmware-agnostic, and convert those. And >> > then take stock of what we have left, and work out what, if anything, >> > still needs to be done. >> >> Many cases are already agnostic in the drivers in terms of the *_get() >> functions. Some are DT specific, but probably because those subsystems >> are new and DT only. In any case, I don't think these 1 line changes >> do anything to make doing conversions here harder. >> >> >> It seems like we're going to have to refactor these bits of code when >> >> they get generalised anyway so I'm not sure that the additional cost >> >> here is that big. >> > >> > That's an acceptable answer — "we're adding legacy code here but we >> > know it's going to be refactored anyway". If that's true, all it takes >> > is a note in the commit comment to that effect. That's different from >> > having not thought about it :) >> >> Considering at one point we did create a fwnode based API, we did >> think about it. Plus there was little input from ACPI folks as to >> whether the change was even useful for ACPI case. > > Well, sorry, but who was asking whom, specifically? You and linux-acpi have been copied on v2 and later of the entire series I think. > The underlying problem is present in ACPI too and we don't really have a good > solution for it. We might benefit from a common one if it existed. The problem for DT is we don't generically know what are the dependencies at a core level. We could know some or most dependencies if phandles (links to other nodes) were typed, but they are not. If the core had this information, we could simply control the device creation to order probing. Instead, this information is encoded into the bindings and binding parsing resides in the subsystems. That parsing happens during probe of the client side and is done by the subsystems (for common bindings). Since we already do the parsing at this point, it is a convenient place to trigger the probe of the dependency. Is ACPI going to be similar in this regard? Fundamentally, it is a question of probe devices when their dependencies are present or drivers ensure their dependencies are ready. IIRC, init systems went thru a similar debate for service dependencies. >> In any case, we're talking about adding 1 line. > > But also about making the driver core slighly OF-centric. How so? The one line is in DT binding parsing code in subsystems, not driver core. The driver core change is we add every device (that happened to be created by DT) to the deferred probe list, so they don't probe right away. > Sure, we need OF-specific code and ACPI-specific code wherever different > handling is required, but doing that at the driver core level seems to be > a bit of a stretch to me. > > Please note that we don't really have ACPI-specific calls in the driver core, > although we might have added them long ago even before the OF stuff appeared > in the kernel for the first time. We didn't do that, (among other things) > because we didn't want that particular firmware interface to appear special > in any way and I'm not really sure why it is now OK to make OF look special > instead. I don't think DT is special and we avoid DT specific core changes as much as possible. I think the difference is DT uses platform_device and ACPI does not. It used to be separate, but got merged together primarily to support the plethora of existing drivers. Anyway, that is all outside of anything in this series. > If it is trivial to avoid that (and you seem to be arguing that it is), why > do we have to do it? Sorry, I don't follow what "that"
Re: [GIT PULL] On-demand device probing
On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse wrote: > > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > >> > But the point I'm making is that we are working towards *fixing* that, > >> > and *not* using DT-specific code in places where we should be using the > >> > generic APIs. > >> > >> What is the plan for fixing things here? It's not obvious (at least to > >> me) that we don't want to have the subsystems having knowledge of how > >> they are bound to a specific firmware which is what you seem to imply > >> here. > > > > I don't know that there *is* a coherent plan here to address it all. > > > > Certainly, we *will* need subsystems to have firmware-specific > > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > > describe GPIO, and properties which reference GPIO pins are intended to > > work through that — while in DT, properties which reference GPIO pins > > will have different contents. They'll be compatible at the driver > > level, in the sense that there's a call to get a given GPIO given the > > property name, but the subsystems *will* be doing different things > > behind the scenes. > > > > My plan, such as it is, is to go through the leaf-node drivers which > > almost definitely *should* be firmware-agnostic, and convert those. And > > then take stock of what we have left, and work out what, if anything, > > still needs to be done. > > Many cases are already agnostic in the drivers in terms of the *_get() > functions. Some are DT specific, but probably because those subsystems > are new and DT only. In any case, I don't think these 1 line changes > do anything to make doing conversions here harder. > > >> It seems like we're going to have to refactor these bits of code when > >> they get generalised anyway so I'm not sure that the additional cost > >> here is that big. > > > > That's an acceptable answer — "we're adding legacy code here but we > > know it's going to be refactored anyway". If that's true, all it takes > > is a note in the commit comment to that effect. That's different from > > having not thought about it :) > > Considering at one point we did create a fwnode based API, we did > think about it. Plus there was little input from ACPI folks as to > whether the change was even useful for ACPI case. Well, sorry, but who was asking whom, specifically? The underlying problem is present in ACPI too and we don't really have a good solution for it. We might benefit from a common one if it existed. > In any case, we're talking about adding 1 line. But also about making the driver core slighly OF-centric. Sure, we need OF-specific code and ACPI-specific code wherever different handling is required, but doing that at the driver core level seems to be a bit of a stretch to me. Please note that we don't really have ACPI-specific calls in the driver core, although we might have added them long ago even before the OF stuff appeared in the kernel for the first time. We didn't do that, (among other things) because we didn't want that particular firmware interface to appear special in any way and I'm not really sure why it is now OK to make OF look special instead. If it is trivial to avoid that (and you seem to be arguing that it is), why do we have to do it? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote: > Hello, > > On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote: > > It's a bit ironic that you've chosen GPIO as an example there. The > > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the > > gpio descriptor. There's no of_* method. > > Without following all that fwnode discussion: > gpiod_get et al. should work for you here, doesn't it? It just takes a > struct device * and I'm happy with it. What if you don't have a struct device? I had that problem recently when modifying the mvebu PCIe code. The 'struct device' node doesn't contain the GPIOs, it's the PCIe controller. Individual ports on the controller are described in DT as sub-nodes, and the sub-nodes can have a GPIO for card reset purposes. These sub-nodes don't have a struct device. Right now, I'm having to do this to work around this issue: reset_gpio = of_get_named_gpio_flags(child, "reset-gpios", 0, ); if (reset_gpio == -EPROBE_DEFER) { ret = reset_gpio; goto err; } if (gpio_is_valid(reset_gpio)) { unsigned long gpio_flags; port->reset_name = devm_kasprintf(dev, GFP_KERNEL, "%s-reset", port->name); if (!port->reset_name) { ret = -ENOMEM; goto err; } if (flags & OF_GPIO_ACTIVE_LOW) { dev_info(dev, "%s: reset gpio is active low\n", of_node_full_name(child)); gpio_flags = GPIOF_ACTIVE_LOW | GPIOF_OUT_INIT_LOW; } else { gpio_flags = GPIOF_OUT_INIT_HIGH; } ret = devm_gpio_request_one(dev, reset_gpio, gpio_flags, port->reset_name); if (ret) { if (ret == -EPROBE_DEFER) goto err; goto skip; } port->reset_gpio = gpio_to_desc(reset_gpio); } Not nice, is it? Not nice to have that in lots of drivers either. However, switching to use any of_* or fwnode_* thing also carries with it another problem: you can't control the name appearing in the allocation, so you end up with a bunch of GPIOs requested with a "reset" name - meaning you lose any identification of which port the GPIO was bound to. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Hello, On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote: > It's a bit ironic that you've chosen GPIO as an example there. The > "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the > gpio descriptor. There's no of_* method. Without following all that fwnode discussion: gpiod_get et al. should work for you here, doesn't it? It just takes a struct device * and I'm happy with it. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Sat, Oct 17, 2015 at 8:19 AM, Rob Herring wrote: > On Fri, Oct 16, 2015 at 4:23 PM, Olof Johansson wrote: >> Hi, >> >> I've bisected boot failures in next-20151016 down to patches in this branch: >> >> On Thu, Oct 15, 2015 at 4:42 AM, Tomeu Vizoso >> wrote: >>> Tomeu Vizoso (20): >>> driver core: handle -EPROBE_DEFER from bus_type.match() >> >> The machine it happened on was OMAP5UEVM: >> >> http://arm-soc.lixom.net/bootlogs/next/next-20151016/omap5uevm-arm-omap2plus_defconfig.html > > So this one is because the MMC node numbering changed. I don't know > how to fix that other than with aliases, but that doesn't solve > backwards compatibility. Yep, aliases will take care of it in this case. This is where -next fills a great purpose, we can make sure we get those aliases added in before the patches go in. >> But I've also seen it on tegra2, that one bisected down to: >> >>> regulator: core: Probe regulators on demand >> >> http://arm-soc.lixom.net/bootlogs/next/next-20151016/seaboard-arm-multi_v7_defconfig.html > > This one you need a rootwait I think. The MMC scanning is not > guaranteed to be done before the rootfs mounting AFAIK. There may be > other problems, but we can't see them since it panics. Embarrassing, I almost always do this and I'm surprised this machine has been this stable without it. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Mon, Oct 19, 2015 at 06:21:40PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux > wrote: > >> > What you can do is print those devices which have failed to probe at > >> > late_initcall() time - possibly augmenting that with reports from > >> > subsystems showing what resources are not available, but that's only > >> > a guide, because of the "it might or might not be in a kernel module" > >> > problem. > >> > >> Well, adding those reports would give you a changelog similar to the > >> one in this series... > > > > I'm not sure about that, because what I was thinking of is adding > > a flag which would be set at late_initcall() time prior to running > > a final round of deferred device probing. > > Which round is the final round? I said "a" not "the". Maybe I should've said "one last round of deferred probing before entering userspace". > That's the one which didn't manage to bind any new devices to drivers, > which is something you only know _after_ the round has been run. > > So I think we need one extra round to handle this. Yes - because the idea is that we do everything we do today without printing anything about deferred probes. We then set a flag which indicates we should report defers, and then we trigger another round of probes. If everything probed successfully, the deferred probe list will be empty and nothing will be seen. Otherwise, we should end up with a report of all the devices that weren't able to be bound to their drivers due to -EPROBE_DEFER. > > > This flag would then be used in a deferred_warn() printk function > > which would normally be silent, but when this flag is set, it would > > print the reason for the deferral - and this would replace (or be > > added) to the subsystems and drivers which return -EPROBE_DEFER. > > > > That has the effect of hiding all the deferrals up until just before > > launching into userspace, which should then acomplish two things - > > firstly, getting rid of the rather useless deferred messages up to > > that point, and secondly printing the reason why the remaining > > deferrals are happening. > > > > That should be a small number of new lines plus a one-line change > > in subsystems and drivers. > > Apart from the extra round we probably can't get rid of, that sounds > OK to me. Yes, it means a little longer to boot, but if there's nothing pending this _should_ only be microseconds - it should be nothing more than setting the flag, possibly taking and releasing a lock, and checking that the deferred probe list is empty. Of course, if the deferred probe list isn't empty, then there'll be more expense - but I'm willing to bet that for those developers with serial console enabled, the kernel boot will be faster overall due to the reduced number of characters printed during the boot. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
Hi Russell, On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux wrote: >> > What you can do is print those devices which have failed to probe at >> > late_initcall() time - possibly augmenting that with reports from >> > subsystems showing what resources are not available, but that's only >> > a guide, because of the "it might or might not be in a kernel module" >> > problem. >> >> Well, adding those reports would give you a changelog similar to the >> one in this series... > > I'm not sure about that, because what I was thinking of is adding > a flag which would be set at late_initcall() time prior to running > a final round of deferred device probing. Which round is the final round? That's the one which didn't manage to bind any new devices to drivers, which is something you only know _after_ the round has been run. So I think we need one extra round to handle this. > This flag would then be used in a deferred_warn() printk function > which would normally be silent, but when this flag is set, it would > print the reason for the deferral - and this would replace (or be > added) to the subsystems and drivers which return -EPROBE_DEFER. > > That has the effect of hiding all the deferrals up until just before > launching into userspace, which should then acomplish two things - > firstly, getting rid of the rather useless deferred messages up to > that point, and secondly printing the reason why the remaining > deferrals are happening. > > That should be a small number of new lines plus a one-line change > in subsystems and drivers. Apart from the extra round we probably can't get rid of, that sounds OK to me. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] On-demand device probing
On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote: > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > > > But the point I'm making is that we are working towards *fixing* that, > > > and *not* using DT-specific code in places where we should be using the > > > generic APIs. > > What is the plan for fixing things here? It's not obvious (at least to > > me) that we don't want to have the subsystems having knowledge of how > > they are bound to a specific firmware which is what you seem to imply > > here. > I don't know that there *is* a coherent plan here to address it all. > Certainly, we *will* need subsystems to have firmware-specific > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > describe GPIO, and properties which reference GPIO pins are intended to > work through that — while in DT, properties which reference GPIO pins > will have different contents. They'll be compatible at the driver > level, in the sense that there's a call to get a given GPIO given the > property name, but the subsystems *will* be doing different things > behind the scenes. I'd expect that to be the norm rather than the exception. > > It seems like we're going to have to refactor these bits of code when > > they get generalised anyway so I'm not sure that the additional cost > > here is that big. > That's an acceptable answer — "we're adding legacy code here but we > know it's going to be refactored anyway". If that's true, all it takes > is a note in the commit comment to that effect. That's different from > having not thought about it :) Given the above I'm not even sure it's legacy code, it's just as likely we're going to get some parallel ACPI code added to the subsystems for parsing their bindings. signature.asc Description: PGP signature
Re: [GIT PULL] On-demand device probing
On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse wrote: > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: >> > But the point I'm making is that we are working towards *fixing* that, >> > and *not* using DT-specific code in places where we should be using the >> > generic APIs. >> >> What is the plan for fixing things here? It's not obvious (at least to >> me) that we don't want to have the subsystems having knowledge of how >> they are bound to a specific firmware which is what you seem to imply >> here. > > I don't know that there *is* a coherent plan here to address it all. > > Certainly, we *will* need subsystems to have firmware-specific > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > describe GPIO, and properties which reference GPIO pins are intended to > work through that — while in DT, properties which reference GPIO pins > will have different contents. They'll be compatible at the driver > level, in the sense that there's a call to get a given GPIO given the > property name, but the subsystems *will* be doing different things > behind the scenes. > > My plan, such as it is, is to go through the leaf-node drivers which > almost definitely *should* be firmware-agnostic, and convert those. And > then take stock of what we have left, and work out what, if anything, > still needs to be done. Many cases are already agnostic in the drivers in terms of the *_get() functions. Some are DT specific, but probably because those subsystems are new and DT only. In any case, I don't think these 1 line changes do anything to make doing conversions here harder. >> It seems like we're going to have to refactor these bits of code when >> they get generalised anyway so I'm not sure that the additional cost >> here is that big. > > That's an acceptable answer — "we're adding legacy code here but we > know it's going to be refactored anyway". If that's true, all it takes > is a note in the commit comment to that effect. That's different from > having not thought about it :) Considering at one point we did create a fwnode based API, we did think about it. Plus there was little input from ACPI folks as to whether the change was even useful for ACPI case. In any case, we're talking about adding 1 line. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/