On 9 September 2015 at 03:33, Rob Herring <robh@xxxxxxxxxx> wrote: > On 09/08/2015 02:30 AM, Tomeu Vizoso wrote: >> On 7 September 2015 at 22:50, Rob Herring <robherring2@xxxxxxxxx> wrote: >>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> wrote: >>>> Hello, >>>> >>>> I have a problem with the panel on my Tegra Chromebook taking longer >>>> than expected to be ready during boot (Stéphane Marchesin reported what >>>> is basically the same issue in [0]), and have looked into ordered >>>> probing as a better way of solving this than moving nodes around in the >>>> DT or playing with initcall levels and linking order. >>>> >>>> While reading the thread [1] that Alexander Holler started with his >>>> series to make probing order deterministic, it occurred to me that it >>>> should be possible to achieve the same by probing devices as they are >>>> referenced by other devices. >>>> >>>> This basically reuses the information that is already implicit in the >>>> probe() implementations, saving us from refactoring existing drivers or >>>> adding information to DTBs. >>>> >>>> During review of v1 of this series Linus Walleij suggested that it >>>> should be the device driver core to make sure that dependencies are >>>> ready before probing a device. I gave this idea a try [2] but Mark Brown >>>> pointed out to the logic duplication between the resource acquisition >>>> and dependency discovery code paths (though I think it's fairly minor). >>>> >>>> To address that code duplication I experimented with Arnd's devm_probe >>>> [3] concept of having drivers declare their dependencies instead of >>>> acquiring them during probe, and while it worked [4], I don't think we >>>> end up winning anything when compared to just probing devices on-demand >>>> from resource getters. >>>> >>>> One remaining objection is to the "sprinkling" of calls to >>>> of_device_probe() in the resource getters of each subsystem, but I think >>>> it's the right thing to do given that the storage of resources is >>>> currently subsystem-specific. >>>> >>>> We could avoid the above by moving resource storage into the core, but I >>>> don't think there's a compelling case for that. >>>> >>>> I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and >>>> OMAP SoCs, and these patches were enough to eliminate all the deferred >>>> probes (except one in PandaBoard because omap_dma_system doesn't have a >>>> firmware node as of yet). >>>> >>>> Have submitted a branch [5] with only these patches on top of thursday's >>>> linux-next to kernelci.org and I don't see any issues that could be >>>> caused by them. For some reason it currently has more passes than the >>>> version of -next it's based on! >>>> >>>> With this series I get the kernel to output to the panel in 0.5s, >>>> instead of 2.8s. >>>> >>>> Regards, >>>> >>>> Tomeu >>>> >>>> [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html >>>> >>>> [1] https://lkml.org/lkml/2014/5/12/452 >>>> >>>> [2] https://lkml.org/lkml/2015/6/17/305 >>>> >>>> [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 >>>> >>>> [4] https://lkml.org/lkml/2015/7/21/441a >>>> >>>> [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6 >>>> >>>> [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/ >>>> >>>> [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/ >>>> >>>> Changes in v4: >>>> - Added bus.pre_probe callback so the probes of Primecell devices can be >>>> deferred if their device IDs cannot be yet read because of the clock >>>> driver not having probed when they are registered. Maybe this goes >>>> overboard and the matching information should be in the DT if there is >>>> one. >>> >>> Seems overboard to me or at least a separate problem. >> >> It's a separate problem but this was preventing the series from >> working on a few boards. > > What is the failure? Not booting? Fixing not working would certainly not > be overboard. On the device I was testing on (qemu's vexpress-a15 machine) the machine booted and I was able to open a ssh session, but serial was broken among other AMBA devices: /memory-controller@2b0a0000 /memory-controller@7ffd0000 /dma@7ffb0000 /smb/motherboard/iofpga@3,00000000/sysctl@020000 /smb/motherboard/iofpga@3,00000000/aaci@040000 /smb/motherboard/iofpga@3,00000000/mmci@050000 /smb/motherboard/iofpga@3,00000000/kmi@060000 /smb/motherboard/iofpga@3,00000000/kmi@070000 /smb/motherboard/iofpga@3,00000000/uart@090000 /smb/motherboard/iofpga@3,00000000/uart@0a0000 /smb/motherboard/iofpga@3,00000000/uart@0b0000 /smb/motherboard/iofpga@3,00000000/uart@0c0000 /smb/motherboard/iofpga@3,00000000/wdt@0f0000 /smb/motherboard/iofpga@3,00000000/timer@110000 /smb/motherboard/iofpga@3,00000000/timer@120000 /smb/motherboard/iofpga@3,00000000/rtc@170000 /smb/motherboard/iofpga@3,00000000/clcd@1f0000 Another way of avoiding this particular problem would be not delaying the probe of devices in the configuration bus, by doing something like this: diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c index 6575c0fe6a4e..eda293869cd3 100644 --- a/drivers/bus/vexpress-config.c +++ b/drivers/bus/vexpress-config.c @@ -181,7 +181,7 @@ static int vexpress_config_populate(struct device_node *node) if (WARN_ON(!parent)) return -ENODEV; - return of_platform_populate(node, NULL, NULL, parent); + return of_platform_populate_early(node, NULL, NULL, parent); } static int __init vexpress_config_init(void) But I think this would be papering over the underlying issue and it would be better to have proper explicit dependencies. Regards, Tomeu >>> Most clocks have >>> to be setup before the driver model simply because timers depend on >>> clocks usually. >> >> Yes, but in this case the apb clocks for the primecell devices are >> implemented in a normal platform driver (vexpress_osc_driver), instead >> of using CLK_OF_DECLARE. > > Okay. > > Rob > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
