[PATCH linux dev-4.10 v6 1/2] ARM: dts: aspeed: Witherspoon add gpio-keys-polled for fan presence

Christopher Bostic cbostic at linux.vnet.ibm.com
Thu Aug 3 12:27:31 AEST 2017



On 8/2/17 3:20 AM, Cédric Le Goater wrote:
> On 08/02/2017 09:10 AM, Cédric Le Goater wrote:
>> On 08/02/2017 04:33 AM, Christopher Bostic wrote:
>>>
>>> On 7/31/17 2:48 AM, Cédric Le Goater wrote:
>>>> On 07/29/2017 08:36 PM, Christopher Bostic wrote:
>>>>> Add gpio-keys-polled  node for pca955x fan presence lines.
>>>>> Add GPIO details to pca955x for the presence lines as well.
>>>>>
>>>>> Polling period of 1 second determined to be the max acceptable
>>>>> value based on discussions with Brad Bishop and Matt Spinler.
>>>>> Tested with gpiomon program - verified.
>>>>>
>>>>> Signed-off-by: Christopher Bostic <cbostic at linux.vnet.ibm.com>
>>>>> ---
>>>>> v6 - Add gpio pin details for fan presence to pca955x node
>>>>> v5 - Fix gpio-keys-polled driver probe errors.  Missing pca955x
>>>>>        gpio cells property and wrong format for poll-interval.
>>>>> v4 - Add details regarding polling period to commit message.
>>>>> v3 - Remove 'autorepeat'
>>>>>      - Increase polling period to 1 second.
>>>>>      - Remove GPIO specifiers from pca955x in dev tree
>>>>> v2 - Change 'linux,code' from a unique global value to a local one
>>>>>        for all the gpio-keys-polled devices.
>>>>> ---
>>>>>    arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 52 ++++++++++++++++++++++++
>>>>>    1 file changed, 52 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>>> index 5afc03a..70328668 100644
>>>>> --- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>>> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>>> @@ -56,6 +56,37 @@
>>>>>            };
>>>>>        };
>>>>>    +    gpio-keys-polled {
>>>>> +        compatible = "gpio-keys-polled";
>>>>> +        #address-cells = <1>;
>>>>> +        #size-cells = <0>;
>>>>> +        poll-interval = <1000>;
>>>>> +
>>>>> +        fan0-presence {
>>>>> +            label = "fan0-presence";
>>>>> +            gpios = <&pca0 4 GPIO_ACTIVE_LOW>;
>>>>> +            linux,code = <4>;
>>>>> +        };
>>>>> +
>>>>> +        fan1-presence {
>>>>> +            label = "fan1-presence";
>>>>> +            gpios = <&pca0 5 GPIO_ACTIVE_LOW>;
>>>>> +            linux,code = <5>;
>>>>> +        };
>>>>> +
>>>>> +        fan2-presence {
>>>>> +            label = "fan2-presence";
>>>>> +            gpios = <&pca0 6 GPIO_ACTIVE_LOW>;
>>>>> +            linux,code = <6>;
>>>>> +        };
>>>>> +
>>>>> +        fan3-presence {
>>>>> +            label = "fan3-presence";
>>>>> +            gpios = <&pca0 7 GPIO_ACTIVE_LOW>;
>>>>> +            linux,code = <7>;
>>>>> +        };
>>>>> +    };
>>>>> +
>>>>>        leds {
>>>>>            compatible = "gpio-leds";
>>>>>    @@ -277,6 +308,7 @@
>>>>>            reg = <0x60>;
>>>>>            #address-cells = <1>;
>>>>>            #size-cells = <0>;
>>>>> +        #gpio-cells = <2>;
>>>> you should also add a :
>>>>
>>>>          gpio-controller;
>>>>
>>>> if you want to use the lines as GPIOs
>>>>
>>>> C.
>>> Hi Cedric,
>>>
>>> If I add 'gpio-controller' here are you indicating that would not
>>> require any modifications I made to the leds-pca955x.c file?
>> yes.
>>
>>> I've tried that and found I still need that leds-pca955x.c change
>>> even if I add 'gpio-controller' attribute to get gpio-keys-polled
>>>   device driver to properly probe the pca955x lines.
>> OK. I will give it a try on a QEMU. Maybe there are some incompatibilities
>> with the gpio-keys driver bindings
> It fails indeed, but the fix you are proposing does not look right
> either.
>
> Maybe we should fully define the pca9552 as a gpio controller and
> then define a gpio-leds and a gpio-keys-polled on top of it ?
Hi Cedric,

What would be entailed in fully defining the pca9552 as a gpio 
controller?   Any other driver examples would help if you know of any.

Currently I see that it has a struct gpio_chip embedded in its 955x chip 
structure and that it defines its various properties, .direction_input, 
.direction_output, etc...   The struct gpio_chip ngpio field is set to a 
subset of pins that are not labeled as LEDS.  Hence my added change to 
count LEDS towards total ngpio's. Given that the pins I'm interested in 
are 4-7 this falls outside the bounds of what the gpio chip considers 
total gpio count.   As a result gpio-keys-polled driver probe fails.

Maybe a quick conference call might be useful?

Thanks,
Chris


> Thanks,
>
> C.
>
>
>> C.
>>
>>> Thanks
>>> Chris
>>>
>>>>>              fan0: led at 0 {
>>>>>                label = "fan0";
>>>>> @@ -302,6 +334,26 @@
>>>>>                reg = <3>;
>>>>>                type = <PCA955X_TYPE_LED>;
>>>>>            };
>>>>> +        fan0_pres_gpio: gpio at 4 {
>>>>> +            label = "fan0_presence";
>>>>> +            reg = <4>;
>>>>> +            type = <PCA955X_TYPE_GPIO>;
>>>>> +        };
>>>>> +        fan1_pres_gpio: gpio at 5 {
>>>>> +            label = "fan1_presence";
>>>>> +            reg = <5>;
>>>>> +            type = <PCA955X_TYPE_GPIO>;
>>>>> +        };
>>>>> +        fan2_pres_gpio: gpio at 6 {
>>>>> +            label = "fan2_presence";
>>>>> +            reg = <6>;
>>>>> +            type = <PCA955X_TYPE_GPIO>;
>>>>> +        };
>>>>> +        fan3_pres_gpio: gpio at 7 {
>>>>> +            label = "fan3_presence";
>>>>> +            reg = <7>;
>>>>> +            type = <PCA955X_TYPE_GPIO>;
>>>>> +        };
>>>>>            front_fault: led at 13 {
>>>>>                label = "front-fault";
>>>>>                default-state = "keep";
>>>>>



More information about the openbmc mailing list