Message ID | 20210806143711.37553-1-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers | show |
Series | [v1,1/1] x86/platform: Increase maximum GPIO number for X86_64 | expand |
On Fri, Aug 6, 2021 at 4:44 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > By default the 512 GPIOs is a maximum on any x86 platform. > With, for example, Intel Tiger Lake-H the SoC based controller > occupies up to 480 pins. This leaves only 32 available for > GPIO expanders or other drivers, like PMIC. Hence, bump the > maximum GPIO number to 1024 for X86_64 and leave 512 for X86_32. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Looks reasonable to me. The goal with the whole descriptor refactoring is to get this completely dynamic but it turns out to take forever. It is as it is. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Wed, Aug 11, 2021 at 03:14:59PM +0200, Linus Walleij wrote: > On Fri, Aug 6, 2021 at 4:44 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > By default the 512 GPIOs is a maximum on any x86 platform. > > With, for example, Intel Tiger Lake-H the SoC based controller > > occupies up to 480 pins. This leaves only 32 available for > > GPIO expanders or other drivers, like PMIC. Hence, bump the > > maximum GPIO number to 1024 for X86_64 and leave 512 for X86_32. > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > Looks reasonable to me. > The goal with the whole descriptor refactoring is to get this > completely dynamic but it turns out to take forever. It is as it > is. > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Thanks! Rafael, can you please review this?
On Fri, Aug 6, 2021 at 4:44 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > By default the 512 GPIOs is a maximum on any x86 platform. > With, for example, Intel Tiger Lake-H the SoC based controller > occupies up to 480 pins. This leaves only 32 available for > GPIO expanders or other drivers, like PMIC. Hence, bump the > maximum GPIO number to 1024 for X86_64 and leave 512 for X86_32. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > arch/x86/Kconfig | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 45962aaf2b2c..495ed6229b52 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -340,6 +340,19 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK > config ARCH_HIBERNATION_POSSIBLE > def_bool y > > +# The GPIO number here must be sorted by descending number. In case of > +# a multiplatform kernel, we just want the highest value required by the > +# selected platforms. > +config ARCH_NR_GPIO > + int > + default 1024 if X86_64 > + default 512 if X86_32 > + default 0 Wouldn't default 1024 if X86_64 default 512 be sufficient? It's either X86_64 or X86_32 anyway AFAICS. > + help > + Maximum number of GPIOs in the system. > + > + If unsure, leave the default value. > + > config ARCH_SUSPEND_POSSIBLE > def_bool y > > --
On Mon, Aug 16, 2021 at 03:25:13PM +0200, Rafael J. Wysocki wrote: > On Fri, Aug 6, 2021 at 4:44 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > By default the 512 GPIOs is a maximum on any x86 platform. > > With, for example, Intel Tiger Lake-H the SoC based controller > > occupies up to 480 pins. This leaves only 32 available for > > GPIO expanders or other drivers, like PMIC. Hence, bump the > > maximum GPIO number to 1024 for X86_64 and leave 512 for X86_32. Thanks for review, my answers below. > > +# The GPIO number here must be sorted by descending number. In case of > > +# a multiplatform kernel, we just want the highest value required by the > > +# selected platforms. > > +config ARCH_NR_GPIO > > + int > > + default 1024 if X86_64 > > + default 512 if X86_32 > > + default 0 > > Wouldn't > > default 1024 if X86_64 > default 512 > > be sufficient? > > It's either X86_64 or X86_32 anyway AFAICS. I guess so. > > + help > > + Maximum number of GPIOs in the system. > > + > > + If unsure, leave the default value. Btw, what do you think. do we need comment above and help text here? I copied these from ARM, but I'm not sure it would be useful on x86 as much.
On Mon, Aug 16, 2021 at 3:35 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Aug 16, 2021 at 03:25:13PM +0200, Rafael J. Wysocki wrote: > > On Fri, Aug 6, 2021 at 4:44 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > By default the 512 GPIOs is a maximum on any x86 platform. > > > With, for example, Intel Tiger Lake-H the SoC based controller > > > occupies up to 480 pins. This leaves only 32 available for > > > GPIO expanders or other drivers, like PMIC. Hence, bump the > > > maximum GPIO number to 1024 for X86_64 and leave 512 for X86_32. > > Thanks for review, my answers below. > > > > +# The GPIO number here must be sorted by descending number. In case of > > > +# a multiplatform kernel, we just want the highest value required by the > > > +# selected platforms. > > > +config ARCH_NR_GPIO > > > + int > > > + default 1024 if X86_64 > > > + default 512 if X86_32 > > > + default 0 > > > > Wouldn't > > > > default 1024 if X86_64 > > default 512 > > > > be sufficient? > > > > It's either X86_64 or X86_32 anyway AFAICS. > > I guess so. > > > > + help > > > + Maximum number of GPIOs in the system. > > > + > > > + If unsure, leave the default value. > > Btw, what do you think. do we need comment above and help text here? I copied > these from ARM, but I'm not sure it would be useful on x86 as much. Both the comment and the help text aren't particularly useful IMO. The comment is a bit confusing even, because x86 kernels are multiplatform as a rule.
On Mon, Aug 16, 2021 at 03:55:59PM +0200, Rafael J. Wysocki wrote: > On Mon, Aug 16, 2021 at 3:35 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, Aug 16, 2021 at 03:25:13PM +0200, Rafael J. Wysocki wrote: > > > On Fri, Aug 6, 2021 at 4:44 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: ... > > > Wouldn't > > > > > > default 1024 if X86_64 > > > default 512 > > > > > > be sufficient? > > > > > > It's either X86_64 or X86_32 anyway AFAICS. Fixed in v2. ... > > Btw, what do you think. do we need comment above and help text here? I copied > > these from ARM, but I'm not sure it would be useful on x86 as much. > > Both the comment and the help text aren't particularly useful IMO. > > The comment is a bit confusing even, because x86 kernels are > multiplatform as a rule. Ditto.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 45962aaf2b2c..495ed6229b52 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -340,6 +340,19 @@ config NEED_PER_CPU_PAGE_FIRST_CHUNK config ARCH_HIBERNATION_POSSIBLE def_bool y +# The GPIO number here must be sorted by descending number. In case of +# a multiplatform kernel, we just want the highest value required by the +# selected platforms. +config ARCH_NR_GPIO + int + default 1024 if X86_64 + default 512 if X86_32 + default 0 + help + Maximum number of GPIOs in the system. + + If unsure, leave the default value. + config ARCH_SUSPEND_POSSIBLE def_bool y
By default the 512 GPIOs is a maximum on any x86 platform. With, for example, Intel Tiger Lake-H the SoC based controller occupies up to 480 pins. This leaves only 32 available for GPIO expanders or other drivers, like PMIC. Hence, bump the maximum GPIO number to 1024 for X86_64 and leave 512 for X86_32. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- arch/x86/Kconfig | 13 +++++++++++++ 1 file changed, 13 insertions(+)