* [PATCH] gpio: gpio-rcar: init at postcore level
@ 2014-02-23 16:37 vladimir.barinov
2014-02-23 19:09 ` Ben Dooks
2014-02-24 2:57 ` Magnus Damm
0 siblings, 2 replies; 6+ messages in thread
From: vladimir.barinov @ 2014-02-23 16:37 UTC (permalink / raw)
To: linux-sh
Cc: linus.walleij, linux-gpio, magnus.damm, horms, gnurou,
linux-kernel, kuninori.morimoto.gx
From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This adds ability to use gpio API at board init_machine level.
F.e. it can be used in the following situation.
Many reference hardware has onboard switches that selects which periferals
to connect to the system. The gpio input state from switches can be used
in choosing platform devices runtime in board code instead of ifdefs/defconfig
changes.
Signed-off-by: <vladimir.barinov@cogentembedded.com>
---
drivers/gpio/gpio-rcar.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
Index: build/drivers/gpio/gpio-rcar.c
===================================================================
--- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400
+++ build/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:52.320229133 +0400
@@ -485,7 +485,17 @@
}
};
-module_platform_driver(gpio_rcar_device_driver);
+static int __init gpio_rcar_init(void)
+{
+ return platform_driver_register(&gpio_rcar_device_driver);
+}
+postcore_initcall(gpio_rcar_init);
+
+static void __exit gpio_rcar_exit(void)
+{
+ platform_driver_unregister(&gpio_rcar_device_driver);
+}
+module_exit(gpio_rcar_exit);
MODULE_AUTHOR("Magnus Damm");
MODULE_DESCRIPTION("Renesas R-Car GPIO Driver");
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] gpio: gpio-rcar: init at postcore level 2014-02-23 16:37 [PATCH] gpio: gpio-rcar: init at postcore level vladimir.barinov @ 2014-02-23 19:09 ` Ben Dooks 2014-02-24 7:46 ` Vladimir Barinov 2014-02-24 2:57 ` Magnus Damm 1 sibling, 1 reply; 6+ messages in thread From: Ben Dooks @ 2014-02-23 19:09 UTC (permalink / raw) To: vladimir.barinov Cc: linux-sh, linus.walleij, linux-gpio, magnus.damm, horms, gnurou, linux-kernel, kuninori.morimoto.gx On 23/02/14 16:37, vladimir.barinov@cogentembedded.com wrote: > From: Vladimir Barinov <vladimir.barinov@cogentembedded.com> > > This adds ability to use gpio API at board init_machine level. > > F.e. it can be used in the following situation. > Many reference hardware has onboard switches that selects which periferals > to connect to the system. The gpio input state from switches can be used > in choosing platform devices runtime in board code instead of ifdefs/defconfig > changes. Firstly, anyone still using platform_devices to describe their system needs to be stopped. We cannot go on supporting this when our primary boot method is supposed to be device-tree. If we keep doing this then we will not get any of the current issues fixed. Will it impact the devicetree bindings on rcar? -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gpio: gpio-rcar: init at postcore level 2014-02-23 19:09 ` Ben Dooks @ 2014-02-24 7:46 ` Vladimir Barinov 0 siblings, 0 replies; 6+ messages in thread From: Vladimir Barinov @ 2014-02-24 7:46 UTC (permalink / raw) To: Ben Dooks Cc: linux-sh, linus.walleij, linux-gpio, magnus.damm, horms, gnurou, linux-kernel, kuninori.morimoto.gx Hello Ben, On 02/23/2014 11:09 PM, Ben Dooks wrote: > On 23/02/14 16:37, vladimir.barinov@cogentembedded.com wrote: >> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com> >> >> This adds ability to use gpio API at board init_machine level. >> >> F.e. it can be used in the following situation. >> Many reference hardware has onboard switches that selects which >> periferals >> to connect to the system. The gpio input state from switches can be used >> in choosing platform devices runtime in board code instead of >> ifdefs/defconfig >> changes. > > Firstly, anyone still using platform_devices to describe their > system needs to be stopped. We cannot go on supporting this when > our primary boot method is supposed to be device-tree. If we keep > doing this then we will not get any of the current issues fixed. Understand. I see that this is not a time for such changes. Hope that the DT model will take into account such kind of situation in the future. > > Will it impact the devicetree bindings on rcar? No Regards, Vladimir ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gpio: gpio-rcar: init at postcore level 2014-02-23 16:37 [PATCH] gpio: gpio-rcar: init at postcore level vladimir.barinov 2014-02-23 19:09 ` Ben Dooks @ 2014-02-24 2:57 ` Magnus Damm 2014-02-24 7:42 ` Vladimir Barinov 1 sibling, 1 reply; 6+ messages in thread From: Magnus Damm @ 2014-02-24 2:57 UTC (permalink / raw) To: vladimir.barinov Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms], Alexandre Courbot, linux-kernel, Kuninori Morimoto Hi Vladimir, On Mon, Feb 24, 2014 at 1:37 AM, <vladimir.barinov@cogentembedded.com> wrote: > From: Vladimir Barinov <vladimir.barinov@cogentembedded.com> > > This adds ability to use gpio API at board init_machine level. > > F.e. it can be used in the following situation. > Many reference hardware has onboard switches that selects which periferals > to connect to the system. The gpio input state from switches can be used > in choosing platform devices runtime in board code instead of ifdefs/defconfig > changes. > > Signed-off-by: <vladimir.barinov@cogentembedded.com> > > --- > drivers/gpio/gpio-rcar.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > Index: build/drivers/gpio/gpio-rcar.c > =================================================================== > --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400 > +++ build/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:52.320229133 +0400 > @@ -485,7 +485,17 @@ > } > }; > > -module_platform_driver(gpio_rcar_device_driver); > +static int __init gpio_rcar_init(void) > +{ > + return platform_driver_register(&gpio_rcar_device_driver); > +} > +postcore_initcall(gpio_rcar_init); > + > +static void __exit gpio_rcar_exit(void) > +{ > + platform_driver_unregister(&gpio_rcar_device_driver); > +} > +module_exit(gpio_rcar_exit); > > MODULE_AUTHOR("Magnus Damm"); > MODULE_DESCRIPTION("Renesas R-Car GPIO Driver"); Hi Vladimir, Thanks for your help. Good to see that you are working on enabling the dual role USB port on Koelsch. Your current board code is checking some DIP switch value during boot, and that kind of early use of GPIO would require a change in the probe order like this patch implements. I do however believe that we should not implement checking during boot like this. If you for instance check the legacy Lager USBHS DIP switch code that runs during driver probe() then that can run can use GPIO without the need for a change like this. So your GPIO user code needs to be adjusted. So this patch will receive a NAK from me I'm afraid. Thanks, / magnus ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gpio: gpio-rcar: init at postcore level 2014-02-24 2:57 ` Magnus Damm @ 2014-02-24 7:42 ` Vladimir Barinov 2014-02-24 7:55 ` Magnus Damm 0 siblings, 1 reply; 6+ messages in thread From: Vladimir Barinov @ 2014-02-24 7:42 UTC (permalink / raw) To: Magnus Damm Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms], Alexandre Courbot, linux-kernel, Kuninori Morimoto Hi Magnus, On 02/24/2014 06:57 AM, Magnus Damm wrote: > Hi Vladimir, > > On Mon, Feb 24, 2014 at 1:37 AM,<vladimir.barinov@cogentembedded.com> wrote: >> From: Vladimir Barinov<vladimir.barinov@cogentembedded.com> >> >> This adds ability to use gpio API at board init_machine level. >> >> F.e. it can be used in the following situation. >> Many reference hardware has onboard switches that selects which periferals >> to connect to the system. The gpio input state from switches can be used >> in choosing platform devices runtime in board code instead of ifdefs/defconfig >> changes. >> >> Signed-off-by:<vladimir.barinov@cogentembedded.com> >> >> --- >> drivers/gpio/gpio-rcar.c | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> Index: build/drivers/gpio/gpio-rcar.c >> =================================================================== >> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 +0400 >> +++ build/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:52.320229133 +0400 >> @@ -485,7 +485,17 @@ >> } >> }; >> >> -module_platform_driver(gpio_rcar_device_driver); >> +static int __init gpio_rcar_init(void) >> +{ >> + return platform_driver_register(&gpio_rcar_device_driver); >> +} >> +postcore_initcall(gpio_rcar_init); >> + >> +static void __exit gpio_rcar_exit(void) >> +{ >> + platform_driver_unregister(&gpio_rcar_device_driver); >> +} >> +module_exit(gpio_rcar_exit); >> >> MODULE_AUTHOR("Magnus Damm"); >> MODULE_DESCRIPTION("Renesas R-Car GPIO Driver"); > Hi Vladimir, > > Thanks for your help. Good to see that you are working on enabling the > dual role USB port on Koelsch. > > Your current board code is checking some DIP switch value during boot, > and that kind of early use of GPIO would require a change in the probe > order like this patch implements. I do however believe that we should > not implement checking during boot like this. > > If you for instance check the legacy Lager USBHS DIP switch code that > runs during driver probe() then that can run can use GPIO without the > need for a change like this. So your GPIO user code needs to be > adjusted. Yes, this is true for USBHS that has platform callbacks like hardware_init/exit. But this is not acceptable for other devices like EHCI PCI/PHY and others. So we wouldn't be able to do such fixup for other cases. > > So this patch will receive a NAK from me I'm afraid. > > Thank you for review. Regards, Vladimir ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gpio: gpio-rcar: init at postcore level 2014-02-24 7:42 ` Vladimir Barinov @ 2014-02-24 7:55 ` Magnus Damm 0 siblings, 0 replies; 6+ messages in thread From: Magnus Damm @ 2014-02-24 7:55 UTC (permalink / raw) To: Vladimir Barinov Cc: SH-Linux, Linus Walleij, linux-gpio, Simon Horman [Horms], Alexandre Courbot, linux-kernel, Kuninori Morimoto Hi Vladimir, On Mon, Feb 24, 2014 at 4:42 PM, Vladimir Barinov <vladimir.barinov@cogentembedded.com> wrote: > Hi Magnus, > > > On 02/24/2014 06:57 AM, Magnus Damm wrote: >> >> Hi Vladimir, >> >> On Mon, Feb 24, 2014 at 1:37 AM,<vladimir.barinov@cogentembedded.com> >> wrote: >>> >>> From: Vladimir Barinov<vladimir.barinov@cogentembedded.com> >>> >>> This adds ability to use gpio API at board init_machine level. >>> >>> F.e. it can be used in the following situation. >>> Many reference hardware has onboard switches that selects which >>> periferals >>> to connect to the system. The gpio input state from switches can be used >>> in choosing platform devices runtime in board code instead of >>> ifdefs/defconfig >>> changes. >>> >>> Signed-off-by:<vladimir.barinov@cogentembedded.com> >>> >>> --- >>> drivers/gpio/gpio-rcar.c | 12 +++++++++++- >>> 1 file changed, 11 insertions(+), 1 deletion(-) >>> >>> Index: build/drivers/gpio/gpio-rcar.c >>> =================================================================== >>> --- build.orig/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:51.456229152 >>> +0400 >>> +++ build/drivers/gpio/gpio-rcar.c 2014-02-22 23:21:52.320229133 >>> +0400 >>> @@ -485,7 +485,17 @@ >>> } >>> }; >>> >>> -module_platform_driver(gpio_rcar_device_driver); >>> +static int __init gpio_rcar_init(void) >>> +{ >>> + return platform_driver_register(&gpio_rcar_device_driver); >>> +} >>> +postcore_initcall(gpio_rcar_init); >>> + >>> +static void __exit gpio_rcar_exit(void) >>> +{ >>> + platform_driver_unregister(&gpio_rcar_device_driver); >>> +} >>> +module_exit(gpio_rcar_exit); >>> >>> MODULE_AUTHOR("Magnus Damm"); >>> MODULE_DESCRIPTION("Renesas R-Car GPIO Driver"); >> >> Hi Vladimir, >> >> Thanks for your help. Good to see that you are working on enabling the >> dual role USB port on Koelsch. >> >> Your current board code is checking some DIP switch value during boot, >> and that kind of early use of GPIO would require a change in the probe >> order like this patch implements. I do however believe that we should >> not implement checking during boot like this. >> >> If you for instance check the legacy Lager USBHS DIP switch code that >> runs during driver probe() then that can run can use GPIO without the >> need for a change like this. So your GPIO user code needs to be >> adjusted. > > Yes, this is true for USBHS that has platform callbacks like > hardware_init/exit. > But this is not acceptable for other devices like EHCI PCI/PHY and others. > So we wouldn't be able to do such fixup for other cases. Right, the USBHS driver has callbacks but PCI-based hardrware like EHCI and OHCI do not have such. But I believe we already have some kind of USB PHY abstraction level and we also have a R-Car Gen2 PHY driver that somehow is integrated together with the PCI-based hardware. Based on that my feeling is that the answer to ID-pin control is there somewhere, and not just once during the boot! =) Cheers, / magnus ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-02-24 7:55 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-23 16:37 [PATCH] gpio: gpio-rcar: init at postcore level vladimir.barinov 2014-02-23 19:09 ` Ben Dooks 2014-02-24 7:46 ` Vladimir Barinov 2014-02-24 2:57 ` Magnus Damm 2014-02-24 7:42 ` Vladimir Barinov 2014-02-24 7:55 ` Magnus Damm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).