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
