Message-ID: <CACRpkdZ19+zUCEBCJJ+MBnnaF+caZKFTDxYiWZ0BRGx+PxN3bw@mail.gmail.com>
Date: Wed, 29 May 2024 10:38:21 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Sean Anderson <sean.anderson@...ux.dev>
Cc: Michal Simek <michal.simek@....com>, linux-gpio@...r.kernel.org, 
	Krishna Potthuri <sai.krishna.potthuri@....com>, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, Conor Dooley <conor+dt@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/2] pinctrl: zynqmp: Support muxing individual pins

On Tue, May 28, 2024 at 4:28 PM Sean Anderson <sean.anderson@...ux.dev> 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.

> > If you want to mux individual pins instead of groups and functions, by
> > all means, but please do not mix the two approaches in the same
> > driver, I'm just trying to save Xilinx from themselves here.
>
> I see no point in creating thousands of groups

Please share your calculations for figures like "thousands".

In my experience, groups are usually in the tens, perhaps
hundreds, physically restricted by the number of pins
underneath a BGA. A Micro-FCBGA has 479 balls and many
are GND and power, so that sets a ballpark figure.

> for every combination of pin musings

It is clear from the documentation that the point if the pinmux
groups and pins are not to present all possible options (known as
a "phone exchange" solution) but those that are used in practice,
i.e. these representing real world use cases. See below.

> when we could just switch to the solution in this (or v2 of)
> patch. For compatibility we cannot be rid of the old situation, but we
> can at least fix it. There is no technical problem with them coexisting.

Historically there are  ~2 camps:

- One camp want to use groups and
functions to combine pins in groups with functions to form usecases.

In some cases (such as pinctrl-gemini.c or the very latest
pinctrl-scmi.c merged for v6.10) this reflects how the hardware
actually looks: it does not make individual pins available for muxing,
but you poke bits or send messages to change entire
groups-to-function mappings, so it is necessary for some hardware.

So when you write that "groups are a Linux-only concept" this
is because you probably haven't seen this part of the world.
Groups exist in hardware, and in the SCMI specification.

There are systems with individual control of the muxing
of every pin, such that e.g. every pin has a muxing register.

These are again not really phone exchanges: I am yet to see
a system where any function can be mapped to any pin. These
just do not exist. What exists in practice is that each pin can be
mapped to 2-4 functions, in extreme cases some more. Often
these functions are mapped to adjacent pins, and the "chessboard"
picture in the documentation for the subsystem reflects this.

For this reason, it is often helpful for driver writers to group
adjacent pins into groups, so an iterator can walk over the
pins and poke their registers in order, instead of treating each
pin as a unique entity.

- Then there is the camp that just by habit *want* to control
each pin individually. The extreme example is pinctrl-single.c
which is named like such because each pin is controlled by
a single register. TI wanted this solution mainly because their
hardware wasn't described in manuals, but in other HW
description files, and they needed to process large volumes
of data into DT-form.

I didn't like this solution initially because it makes it hard for
people without datasheets to understand what is going on.
But I was convinced to let this coexist with the group and function
mapping, which is fine: maybe one size doesn't fit all.

i.MX and others also do this approach but with large sets of
defines in the <dt-bindings/*> files.

Combining these two approaches is not something I recommend.

Yours,
Linus Walleij

Powered by blists - more mailing lists