Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 28.08.2014 11:23, schrieb Catalin Marinas:
On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote:
And I wonder how the ACPI world solves that problem. My guess would be
hardcoded stuff in the firmware-blob (BIOS), just like it happened with
board files, but I've never seen BIOS code and my knowledge about ACPI
is almost zero. ;)
ACPI doesn't even attempt to solve such problems at the OS level. SoCs
aimed at ACPI should have simple hardware configuration (from a Linux
perspective) initialised by firmware (e.g. clocks) and devices living on
a standard bus like PCIe. If a SoC requires specific low-level code to
initialise the hardware in a specific order (other than architected
peripherals like GIC, timers; e.g. MFD devices), we should deem it
unsuitable for ACPI.
ACPI should only be used by vendors who know exactly why they need and
how to implement it properly and not just because the marketing
department told them to (it would also be nice if the Linux kernel
community was informed about such reasons).
Hmm, Jon Masters from Red Hat sounds too like UEFI/ACPI is the way to go.
But maybe he's right and hiding ugly code in proprietary/binary firmware
blobs where no one can see and criticize it is really the way to go.
Personally I think it's a way back to the past ("when everything was
better", at least that is what most human brains do like to suggest) and
just a dream. And I don't believe that the stuff which was and is hidden
away always just works and doesn't need fixes (one can't do themself).
In my humble opinion that's a nice but wrong myth and doesn't take into
consideration that HW (and SW) gets more and more complicated too (and
thus more faulty).
And even the biggest companies already have problems to produce stuff
which just works (they just employ humans too), not to speak from
smaller board vendors. So it's much better to keep the source as visible
as possible to as much people as possible (in the OS) and not to rely on
some binary blob as most BIOSes are.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote: > Am 27.08.2014 18:37, schrieb Stephen Warren: > > Of course, there are probably cases where we could/should add some more > > phandles/... and likewise cases where we shouldn't. That's why detailed > > research is needed. > > Just because I'm curious, I wonder how this research does or shoud look > like. > > Defered probes did come to light with 3.4, that was more than 2 years > ago. Ok, most people (like me) just noticed it during the last months > when they switched to DT and have run into a problem (the deferred probe > mechanism is an error-message killer), but some must have seen it > already 2 years ago. > > And I wonder how the ACPI world solves that problem. My guess would be > hardcoded stuff in the firmware-blob (BIOS), just like it happened with > board files, but I've never seen BIOS code and my knowledge about ACPI > is almost zero. ;) ACPI doesn't even attempt to solve such problems at the OS level. SoCs aimed at ACPI should have simple hardware configuration (from a Linux perspective) initialised by firmware (e.g. clocks) and devices living on a standard bus like PCIe. If a SoC requires specific low-level code to initialise the hardware in a specific order (other than architected peripherals like GIC, timers; e.g. MFD devices), we should deem it unsuitable for ACPI. ACPI should only be used by vendors who know exactly why they need and how to implement it properly and not just because the marketing department told them to (it would also be nice if the Linux kernel community was informed about such reasons). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 27.08.2014 18:37, schrieb Stephen Warren: Of course, there are probably cases where we could/should add some more phandles/... and likewise cases where we shouldn't. That's why detailed research is needed. Just because I'm curious, I wonder how this research does or shoud look like. Defered probes did come to light with 3.4, that was more than 2 years ago. Ok, most people (like me) just noticed it during the last months when they switched to DT and have run into a problem (the deferred probe mechanism is an error-message killer), but some must have seen it already 2 years ago. And I wonder how the ACPI world solves that problem. My guess would be hardcoded stuff in the firmware-blob (BIOS), just like it happened with board files, but I've never seen BIOS code and my knowledge about ACPI is almost zero. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 27.08.2014 19:52, schrieb Catalin Marinas: Irrespective though, a new kernel needs to work against an old DT, I fully agree. But we shouldn't really extend the "old DT" statement to a new ARMv8 SoC ;). Or any new v7 SoC. And even poor users of current ARM HW do want use their HW. And they don't care if they have to change the DT if they finally are able to use their board, which happens seldom enough. (I'm not speaking about companies which are able to spend many man-years to fix one kernel version for use with one specific HW). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Wed, Aug 27, 2014 at 05:37:58PM +0100, Stephen Warren wrote: > On 08/27/2014 10:30 AM, Alexander Holler wrote: > > Am 27.08.2014 18:22, schrieb Stephen Warren: > >> On 08/27/2014 08:44 AM, Catalin Marinas wrote: > > > >>> It's not just optimisation but an important feature for new arm64 SoCs. > >>> Given some Tegra discussions recently, in many cases the machine_desc > >>> use on arm is primarily to initialise devices in the right order. If we > >>> can solve this in a more deterministic way (other than deferred > >>> probing), we avoid the need for a dedicated SoC platform driver (or > >>> machine_desc) or workarounds like different initcall levels and explicit > >>> DT parsing. > >> > >> A lot of the ordering is SW driver dependencies. I'm not sure how much > >> of that can accurately be claimed as HW dependencies. As such, I'm not > >> sure that putting dependencies into DT would be a good idea; it doesn't > >> feel like HW data, and might well change if we restructure SW. It'd need > >> some detailed research though. > > > > Almost every phandle is a dependency, so the DT is already full with them. > > That's true, but not entirely relevant. > > phandles in DT should only be present where there's an obvious HW > dependency. It's obvious that, for example, there's a real HW dependency > between an IRQ controller and a device that has an IRQ signal fed into > the IRQ controller. It makes perfect sense to represent that as a > phandle (+args). Other examples are power controllers or some MFD device (as we have on vexpress). For these we normally have phandles. > However, most of the ordering imposed by the Tegra machine descriptor > callbacks is nothing to do with this. It's more that the SW driver for > component X needs some low level data (e.g. SKU/fuse information) before > it can run. However, there's no real HW dependency between the HW > component X and the fuse module. As such, it doesn't make sense to > represent such a dependency in DT, using a phandle or by any other means. But isn't fuse some piece of hardware? We don't have a model for it, so I guess you just present it as a library that accesses the hardware. Anyway, in such case something like Pawel's SoC driver proposal would work. Now if anything inside the SoC bus (I have to re-read, I don't fully remember the details) is probed after the SoC driver, you could even initialise your SoC at device_initcall() level. > Irrespective though, a new kernel needs to work against an old DT, I fully agree. But we shouldn't really extend the "old DT" statement to a new ARMv8 SoC ;). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 27.08.2014 18:37, schrieb Stephen Warren: On 08/27/2014 10:30 AM, Alexander Holler wrote: Am 27.08.2014 18:22, schrieb Stephen Warren: On 08/27/2014 08:44 AM, Catalin Marinas wrote: It's not just optimisation but an important feature for new arm64 SoCs. Given some Tegra discussions recently, in many cases the machine_desc use on arm is primarily to initialise devices in the right order. If we can solve this in a more deterministic way (other than deferred probing), we avoid the need for a dedicated SoC platform driver (or machine_desc) or workarounds like different initcall levels and explicit DT parsing. A lot of the ordering is SW driver dependencies. I'm not sure how much of that can accurately be claimed as HW dependencies. As such, I'm not sure that putting dependencies into DT would be a good idea; it doesn't feel like HW data, and might well change if we restructure SW. It'd need some detailed research though. Almost every phandle is a dependency, so the DT is already full with them. That's true, but not entirely relevant. phandles in DT should only be present where there's an obvious HW dependency. It's obvious that, for example, there's a real HW dependency between an IRQ controller and a device that has an IRQ signal fed into the IRQ controller. It makes perfect sense to represent that as a phandle (+args). However, most of the ordering imposed by the Tegra machine descriptor callbacks is nothing to do with this. It's more that the SW driver for component X needs some low level data (e.g. SKU/fuse information) before it can run. However, there's no real HW dependency between the HW component X and the fuse module. As such, it doesn't make sense to represent such a dependency in DT, using a phandle or by any other means. Of course, there are probably cases where we could/should add some more phandles/... and likewise cases where we shouldn't. That's why detailed research is needed. Irrespective though, a new kernel needs to work against an old DT, so always needs to work without any (of these new) dependencies being represented in DT, since they aren't represented there today. So, I think pushing the issue into DT is a non-starter either way, unless we accept yet another ABI-breaking change, in which case we should just give up on any claims of ABI and make everyone's lives simpler. If I hear research, my response is usually "how many years"? Fact is that there are already a lot of usable dependencies in the DT, they just didn't find their way into the kernel and weren't used. And I think it doesn't help much to make the picture more complicated than it already is. Solve one step by another and not try to solve everything at once. So first enable the kernel to use dependencies at all. I've shown that it doesn't need magic to do so. Afterwards you can extend or change the existing solution. It's not always the best approach, but for complicated things it often doesn't make sense trying to solve everything at first. Of course, my approach isn't perfect, but at least it is something people can already use to play with. Ok, the way how my patches do handle devices (not drivers) might be completely wrong, but that's just because I've never got in contact with the device-model before, it always just worked. So I haven't spend any time to look into that before and I didn't spend much time to look into that for my patches (I just discoverd that device-handling by drivers looks sometimes awkward). I was happy with what I've achieved in the short time I've spend, and therfor posted the patches to give other people an easy possibility to try the stuff themself. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On 08/27/2014 10:30 AM, Alexander Holler wrote: Am 27.08.2014 18:22, schrieb Stephen Warren: On 08/27/2014 08:44 AM, Catalin Marinas wrote: It's not just optimisation but an important feature for new arm64 SoCs. Given some Tegra discussions recently, in many cases the machine_desc use on arm is primarily to initialise devices in the right order. If we can solve this in a more deterministic way (other than deferred probing), we avoid the need for a dedicated SoC platform driver (or machine_desc) or workarounds like different initcall levels and explicit DT parsing. A lot of the ordering is SW driver dependencies. I'm not sure how much of that can accurately be claimed as HW dependencies. As such, I'm not sure that putting dependencies into DT would be a good idea; it doesn't feel like HW data, and might well change if we restructure SW. It'd need some detailed research though. Almost every phandle is a dependency, so the DT is already full with them. That's true, but not entirely relevant. phandles in DT should only be present where there's an obvious HW dependency. It's obvious that, for example, there's a real HW dependency between an IRQ controller and a device that has an IRQ signal fed into the IRQ controller. It makes perfect sense to represent that as a phandle (+args). However, most of the ordering imposed by the Tegra machine descriptor callbacks is nothing to do with this. It's more that the SW driver for component X needs some low level data (e.g. SKU/fuse information) before it can run. However, there's no real HW dependency between the HW component X and the fuse module. As such, it doesn't make sense to represent such a dependency in DT, using a phandle or by any other means. Of course, there are probably cases where we could/should add some more phandles/... and likewise cases where we shouldn't. That's why detailed research is needed. Irrespective though, a new kernel needs to work against an old DT, so always needs to work without any (of these new) dependencies being represented in DT, since they aren't represented there today. So, I think pushing the issue into DT is a non-starter either way, unless we accept yet another ABI-breaking change, in which case we should just give up on any claims of ABI and make everyone's lives simpler. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 27.08.2014 18:22, schrieb Stephen Warren: On 08/27/2014 08:44 AM, Catalin Marinas wrote: It's not just optimisation but an important feature for new arm64 SoCs. Given some Tegra discussions recently, in many cases the machine_desc use on arm is primarily to initialise devices in the right order. If we can solve this in a more deterministic way (other than deferred probing), we avoid the need for a dedicated SoC platform driver (or machine_desc) or workarounds like different initcall levels and explicit DT parsing. A lot of the ordering is SW driver dependencies. I'm not sure how much of that can accurately be claimed as HW dependencies. As such, I'm not sure that putting dependencies into DT would be a good idea; it doesn't feel like HW data, and might well change if we restructure SW. It'd need some detailed research though. Almost every phandle is a dependency, so the DT is already full with them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On 08/27/2014 08:44 AM, Catalin Marinas wrote: On Wed, Aug 27, 2014 at 11:34:32AM +0100, Grant Likely wrote: On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland wrote: On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote: Am 26.08.2014 10:49, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding wrote: [...] There are somewhat standardized bindings for the above and especially for bindings of the type that clocks implement this is trivial. We can simply iterate over each (phandle, specifier) tuple and check that the corresponding clock provider can be resolved (which typically means that it's been registered with the common clock framework). For regulators (and regulator-like bindings) the problem is somewhat more difficult because they property names are not standardized. One way to solve this would be to look for property names with a -supply suffix, but that could obviously lead to false positives. One alternative that I think could eliminate this would be to explicitly list dependencies in drivers. This would allow core code to step through such a list and resolve the (phandle, specifier) tuples. False positives and negatives may not actually be a problem. It is suboptimal, certainly, but it shouldn't outright break the kernel. There could be cases where some random integer in a cell could be interpreted as a phandle and resolve to a struct device_node. I suppose it might be unlikely, but not impossible, that the device_node could even match a device in the correct subsystem and you'd get a wrong dependency. Granted, a wrong dependency may not be catastrophic in that it won't lead to a crash, but it could lead to various kinds of weirdness and hard to diagnose problems. You need either the type information in the DTB (that's why I've add those "dependencies" to identify phandles), or you need to know every binding (at "dependency-resolve-time" to identify phandles. While having type information in the DTB would be fantastic, it's not something we can expect from the systems already in the wild, and I worry how it would interact with bootloaders that modify the DTB (I don't know if any modify properties with phandles). Anything we do here is firmly in the realm of optimization and improvement. Adding data to the tree is fine as long as we don't make the kernel depend on it. Older platforms will continue to work without the optimization. It's not just optimisation but an important feature for new arm64 SoCs. Given some Tegra discussions recently, in many cases the machine_desc use on arm is primarily to initialise devices in the right order. If we can solve this in a more deterministic way (other than deferred probing), we avoid the need for a dedicated SoC platform driver (or machine_desc) or workarounds like different initcall levels and explicit DT parsing. A lot of the ordering is SW driver dependencies. I'm not sure how much of that can accurately be claimed as HW dependencies. As such, I'm not sure that putting dependencies into DT would be a good idea; it doesn't feel like HW data, and might well change if we restructure SW. It'd need some detailed research though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Wed, Aug 27, 2014 at 11:34:32AM +0100, Grant Likely wrote: > On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland wrote: > > On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote: > > > Am 26.08.2014 10:49, schrieb Thierry Reding: > > > > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > > > >> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding > > > >> wrote: > > > > [...] > > > >>> There are somewhat standardized bindings for the above and especially > > > >>> for bindings of the type that clocks implement this is trivial. We can > > > >>> simply iterate over each (phandle, specifier) tuple and check that the > > > >>> corresponding clock provider can be resolved (which typically means > > > >>> that > > > >>> it's been registered with the common clock framework). > > > >>> > > > >>> For regulators (and regulator-like bindings) the problem is somewhat > > > >>> more difficult because they property names are not standardized. One > > > >>> way > > > >>> to solve this would be to look for property names with a -supply > > > >>> suffix, > > > >>> but that could obviously lead to false positives. One alternative > > > >>> that I > > > >>> think could eliminate this would be to explicitly list dependencies in > > > >>> drivers. This would allow core code to step through such a list and > > > >>> resolve the (phandle, specifier) tuples. > > > >> > > > >> False positives and negatives may not actually be a problem. It is > > > >> suboptimal, certainly, but it shouldn't outright break the kernel. > > > > > > > > There could be cases where some random integer in a cell could be > > > > interpreted as a phandle and resolve to a struct device_node. I suppose > > > > it might be unlikely, but not impossible, that the device_node could > > > > even match a device in the correct subsystem and you'd get a wrong > > > > dependency. Granted, a wrong dependency may not be catastrophic in that > > > > it won't lead to a crash, but it could lead to various kinds of > > > > weirdness and hard to diagnose problems. > > > > > > You need either the type information in the DTB (that's why I've add > > > those "dependencies" to identify phandles), or you need to know every > > > binding (at "dependency-resolve-time" to identify phandles. > > > > While having type information in the DTB would be fantastic, it's not > > something we can expect from the systems already in the wild, and I > > worry how it would interact with bootloaders that modify the DTB (I > > don't know if any modify properties with phandles). > > Anything we do here is firmly in the realm of optimization and > improvement. Adding data to the tree is fine as long as we don't make > the kernel depend on it. Older platforms will continue to work without > the optimization. It's not just optimisation but an important feature for new arm64 SoCs. Given some Tegra discussions recently, in many cases the machine_desc use on arm is primarily to initialise devices in the right order. If we can solve this in a more deterministic way (other than deferred probing), we avoid the need for a dedicated SoC platform driver (or machine_desc) or workarounds like different initcall levels and explicit DT parsing. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, 26 Aug 2014 11:11:07 +0100, Mark Rutland wrote: > On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote: > > Am 26.08.2014 10:49, schrieb Thierry Reding: > > > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > > >> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding > > >> wrote: > > > [...] > > >>> There are somewhat standardized bindings for the above and especially > > >>> for bindings of the type that clocks implement this is trivial. We can > > >>> simply iterate over each (phandle, specifier) tuple and check that the > > >>> corresponding clock provider can be resolved (which typically means that > > >>> it's been registered with the common clock framework). > > >>> > > >>> For regulators (and regulator-like bindings) the problem is somewhat > > >>> more difficult because they property names are not standardized. One way > > >>> to solve this would be to look for property names with a -supply suffix, > > >>> but that could obviously lead to false positives. One alternative that I > > >>> think could eliminate this would be to explicitly list dependencies in > > >>> drivers. This would allow core code to step through such a list and > > >>> resolve the (phandle, specifier) tuples. > > >> > > >> False positives and negatives may not actually be a problem. It is > > >> suboptimal, certainly, but it shouldn't outright break the kernel. > > > > > > There could be cases where some random integer in a cell could be > > > interpreted as a phandle and resolve to a struct device_node. I suppose > > > it might be unlikely, but not impossible, that the device_node could > > > even match a device in the correct subsystem and you'd get a wrong > > > dependency. Granted, a wrong dependency may not be catastrophic in that > > > it won't lead to a crash, but it could lead to various kinds of > > > weirdness and hard to diagnose problems. > > > > You need either the type information in the DTB (that's why I've add > > those "dependencies" to identify phandles), or you need to know every > > binding (at "dependency-resolve-time" to identify phandles. > > While having type information in the DTB would be fantastic, it's not > something we can expect from the systems already in the wild, and I > worry how it would interact with bootloaders that modify the DTB (I > don't know if any modify properties with phandles). Anything we do here is firmly in the realm of optimization and improvement. Adding data to the tree is fine as long as we don't make the kernel depend on it. Older platforms will continue to work without the optimization. > > The latter is impracticable to implement in a generic way (for use > > with every possible binding). > > I don't think we necessarily need dependency information for every > binding and driver. We only need dependency information where a device > has a dependency on another device and we don't currently have an > explicit probe ordering guaranteed by Linux. > > Where a device driver lacks dependency information and fails to probe, > we can fall back to the current deferred probing. Exactly. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 27.08.2014 09:16, schrieb Alexander Holler: Why should I? I've posted patches along with a lot of comments and explanations, and e.g. you are just talking that it should be made like my patches already did. And others do talk too like my patches and the accompanying comments from me which explain most stuff never have existed and just repeat what the patches already do without refering to them. Just to repeat myself: These patches which started this thread are not just some ideas without any sense for the amount of work necessary to implement them (as seen so often). These patches are real working code everyone can apply to the mentioned kernel version and see what happens with his board. They are even checkpatched to avoid bean counting discussion. (Don't forget to use patch 10/9 too) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 15:58, schrieb Jon Loeliger: I think we need to do the complete topsort *before* we attempt to do any probing. So three steps: 1) Graph Construction Add a new "emit dependencies" function to driver bindings. Iterate over known devices or nodes in the DT in any order. Call the "emit dependencies" function. It adds all dependency edges to a global graph by knowing what phandles or other pieces it will need. A driver with no "emit dependencies" function can be added to the graph anywhere without loss of generality. Add any additional edges for whatever reason. 2) Topsort the generated driver graph 3) Call probe for real in topsort order Alexander, I don't recall the details of your patch series. Can you please remind us if it took this approach in the kernel? Anyway, I'm leaving this discussion. I've already made a proposal which solved most mentioned problems (imho) and even offered usable patches Why should I? I've posted patches along with a lot of comments and explanations, and e.g. you are just talking that it should be made like my patches already did. And others do talk too like my patches and the accompanying comments from me which explain most stuff never have existed and just repeat what the patches already do without refering to them. Darn. I think you clearly have a pony in this race, and it would be good if you still participated. Really. Thanks. But I don't see it as a race and I don't want to take part in a race (and I usually avoid those silly contests which have become chic in the IT world). I just offered a solution (or at least a working starting point to a solution). (ok, they suffer under the "not invented here" syndrom, but ...). ;) There isn't a single thing in the entire Linux Kernel community that was "invented here"; every aspect of it was NIH'ed by *someone*. That's how it gets built, changed, maintained, fixed, etc. Might be true in an ideal open source world and might have been true for past kernel development when most people weren't full time kernel developers. But nowadays it appears to me like many parts of the kernel have become in the hands of closed groups. And they build and enforce hurdles that high, that nobody else can take them without spending an idiotic amount of time. Just like many other "consortiums" do, you only have to build enough rules to protect from the outside while still looking open. E.g. an example I've seen often is that someone spend a lot of time to examine and fix a bug and write a commented patch. And the only response from the maintainer was that he should add an emtpy line before a return statement and similiar silly things to enforce patch-ping-pong. Such just drives people on the other end crazy and they likely won't spend the time to post another patch (they still might fix other bugs, but just for themself). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 08:58:34AM -0500, Jon Loeliger wrote: > > >> > > >> Drivers don't provide that information (dependencies) in any usable way. > > >> And > > >> as you said yourself, it's already contained in phandles. So what we are > > >> discussing here about? The proposal to use phandles for that is already > > >> on > > >> the table since several month. ;) > > >> > > >> Sorry, but I don't understand what you want to propose. > > > > > > In many cases we simply don't know where phandles are stored since we > > > don't have the type information in DT. But drivers already know the type > > > of a specific phandle and where to get it from, so the proposal is to > > > make that knowledge more generally useful so that it can be used for > > > dependency resolution. > > > > How? > > Is the issue around which we are dancing here the timing of > topsort and the probing? When the driver is probed, sure, it > touches and resolves a bunch of phandles and references other > nodes and devices. But that is at probe time, and it only has > the context of itself then. > > I think we need to do the complete topsort *before* we attempt > to do any probing. So three steps: > > 1) Graph Construction > Add a new "emit dependencies" function to driver bindings. > Iterate over known devices or nodes in the DT in any order. > Call the "emit dependencies" function. It adds all > dependency edges to a global graph by knowing what > phandles or other pieces it will need. > A driver with no "emit dependencies" function can be > added to the graph anywhere without loss of generality. > Add any additional edges for whatever reason. > > 2) Topsort the generated driver graph > > 3) Call probe for real in topsort order Yes, I think that makes a lot of sense. We need to provide a way to make the dependency information available before probe time, otherwise we don't gain anything. Whether we provide that in a form of a function call or a table is an implementation detail. I do think that requiring drivers to provide a function is going to make things more complicated than necessary since that "emit dependencies" function would need to copy a lot of the things that .probe() does already. Sharing this information in a table sounds like a good idea. An "emit dependencies" function in the core can use that data to resolve dependencies whereas the driver core can equally use that information to request the devices so that the drivers don't have to do so. Thierry pgpqaM8BznLdc.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
> >> > >> Drivers don't provide that information (dependencies) in any usable way. > >> And > >> as you said yourself, it's already contained in phandles. So what we are > >> discussing here about? The proposal to use phandles for that is already on > >> the table since several month. ;) > >> > >> Sorry, but I don't understand what you want to propose. > > > > In many cases we simply don't know where phandles are stored since we > > don't have the type information in DT. But drivers already know the type > > of a specific phandle and where to get it from, so the proposal is to > > make that knowledge more generally useful so that it can be used for > > dependency resolution. > > How? Is the issue around which we are dancing here the timing of topsort and the probing? When the driver is probed, sure, it touches and resolves a bunch of phandles and references other nodes and devices. But that is at probe time, and it only has the context of itself then. I think we need to do the complete topsort *before* we attempt to do any probing. So three steps: 1) Graph Construction Add a new "emit dependencies" function to driver bindings. Iterate over known devices or nodes in the DT in any order. Call the "emit dependencies" function. It adds all dependency edges to a global graph by knowing what phandles or other pieces it will need. A driver with no "emit dependencies" function can be added to the graph anywhere without loss of generality. Add any additional edges for whatever reason. 2) Topsort the generated driver graph 3) Call probe for real in topsort order Alexander, I don't recall the details of your patch series. Can you please remind us if it took this approach in the kernel? > Anyway, I'm leaving this discussion. I've already made a proposal > which solved most mentioned problems (imho) and even offered usable > patches Darn. I think you clearly have a pony in this race, and it would be good if you still participated. Really. > (ok, they suffer under the "not invented here" syndrom, but ...). ;) There isn't a single thing in the entire Linux Kernel community that was "invented here"; every aspect of it was NIH'ed by *someone*. That's how it gets built, changed, maintained, fixed, etc. > But please continue this discussion, I will try to not disturb it > anymore. I'm sorry to hear that. > Regards, > Alexander Holler HTH, jdl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 13:47, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 01:23:54PM +0200, Alexander Holler wrote: Am 26.08.2014 13:08, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote: Am 26.08.2014 12:25, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: You need either the type information in the DTB (that's why I've add those "dependencies" to identify phandles), or you need to know every binding (at "dependency-resolve-time" to identify phandles. The latter is impracticable to implement in a generic way (for use with every possible binding). Like I already mentioned, this could be done in drivers who contain that information already anyway. Or parts of it could be done in subsystem- specific callbacks where a generic binding is available. That would end up with almost the same ugly driver-based workarounds as now. It's much better if a driver author only has to define it's prerequisits (in form of dependencies in the dts) and could be sure the driver will only be probed if those are met, than to do that stuff based on a subsystem or even driver level. If you add dependency-information to drivers, you have two problems: We already have all that dependency information in drivers anyway. Each driver requests the resources at .probe() time. What I proposed (it was really Arnd who proposed it first) is to move that information out of code and into some sort of table that could be used by the driver core to figure out dependencies. - How do you get these information from the driver (remember, currently there is only one initial call, a initcall which might do almost anything) While I don't think it's necessary, that's something that could be changed. I mean, we have access to the full source code of this operating system, so we can change every aspect of it. If we can't find a way to make this work with the current initcall sequence it's always an option to extend that sequence so that it meets our needs. - These information might become outdated and you would have to change all drivers. E.g. if the name of a dependency (driver) changes it wouldn't be done with changing the dts (maybe plural), but you would have to change the source of all dependant drivers too. No. Drivers implement a DT binding. That binding defines what power supplies, clocks, pinmux, ... the device needs. Those constitute the dependencies. We most certainly don't want to depend on driver names since there can be a multitude of different drivers that provide a given dependency. What drivers should provide (and what they already provide today) is the name of the property and the index of the cell that they expect to find a phandle in as well as the type of the phandle. That's all that's necessary, really. Everything else can be derived from that phandle and the type. Drivers don't provide that information (dependencies) in any usable way. And as you said yourself, it's already contained in phandles. So what we are discussing here about? The proposal to use phandles for that is already on the table since several month. ;) Sorry, but I don't understand what you want to propose. In many cases we simply don't know where phandles are stored since we don't have the type information in DT. But drivers already know the type of a specific phandle and where to get it from, so the proposal is to make that knowledge more generally useful so that it can be used for dependency resolution. How? Anyway, I'm leaving this discussion. I've already made a proposal which solved most mentioned problems (imho) and even offered usable patches (ok, they suffer under the "not invented here" syndrom, but ...). ;) But please continue this discussion, I will try to not disturb it anymore. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 01:23:54PM +0200, Alexander Holler wrote: > Am 26.08.2014 13:08, schrieb Thierry Reding: > >On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote: > >>Am 26.08.2014 12:25, schrieb Thierry Reding: > >>>On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: > >> > You need either the type information in the DTB (that's why I've add those > "dependencies" to identify phandles), or you need to know every binding > (at > "dependency-resolve-time" to identify phandles. The latter is > impracticable > to implement in a generic way (for use with every possible binding). > >>> > >>>Like I already mentioned, this could be done in drivers who contain that > >>>information already anyway. Or parts of it could be done in subsystem- > >>>specific callbacks where a generic binding is available. > >> > >>That would end up with almost the same ugly driver-based workarounds as now. > >>It's much better if a driver author only has to define it's prerequisits (in > >>form of dependencies in the dts) and could be sure the driver will only be > >>probed if those are met, than to do that stuff based on a subsystem or even > >>driver level. > >> > >>If you add dependency-information to drivers, you have two problems: > > > >We already have all that dependency information in drivers anyway. Each > >driver requests the resources at .probe() time. What I proposed (it was > >really Arnd who proposed it first) is to move that information out of > >code and into some sort of table that could be used by the driver core > >to figure out dependencies. > > > >>- How do you get these information from the driver (remember, currently > >>there is only one initial call, a initcall which might do almost anything) > > > >While I don't think it's necessary, that's something that could be > >changed. I mean, we have access to the full source code of this > >operating system, so we can change every aspect of it. If we can't find > >a way to make this work with the current initcall sequence it's always > >an option to extend that sequence so that it meets our needs. > > > >>- These information might become outdated and you would have to change all > >>drivers. E.g. if the name of a dependency (driver) changes it wouldn't be > >>done with changing the dts (maybe plural), but you would have to change the > >>source of all dependant drivers too. > > > >No. Drivers implement a DT binding. That binding defines what power > >supplies, clocks, pinmux, ... the device needs. Those constitute the > >dependencies. We most certainly don't want to depend on driver names > >since there can be a multitude of different drivers that provide a given > >dependency. > > > >What drivers should provide (and what they already provide today) is the > >name of the property and the index of the cell that they expect to find > >a phandle in as well as the type of the phandle. That's all that's > >necessary, really. Everything else can be derived from that phandle and > >the type. > > Drivers don't provide that information (dependencies) in any usable way. And > as you said yourself, it's already contained in phandles. So what we are > discussing here about? The proposal to use phandles for that is already on > the table since several month. ;) > > Sorry, but I don't understand what you want to propose. In many cases we simply don't know where phandles are stored since we don't have the type information in DT. But drivers already know the type of a specific phandle and where to get it from, so the proposal is to make that knowledge more generally useful so that it can be used for dependency resolution. Thierry pgpLCTT2WbcEU.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 13:08, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote: Am 26.08.2014 12:25, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: You need either the type information in the DTB (that's why I've add those "dependencies" to identify phandles), or you need to know every binding (at "dependency-resolve-time" to identify phandles. The latter is impracticable to implement in a generic way (for use with every possible binding). Like I already mentioned, this could be done in drivers who contain that information already anyway. Or parts of it could be done in subsystem- specific callbacks where a generic binding is available. That would end up with almost the same ugly driver-based workarounds as now. It's much better if a driver author only has to define it's prerequisits (in form of dependencies in the dts) and could be sure the driver will only be probed if those are met, than to do that stuff based on a subsystem or even driver level. If you add dependency-information to drivers, you have two problems: We already have all that dependency information in drivers anyway. Each driver requests the resources at .probe() time. What I proposed (it was really Arnd who proposed it first) is to move that information out of code and into some sort of table that could be used by the driver core to figure out dependencies. - How do you get these information from the driver (remember, currently there is only one initial call, a initcall which might do almost anything) While I don't think it's necessary, that's something that could be changed. I mean, we have access to the full source code of this operating system, so we can change every aspect of it. If we can't find a way to make this work with the current initcall sequence it's always an option to extend that sequence so that it meets our needs. - These information might become outdated and you would have to change all drivers. E.g. if the name of a dependency (driver) changes it wouldn't be done with changing the dts (maybe plural), but you would have to change the source of all dependant drivers too. No. Drivers implement a DT binding. That binding defines what power supplies, clocks, pinmux, ... the device needs. Those constitute the dependencies. We most certainly don't want to depend on driver names since there can be a multitude of different drivers that provide a given dependency. What drivers should provide (and what they already provide today) is the name of the property and the index of the cell that they expect to find a phandle in as well as the type of the phandle. That's all that's necessary, really. Everything else can be derived from that phandle and the type. Drivers don't provide that information (dependencies) in any usable way. And as you said yourself, it's already contained in phandles. So what we are discussing here about? The proposal to use phandles for that is already on the table since several month. ;) Sorry, but I don't understand what you want to propose. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 12:44:35PM +0200, Alexander Holler wrote: > Am 26.08.2014 12:25, schrieb Thierry Reding: > >On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: > > >>You need either the type information in the DTB (that's why I've add those > >>"dependencies" to identify phandles), or you need to know every binding (at > >>"dependency-resolve-time" to identify phandles. The latter is impracticable > >>to implement in a generic way (for use with every possible binding). > > > >Like I already mentioned, this could be done in drivers who contain that > >information already anyway. Or parts of it could be done in subsystem- > >specific callbacks where a generic binding is available. > > That would end up with almost the same ugly driver-based workarounds as now. > It's much better if a driver author only has to define it's prerequisits (in > form of dependencies in the dts) and could be sure the driver will only be > probed if those are met, than to do that stuff based on a subsystem or even > driver level. > > If you add dependency-information to drivers, you have two problems: We already have all that dependency information in drivers anyway. Each driver requests the resources at .probe() time. What I proposed (it was really Arnd who proposed it first) is to move that information out of code and into some sort of table that could be used by the driver core to figure out dependencies. > - How do you get these information from the driver (remember, currently > there is only one initial call, a initcall which might do almost anything) While I don't think it's necessary, that's something that could be changed. I mean, we have access to the full source code of this operating system, so we can change every aspect of it. If we can't find a way to make this work with the current initcall sequence it's always an option to extend that sequence so that it meets our needs. > - These information might become outdated and you would have to change all > drivers. E.g. if the name of a dependency (driver) changes it wouldn't be > done with changing the dts (maybe plural), but you would have to change the > source of all dependant drivers too. No. Drivers implement a DT binding. That binding defines what power supplies, clocks, pinmux, ... the device needs. Those constitute the dependencies. We most certainly don't want to depend on driver names since there can be a multitude of different drivers that provide a given dependency. What drivers should provide (and what they already provide today) is the name of the property and the index of the cell that they expect to find a phandle in as well as the type of the phandle. That's all that's necessary, really. Everything else can be derived from that phandle and the type. Thierry pgpQiNyzlqH_b.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 12:44, schrieb Alexander Holler: Am 26.08.2014 12:25, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: You need either the type information in the DTB (that's why I've add those "dependencies" to identify phandles), or you need to know every binding (at "dependency-resolve-time" to identify phandles. The latter is impracticable to implement in a generic way (for use with every possible binding). Like I already mentioned, this could be done in drivers who contain that information already anyway. Or parts of it could be done in subsystem- specific callbacks where a generic binding is available. That would end up with almost the same ugly driver-based workarounds as now. It's much better if a driver author only has to define it's prerequisits (in form of dependencies in the dts) and could be sure the driver will only be probed if those are met, than to do that stuff based on a subsystem or even driver level. If you add dependency-information to drivers, you have two problems: - How do you get these information from the driver (remember, currently there is only one initial call, a initcall which might do almost anything) - These information might become outdated and you would have to change all drivers. E.g. if the name of a dependency (driver) changes it wouldn't be done with changing the dts (maybe plural), but you would have to change the source of all dependant drivers too. And after having sorted my brain: A driver depends on a binding (and its API), but not on explicit named other drivers. So trying it (again) on driver level is doomed to fail. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 12:25, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: You need either the type information in the DTB (that's why I've add those "dependencies" to identify phandles), or you need to know every binding (at "dependency-resolve-time" to identify phandles. The latter is impracticable to implement in a generic way (for use with every possible binding). Like I already mentioned, this could be done in drivers who contain that information already anyway. Or parts of it could be done in subsystem- specific callbacks where a generic binding is available. That would end up with almost the same ugly driver-based workarounds as now. It's much better if a driver author only has to define it's prerequisits (in form of dependencies in the dts) and could be sure the driver will only be probed if those are met, than to do that stuff based on a subsystem or even driver level. If you add dependency-information to drivers, you have two problems: - How do you get these information from the driver (remember, currently there is only one initial call, a initcall which might do almost anything) - These information might become outdated and you would have to change all drivers. E.g. if the name of a dependency (driver) changes it wouldn't be done with changing the dts (maybe plural), but you would have to change the source of all dependant drivers too. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 11:42:04AM +0200, Alexander Holler wrote: > Am 26.08.2014 10:49, schrieb Thierry Reding: > >On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > >>On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding > >> wrote: > >[...] > >>>There are somewhat standardized bindings for the above and especially > >>>for bindings of the type that clocks implement this is trivial. We can > >>>simply iterate over each (phandle, specifier) tuple and check that the > >>>corresponding clock provider can be resolved (which typically means that > >>>it's been registered with the common clock framework). > >>> > >>>For regulators (and regulator-like bindings) the problem is somewhat > >>>more difficult because they property names are not standardized. One way > >>>to solve this would be to look for property names with a -supply suffix, > >>>but that could obviously lead to false positives. One alternative that I > >>>think could eliminate this would be to explicitly list dependencies in > >>>drivers. This would allow core code to step through such a list and > >>>resolve the (phandle, specifier) tuples. > >> > >>False positives and negatives may not actually be a problem. It is > >>suboptimal, certainly, but it shouldn't outright break the kernel. > > > >There could be cases where some random integer in a cell could be > >interpreted as a phandle and resolve to a struct device_node. I suppose > >it might be unlikely, but not impossible, that the device_node could > >even match a device in the correct subsystem and you'd get a wrong > >dependency. Granted, a wrong dependency may not be catastrophic in that > >it won't lead to a crash, but it could lead to various kinds of > >weirdness and hard to diagnose problems. > > You need either the type information in the DTB (that's why I've add those > "dependencies" to identify phandles), or you need to know every binding (at > "dependency-resolve-time" to identify phandles. The latter is impracticable > to implement in a generic way (for use with every possible binding). Like I already mentioned, this could be done in drivers who contain that information already anyway. Or parts of it could be done in subsystem- specific callbacks where a generic binding is available. Thierry pgpQOXmzj8AK0.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 11:11:07AM +0100, Mark Rutland wrote: > On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote: > > Am 26.08.2014 10:49, schrieb Thierry Reding: > > > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > > >> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding > > >> wrote: > > > [...] > > >>> There are somewhat standardized bindings for the above and especially > > >>> for bindings of the type that clocks implement this is trivial. We can > > >>> simply iterate over each (phandle, specifier) tuple and check that the > > >>> corresponding clock provider can be resolved (which typically means that > > >>> it's been registered with the common clock framework). > > >>> > > >>> For regulators (and regulator-like bindings) the problem is somewhat > > >>> more difficult because they property names are not standardized. One way > > >>> to solve this would be to look for property names with a -supply suffix, > > >>> but that could obviously lead to false positives. One alternative that I > > >>> think could eliminate this would be to explicitly list dependencies in > > >>> drivers. This would allow core code to step through such a list and > > >>> resolve the (phandle, specifier) tuples. > > >> > > >> False positives and negatives may not actually be a problem. It is > > >> suboptimal, certainly, but it shouldn't outright break the kernel. > > > > > > There could be cases where some random integer in a cell could be > > > interpreted as a phandle and resolve to a struct device_node. I suppose > > > it might be unlikely, but not impossible, that the device_node could > > > even match a device in the correct subsystem and you'd get a wrong > > > dependency. Granted, a wrong dependency may not be catastrophic in that > > > it won't lead to a crash, but it could lead to various kinds of > > > weirdness and hard to diagnose problems. > > > > You need either the type information in the DTB (that's why I've add > > those "dependencies" to identify phandles), or you need to know every > > binding (at "dependency-resolve-time" to identify phandles. > > While having type information in the DTB would be fantastic, it's not > something we can expect from the systems already in the wild, and I > worry how it would interact with bootloaders that modify the DTB (I > don't know if any modify properties with phandles). > > > The latter is impracticable to implement in a generic way (for use > > with every possible binding). > > I don't think we necessarily need dependency information for every > binding and driver. We only need dependency information where a device > has a dependency on another device and we don't currently have an > explicit probe ordering guaranteed by Linux. > > Where a device driver lacks dependency information and fails to probe, > we can fall back to the current deferred probing. > > Do we have any worst case example systems / drivers / dts? Cc'ing Stéphane who's brought this up not long ago. There seem to be cases where display initialization can be delayed up to 5-6 seconds due to deferred probing (where the system would otherwise take 5-6 seconds to boot). Thierry pgpz2tgKTaoL8.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 10:51, schrieb Grant Likely: Getting the dependency tree I think is only half the problem. The other have is how to get the driver model to actually order probing using that list. That problem is hard because the order drivers are probed is currently determined by the interaction of driver link order, driver initcall level, and device registration order. The first devices are > registered at an early initcall, before their drivers, and therefore > bind order is primarily determined by initcall level and driver link > order. However, later devices (ie. i2c clients) are registered by the > bus driver (ie. again, i2c) and probe order may be primarily link order > (if the driver is not yet registered) or registration order (if the > driver was registered before the parent bus). Using my patches, the problem which still exists is how to handle devices (not drivers). I've build the patches based on the assumption that device-handling happens automatically. Unfortunately that isn't really true and device-handling looks awkward. Some drivers build them themself, some require that a device already exists and some require that a device doesn't already exist. But I haven't looked in deep at that. I'm sure that can be fixed by fixing drivers which do things differently than they should (maybe because they needed to do such for dirty workarounds because no order was guaranteed, which wouldn't be true anymore). Anyway, I've not looked further into that problem (with devices, not drivers) as it already seems quiet impossible to get the other necessary stuff into the kernel in a reasonable time (before 32bit-HW which does use DT will not be available anymore). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 10:42:04AM +0100, Alexander Holler wrote: > Am 26.08.2014 10:49, schrieb Thierry Reding: > > On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > >> On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding > >> wrote: > > [...] > >>> There are somewhat standardized bindings for the above and especially > >>> for bindings of the type that clocks implement this is trivial. We can > >>> simply iterate over each (phandle, specifier) tuple and check that the > >>> corresponding clock provider can be resolved (which typically means that > >>> it's been registered with the common clock framework). > >>> > >>> For regulators (and regulator-like bindings) the problem is somewhat > >>> more difficult because they property names are not standardized. One way > >>> to solve this would be to look for property names with a -supply suffix, > >>> but that could obviously lead to false positives. One alternative that I > >>> think could eliminate this would be to explicitly list dependencies in > >>> drivers. This would allow core code to step through such a list and > >>> resolve the (phandle, specifier) tuples. > >> > >> False positives and negatives may not actually be a problem. It is > >> suboptimal, certainly, but it shouldn't outright break the kernel. > > > > There could be cases where some random integer in a cell could be > > interpreted as a phandle and resolve to a struct device_node. I suppose > > it might be unlikely, but not impossible, that the device_node could > > even match a device in the correct subsystem and you'd get a wrong > > dependency. Granted, a wrong dependency may not be catastrophic in that > > it won't lead to a crash, but it could lead to various kinds of > > weirdness and hard to diagnose problems. > > You need either the type information in the DTB (that's why I've add > those "dependencies" to identify phandles), or you need to know every > binding (at "dependency-resolve-time" to identify phandles. While having type information in the DTB would be fantastic, it's not something we can expect from the systems already in the wild, and I worry how it would interact with bootloaders that modify the DTB (I don't know if any modify properties with phandles). > The latter is impracticable to implement in a generic way (for use > with every possible binding). I don't think we necessarily need dependency information for every binding and driver. We only need dependency information where a device has a dependency on another device and we don't currently have an explicit probe ordering guaranteed by Linux. Where a device driver lacks dependency information and fails to probe, we can fall back to the current deferred probing. Do we have any worst case example systems / drivers / dts? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 10:51, schrieb Grant Likely: On Mon, 25 Aug 2014 08:08:59 -0500, Jon Loeliger wrote: Anyway, instead of going back and forth between "deferred probe is good" and "deferred probe is bad", how about we do something useful now and concentrate on how to make use of the information we have in DT with the goal to reduce the number of cases where deferred probing is required? Good idea. The proposal on the table is to allow the probe code to make a topological sort of the devices based on dependency information either implied, explicitly stated or both. That is likely a fundamentally correct approach. I believe some of the issues that need to be resolved are: 1) What constitutes a dependency? 2) How is that dependency expressed? 3) How do we add missing dependencies? 4) Backward compatability problems. There are other questions, of course. Is it a topsort per bus? Are there required "early devices"? Should the inter-node dependencies be expressed at each node, or in a separate hierarchy within the DTS? Others. Topsort by bus wouldn't work. That would imply that nothing uses something involved with another bus. And early devices are handled fine by normal dependencies too (as long as they are complete), so there is no need to make an distinction. Getting the dependency tree I think is only half the problem. The other have is how to get the driver model to actually order probing using that list. That problem is hard because the order drivers are probed is currently determined by the interaction of driver link order, driver initcall level, and device registration order. The first devices are registered at an early initcall, before their drivers, and therefore bind order is primarily determined by initcall level and driver link order. However, later devices (ie. i2c clients) are registered by the bus driver (ie. again, i2c) and probe order may be primarily link order (if the driver is not yet registered) or registration order (if the driver was registered before the parent bus). That's why I've invented those "well-done"-initcalls. These are initcalls which just register a driver and don't probe it. Thats necessary to build a catalog of existing in-kernel-drivers (you have to know what you are sorting). Fortunately most drivers are already of that type. And those which aren't can be either just used like before (if it works) or they can be changed. Changing them can be done per board (only enable dependency based order for a board if necessary drivers have changed). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, Aug 25, 2014 at 10:39:32AM +0100, Thierry Reding wrote: > On Fri, Aug 22, 2014 at 02:19:19PM +0100, Mark Rutland wrote: > > On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote: > > > Am 21.08.2014 16:02, schrieb Thierry Reding: > > > > > > > Anyway, those are all fairly standard reasons for where deferred probe > > > > triggers, and since I do like deferred probe for it's simplicity and > > > > reliability I'd rather not try to work around it if boot time is all > > > > that people are concerned about. > > > > > > It's neither simple nor reliable. It's non deterministic brutforcing > > > while making it almost impossible to identify real errors. > > > > It's horrible, yes. > > > > > In my humble opinion the worst way to solve something. I'm pretty sure > > > if I would have suggest such a solution, the maintainer crowd would have > > > eaten me without cooking. > > > > We didn't have a better workable solution at the time. > > You make it sound like we've come up with a better workable solution in > the meantime. That wasn't the intention, but my sloppy wording does make it come across that way. > > Having a hack that got boards booting was considered better than not > > having them boot. > > I don't remember people being particularly enthralled by the idea. > > Odd, I remember things quite differently. Then perhaps my memory is faulty. :) > Anyway, instead of going back and forth between "deferred probe is good" > and "deferred probe is bad", how about we do something useful now and > concentrate on how to make use of the information we have in DT with the > goal to reduce the number of cases where deferred probing is required? Certainly. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 10:49, schrieb Thierry Reding: On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding wrote: [...] There are somewhat standardized bindings for the above and especially for bindings of the type that clocks implement this is trivial. We can simply iterate over each (phandle, specifier) tuple and check that the corresponding clock provider can be resolved (which typically means that it's been registered with the common clock framework). For regulators (and regulator-like bindings) the problem is somewhat more difficult because they property names are not standardized. One way to solve this would be to look for property names with a -supply suffix, but that could obviously lead to false positives. One alternative that I think could eliminate this would be to explicitly list dependencies in drivers. This would allow core code to step through such a list and resolve the (phandle, specifier) tuples. False positives and negatives may not actually be a problem. It is suboptimal, certainly, but it shouldn't outright break the kernel. There could be cases where some random integer in a cell could be interpreted as a phandle and resolve to a struct device_node. I suppose it might be unlikely, but not impossible, that the device_node could even match a device in the correct subsystem and you'd get a wrong dependency. Granted, a wrong dependency may not be catastrophic in that it won't lead to a crash, but it could lead to various kinds of weirdness and hard to diagnose problems. You need either the type information in the DTB (that's why I've add those "dependencies" to identify phandles), or you need to know every binding (at "dependency-resolve-time" to identify phandles. The latter is impracticable to implement in a generic way (for use with every possible binding). Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, 25 Aug 2014 08:08:59 -0500, Jon Loeliger wrote: > > > > > Anyway, instead of going back and forth between "deferred probe is good" > > and "deferred probe is bad", how about we do something useful now and > > concentrate on how to make use of the information we have in DT with the > > goal to reduce the number of cases where deferred probing is required? > > Good idea. > > The proposal on the table is to allow the probe code > to make a topological sort of the devices based on > dependency information either implied, explicitly stated > or both. That is likely a fundamentally correct approach. > > I believe some of the issues that need to be resolved are: > > 1) What constitutes a dependency? > 2) How is that dependency expressed? > 3) How do we add missing dependencies? > 4) Backward compatability problems. > > There are other questions, of course. Is it a topsort > per bus? Are there required "early devices"? Should > the inter-node dependencies be expressed at each node, > or in a separate hierarchy within the DTS? Others. Getting the dependency tree I think is only half the problem. The other have is how to get the driver model to actually order probing using that list. That problem is hard because the order drivers are probed is currently determined by the interaction of driver link order, driver initcall level, and device registration order. The first devices are registered at an early initcall, before their drivers, and therefore bind order is primarily determined by initcall level and driver link order. However, later devices (ie. i2c clients) are registered by the bus driver (ie. again, i2c) and probe order may be primarily link order (if the driver is not yet registered) or registration order (if the driver was registered before the parent bus). g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Tue, Aug 26, 2014 at 09:42:08AM +0100, Grant Likely wrote: > On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding > wrote: [...] > > There are somewhat standardized bindings for the above and especially > > for bindings of the type that clocks implement this is trivial. We can > > simply iterate over each (phandle, specifier) tuple and check that the > > corresponding clock provider can be resolved (which typically means that > > it's been registered with the common clock framework). > > > > For regulators (and regulator-like bindings) the problem is somewhat > > more difficult because they property names are not standardized. One way > > to solve this would be to look for property names with a -supply suffix, > > but that could obviously lead to false positives. One alternative that I > > think could eliminate this would be to explicitly list dependencies in > > drivers. This would allow core code to step through such a list and > > resolve the (phandle, specifier) tuples. > > False positives and negatives may not actually be a problem. It is > suboptimal, certainly, but it shouldn't outright break the kernel. There could be cases where some random integer in a cell could be interpreted as a phandle and resolve to a struct device_node. I suppose it might be unlikely, but not impossible, that the device_node could even match a device in the correct subsystem and you'd get a wrong dependency. Granted, a wrong dependency may not be catastrophic in that it won't lead to a crash, but it could lead to various kinds of weirdness and hard to diagnose problems. Thierry pgpRS_pcNlY8b.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, 25 Aug 2014 15:37:16 +0200, Thierry Reding
wrote:
> On Mon, Aug 25, 2014 at 08:08:59AM -0500, Jon Loeliger wrote:
> > >
> >
> > > Anyway, instead of going back and forth between "deferred probe is good"
> > > and "deferred probe is bad", how about we do something useful now and
> > > concentrate on how to make use of the information we have in DT with the
> > > goal to reduce the number of cases where deferred probing is required?
> >
> > Good idea.
> >
> > The proposal on the table is to allow the probe code
> > to make a topological sort of the devices based on
> > dependency information either implied, explicitly stated
> > or both. That is likely a fundamentally correct approach.
> >
> > I believe some of the issues that need to be resolved are:
> >
> > 1) What constitutes a dependency?
> > 2) How is that dependency expressed?
> > 3) How do we add missing dependencies?
> > 4) Backward compatability problems.
> >
> > There are other questions, of course. Is it a topsort
> > per bus? Are there required "early devices"? Should
> > the inter-node dependencies be expressed at each node,
> > or in a separate hierarchy within the DTS? Others.
>
> I think Grant already objected to the idea of explicitly adding
> dependency information into the device tree sources. Rather, if I
> understand correctly, we should be using the information readily
> available (phandle references) as much as possible before resorting to
> additional properties.
My objection is primarily around the concern that the dependency data
will get stale if firmware modifies the tree or that the kernel will
break when by relying on incorrect dependency information.
If the kernel can handle incorrect dependencies gracefully (like falling
back to deferred probe) then we can consider additional properties.
> So far we've been operating under the assumption that a dependency is
> modeled as a phandle reference and that the dependent would contain the
> phandle reference to the dependency. That's for example how clocks and
> regulators (to name only a few) work. A simplified example would look
> like this:
>
> clock: clock@... {
> ...
> #clock-cells = <1>;
> ...
> };
>
> pmic: pmic@... {
> regulators {
> vdd_foo: ldo0 {
> ...
> };
>
> vdd_bar: ldo1 {
> ...
> };
> };
>
> device@... {
> vdd-supply = <&vdd_foo>;
> clocks = <&clock 0>;
> };
>
> device@... {
> vdd-supply = <&vdd_bar>;
> clocks = <&clock 1>;
> };
>
> There are somewhat standardized bindings for the above and especially
> for bindings of the type that clocks implement this is trivial. We can
> simply iterate over each (phandle, specifier) tuple and check that the
> corresponding clock provider can be resolved (which typically means that
> it's been registered with the common clock framework).
>
> For regulators (and regulator-like bindings) the problem is somewhat
> more difficult because they property names are not standardized. One way
> to solve this would be to look for property names with a -supply suffix,
> but that could obviously lead to false positives. One alternative that I
> think could eliminate this would be to explicitly list dependencies in
> drivers. This would allow core code to step through such a list and
> resolve the (phandle, specifier) tuples.
False positives and negatives may not actually be a problem. It is
suboptimal, certainly, but it shouldn't outright break the kernel.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 25.08.2014 15:08, schrieb Jon Loeliger: Anyway, instead of going back and forth between "deferred probe is good" and "deferred probe is bad", how about we do something useful now and concentrate on how to make use of the information we have in DT with the goal to reduce the number of cases where deferred probing is required? Good idea. The proposal on the table is to allow the probe code to make a topological sort of the devices based on dependency information either implied, explicitly stated or both. That is likely a fundamentally correct approach. I believe some of the issues that need to be resolved are: 1) What constitutes a dependency? In my patches phandles are used. That works pretty good for almost all DTs. So almost all dependencies are already declared in a DT and almost no changes to the DT are necessary. The only binding I've seen where it doesn't work is remote-endpoint, because that binding isn't a directed dependency. So one of the two places where such a binding occurs needs a "no-dependencies = " to avoid circular dependencies which can be solved. 2) How is that dependency expressed? Already there in form of phandles. 3) How do we add missing dependencies? My patches offer the possibility to extend or reduce the list of (automatically generated) dependencies by using "[no-]dependencies = < list of phandles >;" 4) Backward compatability problems. None in my approach. The DT just includes an additional binding to circumvent the missing but needed type information for phandles. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, Aug 25, 2014 at 09:13:59AM -0500, Jon Loeliger wrote: > > > > > > > I believe some of the issues that need to be resolved are: > > > > > > 1) What constitutes a dependency? > > > 2) How is that dependency expressed? > > > 3) How do we add missing dependencies? > > > 4) Backward compatability problems. > > > > > > There are other questions, of course. Is it a topsort > > > per bus? Are there required "early devices"? Should > > > the inter-node dependencies be expressed at each node, > > > or in a separate hierarchy within the DTS? Others. > > > > I think Grant already objected to the idea of explicitly adding > > dependency information into the device tree sources. > > Clearly, the reason to object to the introdcution of such > an artificial dependency implies that it would be trying > to express something that doesn't actually describe an > existing hardware requirement. That is, it wouldn't be > "describing hardware". That's fine. > > But the inverse should also be true. That is, we should > ensure that where there *is* a hardware dependency that > is currently not expressed, we should introduce that > relationship. Agreed. Any dependency currently not expressed probably indicates that the device tree isn't complete yet and is a result of us coming up with device trees as we go. Using phandles to describe dependencies makes a lot of sense. As I understand it the original intent was for OpenFirmware to use phandle to resolve a "service provider" and call functions that it provided. That's exactly what we need in Linux, too. Deferred probe is usually triggered when one device's driver needs to access services provided by a device that hasn't been registered yet. The way to find such a service provider is by looking up the phandle (really the struct device_node representing the referenced node) in a subsystem-specific registry. Therefore it should be possible to resolve all dependencies at boot time using nothing but the phandles. > > For regulators (and regulator-like bindings) the problem is somewhat > > more difficult because they property names are not standardized. One way > > to solve this would be to look for property names with a -supply suffix, > > but that could obviously lead to false positives. One alternative that I > > think could eliminate this would be to explicitly list dependencies in > > drivers. This would allow core code to step through such a list and > > resolve the (phandle, specifier) tuples. > > So, express the "additional SW dependencies" in the SW? Well, not really. They aren't additional dependencies. The problem is that if we want to use only phandle references to resolve dependencies (which is a requirement if we don't want to rely on DT to provide extra metadata), then we need to know what exactly is a phandle. Since the final DTB will only have a u32 where a phandle was once referenced, we need to provide the driver core with some way to recover that lost information. And the best place to do that really is the driver, because it implements the binding, hence knows exactly what property and cell in that property contains a phandle value. So what we'd be expressing in software is hints as to where to find the list of dependencies. In addition to that, a lot of boiler-plate code could be eliminated in drivers by using that same metadata to automatically request the resources. > > Clocks are usually not a problem with deferred probing since they often > > are registered early anyway. > > Ah, but how are they known to be needed early? A toposort should sort > them into that position. That's not currently done. And I doubt the > set of nodes and expressed dependencies would cause them to be done > early enough by today's standards. They aren't really regular device drivers but rather registered using an explicit initcall. Clock providers are even initialized before initcalls are run. The reason is that they are often required for things like SMP or by other non-driver code that needs to run very early. > > Regulators on the other hand seem to be a fairly common trigger, > > though, so they seem like a good candidate to focus on. > > Yeah. And I've seen some debatable IRQ-PHY-PCIe interaction too. There are probably a couple of these that can be easily identified and would eliminate a large percentage of deferred probe triggers already. I found a link to Arnd's original proposal[0] for the devm_probe() infrastructure and I think that could serve as a useful basis for this. I would imagine that embedding a pointer to the devm_probe structure into a struct device_driver and extending it with a way to resolve the dependencies could work well. Thierry [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/209031.html pgprm9LSEKsUh.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
> > > > I believe some of the issues that need to be resolved are: > > > > 1) What constitutes a dependency? > > 2) How is that dependency expressed? > > 3) How do we add missing dependencies? > > 4) Backward compatability problems. > > > > There are other questions, of course. Is it a topsort > > per bus? Are there required "early devices"? Should > > the inter-node dependencies be expressed at each node, > > or in a separate hierarchy within the DTS? Others. > > I think Grant already objected to the idea of explicitly adding > dependency information into the device tree sources. Clearly, the reason to object to the introdcution of such an artificial dependency implies that it would be trying to express something that doesn't actually describe an existing hardware requirement. That is, it wouldn't be "describing hardware". That's fine. But the inverse should also be true. That is, we should ensure that where there *is* a hardware dependency that is currently not expressed, we should introduce that relationship. > For regulators (and regulator-like bindings) the problem is somewhat > more difficult because they property names are not standardized. One way > to solve this would be to look for property names with a -supply suffix, > but that could obviously lead to false positives. One alternative that I > think could eliminate this would be to explicitly list dependencies in > drivers. This would allow core code to step through such a list and > resolve the (phandle, specifier) tuples. So, express the "additional SW dependencies" in the SW? > Clocks are usually not a problem with deferred probing since they often > are registered early anyway. Ah, but how are they known to be needed early? A toposort should sort them into that position. That's not currently done. And I doubt the set of nodes and expressed dependencies would cause them to be done early enough by today's standards. > Regulators on the other hand seem to be a fairly common trigger, > though, so they seem like a good candidate to focus on. Yeah. And I've seen some debatable IRQ-PHY-PCIe interaction too. > Thierry jdl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, Aug 25, 2014 at 08:08:59AM -0500, Jon Loeliger wrote:
> >
>
> > Anyway, instead of going back and forth between "deferred probe is good"
> > and "deferred probe is bad", how about we do something useful now and
> > concentrate on how to make use of the information we have in DT with the
> > goal to reduce the number of cases where deferred probing is required?
>
> Good idea.
>
> The proposal on the table is to allow the probe code
> to make a topological sort of the devices based on
> dependency information either implied, explicitly stated
> or both. That is likely a fundamentally correct approach.
>
> I believe some of the issues that need to be resolved are:
>
> 1) What constitutes a dependency?
> 2) How is that dependency expressed?
> 3) How do we add missing dependencies?
> 4) Backward compatability problems.
>
> There are other questions, of course. Is it a topsort
> per bus? Are there required "early devices"? Should
> the inter-node dependencies be expressed at each node,
> or in a separate hierarchy within the DTS? Others.
I think Grant already objected to the idea of explicitly adding
dependency information into the device tree sources. Rather, if I
understand correctly, we should be using the information readily
available (phandle references) as much as possible before resorting to
additional properties.
So far we've been operating under the assumption that a dependency is
modeled as a phandle reference and that the dependent would contain the
phandle reference to the dependency. That's for example how clocks and
regulators (to name only a few) work. A simplified example would look
like this:
clock: clock@... {
...
#clock-cells = <1>;
...
};
pmic: pmic@... {
regulators {
vdd_foo: ldo0 {
...
};
vdd_bar: ldo1 {
...
};
};
device@... {
vdd-supply = <&vdd_foo>;
clocks = <&clock 0>;
};
device@... {
vdd-supply = <&vdd_bar>;
clocks = <&clock 1>;
};
There are somewhat standardized bindings for the above and especially
for bindings of the type that clocks implement this is trivial. We can
simply iterate over each (phandle, specifier) tuple and check that the
corresponding clock provider can be resolved (which typically means that
it's been registered with the common clock framework).
For regulators (and regulator-like bindings) the problem is somewhat
more difficult because they property names are not standardized. One way
to solve this would be to look for property names with a -supply suffix,
but that could obviously lead to false positives. One alternative that I
think could eliminate this would be to explicitly list dependencies in
drivers. This would allow core code to step through such a list and
resolve the (phandle, specifier) tuples.
Clocks are usually not a problem with deferred probing since they often
are registered early anyway. Regulators on the other hand seem to be a
fairly common trigger, though, so they seem like a good candidate to
focus on.
Thierry
pgpeBgEZtYCk_.pgp
Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
> > Anyway, instead of going back and forth between "deferred probe is good" > and "deferred probe is bad", how about we do something useful now and > concentrate on how to make use of the information we have in DT with the > goal to reduce the number of cases where deferred probing is required? Good idea. The proposal on the table is to allow the probe code to make a topological sort of the devices based on dependency information either implied, explicitly stated or both. That is likely a fundamentally correct approach. I believe some of the issues that need to be resolved are: 1) What constitutes a dependency? 2) How is that dependency expressed? 3) How do we add missing dependencies? 4) Backward compatability problems. There are other questions, of course. Is it a topsort per bus? Are there required "early devices"? Should the inter-node dependencies be expressed at each node, or in a separate hierarchy within the DTS? Others. HTH, jdl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Fri, Aug 22, 2014 at 02:19:19PM +0100, Mark Rutland wrote: > On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote: > > Am 21.08.2014 16:02, schrieb Thierry Reding: > > > > > Anyway, those are all fairly standard reasons for where deferred probe > > > triggers, and since I do like deferred probe for it's simplicity and > > > reliability I'd rather not try to work around it if boot time is all > > > that people are concerned about. > > > > It's neither simple nor reliable. It's non deterministic brutforcing > > while making it almost impossible to identify real errors. > > It's horrible, yes. > > > In my humble opinion the worst way to solve something. I'm pretty sure > > if I would have suggest such a solution, the maintainer crowd would have > > eaten me without cooking. > > We didn't have a better workable solution at the time. You make it sound like we've come up with a better workable solution in the meantime. > Having a hack that got boards booting was considered better than not > having them boot. > I don't remember people being particularly enthralled by the idea. Odd, I remember things quite differently. Anyway, instead of going back and forth between "deferred probe is good" and "deferred probe is bad", how about we do something useful now and concentrate on how to make use of the information we have in DT with the goal to reduce the number of cases where deferred probing is required? Thierry pgpIqoWjf6TQN.pgp Description: PGP signature
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 22.08.2014 15:19, schrieb Mark Rutland: On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote: Am 21.08.2014 16:02, schrieb Thierry Reding: Anyway, those are all fairly standard reasons for where deferred probe triggers, and since I do like deferred probe for it's simplicity and reliability I'd rather not try to work around it if boot time is all that people are concerned about. It's neither simple nor reliable. It's non deterministic brutforcing while making it almost impossible to identify real errors. It's horrible, yes. In my humble opinion the worst way to solve something. I'm pretty sure if I would have suggest such a solution, the maintainer crowd would have eaten me without cooking. We didn't have a better workable solution at the time. Having a hack that got boards booting was considered better than not having them boot. I don't remember people being particularly enthralled by the idea. Agreed. And usually I don't flame about workarounds. They are needed practice usually born out of a time limited background or similiar constraints. Only Linux kernel maintainers do demand perfect stuff from others as the kernel seems to have to be a perfect school project. I for myself already think checkpatch is a ridiculous tool, only invented to drive people crazy. Of course, it's better a tool drives people crazy than a maintainer who make decisions based on the phase of the moon, but ... ;) And I haven't flamed much about deferred probe before, but if I read it's simple and reliable I couldn't stand still. Sorry, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote: > Am 21.08.2014 16:02, schrieb Thierry Reding: > > > Anyway, those are all fairly standard reasons for where deferred probe > > triggers, and since I do like deferred probe for it's simplicity and > > reliability I'd rather not try to work around it if boot time is all > > that people are concerned about. > > It's neither simple nor reliable. It's non deterministic brutforcing > while making it almost impossible to identify real errors. It's horrible, yes. > In my humble opinion the worst way to solve something. I'm pretty sure > if I would have suggest such a solution, the maintainer crowd would have > eaten me without cooking. We didn't have a better workable solution at the time. Having a hack that got boards booting was considered better than not having them boot. I don't remember people being particularly enthralled by the idea. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 21.08.2014 16:02, schrieb Thierry Reding: Anyway, those are all fairly standard reasons for where deferred probe triggers, and since I do like deferred probe for it's simplicity and reliability I'd rather not try to work around it if boot time is all that people are concerned about. It's neither simple nor reliable. It's non deterministic brutforcing while making it almost impossible to identify real errors. In my humble opinion the worst way to solve something. I'm pretty sure if I would have suggest such a solution, the maintainer crowd would have eaten me without cooking. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Wed, May 14, 2014 at 03:19:14PM +0100, Grant Likely wrote: > On Mon, 12 May 2014 18:47:51 +0200, Alexander Holler > wrote: > > > > Hello, > > > > if I would have to describe the Linux kernels init system (before userspace > > starts), it would be like: > > Unknown functions with almost unknown functionality are called in an almost > > random order. > > > > That reminded me that a kernel-maintainer once said to me: > > "We should aim to make things synchronous, deterministic and > > stuff-happens-in-the-correct-order." > > > > Looks like either the target moved or no Wilhelm Tell was around. ;) > > > > This is an attempt to reach the target for the case of (platform-)drivers. > > It is a mere starting point to reach the final target but it works on two > > DT enabled ARM devices I have and it hasn't any implications on other > > architectures, platforms or whatever. If the new configuration option, > > which is only available if DT is enabled, isn't turned on, there is no > > increase of code size or similiar. > > > > So what are these patches I'm posting here? > > They offer an imho solid base to fix the 3. problem. they build a > > deterministic > > order in which (platform-)drivers should be initialized, based on datas > > (dependencies) found in the device tree. They also offer a starting point > > to fix > > the other 2 problems (unknown functions and unknown functionality) by > > showing a > > way how the long range target of known functions with known functionality > > could > > be reached. > > > > Unfortunately work still isn't done. As written above, this is just a > > starting > > point, neiter complete nor perfect. It is what I could do behind closed > > doors, > > by spending a limited amount of time and resources (I've started to look at > > that stuff 3-4 weeks ago, sometimes after 3.14 appeared), so it can be > > blamed > > quick & dirty. But it should be already enough to explain and test the > > concepts. > > > > Enough forewords. > > > > This is a small patch series to use a deterministic dependency based device > > and driver initialization order on machines which are using device tree. > > The dependency graph will not only be build based on the device tree itself, > > but will use dependencies based on phandle references in the .dts, > > automatically added by dtc through a new property. > > Manualy adding dependencies to the .dts is possible too. > > > > Advantages: > > > > - Correct order of initialization without any "dirty tricks" in drivers or > > the > > machine init code. The order in which devices/drivers will be initialized > > depends only on the DT and the topological sort algorithm used by the > > kernel, not some code elsewhere. That means less code and more homogeneity > > across different SOCs. > > - Might be(come) a little faster because the number of deferred probes > > should > > be minimized (they might not even be necessary anymore at all). > > - Using a modified algorithm, it's possible to build a list of drivers which > > can be initialized in parallel, e.g. using n threads, where n equals the > > number of cores. I have not tested nor implemented it, because I don't > > have > > any multicore DT based board with which I easily can use a (patched) > > mainline > > kernel, just locked down multicore things I don't want to go through the > > pain of unlocking them. > > - Funny dependency graphs when using Graphviz. > > > > Disadvantages: > > > > - To use this feature correctly, binary blobs must be regenerated by > > recompiling them to include properties with dependencies. Without > > recompiling them there will be no advantage. > > Rather than a dtb schema change, for the most common properties (irqs, > clocks, gpios), we could extract dependencies at boot time. I don't like > the idea of adding a separate depends-on property because it is very > easy to get it out of sync with the actual binding data (dtc is not the > only tool that manipulates .dtbs. Firmware will fiddle with it too). Sorry for reviving this old thread, but this issue keeps popping up time and time again and people are starting to think about ways to workaround deferred probe being slow. I'd very much prefer to avoid that and just keep using deferred probing as the one means to resolve dependencies at boot time, but at the same time I can't ignore when several people start complaining about the same thing. This very recently popped up again in the context of DRM and panels. One user complaints that in some cases, deferred probe increases boot time by 1.5 seconds (best case) and 5-6 seconds (worst case). That doesn't sound all that much, objectively, but if the boot time of the device is on the order of 6 seconds or so, then it's quite a lot. The reason why this happens is that the DRM driver looks up a panel connected to it and return -EPROBE_DEFER if the panel hasn't registered yet. Typically the panel would be probed after the DRM drive
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 21:24, schrieb Alexander Holler:
> Am 14.05.2014 21:06, schrieb Rob Herring:
>> I still have not seen an example of A depends on B, deferred probe
>> fails because of ? and here is the code for A that works around the
>> problem.
>>
>>> Anyway, this feature is totally independ of the deferred probe stuff and
>>> both can friendly live together.
>>
>> Yes, except then we get to maintain both.
And just in case someone still hasn't realized what the goal of a
deterministic initialization order is, have a look at this snippet from
arch/arm/mach-omap2/gpio.c:
/*
* gpio_init needs to be done before
* machine_init functions access gpio APIs.
* Hence gpio_init is a omap_postcore_initcall.
*/
static int __init omap2_gpio_init(void)
{
/* If dtb is there, the devices will be created dynamically */
if (of_have_populated_dt())
return -ENODEV;
return omap_hwmod_for_each_by_class("gpio", omap2_gpio_dev_init, NULL);
}
omap_postcore_initcall(omap2_gpio_init);
(Sorry to the OMAP guys, it isn't there fault that it has to look like
this.)
But this is ecactly what should be avoided and why the kernel is in need
of a deterministic, easy to setup, initialization order. And deferred
probes are in now way a help to reach that target, in fact they even
support such stuff. Does anybody outside the OMAP crew do understand
what that piece of code does? The answer is pretty likely no. Again
sorry to the OMAP guys, I'm pretty sure that code was born out of
necessity because no other mechanism is available to get things in order.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 21:06, schrieb Rob Herring: > On Wed, May 14, 2014 at 12:45 PM, Alexander Holler > wrote: >> Am 14.05.2014 19:30, schrieb Rob Herring: >> >>> On Wed, May 14, 2014 at 11:23 AM, Alexander Holler >>> wrote: Am 14.05.2014 18:05, schrieb Grant Likely: > On Wed, May 14, 2014 at 4:02 PM, Alexander Holler > wrote: >> >> >> Am 14.05.2014 16:19, schrieb Grant Likely: >> >> >>> Rather than a dtb schema change, for the most common properties (irqs, >>> clocks, gpios), we could extract dependencies at boot time. I don't >>> like >>> the idea of adding a separate depends-on property because it is very >>> easy to get it out of sync with the actual binding data (dtc is not >>> the >>> only tool that manipulates .dtbs. Firmware will fiddle with it too). >> >> >> >> >> Then that stuff has to fiddle correct. Sorry, but trying to solve all >> problems right from the beginning just leads to endless talks with no >> end >> and nothing will happen at all because nobody aggrees how to start. > > > > I appreciate the problem that you're trying to solve and why you're > using the dtc approach. My job is to poke at the solution and make > sure it is going to be reliable. Making sure all users know how to > fiddle with the new property correctly is not a trivial problem, > especially when it is firmware that will not necessarily be updated. The answer is just that they don't have to use this feature. >>> >>> >>> It's not just about users, but maintainers have to carry the code and >>> anything tied to DT is difficult to change or remove. >>> >>> Lots of inter-dependencies are already described in DT. We should >>> leverage those first and then look at how to add dependencies that are >>> not described. >> >> >> Again, that's what this feature is about. One of the problems it solves is >> that those dependencies which are described in the DT source in form of >> phandle reference, do disappear in the blobs because the init-system would >> have to know all bindings in order to identify phandle references (the >> dependencies) again. > > They don't disappear, but they become binding specific to recover. > What you are loosing is type information which is something we would > like to solve as well. > > You can regenerate or figure out the dependencies with knowledge of > the binding. The of_irq_init code does this. Maintaining this > information in the dtb that can be parsed in a generic way and having > the kernel handle non-bus oriented dependencies are really 2 separate > problems. Let's not try to solve it all at once. > Btw. I wonder if you have really read what I did and what I have written. At first the need for knowledge of the binding is broken by design and will never work for any general solution. Second, I've already written almost the same as you've written in your first paragraph in my pragraph you've just quoted directly above. And third, if you like to solve that problem, I just posted a possible solution. ;) You only have to take it, feel free to so, all the patches do contain a Signed-off-by which means that I don't care much what you do with them. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 21:06, schrieb Rob Herring: On Wed, May 14, 2014 at 12:45 PM, Alexander Holler wrote: Am 14.05.2014 19:30, schrieb Rob Herring: On Wed, May 14, 2014 at 11:23 AM, Alexander Holler wrote: Am 14.05.2014 18:05, schrieb Grant Likely: On Wed, May 14, 2014 at 4:02 PM, Alexander Holler wrote: Am 14.05.2014 16:19, schrieb Grant Likely: Rather than a dtb schema change, for the most common properties (irqs, clocks, gpios), we could extract dependencies at boot time. I don't like the idea of adding a separate depends-on property because it is very easy to get it out of sync with the actual binding data (dtc is not the only tool that manipulates .dtbs. Firmware will fiddle with it too). Then that stuff has to fiddle correct. Sorry, but trying to solve all problems right from the beginning just leads to endless talks with no end and nothing will happen at all because nobody aggrees how to start. I appreciate the problem that you're trying to solve and why you're using the dtc approach. My job is to poke at the solution and make sure it is going to be reliable. Making sure all users know how to fiddle with the new property correctly is not a trivial problem, especially when it is firmware that will not necessarily be updated. The answer is just that they don't have to use this feature. It's not just about users, but maintainers have to carry the code and anything tied to DT is difficult to change or remove. Lots of inter-dependencies are already described in DT. We should leverage those first and then look at how to add dependencies that are not described. Again, that's what this feature is about. One of the problems it solves is that those dependencies which are described in the DT source in form of phandle reference, do disappear in the blobs because the init-system would have to know all bindings in order to identify phandle references (the dependencies) again. They don't disappear, but they become binding specific to recover. What you are loosing is type information which is something we would like to solve as well. You can regenerate or figure out the dependencies with knowledge of the binding. The of_irq_init code does this. Maintaining this information in the dtb that can be parsed in a generic way and having the kernel handle non-bus oriented dependencies are really 2 separate problems. Let's not try to solve it all at once. I'm not saying flat out 'no' here, but before I merge anything, I have to be reasonably certain that the feature is not going to represent a maintenance nightmare over the long term. The maintenance nightmare is already present in form of all the workarounds which are trying to fix the initialzation order necessary for modern hardware. Do you have concrete examples or cases where deferred probe does not work? Why do people come back to the deferred probe stuff? Because it is there today and generally works. One of the biggest problem of the deferred probe stuff is the problem how to identify real problems if everything ends up with a deferred probe when an error occurs? That means if you display an error whenever something is deferred, the log becomes almost unreadable. If you don't display an error, you never will see an error. And how do you display the real error when deferred probes finally do fail? The deferred probe stuff doesn't has any information about the underlying error, so it can't display it. This all sounds like "I don't like deferred probe because it is hard to debug" to me. This all sounds solvable with better instrumentation and debug capability. Why probe is deferred should be available at the source when deciding to return -EPROBE_DEFER. I still have not seen an example of A depends on B, deferred probe fails because of ? and here is the code for A that works around the problem. Anyway, this feature is totally independ of the deferred probe stuff and both can friendly live together. Yes, except then we get to maintain both. Goodbye and thanks for all the fish. Sorry, but my patience in dealing with Linux kernel maintainers was already almost zero before I've posted these patches and I have to realize that only fools still try to do so. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 20:16, schrieb Alexander Holler: Am 14.05.2014 19:53, schrieb Alexander Holler: Am 14.05.2014 19:45, schrieb Alexander Holler: One of the biggest problem of the deferred probe stuff is the problem how to identify real problems if everything ends up with a deferred probe when an error occurs? That means if you display an error whenever something is deferred, the log becomes almost unreadable. If you don't display an error, you never will see an error. And how do you display the real error when deferred probes finally do fail? The deferred probe stuff doesn't has any information about the underlying error, so it can't display it. And that is a real problem. I've recently tried to identify why a driver failed and it was a nightmare because nothing offered any message (debug or not) when a probe was deferred. So I had to insert tons of printks to walk upwards to find the finally place where the probe failed. Everything afterwards just has forwarded the -EPROBE_DEFER without printing any message. To add some numbers, I had to insert around 20-30 printks in around 10 or more files to find the underlying problem. Having to do such whenever an error happens because everything assumes the error will disappear in a later try, which doesn't happen for real errors, is just a nightmare. And to give other people an idea how such a nightmare which has become reality does look like: You see a driver fails (through the deferred stuff). You look at that the driver and see around 5-10 places which return or forward an -EPROBE_DEFER. You add printks (to all or just some of them, hopefully the right ones, but Murphy ...). Then you go to the underlying functions. You see again several places which do the same, you add again printks. You go to the underlying functions ... Finally you've created a tree full with nodes of printks, searching for the one leaf which is the origin of the -EPROBE_DEFER for your problem. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Wed, May 14, 2014 at 12:45 PM, Alexander Holler wrote: > Am 14.05.2014 19:30, schrieb Rob Herring: > >> On Wed, May 14, 2014 at 11:23 AM, Alexander Holler >> wrote: >>> >>> Am 14.05.2014 18:05, schrieb Grant Likely: >>> On Wed, May 14, 2014 at 4:02 PM, Alexander Holler wrote: > > > Am 14.05.2014 16:19, schrieb Grant Likely: > > >> Rather than a dtb schema change, for the most common properties (irqs, >> clocks, gpios), we could extract dependencies at boot time. I don't >> like >> the idea of adding a separate depends-on property because it is very >> easy to get it out of sync with the actual binding data (dtc is not >> the >> only tool that manipulates .dtbs. Firmware will fiddle with it too). > > > > > Then that stuff has to fiddle correct. Sorry, but trying to solve all > problems right from the beginning just leads to endless talks with no > end > and nothing will happen at all because nobody aggrees how to start. I appreciate the problem that you're trying to solve and why you're using the dtc approach. My job is to poke at the solution and make sure it is going to be reliable. Making sure all users know how to fiddle with the new property correctly is not a trivial problem, especially when it is firmware that will not necessarily be updated. >>> >>> >>> >>> The answer is just that they don't have to use this feature. >> >> >> It's not just about users, but maintainers have to carry the code and >> anything tied to DT is difficult to change or remove. >> >> Lots of inter-dependencies are already described in DT. We should >> leverage those first and then look at how to add dependencies that are >> not described. > > > Again, that's what this feature is about. One of the problems it solves is > that those dependencies which are described in the DT source in form of > phandle reference, do disappear in the blobs because the init-system would > have to know all bindings in order to identify phandle references (the > dependencies) again. They don't disappear, but they become binding specific to recover. What you are loosing is type information which is something we would like to solve as well. You can regenerate or figure out the dependencies with knowledge of the binding. The of_irq_init code does this. Maintaining this information in the dtb that can be parsed in a generic way and having the kernel handle non-bus oriented dependencies are really 2 separate problems. Let's not try to solve it all at once. I'm not saying flat out 'no' here, but before I merge anything, I have to be reasonably certain that the feature is not going to represent a maintenance nightmare over the long term. >>> >>> >>> >>> The maintenance nightmare is already present in form of all the >>> workarounds >>> which are trying to fix the initialzation order necessary for modern >>> hardware. >> >> >> Do you have concrete examples or cases where deferred probe does not work? > > > Why do people come back to the deferred probe stuff? Because it is there today and generally works. > One of the biggest problem of the deferred probe stuff is the problem how to > identify real problems if everything ends up with a deferred probe when an > error occurs? That means if you display an error whenever something is > deferred, the log becomes almost unreadable. If you don't display an error, > you never will see an error. And how do you display the real error when > deferred probes finally do fail? The deferred probe stuff doesn't has any > information about the underlying error, so it can't display it. This all sounds like "I don't like deferred probe because it is hard to debug" to me. This all sounds solvable with better instrumentation and debug capability. Why probe is deferred should be available at the source when deciding to return -EPROBE_DEFER. I still have not seen an example of A depends on B, deferred probe fails because of ? and here is the code for A that works around the problem. > Anyway, this feature is totally independ of the deferred probe stuff and > both can friendly live together. Yes, except then we get to maintain both. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 19:53, schrieb Alexander Holler: Am 14.05.2014 19:45, schrieb Alexander Holler: One of the biggest problem of the deferred probe stuff is the problem how to identify real problems if everything ends up with a deferred probe when an error occurs? That means if you display an error whenever something is deferred, the log becomes almost unreadable. If you don't display an error, you never will see an error. And how do you display the real error when deferred probes finally do fail? The deferred probe stuff doesn't has any information about the underlying error, so it can't display it. And that is a real problem. I've recently tried to identify why a driver failed and it was a nightmare because nothing offered any message (debug or not) when a probe was deferred. So I had to insert tons of printks to walk upwards to find the finally place where the probe failed. Everything afterwards just has forwarded the -EPROBE_DEFER without printing any message. To add some numbers, I had to insert around 20-30 printks in around 10 or more files to find the underlying problem. Having to do such whenever an error happens because everything assumes the error will disappear in a later try, which doesn't happen for real errors, is just a nightmare. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 19:45, schrieb Alexander Holler: One of the biggest problem of the deferred probe stuff is the problem how to identify real problems if everything ends up with a deferred probe when an error occurs? That means if you display an error whenever something is deferred, the log becomes almost unreadable. If you don't display an error, you never will see an error. And how do you display the real error when deferred probes finally do fail? The deferred probe stuff doesn't has any information about the underlying error, so it can't display it. And that is a real problem. I've recently tried to identify why a driver failed and it was a nightmare because nothing offered any message (debug or not) when a probe was deferred. So I had to insert tons of printks to walk upwards to find the finally place where the probe failed. Everything afterwards just has forwarded the -EPROBE_DEFER without printing any message. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 19:30, schrieb Rob Herring: On Wed, May 14, 2014 at 11:23 AM, Alexander Holler wrote: Am 14.05.2014 18:05, schrieb Grant Likely: On Wed, May 14, 2014 at 4:02 PM, Alexander Holler wrote: Am 14.05.2014 16:19, schrieb Grant Likely: Rather than a dtb schema change, for the most common properties (irqs, clocks, gpios), we could extract dependencies at boot time. I don't like the idea of adding a separate depends-on property because it is very easy to get it out of sync with the actual binding data (dtc is not the only tool that manipulates .dtbs. Firmware will fiddle with it too). Then that stuff has to fiddle correct. Sorry, but trying to solve all problems right from the beginning just leads to endless talks with no end and nothing will happen at all because nobody aggrees how to start. I appreciate the problem that you're trying to solve and why you're using the dtc approach. My job is to poke at the solution and make sure it is going to be reliable. Making sure all users know how to fiddle with the new property correctly is not a trivial problem, especially when it is firmware that will not necessarily be updated. The answer is just that they don't have to use this feature. It's not just about users, but maintainers have to carry the code and anything tied to DT is difficult to change or remove. Lots of inter-dependencies are already described in DT. We should leverage those first and then look at how to add dependencies that are not described. Again, that's what this feature is about. One of the problems it solves is that those dependencies which are described in the DT source in form of phandle reference, do disappear in the blobs because the init-system would have to know all bindings in order to identify phandle references (the dependencies) again. It is more meant as a long-term solution to fix for the problem of increasing hard-coded workarounds which all are trying to fix the initialization order of drivers. Hardware has become a lot more complicated than it was in the good old days, and I think the time is right trying to adopt the init-system to this new century instead of still adding workarounds here and there. I don't know when the good old days were, but this has been a problem in embedded systems for as long as I have worked on Linux. Yes, but stuff wasn't as complicated as today, which means it was relatively easy to manualy solve dependency problems. But if you look at complicated SOCs like the OMAP, it's much better to let the machine solve the dependencies to get the initialization order instead of still trying to do this manually. I'm not saying flat out 'no' here, but before I merge anything, I have to be reasonably certain that the feature is not going to represent a maintenance nightmare over the long term. The maintenance nightmare is already present in form of all the workarounds which are trying to fix the initialzation order necessary for modern hardware. Do you have concrete examples or cases where deferred probe does not work? Why do people come back to the deferred probe stuff? One of the biggest problem of the deferred probe stuff is the problem how to identify real problems if everything ends up with a deferred probe when an error occurs? That means if you display an error whenever something is deferred, the log becomes almost unreadable. If you don't display an error, you never will see an error. And how do you display the real error when deferred probes finally do fail? The deferred probe stuff doesn't has any information about the underlying error, so it can't display it. Anyway, this feature is totally independ of the deferred probe stuff and both can friendly live together. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Wed, May 14, 2014 at 11:23 AM, Alexander Holler wrote: > Am 14.05.2014 18:05, schrieb Grant Likely: > >> On Wed, May 14, 2014 at 4:02 PM, Alexander Holler >> wrote: >>> >>> Am 14.05.2014 16:19, schrieb Grant Likely: >>> >>> Rather than a dtb schema change, for the most common properties (irqs, clocks, gpios), we could extract dependencies at boot time. I don't like the idea of adding a separate depends-on property because it is very easy to get it out of sync with the actual binding data (dtc is not the only tool that manipulates .dtbs. Firmware will fiddle with it too). >>> >>> >>> >>> Then that stuff has to fiddle correct. Sorry, but trying to solve all >>> problems right from the beginning just leads to endless talks with no end >>> and nothing will happen at all because nobody aggrees how to start. >> >> >> I appreciate the problem that you're trying to solve and why you're >> using the dtc approach. My job is to poke at the solution and make >> sure it is going to be reliable. Making sure all users know how to >> fiddle with the new property correctly is not a trivial problem, >> especially when it is firmware that will not necessarily be updated. > > > The answer is just that they don't have to use this feature. It's not just about users, but maintainers have to carry the code and anything tied to DT is difficult to change or remove. Lots of inter-dependencies are already described in DT. We should leverage those first and then look at how to add dependencies that are not described. > It is more meant as a long-term solution to fix for the problem of > increasing hard-coded workarounds which all are trying to fix the > initialization order of drivers. Hardware has become a lot more complicated > than it was in the good old days, and I think the time is right trying to > adopt the init-system to this new century instead of still adding > workarounds here and there. I don't know when the good old days were, but this has been a problem in embedded systems for as long as I have worked on Linux. >> I'm not saying flat out 'no' here, but before I merge anything, I have >> to be reasonably certain that the feature is not going to represent a >> maintenance nightmare over the long term. > > > The maintenance nightmare is already present in form of all the workarounds > which are trying to fix the initialzation order necessary for modern > hardware. Do you have concrete examples or cases where deferred probe does not work? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 18:05, schrieb Grant Likely: On Wed, May 14, 2014 at 4:02 PM, Alexander Holler wrote: Am 14.05.2014 16:19, schrieb Grant Likely: Rather than a dtb schema change, for the most common properties (irqs, clocks, gpios), we could extract dependencies at boot time. I don't like the idea of adding a separate depends-on property because it is very easy to get it out of sync with the actual binding data (dtc is not the only tool that manipulates .dtbs. Firmware will fiddle with it too). Then that stuff has to fiddle correct. Sorry, but trying to solve all problems right from the beginning just leads to endless talks with no end and nothing will happen at all because nobody aggrees how to start. I appreciate the problem that you're trying to solve and why you're using the dtc approach. My job is to poke at the solution and make sure it is going to be reliable. Making sure all users know how to fiddle with the new property correctly is not a trivial problem, especially when it is firmware that will not necessarily be updated. The answer is just that they don't have to use this feature. It is more meant as a long-term solution to fix for the problem of increasing hard-coded workarounds which all are trying to fix the initialization order of drivers. Hardware has become a lot more complicated than it was in the good old days, and I think the time is right trying to adopt the init-system to this new century instead of still adding workarounds here and there. I'm not saying flat out 'no' here, but before I merge anything, I have to be reasonably certain that the feature is not going to represent a maintenance nightmare over the long term. The maintenance nightmare is already present in form of all the workarounds which are trying to fix the initialzation order necessary for modern hardware. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Wed, May 14, 2014 at 4:02 PM, Alexander Holler wrote: > Am 14.05.2014 16:19, schrieb Grant Likely: > > >> Rather than a dtb schema change, for the most common properties (irqs, >> clocks, gpios), we could extract dependencies at boot time. I don't like >> the idea of adding a separate depends-on property because it is very >> easy to get it out of sync with the actual binding data (dtc is not the >> only tool that manipulates .dtbs. Firmware will fiddle with it too). > > > Then that stuff has to fiddle correct. Sorry, but trying to solve all > problems right from the beginning just leads to endless talks with no end > and nothing will happen at all because nobody aggrees how to start. I appreciate the problem that you're trying to solve and why you're using the dtc approach. My job is to poke at the solution and make sure it is going to be reliable. Making sure all users know how to fiddle with the new property correctly is not a trivial problem, especially when it is firmware that will not necessarily be updated. I'm not saying flat out 'no' here, but before I merge anything, I have to be reasonably certain that the feature is not going to represent a maintenance nightmare over the long term. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 14.05.2014 16:19, schrieb Grant Likely: Rather than a dtb schema change, for the most common properties (irqs, clocks, gpios), we could extract dependencies at boot time. I don't like the idea of adding a separate depends-on property because it is very easy to get it out of sync with the actual binding data (dtc is not the only tool that manipulates .dtbs. Firmware will fiddle with it too). Then that stuff has to fiddle correct. Sorry, but trying to solve all problems right from the beginning just leads to endless talks with no end and nothing will happen at all because nobody aggrees how to start. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Mon, 12 May 2014 18:47:51 +0200, Alexander Holler wrote: > > Hello, > > if I would have to describe the Linux kernels init system (before userspace > starts), it would be like: > Unknown functions with almost unknown functionality are called in an almost > random order. > > That reminded me that a kernel-maintainer once said to me: > "We should aim to make things synchronous, deterministic and > stuff-happens-in-the-correct-order." > > Looks like either the target moved or no Wilhelm Tell was around. ;) > > This is an attempt to reach the target for the case of (platform-)drivers. > It is a mere starting point to reach the final target but it works on two > DT enabled ARM devices I have and it hasn't any implications on other > architectures, platforms or whatever. If the new configuration option, > which is only available if DT is enabled, isn't turned on, there is no > increase of code size or similiar. > > So what are these patches I'm posting here? > They offer an imho solid base to fix the 3. problem. they build a > deterministic > order in which (platform-)drivers should be initialized, based on datas > (dependencies) found in the device tree. They also offer a starting point to > fix > the other 2 problems (unknown functions and unknown functionality) by showing > a > way how the long range target of known functions with known functionality > could > be reached. > > Unfortunately work still isn't done. As written above, this is just a starting > point, neiter complete nor perfect. It is what I could do behind closed doors, > by spending a limited amount of time and resources (I've started to look at > that stuff 3-4 weeks ago, sometimes after 3.14 appeared), so it can be blamed > quick & dirty. But it should be already enough to explain and test the > concepts. > > Enough forewords. > > This is a small patch series to use a deterministic dependency based device > and driver initialization order on machines which are using device tree. > The dependency graph will not only be build based on the device tree itself, > but will use dependencies based on phandle references in the .dts, > automatically added by dtc through a new property. > Manualy adding dependencies to the .dts is possible too. > > Advantages: > > - Correct order of initialization without any "dirty tricks" in drivers or the > machine init code. The order in which devices/drivers will be initialized > depends only on the DT and the topological sort algorithm used by the > kernel, not some code elsewhere. That means less code and more homogeneity > across different SOCs. > - Might be(come) a little faster because the number of deferred probes should > be minimized (they might not even be necessary anymore at all). > - Using a modified algorithm, it's possible to build a list of drivers which > can be initialized in parallel, e.g. using n threads, where n equals the > number of cores. I have not tested nor implemented it, because I don't have > any multicore DT based board with which I easily can use a (patched) > mainline > kernel, just locked down multicore things I don't want to go through the > pain of unlocking them. > - Funny dependency graphs when using Graphviz. > > Disadvantages: > > - To use this feature correctly, binary blobs must be regenerated by > recompiling them to include properties with dependencies. Without > recompiling them there will be no advantage. Rather than a dtb schema change, for the most common properties (irqs, clocks, gpios), we could extract dependencies at boot time. I don't like the idea of adding a separate depends-on property because it is very easy to get it out of sync with the actual binding data (dtc is not the only tool that manipulates .dtbs. Firmware will fiddle with it too). g. > - Binary blobs will be slightly larger (some kb, see numbers below). > - Many .dts might need manual work to add some dependencies. Also most > dependencies will be discovered automatically (based on phandle references > in the .dts, some devices might need additional dependencies. > > > Some numbers (using kernel 3.14.3): > > Dockstar (Kirkwood): > Works out of the box. > Size of dtb without dependencies: 9166 > Size of dtb with dependencies: 9579 > Graph with 34 nodes, 56 edges > Boot to panic (no root) no deps run 1-4: > 1.325474 1.325458 1.325449 1.325494 > Boot to panic (no root) deps run 1-4: > 4.509989 4.484608 4.316221 4.485310 > The large difference in time isn't because of the depency based > init but because ehci detected the connected hd before the panic > occured when deps were enabled. Withoout deps, the panic > already happend without any discovered usb-storage. I haven't > checked why. > The actual times to boot from USB-HD are 3.417248 without > dependencies versus 5.618293 with. I still have to check where > the difference of more than
