Due to some device may need reulator operation in earlier boot time like gpu module which
power domain need regulator power on first. Move regulator of mt6397
initialization earlier in boot so that real devices can use regulator
without probe deferring.
Signed-off-by: Henry Chen <[email protected]>
---
drivers/regulator/mt6397-regulator.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/mt6397-regulator.c b/drivers/regulator/mt6397-regulator.c
index a5b2f47..9b89023 100644
--- a/drivers/regulator/mt6397-regulator.c
+++ b/drivers/regulator/mt6397-regulator.c
@@ -324,7 +324,11 @@ static struct platform_driver mt6397_regulator_driver = {
.probe = mt6397_regulator_probe,
};
-module_platform_driver(mt6397_regulator_driver);
+static int __init mt6397_regulator_init(void)
+{
+ return platform_driver_register(&mt6397_regulator_driver);
+}
+arch_initcall(mt6397_regulator_init);
MODULE_AUTHOR("Flora Fu <[email protected]>");
MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6397 PMIC");
--
1.9.1
On Wed, Dec 23, 2015 at 06:16:08PM +0800, Henry Chen wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> Due to some device may need reulator operation in earlier boot time like gpu module which
> power domain need regulator power on first. Move regulator of mt6397
> initialization earlier in boot so that real devices can use regulator
> without probe deferring.
Several problems here. One is that we usually use subsys_initcall() for
working around the known broken subsystems here, why have you decided to
go for arch_initcall() instead. Another is that you're saying this is
for GPUs but I'm not aware of any reason why GPUs are broken and we
should not be introducing new problems here - what's going on?
On Wed, 2015-12-23 at 12:00 +0000, Mark Brown wrote:
> On Wed, Dec 23, 2015 at 06:16:08PM +0800, Henry Chen wrote:
>
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns. Doing this makes your messages much
> easier to read and reply to.
>
> > Due to some device may need reulator operation in earlier boot time like gpu module which
> > power domain need regulator power on first. Move regulator of mt6397
> > initialization earlier in boot so that real devices can use regulator
> > without probe deferring.
>
> Several problems here. One is that we usually use subsys_initcall() for
> working around the known broken subsystems here, why have you decided to
> go for arch_initcall() instead. Another is that you're saying this is
> for GPUs but I'm not aware of any reason why GPUs are broken and we
> should not be introducing new problems here - what's going on?
These changes are related to pinctrl init order patch. The related
discussion is here:
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003298.html
and these should really be a series:
mediatek pwrap
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003347.html
mt6397 MFD core
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003348.html
mt6397 regulator
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003349.html
I think Henry use arch_initcall because that's what pinctrl patch was
using. In this case, we should use subsys_initcall for all these.
Joe.C