* [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
@ 2019-06-27 11:09 Keerthy
2019-06-27 14:32 ` Nishanth Menon
0 siblings, 1 reply; 6+ messages in thread
From: Keerthy @ 2019-06-27 11:09 UTC (permalink / raw)
To: t-kristo, will.deacon, catalin.marinas, shawnguo
Cc: linux-kernel, linux-arm-kernel, j-keerthy, nm, lokeshvutla
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
help
This enables support for Texas Instruments' K3 multicore SoC
architecture.
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
2019-06-27 11:09 [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3 Keerthy
@ 2019-06-27 14:32 ` Nishanth Menon
2019-06-28 3:38 ` Keerthy
0 siblings, 1 reply; 6+ messages in thread
From: Nishanth Menon @ 2019-06-27 14:32 UTC (permalink / raw)
To: Keerthy
Cc: t-kristo, will.deacon, catalin.marinas, shawnguo, linux-kernel,
linux-arm-kernel, lokeshvutla
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?
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
2019-06-27 14:32 ` Nishanth Menon
@ 2019-06-28 3:38 ` Keerthy
2019-06-28 20:37 ` Nishanth Menon
0 siblings, 1 reply; 6+ messages in thread
From: Keerthy @ 2019-06-28 3:38 UTC (permalink / raw)
To: Nishanth Menon
Cc: t-kristo, will.deacon, catalin.marinas, shawnguo, linux-kernel,
linux-arm-kernel, lokeshvutla
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
2019-06-28 3:38 ` Keerthy
@ 2019-06-28 20:37 ` Nishanth Menon
2019-07-11 5:49 ` Keerthy
0 siblings, 1 reply; 6+ messages in thread
From: Nishanth Menon @ 2019-06-28 20:37 UTC (permalink / raw)
To: Keerthy
Cc: t-kristo, will.deacon, catalin.marinas, shawnguo, linux-kernel,
linux-arm-kernel, lokeshvutla
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
--
Regards,
Nishanth Menon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
2019-06-28 20:37 ` Nishanth Menon
@ 2019-07-11 5:49 ` Keerthy
2019-07-11 7:16 ` Tero Kristo
0 siblings, 1 reply; 6+ messages in thread
From: Keerthy @ 2019-07-11 5:49 UTC (permalink / raw)
To: Nishanth Menon
Cc: t-kristo, will.deacon, catalin.marinas, shawnguo, linux-kernel,
linux-arm-kernel, lokeshvutla
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
2019-07-11 5:49 ` Keerthy
@ 2019-07-11 7:16 ` Tero Kristo
0 siblings, 0 replies; 6+ messages in thread
From: Tero Kristo @ 2019-07-11 7:16 UTC (permalink / raw)
To: Keerthy, Nishanth Menon
Cc: will.deacon, catalin.marinas, shawnguo, linux-kernel,
linux-arm-kernel, lokeshvutla
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-07-11 7:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-27 11:09 [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3 Keerthy
2019-06-27 14:32 ` Nishanth Menon
2019-06-28 3:38 ` Keerthy
2019-06-28 20:37 ` Nishanth Menon
2019-07-11 5:49 ` Keerthy
2019-07-11 7:16 ` Tero Kristo
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).