| Message ID | 1393173467-12240-1-git-send-email-vladimir.barinov@cogentembedded.com (mailing list archive) |
|---|---|
| State | Rejected |
| Headers | show |
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?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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");