Re: [PATCH 0/2] pinctrl: zynqmp: Support muxing individual pins

[Michal Simek]

On 6/3/24 11:02, Linus Walleij wrote:
> On Thu, May 30, 2024 at 7:08 PM Sean Anderson <sean.anderson@xxxxxxxxx> wrote:
> > On 5/29/24 04:38, Linus Walleij wrote:
> > > On Tue, May 28, 2024 at 4:28 PM Sean Anderson <sean.anderson@xxxxxxxxx> wrote:
> > >
> > > > Well, perhaps you should have reviewed the original driver more
> > > > closely.
> > >
> > > Do you want to push me down and increase my work related
> > > stress? Because that is the effect of such statements.
> > >
> > > It looks like criticism of me as a person, so explain yourself.
> > >
> > > Writing this kind of things looks to me like some kind of abusive way
> > > to express your desire and that is what burns maintainers out, so
> > > if that is what you are doing, stop doing that, adjust your behaviour
> > > and focus on technical issues.
> >
> > The technical issue is that the driver does not match the hardware. We
> > must maintain the existing set of groups for backwards-compatibility.
> > But this should not prevent improvement.
> >
> > Saying that we cannot have both group styles means that the driver is
> > permanently stuck with whatever was picked when it was submitted. Hence,
> > if you want to have only one style you had better review new drivers
> > very carefully.
>
> Actually I did say you can rewrite it to the other style, it's just work.
>
> If the previous approach was wrong, just redo it as it should be,
> and rewrite the DT bindings and the existing device trees. If
> backward-compatibility is so important, add a new driver with a new
> unique Kconfig CONFIG_PINCTRL_ZYNQMP_V2 and new bindings
> on the side and select one from a new compatible such as
> "xlnx,zynqmp-pinctrl-v2", problem solved:
> new driver new bindings, can be used on a per-board basis,
> can be compiled into the same kernel image.
>
> It may be embarrassing to have to tell the device tree maintainers
> that the bindings got wrong three years ago and now we need to roll
> a v2, but worse things have happened.
>
> I don't like the approach
> "this was done so we cannot redo it", we can always redo things,
> it is even expected as proven by Fred Brooks timeless statement
> in "The Mythical Man-Month": any team *will* always design
> a throw-away system whether they intend it or not, there will be
> a second version.
>
> This approach will be more clean, I think? Also it will be
> possible to phase over more boards and perhaps eventually
> drop the old driver and the old bindings.
>
> I'd like to hear from Xilinx/AMD how they want to solve this
> going forward.

Sorry for delay jumping to this long discussion. Groups were chosen because 
that's how design tool (Vivado) allow you to configure it. That's why these 
groups are described in TF-A. That's something what fits the need for most of 
use cases.
But then there is technical side of things what can be setup via registers.

If you look at uart0. There are 19 groups in Vivado. uart0_grp0 MIO2-3, etc 
uart0_grp19 MIO74-75 and that's what it is described today.
But it is completely valid if you take MIO 2 from grp0 and MIO75 from grp19.
It will work without any issue but likely we can't described it today.

Uart is interesting one because you can configure one RX channel and up to 19 
(number of groups) TX and it will work properly from HW perspective. I don't 
think you can describe it via DT today.

In Sean's use case with SD we don't have groups with less then 4 data pins but 
SD cards should be still working and that's what we can't really describe too.

I don't think Xilinx recommends these descriptions and normally customers are 
not design it like this but from HW perspective it should be working properly.


Regarding driver. I agree that describing all possible configurations via groups 
is not a good idea because describing all combinations is very hard. It is not 
unlimited number of them but that number is very very high and it won't serve 
the purpose.

TF-A should be capable to provide all information about configurations already 
it is just up to OS to use it properly.
If there is something missing we can take a look but we have already issue with 
TF-A running out of space.

From my perspective allowing functionality per single MIO pins is not a bad way 
to go.
Having it in separate driver is possible but don't think it is worth of effort.

I have asked Sai (driver owner) to take a look at the patch more closely.

Thanks,
Michal