Hi, On 30/10/2019 13.45, Peter Ujfalusi wrote: > Hi, > > The shared GPIO line for external components tends to be a common issue and > there is no 'clean' way of handling it. I have missed Rob and the DT list from the recipients list, I'll send the RFC v2 asap. - Péter > I'm aware of the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag, which must be provided when > a driver tries to request a GPIO which is already in use. > However the driver must know that the component is going to be used in such a > way, which can be said to any external components with GPIO line, so in theory > all drivers must set this flag when requesting the GPIO... > > But with the GPIOD_FLAGS_BIT_NONEXCLUSIVE all clients have full control of the > GPIO line. For example any device using the same GPIO as reset/enable line can > reset/enable other devices, which is not something the other device might like > or can handle. > For example a device needs to be configured after it is enabled, but some other > driver would reset it while handling the same GPIO -> the device is not > operational anymmore as it lost it's configuration. > > With the gpio-shared gpiochip we can overcome this by giving the gpio-shared > the role of making sure that the GPIO line only changes state when it will not > disturb any of the clients sharing the same GPIO line. > > The 'sticky' state of the line depends on the board design, which can be > communicated with the hold-active-state property: > > GPIO_ACTIVE_HIGH: the line must be high as long as any of the clients want it to > be high > GPIO_ACTIVE_LOW: the line must be low as long as any of the clients want it to > be low > > In board DTS files it is just adding the node to descibe the shared GPIO line > and point the users of this line to the shared-gpio node instead of the real > GPIO. > > Something like this: > > codec_reset: gpio-shared0 { > compatible = "gpio-shared"; > gpio-controller; > #gpio-cells = <2>; > > root-gpios = <&audio_exp 0 GPIO_ACTIVE_HIGH>; > > branch-count = <2>; > hold-active-state = <GPIO_ACTIVE_HIGH>; > }; > > &main_i2c3 { > audio_exp: gpio@21 { > compatible = "ti,tca6416"; > reg = <0x21>; > gpio-controller; > #gpio-cells = <2>; > }; > > pcm3168a_a: audio-codec@47 { > compatible = "ti,pcm3168a"; > reg = <0x47>; > > #sound-dai-cells = <1>; > > rst-gpios = <&codec_reset 0 GPIO_ACTIVE_HIGH>; > ... > }; > > pcm3168a_b: audio-codec@46 { > compatible = "ti,pcm3168a"; > reg = <0x46>; > > #sound-dai-cells = <1>; > > rst-gpios = <&codec_reset 1 GPIO_ACTIVE_HIGH>; > ... > }; > }; > > If any of the codec requests the GPIO to be high, the line will go up and will > only going to be low when both of them set's their shared line to low. > > Note: other option would be to have something similar to gpio-hog (gpio-shared) > support in the core itself, but then all of the logic and state handling for the > users of the shared line needs to be moved there. > Simply counting the low and high requests would not work as the GPIO framework > by design does not refcounts the state, iow gpio_set(0) three times and > gpio_set(1) would set the line high. > > I have also looked at the reset framework, but again it can not be applied in a > generic way for GPIOs shared for other purposes and all existing drivers must > be converted to use the reset framework (and adding a linux only warpper on top > of reset GPIOs). > > Regards, > Peter > --- > Peter Ujfalusi (2): > dt-bindings: gpio: Add binding document for shared GPIO > gpio: Add new driver for handling 'shared' gpio lines on boards > > .../devicetree/bindings/gpio/gpio-shared.yaml | 100 ++++++++ > drivers/gpio/Kconfig | 6 + > drivers/gpio/Makefile | 1 + > drivers/gpio/gpio-shared.c | 229 ++++++++++++++++++ > 4 files changed, 336 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/gpio-shared.yaml > create mode 100644 drivers/gpio/gpio-shared.c > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki