Message-ID: <3c384b40-f353-eaec-b1d6-ba74f5338ce1@metux.net>
Date:   Mon, 18 Nov 2019 13:15:52 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Peter Ujfalusi <peter.ujfalusi@...com>, linus.walleij@...aro.org,
        bgolaszewski@...libre.com, robh+dt@...nel.org
Cc:     linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        m.szyprowski@...sung.com, broonie@...nel.org, t-kristo@...com,
        mripard@...nel.org, p.zabel@...gutronix.de,
        devicetree@...r.kernel.org
Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards

On 30.10.19 13:04, Peter Ujfalusi wrote:

Hi,

> 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.

IMHO, for such cases, invidual drivers shouldn't fiddle w/ raw gpio's
directly, but be connected to (gpio-based) reset controllers or
regulators instead. I believe, GPIO isn't the correct abstraction layer
for such cases: it's not even IO, just O.

Let's sit back and rethink what the driver really wants to tell in those
cases. For the enable lines we have:

a) make sure the device is enabled/powered
b) device does not need to be enabled/powered anymore
c) device must be powercycled

You see, it's actually tristate, which gets relevant if multiple devices
on one line.

Now add reset lines:

a) force device into reset state
b) force device out of reset state
c) allow device going into reset state (but no need to force)
d) allow device coming out of reset state (but no need to force)

It even gets more weird if a device can be reset or powercycled
externally.


hmm, not entirely trivial ...

> 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.

Yeah, at least we need some signalling to the driver, so it can do the
necessary steps. From the driver's PoV, it's an "foreign reset".

> 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.

How exactly do we know when such disturbance can / cannot happen ?
That would be depending on individual chips *and* how they're wired on
the board. We'd end up with some logical multiplexer, that's board
specific.

<snip>

> 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.

So, if one driver request reset, all attached devices will be reset ?
Or if all drivers request reset, all attached devices will be reset ?

Doesn't look so quite non-disturbing to me :o

> 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 

What are the exact scenarios you have in mind ?

> and all existing drivers must
> be converted to use the reset framework (and adding a linux only warpper on top
> of reset GPIOs).

Maybe a bit time consuming, but IMHO not difficult. We could add generic
helpers for creating a reset driver on a gpio. So the drivers wouldn't
even care about gpio itself anymore, but let the reset subsystem so it
all (eg. look for DT node and request corresponding gpio, etc).

IMHO, that's something we should do nevertheless, even if it's just for
cleaner code.

After that we could put any kind of funny logic behind the scenes (eg.
one could connect the reset pin to a spare uart instead of gpio, etc),
w/o ever touching the individual drivers.


--mtx

-- 
Dringender Hinweis: aufgrund existenzieller Bedrohung durch "Emotet"
sollten Sie *niemals* MS-Office-Dokumente via E-Mail annehmen/öffenen,
selbst wenn diese von vermeintlich vertrauenswürdigen Absendern zu
stammen scheinen. Andernfalls droht Totalschaden.
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists