| Message ID | 20170713193606.56374-1-cbostic@linux.vnet.ibm.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Fri, Jul 14, 2017 at 5:06 AM, Christopher Bostic <cbostic@linux.vnet.ibm.com> wrote: > Add GPIO keys for power supply 0 and 1 presence as well as ucd alert > to the device tree. > > Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> > --- > arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > index 76a5b28..34c5dfc 100644 > --- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > +++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > @@ -42,6 +42,24 @@ > gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>; > linux,code = <ASPEED_GPIO(J, 2)>; > }; > + > + ps0-presence { > + label = "ps0-presence"; > + gpios = <&gpio ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>; > + linux,code = <ASPEED_GPIO(P, 7)>; > + }; > + > + ps1-presence { > + label = "ps1-presence"; > + gpios = <&gpio ASPEED_GPIO(N, 0) GPIO_ACTIVE_LOW>; > + linux,code = <ASPEED_GPIO(N, 0)>; > + }; Chris, these two look fine. I applied these two and fixed the commit message to not mention the UCD. > + > + ucd-alert { > + label = "ucd-alert"; > + gpios = <&gpio ASPEED_GPIO(I, 2) GPIO_ACTIVE_LOW>; > + linux,code = <ASPEED_GPIO(I, 2)>; > + }; Andrew, are we sure this should be exposed to userspace? Is it something that should be hooked up to the SMBus driver instead? Cheers, Joel > }; > > leds { > -- > 1.8.2.2 >
On Wed, 2017-07-19 at 19:11 +0930, Joel Stanley wrote: > On Fri, Jul 14, 2017 at 5:06 AM, Christopher Bostic > > <cbostic@linux.vnet.ibm.com> wrote: > > Add GPIO keys for power supply 0 and 1 presence as well as ucd alert > > to the device tree. > > > > > > Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> > > --- > > arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > > index 76a5b28..34c5dfc 100644 > > --- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > > +++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > > @@ -42,6 +42,24 @@ > > gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>; > > linux,code = <ASPEED_GPIO(J, 2)>; > > }; > > + > > + ps0-presence { > > + label = "ps0-presence"; > > + gpios = <&gpio ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>; > > + linux,code = <ASPEED_GPIO(P, 7)>; > > + }; > > + > > + ps1-presence { > > + label = "ps1-presence"; > > + gpios = <&gpio ASPEED_GPIO(N, 0) GPIO_ACTIVE_LOW>; > > + linux,code = <ASPEED_GPIO(N, 0)>; > > + }; > > Chris, these two look fine. I applied these two and fixed the commit > message to not mention the UCD. > > > + > > + ucd-alert { > > + label = "ucd-alert"; > > + gpios = <&gpio ASPEED_GPIO(I, 2) GPIO_ACTIVE_LOW>; > > + linux,code = <ASPEED_GPIO(I, 2)>; > > + }; > > Andrew, are we sure this should be exposed to userspace? Is it > something that should be hooked up to the SMBus driver instead? I've looked at the relevant schematics and datasheets, and the GPIO of interest (I2) appears to be correct for the UCD alert. However, GPIOI2 is *not* capable of being muxed as an SMBus Alert (SALT) line and therefore the alert will not be propagated to the I2C master. It appears we must handle it in userspace. Configuring it as GPIO key will give us an interrupt. Hope that helps. Andrew > > Cheers, > > Joel > > > }; > > > > leds { > > -- > > 1.8.2.2 > >
On Thu, Jul 20, 2017 at 11:31 AM, Andrew Jeffery <andrew@aj.id.au> wrote: >> > + >> > + ucd-alert { >> > + label = "ucd-alert"; >> > + gpios = <&gpio ASPEED_GPIO(I, 2) GPIO_ACTIVE_LOW>; >> > + linux,code = <ASPEED_GPIO(I, 2)>; >> > + }; >> >> Andrew, are we sure this should be exposed to userspace? Is it >> something that should be hooked up to the SMBus driver instead? > > I've looked at the relevant schematics and datasheets, and the GPIO of > interest (I2) appears to be correct for the UCD alert. However, GPIOI2 > is *not* capable of being muxed as an SMBus Alert (SALT) line and > therefore the alert will not be propagated to the I2C master. It > appears we must handle it in userspace. Configuring it as GPIO key will > give us an interrupt. We discussed this today, and decided that we would look in to hooking the GPIO up to the ucd driver. From there it will initiate the reading of the fault registers, and allow the implementation of a poll() response on the fault files in sysfs. Cheers, Joel
On 7/19/2017 10:45 PM, Joel Stanley wrote: > On Thu, Jul 20, 2017 at 11:31 AM, Andrew Jeffery <andrew@aj.id.au> wrote: >>>> + >>>> + ucd-alert { >>>> + label = "ucd-alert"; >>>> + gpios = <&gpio ASPEED_GPIO(I, 2) GPIO_ACTIVE_LOW>; >>>> + linux,code = <ASPEED_GPIO(I, 2)>; >>>> + }; >>> Andrew, are we sure this should be exposed to userspace? Is it >>> something that should be hooked up to the SMBus driver instead? >> I've looked at the relevant schematics and datasheets, and the GPIO of >> interest (I2) appears to be correct for the UCD alert. However, GPIOI2 >> is *not* capable of being muxed as an SMBus Alert (SALT) line and >> therefore the alert will not be propagated to the I2C master. It >> appears we must handle it in userspace. Configuring it as GPIO key will >> give us an interrupt. > We discussed this today, and decided that we would look in to hooking > the GPIO up to the ucd driver. From there it will initiate the reading > of the fault registers, and allow the implementation of a poll() > response on the fault files in sysfs. How does this affect the userspace side of things? I am planning on giving up support of doing UCD fault analysis based on interrupts because there are 6 GPUs wired to a single STATUS_WORD bit, so after one faults we'd just keep getting called back again since there's no way to mask at the GPU level, assuming we can even get the interrupt to retrigger again at all. > Cheers, > > Joel >
On Fri, Jul 21, 2017 at 5:06 AM, Matt Spinler <mspinler@linux.vnet.ibm.com> wrote: > > On 7/19/2017 10:45 PM, Joel Stanley wrote: >> >> On Thu, Jul 20, 2017 at 11:31 AM, Andrew Jeffery <andrew@aj.id.au> wrote: >>>>> >>>>> + >>>>> + ucd-alert { >>>>> + label = "ucd-alert"; >>>>> + gpios = <&gpio ASPEED_GPIO(I, 2) >>>>> GPIO_ACTIVE_LOW>; >>>>> + linux,code = <ASPEED_GPIO(I, 2)>; >>>>> + }; >>>> >>>> Andrew, are we sure this should be exposed to userspace? Is it >>>> something that should be hooked up to the SMBus driver instead? >>> >>> I've looked at the relevant schematics and datasheets, and the GPIO of >>> interest (I2) appears to be correct for the UCD alert. However, GPIOI2 >>> is *not* capable of being muxed as an SMBus Alert (SALT) line and >>> therefore the alert will not be propagated to the I2C master. It >>> appears we must handle it in userspace. Configuring it as GPIO key will >>> give us an interrupt. >> >> We discussed this today, and decided that we would look in to hooking >> the GPIO up to the ucd driver. From there it will initiate the reading >> of the fault registers, and allow the implementation of a poll() >> response on the fault files in sysfs. > > How does this affect the userspace side of things? This relates to the pmbus spec's status and error handling. I don't think it would affect the way you interpret the status data in userspace, however I haven't seen the design for what you propose so you would be in a better position to answer that question than me. Cheers, Joel > I am planning on giving > up support of > doing UCD fault analysis based on interrupts because there are 6 GPUs wired > to a single STATUS_WORD > bit, so after one faults we'd just keep getting called back again since > there's no way to mask at the GPU level, > assuming we can even get the interrupt to retrigger again at all. > > > >> Cheers, >> >> Joel >> >
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts index 76a5b28..34c5dfc 100644 --- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts +++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts @@ -42,6 +42,24 @@ gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>; linux,code = <ASPEED_GPIO(J, 2)>; }; + + ps0-presence { + label = "ps0-presence"; + gpios = <&gpio ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>; + linux,code = <ASPEED_GPIO(P, 7)>; + }; + + ps1-presence { + label = "ps1-presence"; + gpios = <&gpio ASPEED_GPIO(N, 0) GPIO_ACTIVE_LOW>; + linux,code = <ASPEED_GPIO(N, 0)>; + }; + + ucd-alert { + label = "ucd-alert"; + gpios = <&gpio ASPEED_GPIO(I, 2) GPIO_ACTIVE_LOW>; + linux,code = <ASPEED_GPIO(I, 2)>; + }; }; leds {
Add GPIO keys for power supply 0 and 1 presence as well as ucd alert to the device tree. Signed-off-by: Christopher Bostic <cbostic@linux.vnet.ibm.com> --- arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)