Re: [PATCH RFC] dt-bindings: pinctrl: support specifying pins

[Andy Shevchenko]

On Fri, Nov 12, 2021 at 2:16 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * Andy Shevchenko <andy.shevchenko@xxxxxxxxx> [211112 11:22]:
> > > We only need the SoC specific data for the booted SoC, so devicetree
> > > and loadable modules makes more sense there compared to the current
> > > built-in setup.
> >
> > I'm against putting that into DT and here is why.
> >
> > DT is the thing that describes the _platform_. While it's fine to put
> > GPIO expander thingy (and we actually do this with labeling schema for
> > GPIOs, right?), the SoC level of things is a _hardware_ and with all
> > flexibility the DT gives us we will definitely have a deviations on
> > _different_ platforms with _the same_ SoC! To work around this we must
> > have a validation of the pin names and their functions in many places.
>
> I think you are misunderstanding what I mean here.

Ah, okay. Thanks for explaining!

>  Certainly the driver
> needs to know how to deal with the SoC specific hardware. And that we
> can easily do that in quite easily already. The device tree data I'm
> describing would be similar to the interrupts with instance offset and
> generic mux flags.
>
> See for example the driver for drivers/pinctrl/ti/pinctrl-ti-iodelay.c.
> For that driver we have the instance and picosecond iodelay values in
> the devicetree, and with #nr-pinctrl cells there could be some generic
> pinctrl mux flags. We are missing the generic pinctrl flags part AFAIK.
>
> > And last but not least the copying it in tons of DT feels like a
> > duplication effort.,
>
> Hmm I don't think we have any of that for what I'm describing. But
> please take a look at the iodelay example above, maybe I'm not
> following.
>
> > AFAIU the topic, the pin control lacks labeling schema that will
> > provide the view from the platform perspective, while driver provides
> > from HW perspective.
>
> Agreed we need a generic labeling schema.



-- 
With Best Regards,
Andy Shevchenko