RE: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support

Subject: Re: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol
protocol basic support

On Sun, Feb 4, 2024 at 10:29 AM Peng Fan [off-list ref] wrote:

quoted

Using generic pinconf means the firmware needs exporting
groups/functions/pins and etc, the firmware design will be complicated and

code size enlarged.

This is very much to the core of the problem isn't it?

Yes. Code size should be as small as possible.

And using SCMI generic pinconf, there will be multiple
SCMI calls(not MMIO access), such as setting mux(ops->set_mux)
needs an SCMI call, pad settings(ops->pin_config_set) needs an SCMI call.
And maybe ops->get_function_name  needs an extra SCMI call.

With current i.MX design, only one SCMI call is used, which
use less time.

So the argument is to save code effort and size in the firmware.

This reflects some of the reasoning behind the device tree bindings that
encode "magic numbers" in the DT nodes to mux and configure pins. Often
the argument is that it saves space and effort.

When the i.MX driver was first discussed it used the standard scheme actually.
Look at i.MX 53 for example:
https://lore.ke/
rnel.org%2Flinux-kernel%2F1322999384-7886-2-git-send-email-
b29396%40freescale.com%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C
db0604b1366346a0da1108dc25b3607d%7C686ea1d3bc2b4c6fa92cd99c5c3
01635%7C0%7C0%7C638426699551848076%7CUnknown%7CTWFpbGZsb3
d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
%3D%7C0%7C%7C%7C&sdata=j%2FA%2BagoL2EXUzDSkg1wtSENPkuxb0YL1
nTTB7xCIBTE%3D&reserved=0

Groups and functions! As strings!

Then the DT bindings were discussed back and forth between Dong Aisheng
(the original driver author), Sasha Hauer and Shawn Guo before arriving at
the fsl,pins scheme.

Back in the day I was pretty much clueless about device tree and relied on
others to review the bindings, which ended up like this:
Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt

This was in 2011/2012 so many things were not considered. It is clear that
this scheme with a number of integers that get poked into registers is
convenient for some DT authors, also pinctrl-single uses this as well as I think
Mediatek and maybe a few others.

Over the years I have come to regret it a bit, I think insisting on groups and
functions as strings is better for abstraction. And the point of firmware is to
abstract things so they work the same on all systems.

With current:
        pinctrl_uart1: uart1grp {
                fsl,pins = <
                        IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX      0x31e
                        IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX      0x31e
                >;
        };

It is very easy for people to know the meaning from reading reference manual.

If using generic pinconf, the dt node will be like
Uartgrp {
        pins = "uart1txd", "uart1rxd";
        functions = "uart1";
        bias-xx
        drive-strength =
};

The firmware needs add more code to export functions, pack the conf settings,
each pins needs a function name per current i.MX HW logic.

And as I said above, more SCMI calls needed for configure a pin.

So it is not a good fit for i.MX platform using SCP processor to use generic
pinconf for SCMI as I think.

Thanks,
Peng.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel