[PATCH linux dev-4.10] ARM: dts: aspeed: Add gpio keys for power supply presence, ucd alert

Joel Stanley joel at jms.id.au
Fri Jul 21 15:19:59 AEST 2017


On Fri, Jul 21, 2017 at 5:06 AM, Matt Spinler
<mspinler at 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 at 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
>>
>


More information about the openbmc mailing list