[RFC PATCH linux dev-4.10] leds: pca955x: add GPIO support

[Cédric Le Goater]

On 05/08/2017 06:58 AM, Joel Stanley wrote:
> On Fri, May 5, 2017 at 10:37 PM, Cédric Le Goater <clg at kaod.org> wrote:
>> The PCA955x family of chips are I2C LED blinkers whose pins not used
>> to control LEDs can be used as general purpose I/Os (GPIOs).
>>
>> The following adds support for device tree and Open Firmware to be
>> able do define different operation modes for each pin. See bindings
>> documentation for more details. The pca955x driver is then extended
>> with a gpio_chip when pins are operating in GPIO mode.
>>
>> Signed-off-by: Cédric Le Goater <clg at kaod.org>
>> ---
>>
>>  I made some experiments on a witherspoon with this tree :
>>
>>    https://github.com/legoater/linux/commits/openbmc-4.10
>>
>>  Looks OK but I don't know what is happening behind the chip.
>>
>>  Please take a look at the DT bindings.
>>
>>  Thanks,
>>
>>  C.
>>
>>  .../devicetree/bindings/leds/leds-pca955x.txt      | 103 ++++++++
>>  drivers/leds/Kconfig                               |  11 +
>>  drivers/leds/leds-pca955x.c                        | 290 ++++++++++++++++++---
>>  3 files changed, 374 insertions(+), 30 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/leds/leds-pca955x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
>> new file mode 100644
>> index 000000000000..98d1053dd1b0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
>> @@ -0,0 +1,103 @@
>> +LEDs connected to pca9550, pca9551, pca9552, pca9553,
>> +
>> +Required properties:
>> +- compatible : should be one of :
>> +       "nxp,pca9550"
>> +       "nxp,pca9551"
>> +       "nxp,pca9552"
>> +       "nxp,pca9553"
>> +- #address-cells: must be 1
>> +- #size-cells: must be 0
>> +- reg: I2C slave address. depends on the model.
>> +
>> +Optional properties:
>> +- gpio-controller: allows pins to be used as GPIOs.
>> +- #gpio-cells: if present, must not be 0.
>> +- gpio-base : base number of the pins used as GPIOs. If there are more
>> +              than one, they should be contiguous. See 'type' property
>> +              below.
>> +
>> +LED sub-node properties:
>> +- reg   : number of LED line.
>> +               from 0 to  1 in pca9550
>> +               from 0 to  7 in pca9551
>> +               from 0 to 15 in pca9552
>> +               from 0 to  3 in pca9553
>> +- compatible: either "none", "led" (default) or "gpio".
>> +- label : (optional)
>> +          see Documentation/devicetree/bindings/leds/common.txt
>> +- linux,default-trigger : (optional)
>> +          see Documentation/devicetree/bindings/leds/common.txt
>> +
>> +Examples:
>> +
>> +pca9552: pca9552 at 60 {
>> +       compatible = "nxp,pca9552";
>> +       #address-cells = <1>;
>> +        #size-cells = <0>;
>> +       reg = <0x60>;
>> +
>> +       gpio-controller;
>> +       #gpio-cells = <2>;
>> +       gpio-base = <12>;
>> +
>> +       gpio at 12 {
>> +               label = "GPIO12";
>> +               reg = <12>;
>> +               compatible = "gpio";
>> +       };
>> +       gpio at 13 {
>> +               label = "GPIO13";
>> +               reg = <13>;
>> +               compatible = "gpio";
>> +       };
>> +       gpio at 14 {
>> +               label = "GPIO14";
>> +               reg = <14>;
>> +               compatible = "gpio";
>> +       };
>> +       gpio at 15 {
>> +               label = "GPIO15";
>> +               reg = <15>;
>> +               compatible = "gpio";
>> +       };
> 
> This is a bit unusual as normally GPIOs aren't described until they're
> being used.

that is to distinguish the LED pins from the GPIO pins.

> In that sense, we should have a GPIO controller that covers all of the
> pins in the device. When requested as LEDs the driver should return
> EBUSY to things that are asking for LEDs.

Well, this is how it works when a LED pin is requested as a GPIO :
EBUSY is returned.


> Perhaps you should just send your RFC upstream and see what they have 
> to say?

Yes. I will in the morning.

Cheers,

C.