| Message ID | 20190627110920.15099-1-j-keerthy@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3 | expand |
On 16:39-20190627, Keerthy wrote: > Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. > > Signed-off-by: Keerthy <j-keerthy@ti.com> > --- > > Changes in v2: > > * Enabling configs in Kconfig.platforms file instead of defconfig. > * Removed GPIO_DEBUG config. > > arch/arm64/Kconfig.platforms | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 4778c775de1b..6e43a0995ed4 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -97,6 +97,8 @@ config ARCH_K3 > select TI_SCI_PROTOCOL > select TI_SCI_INTR_IRQCHIP > select TI_SCI_INTA_IRQCHIP > + select GPIO_SYSFS > + select GPIO_DAVINCI Could you help explain the logic of doing this? commit message is basically the diff in English. To me, this does NOT make sense. I understand GPIO_DAVINCI is the driver compatible, but we cant do this for every single SoC driver that is NOT absolutely mandatory for basic functionality. Also keep in mind the impact to arm64/configs/defconfig -> every single SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force that?
On 27/06/19 8:02 PM, Nishanth Menon wrote: > On 16:39-20190627, Keerthy wrote: >> Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. >> >> Signed-off-by: Keerthy <j-keerthy@ti.com> >> --- >> >> Changes in v2: >> >> * Enabling configs in Kconfig.platforms file instead of defconfig. >> * Removed GPIO_DEBUG config. >> >> arch/arm64/Kconfig.platforms | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >> index 4778c775de1b..6e43a0995ed4 100644 >> --- a/arch/arm64/Kconfig.platforms >> +++ b/arch/arm64/Kconfig.platforms >> @@ -97,6 +97,8 @@ config ARCH_K3 >> select TI_SCI_PROTOCOL >> select TI_SCI_INTR_IRQCHIP >> select TI_SCI_INTA_IRQCHIP >> + select GPIO_SYSFS >> + select GPIO_DAVINCI > > > Could you help explain the logic of doing this? commit message is > basically the diff in English. To me, this does NOT make sense. > > I understand GPIO_DAVINCI is the driver compatible, but we cant do this for > every single SoC driver that is NOT absolutely mandatory for basic > functionality. In case of ARM64 could you help me find the right place to enable such SoC specific configs? > > Also keep in mind the impact to arm64/configs/defconfig -> every single > SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force > that? This was the practice in arm32 soc specific configs like omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i totally understand your concern about every single SoC rebuilding but now where do we need to enable the bare minimal GPIO_DAVINCI config? v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i shifted to this approach. >
On 09:08-20190628, Keerthy wrote: [..] > > > + select GPIO_SYSFS > > > + select GPIO_DAVINCI > > > > > > Could you help explain the logic of doing this? commit message is > > basically the diff in English. To me, this does NOT make sense. > > > > I understand GPIO_DAVINCI is the driver compatible, but we cant do this for > > every single SoC driver that is NOT absolutely mandatory for basic > > functionality. > > In case of ARM64 could you help me find the right place to enable > such SoC specific configs? Is'nt that what defconfig is supposed to be all about? arch/arm64/configs/defconfig > > > > > Also keep in mind the impact to arm64/configs/defconfig -> every single > > SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force > > that? > > This was the practice in arm32 soc specific configs like > omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i totally > understand your concern about every single SoC rebuilding but now where do > we need to enable the bare minimal GPIO_DAVINCI config? Well, SYSFS, I cannot agree testing as the rationale in Kconfig.platform. And, looking at [1], I see majority being mandatory components for the SoC bootup. However, most of the "optional" drivers go into arm64 as defconfig (preferably as a module?) and if you find a rationale for recommending DEBUG_GPIO, you could propose that to the community as well. Now, Thinking about this, I'd even challenge the current list of configs as being "select". I'd rather do an "imply"[2] - yes, you need this for the default dtb to boot, however a carefully carved dtb could boot with lesser driver set to get a smaller (and less functional) kernel. > > v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i > shifted to this approach. I noticed that you were posting a v2, for future reference, please use diffstat section to point to lore/patchworks link to point at v1 (I did notice you mentioned you had an update, thanks - link will help catch up on older discussions). This helps a later revision reviewer like me to get context. Tero, would you be able to help with a better rationale as to where the boundaries are to be in your mind, rather than risk every single peripheral driver getting into ARCH_K3? As of right now, I'd rather we do not explode the current list out of bounds. NAK unless we can find a better rationale. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig.platforms [2] https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt
On 29/06/19 2:07 AM, Nishanth Menon wrote: > On 09:08-20190628, Keerthy wrote: > [..] >>>> + select GPIO_SYSFS >>>> + select GPIO_DAVINCI >>> >>> >>> Could you help explain the logic of doing this? commit message is >>> basically the diff in English. To me, this does NOT make sense. >>> >>> I understand GPIO_DAVINCI is the driver compatible, but we cant do this for >>> every single SoC driver that is NOT absolutely mandatory for basic >>> functionality. >> >> In case of ARM64 could you help me find the right place to enable >> such SoC specific configs? > > Is'nt that what defconfig is supposed to be all about? > > arch/arm64/configs/defconfig > >> >>> >>> Also keep in mind the impact to arm64/configs/defconfig -> every single >>> SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force >>> that? >> >> This was the practice in arm32 soc specific configs like >> omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i totally >> understand your concern about every single SoC rebuilding but now where do >> we need to enable the bare minimal GPIO_DAVINCI config? > > Well, SYSFS, I cannot agree testing as the rationale in > Kconfig.platform. And, looking at [1], I see majority being mandatory > components for the SoC bootup. However, most of the "optional" drivers > go into arm64 as defconfig (preferably as a module?) and if you find a > rationale for recommending DEBUG_GPIO, you could propose that to the > community as well. > > Now, Thinking about this, I'd even challenge the current list of configs as > being "select". I'd rather do an "imply"[2] - yes, you need this for the > default dtb to boot, however a carefully carved dtb could boot with > lesser driver set to get a smaller (and less functional) kernel. > >> >> v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i >> shifted to this approach. > > I noticed that you were posting a v2, for future reference, please use > diffstat section to point to lore/patchworks link to point at v1 (I > did notice you mentioned you had an update, thanks - link will help > catch up on older discussions). This helps a later revision reviewer > like me to get context. > > Tero, would you be able to help with a better rationale as to where the > boundaries are to be in your mind, rather than risk every single > peripheral driver getting into ARCH_K3? Tero, Could you point me to a better place for enabling? - Keerthy > > As of right now, I'd rather we do not explode the current list out of > bounds. NAK unless we can find a better rationale. > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig.platforms > [2] https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt >
On 11/07/2019 08:49, Keerthy wrote: > > > On 29/06/19 2:07 AM, Nishanth Menon wrote: >> On 09:08-20190628, Keerthy wrote: >> [..] >>>>> + select GPIO_SYSFS >>>>> + select GPIO_DAVINCI >>>> >>>> >>>> Could you help explain the logic of doing this? commit message is >>>> basically the diff in English. To me, this does NOT make sense. >>>> >>>> I understand GPIO_DAVINCI is the driver compatible, but we cant do >>>> this for >>>> every single SoC driver that is NOT absolutely mandatory for basic >>>> functionality. >>> >>> In case of ARM64 could you help me find the right place to enable >>> such SoC specific configs? >> >> Is'nt that what defconfig is supposed to be all about? >> >> arch/arm64/configs/defconfig >> >>> >>>> >>>> Also keep in mind the impact to arm64/configs/defconfig -> every single >>>> SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force >>>> that? >>> >>> This was the practice in arm32 soc specific configs like >>> omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i >>> totally >>> understand your concern about every single SoC rebuilding but now >>> where do >>> we need to enable the bare minimal GPIO_DAVINCI config? >> >> Well, SYSFS, I cannot agree testing as the rationale in >> Kconfig.platform. And, looking at [1], I see majority being mandatory >> components for the SoC bootup. However, most of the "optional" drivers >> go into arm64 as defconfig (preferably as a module?) and if you find a >> rationale for recommending DEBUG_GPIO, you could propose that to the >> community as well. >> >> Now, Thinking about this, I'd even challenge the current list of >> configs as >> being "select". I'd rather do an "imply"[2] - yes, you need this for the >> default dtb to boot, however a carefully carved dtb could boot with >> lesser driver set to get a smaller (and less functional) kernel. >> >>> >>> v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i >>> shifted to this approach. >> >> I noticed that you were posting a v2, for future reference, please use >> diffstat section to point to lore/patchworks link to point at v1 (I >> did notice you mentioned you had an update, thanks - link will help >> catch up on older discussions). This helps a later revision reviewer >> like me to get context. >> >> Tero, would you be able to help with a better rationale as to where the >> boundaries are to be in your mind, rather than risk every single >> peripheral driver getting into ARCH_K3? > > Tero, > > Could you point me to a better place for enabling? > Well, thinking about what Nishanth said, we should probably keep the defconfig to bare minimal and only enable peripherals that are absolutely necessary for boot. We should eventually support eth / mmc-sd boot modes for K3 devices, but limit the configs to that. Rest we can carry within TI internal defconfigs, including this GPIO enabler. If GPIO becomes a must have for some future device / peripheral, we can re-consider this. -Tero > - Keerthy > >> >> As of right now, I'd rather we do not explode the current list out of >> bounds. NAK unless we can find a better rationale. >> >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig.platforms >> >> [2] https://www.kernel.org/doc/Documentation/kbuild/kconfig-language.txt >> -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 4778c775de1b..6e43a0995ed4 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -97,6 +97,8 @@ config ARCH_K3 select TI_SCI_PROTOCOL select TI_SCI_INTR_IRQCHIP select TI_SCI_INTA_IRQCHIP + select GPIO_SYSFS + select GPIO_DAVINCI help This enables support for Texas Instruments' K3 multicore SoC architecture.
Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. Signed-off-by: Keerthy <j-keerthy@ti.com> --- Changes in v2: * Enabling configs in Kconfig.platforms file instead of defconfig. * Removed GPIO_DEBUG config. arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+)