On 06/11/2015 10:15 AM, Linus Walleij wrote: > On Wed, Jun 10, 2015 at 12:19 PM, Tomeu Vizoso > <tomeu.vizoso@xxxxxxxxxxxxx> wrote: >> On 10 June 2015 at 09:30, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > >>> regulator_get(...) -> not available, so: >>> - identify target regulator provider - this will need instrumentation >>> - probe it >>> >>> It then turns out the regulator driver is on the i2c bus, so we >>> need to probe the i2c driver: >>> - identify target i2c host for the regulator driver - this will need >>> instrumentation >>> - probe the i2c host driver >>> >>> i2c host comes out, probes the regulator driver, regulator driver >>> probes and then the regulator_get() call returns. >> >> Hmm, if I understand correctly what you say, this is exactly what this >> particular series does: >> >> regulator_get -> of_platform_device_ensure -> probe() on the platform >> device that encloses the requested device node (i2c host) -> i2c slave >> gets probed and the regulator registered -> regulator_get returns the >> requested resource > > Yes. But only for device tree. > >> The downside I'm currently looking at is that an explicit dependency >> graph would be useful to have for other purposes. For example to print >> a neat warning when a dependency cannot be fulfilled. Or to refuse to >> unbind a device which other devices depend on, or to automatically >> unbind the devices that depend on it, or to print a warning if a >> device is hotplugged off and other devices depend on it. > > Unbind/remove() calls are the inverse usually yes. > > But also the [runtime] power up/down sequences for the > devices tend to depend on a similar ordering or mostly > the same. (Mentioned this before I think.) > >>> This requires instrumentation on anything providing a resource >>> to another driver like those I mentioned and a lot of overhead >>> infrastructure, but I think it's the right approach. However I don't >>> know if I would ever be able to pull that off myself, I know talk >>> is cheap and I should show the code instead. >> >> Yeah, if you can give it a second look and say if it matches what you >> wrote above, it would be very much appreciated. > > Yes you are right. But what about ACPI, board files, > Simple Firmware and future hardware description languages... Ah ok, got it now. With fwnode and by moving a bit of code around that shouldn't be a problem. I'm actually now implementing the alternative approach in which dependencies are discovered before the device is probed, then probed in turn until all are available. So functionally is very similar but I expect to find big differences in how the codebase is impacted. Regards, Tomeu > Yours, > Linus Walleij > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
