Messages in this thread | | | Date | Tue, 3 Oct 2023 10:34:08 +0900 | From | AKASHI Takahiro <> | Subject | Re: [RFC 4/4] dt-bindings: gpio: Add bindings for SCMI pinctrl based gpio |
| |
Hi Rob, Cristian,
On Mon, Oct 02, 2023 at 03:58:27PM +0100, Cristian Marussi wrote: > On Mon, Oct 02, 2023 at 09:41:55AM -0500, Rob Herring wrote: > > On Mon, Oct 02, 2023 at 11:16:02AM +0900, AKASHI Takahiro wrote: > > > A dt binding for SCMI pinctrl based gpio driver is defined in this > > > commit. It basically conforms to generic pinctrl-gpio mapping framework. > > [ snip] > > > > + additionalProperties: false > > > + > > > +required: > > > + - compatible > > > + - gpio-controller > > > + - "#gpio-cells" > > > + - gpio-ranges > > > + > > > +additionalProperties: false > > > + > > > +examples: > > > + - | > > > + #include <dt-bindings/gpio/gpio.h> > > > + > > > + scmi_gpio_0: scmi_gpio@0 { > > > > gpio { > > > > But doesn't SCMI have protocol numbers? > > > > My understanding is that this RFC GPIO driver from Akashi is built > completely on Pinctrl facilities (as he says in the cover), it is not > indeed a typical pure SCMI driver, it just happen to trigger the use > of SCMI if the underlying backend pinctrl driver is pinctrl-scmi; > but this driver does not really call directly into any SCMI API by > itself, i.e. it does not get and call any SCMI protocol ops. > (but it could indeed trigger the backend Pinctrl SCMI driver to issue > such call on its behalf AFAIU...)
It would be possible to implement this driver by directly using SCMI pinctrl interfaces (I mean drivers/firmware/arm,scmi/pinctrl.c) if the system wants to utilize SCMI solely for GPIO accesses and doesn't need pinctrl support. (Even so, "protocol@19" will be required due to the current SCMI binding.)
But I didn't take this approach because the kernel's pinctrl framework (and many existing pinctrl drivers) instead adopts standard pinctrl- gpio mapping (I mean gpiolib(-of).c) and it just seems to work well.
> I wonder why it has even a dependency on PINCTRL_SCMI at this point; > is not that it could work (generically) even if the backend Pinctrl > driver is NOT SCMI ? > What makes it usable only against an SCMI Pinctrl backend ? > Cannot be a generic GPIO driver based on top of Pinctrl, no matter which > Pinctrl backend driver has been configured ?
That is one of my questions (See the issue (3) in my cover letter.) Why doesn't there exist a generic GPIO driver of this kind (based on gpiolib framework) even though it could apparently be possible?
I guess that there a couple of reasons: 1) As I mentioned in the issue (1) in my cover letter, the current framework doesn't present an interface, especially for obtaining a value on a gpio input pin. Then it enforces each pinctrl-based gpio driver needs to have its own driver. 2) Furthermore, there may be driver-specific semantics required, say, for pinconf-related configurations? (I don't come up with any example, though)
If my driver is good enough for applying to other gpio controllers as well, I would not hesitate to name it a genuine generic driver whether the backend may be SCMI or not. -> Linus, comment here please.
Due to possible cases of (2), I still added "-generic" postfix to the "compatibles" property so that other variant drivers may be tagged as "arm,scmi-gpio-some-system" or "some-vendor,scmi-gpio".
Thanks, -Takahiro Akashi
> > ...I maybe missing something here about Pinctrl AND GPIO frameworks :P > > Thanks, > Cristian
| |