On 02/14/2013 02:40 PM, Doug Anderson wrote: > On Wed, Feb 13, 2013 at 4:54 PM, Doug Anderson <[email protected]> wrote: >>>>> You should be able to replace all that with: >>>>> >>>>> module_platform_driver(&i2c_arbitrator_driver); ... > OK, so I dug into my problems here a little bit. All of the problems > are with a private branch that includes stuff not fully upstream, > but... > > The problem is that we've got a regulator (tps65090) on this bus. > Right now the first code that wants to use tps65090 runs from the > set_power() callback of "platform-lcd". It looks like: > lcd_fet = regulator_get(NULL, "lcd_vdd"); > > ...and "platform-lcd" is instantiated really early via > platform_device_register() for some reason. > > I tried to fix it by moving platform-lcd to actually be instantiated > via the device tree (with platform data populated through > of_platform_populate). I then hooked up regulators through the device > tree:
It shouldn't matter when the platform-lcd device is instantiated, so doing it via a board file vs. a device tree shouldn't make much difference. ... > ...but when I moved to module_platform_driver() then things still broke. > > [ 1.510000] platform-lcd supply lcd_vdd not found, using dummy regulator What prints that? I assume that's some error-handling logic in the platform-lcd driver. It's probably not detecting an -EPROBE_DEFFERED return from regulator_get() correctly, and hence proceeding with the probe() when it should simply return and let the kernel retry the probe() later. > I was sorta hoping that there would be some magic where > regulator_get() would find the device tree node for the regulator and > then resolve the chain. ...but maybe that's a pipe dream. regulator_get() won't forcibly probe() the whole dependency chain. The idea is that if a driver tries to get a resource, and it fails with -EPROBE_DEFER, the requesting driver should fail its own probe() with that same error code, and the driver core will retry the failed probe() later when the resource is hopefully available. > Is there some better way I should be expressing dependencies? Do I > need to try to hack something together with -EAGAIN (ick!)? Yes, basically. -EPROBE_DEFER specifically, although that might be an alias for -EGAIN; I can't remember which way that went. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
