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@xxxxxxxxx -- +49-151-27565287
