Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1250220 > unrolled thread
| Started by | Mark Brown <broonie@kernel.org> |
|---|---|
| First post | 2015-10-18 21:40 +0200 |
| Last post | 2015-10-24 20:00 +0200 |
| Articles | 20 on this page of 82 — 19 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-18 21:40 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-18 21:40 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-18 22:00 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-19 11:50 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 12:00 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-19 13:10 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-19 14:40 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-19 14:50 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-19 17:00 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-19 17:40 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 17:50 +0200
Re: [GIT PULL] On-demand device probing Uwe Kleine-König <u.kleine-koenig@pengutronix.de> - 2015-10-19 20:30 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 20:50 +0200
Re: [GIT PULL] On-demand device probing Alexandre Courbot <gnurou@gmail.com> - 2015-10-20 01:50 +0200
Re: gpiod API considerations [Was: [GIT PULL] On-demand device probing] Uwe Kleine-König <u.kleine-koenig@pengutronix.de> - 2015-10-20 09:20 +0200
Re: [GIT PULL] On-demand device probing David Woodhouse <dwmw2@infradead.org> - 2015-10-20 13:20 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-19 18:00 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-19 23:20 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh@kernel.org> - 2015-10-20 01:00 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-20 09:30 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh@kernel.org> - 2015-10-20 16:20 +0200
Re: [GIT PULL] On-demand device probing Alan Stern <stern@rowland.harvard.edu> - 2015-10-20 16:50 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-20 17:40 +0200
Re: [GIT PULL] On-demand device probing Alan Stern <stern@rowland.harvard.edu> - 2015-10-20 18:10 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-20 18:30 +0200
Re: [GIT PULL] On-demand device probing Alan Stern <stern@rowland.harvard.edu> - 2015-10-20 19:20 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-20 21:40 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-21 01:10 +0200
Re: [GIT PULL] On-demand device probing Jean-Francois Moine <moinejf@free.fr> - 2015-10-21 08:20 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-22 02:30 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-22 11:20 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-27 05:40 +0100
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-21 01:10 +0200
Re: [GIT PULL] On-demand device probing Geert Uytterhoeven <geert@linux-m68k.org> - 2015-10-21 11:00 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-22 01:20 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-19 18:10 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-19 14:40 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 15:20 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-19 16:20 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 16:40 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-19 17:10 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 17:40 +0200
Re: [GIT PULL] On-demand device probing Geert Uytterhoeven <geert@linux-m68k.org> - 2015-10-19 18:30 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-19 18:50 +0200
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-20 17:50 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-21 06:00 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 10:20 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-21 17:40 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-21 19:00 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 19:30 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-21 20:20 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 20:30 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-22 17:20 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-21 20:10 +0200
Re: Alternative approach to solve the deferred probe Grygorii Strashko <grygorii.strashko@ti.com> - 2015-10-21 20:40 +0200
Re: Alternative approach to solve the deferred probe Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-21 22:40 +0200
Re: Alternative approach to solve the deferred probe Frank Rowand <frowand.list@gmail.com> - 2015-10-22 02:10 +0200
Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing) Mark Brown <broonie@kernel.org> - 2015-10-23 01:40 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-21 18:10 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-21 18:30 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-21 20:30 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-21 23:10 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-21 23:20 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-22 00:00 +0200
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-22 11:10 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-22 16:40 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-22 16:50 +0200
Re: [GIT PULL] On-demand device probing Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-22 17:10 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-23 01:40 +0200
Re: [GIT PULL] On-demand device probing Frank Rowand <frowand.list@gmail.com> - 2015-10-22 21:00 +0200
Re: [GIT PULL] On-demand device probing Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-10-22 21:30 +0200
Re: [GIT PULL] On-demand device probing Tim Bird <tim.bird@sonymobile.com> - 2015-10-23 17:50 +0200
Re: [GIT PULL] On-demand device probing Rob Herring <robh+dt@kernel.org> - 2015-10-23 18:40 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-10-24 15:50 +0200
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-25 00:10 +0200
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rafael@kernel.org> - 2015-10-25 15:00 +0100
Re: [GIT PULL] On-demand device probing Mark Brown <broonie@kernel.org> - 2015-10-26 02:20 +0100
Re: [GIT PULL] On-demand device probing Michael Turquette <mturquette@baylibre.com> - 2015-10-26 12:00 +0100
Re: [GIT PULL] On-demand device probing Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-10-26 14:00 +0100
Re: [GIT PULL] On-demand device probing "Rafael J. Wysocki" <rafael@kernel.org> - 2015-10-27 00:40 +0100
Re: [GIT PULL] On-demand device probing "Andrew F. Davis" <afd@ti.com> - 2015-10-25 20:50 +0100
Re: [GIT PULL] On-demand device probing Geert Uytterhoeven <geert@linux-m68k.org> - 2015-10-24 20:00 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2015-10-20 16:20 +0200 |
| Message-ID | <qlFVE-69D-1@gated-at.bofh.it> |
| In reply to | #1251336 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-10-20 16:50 +0200 |
| Message-ID | <qlGoG-6IS-21@gated-at.bofh.it> |
| In reply to | #1251729 |
On Tue, 20 Oct 2015, Rob Herring wrote: > > The probe ordering is not the entire picture, though. > > > > Even if you get the probe ordering right, the problem is going to show up in > > multiple other places: system suspend/resume, runtime PM, system shutdown, > > unbinding of drivers. In all of those cases it is necessary to handle things > > in a specific order if there is a dependency. > > My understanding was with deferred probe that it also solves suspend > ordering problems because things are suspended in reverse order of > probing. Devices are suspended in reverse order of _registration_. Not of probing. Furthermore, that applies only to devices that use synchronous suspend. Async suspend is becoming common, and there the only restrictions are parent-child relations plus whatever explicit requirements that drivers impose by calling device_pm_wait_for_dev(). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
[toc] | [prev] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-10-20 17:40 +0200 |
| Message-ID | <qlHb5-7U3-23@gated-at.bofh.it> |
| In reply to | #1251762 |
[Multipart message — attachments visible in raw view] — view raw
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...
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-10-20 18:10 +0200 |
| Message-ID | <qlHE6-fg-21@gated-at.bofh.it> |
| In reply to | #1251813 |
On Tue, 20 Oct 2015, Mark Brown wrote: > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > Furthermore, that applies only to devices that use synchronous suspend. > > Async suspend is becoming common, and there the only restrictions are > > parent-child relations plus whatever explicit requirements that drivers > > impose by calling device_pm_wait_for_dev(). > > Hrm, this is the first I'd noticed that feature though I see the initial > commit dates from January. Async suspend and device_pm_wait_for_dev() were added in January 2010, not 2015! > It looks like most of the users are PCs at > the minute but we should be using it more widely for embedded things, > there's definitely some cases I'm aware of where it will allow us to > remove some open coding. > > It does seem like we want to be feeding dependency information we > discover for probing way into the suspend dependencies... Rafael has been thinking about a way to do this systematically. Nothing concrete has emerged yet. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
[toc] | [prev] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-10-20 18:30 +0200 |
| Message-ID | <qlHXt-Cg-29@gated-at.bofh.it> |
| In reply to | #1251841 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Date | 2015-10-20 19:20 +0200 |
| Message-ID | <qlIJQ-1Ol-1@gated-at.bofh.it> |
| In reply to | #1251861 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-10-20 21:40 +0200 |
| Message-ID | <qlKVk-4Vm-3@gated-at.bofh.it> |
| In reply to | #1251898 |
[Multipart message — attachments visible in raw view] — view raw
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.
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-10-21 01:10 +0200 |
| Message-ID | <qlOcy-1rd-35@gated-at.bofh.it> |
| In reply to | #1251984 |
On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote: > > --7fVr/IRGAG9sAW4J > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote: > > On Tue, 20 Oct 2015, Tomeu Vizoso wrote: > > > > This iteration of the series would make this quite easy, as > > > dependencies are calculated before probes are attempted: > > > > https://lkml.org/lkml/2015/6/17/311 > > > But what Rafael is proposing is quite general; it would apply to _all_ > > dependencies as opposed to just those present in DT drivers or those=20 > > affecting platform_devices. > > We'll still need most of the DT bits that are there at the minute (the > ones strewn around the subsystems) AFAICT since it's at the point where > we parse the DT and work out what the dependencies are which we probably > want to do prior to getting the drivers up and will be different for > ACPI. I think the level of DT dependency here looks a lot larger than > it actually is due to the fact that a lot of what's being modified is DT > parsing code. Right, something will have to register the dependency, or a "link" between devices, with the core once we find out that the dependency is there. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
[toc] | [prev] | [next] | [standalone]
| From | Jean-Francois Moine <moinejf@free.fr> |
|---|---|
| Date | 2015-10-21 08:20 +0200 |
| Message-ID | <qlUUG-2TR-5@gated-at.bofh.it> |
| In reply to | #1252354 |
Sorry to enter this thread a bit late. About the number of probe deferred messages, I proposed a simple patch to reduce them: https://lkml.org/lkml/2013/8/20/218 I was wondering how many messages this patch could save... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-10-22 02:30 +0200 |
| Message-ID | <qmbVw-2oP-1@gated-at.bofh.it> |
| In reply to | #1251861 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-10-22 11:20 +0200 |
| Message-ID | <qmkcr-6lH-49@gated-at.bofh.it> |
| In reply to | #1253362 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-10-27 05:40 +0100 |
| Message-ID | <qo4db-Gp-7@gated-at.bofh.it> |
| In reply to | #1251841 |
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote: > On Tue, 20 Oct 2015, Mark Brown wrote: > > > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > > > > > Furthermore, that applies only to devices that use synchronous suspend. > > > Async suspend is becoming common, and there the only restrictions are > > > parent-child relations plus whatever explicit requirements that drivers > > > impose by calling device_pm_wait_for_dev(). > > > > Hrm, this is the first I'd noticed that feature though I see the initial > > commit dates from January. > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > not 2015! > > > It looks like most of the users are PCs at > > the minute but we should be using it more widely for embedded things, > > there's definitely some cases I'm aware of where it will allow us to > > remove some open coding. > > > > It does seem like we want to be feeding dependency information we > > discover for probing way into the suspend dependencies... > > Rafael has been thinking about a way to do this systematically. > Nothing concrete has emerged yet. Well, good point. :-) I've been kind of struggling with finding time to work on the patches lately and some aspects of the design are still not finalized. It seems, though, that it can be beneficial to discuss the approach in general, so let me start a new thread for that. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to 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/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-10-21 01:10 +0200 |
| Message-ID | <qlOcx-1rd-1@gated-at.bofh.it> |
| In reply to | #1251729 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Geert Uytterhoeven <geert@linux-m68k.org> |
|---|---|
| Date | 2015-10-21 11:00 +0200 |
| Message-ID | <qlXpx-6nw-23@gated-at.bofh.it> |
| In reply to | #1252349 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| Date | 2015-10-22 01:20 +0200 |
| Message-ID | <qmaPM-R6-15@gated-at.bofh.it> |
| In reply to | #1252581 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Mark Brown <broonie@kernel.org> |
|---|---|
| Date | 2015-10-19 18:10 +0200 |
| Message-ID | <qllay-Yc-31@gated-at.bofh.it> |
| In reply to | #1250853 |
[Multipart message — attachments visible in raw view] — view raw
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.
[toc] | [prev] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-10-19 14:40 +0200 |
| Message-ID | <qlhTk-4sc-29@gated-at.bofh.it> |
| In reply to | #1250225 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-10-19 15:20 +0200 |
| Message-ID | <qliw2-5t5-15@gated-at.bofh.it> |
| In reply to | #1250617 |
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. -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Tomeu Vizoso <tomeu.vizoso@collabora.com> |
|---|---|
| Date | 2015-10-19 16:20 +0200 |
| Message-ID | <qljs7-6P9-27@gated-at.bofh.it> |
| In reply to | #1250671 |
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 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/
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@arm.linux.org.uk> |
|---|---|
| Date | 2015-10-19 16:40 +0200 |
| Message-ID | <qljLt-7dl-29@gated-at.bofh.it> |
| In reply to | #1250742 |
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. -- 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/
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | linux.kernel
csiph-web