Re: [PATCH] arm: dts: qcom: Sync pinctrl DT nodes with Linux bindings

[Stephan Gerhold <stephan@gerhold.net>]

On Fri, Jul 15, 2022 at 03:21:45PM +0530, Sumit Garg wrote:
> On Thu, 14 Jul 2022 at 23:45, Stephan Gerhold <stephan@gerhold.net> wrote:
> > On Thu, Jul 14, 2022 at 01:03:37PM +0530, Sumit Garg wrote:
> > > This is based on top of mine other patch-set [1]. Although, I have
> > > tested it on db845c and qcs404-evb but I would like other board
> > > maintainers to test it as well.
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=309135
> >
> > If possible I would prefer to introduce the QCS404 platform with a clean
> > DT (i.e. qcs404.dtsi imported from the Linux kernel, instead of adding
> > the custom qcs404-evb.dts and then cleaning it up). This patch would
> > need to come before the QCS404 addition then.
> >
> 
> Sorry but it's unfair to block new SoCs/boards support until all the
> existing mess around DT is cleaned up in Qcom specific u-boot drivers.
> This patch is a good example to demonstrate that all corresponding
> boards DT need to be fixed as well which requires testing. And I don't
> even have access to starqltechn, ipq4019 based board and db820c.
> 

Sorry, I thought this is the only patch you need to use the Linux QCS404
DT as-is (maybe I misunderstood). I'm not expecting that you clean up
all existing boards first of course. :) I just thought it would be nice
to start clean for QCS404 immediately if this is the only patch you need.

This patch looks simple enough for me if we test it on a couple of
boards, the pinctrl setup is fairly similar across all of them. However,
I wrote this before the comments with the additional "reg"s below. If we
need to add handling for that as well the patch will need to become a
bit larger of course, maybe too large to prepend it to your QCS404
series.

> AFAIK, it's not a requirement yet but a recommendation at this stage
> to import DT directly from Linux kernel and work with it. But I would
> be very happy to work in this direction to make Qcom SoCs/boards DT
> compliant. So I would request the merge of new boards support and then
> we can follow up with patches like this one.
> 

Thanks! I'm not familiar with the requirements so I'll leave this up to
Tom to decide. :)

> [...]
> > > diff --git a/arch/arm/dts/qcs404-evb.dts b/arch/arm/dts/qcs404-evb.dts
> > > index 4f0ae20bdb..09687e1fd3 100644
> > > --- a/arch/arm/dts/qcs404-evb.dts
> > > +++ b/arch/arm/dts/qcs404-evb.dts
> > > @@ -38,7 +38,7 @@
> > >               compatible = "simple-bus";
> > >
> > >               pinctrl_north@1300000 {
> > > -                     compatible = "qcom,tlmm-qcs404";
> > > +                     compatible = "qcom,qcs404-pinctrl";
> > >                       reg = <0x1300000 0x200000>;
> >
> > The Linux node still looks a bit different (from qcs404.dtsi):
> >
> >                 tlmm: pinctrl@1000000 {
> >                         compatible = "qcom,qcs404-pinctrl";
> >                         reg = <0x01000000 0x200000>,
> >                               <0x01300000 0x200000>,
> >                               <0x07b00000 0x200000>;
> >                         reg-names = "south", "north", "east";
> >
> > I guess we'll need to fetch the "north" region from it (if that's what
> > you need)?
> 
> This is another example of a shortcut already used by the u-boot
> pinctrl driver (arch/arm/mach-snapdragon/pinctrl-snapdragon.c). You
> can find another user here (arch/arm/dts/sdm845.dtsi). So the pinctrl
> drivers need to be converted to a format supported by Linux kernel.
> Also, the pinctrl drivers need to be moved to "drivers/pinctrl/qcom/"
> dir instead.
> 

Right. FYI, there is started work on one possible solution for this
here: https://github.com/minlexx/u-boot-2nd/commits/660

Basically Alexey (now in Cc) and Michael ported parts of the Linux
pinctrl-msm driver to U-Boot, in a way that you can mostly just copy the
platform specific definitions as-is. The additional memory regions are
handled correctly there AFAICT.

The code size overall is quite a bit higher of course, but I think this
is not a problem for any of the Qualcomm boards in U-Boot. The ease of
porting and flexibility should outweigh the cost here, I think.

Thanks,
Stephan