* [PATCH linux dev-4.10] aspeed: Set max gpio num. @ 2017-06-29 13:30 Mykola Kostenok 2017-06-30 0:34 ` Milton Miller II 0 siblings, 1 reply; 8+ messages in thread From: Mykola Kostenok @ 2017-06-29 13:30 UTC (permalink / raw) To: Joel Stanley, openbmc; +Cc: Mykola Kostenok Set maximum number of gpio for ARCH_ASPEED. Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 186c4c214e0a..9d373685c628 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO default 352 if ARCH_VT8500 default 288 if ARCH_ROCKCHIP default 264 if MACH_H4700 + default 232 if ARCH_ASPEED default 0 help Maximum number of GPIOs in the system. -- 2.11.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. 2017-06-29 13:30 [PATCH linux dev-4.10] aspeed: Set max gpio num Mykola Kostenok @ 2017-06-30 0:34 ` Milton Miller II 2017-06-30 1:31 ` Andrew Jeffery 0 siblings, 1 reply; 8+ messages in thread From: Milton Miller II @ 2017-06-30 0:34 UTC (permalink / raw) To: Mykola Kostenok; +Cc: Joel Stanley, openbmc On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote: > >Set maximum number of gpio for ARCH_ASPEED. > >Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> >diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig >index 186c4c214e0a..9d373685c628 100644 >--- a/arch/arm/Kconfig >+++ b/arch/arm/Kconfig >@@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO > default 352 if ARCH_VT8500 > default 288 if ARCH_ROCKCHIP > default 264 if MACH_H4700 >+ default 232 if ARCH_ASPEED > default 0 > help > Maximum number of GPIOs in the system. This is a bad idea. This sets the maximum total number of gpios supported by the kernel, and setting it to this value would not allow any space for the various pca expanders to define additional gpios. The logic in asm-generic/gpio.h says if the CONFIG number is 0 use 512 else use the supplied value. I'm guessing this was motivated to make the gpio numbers match with the controller. Unfortunately the gpios from the device tree are assigned numbers from the end of the number space. If we need to assign a specific range, we should try to define an optional property in the gpio chip binding and assign the value to gpio-chip.base in gpio-aspeed.c, but I am doubtful that such a patch would be accepted upstream. milton ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. 2017-06-30 0:34 ` Milton Miller II @ 2017-06-30 1:31 ` Andrew Jeffery 2017-06-30 4:51 ` Vadim Pasternak 0 siblings, 1 reply; 8+ messages in thread From: Andrew Jeffery @ 2017-06-30 1:31 UTC (permalink / raw) To: Milton Miller II, Mykola Kostenok; +Cc: openbmc [-- Attachment #1: Type: text/plain, Size: 2247 bytes --] On Fri, 2017-06-30 at 00:34 +0000, Milton Miller II wrote: > On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote: > > > > Set maximum number of gpio for ARCH_ASPEED. > > > > > > Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 186c4c214e0a..9d373685c628 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO > > default 352 if ARCH_VT8500 > > default 288 if ARCH_ROCKCHIP > > default 264 if MACH_H4700 > > > > + default 232 if ARCH_ASPEED > > default 0 > > help > > Maximum number of GPIOs in the system. > > > This is a bad idea. I agree. > This sets the maximum total number > of gpios supported by the kernel, and setting it to this > value would not allow any space for the various pca > expanders to define additional gpios. > > The logic in asm-generic/gpio.h says if the CONFIG > number is 0 use 512 else use the supplied value. > > I'm guessing this was motivated to make the gpio numbers > match with the controller. Right; what's missing is any mention of the motivation. Mykola: What problem are you trying to solve with this patch? As Milton mentions it might be making the GPIO numbers align with the controller, but why do you need that? It should already be possible to describe the system without this patch. > Unfortunately the gpios from > the device tree are assigned numbers from the end of > the number space. > > If we need to assign a specific range, we should try > to define an optional property in the gpio chip binding > and assign the value to gpio-chip.base in gpio-aspeed.c, > but I am doubtful that such a patch would be accepted > upstream. I tend to doubt it as well. Describing GPIOs in the devicetree always uses the GPIO controller phandle for a base reference and the pin numbers are mapped at runtime as required. If it's a userspace problem, then there are means via sysfs and the chardev API to discover which controller you're talking to (e.g. chip labels, named gpios). Either of those approaches should suffice. Cheers, Andrew > > milton > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH linux dev-4.10] aspeed: Set max gpio num. 2017-06-30 1:31 ` Andrew Jeffery @ 2017-06-30 4:51 ` Vadim Pasternak 2017-06-30 5:30 ` Joel Stanley 0 siblings, 1 reply; 8+ messages in thread From: Vadim Pasternak @ 2017-06-30 4:51 UTC (permalink / raw) To: Andrew Jeffery, Milton Miller II, Mykola Kostenok; +Cc: openbmc Hi Andrew, > -----Original Message----- > From: openbmc [mailto:openbmc- > bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of Andrew > Jeffery > Sent: Friday, June 30, 2017 4:31 AM > To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok > <c_mykolak@mellanox.com> > Cc: openbmc@lists.ozlabs.org > Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > > On Fri, 2017-06-30 at 00:34 +0000, Milton Miller II wrote: > > On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote: > > > > > > Set maximum number of gpio for ARCH_ASPEED. > > > > > > > > Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > > > 186c4c214e0a..9d373685c628 100644 > > > --- a/arch/arm/Kconfig > > > +++ b/arch/arm/Kconfig > > > @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO > > > default 352 if ARCH_VT8500 > > > default 288 if ARCH_ROCKCHIP > > > default 264 if MACH_H4700 > > > > > + default 232 if ARCH_ASPEED > > > default 0 > > > help > > > Maximum number of GPIOs in the system. > > > > > > This is a bad idea. > > I agree. > > > This sets the maximum total number > > of gpios supported by the kernel, and setting it to this value would > > not allow any space for the various pca expanders to define additional > > gpios. > > > > The logic in asm-generic/gpio.h says if the CONFIG number is 0 use 512 > > else use the supplied value. > > > > I'm guessing this was motivated to make the gpio numbers match with > > the controller. > > Right; what's missing is any mention of the motivation. > > Mykola: What problem are you trying to solve with this patch? As Milton > mentions it might be making the GPIO numbers align with the controller, but > why do you need that? It should already be possible to describe the system > without this patch. > > > Unfortunately the gpios from > > the device tree are assigned numbers from the end of the number space. > > > > If we need to assign a specific range, we should try to define an > > optional property in the gpio chip binding and assign the value to > > gpio-chip.base in gpio-aspeed.c, but I am doubtful that such a patch > > would be accepted upstream. > > I tend to doubt it as well. Describing GPIOs in the devicetree always uses the > GPIO controller phandle for a base reference and the pin numbers are > mapped at runtime as required. > > If it's a userspace problem, then there are means via sysfs and the chardev > API to discover which controller you're talking to (e.g. chip labels, named > gpios). Either of those approaches should suffice. The motivation to control GPIOs though SYSFS. We have a couple of reasons for that: Need it to support production - they used to verify all the connected GPIOs. Some GPIOs used to allow access to remote components like NC-SI SPI flash, BIOS SPI flash, JTAG interface to CPLDs or some others devices. And we are doing it through /sys/class/gpio. Cheers, Vadim. > > Cheers, > > Andrew > > > > > milton > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. 2017-06-30 4:51 ` Vadim Pasternak @ 2017-06-30 5:30 ` Joel Stanley 2017-07-03 10:52 ` Vadim Pasternak 0 siblings, 1 reply; 8+ messages in thread From: Joel Stanley @ 2017-06-30 5:30 UTC (permalink / raw) To: Vadim Pasternak Cc: Andrew Jeffery, Milton Miller II, Mykola Kostenok, openbmc On Fri, Jun 30, 2017 at 2:21 PM, Vadim Pasternak <vadimp@mellanox.com> wrote: > Hi Andrew, > >> -----Original Message----- >> From: openbmc [mailto:openbmc- >> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of Andrew >> Jeffery >> Sent: Friday, June 30, 2017 4:31 AM >> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok >> <c_mykolak@mellanox.com> >> Cc: openbmc@lists.ozlabs.org >> Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. >> >> On Fri, 2017-06-30 at 00:34 +0000, Milton Miller II wrote: >> > On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote: >> > > >> > > Set maximum number of gpio for ARCH_ASPEED. >> > > >> > > > > Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> >> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index >> > > 186c4c214e0a..9d373685c628 100644 >> > > --- a/arch/arm/Kconfig >> > > +++ b/arch/arm/Kconfig >> > > @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO >> > > default 352 if ARCH_VT8500 >> > > default 288 if ARCH_ROCKCHIP >> > > default 264 if MACH_H4700 >> > > > > + default 232 if ARCH_ASPEED >> > > default 0 >> > > help >> > > Maximum number of GPIOs in the system. >> > >> > >> > This is a bad idea. >> >> I agree. >> >> > This sets the maximum total number >> > of gpios supported by the kernel, and setting it to this value would >> > not allow any space for the various pca expanders to define additional >> > gpios. >> > >> > The logic in asm-generic/gpio.h says if the CONFIG number is 0 use 512 >> > else use the supplied value. >> > >> > I'm guessing this was motivated to make the gpio numbers match with >> > the controller. >> >> Right; what's missing is any mention of the motivation. >> >> Mykola: What problem are you trying to solve with this patch? As Milton >> mentions it might be making the GPIO numbers align with the controller, but >> why do you need that? It should already be possible to describe the system >> without this patch. >> >> > Unfortunately the gpios from >> > the device tree are assigned numbers from the end of the number space. >> > >> > If we need to assign a specific range, we should try to define an >> > optional property in the gpio chip binding and assign the value to >> > gpio-chip.base in gpio-aspeed.c, but I am doubtful that such a patch >> > would be accepted upstream. >> >> I tend to doubt it as well. Describing GPIOs in the devicetree always uses the >> GPIO controller phandle for a base reference and the pin numbers are >> mapped at runtime as required. >> >> If it's a userspace problem, then there are means via sysfs and the chardev >> API to discover which controller you're talking to (e.g. chip labels, named >> gpios). Either of those approaches should suffice. > > The motivation to control GPIOs though SYSFS. > We have a couple of reasons for that: > > Need it to support production - they used to verify all the connected GPIOs. > > Some GPIOs used to allow access to remote components like NC-SI SPI flash, BIOS SPI flash, JTAG interface to CPLDs or some others devices. > > And we are doing it through /sys/class/gpio. You should be able to achieve this without any further kernel changes. OpenBMC on Aspeed uses the sysfs API to do this. Can you show is the code that is using the GPIOs? Cheers, Joel ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH linux dev-4.10] aspeed: Set max gpio num. 2017-06-30 5:30 ` Joel Stanley @ 2017-07-03 10:52 ` Vadim Pasternak 2017-07-03 11:32 ` Andrew Jeffery 0 siblings, 1 reply; 8+ messages in thread From: Vadim Pasternak @ 2017-07-03 10:52 UTC (permalink / raw) To: Joel Stanley; +Cc: Andrew Jeffery, Milton Miller II, Mykola Kostenok, openbmc Hi Joel, > -----Original Message----- > From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel > Stanley > Sent: Friday, June 30, 2017 8:31 AM > To: Vadim Pasternak <vadimp@mellanox.com> > Cc: Andrew Jeffery <andrew@aj.id.au>; Milton Miller II > <miltonm@us.ibm.com>; Mykola Kostenok <c_mykolak@mellanox.com>; > openbmc@lists.ozlabs.org > Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > > On Fri, Jun 30, 2017 at 2:21 PM, Vadim Pasternak <vadimp@mellanox.com> > wrote: > > Hi Andrew, > > > >> -----Original Message----- > >> From: openbmc [mailto:openbmc- > >> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of Andrew > >> Jeffery > >> Sent: Friday, June 30, 2017 4:31 AM > >> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok > >> <c_mykolak@mellanox.com> > >> Cc: openbmc@lists.ozlabs.org > >> Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > >> > >> On Fri, 2017-06-30 at 00:34 +0000, Milton Miller II wrote: > >> > On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote: > >> > > > >> > > Set maximum number of gpio for ARCH_ASPEED. > >> > > > >> > > > > Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> > >> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > >> > > 186c4c214e0a..9d373685c628 100644 > >> > > --- a/arch/arm/Kconfig > >> > > +++ b/arch/arm/Kconfig > >> > > @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO > >> > > default 352 if ARCH_VT8500 > >> > > default 288 if ARCH_ROCKCHIP > >> > > default 264 if MACH_H4700 > >> > > > > + default 232 if ARCH_ASPEED > >> > > default 0 > >> > > help > >> > > Maximum number of GPIOs in the system. > >> > > >> > > >> > This is a bad idea. > >> > >> I agree. > >> > >> > This sets the maximum total number of gpios supported by the > >> > kernel, and setting it to this value would not allow any space for > >> > the various pca expanders to define additional gpios. > >> > > >> > The logic in asm-generic/gpio.h says if the CONFIG number is 0 use > >> > 512 else use the supplied value. > >> > > >> > I'm guessing this was motivated to make the gpio numbers match with > >> > the controller. > >> > >> Right; what's missing is any mention of the motivation. > >> > >> Mykola: What problem are you trying to solve with this patch? As > >> Milton mentions it might be making the GPIO numbers align with the > >> controller, but why do you need that? It should already be possible > >> to describe the system without this patch. > >> > >> > Unfortunately the gpios from > >> > the device tree are assigned numbers from the end of the number > space. > >> > > >> > If we need to assign a specific range, we should try to define an > >> > optional property in the gpio chip binding and assign the value to > >> > gpio-chip.base in gpio-aspeed.c, but I am doubtful that such a > >> > patch would be accepted upstream. > >> > >> I tend to doubt it as well. Describing GPIOs in the devicetree always > >> uses the GPIO controller phandle for a base reference and the pin > >> numbers are mapped at runtime as required. > >> > >> If it's a userspace problem, then there are means via sysfs and the > >> chardev API to discover which controller you're talking to (e.g. chip > >> labels, named gpios). Either of those approaches should suffice. > > > > The motivation to control GPIOs though SYSFS. > > We have a couple of reasons for that: > > > > Need it to support production - they used to verify all the connected > GPIOs. > > > > Some GPIOs used to allow access to remote components like NC-SI SPI > flash, BIOS SPI flash, JTAG interface to CPLDs or some others devices. > > > > And we are doing it through /sys/class/gpio. > > You should be able to achieve this without any further kernel changes. > OpenBMC on Aspeed uses the sysfs API to do this. > > Can you show is the code that is using the GPIOs? We just getting in /sys/class/gpio all with offset 280, like: gpio281 gpio511 gpiochip280 It means we have to consider this offset in our user space applications, in case we can't have gpiochip0 here. Right? > > Cheers, > > Joel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. 2017-07-03 10:52 ` Vadim Pasternak @ 2017-07-03 11:32 ` Andrew Jeffery 2017-07-03 11:44 ` Vadim Pasternak 0 siblings, 1 reply; 8+ messages in thread From: Andrew Jeffery @ 2017-07-03 11:32 UTC (permalink / raw) To: Vadim Pasternak, Joel Stanley; +Cc: Milton Miller II, Mykola Kostenok, openbmc Hi Vadim, On Mon, Jul 3, 2017, at 20:22, Vadim Pasternak wrote: > Hi Joel, > > > -----Original Message----- > > From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of Joel > > Stanley > > Sent: Friday, June 30, 2017 8:31 AM > > To: Vadim Pasternak <vadimp@mellanox.com> > > Cc: Andrew Jeffery <andrew@aj.id.au>; Milton Miller II > > <miltonm@us.ibm.com>; Mykola Kostenok <c_mykolak@mellanox.com>; > > openbmc@lists.ozlabs.org > > Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > > > > On Fri, Jun 30, 2017 at 2:21 PM, Vadim Pasternak <vadimp@mellanox.com> > > wrote: > > > Hi Andrew, > > > > > >> -----Original Message----- > > >> From: openbmc [mailto:openbmc- > > >> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of Andrew > > >> Jeffery > > >> Sent: Friday, June 30, 2017 4:31 AM > > >> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok > > >> <c_mykolak@mellanox.com> > > >> Cc: openbmc@lists.ozlabs.org > > >> Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > > >> > > >> On Fri, 2017-06-30 at 00:34 +0000, Milton Miller II wrote: > > >> > On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote: > > >> > > > > >> > > Set maximum number of gpio for ARCH_ASPEED. > > >> > > > > >> > > > > Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> > > >> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > > >> > > 186c4c214e0a..9d373685c628 100644 > > >> > > --- a/arch/arm/Kconfig > > >> > > +++ b/arch/arm/Kconfig > > >> > > @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO > > >> > > default 352 if ARCH_VT8500 > > >> > > default 288 if ARCH_ROCKCHIP > > >> > > default 264 if MACH_H4700 > > >> > > > > + default 232 if ARCH_ASPEED > > >> > > default 0 > > >> > > help > > >> > > Maximum number of GPIOs in the system. > > >> > > > >> > > > >> > This is a bad idea. > > >> > > >> I agree. > > >> > > >> > This sets the maximum total number of gpios supported by the > > >> > kernel, and setting it to this value would not allow any space for > > >> > the various pca expanders to define additional gpios. > > >> > > > >> > The logic in asm-generic/gpio.h says if the CONFIG number is 0 use > > >> > 512 else use the supplied value. > > >> > > > >> > I'm guessing this was motivated to make the gpio numbers match with > > >> > the controller. > > >> > > >> Right; what's missing is any mention of the motivation. > > >> > > >> Mykola: What problem are you trying to solve with this patch? As > > >> Milton mentions it might be making the GPIO numbers align with the > > >> controller, but why do you need that? It should already be possible > > >> to describe the system without this patch. > > >> > > >> > Unfortunately the gpios from > > >> > the device tree are assigned numbers from the end of the number > > space. > > >> > > > >> > If we need to assign a specific range, we should try to define an > > >> > optional property in the gpio chip binding and assign the value to > > >> > gpio-chip.base in gpio-aspeed.c, but I am doubtful that such a > > >> > patch would be accepted upstream. > > >> > > >> I tend to doubt it as well. Describing GPIOs in the devicetree always > > >> uses the GPIO controller phandle for a base reference and the pin > > >> numbers are mapped at runtime as required. > > >> > > >> If it's a userspace problem, then there are means via sysfs and the > > >> chardev API to discover which controller you're talking to (e.g. chip > > >> labels, named gpios). Either of those approaches should suffice. > > > > > > The motivation to control GPIOs though SYSFS. > > > We have a couple of reasons for that: > > > > > > Need it to support production - they used to verify all the connected > > GPIOs. > > > > > > Some GPIOs used to allow access to remote components like NC-SI SPI > > flash, BIOS SPI flash, JTAG interface to CPLDs or some others devices. > > > > > > And we are doing it through /sys/class/gpio. > > > > You should be able to achieve this without any further kernel changes. > > OpenBMC on Aspeed uses the sysfs API to do this. > > > > Can you show is the code that is using the GPIOs? > > We just getting in /sys/class/gpio all with offset 280, like: > gpio281 gpio511 gpiochip280 This looks like what I'd expect. > > It means we have to consider this offset in our user space applications, > in case we can't have gpiochip0 here. Right? Yes. For example, the openbmc userspace probes the GPIO chips here: https://github.com/openbmc/skeleton/blob/master/pysystemmgr/obmc/system/__init__.py#L4 Hope that helps. Andrew > > > > > > Cheers, > > > > Joel ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH linux dev-4.10] aspeed: Set max gpio num. 2017-07-03 11:32 ` Andrew Jeffery @ 2017-07-03 11:44 ` Vadim Pasternak 0 siblings, 0 replies; 8+ messages in thread From: Vadim Pasternak @ 2017-07-03 11:44 UTC (permalink / raw) To: Andrew Jeffery, Joel Stanley; +Cc: Milton Miller II, Mykola Kostenok, openbmc Hi Andrew, > -----Original Message----- > From: Andrew Jeffery [mailto:andrew@aj.id.au] > Sent: Monday, July 03, 2017 2:33 PM > To: Vadim Pasternak <vadimp@mellanox.com>; Joel Stanley > <joel@jms.id.au> > Cc: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok > <c_mykolak@mellanox.com>; openbmc@lists.ozlabs.org > Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > > Hi Vadim, > > On Mon, Jul 3, 2017, at 20:22, Vadim Pasternak wrote: > > Hi Joel, > > > > > -----Original Message----- > > > From: joel.stan@gmail.com [mailto:joel.stan@gmail.com] On Behalf Of > > > Joel Stanley > > > Sent: Friday, June 30, 2017 8:31 AM > > > To: Vadim Pasternak <vadimp@mellanox.com> > > > Cc: Andrew Jeffery <andrew@aj.id.au>; Milton Miller II > > > <miltonm@us.ibm.com>; Mykola Kostenok > <c_mykolak@mellanox.com>; > > > openbmc@lists.ozlabs.org > > > Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > > > > > > On Fri, Jun 30, 2017 at 2:21 PM, Vadim Pasternak > > > <vadimp@mellanox.com> > > > wrote: > > > > Hi Andrew, > > > > > > > >> -----Original Message----- > > > >> From: openbmc [mailto:openbmc- > > > >> bounces+yanivab=mellanox.com@lists.ozlabs.org] On Behalf Of > > > >> bounces+Andrew > > > >> Jeffery > > > >> Sent: Friday, June 30, 2017 4:31 AM > > > >> To: Milton Miller II <miltonm@us.ibm.com>; Mykola Kostenok > > > >> <c_mykolak@mellanox.com> > > > >> Cc: openbmc@lists.ozlabs.org > > > >> Subject: Re: [PATCH linux dev-4.10] aspeed: Set max gpio num. > > > >> > > > >> On Fri, 2017-06-30 at 00:34 +0000, Milton Miller II wrote: > > > >> > On June 29 2017 at 8:31 in some time zone, Mykola Kostenok wrote: > > > >> > > > > > >> > > Set maximum number of gpio for ARCH_ASPEED. > > > >> > > > > > >> > > > > Signed-off-by: Mykola Kostenok <c_mykolak@mellanox.com> > > > >> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > > > >> > > 186c4c214e0a..9d373685c628 100644 > > > >> > > --- a/arch/arm/Kconfig > > > >> > > +++ b/arch/arm/Kconfig > > > >> > > @@ -1492,6 +1492,7 @@ config ARCH_NR_GPIO > > > >> > > default 352 if ARCH_VT8500 > > > >> > > default 288 if ARCH_ROCKCHIP > > > >> > > default 264 if MACH_H4700 > > > >> > > > > + default 232 if ARCH_ASPEED > > > >> > > default 0 > > > >> > > help > > > >> > > Maximum number of GPIOs in the system. > > > >> > > > > >> > > > > >> > This is a bad idea. > > > >> > > > >> I agree. > > > >> > > > >> > This sets the maximum total number of gpios supported by the > > > >> > kernel, and setting it to this value would not allow any space > > > >> > for the various pca expanders to define additional gpios. > > > >> > > > > >> > The logic in asm-generic/gpio.h says if the CONFIG number is 0 > > > >> > use > > > >> > 512 else use the supplied value. > > > >> > > > > >> > I'm guessing this was motivated to make the gpio numbers match > > > >> > with the controller. > > > >> > > > >> Right; what's missing is any mention of the motivation. > > > >> > > > >> Mykola: What problem are you trying to solve with this patch? As > > > >> Milton mentions it might be making the GPIO numbers align with > > > >> the controller, but why do you need that? It should already be > > > >> possible to describe the system without this patch. > > > >> > > > >> > Unfortunately the gpios from > > > >> > the device tree are assigned numbers from the end of the number > > > space. > > > >> > > > > >> > If we need to assign a specific range, we should try to define > > > >> > an optional property in the gpio chip binding and assign the > > > >> > value to gpio-chip.base in gpio-aspeed.c, but I am doubtful > > > >> > that such a patch would be accepted upstream. > > > >> > > > >> I tend to doubt it as well. Describing GPIOs in the devicetree > > > >> always uses the GPIO controller phandle for a base reference and > > > >> the pin numbers are mapped at runtime as required. > > > >> > > > >> If it's a userspace problem, then there are means via sysfs and > > > >> the chardev API to discover which controller you're talking to > > > >> (e.g. chip labels, named gpios). Either of those approaches should > suffice. > > > > > > > > The motivation to control GPIOs though SYSFS. > > > > We have a couple of reasons for that: > > > > > > > > Need it to support production - they used to verify all the > > > > connected > > > GPIOs. > > > > > > > > Some GPIOs used to allow access to remote components like NC-SI > > > > SPI > > > flash, BIOS SPI flash, JTAG interface to CPLDs or some others devices. > > > > > > > > And we are doing it through /sys/class/gpio. > > > > > > You should be able to achieve this without any further kernel changes. > > > OpenBMC on Aspeed uses the sysfs API to do this. > > > > > > Can you show is the code that is using the GPIOs? > > > > We just getting in /sys/class/gpio all with offset 280, like: > > gpio281 gpio511 gpiochip280 > > This looks like what I'd expect. > > > > > It means we have to consider this offset in our user space > > applications, in case we can't have gpiochip0 here. Right? > > Yes. For example, the openbmc userspace probes the GPIO chips here: > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > hub.com%2Fopenbmc%2Fskeleton%2Fblob%2Fmaster%2Fpysystemmgr%2F > obmc%2Fsystem%2F__init__.py%23L4&data=02%7C01%7Cvadimp%40mella > nox.com%7C7ab16551b30f433e3b1b08d4c20742fb%7Ca652971c7d2e4d9ba6a > 4d149256f461b%7C0%7C0%7C636346783833758007&sdata=9DV5e4dERXNj93 > Mdet4dbMcQeryqiwysIzySnfxaBHk%3D&reserved=0 > > Hope that helps. Thank you for the pointer. This is good with us. > > Andrew > > > > > > > > > > > Cheers, > > > > > > Joel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-07-03 11:44 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-29 13:30 [PATCH linux dev-4.10] aspeed: Set max gpio num Mykola Kostenok 2017-06-30 0:34 ` Milton Miller II 2017-06-30 1:31 ` Andrew Jeffery 2017-06-30 4:51 ` Vadim Pasternak 2017-06-30 5:30 ` Joel Stanley 2017-07-03 10:52 ` Vadim Pasternak 2017-07-03 11:32 ` Andrew Jeffery 2017-07-03 11:44 ` Vadim Pasternak
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.