MIME-Version: 1.0
References: <20211110231436.8866-1-zajec5@gmail.com> <CACRpkdbAS0JiqTQUU0R0yRhVCwagubwsNYLxj1DLE1Ldc+H_JQ@mail.gmail.com>
 <YY4+4Wb/H2ogKnQg@atomide.com> <CAHp75VeO4yr9fAx_-MHDnRGQn1paWF=59+o-9ZyP5PGSCPU8og@mail.gmail.com>
 <YY5bI+QzDA0zs/mN@atomide.com>
In-Reply-To: <YY5bI+QzDA0zs/mN@atomide.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Fri, 12 Nov 2021 14:20:55 +0200
Message-ID: <CAHp75Ve3GeM6UZExYhGdi59ogOHKt6_uzK9e+LMTyerpcHnwdQ@mail.gmail.com>
Subject: Re: [PATCH RFC] dt-bindings: pinctrl: support specifying pins
To:     Tony Lindgren <tony@atomide.com>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        devicetree <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <rafal@milecki.pl>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Nov 12, 2021 at 2:16 PM Tony Lindgren <tony@atomide.com> wrote:
> * Andy Shevchenko <andy.shevchenko@gmail.com> [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