| Message ID | 1386787041-6035-4-git-send-email-syin@broadcom.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Dec 11, 2013 at 7:37 PM, Sherman Yin <syin@broadcom.com> wrote: > Adds a string to the PINCTRL config option so that 1) CONFIG_PINCTRL=y would > not be erased by make config, and 2) PINCTRL option would show up in menuconfig. > > Signed-off-by: Sherman Yin <syin@broadcom.com> > --- > v3: added to patchset NAK. The pin control subsystem has been designed so that you should select the pin controller through select statements from the SoC using it. This was requested at one time by Linus (Torvalds). You need to convince me that this is really needed. Yours, Linus Walleij
On Thu, Dec 12, 2013 at 12:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Wed, Dec 11, 2013 at 7:37 PM, Sherman Yin <syin@broadcom.com> wrote: > >> Adds a string to the PINCTRL config option so that 1) CONFIG_PINCTRL=y would >> not be erased by make config, and 2) PINCTRL option would show up in menuconfig. >> >> Signed-off-by: Sherman Yin <syin@broadcom.com> >> --- >> v3: added to patchset > > NAK. The pin control subsystem has been designed so that > you should select the pin controller through select statements > from the SoC using it. > > This was requested at one time by Linus (Torvalds). > > You need to convince me that this is really needed. > > Yours, > Linus Walleij Hi Linus, I had requested this from Sherman. The reason is so that pinctrl can be selectable through defconfig, instead of through SoC select statements. And the reason for that is so that, in the future, some of these can be switched into loadable modules (which can't be done from Kconfig). This will become necessary with the move to multiplatform - we won't be able to have everything static anymore. Thanks, csd
On Thu, Dec 12, 2013 at 10:35 PM, Christian Daudt <bcm@fixthebug.org> wrote: > I had requested this from Sherman. The reason is so that pinctrl can > be selectable through defconfig, instead of through SoC select > statements. And the reason for that is so that, in the future, some of > these can be switched into loadable modules (which can't be done from > Kconfig). This will become necessary with the move to multiplatform - > we won't be able to have everything static anymore. Isn't it sufficient to make the pin controller entry tristate rather than bool? And as mentioned elsewhere this does not at all solve the issue that we still need to have all basic IRQchips and timer drivers compiled into the kernel. Yours, Linus Walleij
On Mon 16 Dec 02:01 PST 2013, Linus Walleij wrote: > On Thu, Dec 12, 2013 at 10:35 PM, Christian Daudt <bcm@fixthebug.org> wrote: > > > I had requested this from Sherman. The reason is so that pinctrl can > > be selectable through defconfig, instead of through SoC select > > statements. And the reason for that is so that, in the future, some of > > these can be switched into loadable modules (which can't be done from > > Kconfig). This will become necessary with the move to multiplatform - > > we won't be able to have everything static anymore. > > Isn't it sufficient to make the pin controller entry tristate rather > than bool? > > And as mentioned elsewhere this does not at all solve the issue > that we still need to have all basic IRQchips and timer drivers > compiled into the kernel. No matter how we build the individual pinctrl drivers we will always need the pinctrl framework in a multi-soc zImage; so I can't see that we gain anything from being able to compile PINCTRL as a module. I don't like compiling the individual pinctrl drivers as modules, as it leaves us with a waterfall of PROBE_DEFERRs. Regards, Bjorn
On Tue, Dec 17, 2013 at 1:18 AM, Bjorn Andersson <bjorn.andersson@sonymobile.com> wrote: > No matter how we build the individual pinctrl drivers we will always > need the pinctrl framework in a multi-soc zImage; so I can't see that > we gain anything from being able to compile PINCTRL as a module. I discussed this matter with Christian on IRC and I believe we could basically do "select PINCTRL" on ARCH_MULTIPLATFORM as the vast majority of multiplatforms appear to be using this anyway, this would make the submenu for pin control pop up in menuconfig for this, and make it possible to move different subdrivers to modules if desired. MULTIPLATFORM does not seem to be about saving footprint bytes on a very fine-granular level anyway, more about doing the module loading/unloading approach to footprint. (That drivers such as clk, regulator, pin control, GPIO, irqchip are usually impossible to rmmod as their tentacles will invariably be in all drivers everywhere is another issue, but this approach will solve modular *loading* atleast.) Yours, Linus Walleij
On Friday 20 December 2013, Linus Walleij wrote: > On Tue, Dec 17, 2013 at 1:18 AM, Bjorn Andersson > <bjorn.andersson@sonymobile.com> wrote: > > > No matter how we build the individual pinctrl drivers we will always > > need the pinctrl framework in a multi-soc zImage; so I can't see that > > we gain anything from being able to compile PINCTRL as a module. > > I discussed this matter with Christian on IRC and I believe we could > basically do "select PINCTRL" on ARCH_MULTIPLATFORM as the > vast majority of multiplatforms appear to be using this anyway, this > would make the submenu for pin control pop up in menuconfig > for this, and make it possible to move different subdrivers to modules > if desired. > > MULTIPLATFORM does not seem to be about saving footprint bytes > on a very fine-granular level anyway, more about doing the module > loading/unloading approach to footprint. Let's review the list of platforms that don't select PINCTRL. There are some platforms that are indeed sensitive about memory footprint, and I promised people that converting to multiplatform won't cause a significant increase in kernel binary size as long as no other platforms are enabled. Arnd
On 13-12-20 12:58 PM, Arnd Bergmann wrote: > On Friday 20 December 2013, Linus Walleij wrote: >> On Tue, Dec 17, 2013 at 1:18 AM, Bjorn Andersson >> <bjorn.andersson@sonymobile.com> wrote: >> >>> No matter how we build the individual pinctrl drivers we will always >>> need the pinctrl framework in a multi-soc zImage; so I can't see that >>> we gain anything from being able to compile PINCTRL as a module. >> >> I discussed this matter with Christian on IRC and I believe we could >> basically do "select PINCTRL" on ARCH_MULTIPLATFORM as the >> vast majority of multiplatforms appear to be using this anyway, this >> would make the submenu for pin control pop up in menuconfig >> for this, and make it possible to move different subdrivers to modules >> if desired. >> >> MULTIPLATFORM does not seem to be about saving footprint bytes >> on a very fine-granular level anyway, more about doing the module >> loading/unloading approach to footprint. > > Let's review the list of platforms that don't select PINCTRL. There > are some platforms that are indeed sensitive about memory footprint, > and I promised people that converting to multiplatform won't cause > a significant increase in kernel binary size as long as no other > platforms are enabled. > > Arnd > Ok, for this driver, I'll just select PINCTRL under the ARCH_BCM_MOBILE. We can move this to ARCH_MULTIPLATFORM once we're sure this is okay for other platforms. Regards, Sherman
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index 33f9dc1..a921ff1 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -3,7 +3,7 @@ # config PINCTRL - bool + bool "Enable the pinctrl framework" if PINCTRL
Adds a string to the PINCTRL config option so that 1) CONFIG_PINCTRL=y would not be erased by make config, and 2) PINCTRL option would show up in menuconfig. Signed-off-by: Sherman Yin <syin@broadcom.com> --- v3: added to patchset drivers/pinctrl/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)