| Message ID | 561E1378.6000906@collabora.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > on-demand-probes-for-next In don't think that's the URL you intended to use (also everything looks word wrapped here)?
On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > Hi Rob, > > here is the pull request you asked for, with no changes from the version > that I posted last to the list. > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > on-demand-probes-for-next That's not a signed tag :( Anyway, I REALLY don't like this series (sorry for the delay in reviewing them, normally I trust Rob's judgement...) I can't see adding calls like this all over the tree just to solve a bus-specific problem, you are adding of_* calls where they aren't needed, or wanted, at all. What is the root-problem of your delay in device probing? I read your last patch series and I can't seem to figure out what the issue is that this is solving in any "better" way from the existing deferred probing. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: >> Hi Rob, >> >> here is the pull request you asked for, with no changes from the version >> that I posted last to the list. >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) >> >> are available in the git repository at: >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git >> on-demand-probes-for-next > > That's not a signed tag :( > > Anyway, I REALLY don't like this series (sorry for the delay in > reviewing them, normally I trust Rob's judgement...) We've seen a lot of attempts here. This is really the best solution so far in that it is simple, uses existing data from DT, and was low risk for breaking platforms (at least I thought it would be). Anyway, getting more exposure is why I've put it into -next. > I can't see adding calls like this all over the tree just to solve a > bus-specific problem, you are adding of_* calls where they aren't > needed, or wanted, at all. I think Linus W, Mark B, and I all said a similar thing initially in that dependencies should be handled in the driver core. We went down the path of making this not firmware (aka bus) specific and an earlier version had just that (with fwnode_* calls). That turned out to be pointless as the calling locations were almost always in DT specific code anyway. If you notice, the calls are next to other DT specific calls generally (usually a "get"). So yes, I'd prefer not to have to touch every subsystem, but we had to do that anyway to add DT support. We've generally split the DT code into the core (in drivers/of) and the binding specific (in subsystems). Extracting dependency information the DT is going to require binding specific knowledge, so subsystem changes are probably unavoidable. The alternative is we put binding specific knowledge into the core DT code to parse dependencies. > What is the root-problem of your delay in device probing? I read your > last patch series and I can't seem to figure out what the issue is that > this is solving in any "better" way from the existing deferred probing. It saves 2 seconds in the boot time as re-probing takes time. That alone seems compelling to me. Another downside to deferred probing is you have to touch every driver and subsystem to support it. This contains the problem to the subsystems. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: > On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > >> Hi Rob, > >> > >> here is the pull request you asked for, with no changes from the version > >> that I posted last to the list. > >> > >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > >> > >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > >> > >> are available in the git repository at: > >> > >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > >> on-demand-probes-for-next > > > > That's not a signed tag :( > > > > Anyway, I REALLY don't like this series (sorry for the delay in > > reviewing them, normally I trust Rob's judgement...) > > We've seen a lot of attempts here. This is really the best solution so > far in that it is simple, uses existing data from DT, and was low risk > for breaking platforms (at least I thought it would be). Anyway, > getting more exposure is why I've put it into -next. Exposure is good, now we know it breaks some builds, which was useful :) > > I can't see adding calls like this all over the tree just to solve a > > bus-specific problem, you are adding of_* calls where they aren't > > needed, or wanted, at all. > > I think Linus W, Mark B, and I all said a similar thing initially in > that dependencies should be handled in the driver core. We went down > the path of making this not firmware (aka bus) specific and an earlier > version had just that (with fwnode_* calls). That turned out to be > pointless as the calling locations were almost always in DT specific > code anyway. If you notice, the calls are next to other DT specific > calls generally (usually a "get"). So yes, I'd prefer not to have to > touch every subsystem, but we had to do that anyway to add DT support. If they are "next" to a call like that, why not put it in that call? I really object to having to "sprinkle" this all over the kernel, for no obvious reason why that is happening at all (look at the USB patch for one such example.) > We've generally split the DT code into the core (in drivers/of) and > the binding specific (in subsystems). Extracting dependency > information the DT is going to require binding specific knowledge, so > subsystem changes are probably unavoidable. > > The alternative is we put binding specific knowledge into the core DT > code to parse dependencies. > > > What is the root-problem of your delay in device probing? I read your > > last patch series and I can't seem to figure out what the issue is that > > this is solving in any "better" way from the existing deferred probing. > > It saves 2 seconds in the boot time as re-probing takes time. That > alone seems compelling to me. 2 seconds is _forever_, and really seems like some other driver is sleeping and causing this problem. What does the bootlog time-chart say is really causing this long delay? There's no way we are stuck in some sort of logic loop for that long (i.e. having to walk the list of devices somehow.) This sounds like a driver-specific problem that is being worked around by having to touch all subsystems, which isn't nice. Hint, we didn't have to do this type of thing to solve boot delays on x86 when we had hardware that was slow to initialize, why should DT be special? :) > Another downside to deferred probing is you have to touch every driver > and subsystem to support it. This contains the problem to the > subsystems. But we have deferred probing already, only those drivers that need/want it have to do anything, why create yet-another model here? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman >> <gregkh@linuxfoundation.org> wrote: >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: >> >> Hi Rob, >> >> >> >> here is the pull request you asked for, with no changes from the version >> >> that I posted last to the list. >> >> >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: >> >> >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) >> >> >> >> are available in the git repository at: >> >> >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git >> >> on-demand-probes-for-next >> > >> > That's not a signed tag :( >> > >> > Anyway, I REALLY don't like this series (sorry for the delay in >> > reviewing them, normally I trust Rob's judgement...) >> >> We've seen a lot of attempts here. This is really the best solution so >> far in that it is simple, uses existing data from DT, and was low risk >> for breaking platforms (at least I thought it would be). Anyway, >> getting more exposure is why I've put it into -next. > > Exposure is good, now we know it breaks some builds, which was useful :) Now that I've looked at them, they are somewhat questionable failures. They do show the fragile nature of probe ordering and the implicit dependencies we have. >> > I can't see adding calls like this all over the tree just to solve a >> > bus-specific problem, you are adding of_* calls where they aren't >> > needed, or wanted, at all. >> >> I think Linus W, Mark B, and I all said a similar thing initially in >> that dependencies should be handled in the driver core. We went down >> the path of making this not firmware (aka bus) specific and an earlier >> version had just that (with fwnode_* calls). That turned out to be >> pointless as the calling locations were almost always in DT specific >> code anyway. If you notice, the calls are next to other DT specific >> calls generally (usually a "get"). So yes, I'd prefer not to have to >> touch every subsystem, but we had to do that anyway to add DT support. > > If they are "next" to a call like that, why not put it in that call? I > really object to having to "sprinkle" this all over the kernel, for no > obvious reason why that is happening at all (look at the USB patch for > one such example.) Looking at it again, they are in DT specific code already. The USB one is in devm_usb_get_phy_by_node() which is a DT specific call. >> We've generally split the DT code into the core (in drivers/of) and >> the binding specific (in subsystems). Extracting dependency >> information the DT is going to require binding specific knowledge, so >> subsystem changes are probably unavoidable. >> >> The alternative is we put binding specific knowledge into the core DT >> code to parse dependencies. >> >> > What is the root-problem of your delay in device probing? I read your >> > last patch series and I can't seem to figure out what the issue is that >> > this is solving in any "better" way from the existing deferred probing. >> >> It saves 2 seconds in the boot time as re-probing takes time. That >> alone seems compelling to me. > > 2 seconds is _forever_, and really seems like some other driver is > sleeping and causing this problem. What does the bootlog time-chart say > is really causing this long delay? There's no way we are stuck in some > sort of logic loop for that long (i.e. having to walk the list of > devices somehow.) This sounds like a driver-specific problem that is > being worked around by having to touch all subsystems, which isn't nice. I don't think it is one driver as the improvement is seen on multiple platforms. I'll let Tomeu comment further on where the time was spent. > Hint, we didn't have to do this type of thing to solve boot delays on > x86 when we had hardware that was slow to initialize, why should DT be > special? :) x86 did not need deferred probe either (though we probably can find some initcall ordering hacks). This is an embedded problem, not a DT problem. I'm guessing the time is a matter of probing and undoing the probes rather than slow h/w. We could maybe improve things by making sure drivers move what they defer on to the beginning of probe, but that seems like a horrible, fragile hack. >> Another downside to deferred probing is you have to touch every driver >> and subsystem to support it. This contains the problem to the >> subsystems. > > But we have deferred probing already, only those drivers that need/want > it have to do anything, why create yet-another model here? Yes, the only ones needing it are drivers dependent on clocks, gpio, regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This is a side benefit and wouldn't take this series for that reason alone. I've used the deferred probing is good enough argument myself on previous attempts. The boot time improvements convinced me it is not good enough except for simple cases. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 11:28:29AM -0500, Rob Herring wrote: > On Sat, Oct 17, 2015 at 10:47 AM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: > >> On Sat, Oct 17, 2015 at 1:57 AM, Greg Kroah-Hartman > >> <gregkh@linuxfoundation.org> wrote: > >> > On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote: > >> >> Hi Rob, > >> >> > >> >> here is the pull request you asked for, with no changes from the version > >> >> that I posted last to the list. > >> >> > >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > >> >> > >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > >> >> > >> >> are available in the git repository at: > >> >> > >> >> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git > >> >> on-demand-probes-for-next > >> > > >> > That's not a signed tag :( > >> > > >> > Anyway, I REALLY don't like this series (sorry for the delay in > >> > reviewing them, normally I trust Rob's judgement...) > >> > >> We've seen a lot of attempts here. This is really the best solution so > >> far in that it is simple, uses existing data from DT, and was low risk > >> for breaking platforms (at least I thought it would be). Anyway, > >> getting more exposure is why I've put it into -next. > > > > Exposure is good, now we know it breaks some builds, which was useful :) > > Now that I've looked at them, they are somewhat questionable failures. > They do show the fragile nature of probe ordering and the implicit > dependencies we have. > > >> > I can't see adding calls like this all over the tree just to solve a > >> > bus-specific problem, you are adding of_* calls where they aren't > >> > needed, or wanted, at all. > >> > >> I think Linus W, Mark B, and I all said a similar thing initially in > >> that dependencies should be handled in the driver core. We went down > >> the path of making this not firmware (aka bus) specific and an earlier > >> version had just that (with fwnode_* calls). That turned out to be > >> pointless as the calling locations were almost always in DT specific > >> code anyway. If you notice, the calls are next to other DT specific > >> calls generally (usually a "get"). So yes, I'd prefer not to have to > >> touch every subsystem, but we had to do that anyway to add DT support. > > > > If they are "next" to a call like that, why not put it in that call? I > > really object to having to "sprinkle" this all over the kernel, for no > > obvious reason why that is happening at all (look at the USB patch for > > one such example.) > > Looking at it again, they are in DT specific code already. The USB one > is in devm_usb_get_phy_by_node() which is a DT specific call. But that's not very obvious, right? Especially given that you now have to add a new .h file, which implies that suddenly this file is now touching a new subsystem. > >> We've generally split the DT code into the core (in drivers/of) and > >> the binding specific (in subsystems). Extracting dependency > >> information the DT is going to require binding specific knowledge, so > >> subsystem changes are probably unavoidable. > >> > >> The alternative is we put binding specific knowledge into the core DT > >> code to parse dependencies. > >> > >> > What is the root-problem of your delay in device probing? I read your > >> > last patch series and I can't seem to figure out what the issue is that > >> > this is solving in any "better" way from the existing deferred probing. > >> > >> It saves 2 seconds in the boot time as re-probing takes time. That > >> alone seems compelling to me. > > > > 2 seconds is _forever_, and really seems like some other driver is > > sleeping and causing this problem. What does the bootlog time-chart say > > is really causing this long delay? There's no way we are stuck in some > > sort of logic loop for that long (i.e. having to walk the list of > > devices somehow.) This sounds like a driver-specific problem that is > > being worked around by having to touch all subsystems, which isn't nice. > > I don't think it is one driver as the improvement is seen on multiple > platforms. I'll let Tomeu comment further on where the time was spent. That would be good to know, as 2 seconds is forever (my whole machine boots to a gnome login faster than that.) > > Hint, we didn't have to do this type of thing to solve boot delays on > > x86 when we had hardware that was slow to initialize, why should DT be > > special? :) > > x86 did not need deferred probe either (though we probably can find > some initcall ordering hacks). This is an embedded problem, not a DT > problem. x86 is embedded :) > I'm guessing the time is a matter of probing and undoing the probes > rather than slow h/w. We could maybe improve things by making sure > drivers move what they defer on to the beginning of probe, but that > seems like a horrible, fragile hack. How can calling probe and failing cause 2 seconds? How many different probe calls are failing here? Again, a boot log graph would be great to see as it will show the root cause, not just guessing at this. > >> Another downside to deferred probing is you have to touch every driver > >> and subsystem to support it. This contains the problem to the > >> subsystems. > > > > But we have deferred probing already, only those drivers that need/want > > it have to do anything, why create yet-another model here? > > Yes, the only ones needing it are drivers dependent on clocks, gpio, > regulators, pwm, pin-ctrl, dma, etc. That's not a small number. This > is a side benefit and wouldn't take this series for that reason alone. > > I've used the deferred probing is good enough argument myself on > previous attempts. The boot time improvements convinced me it is not > good enough except for simple cases. Then let's fix deferred probing to do it "correctly", let's not add yet-another-way-to-probe instead please, as we will be forever sprinkling these calls around subsystems in a cargo-cult-like manner for forever. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: >> I'm guessing the time is a matter of probing and undoing the probes >> rather than slow h/w. We could maybe improve things by making sure >> drivers move what they defer on to the beginning of probe, but that >> seems like a horrible, fragile hack. > > How can calling probe and failing cause 2 seconds? How many different > probe calls are failing here? Again, a boot log graph would be great to > see as it will show the root cause, not just guessing at this. just fwiw, but when you have a driver that depends on several other drivers (which in turn depend on other drivers and so on), the amount of probe-defer we end up seeing is pretty comical. Yeah, there probably is some room to optimize by juggling around order drivers do things in probe. But that doesn't solve the fundamental problem with the current state, about probe order having no clue about dependencies.. BR, -R -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: > On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > >> I'm guessing the time is a matter of probing and undoing the probes > >> rather than slow h/w. We could maybe improve things by making sure > >> drivers move what they defer on to the beginning of probe, but that > >> seems like a horrible, fragile hack. > > > > How can calling probe and failing cause 2 seconds? How many different > > probe calls are failing here? Again, a boot log graph would be great to > > see as it will show the root cause, not just guessing at this. > > > just fwiw, but when you have a driver that depends on several other > drivers (which in turn depend on other drivers and so on), the amount > of probe-defer we end up seeing is pretty comical. Yeah, there > probably is some room to optimize by juggling around order drivers do > things in probe. But that doesn't solve the fundamental problem with > the current state, about probe order having no clue about > dependencies.. I can imagine it is a lot of iterations, but how long does it really take? How many different devices are involved that it takes multiple loops in order to finally work out the correct order? Where is the time delays here, just calling probe() and having it instantly return shouldn't take all that long. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman >> <gregkh@linuxfoundation.org> wrote: >> >> I'm guessing the time is a matter of probing and undoing the probes >> >> rather than slow h/w. We could maybe improve things by making sure >> >> drivers move what they defer on to the beginning of probe, but that >> >> seems like a horrible, fragile hack. >> > >> > How can calling probe and failing cause 2 seconds? How many different >> > probe calls are failing here? Again, a boot log graph would be great to >> > see as it will show the root cause, not just guessing at this. >> >> >> just fwiw, but when you have a driver that depends on several other >> drivers (which in turn depend on other drivers and so on), the amount >> of probe-defer we end up seeing is pretty comical. Yeah, there >> probably is some room to optimize by juggling around order drivers do >> things in probe. But that doesn't solve the fundamental problem with >> the current state, about probe order having no clue about >> dependencies.. > > I can imagine it is a lot of iterations, but how long does it really > take? How many different devices are involved that it takes multiple > loops in order to finally work out the correct order? Where is the time > delays here, just calling probe() and having it instantly return > shouldn't take all that long. offhand, I think the dependencies go at *least* three levels deep.. I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to get all the way through requesting it's various different regulators/clks/gpios. I hadn't really paid attention to how many tries the drivers I depend on go through. (Of those, I take clks from two different clk drivers (which have dependency on a 3rd clk driver), and regulators and gpio's come from at least two places, which in turn have dependencies on clks, etc.) I don't have really good hard numbers handy (since my observations of this are w/ console over uart which effects timings, and so I see it taking much longer than 2sec).. but the 2sec figure that Tomeu mentioned seemed pretty plausible to me. I can try to get better #'s... I should have my kernel hat on at least some of the time next week.. but the 2sec figure didn't seem unrealistic to me. Just as an aside, the amount of probe-defer adds quite a lot of noise when you are trying to debug why some driver doesn't probe successfully. Which itself would be a nice reason to do something more clever.. BR, -R > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote: > On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: > >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman > >> <gregkh@linuxfoundation.org> wrote: > >> >> I'm guessing the time is a matter of probing and undoing the probes > >> >> rather than slow h/w. We could maybe improve things by making sure > >> >> drivers move what they defer on to the beginning of probe, but that > >> >> seems like a horrible, fragile hack. > >> > > >> > How can calling probe and failing cause 2 seconds? How many different > >> > probe calls are failing here? Again, a boot log graph would be great to > >> > see as it will show the root cause, not just guessing at this. > >> > >> > >> just fwiw, but when you have a driver that depends on several other > >> drivers (which in turn depend on other drivers and so on), the amount > >> of probe-defer we end up seeing is pretty comical. Yeah, there > >> probably is some room to optimize by juggling around order drivers do > >> things in probe. But that doesn't solve the fundamental problem with > >> the current state, about probe order having no clue about > >> dependencies.. > > > > I can imagine it is a lot of iterations, but how long does it really > > take? How many different devices are involved that it takes multiple > > loops in order to finally work out the correct order? Where is the time > > delays here, just calling probe() and having it instantly return > > shouldn't take all that long. > > offhand, I think the dependencies go at *least* three levels deep.. > I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to > get all the way through requesting it's various different > regulators/clks/gpios. And how long does that really take? Numbers please :) > I hadn't really paid attention to how many > tries the drivers I depend on go through. (Of those, I take clks from > two different clk drivers (which have dependency on a 3rd clk driver), > and regulators and gpio's come from at least two places, which in turn > have dependencies on clks, etc.) I don't have really good hard > numbers handy (since my observations of this are w/ console over uart > which effects timings, and so I see it taking much longer than 2sec).. > but the 2sec figure that Tomeu mentioned seemed pretty plausible to > me. > > I can try to get better #'s... I should have my kernel hat on at least > some of the time next week.. but the 2sec figure didn't seem > unrealistic to me. Based on the time it takes a modern laptop to boot, 2 seconds is forever, there has to be something else going on here other than just calling probe() a bunch of times. Please use the tools we have to determine this before trying to change the driver core. > Just as an aside, the amount of probe-defer adds quite a lot of noise > when you are trying to debug why some driver doesn't probe > successfully. Which itself would be a nice reason to do something > more clever.. People seem to not like the noise, so let's turn off those messages, that should speed things up :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Den 17.10.2015 20:45, skrev Rob Clark: > On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: >> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: >>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman >>> <gregkh@linuxfoundation.org> wrote: >>>>> I'm guessing the time is a matter of probing and undoing the probes >>>>> rather than slow h/w. We could maybe improve things by making sure >>>>> drivers move what they defer on to the beginning of probe, but that >>>>> seems like a horrible, fragile hack. >>>> How can calling probe and failing cause 2 seconds? How many different >>>> probe calls are failing here? Again, a boot log graph would be great to >>>> see as it will show the root cause, not just guessing at this. >>> >>> just fwiw, but when you have a driver that depends on several other >>> drivers (which in turn depend on other drivers and so on), the amount >>> of probe-defer we end up seeing is pretty comical. Yeah, there >>> probably is some room to optimize by juggling around order drivers do >>> things in probe. But that doesn't solve the fundamental problem with >>> the current state, about probe order having no clue about >>> dependencies.. >> I can imagine it is a lot of iterations, but how long does it really >> take? How many different devices are involved that it takes multiple >> loops in order to finally work out the correct order? Where is the time >> delays here, just calling probe() and having it instantly return >> shouldn't take all that long. > offhand, I think the dependencies go at *least* three levels deep.. > I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to > get all the way through requesting it's various different > regulators/clks/gpios. I hadn't really paid attention to how many > tries the drivers I depend on go through. (Of those, I take clks from > two different clk drivers (which have dependency on a 3rd clk driver), > and regulators and gpio's come from at least two places, which in turn > have dependencies on clks, etc.) I don't have really good hard > numbers handy (since my observations of this are w/ console over uart > which effects timings, and so I see it taking much longer than 2sec).. > but the 2sec figure that Tomeu mentioned seemed pretty plausible to > me. > > I can try to get better #'s... I should have my kernel hat on at least > some of the time next week.. but the 2sec figure didn't seem > unrealistic to me. Are you saying that the total boot time is increased by 2 sec due to deferred probing, or that display initialization is happening 2 sec after it's first try? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote: >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman >> <gregkh@linuxfoundation.org> wrote: >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman >> >> <gregkh@linuxfoundation.org> wrote: >> >> >> I'm guessing the time is a matter of probing and undoing the probes >> >> >> rather than slow h/w. We could maybe improve things by making sure >> >> >> drivers move what they defer on to the beginning of probe, but that >> >> >> seems like a horrible, fragile hack. >> >> > >> >> > How can calling probe and failing cause 2 seconds? How many different >> >> > probe calls are failing here? Again, a boot log graph would be great to >> >> > see as it will show the root cause, not just guessing at this. >> >> >> >> >> >> just fwiw, but when you have a driver that depends on several other >> >> drivers (which in turn depend on other drivers and so on), the amount >> >> of probe-defer we end up seeing is pretty comical. Yeah, there >> >> probably is some room to optimize by juggling around order drivers do >> >> things in probe. But that doesn't solve the fundamental problem with >> >> the current state, about probe order having no clue about >> >> dependencies.. >> > >> > I can imagine it is a lot of iterations, but how long does it really >> > take? How many different devices are involved that it takes multiple >> > loops in order to finally work out the correct order? Where is the time >> > delays here, just calling probe() and having it instantly return >> > shouldn't take all that long. >> >> offhand, I think the dependencies go at *least* three levels deep.. >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to >> get all the way through requesting it's various different >> regulators/clks/gpios. > > And how long does that really take? Numbers please :) > >> I hadn't really paid attention to how many >> tries the drivers I depend on go through. (Of those, I take clks from >> two different clk drivers (which have dependency on a 3rd clk driver), >> and regulators and gpio's come from at least two places, which in turn >> have dependencies on clks, etc.) I don't have really good hard >> numbers handy (since my observations of this are w/ console over uart >> which effects timings, and so I see it taking much longer than 2sec).. >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to >> me. >> >> I can try to get better #'s... I should have my kernel hat on at least >> some of the time next week.. but the 2sec figure didn't seem >> unrealistic to me. > > Based on the time it takes a modern laptop to boot, 2 seconds is > forever, there has to be something else going on here other than just > calling probe() a bunch of times. Please use the tools we have to > determine this before trying to change the driver core. yes, I am aware of the tools.. although so far I spend most of my time just trying to get things working in the first place ;-) All I was trying to point out was that Tomeu's figures didn't really seem unrealistic. I mean, given that the average SoC driver probably depends on at least one clock and at least one regulator, having to probe each driver at least twice seems plausible. And that having a noticeable effect on boot time doesn't seem surprising. I'm not sure that saying 'modern laptop can boot in 2sec' adds much to the discussion since I don't think you have quite so much interdependency between devices vs random probe order. I have seen arm devices boot to UI in similar times, but that was pre-devicetree days. I expect Tomeu has some better number.. if not I can collect some. >> Just as an aside, the amount of probe-defer adds quite a lot of noise >> when you are trying to debug why some driver doesn't probe >> successfully. Which itself would be a nice reason to do something >> more clever.. > > People seem to not like the noise, so let's turn off those messages, > that should speed things up :) heh, except for when you are trying to debug what is missing preventing the driver you depend on from probing ;-) BR, -R -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 3:04 PM, Noralf Trønnes <noralf@tronnes.org> wrote: > > Den 17.10.2015 20:45, skrev Rob Clark: >> >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman >> <gregkh@linuxfoundation.org> wrote: >>> >>> On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: >>>> >>>> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman >>>> <gregkh@linuxfoundation.org> wrote: >>>>>> >>>>>> I'm guessing the time is a matter of probing and undoing the probes >>>>>> rather than slow h/w. We could maybe improve things by making sure >>>>>> drivers move what they defer on to the beginning of probe, but that >>>>>> seems like a horrible, fragile hack. >>>>> >>>>> How can calling probe and failing cause 2 seconds? How many different >>>>> probe calls are failing here? Again, a boot log graph would be great >>>>> to >>>>> see as it will show the root cause, not just guessing at this. >>>> >>>> >>>> just fwiw, but when you have a driver that depends on several other >>>> drivers (which in turn depend on other drivers and so on), the amount >>>> of probe-defer we end up seeing is pretty comical. Yeah, there >>>> probably is some room to optimize by juggling around order drivers do >>>> things in probe. But that doesn't solve the fundamental problem with >>>> the current state, about probe order having no clue about >>>> dependencies.. >>> >>> I can imagine it is a lot of iterations, but how long does it really >>> take? How many different devices are involved that it takes multiple >>> loops in order to finally work out the correct order? Where is the time >>> delays here, just calling probe() and having it instantly return >>> shouldn't take all that long. >> >> offhand, I think the dependencies go at *least* three levels deep.. >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to >> get all the way through requesting it's various different >> regulators/clks/gpios. I hadn't really paid attention to how many >> tries the drivers I depend on go through. (Of those, I take clks from >> two different clk drivers (which have dependency on a 3rd clk driver), >> and regulators and gpio's come from at least two places, which in turn >> have dependencies on clks, etc.) I don't have really good hard >> numbers handy (since my observations of this are w/ console over uart >> which effects timings, and so I see it taking much longer than 2sec).. >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to >> me. >> >> I can try to get better #'s... I should have my kernel hat on at least >> some of the time next week.. but the 2sec figure didn't seem >> unrealistic to me. > > > Are you saying that the total boot time is increased by 2 sec due to > deferred probing, or that display initialization is happening 2 sec > after it's first try? > The 2sec figure was from Tomeu, but I guess display should be probed in first pass through list of devices (and ofc deferring the first time), I'll say "probably both".. BR, -R -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 03:39:20PM -0400, Rob Clark wrote: > On Sat, Oct 17, 2015 at 2:59 PM, Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Sat, Oct 17, 2015 at 02:45:34PM -0400, Rob Clark wrote: > >> On Sat, Oct 17, 2015 at 2:27 PM, Greg Kroah-Hartman > >> <gregkh@linuxfoundation.org> wrote: > >> > On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote: > >> >> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman > >> >> <gregkh@linuxfoundation.org> wrote: > >> >> >> I'm guessing the time is a matter of probing and undoing the probes > >> >> >> rather than slow h/w. We could maybe improve things by making sure > >> >> >> drivers move what they defer on to the beginning of probe, but that > >> >> >> seems like a horrible, fragile hack. > >> >> > > >> >> > How can calling probe and failing cause 2 seconds? How many different > >> >> > probe calls are failing here? Again, a boot log graph would be great to > >> >> > see as it will show the root cause, not just guessing at this. > >> >> > >> >> > >> >> just fwiw, but when you have a driver that depends on several other > >> >> drivers (which in turn depend on other drivers and so on), the amount > >> >> of probe-defer we end up seeing is pretty comical. Yeah, there > >> >> probably is some room to optimize by juggling around order drivers do > >> >> things in probe. But that doesn't solve the fundamental problem with > >> >> the current state, about probe order having no clue about > >> >> dependencies.. > >> > > >> > I can imagine it is a lot of iterations, but how long does it really > >> > take? How many different devices are involved that it takes multiple > >> > loops in order to finally work out the correct order? Where is the time > >> > delays here, just calling probe() and having it instantly return > >> > shouldn't take all that long. > >> > >> offhand, I think the dependencies go at *least* three levels deep.. > >> I'd say, from memory, I see drm/msm taking at least 5 or 6 tries to > >> get all the way through requesting it's various different > >> regulators/clks/gpios. > > > > And how long does that really take? Numbers please :) > > > >> I hadn't really paid attention to how many > >> tries the drivers I depend on go through. (Of those, I take clks from > >> two different clk drivers (which have dependency on a 3rd clk driver), > >> and regulators and gpio's come from at least two places, which in turn > >> have dependencies on clks, etc.) I don't have really good hard > >> numbers handy (since my observations of this are w/ console over uart > >> which effects timings, and so I see it taking much longer than 2sec).. > >> but the 2sec figure that Tomeu mentioned seemed pretty plausible to > >> me. > >> > >> I can try to get better #'s... I should have my kernel hat on at least > >> some of the time next week.. but the 2sec figure didn't seem > >> unrealistic to me. > > > > Based on the time it takes a modern laptop to boot, 2 seconds is > > forever, there has to be something else going on here other than just > > calling probe() a bunch of times. Please use the tools we have to > > determine this before trying to change the driver core. > > yes, I am aware of the tools.. although so far I spend most of my time > just trying to get things working in the first place ;-) And that's where most people stop, if you want to make it fast, you have to put in more effort, sorry. Don't expect the driver core to work around driver bugs for you. > All I was trying to point out was that Tomeu's figures didn't really > seem unrealistic. I mean, given that the average SoC driver probably > depends on at least one clock and at least one regulator, having to > probe each driver at least twice seems plausible. And that having a > noticeable effect on boot time doesn't seem surprising. I'm not sure > that saying 'modern laptop can boot in 2sec' adds much to the > discussion since I don't think you have quite so much interdependency > between devices vs random probe order. I have seen arm devices boot > to UI in similar times, but that was pre-devicetree days. 2 extra probes add a second to the boot time? Those sound like really broken drivers to me :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote: > I can't see adding calls like this all over the tree just to solve a > bus-specific problem, you are adding of_* calls where they aren't > needed, or wanted, at all. This isn't bus specific, I'm not sure what makes you say that? > What is the root-problem of your delay in device probing? I read your > last patch series and I can't seem to figure out what the issue is that > this is solving in any "better" way from the existing deferred probing. So, I don't actually have any platforms that are especially bothered by this (at least not for my use cases) so there's a bit of educated guessing going on here but there's two broad things I'm aware of. One is that regardless of the actual performance of the system when deferred probe goes off it splats errors all over the console which makes it look like something is going wrong even if everything is fine in the end. If lots of deferred probing happens then the volume gets big too. People find this distracting, noisy and ugly - it obscures actual issues and trains people to ignore errors. I do think this is a reasonable concern and that it's worth trying to mitigate against deferral for this reason alone. We don't want to just ignore the errors and not print anything either since if the resource doesn't appear the user needs to know what is preventing the driver from instantiating so they can try to fix it. The other is that if you're printing to a serial console then that's not an especially fast operation so if you're getting lots of messages being printed simply physically outputting them takes measurable time. I'm not aware of any performance concerns outside of that, but like I say I'm not affected by this myself in any great way. Obviously this can be configured but not having actual errors on the console isn't super awesome either for systems that make use of the logging there and we don't have a good way of telling what's from deferral and what's not.
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: > > > I can't see adding calls like this all over the tree just to solve a > > bus-specific problem, you are adding of_* calls where they aren't > > needed, or wanted, at all. > > This isn't bus specific, I'm not sure what makes you say that? You are making it bus-specific by putting these calls all over the tree in different bus subsystems semi-randomly for all I can determine. > > What is the root-problem of your delay in device probing? I read your > > last patch series and I can't seem to figure out what the issue is that > > this is solving in any "better" way from the existing deferred probing. > > So, I don't actually have any platforms that are especially bothered by > this (at least not for my use cases) so there's a bit of educated > guessing going on here but there's two broad things I'm aware of. > > One is that regardless of the actual performance of the system when > deferred probe goes off it splats errors all over the console which > makes it look like something is going wrong even if everything is fine > in the end. If lots of deferred probing happens then the volume gets > big too. People find this distracting, noisy and ugly - it obscures > actual issues and trains people to ignore errors. I do think this is a > reasonable concern and that it's worth trying to mitigate against > deferral for this reason alone. We don't want to just ignore the errors > and not print anything either since if the resource doesn't appear the > user needs to know what is preventing the driver from instantiating so > they can try to fix it. This has come up many times, I have no objection to just turning that message into a debug message that can be dynamically enabled for those people wanting to debug their systems for boot time issues. Please send a patch to do so. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote: > On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote: > > I think Linus W, Mark B, and I all said a similar thing initially in > > that dependencies should be handled in the driver core. We went down > > the path of making this not firmware (aka bus) specific and an earlier > > version had just that (with fwnode_* calls). That turned out to be > > pointless as the calling locations were almost always in DT specific > > code anyway. If you notice, the calls are next to other DT specific > > calls generally (usually a "get"). So yes, I'd prefer not to have to > > touch every subsystem, but we had to do that anyway to add DT support. > If they are "next" to a call like that, why not put it in that call? I > really object to having to "sprinkle" this all over the kernel, for no > obvious reason why that is happening at all (look at the USB patch for > one such example.) I did ask that question myself IIRC - we could probably get a long way by trying to instantiate anything that looks probable when we do a phandle lookup on it.
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: > > > I can't see adding calls like this all over the tree just to solve a > > > bus-specific problem, you are adding of_* calls where they aren't > > > needed, or wanted, at all. > > This isn't bus specific, I'm not sure what makes you say that? > You are making it bus-specific by putting these calls all over the tree > in different bus subsystems semi-randomly for all I can determine. Do you mean firmware rather than bus here? I think that's the confusion I have... > > One is that regardless of the actual performance of the system when > > deferred probe goes off it splats errors all over the console which > > makes it look like something is going wrong even if everything is fine > > in the end. If lots of deferred probing happens then the volume gets > > big too. People find this distracting, noisy and ugly - it obscures > > actual issues and trains people to ignore errors. I do think this is a > > reasonable concern and that it's worth trying to mitigate against > > deferral for this reason alone. We don't want to just ignore the errors > > and not print anything either since if the resource doesn't appear the > > user needs to know what is preventing the driver from instantiating so > > they can try to fix it. > This has come up many times, I have no objection to just turning that > message into a debug message that can be dynamically enabled for those > people wanting to debug their systems for boot time issues. It's not just the driver core logging, it's also all the individual drivers logging that they failed to get whatever resource since silently failing is not a great user experience. Many, hopefully most, of the drivers don't actually have special handling for probe deferral since half the beauty of probe deferral is that the subsystem supplying the resource can just return -EPROBE_DEFER when it notices something is missing but might appear and then the drivers will do the right thing so long as they have error handling code that they really should have anyway. We'd need to have a special dev_err() that handled probe deferral errors for drivers to use during probe or some other smarts in the logging infrastructure. Which isn't a totally horrible idea.
On Sun, 2015-10-18 at 20:53 +0100, 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: > > > > > I can't see adding calls like this all over the tree just to solve a > > > > bus-specific problem, you are adding of_* calls where they aren't > > > > needed, or wanted, at all. > > > > This isn't bus specific, I'm not sure what makes you say that? > > > You are making it bus-specific by putting these calls all over the tree > > in different bus subsystems semi-randomly for all I can determine. > > Do you mean firmware rather than bus here? I think that's the confusion > I have... Certainly, if it literally is adding of_* calls then that would seem to be gratuitously firmware-specific. Nothing should be using those these days; any new code should be using the generic device property APIs (except in special cases).
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote: > On Sun, 2015-10-18 at 20:53 +0100, 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: > > > > > > > I can't see adding calls like this all over the tree just to solve a > > > > > bus-specific problem, you are adding of_* calls where they aren't > > > > > needed, or wanted, at all. > > > > > > This isn't bus specific, I'm not sure what makes you say that? > > > > > You are making it bus-specific by putting these calls all over the tree > > > in different bus subsystems semi-randomly for all I can determine. > > > > Do you mean firmware rather than bus here? I think that's the confusion > > I have... > > Certainly, if it literally is adding of_* calls then that would seem to > be gratuitously firmware-specific. Nothing should be using those these > days; any new code should be using the generic device property APIs > (except in special cases). I asked Linus Walleij about that with the fwnode_get_named_gpiod() stuff, and Linus didn't seem to know how this should be used. It doesn't help that dev->fwnode is not initialised, but dev->of_node is. Are we supposed to grope around in dev->of_node for the embedded fwnode instead of using dev->fwnode? At the moment, at least to me, fwnode looks like some kind of experimental half-baked thing rather than a real usable solution.
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote: > On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote: > > Do you mean firmware rather than bus here? I think that's the confusion > > I have... > Certainly, if it literally is adding of_* calls then that would seem to > be gratuitously firmware-specific. Nothing should be using those these > days; any new code should be using the generic device property APIs > (except in special cases). It's not entirely clear to me that we should be moving to fwnode_ wholesale yet - the last advice was to hold off for a little while which makes sense given that the ACPI community still doesn't seem to have worked out what it wants to do here and how. The x86 embedded people are all gung ho but it's less clear that anyone else wants to use _DSD in quite the same way (I know of some efforts to use _DSD separately to the DT compatibility stuff) and there are some vendors who definitely do have completely different binding schemes for ACPI and DT and therefore specifically care which is in use. It would really help if ACPI could get their binding review process in place, and if we do want to actually start converting everything to fwnode_ we need to start communicating that actively since otherwise people can't really be expected to know.
On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> 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: > >> > > I can't see adding calls like this all over the tree just to solve a >> > > bus-specific problem, you are adding of_* calls where they aren't >> > > needed, or wanted, at all. > >> > This isn't bus specific, I'm not sure what makes you say that? > >> You are making it bus-specific by putting these calls all over the tree >> in different bus subsystems semi-randomly for all I can determine. > > Do you mean firmware rather than bus here? I think that's the confusion > I have... Hi all, 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. 1) About the sprinkling of calls, everybody agreed it's a bad smell from the start, but the intention is to modify the behaviour of the already-DT-specific part of each subsystem without duplicating code. A way to avoid the sprinkling would be to move the storage and lookup of resources to the core (using classes and their list of devices to replace the likes of __of_usb_find_phy). I also like Mark's idea of calling of_device_probe from of_parse_phandle, which would be much less invasive but I'm not sure if it would be right to call that function in all the current cases in which of_parse_phandle is called. 2) About the goal of the series, what matters to my employer is that once a device defers its probe it's only going to be reprobed in late_initcall, after all the devices have been tentatively probed once. In the practice this means that devices get probed in a dependency order in which first go devices without dependencies then go up the tree until the leave devices (which tend to be the ones with effects visible to the user). This series changes to another dependency order in which when a leaf node gets probed, it recursively "pulls" its dependencies. This way we stop massively delaying the probing of the display devices and vendors can stop carrying sizeable hacks in their trees which just further reduce the incentive to upstream. The above is what funds this work, but in my personal opinion the biggest advantage of this work is that it makes development on embedded platforms more efficient because right now we don't have a way of telling if a device deferred its probe because of an ordering issue, or because there's a problem. If a device is available and has a compatible driver, but it cannot be probed because a dependency isn't going to be available, that's an error and is going to cause real-world problems unless the device is redundant. Currently we say nothing because with deferred probe the probe callbacks are also part of the mechanism that determines the dependency order. I have wasted countless hours hunting for the reason why a device didn't probe and I have heard the same several times from others. Having a specific switch for enabling deferred probe logging sounds good, but there's going to be hundreds of spurious messages about deferred probes that were just deferrals and only one of them is going to be the actual error in which a device failed to find a dependency. 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. 4) About the breakage we have seen, that's not caused so far by probing devices on-demand but by delaying probes until all built-in drivers have been registered. The latter isn't strictly needed for on-demand probing but without it most of the benefits are lost because probes of dependencies are going to be deferred because the drivers aren't there yet. We could avoid that by registering drivers also on-demand but we would need to make the matching information available beforehand, which is a massive change in itself. This should speed up boot some, and also cause leaf devices to be up earlier. One more thing about the breakage we have seen so far is that it's generally caused by implicit dependencies and hunting those is probably the second biggest timesink of the linux embedded developer after failed probes. We depend on hacks such as link order, node order in the DT, initcall gerrymandering and a blind hope in things that started some time ago to have finished by now. And those implicit dependencies are often left completely undocumented. This is really fragile and breaks often when changing something unrelated such as when adding another revision of a board or soc and a dependency starts deferring its probe or is delayed because of something else. Also breaks with async probing. Delayed probes can be reverted by disabling a Kconfig, so we can fix those issues in an ordered manner as time allows (we could disable it by default now and add CI jobs with that enabled during a transitory period). Back when I made the series FW-independent with fwnode additions I felt in my interaction with the ACPI folks that there's a bit of a chasm in this issue between embedded and non-embedded people. This could be because with ACPI most of the low-level hw elements such as clocks, regulators, gpios and pins are hidden from the kernel and are already ready when we start probing devices. With DT, the kernel has to initialize all those and only then it can initialize the higher level devices that depend on them. This means lots more of devices and dependencies and thus we feel more acutely the shortcomings of the current device framework at the scale we are using it today. I think that having all dependencies be explicit and represented in the device-driver model, along with a more advanced method of ordering probes is something that would be good to have at this moment, even if it won't benefit all users of the kernel. Thanks, Tomeu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 19, 2015 at 4:44 AM, David Woodhouse <dwmw2@infradead.org> wrote: > On Sun, 2015-10-18 at 20:53 +0100, 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: >> >> > > > I can't see adding calls like this all over the tree just to solve a >> > > > bus-specific problem, you are adding of_* calls where they aren't >> > > > needed, or wanted, at all. >> >> > > This isn't bus specific, I'm not sure what makes you say that? >> >> > You are making it bus-specific by putting these calls all over the tree >> > in different bus subsystems semi-randomly for all I can determine. >> >> Do you mean firmware rather than bus here? I think that's the confusion >> I have... > > Certainly, if it literally is adding of_* calls then that would seem to > be gratuitously firmware-specific. Nothing should be using those these > days; any new code should be using the generic device property APIs > (except in special cases). See version 2 of the series[1] which did that. It became obvious that was pointless because the call paths ended up looking like this: Generic subsystem code -> DT look-up code -> fwnode_probe_device -> of_probe_device Rob [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/361137.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote: > > > Certainly, if it literally is adding of_* calls then that would seem to > > be gratuitously firmware-specific. Nothing should be using those these > > days; any new code should be using the generic device property APIs > > (except in special cases). > > See version 2 of the series[1] which did that. It became obvious that > was pointless because the call paths ended up looking like this: > > Generic subsystem code -> DT look-up code -> fwnode_probe_device -> > of_probe_device You link to a thread which says that "AT LEAST CURRENTLY, the calling locations [the 'DT look-up code' you mention above] are DT specific functions anyway. 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. Sure, Russell is probably right that there are some places where the generic APIs need fixing because they don't quite cover all use cases yet. And Mark is (unfortunately) right that some people are inventing new bindings *purely* for ACPI which are different to the DT bindings for the same device. But still, in those cases you'll theoretically be able to see the *same* device represented under ACPI with *either* its new ACPI HID and the ACPI-specific bindings, *or* as a PRP0001 with the DT bindings. And this was always possible even with just DT — you could have two incompatible bindings for the *same* hardware, with different drivers. It was just a bad thing. And still is when one is ACPI and one is DT, in my opinion. None of that really negates that fact that we are *working* on cleaning these code paths up to be firmware-agnostic, and the fact that we haven't got to this one *yet* isn't necessarily a good reason to make it *worse* by adding new firmware-specificity to it.
On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote: > ... If a device is available and has > a compatible driver, but it cannot be probed because a dependency > isn't going to be available, that's an error and is going to cause > real-world problems unless the device is redundant. Currently we say > nothing because with deferred probe the probe callbacks are also part > of the mechanism that determines the dependency order. So what if device X depends on device Y, and we have a driver for device Y built-in to the kernel, but the driver for device X is a module? I don't see this being solvable in the way you describe above - it's going to identify X as being unable to be satisfied, and report it as an error - but it's not an error at all. > Having a specific switch for enabling deferred probe logging sounds > good, but there's going to be hundreds of spurious messages about > deferred probes that were just deferrals and only one of them is going > to be the actual error in which a device failed to find a dependency. Why would there be? Sounds like something's very wrong there. You should only get deferred probes for devices which are declared to be present, but their resources have not yet been satisfied. It doesn't change anything if you have a kernel with lots of device drivers or just the device drivers you need - the device drivers you don't need do not contribute to the deferred probing in any way. So, really, after boot and all appropriate modules have been loaded, you should end up with no deferred probes. Are you saying that you still have "hundreds" at that point? If you do, that sounds like there's something very wrong. > 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. For me, on my fastest ARM board, though running serial console: [ 2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1. There's a couple of delays in there, but they're not down to deferred probing. The biggest one is serial console startup (due to the time it takes to write out the initial kernel messages): [ 0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A [ 0.944124] console [ttyS0] enabled and DSA switch initialisation: [ 1.530655] libphy: dsa slave smi: probed [ 2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY] I'm not sure what causes that, but at a guess it's having to talk to the DSA switch over the MDIO bus via several layers of indirect accesses. Of course, serial console adds to the boot time significantly anyway, especially at the "standard" kernel logging level. > One more thing about the breakage we have seen so far is that it's > generally caused by implicit dependencies and hunting those is > probably the second biggest timesink of the linux embedded developer > after failed probes. ... which is generally caused by the crappy code which the average embedded Linux developer creates, particularly with the crappy error messages they like creating. For the most part, they _might_ as well just print "Error!\n" and be done with it, for all the use they are. When creating an error print, your average embedded Linux developer fails to print the _reason_ why something failed, which makes debugging it much harder. The first thing I do when I touch code that needs this kind of debugging is to go through and add printing of the error code. That normally lets me quickly narrow down what's failed. If embedded Linux developers are struggling with this, they only have themselves to blame. In the case of deferred probing, what _may_ help is if we got rid of the core code printing that driver X requested deferred probing, instead moving the responsibility to report this onto the driver or subsystem. Resource claiming generally has the struct device, and can use dev_warn() to report which device is being probed, along with which resource is not yet available. This debug problem is solvable without needing to resort to complex probing solutions.
On 19 October 2015 at 15:18, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote: >> ... If a device is available and has >> a compatible driver, but it cannot be probed because a dependency >> isn't going to be available, that's an error and is going to cause >> real-world problems unless the device is redundant. Currently we say >> nothing because with deferred probe the probe callbacks are also part >> of the mechanism that determines the dependency order. > > So what if device X depends on device Y, and we have a driver for > device Y built-in to the kernel, but the driver for device X is a > module? > > I don't see this being solvable in the way you describe above - it's > going to identify X as being unable to be satisfied, and report it as > an error - but it's not an error at all. It's going to probe Y at late_initcall, then probe X when its driver is registered. No deferred probes nor messages about it. But if you meant to write the opposite case (X built-in and Y in a module), then I have to ask you in what situation that would make sense. >> Having a specific switch for enabling deferred probe logging sounds >> good, but there's going to be hundreds of spurious messages about >> deferred probes that were just deferrals and only one of them is going >> to be the actual error in which a device failed to find a dependency. > > Why would there be? Sounds like something's very wrong there. Sorry about that, I have checked that only now and I "only" get 39 deferred probe messages on exynos5250-snow. > You should only get deferred probes for devices which are declared to > be present, but their resources have not yet been satisfied. It > doesn't change anything if you have a kernel with lots of device drivers > or just the device drivers you need - the device drivers you don't need > do not contribute to the deferred probing in any way. I don't think that the number of registered drivers affects the number of probes that get deferred (but I'm not sure why you mention that). > So, really, after boot and all appropriate modules have been loaded, > you should end up with no deferred probes. Are you saying that you > still have "hundreds" at that point? If you do, that sounds like > there's something very wrong. I was talking about messages if we log each -EPROBE_DEFER, not devices that remain to be probed. The point being that right now we don't have a way to know if we are deferring because the dependency will be around later, or if we have a problem and the dependency isn't going to be there at all. If we had a way to enable printing the cause of each -EPROBE_DEFER, right now that would print 39 messages of this board that are only due to ordering. The actual issue would be printed in exactly the same way somewhere in the middle. >> 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. > > For me, on my fastest ARM board, though running serial console: > > [ 2.293468] VFS: Mounted root (ext4 filesystem) on device 179:1. > > There's a couple of delays in there, but they're not down to deferred > probing. The biggest one is serial console startup (due to the time > it takes to write out the initial kernel messages): > > [ 0.289962] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 23, base_baud = 15625000) is a 16550A > [ 0.944124] console [ttyS0] enabled > > and DSA switch initialisation: > > [ 1.530655] libphy: dsa slave smi: probed > [ 2.034426] dsa dsa@0 lan6 (uninitialized): attached PHY at address 0 [Generic PHY] > > I'm not sure what causes that, but at a guess it's having to talk to the > DSA switch over the MDIO bus via several layers of indirect accesses. > Of course, serial console adds to the boot time significantly anyway, > especially at the "standard" kernel logging level. Yes, I don't think it makes any sense to measure boot times with the serial console on, because it's not comparable to production and because printing an additional line during boot affects significantly the times. To be clear, I was saying that this series should NOT affect total boot times much. >> One more thing about the breakage we have seen so far is that it's >> generally caused by implicit dependencies and hunting those is >> probably the second biggest timesink of the linux embedded developer >> after failed probes. > > ... which is generally caused by the crappy code which the average > embedded Linux developer creates, particularly with the crappy error > messages they like creating. For the most part, they _might_ as well > just print "Error!\n" and be done with it, for all the use they are. > When creating an error print, your average embedded Linux developer > fails to print the _reason_ why something failed, which makes debugging > it much harder. > > The first thing I do when I touch code that needs this kind of debugging > is to go through and add printing of the error code. That normally lets > me quickly narrow down what's failed. > > If embedded Linux developers are struggling with this, they only have > themselves to blame. > > In the case of deferred probing, what _may_ help is if we got rid of the > core code printing that driver X requested deferred probing, instead > moving the responsibility to report this onto the driver or subsystem. > Resource claiming generally has the struct device, and can use dev_warn() > to report which device is being probed, along with which resource is > not yet available. Agreed, with the note from above on why it would be better to only print such a message only when the -EPROBE_DEFER is likely to be a problem. > This debug problem is solvable without needing to resort to complex > probing solutions. If you really think anything in this series is complex, you should look at the other ones that tried to accomplish the same! Thanks, Tomeu > -- > 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 majordomo@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote: > On 19 October 2015 at 15:18, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote: > >> ... If a device is available and has > >> a compatible driver, but it cannot be probed because a dependency > >> isn't going to be available, that's an error and is going to cause > >> real-world problems unless the device is redundant. Currently we say > >> nothing because with deferred probe the probe callbacks are also part > >> of the mechanism that determines the dependency order. > > > > So what if device X depends on device Y, and we have a driver for > > device Y built-in to the kernel, but the driver for device X is a > > module? > > > > I don't see this being solvable in the way you describe above - it's > > going to identify X as being unable to be satisfied, and report it as > > an error - but it's not an error at all. > > It's going to probe Y at late_initcall, then probe X when its driver > is registered. No deferred probes nor messages about it. > > But if you meant to write the opposite case (X built-in and Y in a > module), then I have to ask you in what situation that would make > sense. I did mean the opposite way around. It may not make sense if you're targetting a single platform, but it may make sense in a single zImage kernel. Consider something like a single zImage kernel that is built with everything built-in to be able to boot and mount rootfs without initramfs support on both platform A and platform B. Both platforms share some hardware (eg, an I2C GPIO expander) which is built as a module. It is a resource provider. Platform B contains a driver which is required to boot on platform A, but not platform B (so the kernel has to have that driver built-in.) On platform B, there is a dependency to the I2C GPIO expander device. > >> Having a specific switch for enabling deferred probe logging sounds > >> good, but there's going to be hundreds of spurious messages about > >> deferred probes that were just deferrals and only one of them is going > >> to be the actual error in which a device failed to find a dependency. > > > > Why would there be? Sounds like something's very wrong there. > > Sorry about that, I have checked that only now and I "only" get 39 > deferred probe messages on exynos5250-snow. I typically see one or two, maybe five maximum on the platforms I have here, but normally zero. > > So, really, after boot and all appropriate modules have been loaded, > > you should end up with no deferred probes. Are you saying that you > > still have "hundreds" at that point? If you do, that sounds like > > there's something very wrong. > > I was talking about messages if we log each -EPROBE_DEFER, not devices > that remain to be probed. The point being that right now we don't have > a way to know if we are deferring because the dependency will be > around later, or if we have a problem and the dependency isn't going > to be there at all. What's the difference between a dependency which isn't around because the driver is not built into the kernel but is available as a module, and a dependency that isn't around because the module hasn't been loaded yet? How do you distinguish between those two scenarios? In the former scenario, the device will eventually come up when udev loads the module. In the latter case, it's a persistent failing case. > Agreed, with the note from above on why it would be better to only > print such a message only when the -EPROBE_DEFER is likely to be a > problem. ... and my argument is that there's _no way_ to know for certain which deferred probes will be a problem, and which won't. The only way to definitely know that is if you disable kernel modules, and require all drivers to be built into the kernel. 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.
On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote: > On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote: > > See version 2 of the series[1] which did that. It became obvious that > > was pointless because the call paths ended up looking like this: > > Generic subsystem code -> DT look-up code -> fwnode_probe_device -> > > of_probe_device > You link to a thread which says that "AT LEAST CURRENTLY, the calling > locations [the 'DT look-up code' you mention above] are DT specific > functions anyway. > 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. That seems like it's going to fall down since the different firmware interfaces do have quite different ideas about how things fit together at a system level and different compatibility needs which do suggest that just trying to do a direct mapping from DT into ACPI may well not make people happy but it sounds like that's the intention. When it gets to drivers the situation is much more clear since it's normally just simple properties, it's generally a bit more worrying if drivers are needing to directly interact with cross-device linkage. This is all subsystem level code though. > None of that really negates that fact that we are *working* on cleaning > these code paths up to be firmware-agnostic, and the fact that we > haven't got to this one *yet* isn't necessarily a good reason to make > it *worse* by adding new firmware-specificity to it. 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.
On 19 October 2015 at 16:30, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Oct 19, 2015 at 04:10:56PM +0200, Tomeu Vizoso wrote: >> On 19 October 2015 at 15:18, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > On Mon, Oct 19, 2015 at 02:34:22PM +0200, Tomeu Vizoso wrote: >> >> ... If a device is available and has >> >> a compatible driver, but it cannot be probed because a dependency >> >> isn't going to be available, that's an error and is going to cause >> >> real-world problems unless the device is redundant. Currently we say >> >> nothing because with deferred probe the probe callbacks are also part >> >> of the mechanism that determines the dependency order. >> > >> > So what if device X depends on device Y, and we have a driver for >> > device Y built-in to the kernel, but the driver for device X is a >> > module? >> > >> > I don't see this being solvable in the way you describe above - it's >> > going to identify X as being unable to be satisfied, and report it as >> > an error - but it's not an error at all. >> >> It's going to probe Y at late_initcall, then probe X when its driver >> is registered. No deferred probes nor messages about it. >> >> But if you meant to write the opposite case (X built-in and Y in a >> module), then I have to ask you in what situation that would make >> sense. > > I did mean the opposite way around. It may not make sense if you're > targetting a single platform, but it may make sense in a single zImage > kernel. > > Consider something like a single zImage kernel that is built with > everything built-in to be able to boot and mount rootfs without > initramfs support on both platform A and platform B. Both platforms > share some hardware (eg, an I2C GPIO expander) which is built as a > module. It is a resource provider. Platform B contains a driver > which is required to boot on platform A, but not platform B (so the > kernel has to have that driver built-in.) On platform B, there is > a dependency to the I2C GPIO expander device. I see, in this situation the person trying to find out why some device hadn't probed would enable debug logging of failed probes and would see one spurious message if there was a deferred probe because of the module. >> >> Having a specific switch for enabling deferred probe logging sounds >> >> good, but there's going to be hundreds of spurious messages about >> >> deferred probes that were just deferrals and only one of them is going >> >> to be the actual error in which a device failed to find a dependency. >> > >> > Why would there be? Sounds like something's very wrong there. >> >> Sorry about that, I have checked that only now and I "only" get 39 >> deferred probe messages on exynos5250-snow. > > I typically see one or two, maybe five maximum on the platforms I have > here, but normally zero. Hmm, I have given a look at our lava farm and have seen 2 dozens as common (with multi_v7). >> > So, really, after boot and all appropriate modules have been loaded, >> > you should end up with no deferred probes. Are you saying that you >> > still have "hundreds" at that point? If you do, that sounds like >> > there's something very wrong. >> >> I was talking about messages if we log each -EPROBE_DEFER, not devices >> that remain to be probed. The point being that right now we don't have >> a way to know if we are deferring because the dependency will be >> around later, or if we have a problem and the dependency isn't going >> to be there at all. > > What's the difference between a dependency which isn't around because > the driver is not built into the kernel but is available as a module, > and a dependency that isn't around because the module hasn't been > loaded yet? > > How do you distinguish between those two scenarios? In the former > scenario, the device will eventually come up when udev loads the > module. In the latter case, it's a persistent failing case. Agreed, but it's something that doesn't happen often and that's why such messages would be at the debug level instead of being warns or errors. >> Agreed, with the note from above on why it would be better to only >> print such a message only when the -EPROBE_DEFER is likely to be a >> problem. > > ... and my argument is that there's _no way_ to know for certain which > deferred probes will be a problem, and which won't. The only way to > definitely know that is if you disable kernel modules, and require > all drivers to be built into the kernel. > > 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... Thanks, Tomeu > -- > 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 majordomo@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. > 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 :)
On Mon, Oct 19, 2015 at 05:00:54PM +0200, Tomeu Vizoso wrote: > On 19 October 2015 at 16:30, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > I typically see one or two, maybe five maximum on the platforms I have > > here, but normally zero. > > Hmm, I have given a look at our lava farm and have seen 2 dozens as > common (with multi_v7). No, because the lava farms tend not to be public. > > 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. 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.
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'd like to use the gpiod_* stuff, but I feel that my options are rather limited: either use fwnode_get_named_gpiod() with &dev->of_node->fwnode, which seems like a hack by going underneath the covers of how fwnode is (partially) implemented with DT, or by using of_get_named_gpio() and the converting the gpio number to a descriptor via gpio_to_desc(). Both feel very hacky. 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, and it seems to make the use of the gpiod* interfaces where we _do_ need to use it (DT) harder and more hacky.
On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
Hi Russell, On Mon, Oct 19, 2015 at 5:35 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> 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 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > <linux@arm.linux.org.uk> 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.
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
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, &flags); 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.
On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> 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" or "it" is. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> 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, &flags); > 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote: > On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> 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 > 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. The "that happened to be created by DT" part is of concern here. What is there that makes DT special in that respect? Why shouldn't that be applicable to devices created by the ACPI core, for example, or by a board file or something else? > > 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. ACPI uses platform devices too. In fact, ACPI device objects are enumerated as platform devices by default now. Or do you means something else here? > 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. It explains the context of the series, so it is useful to talk about IMO. > > > 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" or "it" is. OK, so maybe I misunderstood you, sorry about that. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <this> controller and GPIOs #27 and #31 from <that> 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.
On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> 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 <rjw@rjwysocki.net> wrote: >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> 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 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. My understanding was with deferred probe that it also solves suspend ordering problems because things are suspended in reverse order of probing. I suppose you could have slightly different dependencies for suspend, runtime PM, etc. than for probe? Perhaps we need to save the list of dependencies as we probe them. I don't think that would be too hard to add on to this series, but then if we don't need it now, why add it? >> >> 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. > > The "that happened to be created by DT" part is of concern here. What is there > that makes DT special in that respect? Why shouldn't that be applicable to > devices created by the ACPI core, for example, or by a board file or something > else? DT is first. I think both examples could use this. Board files avoid the problem by controlling the registration order with initcall levels and just the call order in the code. You could come up with some way to define dependencies for devices in board files and reuse this mechanism. ACPI could use this as well if the dependencies are handled in a similar way and it seems like they could be. >> > 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. > > 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(&pdev->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. Converting things like this to fwnode calls isn't hard to do. There just hasn't been a pressing need or mandate to do so. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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...
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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> 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 majordomo@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki <rjw@rjwysocki.net> 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 <rjw@rjwysocki.net> wrote: > >> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote: > >> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse <dwmw2@infradead.org> 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 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. Well, something along these lines probably. > >> 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. > > My understanding was with deferred probe that it also solves suspend > ordering problems because things are suspended in reverse order of > probing. I suppose you could have slightly different dependencies for > suspend, runtime PM, etc. than for probe? Perhaps we need to save the > list of dependencies as we probe them. I don't think that would be too > hard to add on to this series, but then if we don't need it now, why > add it? As Alan said, there are two problems here. First off, the ordering of the list used by system suspend/resume is the registration ordering, not the probe ordering. Moreover, though, even if we get the ordering right, it still is not sufficient for devices with async_suspend set. To address this, the core will have to make the involved async threads wait for each other in accordance with the dependencies too. That, in turn, is very close to what's needed for runtime PM. > >> >> 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. > > > > The "that happened to be created by DT" part is of concern here. What is there > > that makes DT special in that respect? Why shouldn't that be applicable to > > devices created by the ACPI core, for example, or by a board file or something > > else? > > DT is first. I think both examples could use this. Board files avoid > the problem by controlling the registration order with initcall levels > and just the call order in the code. You could come up with some way > to define dependencies for devices in board files and reuse this > mechanism. ACPI could use this as well if the dependencies are handled > in a similar way and it seems like they could be. > > >> > 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. > > > > 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(&pdev->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. > Converting things like this to fwnode calls isn't hard to do. There > just hasn't been a pressing need or mandate to do so. Well, to me the problem is actually generic, so it is better to use generic concepts to start with when trying to address it where that doesn't add too much overhead. Otherwise it's very easy to lose the broader context from one's sight and then to start cutting corners. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > 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 >> <linux@arm.linux.org.uk> 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.) I like the concept (I have been thinking along similar lines lately). But I think this might make the console messages more confusing than they are now. The problem is that debug, warn, and error messages come from a somewhat random set of locations at the moment. Some come from the driver probe routines and some come from the subsystems that the probe routines call. So the patch is suppressing some messages, but not others. One thing that seemed pretty obvious from the patches is that the current probe routines are somewhat inconsistent in terms of messages, and that there is room for a set of best practices for messaging. That is on my long term wish list, but I'm not sure I'll ever chase after those windmills. A couple of specific comments below. > > 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(&deferred_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", &vaf); > + va_end(ap); > + } > +} > +EXPORT_SYMBOL_GPL(dev_warn_deferred); The places where dev_warn_deferred() replaces dev_dbg(), we lose the ability to turn on debugging and observe the driver reporting the specific reason the deferral is occurring. So it would be useful to add an "else dev_dbg()" in dev_warn_deferred() to retain that capability. > + > 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(); Couldn't you put the "driver_deferred_probe_report = true" here? And then not add another round of probes. > /* 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 possible before exiting initcalls */ > + flush_workqueue(deferred_wq); > + > return 0; > } < snip > -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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...
On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: > On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > > 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 > >> <linux@arm.linux.org.uk> 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.) > > I like the concept (I have been thinking along similar lines lately). > But I think this might make the console messages more confusing than > they are now. If messages end up being given from the subsystem rather than the driver, surely they become more consistent? > The problem is that debug, warn, and error messages > come from a somewhat random set of locations at the moment. Some > come from the driver probe routines and some come from the subsystems > that the probe routines call. So the patch is suppressing some > messages, but not others. The patch is not complete (read the description above). > > +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", &vaf); > > + va_end(ap); > > + } > > +} > > +EXPORT_SYMBOL_GPL(dev_warn_deferred); > > The places where dev_warn_deferred() replaces dev_dbg(), we lose the > ability to turn on debugging and observe the driver reporting the > specific reason the deferral is occurring. So it would be useful to > add an "else dev_dbg()" in dev_warn_deferred() to retain that capability. That's a possibility. > > > + > > 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(); > > Couldn't you put the "driver_deferred_probe_report = true" here? And then > not add another round of probes. The idea is not to report anything for drivers that were deferred during the normal bootup. The above is part of the normal bootup, and the deferred activity should not be warned about. If we have any devices still deferring after _this_ round, that must indicate that some resource they want is not available, and that should be warned about. Of course, modules can defer too - and I made some suggestions in my waffle above the patch about that.
Hi Rafael, On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki <rjw@rjwysocki.net> 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 <rjw@rjwysocki.net> 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(&pdev->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 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: < snip > >>> + >>> 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(); >> >> Couldn't you put the "driver_deferred_probe_report = true" here? And then >> not add another round of probes. > > The idea is not to report anything for drivers that were deferred > during the normal bootup. The above is part of the normal bootup, > and the deferred activity should not be warned about. The above is currently the last point for probe to succeed or defer (until possibly, as you mentioned, module loading resolves the defer). If a probe defers above, it will defer again below. The set of defers should be exactly the same above and below. > > If we have any devices still deferring after _this_ round, that must > indicate that some resource they want is not available, and that > should be warned about. > > Of course, modules can defer too - and I made some suggestions in my > waffle above the patch about that. > < adding back trimmed, for fuller context > >>> /* 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 possible before exiting initcalls */ >>> + flush_workqueue(deferred_wq); >>> + >>> return 0; >>> } -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > On 18 October 2015 at 21:53, Mark Brown <broonie@kernel.org> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
On 10/21/2015 06:36 PM, Frank Rowand wrote: > On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: >> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: >>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > > < snip > > >>>> + >>>> 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(); >>> >>> Couldn't you put the "driver_deferred_probe_report = true" here? And then >>> not add another round of probes. >> >> The idea is not to report anything for drivers that were deferred >> during the normal bootup. The above is part of the normal bootup, >> and the deferred activity should not be warned about. > > The above is currently the last point for probe to succeed or defer > (until possibly, as you mentioned, module loading resolves the defer). > If a probe defers above, it will defer again below. The set of defers > should be exactly the same above and below. > Unfortunately this is not "the last point for probe to succeed or defer". There are still a bunch of drivers in Kernel which will be probed at late_initcall() level. (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init); Yes - they probably need to be updated to use module_init(), but that's what we have now). Those drivers will re-trigger deferred device probing if their probe succeeded. As result, it is impossible to say when will it happen the "final round of deferred device probing" :( and final list of drivers which was "deferred forever" will be know only when kernel exits to User space ("deferred forever" - before loading modules). May be, we also can consider adding debug_fs entry which can be used to display actual state of deferred_probe_pending_list? >> >> If we have any devices still deferring after _this_ round, that must >> indicate that some resource they want is not available, and that >> should be warned about. >> >> Of course, modules can defer too - and I made some suggestions in my >> waffle above the patch about that. >> > > < adding back trimmed, for fuller context > > >>>> /* 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 possible before exiting initcalls */ >>>> + flush_workqueue(deferred_wq); >>>> + >>>> return 0; >>>> }
On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote: > On 10/21/2015 06:36 PM, Frank Rowand wrote: > > The above is currently the last point for probe to succeed or defer > > (until possibly, as you mentioned, module loading resolves the defer). > > If a probe defers above, it will defer again below. The set of defers > > should be exactly the same above and below. > > > > Unfortunately this is not "the last point for probe to succeed or defer". Of course it isn't. Being pedantic, there's actually no such thing, because the point that the kernel as finished booting can never actually be determined with things like modules being present. That's something I've acknowledged from the start of this. > There are still a bunch of drivers in Kernel which will be probed at late_initcall() level. > (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init); > Yes - they probably need to be updated to use module_init(), but that's what > we have now). Those drivers will re-trigger deferred device probing if their > probe succeeded. Maybe this particular late_initcall() which triggers off the deferred probing should be moved to its own really_late_initcall() which happens as the very last thing - I think this is intended to run after everything else has had a chance to probe once. > As result, it is impossible to say when will it happen the > "final round of deferred device probing" :( and final list of drivers > which was "deferred forever" will be know only when kernel exits to > User space ("deferred forever" - before loading modules). > > May be, we also can consider adding debug_fs entry which can be used to > display actual state of deferred_probe_pending_list? There are complaints in this thread about the existing deferred probing implementation being hard to debug - where it's known that a device has deferred, but it's not known why that happened. That would be solved by my proposal, as this final round of probing before entering userspace after _all_ normal device probes have been attempted once and then we've tried to satisfy the deferred probe (okay, that's what it's _supposed_ to be - and as it takes three lines to write it, you'll excuse me if I just use the abbreviated "final round of deferred probe" which is much shorter - but remember that the long version is what I actually mean) would produce a list of not only the devices that failed to probe, but also the cause of the deferred probes. My proposal would ensure that subsystems are happier to add these prints, because in the normal scenario where we have deferred probing, we're not littering the console log with lots of useless failure messages which make people stop and think "now did device X probe?" It also means scripts in our boot farms can more effectively analyse the log and determine whether the boot was actually successful and contained no errors. Merely printing the list of devices which have been deferred is next to useless. The next question will always be "why did device X defer?" and if that can't be answered, it means people having to spend a long time adding lots of printks to the kernel at lots of -EPROBE_DEFER returning sites or in the relevant drivers, tracing through the code back towards the -EPROBE_DEFER sites to try and track it down.
On 10/21/2015 9:55 AM, Grygorii Strashko wrote: > On 10/21/2015 06:36 PM, Frank Rowand wrote: >> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: >>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: >>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: >> >> < snip > >> >>>>> + >>>>> 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(); >>>> >>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then >>>> not add another round of probes. >>> >>> The idea is not to report anything for drivers that were deferred >>> during the normal bootup. The above is part of the normal bootup, >>> and the deferred activity should not be warned about. >> >> The above is currently the last point for probe to succeed or defer >> (until possibly, as you mentioned, module loading resolves the defer). >> If a probe defers above, it will defer again below. The set of defers >> should be exactly the same above and below. >> > > Unfortunately this is not "the last point for probe to succeed or defer". > There are still a bunch of drivers in Kernel which will be probed at late_initcall() level. > (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init); Yes, cpsw_init() should _not_ be a late_initcall. This is yet another example of playing games with ordering probes that we have been trying to eliminate. Thanks for pointing out one of the resulting problems this causes for the deferred probe mechanism. > Yes - they probably need to be updated to use module_init(), but that's what > we have now). Those drivers will re-trigger deferred device probing if their > probe succeeded. Yes, if cpsw_init() leads to a successful probe, then deferred device probing will be re-triggered. I do not know if cpsw_init() will be called before or after deferred_probe_initcall(). The general initcall mechanism does not provide any ordering guarantees between the two functions because they are at the same initcall level. > > As result, it is impossible to say when will it happen the > "final round of deferred device probing" :( and final list of drivers which > was "deferred forever" will be know only when kernel exits to User space > ("deferred forever" - before loading modules). > > May be, we also can consider adding debug_fs entry which can be used to display > actual state of deferred_probe_pending_list? > >>> >>> If we have any devices still deferring after _this_ round, that must >>> indicate that some resource they want is not available, and that >>> should be warned about. >>> >>> Of course, modules can defer too - and I made some suggestions in my >>> waffle above the patch about that. >>> >> >> < adding back trimmed, for fuller context > >> >>>>> /* 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 possible before exiting initcalls */ >>>>> + flush_workqueue(deferred_wq); >>>>> + >>>>> return 0; >>>>> } > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Russell, On 10/21/2015 08:20 PM, Russell King - ARM Linux wrote: > On Wed, Oct 21, 2015 at 07:55:29PM +0300, Grygorii Strashko wrote: >> On 10/21/2015 06:36 PM, Frank Rowand wrote: >>> The above is currently the last point for probe to succeed or defer >>> (until possibly, as you mentioned, module loading resolves the defer). >>> If a probe defers above, it will defer again below. The set of defers >>> should be exactly the same above and below. >>> >> >> Unfortunately this is not "the last point for probe to succeed or defer". > > Of course it isn't. Being pedantic, there's actually no such thing, > because the point that the kernel as finished booting can never actually > be determined with things like modules being present. That's something > I've acknowledged from the start of this. > >> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level. >> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init); >> Yes - they probably need to be updated to use module_init(), but that's what >> we have now). Those drivers will re-trigger deferred device probing if their >> probe succeeded. > > Maybe this particular late_initcall() which triggers off the deferred > probing should be moved to its own really_late_initcall() which happens > as the very last thing - I think this is intended to run after everything > else has had a chance to probe once. > >> As result, it is impossible to say when will it happen the >> "final round of deferred device probing" :( and final list of drivers >> which was "deferred forever" will be know only when kernel exits to >> User space ("deferred forever" - before loading modules). >> >> May be, we also can consider adding debug_fs entry which can be used to >> display actual state of deferred_probe_pending_list? > > There are complaints in this thread about the existing deferred probing > implementation being hard to debug - where it's known that a device > has deferred, but it's not known why that happened. > > That would be solved by my proposal, as this final round of probing > before entering userspace after _all_ normal device probes have been > attempted once and then we've tried to satisfy the deferred probe > (okay, that's what it's _supposed_ to be - and as it takes three lines > to write it, you'll excuse me if I just use the abbreviated "final > round of deferred probe" which is much shorter - but remember that > the long version is what I actually mean) would produce a list of > not only the devices that failed to probe, but also the cause of the > deferred probes. > > My proposal would ensure that subsystems are happier to add these > prints, because in the normal scenario where we have deferred probing, > we're not littering the console log with lots of useless failure > messages which make people stop and think "now did device X probe?" > It also means scripts in our boot farms can more effectively analyse > the log and determine whether the boot was actually successful and > contained no errors. > > Merely printing the list of devices which have been deferred is next > to useless. The next question will always be "why did device X defer?" > and if that can't be answered, it means people having to spend a long > time adding lots of printks to the kernel at lots of -EPROBE_DEFER > returning sites or in the relevant drivers, tracing through the code > back towards the -EPROBE_DEFER sites to try and track it down. > I perfectly understand your proposal and spent a lot of time trying to debug such kind issues also (and using printks). But I worry a bit (and that my main point) about these few additional rounds of deferred device probing which I have right now and which allows some of drivers to finish, finally, their probes successfully. With proposed change I'll get more messages in boot log, but some of them will belong to drivers which have been probed successfully and so, they will be not really useful. As result, I think, the most important thing is to identify (or create) some point during kernel boot when it will be possible to say that all built-in drivers (at least) finish their probes 100% (done or defer). Might be do_initcalls() can be updated (smth like this): static void __init do_initcalls(void) { int level; for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++) do_initcall_level(level); + wait_for_device_probe(); + /* Now one final round, reporting any devices that remain deferred */ + driver_deferred_probe_report = true; + driver_deferred_probe_trigger(); + wait_for_device_probe(); } Also, in my opinion, it will be useful if this debugging feature will be optional. Thanks.
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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote: > But I worry a bit (and that my main point) about these few additional > rounds of deferred device probing which I have right now and which allows > some of drivers to finish, finally, their probes successfully. > With proposed change I'll get more messages in boot log, but some of > them will belong to drivers which have been probed successfully and so, > they will be not really useful. Then you haven't properly understood my proposal. I want to get rid of all the "X deferred its probing" messages up until the point that we set the "please report deferred probes" flag. That _should_ mean that all the deferred probing that goes on becomes _totally_ silent and becomes hidden (unless you really want to see it, in which case we can make a debug option which turns it on) up until we're at the point where we want to enter userspace. At that point, we then report into the kernel log which devices are still deferring and, via appropriately placed dev_warn_deferred(), the reasons why the devices are being deferred. So, gone will be all the messages earlier in the log about device X not having a GPIO/clock/whatever because the device providing the GPIO/clock/whatever hasn't been probed. If everything is satisfied by the time we run this last round (again, I'm not using a three line sentence to describe exactly what I mean, I'm sure you know by now... oops, I just did) then the kernel will report nothing about any deferrals. That's _got_ to be an improvement. > > As result, I think, the most important thing is to identify (or create) > some point during kernel boot when it will be possible to say that all > built-in drivers (at least) finish their probes 100% (done or defer). > > Might be do_initcalls() can be updated (smth like this): > static void __init do_initcalls(void) > { > int level; > > for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++) > do_initcall_level(level); > > + wait_for_device_probe(); > + /* Now one final round, reporting any devices that remain deferred */ > + driver_deferred_probe_report = true; > + driver_deferred_probe_trigger(); > + wait_for_device_probe(); > } > > Also, in my opinion, it will be useful if this debugging feature will be > optional. I wonder why you want it optional... so I'm going to guess and cover both cases I can think of below to head off another round of reply on this point (sorry if this sucks eggs.) I don't see it as being optional, because it's going to be cheap to run in the case of a system which has very few or no errors - which is what you should have for production systems, right? Remember, only devices and drivers that are present and have been probed once get added to the deferred probe list, not devices for which their drivers are modules.
On 10/21/2015 09:02 PM, Frank Rowand wrote: > On 10/21/2015 9:55 AM, Grygorii Strashko wrote: >> On 10/21/2015 06:36 PM, Frank Rowand wrote: >>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: >>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: >>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: >>> >>> < snip > >>> >>>>>> + >>>>>> 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(); >>>>> >>>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then >>>>> not add another round of probes. >>>> >>>> The idea is not to report anything for drivers that were deferred >>>> during the normal bootup. The above is part of the normal bootup, >>>> and the deferred activity should not be warned about. >>> >>> The above is currently the last point for probe to succeed or defer >>> (until possibly, as you mentioned, module loading resolves the defer). >>> If a probe defers above, it will defer again below. The set of defers >>> should be exactly the same above and below. >>> >> >> Unfortunately this is not "the last point for probe to succeed or defer". >> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level. >> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init); > > Yes, cpsw_init() should _not_ be a late_initcall. This is yet another > example of playing games with ordering probes that we have been trying > to eliminate. yes, we're trying to solve such issues and have all TI's drivers initialized from module_init() level, but as usual this process is not so fast. You know, some times ago there was no other way to solve boot ordering issues, but only to play with init levels :) And, as result, right now in drivers/ and sound/ folders there are >77 occurrences of late_initcall(). > > Thanks for pointing out one of the resulting problems this causes for the > deferred probe mechanism. > >> Yes - they probably need to be updated to use module_init(), but that's what >> we have now). Those drivers will re-trigger deferred device probing if their >> probe succeeded. > > Yes, if cpsw_init() leads to a successful probe, then deferred device probing > will be re-triggered. I do not know if cpsw_init() will be called before or > after deferred_probe_initcall(). The general initcall mechanism does not > provide any ordering guarantees between the two functions because they are > at the same initcall level. It will be called after and it will re-triggered deferred device probing. Now ordering of init calls will be specified by drivers/Makefile which itself is funny thing. > >> >> As result, it is impossible to say when will it happen the >> "final round of deferred device probing" :( and final list of drivers which >> was "deferred forever" will be know only when kernel exits to User space >> ("deferred forever" - before loading modules). >> >> May be, we also can consider adding debug_fs entry which can be used to display >> actual state of deferred_probe_pending_list? >> >>>> >>>> If we have any devices still deferring after _this_ round, that must >>>> indicate that some resource they want is not available, and that >>>> should be warned about. >>>> >>>> Of course, modules can defer too - and I made some suggestions in my >>>> waffle above the patch about that. >>>> >>> >>> < adding back trimmed, for fuller context > >>> >>>>>> /* 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 possible before exiting initcalls */ >>>>>> + flush_workqueue(deferred_wq); >>>>>> + >>>>>> return 0; >>>>>> } >> >> >
On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote: > On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: > > On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: > >> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: > > < snip > > > >>> + > >>> 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(); > >> > >> Couldn't you put the "driver_deferred_probe_report = true" here? And then > >> not add another round of probes. > > > > The idea is not to report anything for drivers that were deferred > > during the normal bootup. The above is part of the normal bootup, > > and the deferred activity should not be warned about. > > The above is currently the last point for probe to succeed or defer > (until possibly, as you mentioned, module loading resolves the defer). > If a probe defers above, it will defer again below. The set of defers > should be exactly the same above and below. Why should it? Isn't this late_initcall() the first opportunity that deferred devices get to be re-probed from their first set of attempts via the drivers having their initcalls called? If what you're saying is true, what's the point of this late_initcall()? <re-cut again, I've no idea why you keep adding it back>
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).
On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/21/2015 2:12 PM, Rob Herring wrote: > On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <rjw@rjwysocki.net> 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 <rjw@rjwysocki.net> 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(&pdev->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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/21/2015 1:35 PM, Russell King - ARM Linux wrote: > On Wed, Oct 21, 2015 at 08:36:23AM -0700, Frank Rowand wrote: >> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote: >>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote: >>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote: >> >> < snip > >> >>>>> + >>>>> 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(); >>>> >>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then >>>> not add another round of probes. >>> >>> The idea is not to report anything for drivers that were deferred >>> during the normal bootup. The above is part of the normal bootup, >>> and the deferred activity should not be warned about. >> >> The above is currently the last point for probe to succeed or defer >> (until possibly, as you mentioned, module loading resolves the defer). >> If a probe defers above, it will defer again below. The set of defers >> should be exactly the same above and below. > > Why should it? My assertion was incorrect. A probe in the deferral processing can result in the driver being placed on the new deferred list, then when a later probe of another deferred driver succeeds, the first driver will be moved to the active deferred list, and might succeed on the second probe attempt (or with the current messages would result in a second set of deferred messages). So yes, placing "driver_deferred_probe_report = true" where your patch put it and running through the deferred probe processing again is correct. -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote: > On 10/21/2015 2:12 PM, Rob Herring wrote: >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> 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 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 majordomo@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 22 October 2015 at 02:54, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: >> On 20 October 2015 at 18:04, Alan Stern <stern@rowland.harvard.edu> 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 majordomo@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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", &vaf); > + 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.
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > On 21 October 2015 at 23:50, Frank Rowand <frowand.list@gmail.com> wrote: > > On 10/21/2015 2:12 PM, Rob Herring wrote: > >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand <frowand.list@gmail.com> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
<oops, sent too early...> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote: > <oops, sent too early...> > > 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. +100000000000, 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. :)
On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > <oops, sent too early...> > > 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > <oops, sent too early...> > > > > 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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: >>> <oops, sent too early...> >>> >>> 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, 145b0000.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.000000] Booting Linux on physical CPU 0x0 [ 0.000000] 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.000000] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [ 0.000000] Machine model: Google Snow [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] cma: Reserved 64 MiB at 0xbc000000 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] Samsung CPU ID: 0x43520010 [ 0.000000] On node 0 totalpages: 524288 [ 0.000000] free_area_init_node: node 0, pgdat c083cc40, node_mem_map eeff7000 [ 0.000000] Normal zone: 1536 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 327680 pages, LIFO batch:31 [ 0.000000] PERCPU: Embedded 12 pages/cpu @eefa7000 s18880 r8192 d22080 u49152 [ 0.000000] pcpu-alloc: s18880 r8192 d22080 u49152 alloc=12*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522752 [ 0.000000] Kernel command line: console=tty1 initcall_debug rw rootwait root=/dev/nfs nfsroot=10.42.0.1:/home/tomeu/nfsroot,vers=3 ip=dhcp ignore_loglevel log_buf_len=16M drm.debug=0x00 no_console_suspend [ 0.000000] log_buf_len: 16777216 bytes [ 0.000000] early log buf free: 129580(98%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 1988920K/2097152K available (5722K kernel code, 238K rwdata, 2016K rodata, 428K init, 315K bss, 42696K reserved, 65536K cma-reserved, 1245184K highmem) [ 0.000000] Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .text : 0xc0008000 - 0xc0796ad4 (7739 kB) .init : 0xc0797000 - 0xc0802000 ( 428 kB) .data : 0xc0802000 - 0xc083dbc0 ( 239 kB) .bss : 0xc0840000 - 0xc088ec90 ( 316 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 32. [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2 [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] GIC physical location is 0x10481000 [ 0.000000] L2C: failed to init: -19 [ 0.000000] Exynos5250: clock setup completed, armclk=1700000000 [ 0.000000] Architected cp15 timer(s) running at 24.00MHz (virt). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [ 0.000002] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [ 0.000009] Switching to timer-based delay loop, resolution 41ns [ 0.000170] Ignoring duplicate/late registration of read_current_timer delay [ 0.000178] clocksource: mct-frc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns [ 0.000187] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [ 0.000484] Console: colour dummy device 80x30 [ 0.000824] console [tty1] enabled [ 0.000838] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000) [ 0.000858] pid_max: default: 32768 minimum: 301 [ 0.000937] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000950] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.001289] CPU: Testing write buffer coherency: ok [ 0.001421] CPU0: update cpu_capacity 1024 [ 0.001433] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.001492] calling cpu_suspend_alloc_sp+0x0/0x9c @ 1 [ 0.001507] initcall cpu_suspend_alloc_sp+0x0/0x9c returned 0 after 0 usecs [ 0.001527] calling init_static_idmap+0x0/0x114 @ 1 [ 0.001545] Setting up static identity map for 0x40008280 - 0x400082d8 [ 0.001564] initcall init_static_idmap+0x0/0x114 returned 0 after 0 usecs [ 0.001583] calling exynos_mcpm_init+0x0/0x168 @ 1 [ 0.001729] initcall exynos_mcpm_init+0x0/0x168 returned -19 after 0 usecs [ 0.001747] calling spawn_ksoftirqd+0x0/0x34 @ 1 [ 0.004936] initcall spawn_ksoftirqd+0x0/0x34 returned 0 after 4882 usecs [ 0.004955] calling init_workqueues+0x0/0x3dc @ 1 [ 0.019997] initcall init_workqueues+0x0/0x3dc returned 0 after 14648 usecs [ 0.020016] calling migration_init+0x0/0x6c @ 1 [ 0.020034] initcall migration_init+0x0/0x6c returned 0 after 0 usecs [ 0.020049] calling check_cpu_stall_init+0x0/0x20 @ 1 [ 0.020062] initcall check_cpu_stall_init+0x0/0x20 returned 0 after 0 usecs [ 0.020077] calling rcu_spawn_gp_kthread+0x0/0x104 @ 1 [ 0.020195] initcall rcu_spawn_gp_kthread+0x0/0x104 returned 0 after 0 usecs [ 0.020213] calling cpu_stop_init+0x0/0xac @ 1 [ 0.024982] initcall cpu_stop_init+0x0/0xac returned 0 after 4882 usecs [ 0.025000] calling cci_init+0x0/0x18 @ 1 [ 0.025080] initcall cci_init+0x0/0x18 returned -19 after 0 usecs [ 0.025098] calling rand_initialize+0x0/0x2c @ 1 [ 0.025214] initcall rand_initialize+0x0/0x2c returned 0 after 0 usecs [ 0.025232] calling dummy_timer_register+0x0/0x48 @ 1 [ 0.025247] initcall dummy_timer_register+0x0/0x48 returned 0 after 0 usecs [ 0.045065] CPU1: update cpu_capacity 1024 [ 0.045069] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.045119] Brought up 2 CPUs [ 0.045146] SMP: Total of 2 processors activated (96.00 BogoMIPS). [ 0.045156] CPU: All CPU(s) started in SVC mode. [ 0.045767] devtmpfs: initialized [ 0.055547] calling ipc_ns_init+0x0/0x3c @ 1 [ 0.055566] initcall ipc_ns_init+0x0/0x3c returned 0 after 0 usecs [ 0.055580] calling init_mmap_min_addr+0x0/0x20 @ 1 [ 0.055592] initcall init_mmap_min_addr+0x0/0x20 returned 0 after 0 usecs [ 0.055608] calling init_cpufreq_transition_notifier_list+0x0/0x24 @ 1 [ 0.055625] initcall init_cpufreq_transition_notifier_list+0x0/0x24 returned 0 after 0 usecs [ 0.055647] calling net_ns_init+0x0/0x14c @ 1 [ 0.055754] initcall net_ns_init+0x0/0x14c returned 0 after 0 usecs [ 0.055833] calling vfp_init+0x0/0x1b8 @ 1 [ 0.055847] VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0 [ 0.055871] initcall vfp_init+0x0/0x1b8 returned 0 after 0 usecs [ 0.055885] calling ptrace_break_init+0x0/0x2c @ 1 [ 0.055898] initcall ptrace_break_init+0x0/0x2c returned 0 after 0 usecs [ 0.055913] calling register_cpufreq_notifier+0x0/0x10 @ 1 [ 0.055926] initcall register_cpufreq_notifier+0x0/0x10 returned 0 after 0 usecs [ 0.055945] calling v6_userpage_init+0x0/0x8 @ 1 [ 0.055957] initcall v6_userpage_init+0x0/0x8 returned 0 after 0 usecs [ 0.055973] calling exynos4_pm_init_power_domain+0x0/0x2e0 @ 1 [ 0.056176] initcall exynos4_pm_init_power_domain+0x0/0x2e0 returned 0 after 0 usecs [ 0.056197] calling cpu_hotplug_pm_sync_init+0x0/0x18 @ 1 [ 0.056210] initcall cpu_hotplug_pm_sync_init+0x0/0x18 returned 0 after 0 usecs [ 0.056230] calling alloc_frozen_cpus+0x0/0x8 @ 1 [ 0.056241] initcall alloc_frozen_cpus+0x0/0x8 returned 0 after 0 usecs [ 0.056257] calling wq_sysfs_init+0x0/0x30 @ 1 [ 0.056444] initcall wq_sysfs_init+0x0/0x30 returned 0 after 0 usecs [ 0.056462] calling ksysfs_init+0x0/0xa4 @ 1 [ 0.056494] initcall ksysfs_init+0x0/0xa4 returned 0 after 0 usecs [ 0.056511] calling pm_init+0x0/0x78 @ 1 [ 0.056565] initcall pm_init+0x0/0x78 returned 0 after 0 usecs [ 0.056579] calling init_jiffies_clocksource+0x0/0x14 @ 1 [ 0.056592] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302231375000 ns [ 0.056610] initcall init_jiffies_clocksource+0x0/0x14 returned 0 after 0 usecs [ 0.056628] calling cgroup_wq_init+0x0/0x80 @ 1 [ 0.056665] initcall cgroup_wq_init+0x0/0x80 returned 0 after 0 usecs [ 0.056680] calling cpu_pm_init+0x0/0x18 @ 1 [ 0.056692] initcall cpu_pm_init+0x0/0x18 returned 0 after 0 usecs [ 0.056707] calling init_zero_pfn+0x0/0x40 @ 1 [ 0.056718] initcall init_zero_pfn+0x0/0x40 returned 0 after 0 usecs [ 0.056734] calling cma_init_reserved_areas+0x0/0x1d4 @ 1 [ 0.057256] initcall cma_init_reserved_areas+0x0/0x1d4 returned 0 after 0 usecs [ 0.057278] calling fsnotify_init+0x0/0x24 @ 1 [ 0.057294] initcall fsnotify_init+0x0/0x24 returned 0 after 0 usecs [ 0.057310] calling filelock_init+0x0/0xc4 @ 1 [ 0.057335] initcall filelock_init+0x0/0xc4 returned 0 after 0 usecs [ 0.057351] calling init_script_binfmt+0x0/0x1c @ 1 [ 0.057364] initcall init_script_binfmt+0x0/0x1c returned 0 after 0 usecs [ 0.057379] calling init_elf_binfmt+0x0/0x1c @ 1 [ 0.057391] initcall init_elf_binfmt+0x0/0x1c returned 0 after 0 usecs [ 0.057407] calling configfs_init+0x0/0xb0 @ 1 [ 0.057437] initcall configfs_init+0x0/0xb0 returned 0 after 0 usecs [ 0.057451] calling debugfs_init+0x0/0x68 @ 1 [ 0.057467] initcall debugfs_init+0x0/0x68 returned 0 after 0 usecs [ 0.057480] calling securityfs_init+0x0/0x58 @ 1 [ 0.057495] initcall securityfs_init+0x0/0x58 returned 0 after 0 usecs [ 0.057509] calling prandom_init+0x0/0xe4 @ 1 [ 0.057521] initcall prandom_init+0x0/0xe4 returned 0 after 0 usecs [ 0.057535] calling cci_platform_init+0x0/0x8 @ 1 [ 0.057546] initcall cci_platform_init+0x0/0x8 returned 0 after 0 usecs [ 0.057560] calling pinctrl_init+0x0/0xd4 @ 1 [ 0.057569] pinctrl core: initialized pinctrl subsystem [ 0.057622] initcall pinctrl_init+0x0/0xd4 returned 0 after 0 usecs [ 0.057638] calling regulator_init+0x0/0xa4 @ 1 [ 0.057836] bus: 'platform': driver_probe_device: matched device reg-dummy with driver reg-dummy [ 0.057855] bus: 'platform': really_probe: probing driver reg-dummy with device reg-dummy [ 0.058019] driver: 'reg-dummy': driver_bound: bound to device 'reg-dummy' [ 0.058033] bus: 'platform': really_probe: bound device reg-dummy to driver reg-dummy [ 0.058097] initcall regulator_init+0x0/0xa4 returned 0 after 0 usecs [ 0.058114] calling cpufreq_core_init+0x0/0x50 @ 1 [ 0.058126] initcall cpufreq_core_init+0x0/0x50 returned 0 after 0 usecs [ 0.058140] calling cpuidle_init+0x0/0x58 @ 1 [ 0.058163] initcall cpuidle_init+0x0/0x58 returned 0 after 0 usecs [ 0.058177] calling cpuidle_coupled_init+0x0/0xc @ 1 [ 0.058190] initcall cpuidle_coupled_init+0x0/0xc returned 0 after 0 usecs [ 0.058207] calling exynos_audss_clk_init+0x0/0x10 @ 1 [ 0.058265] initcall exynos_audss_clk_init+0x0/0x10 returned 0 after 0 usecs [ 0.058282] calling sock_init+0x0/0x94 @ 1 [ 0.058334] initcall sock_init+0x0/0x94 returned 0 after 0 usecs [ 0.058351] calling net_inuse_init+0x0/0x24 @ 1 [ 0.058365] initcall net_inuse_init+0x0/0x24 returned 0 after 0 usecs [ 0.058379] calling netlink_proto_init+0x0/0x148 @ 1 [ 0.058490] NET: Registered protocol family 16 [ 0.058519] initcall netlink_proto_init+0x0/0x148 returned 0 after 0 usecs [ 0.058604] calling atomic_pool_init+0x0/0x168 @ 1 [ 0.059145] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.059160] initcall atomic_pool_init+0x0/0x168 returned 0 after 0 usecs [ 0.059177] calling exynos_pmu_init+0x0/0x10 @ 1 [ 0.059247] initcall exynos_pmu_init+0x0/0x10 returned 0 after 0 usecs [ 0.059265] calling bdi_class_init+0x0/0x5c @ 1 [ 0.059317] initcall bdi_class_init+0x0/0x5c returned 0 after 0 usecs [ 0.059333] calling mm_sysfs_init+0x0/0x38 @ 1 [ 0.059349] initcall mm_sysfs_init+0x0/0x38 returned 0 after 0 usecs [ 0.059364] calling kobject_uevent_init+0x0/0xc @ 1 [ 0.059383] initcall kobject_uevent_init+0x0/0xc returned 0 after 0 usecs [ 0.059398] calling samsung_pinctrl_drv_register+0x0/0x24 @ 1 [ 0.059457] initcall samsung_pinctrl_drv_register+0x0/0x24 returned 0 after 0 usecs [ 0.059477] calling exynos5440_pinctrl_drv_register+0x0/0x10 @ 1 [ 0.059533] initcall exynos5440_pinctrl_drv_register+0x0/0x10 returned 0 after 0 usecs [ 0.059553] calling lcd_class_init+0x0/0x58 @ 1 [ 0.059601] initcall lcd_class_init+0x0/0x58 returned 0 after 0 usecs [ 0.059616] calling backlight_class_init+0x0/0xa4 @ 1 [ 0.059661] initcall backlight_class_init+0x0/0xa4 returned 0 after 0 usecs [ 0.059677] calling amba_init+0x0/0xc @ 1 [ 0.059741] initcall amba_init+0x0/0xc returned 0 after 0 usecs [ 0.059757] calling tty_class_init+0x0/0x40 @ 1 [ 0.059800] initcall tty_class_init+0x0/0x40 returned 0 after 0 usecs [ 0.059817] calling vtconsole_class_init+0x0/0xec @ 1 [ 0.059947] initcall vtconsole_class_init+0x0/0xec returned 0 after 0 usecs [ 0.059965] calling mipi_dsi_bus_init+0x0/0xc @ 1 [ 0.060052] initcall mipi_dsi_bus_init+0x0/0xc returned 0 after 4882 usecs [ 0.060070] calling wakeup_sources_debugfs_init+0x0/0x38 @ 1 [ 0.060104] initcall wakeup_sources_debugfs_init+0x0/0x38 returned 0 after 0 usecs [ 0.060123] calling regmap_initcall+0x0/0x10 @ 1 [ 0.060141] initcall regmap_initcall+0x0/0x10 returned 0 after 0 usecs [ 0.060157] calling sram_init+0x0/0x10 @ 1 [ 0.060218] initcall sram_init+0x0/0x10 returned 0 after 0 usecs [ 0.060235] calling syscon_init+0x0/0x10 @ 1 [ 0.060291] initcall syscon_init+0x0/0x10 returned 0 after 0 usecs [ 0.060307] calling spi_init+0x0/0x94 @ 1 [ 0.060403] initcall spi_init+0x0/0x94 returned 0 after 0 usecs [ 0.060418] calling i2c_init+0x0/0xb8 @ 1 [ 0.060538] initcall i2c_init+0x0/0xb8 returned 0 after 0 usecs [ 0.060553] calling init_ladder+0x0/0xc @ 1 [ 0.075090] cpuidle: using governor ladder [ 0.075103] initcall init_ladder+0x0/0xc returned 0 after 14648 usecs [ 0.075116] calling init_menu+0x0/0xc @ 1 [ 0.095118] cpuidle: using governor menu [ 0.095131] initcall init_menu+0x0/0xc returned 0 after 19531 usecs [ 0.095207] calling gate_vma_init+0x0/0x24 @ 1 [ 0.095219] initcall gate_vma_init+0x0/0x24 returned 0 after 0 usecs [ 0.095233] calling customize_machine+0x0/0x40 @ 1 [ 0.097232] bus: 'platform': driver_probe_device: matched device 2020000.sysram with driver sram [ 0.097251] bus: 'platform': really_probe: probing driver sram with device 2020000.sysram [ 0.097318] driver: 'sram': driver_bound: bound to device '2020000.sysram' [ 0.097332] bus: 'platform': really_probe: bound device 2020000.sysram to driver sram [ 0.097885] bus: 'platform': driver_probe_device: matched device 3810000.audss-clock-controller with driver exynos-audss-clk [ 0.097903] bus: 'platform': really_probe: probing driver exynos-audss-clk with device 3810000.audss-clock-controller [ 0.098183] exynos-audss-clk 3810000.audss-clock-controller: setup completed [ 0.098197] driver: 'exynos-audss-clk': driver_bound: bound to device '3810000.audss-clock-controller' [ 0.098213] bus: 'platform': really_probe: bound device 3810000.audss-clock-controller to driver exynos-audss-clk [ 0.098911] bus: 'platform': driver_probe_device: matched device 11400000.pinctrl with driver samsung-pinctrl [ 0.098929] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 11400000.pinctrl [ 0.099063] gpiochip_add: registered GPIOs 0 to 7 on device: gpa0 [ 0.099077] gpiochip_add: registered GPIOs 8 to 13 on device: gpa1 [ 0.099090] gpiochip_add: registered GPIOs 14 to 21 on device: gpa2 [ 0.099102] gpiochip_add: registered GPIOs 22 to 26 on device: gpb0 [ 0.099114] gpiochip_add: registered GPIOs 27 to 31 on device: gpb1 [ 0.099127] gpiochip_add: registered GPIOs 32 to 35 on device: gpb2 [ 0.099138] gpiochip_add: registered GPIOs 36 to 39 on device: gpb3 [ 0.099150] gpiochip_add: registered GPIOs 40 to 46 on device: gpc0 [ 0.099162] gpiochip_add: registered GPIOs 47 to 50 on device: gpc1 [ 0.099177] gpiochip_add: registered GPIOs 51 to 57 on device: gpc2 [ 0.099188] gpiochip_add: registered GPIOs 58 to 64 on device: gpc3 [ 0.099201] gpiochip_add: registered GPIOs 65 to 68 on device: gpd0 [ 0.099213] gpiochip_add: registered GPIOs 69 to 76 on device: gpd1 [ 0.099225] gpiochip_add: registered GPIOs 77 to 83 on device: gpc4 [ 0.099237] gpiochip_add: registered GPIOs 84 to 89 on device: gpy0 [ 0.099249] gpiochip_add: registered GPIOs 90 to 93 on device: gpy1 [ 0.099261] gpiochip_add: registered GPIOs 94 to 99 on device: gpy2 [ 0.099274] gpiochip_add: registered GPIOs 100 to 107 on device: gpy3 [ 0.099286] gpiochip_add: registered GPIOs 108 to 115 on device: gpy4 [ 0.099298] gpiochip_add: registered GPIOs 116 to 123 on device: gpy5 [ 0.099311] gpiochip_add: registered GPIOs 124 to 131 on device: gpy6 [ 0.099323] gpiochip_add: registered GPIOs 132 to 139 on device: gpx0 [ 0.099336] gpiochip_add: registered GPIOs 140 to 147 on device: gpx1 [ 0.099348] gpiochip_add: registered GPIOs 148 to 155 on device: gpx2 [ 0.099360] gpiochip_add: registered GPIOs 156 to 163 on device: gpx3 [ 0.100001] driver: 'samsung-pinctrl': driver_bound: bound to device '11400000.pinctrl' [ 0.100019] bus: 'platform': really_probe: bound device 11400000.pinctrl to driver samsung-pinctrl [ 0.100207] bus: 'platform': driver_probe_device: matched device 13400000.pinctrl with driver samsung-pinctrl [ 0.100225] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 13400000.pinctrl [ 0.100290] gpiochip_add: registered GPIOs 164 to 171 on device: gpe0 [ 0.100304] gpiochip_add: registered GPIOs 172 to 173 on device: gpe1 [ 0.100317] gpiochip_add: registered GPIOs 174 to 177 on device: gpf0 [ 0.100330] gpiochip_add: registered GPIOs 178 to 181 on device: gpf1 [ 0.100342] gpiochip_add: registered GPIOs 182 to 189 on device: gpg0 [ 0.100355] gpiochip_add: registered GPIOs 190 to 197 on device: gpg1 [ 0.100367] gpiochip_add: registered GPIOs 198 to 199 on device: gpg2 [ 0.100379] gpiochip_add: registered GPIOs 200 to 203 on device: gph0 [ 0.100392] gpiochip_add: registered GPIOs 204 to 211 on device: gph1 [ 0.100580] driver: 'samsung-pinctrl': driver_bound: bound to device '13400000.pinctrl' [ 0.100597] bus: 'platform': really_probe: bound device 13400000.pinctrl to driver samsung-pinctrl [ 0.100751] bus: 'platform': driver_probe_device: matched device 10d10000.pinctrl with driver samsung-pinctrl [ 0.100769] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 10d10000.pinctrl [ 0.100825] gpiochip_add: registered GPIOs 212 to 219 on device: gpv0 [ 0.100838] gpiochip_add: registered GPIOs 220 to 227 on device: gpv1 [ 0.100851] gpiochip_add: registered GPIOs 228 to 235 on device: gpv2 [ 0.100863] gpiochip_add: registered GPIOs 236 to 243 on device: gpv3 [ 0.100876] gpiochip_add: registered GPIOs 244 to 245 on device: gpv4 [ 0.101006] driver: 'samsung-pinctrl': driver_bound: bound to device '10d10000.pinctrl' [ 0.101023] bus: 'platform': really_probe: bound device 10d10000.pinctrl to driver samsung-pinctrl [ 0.101175] bus: 'platform': driver_probe_device: matched device 3860000.pinctrl with driver samsung-pinctrl [ 0.101192] bus: 'platform': really_probe: probing driver samsung-pinctrl with device 3860000.pinctrl [ 0.101237] gpiochip_add: registered GPIOs 246 to 252 on device: gpz [ 0.101330] driver: 'samsung-pinctrl': driver_bound: bound to device '3860000.pinctrl' [ 0.101347] bus: 'platform': really_probe: bound device 3860000.pinctrl to driver samsung-pinctrl [ 0.101472] bus: 'platform': driver_probe_device: matched device 10040000.system-controller with driver exynos-pmu [ 0.101490] bus: 'platform': really_probe: probing driver exynos-pmu with device 10040000.system-controller [ 0.101531] driver: 'exynos-pmu': driver_bound: bound to device '10040000.system-controller' [ 0.101547] bus: 'platform': really_probe: bound device 10040000.system-controller to driver exynos-pmu [ 0.109998] initcall customize_machine+0x0/0x40 returned 0 after 9765 usecs [ 0.110020] calling vdso_init+0x0/0x1a4 @ 1 [ 0.110049] initcall vdso_init+0x0/0x1a4 returned 0 after 0 usecs [ 0.110064] calling exceptions_init+0x0/0x9c @ 1 [ 0.110077] initcall exceptions_init+0x0/0x9c returned 0 after 0 usecs [ 0.110093] calling s3c_arch_init+0x0/0x40 @ 1 [ 0.110106] initcall s3c_arch_init+0x0/0x40 returned 0 after 0 usecs [ 0.110121] calling dma_bus_init+0x0/0xa8 @ 1 [ 0.110212] initcall dma_bus_init+0x0/0xa8 returned 0 after 0 usecs [ 0.110230] calling dma_channel_table_init+0x0/0xf0 @ 1 [ 0.110255] initcall dma_channel_table_init+0x0/0xf0 returned 0 after 0 usecs [ 0.110337] calling topology_init+0x0/0x74 @ 1 [ 0.110517] initcall topology_init+0x0/0x74 returned 0 after 0 usecs [ 0.110535] calling uid_cache_init+0x0/0xa4 @ 1 [ 0.110550] initcall uid_cache_init+0x0/0xa4 returned 0 after 0 usecs [ 0.110567] calling param_sysfs_init+0x0/0x1d8 @ 1 [ 0.119328] initcall param_sysfs_init+0x0/0x1d8 returned 0 after 4882 usecs [ 0.119354] calling pm_sysrq_init+0x0/0x1c @ 1 [ 0.130217] initcall pm_sysrq_init+0x0/0x1c returned 0 after 14648 usecs [ 0.130237] calling hung_task_init+0x0/0x58 @ 1 [ 0.130296] initcall hung_task_init+0x0/0x58 returned 0 after 0 usecs [ 0.130312] calling default_bdi_init+0x0/0x58 @ 1 [ 0.130493] initcall default_bdi_init+0x0/0x58 returned 0 after 0 usecs [ 0.130510] calling percpu_enable_async+0x0/0x18 @ 1 [ 0.130522] initcall percpu_enable_async+0x0/0x18 returned 0 after 0 usecs [ 0.130539] calling init_reserve_notifier+0x0/0x8 @ 1 [ 0.130552] initcall init_reserve_notifier+0x0/0x8 returned 0 after 0 usecs [ 0.130573] calling init_admin_reserve+0x0/0x30 @ 1 [ 0.130586] initcall init_admin_reserve+0x0/0x30 returned 0 after 0 usecs [ 0.130602] calling init_user_reserve+0x0/0x30 @ 1 [ 0.130614] initcall init_user_reserve+0x0/0x30 returned 0 after 0 usecs [ 0.130628] calling crypto_wq_init+0x0/0x44 @ 1 [ 0.130696] initcall crypto_wq_init+0x0/0x44 returned 0 after 0 usecs [ 0.130711] calling cryptomgr_init+0x0/0xc @ 1 [ 0.130722] initcall cryptomgr_init+0x0/0xc returned 0 after 0 usecs [ 0.130735] calling init_bio+0x0/0xc0 @ 1 [ 0.130824] initcall init_bio+0x0/0xc0 returned 0 after 0 usecs [ 0.130839] calling blk_settings_init+0x0/0x38 @ 1 [ 0.130850] initcall blk_settings_init+0x0/0x38 returned 0 after 0 usecs [ 0.130863] calling blk_ioc_init+0x0/0x40 @ 1 [ 0.130877] initcall blk_ioc_init+0x0/0x40 returned 0 after 0 usecs [ 0.130890] calling blk_softirq_init+0x0/0x80 @ 1 [ 0.130903] initcall blk_softirq_init+0x0/0x80 returned 0 after 0 usecs [ 0.130917] calling blk_iopoll_setup+0x0/0x80 @ 1 [ 0.130928] initcall blk_iopoll_setup+0x0/0x80 returned 0 after 0 usecs [ 0.130941] calling blk_mq_init+0x0/0x1c @ 1 [ 0.130953] initcall blk_mq_init+0x0/0x1c returned 0 after 0 usecs [ 0.130967] calling genhd_device_init+0x0/0x80 @ 1 [ 0.131085] initcall genhd_device_init+0x0/0x80 returned 0 after 0 usecs [ 0.131102] calling gpiolib_debugfs_init+0x0/0x38 @ 1 [ 0.131123] initcall gpiolib_debugfs_init+0x0/0x38 returned 0 after 0 usecs [ 0.131138] calling pwm_debugfs_init+0x0/0x38 @ 1 [ 0.131153] initcall pwm_debugfs_init+0x0/0x38 returned 0 after 0 usecs [ 0.131168] calling pwm_sysfs_init+0x0/0x14 @ 1 [ 0.131215] initcall pwm_sysfs_init+0x0/0x14 returned 0 after 0 usecs [ 0.131230] calling fbmem_init+0x0/0xb4 @ 1 [ 0.131285] initcall fbmem_init+0x0/0xb4 returned 0 after 0 usecs [ 0.131302] calling regulator_fixed_voltage_init+0x0/0x10 @ 1 [ 0.131427] bus: 'platform': driver_probe_device: matched device vbat-fixed-regulator with driver reg-fixed-voltage [ 0.131445] bus: 'platform': really_probe: probing driver reg-fixed-voltage with device vbat-fixed-regulator [ 0.131498] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/vbat-fixed-regulator[0]' [ 0.131664] driver: 'reg-fixed-voltage': driver_bound: bound to device 'vbat-fixed-regulator' [ 0.131682] bus: 'platform': really_probe: bound device vbat-fixed-regulator to driver reg-fixed-voltage [ 0.131704] bus: 'platform': driver_probe_device: matched device regulator-usb3 with driver reg-fixed-voltage [ 0.131722] bus: 'platform': really_probe: probing driver reg-fixed-voltage with device regulator-usb3 [ 0.131832] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulator-usb3[0]' - status (0) [ 0.132003] driver: 'reg-fixed-voltage': driver_bound: bound to device 'regulator-usb3' [ 0.132021] bus: 'platform': really_probe: bound device regulator-usb3 to driver reg-fixed-voltage [ 0.132089] initcall regulator_fixed_voltage_init+0x0/0x10 returned 0 after 0 usecs [ 0.132109] calling gpio_regulator_init+0x0/0x10 @ 1 [ 0.132241] initcall gpio_regulator_init+0x0/0x10 returned 0 after 0 usecs [ 0.132258] calling max14577_regulator_init+0x0/0x10 @ 1 [ 0.132344] initcall max14577_regulator_init+0x0/0x10 returned 0 after 0 usecs [ 0.132364] calling max8997_pmic_init+0x0/0x10 @ 1 [ 0.132445] initcall max8997_pmic_init+0x0/0x10 returned 0 after 0 usecs [ 0.132461] calling max77686_pmic_init+0x0/0x10 @ 1 [ 0.132548] initcall max77686_pmic_init+0x0/0x10 returned 0 after 0 usecs [ 0.132564] calling max77693_pmic_init+0x0/0x10 @ 1 [ 0.132650] initcall max77693_pmic_init+0x0/0x10 returned 0 after 0 usecs [ 0.132666] calling s2mps11_pmic_init+0x0/0x10 @ 1 [ 0.132751] initcall s2mps11_pmic_init+0x0/0x10 returned 0 after 0 usecs [ 0.132767] calling s5m8767_pmic_init+0x0/0x10 @ 1 [ 0.132850] initcall s5m8767_pmic_init+0x0/0x10 returned 0 after 0 usecs [ 0.132866] calling tps65090_regulator_init+0x0/0x10 @ 1 [ 0.132952] initcall tps65090_regulator_init+0x0/0x10 returned 0 after 0 usecs [ 0.132972] calling misc_init+0x0/0xe0 @ 1 [ 0.133025] initcall misc_init+0x0/0xe0 returned 0 after 0 usecs [ 0.133040] calling tpm_init+0x0/0x8c @ 1 [ 0.133086] initcall tpm_init+0x0/0x8c returned 0 after 0 usecs [ 0.133104] calling max14577_i2c_init+0x0/0x10 @ 1 [ 0.133160] initcall max14577_i2c_init+0x0/0x10 returned 0 after 0 usecs [ 0.133177] calling max77686_i2c_init+0x0/0x10 @ 1 [ 0.133232] initcall max77686_i2c_init+0x0/0x10 returned 0 after 0 usecs [ 0.133249] calling max77693_i2c_init+0x0/0x10 @ 1 [ 0.133303] initcall max77693_i2c_init+0x0/0x10 returned 0 after 0 usecs [ 0.133320] calling max8997_i2c_init+0x0/0x10 @ 1 [ 0.133375] initcall max8997_i2c_init+0x0/0x10 returned 0 after 0 usecs [ 0.133392] calling tps65090_init+0x0/0x10 @ 1 [ 0.133447] initcall tps65090_init+0x0/0x10 returned 0 after 0 usecs [ 0.133463] calling sec_pmic_init+0x0/0x10 @ 1 [ 0.133518] initcall sec_pmic_init+0x0/0x10 returned 0 after 0 usecs [ 0.133534] calling dma_buf_init+0x0/0x84 @ 1 [ 0.133555] initcall dma_buf_init+0x0/0x84 returned 0 after 0 usecs [ 0.133571] calling init_scsi+0x0/0x8c @ 1 [ 0.133795] SCSI subsystem initialized [ 0.133810] initcall init_scsi+0x0/0x8c returned 0 after 0 usecs [ 0.133826] calling phy_init+0x0/0x3c @ 1 [ 0.134005] initcall phy_init+0x0/0x3c returned 0 after 0 usecs [ 0.134022] calling usb_init+0x0/0x17c @ 1 [ 0.134159] usbcore: registered new interface driver usbfs [ 0.134230] usbcore: registered new interface driver hub [ 0.134308] usbcore: registered new device driver usb [ 0.134322] initcall usb_init+0x0/0x17c returned 0 after 0 usecs [ 0.134339] calling usb_udc_init+0x0/0x58 @ 1 [ 0.134384] initcall usb_udc_init+0x0/0x58 returned 0 after 0 usecs [ 0.134398] calling serio_init+0x0/0x30 @ 1 [ 0.134459] initcall serio_init+0x0/0x30 returned 0 after 0 usecs [ 0.134473] calling input_init+0x0/0x11c @ 1 [ 0.134525] initcall input_init+0x0/0x11c returned 0 after 0 usecs [ 0.134539] calling rtc_init+0x0/0x58 @ 1 [ 0.134584] initcall rtc_init+0x0/0x58 returned 0 after 0 usecs [ 0.134598] calling i2c_gpio_init+0x0/0x34 @ 1 [ 0.134740] initcall i2c_gpio_init+0x0/0x34 returned 0 after 0 usecs [ 0.134754] calling i2c_adap_s3c_init+0x0/0x10 @ 1 [ 0.134821] bus: 'platform': driver_probe_device: matched device 12c60000.i2c with driver s3c-i2c [ 0.134838] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c60000.i2c [ 0.134973] s3c-i2c 12c60000.i2c: slave address 0x00 [ 0.134988] s3c-i2c 12c60000.i2c: bus frequency set to 378 KHz [ 0.135315] bus: 'i2c': driver_probe_device: matched device 0-0009 with driver max77686 [ 0.135335] bus: 'i2c': really_probe: probing driver max77686 with device 0-0009 [ 0.135750] bus: 'i2c': driver_probe_device: matched device 0-0006 with driver dummy [ 0.135769] bus: 'i2c': really_probe: probing driver dummy with device 0-0006 [ 0.135796] driver: 'dummy': driver_bound: bound to device '0-0006' [ 0.135808] bus: 'i2c': really_probe: bound device 0-0006 to driver dummy [ 0.136613] bus: 'platform': driver_probe_device: matched device max77686-pmic with driver max77686-pmic [ 0.136631] bus: 'platform': really_probe: probing driver max77686-pmic with device max77686-pmic [ 0.155437] of_get_named_gpiod_flags: can't parse 'maxim,ena-gpios' property of node '/i2c@12C60000/max77686@09/voltage-regulators/BUCK8[0]' [ 0.156487] driver: 'max77686-pmic': driver_bound: bound to device 'max77686-pmic' [ 0.156505] bus: 'platform': really_probe: bound device max77686-pmic to driver max77686-pmic [ 0.156702] driver: 'max77686': driver_bound: bound to device '0-0009' [ 0.156715] bus: 'i2c': really_probe: bound device 0-0009 to driver max77686 [ 0.156737] s3c-i2c 12c60000.i2c: i2c-0: S3C I2C adapter [ 0.156748] driver: 's3c-i2c': driver_bound: bound to device '12c60000.i2c' [ 0.156760] bus: 'platform': really_probe: bound device 12c60000.i2c to driver s3c-i2c [ 0.156781] bus: 'platform': driver_probe_device: matched device 12c70000.i2c with driver s3c-i2c [ 0.156797] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c70000.i2c [ 0.156922] s3c-i2c 12c70000.i2c: slave address 0x00 [ 0.156937] s3c-i2c 12c70000.i2c: bus frequency set to 378 KHz [ 0.157205] s3c-i2c 12c70000.i2c: i2c-1: S3C I2C adapter [ 0.157218] driver: 's3c-i2c': driver_bound: bound to device '12c70000.i2c' [ 0.157231] bus: 'platform': really_probe: bound device 12c70000.i2c to driver s3c-i2c [ 0.157251] bus: 'platform': driver_probe_device: matched device 12c80000.i2c with driver s3c-i2c [ 0.157267] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c80000.i2c [ 0.157352] s3c-i2c 12c80000.i2c: slave address 0x00 [ 0.157366] s3c-i2c 12c80000.i2c: bus frequency set to 65 KHz [ 0.157617] s3c-i2c 12c80000.i2c: i2c-2: S3C I2C adapter [ 0.157629] driver: 's3c-i2c': driver_bound: bound to device '12c80000.i2c' [ 0.157641] bus: 'platform': really_probe: bound device 12c80000.i2c to driver s3c-i2c [ 0.157660] bus: 'platform': driver_probe_device: matched device 12c90000.i2c with driver s3c-i2c [ 0.157676] bus: 'platform': really_probe: probing driver s3c-i2c with device 12c90000.i2c [ 0.157763] s3c-i2c 12c90000.i2c: slave address 0x00 [ 0.157776] s3c-i2c 12c90000.i2c: bus frequency set to 65 KHz [ 0.157929] s3c-i2c 12c90000.i2c: i2c-3: S3C I2C adapter [ 0.157941] driver: 's3c-i2c': driver_bound: bound to device '12c90000.i2c' [ 0.157953] bus: 'platform': really_probe: bound device 12c90000.i2c to driver s3c-i2c [ 0.157972] bus: 'platform': driver_probe_device: matched device 12ca0000.i2c with driver s3c-i2c [ 0.157988] bus: 'platform': really_probe: probing driver s3c-i2c with device 12ca0000.i2c [ 0.158063] s3c-i2c 12ca0000.i2c: slave address 0x00 [ 0.158077] s3c-i2c 12ca0000.i2c: bus frequency set to 65 KHz [ 0.158230] s3c-i2c 12ca0000.i2c: i2c-4: S3C I2C adapter [ 0.158241] driver: 's3c-i2c': driver_bound: bound to device '12ca0000.i2c' [ 0.158253] bus: 'platform': really_probe: bound device 12ca0000.i2c to driver s3c-i2c [ 0.158272] bus: 'platform': driver_probe_device: matched device 12cb0000.i2c with driver s3c-i2c [ 0.158289] bus: 'platform': really_probe: probing driver s3c-i2c with device 12cb0000.i2c [ 0.158365] s3c-i2c 12cb0000.i2c: slave address 0x00 [ 0.158379] s3c-i2c 12cb0000.i2c: bus frequency set to 65 KHz [ 0.158538] s3c-i2c 12cb0000.i2c: i2c-5: S3C I2C adapter [ 0.158550] driver: 's3c-i2c': driver_bound: bound to device '12cb0000.i2c' [ 0.158562] bus: 'platform': really_probe: bound device 12cb0000.i2c to driver s3c-i2c [ 0.158581] bus: 'platform': driver_probe_device: matched device 12cd0000.i2c with driver s3c-i2c [ 0.158598] bus: 'platform': really_probe: probing driver s3c-i2c with device 12cd0000.i2c [ 0.158676] s3c-i2c 12cd0000.i2c: slave address 0x00 [ 0.158690] s3c-i2c 12cd0000.i2c: bus frequency set to 65 KHz [ 0.159023] s3c-i2c 12cd0000.i2c: i2c-7: S3C I2C adapter [ 0.159035] driver: 's3c-i2c': driver_bound: bound to device '12cd0000.i2c' [ 0.159046] bus: 'platform': really_probe: bound device 12cd0000.i2c to driver s3c-i2c [ 0.159066] bus: 'platform': driver_probe_device: matched device 12ce0000.i2c with driver s3c-i2c [ 0.159082] bus: 'platform': really_probe: probing driver s3c-i2c with device 12ce0000.i2c [ 0.159140] s3c-i2c 12ce0000.i2c: slave address 0x00 [ 0.159153] s3c-i2c 12ce0000.i2c: bus frequency set to 378 KHz [ 0.159404] s3c-i2c 12ce0000.i2c: i2c-8: S3C I2C adapter [ 0.159416] driver: 's3c-i2c': driver_bound: bound to device '12ce0000.i2c' [ 0.159428] bus: 'platform': really_probe: bound device 12ce0000.i2c to driver s3c-i2c [ 0.159600] initcall i2c_adap_s3c_init+0x0/0x10 returned 0 after 24414 usecs [ 0.159617] calling power_supply_class_init+0x0/0x50 @ 1 [ 0.159665] initcall power_supply_class_init+0x0/0x50 returned 0 after 0 usecs [ 0.159684] calling hwmon_init+0x0/0x34 @ 1 [ 0.159728] initcall hwmon_init+0x0/0x34 returned 0 after 0 usecs [ 0.159743] calling mmc_init+0x0/0x88 @ 1 [ 0.159906] initcall mmc_init+0x0/0x88 returned 0 after 0 usecs [ 0.159921] calling leds_init+0x0/0x4c @ 1 [ 0.159966] initcall leds_init+0x0/0x4c returned 0 after 0 usecs [ 0.159983] calling s2mps11_clk_init+0x0/0x10 @ 1 [ 0.160082] initcall s2mps11_clk_init+0x0/0x10 returned 0 after 0 usecs [ 0.160099] calling exynos3250_cmu_platform_init+0x0/0x18 @ 1 [ 0.160321] initcall exynos3250_cmu_platform_init+0x0/0x18 returned -19 after 4882 usecs [ 0.160345] calling iio_init+0x0/0x94 @ 1 [ 0.160421] initcall iio_init+0x0/0x94 returned 0 after 0 usecs [ 0.160437] calling init_soundcore+0x0/0x40 @ 1 [ 0.160483] initcall init_soundcore+0x0/0x40 returned 0 after 0 usecs [ 0.160500] calling alsa_sound_init+0x0/0xb0 @ 1 [ 0.160527] Advanced Linux Sound Architecture Driver Initialized. [ 0.160540] initcall alsa_sound_init+0x0/0xb0 returned 0 after 0 usecs [ 0.160556] calling proto_init+0x0/0xc @ 1 [ 0.160573] initcall proto_init+0x0/0xc returned 0 after 0 usecs [ 0.160589] calling net_dev_init+0x0/0x1e8 @ 1 [ 0.161022] initcall net_dev_init+0x0/0x1e8 returned 0 after 0 usecs [ 0.161040] calling neigh_init+0x0/0xa4 @ 1 [ 0.161052] initcall neigh_init+0x0/0xa4 returned 0 after 0 usecs [ 0.161066] calling genl_init+0x0/0x80 @ 1 [ 0.161089] initcall genl_init+0x0/0x80 returned 0 after 0 usecs [ 0.161104] calling cfg80211_init+0x0/0xe4 @ 1 [ 0.161431] initcall cfg80211_init+0x0/0xe4 returned 0 after 0 usecs [ 0.161448] calling watchdog_init+0x0/0xc0 @ 1 [ 0.161497] initcall watchdog_init+0x0/0xc0 returned 0 after 0 usecs [ 0.161583] calling proc_cpu_init+0x0/0x24 @ 1 [ 0.161598] initcall proc_cpu_init+0x0/0x24 returned 0 after 0 usecs [ 0.161614] calling dma_debug_do_init+0x0/0x8 @ 1 [ 0.161625] initcall dma_debug_do_init+0x0/0x8 returned 0 after 0 usecs [ 0.161641] calling alignment_init+0x0/0xe8 @ 1 [ 0.161657] initcall alignment_init+0x0/0xe8 returned 0 after 0 usecs [ 0.161671] calling clocksource_done_booting+0x0/0x44 @ 1 [ 0.161708] clocksource: Switched to clocksource arch_sys_counter [ 0.161721] initcall clocksource_done_booting+0x0/0x44 returned 0 after 19 usecs [ 0.161742] calling init_pipe_fs+0x0/0x58 @ 1 [ 0.161776] initcall init_pipe_fs+0x0/0x58 returned 0 after 21 usecs [ 0.161792] calling inotify_user_setup+0x0/0x54 @ 1 [ 0.161808] initcall inotify_user_setup+0x0/0x54 returned 0 after 3 usecs [ 0.161823] calling eventpoll_init+0x0/0xfc @ 1 [ 0.161841] initcall eventpoll_init+0x0/0xfc returned 0 after 6 usecs [ 0.161857] calling anon_inode_init+0x0/0x6c @ 1 [ 0.161893] initcall anon_inode_init+0x0/0x6c returned 0 after 22 usecs [ 0.161910] calling proc_cmdline_init+0x0/0x38 @ 1 [ 0.161926] initcall proc_cmdline_init+0x0/0x38 returned 0 after 3 usecs [ 0.161942] calling proc_consoles_init+0x0/0x38 @ 1 [ 0.161957] initcall proc_consoles_init+0x0/0x38 returned 0 after 2 usecs [ 0.161973] calling proc_cpuinfo_init+0x0/0x38 @ 1 [ 0.161989] initcall proc_cpuinfo_init+0x0/0x38 returned 0 after 3 usecs [ 0.162005] calling proc_devices_init+0x0/0x38 @ 1 [ 0.162020] initcall proc_devices_init+0x0/0x38 returned 0 after 2 usecs [ 0.162036] calling proc_interrupts_init+0x0/0x38 @ 1 [ 0.162051] initcall proc_interrupts_init+0x0/0x38 returned 0 after 2 usecs [ 0.162067] calling proc_loadavg_init+0x0/0x38 @ 1 [ 0.162081] initcall proc_loadavg_init+0x0/0x38 returned 0 after 2 usecs [ 0.162097] calling proc_meminfo_init+0x0/0x38 @ 1 [ 0.162112] initcall proc_meminfo_init+0x0/0x38 returned 0 after 2 usecs [ 0.162128] calling proc_stat_init+0x0/0x38 @ 1 [ 0.162142] initcall proc_stat_init+0x0/0x38 returned 0 after 2 usecs [ 0.162158] calling proc_uptime_init+0x0/0x38 @ 1 [ 0.162173] initcall proc_uptime_init+0x0/0x38 returned 0 after 2 usecs [ 0.162189] calling proc_version_init+0x0/0x38 @ 1 [ 0.162204] initcall proc_version_init+0x0/0x38 returned 0 after 2 usecs [ 0.162220] calling proc_softirqs_init+0x0/0x38 @ 1 [ 0.162234] initcall proc_softirqs_init+0x0/0x38 returned 0 after 2 usecs [ 0.162250] calling proc_kmsg_init+0x0/0x38 @ 1 [ 0.162265] initcall proc_kmsg_init+0x0/0x38 returned 0 after 2 usecs [ 0.162280] calling proc_page_init+0x0/0x58 @ 1 [ 0.162297] initcall proc_page_init+0x0/0x58 returned 0 after 4 usecs [ 0.162313] calling init_ramfs_fs+0x0/0x34 @ 1 [ 0.162325] initcall init_ramfs_fs+0x0/0x34 returned 0 after 0 usecs [ 0.162339] calling blk_scsi_ioctl_init+0x0/0xdc @ 1 [ 0.162351] initcall blk_scsi_ioctl_init+0x0/0xdc returned 0 after 0 usecs [ 0.162365] calling fb_console_init+0x0/0x140 @ 1 [ 0.162476] initcall fb_console_init+0x0/0x140 returned 0 after 95 usecs [ 0.162493] calling chr_dev_init+0x0/0xc8 @ 1 [ 0.170806] initcall chr_dev_init+0x0/0xc8 returned 0 after 8100 usecs [ 0.170829] calling firmware_class_init+0x0/0xc8 @ 1 [ 0.170844] initcall firmware_class_init+0x0/0xc8 returned 0 after 2 usecs [ 0.170858] calling thermal_init+0x0/0xb4 @ 1 [ 0.171140] initcall thermal_init+0x0/0xb4 returned 0 after 262 usecs [ 0.171157] calling cpufreq_gov_performance_init+0x0/0xc @ 1 [ 0.171171] initcall cpufreq_gov_performance_init+0x0/0xc returned 0 after 1 usecs [ 0.171189] calling cpufreq_gov_dbs_init+0x0/0xc @ 1 [ 0.171202] initcall cpufreq_gov_dbs_init+0x0/0xc returned 0 after 0 usecs [ 0.171220] calling sysctl_core_init+0x0/0x30 @ 1 [ 0.171251] initcall sysctl_core_init+0x0/0x30 returned 0 after 17 usecs [ 0.171265] calling eth_offload_init+0x0/0x18 @ 1 [ 0.171276] initcall eth_offload_init+0x0/0x18 returned 0 after 0 usecs [ 0.171290] calling inet_init+0x0/0x250 @ 1 [ 0.171333] NET: Registered protocol family 2 [ 0.171618] TCP established hash table entries: 8192 (order: 3, 32768 bytes) [ 0.171673] TCP bind hash table entries: 8192 (order: 5, 163840 bytes) [ 0.171813] TCP: Hash tables configured (established 8192 bind 8192) [ 0.171862] UDP hash table entries: 512 (order: 2, 24576 bytes) [ 0.171891] UDP-Lite hash table entries: 512 (order: 2, 24576 bytes) [ 0.171998] initcall inet_init+0x0/0x250 returned 0 after 677 usecs [ 0.172015] calling ipv4_offload_init+0x0/0x68 @ 1 [ 0.172027] initcall ipv4_offload_init+0x0/0x68 returned 0 after 0 usecs [ 0.172041] calling af_unix_init+0x0/0x54 @ 1 [ 0.172054] NET: Registered protocol family 1 [ 0.172075] initcall af_unix_init+0x0/0x54 returned 0 after 21 usecs [ 0.172089] calling ipv6_offload_init+0x0/0x88 @ 1 [ 0.172103] initcall ipv6_offload_init+0x0/0x88 returned 0 after 1 usecs [ 0.172117] calling init_sunrpc+0x0/0x6c @ 1 [ 0.172265] RPC: Registered named UNIX socket transport module. [ 0.172278] RPC: Registered udp transport module. [ 0.172287] RPC: Registered tcp transport module. [ 0.172297] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.172310] initcall init_sunrpc+0x0/0x6c returned 0 after 175 usecs [ 0.172325] calling populate_rootfs+0x0/0x25c @ 1 [ 0.172448] initcall populate_rootfs+0x0/0x25c returned 0 after 106 usecs [ 0.172540] calling bL_switcher_dummy_if_init+0x0/0xc @ 1 [ 0.172686] initcall bL_switcher_dummy_if_init+0x0/0xc returned 0 after 128 usecs [ 0.172709] calling proc_execdomains_init+0x0/0x38 @ 1 [ 0.172727] initcall proc_execdomains_init+0x0/0x38 returned 0 after 4 usecs [ 0.172744] calling ioresources_init+0x0/0x58 @ 1 [ 0.172762] initcall ioresources_init+0x0/0x58 returned 0 after 5 usecs [ 0.172780] calling init_sched_debug_procfs+0x0/0x3c @ 1 [ 0.172796] initcall init_sched_debug_procfs+0x0/0x3c returned 0 after 3 usecs [ 0.172813] calling irq_gc_init_ops+0x0/0x18 @ 1 [ 0.172825] initcall irq_gc_init_ops+0x0/0x18 returned 0 after 1 usecs [ 0.172838] calling irq_pm_init_ops+0x0/0x18 @ 1 [ 0.172849] initcall irq_pm_init_ops+0x0/0x18 returned 0 after 0 usecs [ 0.172862] calling init_posix_timers+0x0/0x210 @ 1 [ 0.172882] initcall init_posix_timers+0x0/0x210 returned 0 after 8 usecs [ 0.172895] calling init_posix_cpu_timers+0x0/0xdc @ 1 [ 0.172907] initcall init_posix_cpu_timers+0x0/0xdc returned 0 after 0 usecs [ 0.172921] calling timekeeping_init_ops+0x0/0x18 @ 1 [ 0.172933] initcall timekeeping_init_ops+0x0/0x18 returned 0 after 0 usecs [ 0.172946] calling init_clocksource_sysfs+0x0/0x74 @ 1 [ 0.173133] initcall init_clocksource_sysfs+0x0/0x74 returned 0 after 169 usecs [ 0.173152] calling init_timer_list_procfs+0x0/0x3c @ 1 [ 0.173168] initcall init_timer_list_procfs+0x0/0x3c returned 0 after 3 usecs [ 0.173182] calling alarmtimer_init+0x0/0x1a8 @ 1 [ 0.173394] bus: 'platform': driver_probe_device: matched device alarmtimer with driver alarmtimer [ 0.173412] bus: 'platform': really_probe: probing driver alarmtimer with device alarmtimer [ 0.173453] alarmtimer: probe of alarmtimer rejects match -19 [ 0.173471] initcall alarmtimer_init+0x0/0x1a8 returned 0 after 271 usecs [ 0.173486] calling clockevents_init_sysfs+0x0/0xdc @ 1 [ 0.173809] initcall clockevents_init_sysfs+0x0/0xdc returned 0 after 301 usecs [ 0.173828] calling sched_clock_syscore_init+0x0/0x18 @ 1 [ 0.173840] initcall sched_clock_syscore_init+0x0/0x18 returned 0 after 0 usecs [ 0.173857] calling futex_init+0x0/0x108 @ 1 [ 0.173870] futex hash table entries: 512 (order: 3, 32768 bytes) [ 0.173899] initcall futex_init+0x0/0x108 returned 0 after 29 usecs [ 0.173913] calling proc_modules_init+0x0/0x38 @ 1 [ 0.173929] initcall proc_modules_init+0x0/0x38 returned 0 after 4 usecs [ 0.173943] calling kallsyms_init+0x0/0x38 @ 1 [ 0.173957] initcall kallsyms_init+0x0/0x38 returned 0 after 3 usecs [ 0.173971] calling pid_namespaces_init+0x0/0x40 @ 1 [ 0.173987] initcall pid_namespaces_init+0x0/0x40 returned 0 after 4 usecs [ 0.174002] calling utsname_sysctl_init+0x0/0x18 @ 1 [ 0.174026] initcall utsname_sysctl_init+0x0/0x18 returned 0 after 12 usecs [ 0.174041] calling init_per_zone_wmark_min+0x0/0xbc @ 1 [ 0.174059] initcall init_per_zone_wmark_min+0x0/0xbc returned 0 after 5 usecs [ 0.174077] calling kswapd_init+0x0/0x24 @ 1 [ 0.174134] initcall kswapd_init+0x0/0x24 returned 0 after 43 usecs [ 0.174150] calling extfrag_debug_init+0x0/0x94 @ 1 [ 0.174181] initcall extfrag_debug_init+0x0/0x94 returned 0 after 17 usecs [ 0.174196] calling setup_vmstat+0x0/0x1b4 @ 1 [ 0.174219] initcall setup_vmstat+0x0/0x1b4 returned 0 after 12 usecs [ 0.174234] calling mm_compute_batch_init+0x0/0x5c @ 1 [ 0.174246] initcall mm_compute_batch_init+0x0/0x5c returned 0 after 0 usecs [ 0.174261] calling slab_proc_init+0x0/0x38 @ 1 [ 0.174275] initcall slab_proc_init+0x0/0x38 returned 0 after 2 usecs [ 0.174290] calling workingset_init+0x0/0x50 @ 1 [ 0.174302] initcall workingset_init+0x0/0x50 returned 0 after 1 usecs [ 0.174317] calling proc_vmalloc_init+0x0/0x38 @ 1 [ 0.174332] initcall proc_vmalloc_init+0x0/0x38 returned 0 after 3 usecs [ 0.174348] calling memblock_init_debugfs+0x0/0x78 @ 1 [ 0.174372] initcall memblock_init_debugfs+0x0/0x78 returned 0 after 11 usecs [ 0.174387] calling procswaps_init+0x0/0x38 @ 1 [ 0.174402] initcall procswaps_init+0x0/0x38 returned 0 after 2 usecs [ 0.174418] calling slab_sysfs_init+0x0/0x11c @ 1 [ 0.180816] initcall slab_sysfs_init+0x0/0x11c returned 0 after 6232 usecs [ 0.180838] calling fcntl_init+0x0/0x40 @ 1 [ 0.180858] initcall fcntl_init+0x0/0x40 returned 0 after 7 usecs [ 0.180874] calling proc_filesystems_init+0x0/0x38 @ 1 [ 0.180892] initcall proc_filesystems_init+0x0/0x38 returned 0 after 5 usecs [ 0.180909] calling start_dirtytime_writeback+0x0/0x34 @ 1 [ 0.180923] initcall start_dirtytime_writeback+0x0/0x34 returned 0 after 1 usecs [ 0.180942] calling dio_init+0x0/0x40 @ 1 [ 0.180961] initcall dio_init+0x0/0x40 returned 0 after 6 usecs [ 0.180977] calling fsnotify_mark_init+0x0/0x40 @ 1 [ 0.181031] initcall fsnotify_mark_init+0x0/0x40 returned 0 after 39 usecs [ 0.181049] calling dnotify_init+0x0/0x84 @ 1 [ 0.181074] initcall dnotify_init+0x0/0x84 returned 0 after 12 usecs [ 0.181089] calling aio_setup+0x0/0x88 @ 1 [ 0.181137] initcall aio_setup+0x0/0x88 returned 0 after 34 usecs [ 0.181154] calling proc_locks_init+0x0/0x38 @ 1 [ 0.181170] initcall proc_locks_init+0x0/0x38 returned 0 after 3 usecs [ 0.181186] calling init_mbcache+0x0/0x18 @ 1 [ 0.181198] initcall init_mbcache+0x0/0x18 returned 0 after 0 usecs [ 0.181213] calling init_grace+0x0/0xc @ 1 [ 0.181227] initcall init_grace+0x0/0xc returned 0 after 2 usecs [ 0.181242] calling init_devpts_fs+0x0/0x70 @ 1 [ 0.181281] initcall init_devpts_fs+0x0/0x70 returned 0 after 25 usecs [ 0.181298] calling init_ext2_fs+0x0/0x78 @ 1 [ 0.181444] initcall init_ext2_fs+0x0/0x78 returned 0 after 128 usecs [ 0.181462] calling ext4_init_fs+0x0/0x1ac @ 1 [ 0.182207] initcall ext4_init_fs+0x0/0x1ac returned 0 after 714 usecs [ 0.182226] calling journal_init+0x0/0x118 @ 1 [ 0.182652] initcall journal_init+0x0/0x118 returned 0 after 401 usecs [ 0.182670] calling init_cramfs_fs+0x0/0x38 @ 1 [ 0.182700] initcall init_cramfs_fs+0x0/0x38 returned 0 after 16 usecs [ 0.182717] calling init_fat_fs+0x0/0x64 @ 1 [ 0.182984] initcall init_fat_fs+0x0/0x64 returned 0 after 247 usecs [ 0.183003] calling init_vfat_fs+0x0/0xc @ 1 [ 0.183017] initcall init_vfat_fs+0x0/0xc returned 0 after 1 usecs [ 0.183033] calling init_msdos_fs+0x0/0xc @ 1 [ 0.183046] initcall init_msdos_fs+0x0/0xc returned 0 after 1 usecs [ 0.183062] calling init_nfs_fs+0x0/0x160 @ 1 [ 0.183598] initcall init_nfs_fs+0x0/0x160 returned 0 after 509 usecs [ 0.183613] calling init_nfs_v2+0x0/0x18 @ 1 [ 0.183625] initcall init_nfs_v2+0x0/0x18 returned 0 after 0 usecs [ 0.183638] calling init_nfs_v3+0x0/0x18 @ 1 [ 0.183649] initcall init_nfs_v3+0x0/0x18 returned 0 after 0 usecs [ 0.183662] calling init_nlm+0x0/0x70 @ 1 [ 0.183686] initcall init_nlm+0x0/0x70 returned 0 after 12 usecs [ 0.183699] calling init_nls_cp437+0x0/0x10 @ 1 [ 0.183711] initcall init_nls_cp437+0x0/0x10 returned 0 after 0 usecs [ 0.183724] calling init_nls_ascii+0x0/0x10 @ 1 [ 0.183735] initcall init_nls_ascii+0x0/0x10 returned 0 after 0 usecs [ 0.183748] calling init_nls_iso8859_1+0x0/0x10 @ 1 [ 0.183759] initcall init_nls_iso8859_1+0x0/0x10 returned 0 after 0 usecs [ 0.183772] calling init_romfs_fs+0x0/0x98 @ 1 [ 0.183781] romfs: ROMFS MTD (C) 2007 Red Hat, Inc. [ 0.183926] initcall init_romfs_fs+0x0/0x98 returned 0 after 138 usecs [ 0.183941] calling ipc_init+0x0/0x18 @ 1 [ 0.183961] initcall ipc_init+0x0/0x18 returned 0 after 9 usecs [ 0.183974] calling ipc_sysctl_init+0x0/0x18 @ 1 [ 0.183996] initcall ipc_sysctl_init+0x0/0x18 returned 0 after 10 usecs [ 0.184010] calling crypto_algapi_init+0x0/0x10 @ 1 [ 0.184024] initcall crypto_algapi_init+0x0/0x10 returned 0 after 3 usecs [ 0.184038] calling chainiv_module_init+0x0/0xc @ 1 [ 0.184051] initcall chainiv_module_init+0x0/0xc returned 0 after 2 usecs [ 0.184065] calling eseqiv_module_init+0x0/0xc @ 1 [ 0.184076] initcall eseqiv_module_init+0x0/0xc returned 0 after 0 usecs [ 0.184089] calling crypto_null_mod_init+0x0/0x4c @ 1 [ 0.184291] initcall crypto_null_mod_init+0x0/0x4c returned 0 after 184 usecs [ 0.184307] calling sha256_generic_mod_init+0x0/0x10 @ 1 [ 0.184402] initcall sha256_generic_mod_init+0x0/0x10 returned 0 after 79 usecs [ 0.184421] calling crypto_cbc_module_init+0x0/0xc @ 1 [ 0.184433] initcall crypto_cbc_module_init+0x0/0xc returned 0 after 0 usecs [ 0.184446] calling aes_init+0x0/0xc @ 1 [ 0.184503] initcall aes_init+0x0/0xc returned 0 after 43 usecs [ 0.184517] calling crc32c_mod_init+0x0/0xc @ 1 [ 0.184574] initcall crc32c_mod_init+0x0/0xc returned 0 after 43 usecs [ 0.184588] calling proc_genhd_init+0x0/0x58 @ 1 [ 0.184606] initcall proc_genhd_init+0x0/0x58 returned 0 after 6 usecs [ 0.184621] calling init_emergency_pool+0x0/0x78 @ 1 [ 0.184654] bounce: pool size: 64 pages [ 0.184665] initcall init_emergency_pool+0x0/0x78 returned 0 after 32 usecs [ 0.184679] calling noop_init+0x0/0xc @ 1 [ 0.184690] io scheduler noop registered [ 0.184701] initcall noop_init+0x0/0xc returned 0 after 10 usecs [ 0.184714] calling deadline_init+0x0/0xc @ 1 [ 0.184724] io scheduler deadline registered [ 0.184735] initcall deadline_init+0x0/0xc returned 0 after 9 usecs [ 0.184748] calling cfq_init+0x0/0xa4 @ 1 [ 0.184908] io scheduler cfq registered (default) [ 0.184922] initcall cfq_init+0x0/0xa4 returned 0 after 157 usecs [ 0.184936] calling percpu_counter_startup+0x0/0x1c @ 1 [ 0.184950] initcall percpu_counter_startup+0x0/0x1c returned 0 after 2 usecs [ 0.184965] calling phy_core_init+0x0/0x58 @ 1 [ 0.185013] initcall phy_core_init+0x0/0x58 returned 0 after 35 usecs [ 0.185030] calling exynos_dp_video_phy_driver_init+0x0/0x10 @ 1 [ 0.185148] bus: 'platform': driver_probe_device: matched device video-phy@10040720 with driver exynos-dp-video-phy [ 0.185167] bus: 'platform': really_probe: probing driver exynos-dp-video-phy with device video-phy@10040720 [ 0.185389] driver: 'exynos-dp-video-phy': driver_bound: bound to device 'video-phy@10040720' [ 0.185409] bus: 'platform': really_probe: bound device video-phy@10040720 to driver exynos-dp-video-phy [ 0.185524] initcall exynos_dp_video_phy_driver_init+0x0/0x10 returned 0 after 468 usecs [ 0.185546] calling exynos_mipi_video_phy_driver_init+0x0/0x10 @ 1 [ 0.185682] initcall exynos_mipi_video_phy_driver_init+0x0/0x10 returned 0 after 119 usecs [ 0.185702] calling exynos_sata_phy_driver_init+0x0/0x10 @ 1 [ 0.185835] initcall exynos_sata_phy_driver_init+0x0/0x10 returned 0 after 115 usecs [ 0.185856] calling samsung_usb2_phy_driver_init+0x0/0x10 @ 1 [ 0.185943] bus: 'platform': driver_probe_device: matched device 12130000.phy with driver samsung-usb2-phy [ 0.185961] bus: 'platform': really_probe: probing driver samsung-usb2-phy with device 12130000.phy [ 0.186427] driver: 'samsung-usb2-phy': driver_bound: bound to device '12130000.phy' [ 0.186444] bus: 'platform': really_probe: bound device 12130000.phy to driver samsung-usb2-phy [ 0.186562] initcall samsung_usb2_phy_driver_init+0x0/0x10 returned 0 after 675 usecs [ 0.186582] calling exynos5_usb3drd_phy_init+0x0/0x10 @ 1 [ 0.186667] bus: 'platform': driver_probe_device: matched device 12100000.phy with driver exynos5_usb3drd_phy [ 0.186684] bus: 'platform': really_probe: probing driver exynos5_usb3drd_phy with device 12100000.phy [ 0.186848] 12100000.phy supply vbus-boost not found, using dummy regulator [ 0.187098] driver: 'exynos5_usb3drd_phy': driver_bound: bound to device '12100000.phy' [ 0.187116] bus: 'platform': really_probe: bound device 12100000.phy to driver exynos5_usb3drd_phy [ 0.187243] initcall exynos5_usb3drd_phy_init+0x0/0x10 returned 0 after 631 usecs [ 0.187264] calling pwm_samsung_driver_init+0x0/0x10 @ 1 [ 0.187360] bus: 'platform': driver_probe_device: matched device 12dd0000.pwm with driver samsung-pwm [ 0.187377] bus: 'platform': really_probe: probing driver samsung-pwm with device 12dd0000.pwm [ 0.187536] driver: 'samsung-pwm': driver_bound: bound to device '12dd0000.pwm' [ 0.187554] bus: 'platform': really_probe: bound device 12dd0000.pwm to driver samsung-pwm [ 0.187674] initcall pwm_samsung_driver_init+0x0/0x10 returned 0 after 386 usecs [ 0.187693] calling platform_lcd_driver_init+0x0/0x10 @ 1 [ 0.187816] initcall platform_lcd_driver_init+0x0/0x10 returned 0 after 106 usecs [ 0.187836] calling genericbl_driver_init+0x0/0x10 @ 1 [ 0.187926] initcall genericbl_driver_init+0x0/0x10 returned 0 after 74 usecs [ 0.187943] calling pwm_backlight_driver_init+0x0/0x10 @ 1 [ 0.188023] bus: 'platform': driver_probe_device: matched device backlight with driver pwm-backlight [ 0.188040] bus: 'platform': really_probe: probing driver pwm-backlight with device backlight [ 0.188109] pwm-backlight backlight: GPIO lookup for consumer enable [ 0.188121] pwm-backlight backlight: using device tree for GPIO lookup [ 0.188140] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/backlight[0]' - status (0) [ 0.188208] platform backlight: Driver pwm-backlight requests probe deferral [ 0.188221] platform backlight: Added to deferred list [ 0.188283] initcall pwm_backlight_driver_init+0x0/0x10 returned 0 after 318 usecs [ 0.188304] calling exynos_mipi_dsi_driver_init+0x0/0x10 @ 1 [ 0.188393] initcall exynos_mipi_dsi_driver_init+0x0/0x10 returned 0 after 73 usecs [ 0.188413] calling pl330_driver_init+0x0/0xc @ 1 [ 0.188432] bus: 'amba': driver_probe_device: matched device 121a0000.pdma with driver dma-pl330 [ 0.188449] bus: 'amba': really_probe: probing driver dma-pl330 with device 121a0000.pdma [ 0.191215] dma-pl330 121a0000.pdma: Loaded driver for PL330 DMAC-241330 [ 0.191232] dma-pl330 121a0000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32 [ 0.191253] driver: 'dma-pl330': driver_bound: bound to device '121a0000.pdma' [ 0.191269] bus: 'amba': really_probe: bound device 121a0000.pdma to driver dma-pl330 [ 0.191298] bus: 'amba': driver_probe_device: matched device 121b0000.pdma with driver dma-pl330 [ 0.191315] bus: 'amba': really_probe: probing driver dma-pl330 with device 121b0000.pdma [ 0.194244] dma-pl330 121b0000.pdma: Loaded driver for PL330 DMAC-241330 [ 0.194262] dma-pl330 121b0000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32 [ 0.194282] driver: 'dma-pl330': driver_bound: bound to device '121b0000.pdma' [ 0.194298] bus: 'amba': really_probe: bound device 121b0000.pdma to driver dma-pl330 [ 0.194327] bus: 'amba': driver_probe_device: matched device 10800000.mdma with driver dma-pl330 [ 0.194344] bus: 'amba': really_probe: probing driver dma-pl330 with device 10800000.mdma [ 0.195148] dma-pl330 10800000.mdma: Loaded driver for PL330 DMAC-241330 [ 0.195164] dma-pl330 10800000.mdma: DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32 [ 0.195183] driver: 'dma-pl330': driver_bound: bound to device '10800000.mdma' [ 0.195198] bus: 'amba': really_probe: bound device 10800000.mdma to driver dma-pl330 [ 0.195225] bus: 'amba': driver_probe_device: matched device 11c10000.mdma with driver dma-pl330 [ 0.195241] bus: 'amba': really_probe: probing driver dma-pl330 with device 11c10000.mdma [ 0.196010] dma-pl330 11c10000.mdma: Loaded driver for PL330 DMAC-241330 [ 0.196024] dma-pl330 11c10000.mdma: DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32 [ 0.196042] driver: 'dma-pl330': driver_bound: bound to device '11c10000.mdma' [ 0.196057] bus: 'amba': really_probe: bound device 11c10000.mdma to driver dma-pl330 [ 0.196127] initcall pl330_driver_init+0x0/0xc returned 0 after 7517 usecs [ 0.196144] calling max77802_pmic_driver_init+0x0/0x10 @ 1 [ 0.196257] initcall max77802_pmic_driver_init+0x0/0x10 returned 0 after 96 usecs [ 0.196278] calling s2mpa01_pmic_driver_init+0x0/0x10 @ 1 [ 0.196366] initcall s2mpa01_pmic_driver_init+0x0/0x10 returned 0 after 72 usecs [ 0.196385] calling pty_init+0x0/0x3dc @ 1 [ 0.249310] initcall pty_init+0x0/0x3dc returned 0 after 51665 usecs [ 0.249336] calling sysrq_init+0x0/0xa0 @ 1 [ 0.249359] initcall sysrq_init+0x0/0xa0 returned 0 after 9 usecs [ 0.249376] calling serial8250_init+0x0/0x144 @ 1 [ 0.249387] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.250295] bus: 'platform': driver_probe_device: matched device serial8250 with driver serial8250 [ 0.250315] bus: 'platform': really_probe: probing driver serial8250 with device serial8250 [ 0.250352] driver: 'serial8250': driver_bound: bound to device 'serial8250' [ 0.250365] bus: 'platform': really_probe: bound device serial8250 to driver serial8250 [ 0.250428] initcall serial8250_init+0x0/0x144 returned 0 after 1012 usecs [ 0.250446] calling samsung_serial_driver_init+0x0/0x10 @ 1 [ 0.250478] bus: 'platform': driver_probe_device: matched device 12c00000.serial with driver samsung-uart [ 0.250496] bus: 'platform': really_probe: probing driver samsung-uart with device 12c00000.serial [ 0.250603] 12c00000.serial: ttySAC0 at MMIO 0x12c00000 (irq = 56, base_baud = 0) is a S3C6400/10 [ 0.250823] driver: 'samsung-uart': driver_bound: bound to device '12c00000.serial' [ 0.250840] bus: 'platform': really_probe: bound device 12c00000.serial to driver samsung-uart [ 0.250861] bus: 'platform': driver_probe_device: matched device 12c10000.serial with driver samsung-uart [ 0.250879] bus: 'platform': really_probe: probing driver samsung-uart with device 12c10000.serial [ 0.250943] 12c10000.serial: ttySAC1 at MMIO 0x12c10000 (irq = 57, base_baud = 0) is a S3C6400/10 [ 0.251144] driver: 'samsung-uart': driver_bound: bound to device '12c10000.serial' [ 0.251161] bus: 'platform': really_probe: bound device 12c10000.serial to driver samsung-uart [ 0.251181] bus: 'platform': driver_probe_device: matched device 12c20000.serial with driver samsung-uart [ 0.251198] bus: 'platform': really_probe: probing driver samsung-uart with device 12c20000.serial [ 0.251264] 12c20000.serial: ttySAC2 at MMIO 0x12c20000 (irq = 58, base_baud = 0) is a S3C6400/10 [ 0.251468] driver: 'samsung-uart': driver_bound: bound to device '12c20000.serial' [ 0.251484] bus: 'platform': really_probe: bound device 12c20000.serial to driver samsung-uart [ 0.251505] bus: 'platform': driver_probe_device: matched device 12c30000.serial with driver samsung-uart [ 0.251522] bus: 'platform': really_probe: probing driver samsung-uart with device 12c30000.serial [ 0.251585] 12c30000.serial: ttySAC3 at MMIO 0x12c30000 (irq = 59, base_baud = 0) is a S3C6400/10 [ 0.251852] driver: 'samsung-uart': driver_bound: bound to device '12c30000.serial' [ 0.251870] bus: 'platform': really_probe: bound device 12c30000.serial to driver samsung-uart [ 0.252163] initcall samsung_serial_driver_init+0x0/0x10 returned 0 after 1660 usecs [ 0.252185] calling of_platform_serial_driver_init+0x0/0x10 @ 1 [ 0.252481] initcall of_platform_serial_driver_init+0x0/0x10 returned 0 after 273 usecs [ 0.252502] calling hwrng_modinit+0x0/0xc @ 1 [ 0.252635] initcall hwrng_modinit+0x0/0xc returned 0 after 116 usecs [ 0.252652] calling exynos_rng_driver_init+0x0/0x10 @ 1 [ 0.252744] initcall exynos_rng_driver_init+0x0/0x10 returned 0 after 76 usecs [ 0.252765] calling rng_init+0x0/0xc @ 1 [ 0.252780] initcall rng_init+0x0/0xc returned 0 after 3 usecs [ 0.252795] calling tpm_tis_i2c_driver_init+0x0/0x10 @ 1 [ 0.252884] initcall tpm_tis_i2c_driver_init+0x0/0x10 returned 0 after 72 usecs [ 0.252904] calling drm_core_init+0x0/0x104 @ 1 [ 0.252967] [drm] Initialized drm 1.1.0 20060810 [ 0.252981] initcall drm_core_init+0x0/0x104 returned 0 after 63 usecs [ 0.252996] calling exynos_drm_init+0x0/0xc0 @ 1 [ 0.253134] bus: 'platform': driver_probe_device: matched device 14400000.fimd with driver exynos4-fb [ 0.253152] bus: 'platform': really_probe: probing driver exynos4-fb with device 14400000.fimd [ 0.253290] driver: 'exynos4-fb': driver_bound: bound to device '14400000.fimd' [ 0.253307] bus: 'platform': really_probe: bound device 14400000.fimd to driver exynos4-fb [ 0.253551] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp [ 0.253570] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller [ 0.254151] platform 145b0000.dp-controller: Driver exynos-dp requests probe deferral [ 0.254168] platform 145b0000.dp-controller: Added to deferred list [ 0.254605] bus: 'platform': driver_probe_device: matched device 14450000.mixer with driver exynos-mixer [ 0.254623] bus: 'platform': really_probe: probing driver exynos-mixer with device 14450000.mixer [ 0.255125] driver: 'exynos-mixer': driver_bound: bound to device '14450000.mixer' [ 0.255142] bus: 'platform': really_probe: bound device 14450000.mixer to driver exynos-mixer [ 0.255358] bus: 'platform': driver_probe_device: matched device 14530000.hdmi with driver exynos-hdmi [ 0.255376] bus: 'platform': really_probe: probing driver exynos-hdmi with device 14530000.hdmi [ 0.255911] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of node '/hdmi[0]' - status (0) [ 0.256608] [drm:hdmi_probe] *ERROR* failed to get hdmi-en regulator [ 0.256623] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed [ 0.256796] platform 14530000.hdmi: Driver exynos-hdmi requests probe deferral [ 0.256813] platform 14530000.hdmi: Added to deferred list [ 0.256978] bus: 'platform': driver_probe_device: matched device exynos-drm with driver exynos-drm [ 0.256996] bus: 'platform': really_probe: probing driver exynos-drm with device exynos-drm [ 0.257649] driver: 'exynos-drm': driver_bound: bound to device 'exynos-drm' [ 0.257661] bus: 'platform': really_probe: bound device exynos-drm to driver exynos-drm [ 0.257723] initcall exynos_drm_init+0x0/0xc0 returned 0 after 4604 usecs [ 0.257742] calling panel_simple_init+0x0/0x34 @ 1 [ 0.258146] bus: 'platform': driver_probe_device: matched device panel with driver panel-simple [ 0.258162] bus: 'platform': really_probe: probing driver panel-simple with device panel [ 0.258232] platform panel: Driver panel-simple requests probe deferral [ 0.258244] platform panel: Added to deferred list [ 0.258358] initcall panel_simple_init+0x0/0x34 returned 0 after 586 usecs [ 0.258376] calling s6e8aa0_driver_init+0x0/0x10 @ 1 [ 0.258433] initcall s6e8aa0_driver_init+0x0/0x10 returned 0 after 42 usecs [ 0.258450] calling ptn3460_driver_init+0x0/0x10 @ 1 [ 0.258476] bus: 'i2c': driver_probe_device: matched device 7-0020 with driver nxp,ptn3460 [ 0.258497] bus: 'i2c': really_probe: probing driver nxp,ptn3460 with device 7-0020 [ 0.258554] i2c 7-0020: Driver nxp,ptn3460 requests probe deferral [ 0.258566] i2c 7-0020: Added to deferred list [ 0.258641] initcall ptn3460_driver_init+0x0/0x10 returned 0 after 173 usecs [ 0.258659] calling ps8622_driver_init+0x0/0x10 @ 1 [ 0.258732] initcall ps8622_driver_init+0x0/0x10 returned 0 after 58 usecs [ 0.258751] calling topology_sysfs_init+0x0/0x7c @ 1 [ 0.258812] initcall topology_sysfs_init+0x0/0x7c returned 0 after 47 usecs [ 0.258828] calling cacheinfo_sysfs_init+0x0/0x94 @ 1 [ 0.258841] initcall cacheinfo_sysfs_init+0x0/0x94 returned -2 after 1 usecs [ 0.258857] calling devcoredump_init+0x0/0x14 @ 1 [ 0.258911] initcall devcoredump_init+0x0/0x14 returned 0 after 39 usecs [ 0.258928] calling brd_init+0x0/0x170 @ 1 [ 0.266174] brd: module loaded [ 0.266198] initcall brd_init+0x0/0x170 returned 0 after 7083 usecs [ 0.266215] calling loop_init+0x0/0x12c @ 1 [ 0.270220] loop: module loaded [ 0.270243] initcall loop_init+0x0/0x12c returned 0 after 3917 usecs [ 0.270261] calling init_cryptoloop+0x0/0x2c @ 1 [ 0.270274] initcall init_cryptoloop+0x0/0x2c returned 0 after 0 usecs [ 0.270290] calling cros_ec_driver_init+0x0/0x10 @ 1 [ 0.270378] initcall cros_ec_driver_init+0x0/0x10 returned 0 after 72 usecs [ 0.270396] calling cros_ec_driver_spi_init+0x0/0xc @ 1 [ 0.270455] initcall cros_ec_driver_spi_init+0x0/0xc returned 0 after 43 usecs [ 0.270475] calling init_sd+0x0/0x164 @ 1 [ 0.270603] initcall init_sd+0x0/0x164 returned 0 after 111 usecs [ 0.270620] calling init_sg+0x0/0x134 @ 1 [ 0.270697] initcall init_sg+0x0/0x134 returned 0 after 61 usecs [ 0.270714] calling s3c64xx_spi_driver_init+0x0/0x10 @ 1 [ 0.270835] bus: 'platform': driver_probe_device: matched device 12d30000.spi with driver s3c64xx-spi [ 0.270853] bus: 'platform': really_probe: probing driver s3c64xx-spi with device 12d30000.spi [ 0.271044] of_get_named_gpiod_flags: parsed 'cs-gpios' property of node '/spi@12d30000[0]' - status (0) [ 0.271294] driver: 's3c64xx-spi': driver_bound: bound to device '12d30000.spi' [ 0.271312] bus: 'platform': really_probe: bound device 12d30000.spi to driver s3c64xx-spi [ 0.271506] initcall s3c64xx_spi_driver_init+0x0/0x10 returned 0 after 758 usecs [ 0.271529] calling net_olddevs_init+0x0/0x6c @ 1 [ 0.271546] initcall net_olddevs_init+0x0/0x6c returned 0 after 4 usecs [ 0.271562] calling smsc911x_init_module+0x0/0x10 @ 1 [ 0.271697] initcall smsc911x_init_module+0x0/0x10 returned 0 after 118 usecs [ 0.271770] calling rtl8152_driver_init+0x0/0x18 @ 1 [ 0.271867] usbcore: registered new interface driver r8152 [ 0.271883] initcall rtl8152_driver_init+0x0/0x18 returned 0 after 96 usecs [ 0.271900] calling asix_driver_init+0x0/0x18 @ 1 [ 0.271987] usbcore: registered new interface driver asix [ 0.272002] initcall asix_driver_init+0x0/0x18 returned 0 after 86 usecs [ 0.272019] calling ax88179_178a_driver_init+0x0/0x18 @ 1 [ 0.272086] usbcore: registered new interface driver ax88179_178a [ 0.272102] initcall ax88179_178a_driver_init+0x0/0x18 returned 0 after 67 usecs [ 0.272122] calling cdc_driver_init+0x0/0x18 @ 1 [ 0.272192] usbcore: registered new interface driver cdc_ether [ 0.272207] initcall cdc_driver_init+0x0/0x18 returned 0 after 69 usecs [ 0.272223] calling smsc75xx_driver_init+0x0/0x18 @ 1 [ 0.272305] usbcore: registered new interface driver smsc75xx [ 0.272321] initcall smsc75xx_driver_init+0x0/0x18 returned 0 after 82 usecs [ 0.272338] calling smsc95xx_driver_init+0x0/0x18 @ 1 [ 0.272415] usbcore: registered new interface driver smsc95xx [ 0.272430] initcall smsc95xx_driver_init+0x0/0x18 returned 0 after 76 usecs [ 0.272447] calling net1080_driver_init+0x0/0x18 @ 1 [ 0.272510] usbcore: registered new interface driver net1080 [ 0.272525] initcall net1080_driver_init+0x0/0x18 returned 0 after 63 usecs [ 0.272541] calling cdc_subset_driver_init+0x0/0x18 @ 1 [ 0.272602] usbcore: registered new interface driver cdc_subset [ 0.272617] initcall cdc_subset_driver_init+0x0/0x18 returned 0 after 61 usecs [ 0.272637] calling zaurus_driver_init+0x0/0x18 @ 1 [ 0.272697] usbcore: registered new interface driver zaurus [ 0.272712] initcall zaurus_driver_init+0x0/0x18 returned 0 after 60 usecs [ 0.272728] calling usbnet_init+0x0/0x30 @ 1 [ 0.272747] initcall usbnet_init+0x0/0x30 returned 0 after 6 usecs [ 0.272763] calling cdc_ncm_driver_init+0x0/0x18 @ 1 [ 0.272837] usbcore: registered new interface driver cdc_ncm [ 0.272852] initcall cdc_ncm_driver_init+0x0/0x18 returned 0 after 73 usecs [ 0.272868] calling dwc3_driver_init+0x0/0x10 @ 1 [ 0.273026] initcall dwc3_driver_init+0x0/0x10 returned 0 after 140 usecs [ 0.273044] calling dwc3_exynos_driver_init+0x0/0x10 @ 1 [ 0.273110] bus: 'platform': driver_probe_device: matched device usb@12000000 with driver exynos-dwc3 [ 0.273127] bus: 'platform': really_probe: probing driver exynos-dwc3 with device usb@12000000 [ 0.273407] exynos-dwc3 usb@12000000: no suspend clk specified [ 0.273446] usb@12000000 supply vdd33 not found, using dummy regulator [ 0.273499] usb@12000000 supply vdd10 not found, using dummy regulator [ 0.273738] bus: 'platform': driver_probe_device: matched device 12000000.dwc3 with driver dwc3 [ 0.273756] bus: 'platform': really_probe: probing driver dwc3 with device 12000000.dwc3 [ 0.474148] driver: 'dwc3': driver_bound: bound to device '12000000.dwc3' [ 0.474163] bus: 'platform': really_probe: bound device 12000000.dwc3 to driver dwc3 [ 0.474182] driver: 'exynos-dwc3': driver_bound: bound to device 'usb@12000000' [ 0.474198] bus: 'platform': really_probe: bound device usb@12000000 to driver exynos-dwc3 [ 0.474322] initcall dwc3_exynos_driver_init+0x0/0x10 returned 0 after 196544 usecs [ 0.474345] calling dwc2_platform_driver_init+0x0/0x10 @ 1 [ 0.474531] initcall dwc2_platform_driver_init+0x0/0x10 returned 0 after 167 usecs [ 0.474554] calling xhci_plat_init+0x0/0x2c @ 1 [ 0.474694] bus: 'platform': driver_probe_device: matched device xhci-hcd.2.auto with driver xhci-hcd [ 0.474712] bus: 'platform': really_probe: probing driver xhci-hcd with device xhci-hcd.2.auto [ 0.474759] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller [ 0.474785] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 1 [ 0.475001] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010 [ 0.475044] xhci-hcd xhci-hcd.2.auto: irq 144, io mem 0x12000000 [ 0.475153] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 0.475166] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.475182] usb usb1: Product: xHCI Host Controller [ 0.475192] usb usb1: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty xhci-hcd [ 0.475207] usb usb1: SerialNumber: xhci-hcd.2.auto [ 0.475534] bus: 'usb': driver_probe_device: matched device usb1 with driver usb [ 0.475551] bus: 'usb': really_probe: probing driver usb with device usb1 [ 0.475689] bus: 'usb': driver_probe_device: matched device 1-0:1.0 with driver hub [ 0.475706] bus: 'usb': really_probe: probing driver hub with device 1-0:1.0 [ 0.475736] hub 1-0:1.0: USB hub found [ 0.475764] hub 1-0:1.0: 1 port detected [ 0.475881] driver: 'hub': driver_bound: bound to device '1-0:1.0' [ 0.475895] bus: 'usb': really_probe: bound device 1-0:1.0 to driver hub [ 0.475967] driver: 'usb': driver_bound: bound to device 'usb1' [ 0.475979] bus: 'usb': really_probe: bound device usb1 to driver usb [ 0.476058] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller [ 0.476077] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 2 [ 0.476132] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. [ 0.476211] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 [ 0.476224] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.476239] usb usb2: Product: xHCI Host Controller [ 0.476250] usb usb2: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty xhci-hcd [ 0.476265] usb usb2: SerialNumber: xhci-hcd.2.auto [ 0.476551] bus: 'usb': driver_probe_device: matched device usb2 with driver usb [ 0.476568] bus: 'usb': really_probe: probing driver usb with device usb2 [ 0.476739] bus: 'usb': driver_probe_device: matched device 2-0:1.0 with driver hub [ 0.476757] bus: 'usb': really_probe: probing driver hub with device 2-0:1.0 [ 0.476786] hub 2-0:1.0: USB hub found [ 0.476811] hub 2-0:1.0: 1 port detected [ 0.476926] driver: 'hub': driver_bound: bound to device '2-0:1.0' [ 0.476938] bus: 'usb': really_probe: bound device 2-0:1.0 to driver hub [ 0.477007] driver: 'usb': driver_bound: bound to device 'usb2' [ 0.477019] bus: 'usb': really_probe: bound device usb2 to driver usb [ 0.477098] driver: 'xhci-hcd': driver_bound: bound to device 'xhci-hcd.2.auto' [ 0.477114] bus: 'platform': really_probe: bound device xhci-hcd.2.auto to driver xhci-hcd [ 0.477176] initcall xhci_plat_init+0x0/0x2c returned 0 after 2546 usecs [ 0.477194] calling ehci_hcd_init+0x0/0x70 @ 1 [ 0.477204] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.477217] initcall ehci_hcd_init+0x0/0x70 returned 0 after 10 usecs [ 0.477233] calling ehci_exynos_init+0x0/0x54 @ 1 [ 0.477243] ehci-exynos: EHCI EXYNOS driver [ 0.477322] bus: 'platform': driver_probe_device: matched device 12110000.usb with driver exynos-ehci [ 0.477340] bus: 'platform': really_probe: probing driver exynos-ehci with device 12110000.usb [ 0.477387] of_get_named_gpiod_flags: parsed 'samsung,vbus-gpio' property of node '/usb@12110000[0]' - status (0) [ 0.477587] exynos-ehci 12110000.usb: EHCI Host Controller [ 0.477613] exynos-ehci 12110000.usb: new USB bus registered, assigned bus number 3 [ 0.477724] exynos-ehci 12110000.usb: irq 108, io mem 0x12110000 [ 0.486728] exynos-ehci 12110000.usb: USB 2.0 started, EHCI 1.00 [ 0.486832] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 0.486846] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.486861] usb usb3: Product: EHCI Host Controller [ 0.486871] usb usb3: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty ehci_hcd [ 0.486886] usb usb3: SerialNumber: 12110000.usb [ 0.487180] bus: 'usb': driver_probe_device: matched device usb3 with driver usb [ 0.487197] bus: 'usb': really_probe: probing driver usb with device usb3 [ 0.487328] bus: 'usb': driver_probe_device: matched device 3-0:1.0 with driver hub [ 0.487345] bus: 'usb': really_probe: probing driver hub with device 3-0:1.0 [ 0.487374] hub 3-0:1.0: USB hub found [ 0.487398] hub 3-0:1.0: 3 ports detected [ 0.487630] driver: 'hub': driver_bound: bound to device '3-0:1.0' [ 0.487643] bus: 'usb': really_probe: bound device 3-0:1.0 to driver hub [ 0.487710] driver: 'usb': driver_bound: bound to device 'usb3' [ 0.487723] bus: 'usb': really_probe: bound device usb3 to driver usb [ 0.487796] driver: 'exynos-ehci': driver_bound: bound to device '12110000.usb' [ 0.487812] bus: 'platform': really_probe: bound device 12110000.usb to driver exynos-ehci [ 0.487937] initcall ehci_exynos_init+0x0/0x54 returned 0 after 10437 usecs [ 0.487955] calling ohci_hcd_mod_init+0x0/0x80 @ 1 [ 0.487965] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 0.487985] initcall ohci_hcd_mod_init+0x0/0x80 returned 0 after 17 usecs [ 0.488002] calling ohci_exynos_init+0x0/0x54 @ 1 [ 0.488011] ohci-exynos: OHCI EXYNOS driver [ 0.488085] bus: 'platform': driver_probe_device: matched device 12120000.usb with driver exynos-ohci [ 0.488103] bus: 'platform': really_probe: probing driver exynos-ohci with device 12120000.usb [ 0.488179] exynos-ohci 12120000.usb: USB Host Controller [ 0.488204] exynos-ohci 12120000.usb: new USB bus registered, assigned bus number 4 [ 0.488279] exynos-ohci 12120000.usb: irq 108, io mem 0x12120000 [ 0.545832] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 [ 0.545845] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 0.545861] usb usb4: Product: USB Host Controller [ 0.545871] usb usb4: Manufacturer: Linux 4.3.0-rc5-next-20151013-dirty ohci_hcd [ 0.545886] usb usb4: SerialNumber: 12120000.usb [ 0.546171] bus: 'usb': driver_probe_device: matched device usb4 with driver usb [ 0.546188] bus: 'usb': really_probe: probing driver usb with device usb4 [ 0.546322] bus: 'usb': driver_probe_device: matched device 4-0:1.0 with driver hub [ 0.546339] bus: 'usb': really_probe: probing driver hub with device 4-0:1.0 [ 0.546368] hub 4-0:1.0: USB hub found [ 0.546394] hub 4-0:1.0: 3 ports detected [ 0.546583] driver: 'hub': driver_bound: bound to device '4-0:1.0' [ 0.546596] bus: 'usb': really_probe: bound device 4-0:1.0 to driver hub [ 0.546667] driver: 'usb': driver_bound: bound to device 'usb4' [ 0.546679] bus: 'usb': really_probe: bound device usb4 to driver usb [ 0.546777] driver: 'exynos-ohci': driver_bound: bound to device '12120000.usb' [ 0.546793] bus: 'platform': really_probe: bound device 12120000.usb to driver exynos-ohci [ 0.546905] initcall ohci_exynos_init+0x0/0x54 returned 0 after 57508 usecs [ 0.546923] calling xhci_hcd_init+0x0/0x8 @ 1 [ 0.546935] initcall xhci_hcd_init+0x0/0x8 returned 0 after 0 usecs [ 0.546951] calling usb_storage_driver_init+0x0/0x38 @ 1 [ 0.547053] usbcore: registered new interface driver usb-storage [ 0.547068] initcall usb_storage_driver_init+0x0/0x38 returned 0 after 100 usecs [ 0.547089] calling usb3503_init+0x0/0x54 @ 1 [ 0.547304] initcall usb3503_init+0x0/0x54 returned 0 after 196 usecs [ 0.547322] calling gadget_cfs_init+0x0/0x20 @ 1 [ 0.547369] initcall gadget_cfs_init+0x0/0x20 returned 0 after 31 usecs [ 0.547386] calling ecmmod_init+0x0/0xc @ 1 [ 0.547399] initcall ecmmod_init+0x0/0xc returned 0 after 1 usecs [ 0.547415] calling gethmod_init+0x0/0xc @ 1 [ 0.547427] initcall gethmod_init+0x0/0xc returned 0 after 0 usecs [ 0.547443] calling rndismod_init+0x0/0xc @ 1 [ 0.547455] initcall rndismod_init+0x0/0xc returned 0 after 0 usecs [ 0.547468] calling eth_driver_init+0x0/0xc @ 1 [ 0.547480] initcall eth_driver_init+0x0/0xc returned -19 after 1 usecs [ 0.547492] calling serport_init+0x0/0x30 @ 1 [ 0.547504] initcall serport_init+0x0/0x30 returned 0 after 0 usecs [ 0.547516] calling input_leds_init+0x0/0xc @ 1 [ 0.547529] initcall input_leds_init+0x0/0xc returned 0 after 1 usecs [ 0.547542] calling mousedev_init+0x0/0x88 @ 1 [ 0.547799] mousedev: PS/2 mouse device common for all mice [ 0.547813] initcall mousedev_init+0x0/0x88 returned 0 after 254 usecs [ 0.547827] calling evdev_init+0x0/0xc @ 1 [ 0.547839] initcall evdev_init+0x0/0xc returned 0 after 1 usecs [ 0.547851] calling atkbd_init+0x0/0x18 @ 1 [ 0.547929] initcall atkbd_init+0x0/0x18 returned 0 after 63 usecs [ 0.547944] calling cros_ec_keyb_driver_init+0x0/0x10 @ 1 [ 0.548078] initcall cros_ec_keyb_driver_init+0x0/0x10 returned 0 after 118 usecs [ 0.548097] calling samsung_keypad_driver_init+0x0/0x10 @ 1 [ 0.548243] initcall samsung_keypad_driver_init+0x0/0x10 returned 0 after 129 usecs [ 0.548261] calling cyapa_driver_init+0x0/0x10 @ 1 [ 0.548283] bus: 'i2c': driver_probe_device: matched device 1-0067 with driver cyapa [ 0.548304] bus: 'i2c': really_probe: probing driver cyapa with device 1-0067 [ 0.548768] 1-0067 supply vcc not found, using dummy regulator [ 0.597006] input: Cypress APA Trackpad (cyapa) as /devices/platform/12c70000.i2c/i2c-1/1-0067/input/input0 [ 0.597269] driver: 'cyapa': driver_bound: bound to device '1-0067' [ 0.597282] bus: 'i2c': really_probe: bound device 1-0067 to driver cyapa [ 0.597360] initcall cyapa_driver_init+0x0/0x10 returned 0 after 47935 usecs [ 0.597376] calling mxt_driver_init+0x0/0x10 @ 1 [ 0.597448] initcall mxt_driver_init+0x0/0x10 returned 0 after 57 usecs [ 0.597463] calling max77686_rtc_driver_init+0x0/0x10 @ 1 [ 0.597521] bus: 'platform': driver_probe_device: matched device max77686-rtc with driver max77686-rtc [ 0.597539] bus: 'platform': really_probe: probing driver max77686-rtc with device max77686-rtc [ 0.597572] max77686-rtc max77686-rtc: max77686_rtc_probe [ 0.697208] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0 [ 0.697535] driver: 'max77686-rtc': driver_bound: bound to device 'max77686-rtc' [ 0.697552] bus: 'platform': really_probe: bound device max77686-rtc to driver max77686-rtc [ 0.697626] initcall max77686_rtc_driver_init+0x0/0x10 returned 0 after 97801 usecs [ 0.697645] calling max77802_rtc_driver_init+0x0/0x10 @ 1 [ 0.697741] initcall max77802_rtc_driver_init+0x0/0x10 returned 0 after 80 usecs [ 0.697759] calling s3c_rtc_driver_init+0x0/0x10 @ 1 [ 0.697795] bus: 'platform': driver_probe_device: matched device 101e0000.rtc with driver s3c-rtc [ 0.697812] bus: 'platform': really_probe: probing driver s3c-rtc with device 101e0000.rtc [ 0.697909] s3c-rtc 101e0000.rtc: failed to find rtc source clock [ 0.697936] platform 101e0000.rtc: Driver s3c-rtc requests probe deferral [ 0.697949] platform 101e0000.rtc: Added to deferred list [ 0.698141] initcall s3c_rtc_driver_init+0x0/0x10 returned 0 after 359 usecs [ 0.698156] calling s5m_rtc_driver_init+0x0/0x10 @ 1 [ 0.698246] initcall s5m_rtc_driver_init+0x0/0x10 returned 0 after 74 usecs [ 0.698260] calling i2c_dev_init+0x0/0xe0 @ 1 [ 0.698270] i2c /dev entries driver [ 0.699243] initcall i2c_dev_init+0x0/0xe0 returned 0 after 946 usecs [ 0.699259] calling exynos5_i2c_driver_init+0x0/0x10 @ 1 [ 0.699457] initcall exynos5_i2c_driver_init+0x0/0x10 returned 0 after 180 usecs [ 0.699477] calling ec_i2c_tunnel_driver_init+0x0/0x10 @ 1 [ 0.699602] initcall ec_i2c_tunnel_driver_init+0x0/0x10 returned 0 after 109 usecs [ 0.699621] calling i2c_arbitrator_driver_init+0x0/0x10 @ 1 [ 0.699699] bus: 'platform': driver_probe_device: matched device i2c-arbitrator with driver i2c-arb-gpio-challenge [ 0.699718] bus: 'platform': really_probe: probing driver i2c-arb-gpio-challenge with device i2c-arbitrator [ 0.699808] of_get_named_gpiod_flags: parsed 'our-claim-gpio' property of node '/i2c-arbitrator[0]' - status (0) [ 0.699839] of_get_named_gpiod_flags: parsed 'their-claim-gpios' property of node '/i2c-arbitrator[0]' - status (0) [ 0.699866] of_get_named_gpiod_flags: can't parse 'their-claim-gpios' property of node '/i2c-arbitrator[1]' [ 0.700358] bus: 'i2c': driver_probe_device: matched device 104-001e with driver cros-ec-i2c [ 0.700375] bus: 'i2c': really_probe: probing driver cros-ec-i2c with device 104-001e [ 0.708772] bus: 'platform': driver_probe_device: matched device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller with driver cros-ec-keyb [ 0.708793] bus: 'platform': really_probe: probing driver cros-ec-keyb with device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller [ 0.709002] input: cros_ec as /devices/platform/12ca0000.i2c/i2c-4/i2c-104/104-001e/i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller/input/input1 [ 0.709218] driver: 'cros-ec-keyb': driver_bound: bound to device 'i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller' [ 0.709238] bus: 'platform': really_probe: bound device i2c-arbitrator:i2c@0:embedded-controller:keyboard-controller to driver cros-ec-keyb [ 0.709261] cros-ec-i2c 104-001e: Chrome EC device registered [ 0.709272] driver: 'cros-ec-i2c': driver_bound: bound to device '104-001e' [ 0.709284] bus: 'i2c': really_probe: bound device 104-001e to driver cros-ec-i2c [ 0.709397] bus: 'i2c': driver_probe_device: matched device 104-0048 with driver tps65090 [ 0.709414] bus: 'i2c': really_probe: probing driver tps65090 with device 104-0048 [ 0.709500] tps65090 104-0048: No cache defaults, reading back from HW [ 0.713554] bus: 'platform': driver_probe_device: matched device tps65090-pmic with driver tps65090-pmic [ 0.713572] bus: 'platform': really_probe: probing driver tps65090-pmic with device tps65090-pmic [ 0.713701] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]' [ 0.713719] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]' [ 0.713737] of_get_named_gpiod_flags: can't parse 'dcdc-ext-control-gpios' property of node '/i2c-arbitrator/i2c@0/power-regulator[0]' [ 0.727363] driver: 'tps65090-pmic': driver_bound: bound to device 'tps65090-pmic' [ 0.727384] bus: 'platform': really_probe: bound device tps65090-pmic to driver tps65090-pmic [ 0.727564] driver: 'tps65090': driver_bound: bound to device '104-0048' [ 0.727578] bus: 'i2c': really_probe: bound device 104-0048 to driver tps65090 [ 0.727614] i2c i2c-4: Added multiplexed i2c bus 104 [ 0.727624] driver: 'i2c-arb-gpio-challenge': driver_bound: bound to device 'i2c-arbitrator' [ 0.727640] bus: 'platform': really_probe: bound device i2c-arbitrator to driver i2c-arb-gpio-challenge [ 0.727716] initcall i2c_arbitrator_driver_init+0x0/0x10 returned 0 after 27422 usecs [ 0.727737] calling sbs_battery_driver_init+0x0/0x10 @ 1 [ 0.727771] bus: 'i2c': driver_probe_device: matched device 104-000b with driver sbs-battery [ 0.727788] bus: 'i2c': really_probe: probing driver sbs-battery with device 104-000b [ 0.730061] sbs-battery 104-000b: sbs-battery: battery gas gauge device registered [ 0.730078] driver: 'sbs-battery': driver_bound: bound to device '104-000b' [ 0.730090] bus: 'i2c': really_probe: bound device 104-000b to driver sbs-battery [ 0.730159] initcall sbs_battery_driver_init+0x0/0x10 returned 0 after 2352 usecs [ 0.730178] calling max17040_i2c_driver_init+0x0/0x10 @ 1 [ 0.730248] initcall max17040_i2c_driver_init+0x0/0x10 returned 0 after 55 usecs [ 0.730267] calling max17042_i2c_driver_init+0x0/0x10 @ 1 [ 0.730344] initcall max17042_i2c_driver_init+0x0/0x10 returned 0 after 62 usecs [ 0.730363] calling max14577_charger_driver_init+0x0/0x10 @ 1 [ 0.730471] initcall max14577_charger_driver_init+0x0/0x10 returned 0 after 92 usecs [ 0.730490] calling max77693_charger_driver_init+0x0/0x10 @ 1 [ 0.730583] initcall max77693_charger_driver_init+0x0/0x10 returned 0 after 78 usecs [ 0.730602] calling tps65090_charger_driver_init+0x0/0x10 @ 1 [ 0.730712] bus: 'platform': driver_probe_device: matched device tps65090-charger with driver tps65090-charger [ 0.730731] bus: 'platform': really_probe: probing driver tps65090-charger with device tps65090-charger [ 0.732656] driver: 'tps65090-charger': driver_bound: bound to device 'tps65090-charger' [ 0.732674] bus: 'platform': really_probe: bound device tps65090-charger to driver tps65090-charger [ 0.732735] initcall tps65090_charger_driver_init+0x0/0x10 returned 0 after 2068 usecs [ 0.732754] calling ina2xx_driver_init+0x0/0x10 @ 1 [ 0.732829] initcall ina2xx_driver_init+0x0/0x10 returned 0 after 60 usecs [ 0.732844] calling lm90_driver_init+0x0/0x10 @ 1 [ 0.732917] initcall lm90_driver_init+0x0/0x10 returned 0 after 59 usecs [ 0.732932] calling ntc_thermistor_driver_init+0x0/0x10 @ 1 [ 0.733197] initcall ntc_thermistor_driver_init+0x0/0x10 returned 0 after 245 usecs [ 0.733216] calling pwm_fan_driver_init+0x0/0x10 @ 1 [ 0.733344] initcall pwm_fan_driver_init+0x0/0x10 returned 0 after 111 usecs [ 0.733359] calling exynos_tmu_driver_init+0x0/0x10 @ 1 [ 0.733457] bus: 'platform': driver_probe_device: matched device 10060000.tmu with driver exynos-tmu [ 0.733474] bus: 'platform': really_probe: probing driver exynos-tmu with device 10060000.tmu [ 0.733535] thermal thermal_zone0: failed to read out thermal zone (-22) [ 0.733583] 10060000.tmu supply vtmu not found, using dummy regulator [ 0.733713] driver: 'exynos-tmu': driver_bound: bound to device '10060000.tmu' [ 0.733730] bus: 'platform': really_probe: bound device 10060000.tmu to driver exynos-tmu [ 0.733960] initcall exynos_tmu_driver_init+0x0/0x10 returned 0 after 573 usecs [ 0.733981] calling s3c2410wdt_driver_init+0x0/0x10 @ 1 [ 0.734041] bus: 'platform': driver_probe_device: matched device 101d0000.watchdog with driver s3c2410-wdt [ 0.734059] bus: 'platform': really_probe: probing driver s3c2410-wdt with device 101d0000.watchdog [ 0.734400] s3c2410-wdt 101d0000.watchdog: watchdog inactive, reset disabled, irq disabled [ 0.734418] driver: 's3c2410-wdt': driver_bound: bound to device '101d0000.watchdog' [ 0.734433] bus: 'platform': really_probe: bound device 101d0000.watchdog to driver s3c2410-wdt [ 0.734587] initcall s3c2410wdt_driver_init+0x0/0x10 returned 0 after 579 usecs [ 0.734606] calling dm_init+0x0/0x54 @ 1 [ 0.734926] device-mapper: ioctl: 4.33.0-ioctl (2015-8-18) initialised: dm-devel@redhat.com [ 0.734945] initcall dm_init+0x0/0x54 returned 0 after 319 usecs [ 0.734960] calling cpufreq_stats_init+0x0/0xe8 @ 1 [ 0.734974] initcall cpufreq_stats_init+0x0/0xe8 returned 0 after 2 usecs [ 0.734989] calling dt_cpufreq_platdrv_init+0x0/0x10 @ 1 [ 0.735012] bus: 'platform': driver_probe_device: matched device cpufreq-dt with driver cpufreq-dt [ 0.735029] bus: 'platform': really_probe: probing driver cpufreq-dt with device cpufreq-dt [ 0.736234] driver: 'cpufreq-dt': driver_bound: bound to device 'cpufreq-dt' [ 0.736249] bus: 'platform': really_probe: bound device cpufreq-dt to driver cpufreq-dt [ 0.736348] initcall dt_cpufreq_platdrv_init+0x0/0x10 returned 0 after 1313 usecs [ 0.736368] calling exynos_cpufreq_platdrv_init+0x0/0x10 @ 1 [ 0.736517] initcall exynos_cpufreq_platdrv_init+0x0/0x10 returned 0 after 131 usecs [ 0.736537] calling exynos_cpuidle_driver_init+0x0/0x10 @ 1 [ 0.736558] bus: 'platform': driver_probe_device: matched device exynos_cpuidle with driver exynos_cpuidle [ 0.736576] bus: 'platform': really_probe: probing driver exynos_cpuidle with device exynos_cpuidle [ 0.736860] driver: 'exynos_cpuidle': driver_bound: bound to device 'exynos_cpuidle' [ 0.736878] bus: 'platform': really_probe: bound device exynos_cpuidle to driver exynos_cpuidle [ 0.736979] initcall exynos_cpuidle_driver_init+0x0/0x10 returned 0 after 418 usecs [ 0.736999] calling mmc_blk_init+0x0/0x98 @ 1 [ 0.737056] initcall mmc_blk_init+0x0/0x98 returned 0 after 43 usecs [ 0.737072] calling sdhci_drv_init+0x0/0x24 @ 1 [ 0.737082] sdhci: Secure Digital Host Controller Interface driver [ 0.737092] sdhci: Copyright(c) Pierre Ossman [ 0.737103] initcall sdhci_drv_init+0x0/0x24 returned 0 after 18 usecs [ 0.737124] calling sdhci_s3c_driver_init+0x0/0x10 @ 1 [ 0.737293] initcall sdhci_s3c_driver_init+0x0/0x10 returned 0 after 151 usecs [ 0.737312] calling dw_mci_init+0x0/0x18 @ 1 [ 0.737321] Synopsys Designware Multimedia Card Interface Driver [ 0.737333] initcall dw_mci_init+0x0/0x18 returned 0 after 9 usecs [ 0.737348] calling dw_mci_pltfm_driver_init+0x0/0x10 @ 1 [ 0.737504] initcall dw_mci_pltfm_driver_init+0x0/0x10 returned 0 after 139 usecs [ 0.737523] calling dw_mci_exynos_pltfm_driver_init+0x0/0x10 @ 1 [ 0.737752] bus: 'platform': driver_probe_device: matched device 12200000.mmc with driver dwmmc_exynos [ 0.737770] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12200000.mmc [ 0.738028] dwmmc_exynos 12200000.mmc: IDMAC supports 32-bit address mode. [ 0.738082] dwmmc_exynos 12200000.mmc: Using internal DMA controller. [ 0.738098] dwmmc_exynos 12200000.mmc: Version ID is 241a [ 0.738136] dwmmc_exynos 12200000.mmc: DW MMC controller at irq 105,32 bit host data width,128 deep fifo [ 0.738208] dwmmc_exynos 12200000.mmc: No vmmc regulator found [ 0.738220] dwmmc_exynos 12200000.mmc: No vqmmc regulator found [ 0.738237] dwmmc_exynos 12200000.mmc: GPIO lookup for consumer cd [ 0.738248] dwmmc_exynos 12200000.mmc: using device tree for GPIO lookup [ 0.738261] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12200000[0]' [ 0.738277] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12200000[0]' [ 0.738293] dwmmc_exynos 12200000.mmc: using lookup tables for GPIO lookup [ 0.738305] dwmmc_exynos 12200000.mmc: lookup for GPIO cd failed [ 0.738317] dwmmc_exynos 12200000.mmc: GPIO lookup for consumer wp [ 0.738328] dwmmc_exynos 12200000.mmc: using device tree for GPIO lookup [ 0.738344] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12200000[0]' [ 0.738359] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12200000[0]' [ 0.738375] dwmmc_exynos 12200000.mmc: using lookup tables for GPIO lookup [ 0.738386] dwmmc_exynos 12200000.mmc: lookup for GPIO wp failed [ 0.766769] dwmmc_exynos 12200000.mmc: 1 slots initialized [ 0.766782] driver: 'dwmmc_exynos': driver_bound: bound to device '12200000.mmc' [ 0.766799] bus: 'platform': really_probe: bound device 12200000.mmc to driver dwmmc_exynos [ 0.766820] bus: 'platform': driver_probe_device: matched device 12220000.mmc with driver dwmmc_exynos [ 0.766837] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12220000.mmc [ 0.767133] dwmmc_exynos 12220000.mmc: IDMAC supports 32-bit address mode. [ 0.767170] dwmmc_exynos 12220000.mmc: Using internal DMA controller. [ 0.767186] dwmmc_exynos 12220000.mmc: Version ID is 241a [ 0.767220] dwmmc_exynos 12220000.mmc: DW MMC controller at irq 106,32 bit host data width,128 deep fifo [ 0.767287] dwmmc_exynos 12220000.mmc: No vmmc regulator found [ 0.767298] dwmmc_exynos 12220000.mmc: No vqmmc regulator found [ 0.767315] dwmmc_exynos 12220000.mmc: GPIO lookup for consumer cd [ 0.767326] dwmmc_exynos 12220000.mmc: using device tree for GPIO lookup [ 0.767338] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12220000[0]' [ 0.767355] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12220000[0]' [ 0.767370] dwmmc_exynos 12220000.mmc: using lookup tables for GPIO lookup [ 0.767382] dwmmc_exynos 12220000.mmc: lookup for GPIO cd failed [ 0.767394] dwmmc_exynos 12220000.mmc: GPIO lookup for consumer wp [ 0.767405] dwmmc_exynos 12220000.mmc: using device tree for GPIO lookup [ 0.767420] of_get_named_gpiod_flags: parsed 'wp-gpios' property of node '/mmc@12220000[0]' - status (0) [ 0.767449] dwmmc_exynos 12220000.mmc: Got WP GPIO [ 0.781730] usb 1-1: new high-speed USB device number 2 using xhci-hcd [ 0.796758] dwmmc_exynos 12220000.mmc: 1 slots initialized [ 0.796773] driver: 'dwmmc_exynos': driver_bound: bound to device '12220000.mmc' [ 0.796789] bus: 'platform': really_probe: bound device 12220000.mmc to driver dwmmc_exynos [ 0.796810] bus: 'platform': driver_probe_device: matched device 12230000.mmc with driver dwmmc_exynos [ 0.796827] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12230000.mmc [ 0.797098] dwmmc_exynos 12230000.mmc: IDMAC supports 32-bit address mode. [ 0.797138] dwmmc_exynos 12230000.mmc: Using internal DMA controller. [ 0.797154] dwmmc_exynos 12230000.mmc: Version ID is 241a [ 0.797188] dwmmc_exynos 12230000.mmc: DW MMC controller at irq 107,32 bit host data width,128 deep fifo [ 0.797250] dwmmc_exynos 12230000.mmc: No vmmc regulator found [ 0.797261] dwmmc_exynos 12230000.mmc: No vqmmc regulator found [ 0.797277] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer cd [ 0.797289] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup [ 0.797301] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12230000[0]' [ 0.797318] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12230000[0]' [ 0.797333] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup [ 0.797345] dwmmc_exynos 12230000.mmc: lookup for GPIO cd failed [ 0.797357] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer wp [ 0.797368] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup [ 0.797379] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12230000[0]' [ 0.797395] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12230000[0]' [ 0.797410] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup [ 0.797422] dwmmc_exynos 12230000.mmc: lookup for GPIO wp failed [ 0.797554] platform 12230000.mmc: Driver dwmmc_exynos requests probe deferral [ 0.797570] platform 12230000.mmc: Added to deferred list [ 0.797714] initcall dw_mci_exynos_pltfm_driver_init+0x0/0x10 returned 0 after 58764 usecs [ 0.797735] calling gpio_led_driver_init+0x0/0x10 @ 1 [ 0.797862] initcall gpio_led_driver_init+0x0/0x10 returned 0 after 111 usecs [ 0.797879] calling led_pwm_driver_init+0x0/0x10 @ 1 [ 0.797990] initcall led_pwm_driver_init+0x0/0x10 returned 0 after 95 usecs [ 0.798006] calling heartbeat_trig_init+0x0/0x40 @ 1 [ 0.798021] initcall heartbeat_trig_init+0x0/0x40 returned 0 after 2 usecs [ 0.798035] calling hid_init+0x0/0x54 @ 1 [ 0.798086] initcall hid_init+0x0/0x54 returned 0 after 38 usecs [ 0.798101] calling hid_generic_init+0x0/0x18 @ 1 [ 0.798146] initcall hid_generic_init+0x0/0x18 returned 0 after 32 usecs [ 0.798161] calling a4_driver_init+0x0/0x18 @ 1 [ 0.798201] initcall a4_driver_init+0x0/0x18 returned 0 after 26 usecs [ 0.798216] calling apple_driver_init+0x0/0x18 @ 1 [ 0.798266] initcall apple_driver_init+0x0/0x18 returned 0 after 37 usecs [ 0.798282] calling belkin_driver_init+0x0/0x18 @ 1 [ 0.798326] initcall belkin_driver_init+0x0/0x18 returned 0 after 31 usecs [ 0.798342] calling ch_driver_init+0x0/0x18 @ 1 [ 0.798380] initcall ch_driver_init+0x0/0x18 returned 0 after 25 usecs [ 0.798395] calling ch_driver_init+0x0/0x18 @ 1 [ 0.798432] initcall ch_driver_init+0x0/0x18 returned 0 after 25 usecs [ 0.798447] calling cp_driver_init+0x0/0x18 @ 1 [ 0.798484] initcall cp_driver_init+0x0/0x18 returned 0 after 25 usecs [ 0.798499] calling ez_driver_init+0x0/0x18 @ 1 [ 0.798538] initcall ez_driver_init+0x0/0x18 returned 0 after 26 usecs [ 0.798553] calling ks_driver_init+0x0/0x18 @ 1 [ 0.798590] initcall ks_driver_init+0x0/0x18 returned 0 after 25 usecs [ 0.798605] calling lg_driver_init+0x0/0x18 @ 1 [ 0.798642] initcall lg_driver_init+0x0/0x18 returned 0 after 25 usecs [ 0.798657] calling ms_driver_init+0x0/0x18 @ 1 [ 0.798695] initcall ms_driver_init+0x0/0x18 returned 0 after 25 usecs [ 0.798710] calling mr_driver_init+0x0/0x18 @ 1 [ 0.798750] initcall mr_driver_init+0x0/0x18 returned 0 after 28 usecs [ 0.798765] calling hid_init+0x0/0x5c @ 1 [ 0.798829] usbcore: registered new interface driver usbhid [ 0.798840] usbhid: USB HID core driver [ 0.798851] initcall hid_init+0x0/0x5c returned 0 after 72 usecs [ 0.798866] calling cros_ec_dev_init+0x0/0xd4 @ 1 [ 0.798938] bus: 'platform': driver_probe_device: matched device cros-ec-ctl.3.auto with driver cros-ec-ctl [ 0.798956] bus: 'platform': really_probe: probing driver cros-ec-ctl with device cros-ec-ctl.3.auto [ 0.799149] driver: 'cros-ec-ctl': driver_bound: bound to device 'cros-ec-ctl.3.auto' [ 0.799167] bus: 'platform': really_probe: bound device cros-ec-ctl.3.auto to driver cros-ec-ctl [ 0.799207] initcall cros_ec_dev_init+0x0/0xd4 returned 0 after 320 usecs [ 0.799224] calling max77686_clk_driver_init+0x0/0x10 @ 1 [ 0.799282] bus: 'platform': driver_probe_device: matched device max77686-clk with driver max77686-clk [ 0.799300] bus: 'platform': really_probe: probing driver max77686-clk with device max77686-clk [ 0.799407] driver: 'max77686-clk': driver_bound: bound to device 'max77686-clk' [ 0.799423] bus: 'platform': really_probe: bound device max77686-clk to driver max77686-clk [ 0.799475] initcall max77686_clk_driver_init+0x0/0x10 returned 0 after 230 usecs [ 0.799495] calling max77802_clk_driver_init+0x0/0x10 @ 1 [ 0.799570] initcall max77802_clk_driver_init+0x0/0x10 returned 0 after 60 usecs [ 0.799593] calling extcon_class_init+0x0/0x20 @ 1 [ 0.799622] initcall extcon_class_init+0x0/0x20 returned 0 after 15 usecs [ 0.799639] calling max14577_muic_driver_init+0x0/0x10 @ 1 [ 0.799714] initcall max14577_muic_driver_init+0x0/0x10 returned 0 after 59 usecs [ 0.799736] calling max77693_muic_driver_init+0x0/0x10 @ 1 [ 0.799811] initcall max77693_muic_driver_init+0x0/0x10 returned 0 after 61 usecs [ 0.799832] calling exynos_adc_driver_init+0x0/0x10 @ 1 [ 0.800196] initcall exynos_adc_driver_init+0x0/0x10 returned 0 after 341 usecs [ 0.800219] calling alsa_timer_init+0x0/0x200 @ 1 [ 0.800366] initcall alsa_timer_init+0x0/0x200 returned 0 after 129 usecs [ 0.800385] calling alsa_pcm_init+0x0/0x6c @ 1 [ 0.800402] initcall alsa_pcm_init+0x0/0x6c returned 0 after 4 usecs [ 0.800419] calling snd_compress_init+0x0/0x8 @ 1 [ 0.800431] initcall snd_compress_init+0x0/0x8 returned 0 after 0 usecs [ 0.800447] calling snd_soc_init+0x0/0x11c @ 1 [ 0.800636] bus: 'platform': driver_probe_device: matched device snd-soc-dummy with driver snd-soc-dummy [ 0.800654] bus: 'platform': really_probe: probing driver snd-soc-dummy with device snd-soc-dummy [ 0.800697] driver: 'snd-soc-dummy': driver_bound: bound to device 'snd-soc-dummy' [ 0.800714] bus: 'platform': really_probe: bound device snd-soc-dummy to driver snd-soc-dummy [ 0.800818] initcall snd_soc_init+0x0/0x11c returned 0 after 349 usecs [ 0.800845] calling max98090_i2c_driver_init+0x0/0x10 @ 1 [ 0.800912] initcall max98090_i2c_driver_init+0x0/0x10 returned 0 after 51 usecs [ 0.800934] calling max98095_i2c_driver_init+0x0/0x10 @ 1 [ 0.800958] bus: 'i2c': driver_probe_device: matched device 7-0011 with driver max98095 [ 0.800979] bus: 'i2c': really_probe: probing driver max98095 with device 7-0011 [ 0.801145] driver: 'max98095': driver_bound: bound to device '7-0011' [ 0.801159] bus: 'i2c': really_probe: bound device 7-0011 to driver max98095 [ 0.801212] initcall max98095_i2c_driver_init+0x0/0x10 returned 0 after 256 usecs [ 0.801234] calling asoc_simple_card_init+0x0/0x10 @ 1 [ 0.801356] initcall asoc_simple_card_init+0x0/0x10 returned 0 after 105 usecs [ 0.801378] calling samsung_i2s_driver_init+0x0/0x10 @ 1 [ 0.801468] bus: 'platform': driver_probe_device: matched device 3830000.i2s with driver samsung-i2s [ 0.801485] bus: 'platform': really_probe: probing driver samsung-i2s with device 3830000.i2s [ 0.801739] bus: 'platform': driver_probe_device: matched device samsung-i2s-sec with driver samsung-i2s [ 0.801758] bus: 'platform': really_probe: probing driver samsung-i2s with device samsung-i2s-sec [ 0.801798] driver: 'samsung-i2s': driver_bound: bound to device 'samsung-i2s-sec' [ 0.801814] bus: 'platform': really_probe: bound device samsung-i2s-sec to driver samsung-i2s [ 0.801840] driver: 'samsung-i2s': driver_bound: bound to device '3830000.i2s' [ 0.801855] bus: 'platform': really_probe: bound device 3830000.i2s to driver samsung-i2s [ 0.801982] initcall samsung_i2s_driver_init+0x0/0x10 returned 0 after 574 usecs [ 0.802004] calling asoc_idma_driver_init+0x0/0x10 @ 1 [ 0.802078] initcall asoc_idma_driver_init+0x0/0x10 returned 0 after 59 usecs [ 0.802096] calling snow_driver_init+0x0/0x10 @ 1 [ 0.802200] bus: 'platform': driver_probe_device: matched device sound with driver snow-audio [ 0.802217] bus: 'platform': really_probe: probing driver snow-audio with device sound [ 0.825682] mmc0: MAN_BKOPS_EN bit is not set [ 0.828300] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) [ 0.829748] mmc_host mmc0: Bus speed (slot 0) = 100000000Hz (slot req 52000000Hz, actual 50000000HZ div = 1) [ 0.830247] mmc0: new DDR MMC card at address 0001 [ 0.830645] bus: 'mmc': driver_probe_device: matched device mmc0:0001 with driver mmcblk [ 0.830694] bus: 'mmc': really_probe: probing driver mmcblk with device mmc0:0001 [ 0.831127] mmcblk0: mmc0:0001 SEM16G 14.6 GiB [ 0.831432] mmcblk0boot0: mmc0:0001 SEM16G partition 1 2.00 MiB [ 0.831814] mmcblk0boot1: mmc0:0001 SEM16G partition 2 2.00 MiB [ 0.832102] mmcblk0rpmb: mmc0:0001 SEM16G partition 3 128 KiB [ 0.836941] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 [ 0.844786] driver: 'mmcblk': driver_bound: bound to device 'mmc0:0001' [ 0.844826] bus: 'mmc': really_probe: bound device mmc0:0001 to driver mmcblk [ 0.870562] max98095 7-0011: Hardware revision: C [ 0.879992] snow-audio sound: HiFi <-> 3830000.i2s mapping ok [ 0.880747] max98095 7-0011: ASoC: mux External MIC has no paths [ 0.880794] max98095 7-0011: ASoC: mux Linein Mux has no paths [ 0.883662] driver: 'snow-audio': driver_bound: bound to device 'sound' [ 0.883702] bus: 'platform': really_probe: bound device sound to driver snow-audio [ 0.883860] initcall snow_driver_init+0x0/0x10 returned 0 after 79820 usecs [ 0.883913] calling odroidx2_audio_driver_init+0x0/0x10 @ 1 [ 0.884323] initcall odroidx2_audio_driver_init+0x0/0x10 returned 0 after 361 usecs [ 0.884375] calling sock_diag_init+0x0/0x50 @ 1 [ 0.884457] initcall sock_diag_init+0x0/0x50 returned 0 after 46 usecs [ 0.884500] calling gre_offload_init+0x0/0x10 @ 1 [ 0.884533] initcall gre_offload_init+0x0/0x10 returned 0 after 1 usecs [ 0.884571] calling sysctl_ipv4_init+0x0/0x54 @ 1 [ 0.884768] initcall sysctl_ipv4_init+0x0/0x54 returned 0 after 160 usecs [ 0.884808] calling xfrm4_beet_init+0x0/0x10 @ 1 [ 0.884842] initcall xfrm4_beet_init+0x0/0x10 returned 0 after 2 usecs [ 0.884880] calling tunnel4_init+0x0/0x70 @ 1 [ 0.884911] initcall tunnel4_init+0x0/0x70 returned 0 after 1 usecs [ 0.884949] calling xfrm4_transport_init+0x0/0x10 @ 1 [ 0.884981] initcall xfrm4_transport_init+0x0/0x10 returned 0 after 1 usecs [ 0.885020] calling xfrm4_mode_tunnel_init+0x0/0x10 @ 1 [ 0.885053] initcall xfrm4_mode_tunnel_init+0x0/0x10 returned 0 after 1 usecs [ 0.885091] calling inet_diag_init+0x0/0x88 @ 1 [ 0.885128] initcall inet_diag_init+0x0/0x88 returned 0 after 6 usecs [ 0.885165] calling tcp_diag_init+0x0/0xc @ 1 [ 0.885197] initcall tcp_diag_init+0x0/0xc returned 0 after 2 usecs [ 0.885234] calling cubictcp_register+0x0/0x64 @ 1 [ 0.885267] initcall cubictcp_register+0x0/0x64 returned 0 after 2 usecs [ 0.885305] calling inet6_init+0x0/0x2c0 @ 1 [ 0.887211] NET: Registered protocol family 10 [ 0.893144] initcall inet6_init+0x0/0x2c0 returned 0 after 7619 usecs [ 0.893192] calling xfrm6_transport_init+0x0/0x10 @ 1 [ 0.893227] initcall xfrm6_transport_init+0x0/0x10 returned 0 after 1 usecs [ 0.893268] calling xfrm6_mode_tunnel_init+0x0/0x10 @ 1 [ 0.893302] initcall xfrm6_mode_tunnel_init+0x0/0x10 returned 0 after 1 usecs [ 0.893343] calling xfrm6_beet_init+0x0/0x10 @ 1 [ 0.893375] initcall xfrm6_beet_init+0x0/0x10 returned 0 after 1 usecs [ 0.893414] calling sit_init+0x0/0xc8 @ 1 [ 0.893439] sit: IPv6 over IPv4 tunneling driver [ 0.894527] initcall sit_init+0x0/0xc8 returned 0 after 1052 usecs [ 0.894570] calling packet_init+0x0/0x48 @ 1 [ 0.894600] NET: Registered protocol family 17 [ 0.894648] initcall packet_init+0x0/0x48 returned 0 after 43 usecs [ 0.894688] calling ipsec_pfkey_init+0x0/0x78 @ 1 [ 0.894731] NET: Registered protocol family 15 [ 0.894764] initcall ipsec_pfkey_init+0x0/0x78 returned 0 after 42 usecs [ 0.894987] calling init_machine_late+0x0/0x98 @ 1 [ 0.895378] initcall init_machine_late+0x0/0x98 returned 0 after 349 usecs [ 0.895422] calling swp_emulation_init+0x0/0x6c @ 1 [ 0.895465] Registering SWP/SWPB emulation handler [ 0.895500] initcall swp_emulation_init+0x0/0x6c returned 0 after 44 usecs [ 0.895544] calling bL_switcher_init+0x0/0xb8 @ 1 [ 0.895578] initcall bL_switcher_init+0x0/0xb8 returned -19 after 1 usecs [ 0.895616] calling init_oops_id+0x0/0x40 @ 1 [ 0.895657] initcall init_oops_id+0x0/0x40 returned 0 after 10 usecs [ 0.895704] calling sched_init_debug+0x0/0x3c @ 1 [ 0.895754] initcall sched_init_debug+0x0/0x3c returned 0 after 15 usecs [ 0.895800] calling pm_qos_power_init+0x0/0xb0 @ 1 [ 0.896866] initcall pm_qos_power_init+0x0/0xb0 returned 0 after 1004 usecs [ 0.896919] calling pm_debugfs_init+0x0/0x38 @ 1 [ 0.896966] initcall pm_debugfs_init+0x0/0x38 returned 0 after 12 usecs [ 0.897004] calling printk_late_init+0x0/0x5c @ 1 [ 0.897041] initcall printk_late_init+0x0/0x5c returned 0 after 6 usecs [ 0.897080] calling tk_debug_sleep_time_init+0x0/0x50 @ 1 [ 0.897124] initcall tk_debug_sleep_time_init+0x0/0x50 returned 0 after 11 usecs [ 0.897177] calling fault_around_debugfs+0x0/0x4c @ 1 [ 0.897234] initcall fault_around_debugfs+0x0/0x4c returned 0 after 23 usecs [ 0.897280] calling max_swapfiles_check+0x0/0x8 @ 1 [ 0.897313] initcall max_swapfiles_check+0x0/0x8 returned 0 after 0 usecs [ 0.897351] calling prandom_reseed+0x0/0x44 @ 1 [ 0.897410] initcall prandom_reseed+0x0/0x44 returned 0 after 25 usecs [ 0.897451] calling fb_logo_late_init+0x0/0x18 @ 1 [ 0.897483] initcall fb_logo_late_init+0x0/0x18 returned 0 after 0 usecs [ 0.897528] calling deferred_probe_initcall+0x0/0x88 @ 1 [ 0.897706] platform backlight: Retrying from deferred list [ 0.897819] bus: 'platform': driver_probe_device: matched device backlight with driver pwm-backlight [ 0.897867] bus: 'platform': really_probe: probing driver pwm-backlight with device backlight [ 0.898052] pwm-backlight backlight: GPIO lookup for consumer enable [ 0.898087] pwm-backlight backlight: using device tree for GPIO lookup [ 0.898134] of_get_named_gpiod_flags: parsed 'enable-gpios' property of node '/backlight[0]' - status (0) [ 0.898298] vcd_led: supplied by vbat-supply [ 0.900171] driver: 'pwm-backlight': driver_bound: bound to device 'backlight' [ 0.900227] bus: 'platform': really_probe: bound device backlight to driver pwm-backlight [ 0.900283] platform 145b0000.dp-controller: Retrying from deferred list [ 0.900416] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp [ 0.900462] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller [ 0.901117] platform 145b0000.dp-controller: Driver exynos-dp requests probe deferral [ 0.901165] platform 145b0000.dp-controller: Added to deferred list [ 0.901386] platform 14530000.hdmi: Retrying from deferred list [ 0.901527] bus: 'platform': driver_probe_device: matched device 14530000.hdmi with driver exynos-hdmi [ 0.901572] bus: 'platform': really_probe: probing driver exynos-hdmi with device 14530000.hdmi [ 0.902450] of_get_named_gpiod_flags: parsed 'hpd-gpio' property of node '/hdmi[0]' - status (0) [ 0.903637] video_mid_1a: supplied by vbat-supply [ 0.905765] driver: 'exynos-hdmi': driver_bound: bound to device '14530000.hdmi' [ 0.905817] bus: 'platform': really_probe: bound device 14530000.hdmi to driver exynos-hdmi [ 0.905899] platform panel: Retrying from deferred list [ 0.906062] bus: 'platform': driver_probe_device: matched device panel with driver panel-simple [ 0.906109] bus: 'platform': really_probe: probing driver panel-simple with device panel [ 0.906306] lcd_vdd: supplied by vbat-supply [ 0.907007] usb 1-1: New USB device found, idVendor=0424, idProduct=9514 [ 0.907046] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 0.907234] panel-simple panel: GPIO lookup for consumer enable [ 0.907272] panel-simple panel: using device tree for GPIO lookup [ 0.907306] of_get_named_gpiod_flags: can't parse 'enable-gpios' property of node '/panel[0]' [ 0.907351] of_get_named_gpiod_flags: can't parse 'enable-gpio' property of node '/panel[0]' [ 0.907394] panel-simple panel: using lookup tables for GPIO lookup [ 0.907427] panel-simple panel: lookup for GPIO enable failed [ 0.907558] driver: 'panel-simple': driver_bound: bound to device 'panel' [ 0.907595] bus: 'platform': really_probe: bound device panel to driver panel-simple [ 0.907651] i2c 7-0020: Retrying from deferred list [ 0.907661] bus: 'usb': driver_probe_device: matched device 1-1 with driver usb [ 0.907669] bus: 'usb': really_probe: probing driver usb with device 1-1 [ 0.907785] bus: 'i2c': driver_probe_device: matched device 7-0020 with driver nxp,ptn3460 [ 0.907831] bus: 'i2c': really_probe: probing driver nxp,ptn3460 with device 7-0020 [ 0.907981] nxp,ptn3460 7-0020: GPIO lookup for consumer powerdown [ 0.908014] nxp,ptn3460 7-0020: using device tree for GPIO lookup [ 0.908056] of_get_named_gpiod_flags: parsed 'powerdown-gpios' property of node '/i2c@12CD0000/lvds-bridge@20[0]' - status (0) [ 0.908120] nxp,ptn3460 7-0020: GPIO lookup for consumer reset [ 0.908150] nxp,ptn3460 7-0020: using device tree for GPIO lookup [ 0.908190] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/i2c@12CD0000/lvds-bridge@20[0]' - status (0) [ 0.908252] driver: 'nxp,ptn3460': driver_bound: bound to device '7-0020' [ 0.908286] bus: 'i2c': really_probe: bound device 7-0020 to driver nxp,ptn3460 [ 0.908373] platform 101e0000.rtc: Retrying from deferred list [ 0.908572] bus: 'platform': driver_probe_device: matched device 101e0000.rtc with driver s3c-rtc [ 0.908616] bus: 'platform': really_probe: probing driver s3c-rtc with device 101e0000.rtc [ 0.909091] s3c-rtc 101e0000.rtc: rtc disabled, re-enabling [ 0.909614] s3c-rtc 101e0000.rtc: rtc core: registered s3c as rtc1 [ 0.909765] driver: 's3c-rtc': driver_bound: bound to device '101e0000.rtc' [ 0.909803] bus: 'platform': really_probe: bound device 101e0000.rtc to driver s3c-rtc [ 0.909858] platform 12230000.mmc: Retrying from deferred list [ 0.910111] bus: 'platform': driver_probe_device: matched device 12230000.mmc with driver dwmmc_exynos [ 0.910156] bus: 'platform': really_probe: probing driver dwmmc_exynos with device 12230000.mmc [ 0.910775] dwmmc_exynos 12230000.mmc: IDMAC supports 32-bit address mode. [ 0.910892] dwmmc_exynos 12230000.mmc: Using internal DMA controller. [ 0.910929] dwmmc_exynos 12230000.mmc: Version ID is 241a [ 0.910983] dwmmc_exynos 12230000.mmc: DW MMC controller at irq 107,32 bit host data width,128 deep fifo [ 0.911167] dwmmc_exynos 12230000.mmc: No vmmc regulator found [ 0.911198] dwmmc_exynos 12230000.mmc: No vqmmc regulator found [ 0.911241] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer cd [ 0.911273] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup [ 0.911306] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/mmc@12230000[0]' [ 0.911352] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/mmc@12230000[0]' [ 0.911394] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup [ 0.911427] dwmmc_exynos 12230000.mmc: lookup for GPIO cd failed [ 0.911461] dwmmc_exynos 12230000.mmc: GPIO lookup for consumer wp [ 0.911492] dwmmc_exynos 12230000.mmc: using device tree for GPIO lookup [ 0.911524] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12230000[0]' [ 0.911567] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12230000[0]' [ 0.911609] dwmmc_exynos 12230000.mmc: using lookup tables for GPIO lookup [ 0.911641] dwmmc_exynos 12230000.mmc: lookup for GPIO wp failed [ 0.911898] platform mmc3_pwrseq: GPIO lookup for consumer reset [ 0.911930] platform mmc3_pwrseq: using device tree for GPIO lookup [ 0.911970] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/mmc3_pwrseq[0]' - status (0) [ 0.912030] platform mmc3_pwrseq: GPIO lookup for consumer reset [ 0.912059] platform mmc3_pwrseq: using device tree for GPIO lookup [ 0.912102] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/mmc3_pwrseq[1]' - status (0) [ 0.912160] dwmmc_exynos 12230000.mmc: allocated mmc-pwrseq [ 0.924495] bus: 'usb': driver_probe_device: matched device 1-1:1.0 with driver hub [ 0.924546] bus: 'usb': really_probe: probing driver hub with device 1-1:1.0 [ 0.924638] hub 1-1:1.0: USB hub found [ 0.924777] hub 1-1:1.0: 5 ports detected [ 0.941824] dwmmc_exynos 12230000.mmc: 1 slots initialized [ 0.941859] driver: 'dwmmc_exynos': driver_bound: bound to device '12230000.mmc' [ 0.941905] bus: 'platform': really_probe: bound device 12230000.mmc to driver dwmmc_exynos [ 0.941961] platform 145b0000.dp-controller: Retrying from deferred list [ 0.942096] bus: 'platform': driver_probe_device: matched device 145b0000.dp-controller with driver exynos-dp [ 0.942142] bus: 'platform': really_probe: probing driver exynos-dp with device 145b0000.dp-controller [ 0.944121] exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops) [ 0.944279] of_get_named_gpiod_flags: parsed 'samsung,hpd-gpio' property of node '/dp-controller@145B0000[0]' - status (0) [ 0.945111] exynos-drm exynos-drm: bound 145b0000.dp-controller (ops exynos_dp_ops) [ 0.945297] exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops) [ 0.945776] exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_component_ops) [ 0.945820] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 0.945849] [drm] No driver support for vblank timestamp query. [ 0.957614] driver: 'hub': driver_bound: bound to device '1-1:1.0' [ 0.957657] bus: 'usb': really_probe: bound device 1-1:1.0 to driver hub [ 0.957699] driver: 'usb': driver_bound: bound to device '1-1' [ 0.957735] bus: 'usb': really_probe: bound device 1-1 to driver usb [ 0.998673] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) [ 1.005565] mmc2: new high speed SDIO card at address 0001 [ 1.005772] bus: 'mmc': driver_probe_device: matched device mmc2:0001 with driver mmcblk [ 1.005819] bus: 'mmc': really_probe: probing driver mmcblk with device mmc2:0001 [ 1.005927] mmcblk: probe of mmc2:0001 rejects match -19 [ 1.164353] exynos-dp 145b0000.dp-controller: EDID data does not include any extensions. [ 1.173729] exynos-dp 145b0000.dp-controller: Link Training Clock Recovery success [ 1.175695] exynos-dp 145b0000.dp-controller: Link Training success! [ 1.241824] usb 1-1.1: new high-speed USB device number 3 using xhci-hcd [ 1.282317] exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok [ 1.282333] exynos-dp 145b0000.dp-controller: unable to config video [ 1.306078] Console: switching to colour frame buffer device 195x54 [ 1.339302] exynos-drm exynos-drm: fb0: frame buffer device [ 1.342018] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [ 1.342191] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 1.343034] bus: 'usb': driver_probe_device: matched device 1-1.1 with driver usb [ 1.343214] bus: 'usb': really_probe: probing driver usb with device 1-1.1 [ 1.351767] [drm] Initialized exynos 1.0.0 20110530 on minor 0 [ 1.351924] driver: 'exynos-dp': driver_bound: bound to device '145b0000.dp-controller' [ 1.352113] bus: 'platform': really_probe: bound device 145b0000.dp-controller to driver exynos-dp [ 1.352373] initcall deferred_probe_initcall+0x0/0x88 returned 0 after 444139 usecs [ 1.352579] calling genpd_poweroff_unused+0x0/0x10 @ 1 [ 1.352731] initcall genpd_poweroff_unused+0x0/0x10 returned 0 after 17 usecs [ 1.352905] calling gpio_keys_init+0x0/0x10 @ 1 [ 1.353304] bus: 'platform': driver_probe_device: matched device gpio-keys with driver gpio-keys [ 1.353507] bus: 'platform': really_probe: probing driver gpio-keys with device gpio-keys [ 1.353969] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/power[0]' - status (0) [ 1.354210] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/lid-switch[0]' - status (0) [ 1.354489] gpio-143 (Power): gpiod_set_debounce: missing set() or set_debounce() operations [ 1.354806] gpio-161 (Lid): gpiod_set_debounce: missing set() or set_debounce() operations [ 1.362148] input: gpio-keys as /devices/platform/gpio-keys/input/input2 [ 1.369136] driver: 'gpio-keys': driver_bound: bound to device 'gpio-keys' [ 1.375754] bus: 'platform': really_probe: bound device gpio-keys to driver gpio-keys [ 1.382625] bus: 'usb': driver_probe_device: matched device 1-1.1:1.0 with driver smsc95xx [ 1.389262] initcall gpio_keys_init+0x0/0x10 returned 0 after 35386 usecs [ 1.395759] bus: 'usb': really_probe: probing driver smsc95xx with device 1-1.1:1.0 [ 1.402265] calling rtc_hctosys+0x0/0xf4 @ 1 [ 1.408772] smsc95xx v1.0.4 [ 1.437322] max77686-rtc max77686-rtc: setting system clock to 2000-01-01 01:57:26 UTC (946691846) [ 1.443937] initcall rtc_hctosys+0x0/0xf4 returned 0 after 28140 usecs [ 1.451588] calling of_fdt_raw_init+0x0/0x74 @ 1 [ 1.458493] initcall of_fdt_raw_init+0x0/0x74 returned 0 after 434 usecs [ 1.461689] calling clk_debug_init+0x0/0x138 @ 1 [ 1.477872] initcall clk_debug_init+0x0/0x138 returned 0 after 12672 usecs [ 1.481044] calling register_sk_filter_ops+0x0/0x8 @ 1 [ 1.484255] initcall register_sk_filter_ops+0x0/0x8 returned 0 after 0 usecs [ 1.487492] calling tcp_congestion_default+0x0/0xc @ 1 [ 1.490691] initcall tcp_congestion_default+0x0/0xc returned 0 after 1 usecs [ 1.493899] calling ip_auto_config+0x0/0x10b0 @ 1 [ 1.514042] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.2.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:00:a7 [ 1.517308] driver: 'smsc95xx': driver_bound: bound to device '1-1.1:1.0' [ 1.520535] bus: 'usb': really_probe: bound device 1-1.1:1.0 to driver smsc95xx [ 1.523776] driver: 'usb': driver_bound: bound to device '1-1.1' [ 1.527000] bus: 'usb': really_probe: bound device 1-1.1 to driver usb [ 2.550550] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup [ 2.567181] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 4.068149] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 [ 4.084229] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 4.087043] Sending DHCP requests ., OK [ 4.126806] IP-Config: Got DHCP answer from 10.42.0.1, my address is 10.42.0.61 [ 4.135375] IP-Config: Complete: [ 4.143386] device=eth0, hwaddr=94:eb:2c:00:00:a7, ipaddr=10.42.0.61, mask=255.255.255.0, gw=10.42.0.1 [ 4.151607] host=10.42.0.61, domain=, nis-domain=(none) [ 4.159839] bootserver=10.42.0.1, rootserver=10.42.0.1, rootpath= [ 4.160031] nameserver0=10.42.0.1 [ 4.176184] initcall ip_auto_config+0x0/0x10b0 returned 0 after 2616292 usecs [ 4.184459] calling regulator_init_complete+0x0/0x48 @ 1 [ 4.192736] TPS65090_RAILSDCDC1: disabling [ 4.200927] TPS65090_RAILSDCDC2: disabling [ 4.208995] TPS65090_RAILSDCDC3: disabling [ 4.217785] TPS65090_RAILSLDO1: disabling [ 4.225673] TPS65090_RAILSLDO2: disabling [ 4.233409] initcall regulator_init_complete+0x0/0x48 returned 0 after 39771 usecs [ 4.241321] calling clk_disable_unused+0x0/0x138 @ 1 [ 4.251036] initcall clk_disable_unused+0x0/0x138 returned 0 after 1869 usecs [ 4.253336] calling alsa_sound_last_init+0x0/0x6c @ 1 [ 4.255606] ALSA device list: [ 4.257859] #0: Snow-I2S-MAX98095 [ 4.260076] initcall alsa_sound_last_init+0x0/0x6c returned 0 after 4360 usecs [ 4.262337] calling init_default_flow_dissectors+0x0/0x3c @ 1 [ 4.264559] initcall init_default_flow_dissectors+0x0/0x3c returned 0 after 0 usecs [ 4.280283] VFS: Mounted root (nfs filesystem) on device 0:15. [ 4.283182] devtmpfs: mounted [ 4.285506] Freeing unused kernel memory: 428K (c0797000 - c0802000) [ 4.612617] random: systemd urandom read with 60 bits of entropy available [ 4.620773] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR) [ 4.624141] systemd[1]: Detected architecture 'arm'. [ 4.669694] systemd[1]: Failed to insert module 'autofs4' [ 4.675496] systemd[1]: Set hostname to <singularity>. [ 5.336213] systemd[1]: Cannot add dependency job for unit fstrim.timer, ignoring: Unit fstrim.timer failed to load: No such file or directory. [ 5.340944] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. [ 5.347662] systemd[1]: Starting Forward Password Requests to Wall Directory Watch. [ 5.352548] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 5.357117] systemd[1]: Starting Remote File Systems (Pre). [ 5.366583] systemd[1]: Reached target Remote File Systems (Pre). [ 5.371155] systemd[1]: Starting Encrypted Volumes. [ 5.380536] systemd[1]: Reached target Encrypted Volumes. [ 5.385193] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 5.389753] systemd[1]: Starting Swap. [ 5.398864] systemd[1]: Reached target Swap. [ 5.403226] systemd[1]: Starting Root Slice. [ 5.412250] systemd[1]: Created slice Root Slice. [ 5.416473] systemd[1]: Starting Delayed Shutdown Socket. [ 5.425353] systemd[1]: Listening on Delayed Shutdown Socket. [ 5.429611] systemd[1]: Starting /dev/initctl Compatibility Named Pipe. [ 5.439356] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. [ 5.443581] systemd[1]: Starting Journal Socket (/dev/log). [ 5.453105] systemd[1]: Listening on Journal Socket (/dev/log). [ 5.457315] systemd[1]: Starting udev Control Socket. [ 5.466584] systemd[1]: Listening on udev Control Socket. [ 5.470751] systemd[1]: Starting udev Kernel Socket. [ 5.478879] systemd[1]: Listening on udev Kernel Socket. [ 5.480820] systemd[1]: Starting User and Session Slice. [ 5.484988] systemd[1]: Created slice User and Session Slice. [ 5.486955] systemd[1]: Starting Journal Socket. [ 5.491019] systemd[1]: Listening on Journal Socket. [ 5.492991] systemd[1]: Starting System Slice. [ 5.497088] systemd[1]: Created slice System Slice. [ 5.503932] systemd[1]: Started Set Up Additional Binary Formats. [ 5.505876] systemd[1]: Mounted POSIX Message Queue File System. [ 5.507955] systemd[1]: Mounting Debug File System... [ 5.535382] systemd[1]: Starting Load Kernel Modules... [ 5.541341] systemd[1]: Starting Create list of required static device nodes for the current kernel... [ 5.546898] systemd[1]: Starting udev Coldplug all Devices... [ 5.553220] systemd[1]: Mounted Huge Pages File System. [ 5.555445] systemd[1]: Starting system-getty.slice. [ 5.560549] systemd[1]: Created slice system-getty.slice. [ 5.562837] systemd[1]: Starting Journal Service... [ 5.584166] systemd[1]: Started Journal Service. [ 5.863752] systemd-udevd[1824]: starting version 215 [ 6.460842] random: nonblocking pool is initialized [ 7.142323] calling mwifiex_init_module+0x0/0x10 [mwifiex] @ 2870 [ 7.144261] initcall mwifiex_init_module+0x0/0x10 [mwifiex] returned 0 after 11 usecs [ 7.194574] calling mwifiex_sdio_init_module+0x0/0x54 [mwifiex_sdio] @ 2870 [ 7.198388] bus: 'sdio': driver_probe_device: matched device mmc2:0001:1 with driver mwifiex_sdio [ 7.203684] bus: 'sdio': really_probe: probing driver mwifiex_sdio with device mmc2:0001:1 [ 7.228437] mwifiex: rx work enabled, cpus 2 [ 7.253138] driver: 'mwifiex_sdio': driver_bound: bound to device 'mmc2:0001:1' [ 7.255160] bus: 'sdio': really_probe: bound device mmc2:0001:1 to driver mwifiex_sdio [ 7.265718] initcall mwifiex_sdio_init_module+0x0/0x54 [mwifiex_sdio] returned 0 after 65757 usecs [ 7.956437] mwifiex_sdio mmc2:0001:1: info: FW download over, size 458108 bytes [ 8.271818] mwifiex_sdio mmc2:0001:1: WLAN FW is active [ 8.667367] mwifiex_sdio mmc2:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (14.66.11.p151) [ 8.672804] mwifiex_sdio mmc2:0001:1: driver_version = mwifiex 1.0 (14.66.11.p151) [ 11.532582] systemd-journald[1590]: Received request to flush runtime journal from PID 1 [ 18.478513] systemd-journald[1590]: Failed to read ACL on /var/log/journal/becefd5da725413ebc34ab1a301f3fc7/user-1001.journal, ignoring: Operation not supported
On 10/22/2015 11:53 AM, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >> <oops, sent too early...> >> >> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote: > On 10/22/2015 11:53 AM, Frank Rowand wrote: >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: >>> <oops, sent too early...> >>> >>> 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 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.) Exactly. That was a large part of my accepting it. > 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. :-) That would be a challenge to measure since it is distributed. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote: > On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird <tim.bird@sonymobile.com> wrote: > > On 10/22/2015 11:53 AM, Frank Rowand wrote: > >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > >>> <oops, sent too early...> > >>> > >>> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 22, 2015 at 8:53 PM, Frank Rowand <frowand.list@gmail.com> 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 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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?).
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 = <&phandle>;" to nodes when we know they are needed for our board? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <broonie@kernel.org> 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).
Quoting Rafael J. Wysocki (2015-10-25 06:54:39) > On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 26 October 2015 at 11:51, Michael Turquette <mturquette@baylibre.com> wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> 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 majordomo@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette <mturquette@baylibre.com> wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@kernel.org> 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html