[PATCH linux dev-4.10] aspeed: Set max gpio num.

Mon Jul 3 21:44:02 AEST 2017

Hi Andrew,

> -----Original Message-----
> From: Andrew Jeffery [mailto:andrew at aj.id.au]
> Sent: Monday, July 03, 2017 2:33 PM
> To: Vadim Pasternak <vadimp at mellanox.com>; Joel Stanley
> <joel at jms.id.au>
> Cc: Milton Miller II <miltonm at us.ibm.com>; Mykola Kostenok
> <c_mykolak at mellanox.com>; openbmc at 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 at gmail.com [mailto:joel.stan at gmail.com] On Behalf Of
> > > Joel Stanley
> > > Sent: Friday, June 30, 2017 8:31 AM
> > > To: Vadim Pasternak <vadimp at mellanox.com>
> > > Cc: Andrew Jeffery <andrew at aj.id.au>; Milton Miller II
> > > <miltonm at us.ibm.com>; Mykola Kostenok
> <c_mykolak at mellanox.com>;
> > > openbmc at 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 at mellanox.com>
> > > wrote:
> > > > Hi Andrew,
> > > >
> > > >> -----Original Message-----
> > > >> From: openbmc [mailto:openbmc-
> > > >> bounces+yanivab=mellanox.com at lists.ozlabs.org] On Behalf Of
> > > >> bounces+Andrew
> > > >> Jeffery
> > > >> Sent: Friday, June 30, 2017 4:31 AM
> > > >> To: Milton Miller II <miltonm at us.ibm.com>; Mykola Kostenok
> > > >> <c_mykolak at mellanox.com>
> > > >> Cc: openbmc at 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 at 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