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
