| Message ID | 1355129761-8088-2-git-send-email-lee.jones@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Dec 10, 2012 at 08:55:50AM +0000, Lee Jones wrote: > The normal course of action would be to defer the MMCI driver too, > but these IOS level-shifter regulators aren't present on all > platforms, so deferring until one is found would be incorrect. > So the best solution is to demote the GPIO Regulator driver, so > it starts later than the TC35892 GPIO controller, which is also > configured to start at subsys_initcall() time, but before deferred > probing time, which starts at late_initcall(), after many of the > drivers requiring these regulators would have already started. This really isn't a good solution, especially not for a system that's DT based - on a DT system we can tell if there should be a GPIO present so we should be able to defer only when there's something that might provide the GPIO later on.
On Mon, 10 Dec 2012, Mark Brown wrote: > On Mon, Dec 10, 2012 at 08:55:50AM +0000, Lee Jones wrote: > > > The normal course of action would be to defer the MMCI driver too, > > but these IOS level-shifter regulators aren't present on all > > platforms, so deferring until one is found would be incorrect. > > > So the best solution is to demote the GPIO Regulator driver, so > > it starts later than the TC35892 GPIO controller, which is also > > configured to start at subsys_initcall() time, but before deferred > > probing time, which starts at late_initcall(), after many of the > > drivers requiring these regulators would have already started. > > This really isn't a good solution, especially not for a system that's DT > based - on a DT system we can tell if there should be a GPIO present so > we should be able to defer only when there's something that might > provide the GPIO later on. Understood, but what's the solution for non-DT systems?
On Mon, Dec 10, 2012 at 02:28:36PM +0000, Lee Jones wrote: > On Mon, 10 Dec 2012, Mark Brown wrote: > > This really isn't a good solution, especially not for a system that's DT > > based - on a DT system we can tell if there should be a GPIO present so > > we should be able to defer only when there's something that might > > provide the GPIO later on. > Understood, but what's the solution for non-DT systems? Provide a fixed regulator or something, perhaps we need a "definitely does not exist" regulator to help with this. For every board you help with a sequencing bodge you're probably going to break another that needs different sequencing; for that matter it's not like GPIO controlled regulators are exclusively used for MMC, or that MMC exclusively uses GPIO - doing this for only one regulator is a bit of a red flag.
On Mon, 10 Dec 2012, Mark Brown wrote: > On Mon, Dec 10, 2012 at 02:28:36PM +0000, Lee Jones wrote: > > On Mon, 10 Dec 2012, Mark Brown wrote: > > > > This really isn't a good solution, especially not for a system that's DT > > > based - on a DT system we can tell if there should be a GPIO present so > > > we should be able to defer only when there's something that might > > > provide the GPIO later on. > > > Understood, but what's the solution for non-DT systems? > > Provide a fixed regulator or something, perhaps we need a "definitely > does not exist" regulator to help with this. For every board you help > with a sequencing bodge you're probably going to break another that > needs different sequencing; for that matter it's not like GPIO > controlled regulators are exclusively used for MMC, or that MMC > exclusively uses GPIO - doing this for only one regulator is a bit of a > red flag. I understand your logic, hence why I wrote such a lengthy commit message. However, I'm not sure I see a logical way around it. Asking all users of MMCI to provide a not-regulator to declare that a secondary regulator isn't available seems a little unreasonable to me. Is there anything else we can do?
On Thu, Dec 13, 2012 at 11:55:24AM +0000, Lee Jones wrote: > I understand your logic, hence why I wrote such a lengthy commit > message. However, I'm not sure I see a logical way around it. Asking > all users of MMCI to provide a not-regulator to declare that a > secondary regulator isn't available seems a little unreasonable to me. > Is there anything else we can do? Have all the people setting up this secondary regulator explicitly declare it?
diff --git a/drivers/regulator/gpio-regulator.c b/drivers/regulator/gpio-regulator.c index 3ee79c8..1a71be2 100644 --- a/drivers/regulator/gpio-regulator.c +++ b/drivers/regulator/gpio-regulator.c @@ -383,7 +383,7 @@ static int __init gpio_regulator_init(void) { return platform_driver_register(&gpio_regulator_driver); } -subsys_initcall(gpio_regulator_init); +fs_initcall(gpio_regulator_init); static void __exit gpio_regulator_exit(void) {
We have quite a complicated hurdle we need to over-come, and this patch aims to rectify it the best way possible. We're attempting to move some MMC related voltage level-shifters out of platform code and over to the new GPIO Regulator framework. The aim of this change is to void the requirement for two separate call-backs; one from the TC35892 GPIO controller which sets up MMC level-shifter GPIOs and another from the MMCI driver to toggle the lines at the appropriate times. The issues come from device bring-up order during boot, and -EPROBE_DEFER cannot help for this particular use-case. In its current configuration the GPIO Regulator starts first. It parses the Device Tree for 'enable' and 'voltage_select' GPIOs, then requests them. However, the TC35892 GPIO controller isn't up yet so it defers probe(). By the time it re-probes, the MMCI driver has finished its probe and should have toggled the 'enable' and 'voltage_select' lines a few times already by now. The normal course of action would be to defer the MMCI driver too, but these IOS level-shifter regulators aren't present on all platforms, so deferring until one is found would be incorrect. So the best solution is to demote the GPIO Regulator driver, so it starts later than the TC35892 GPIO controller, which is also configured to start at subsys_initcall() time, but before deferred probing time, which starts at late_initcall(), after many of the drivers requiring these regulators would have already started. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> --- drivers/regulator/gpio-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)