On 2024/10/28 17:46, neil.armstrong@linaro.org wrote:

[ EXTERNAL EMAIL ]

On 28/10/2024 10:36, Xianwei Zhao wrote:

quoted

Hi Neil,
    Thanks for your advice.

On 2024/10/28 17:09, neil.armstrong@linaro.org wrote:

quoted

[ EXTERNAL EMAIL ]

On 28/10/2024 10:07, Xianwei Zhao wrote:

quoted

Hi Neil,
     Based on the current discussion results, GPIO index macro 
definition does not belong to bindings. If so, the pinctrl driver 
keeps the existing architecture, and use numbers instead in dts 
file. Or the pinctrl driver use bank mode acess, this may not be 
compatible with existing frameworks. This is done by adding of_xlate 
hook functions in pinctrl_chip struct.

What is your advice that I can implement in the next version. Thanks!

Keep the driver as-is, but move the header file into 
arch/arm64/boot/dts/amlogic like it was done for the last reset 
controller support:
arch/arm64/boot/dts/amlogic/amlogic-t7-reset.h

I don't see examples C file applies dts header file.
C file need to be defined once, and this needs to be defined again in 
dts header file.

Sorry could you rephrase, the sentence isn't clear.

I'm sorry I didn't describe it clearly.

The pin index definition is used in driver C file and in DTS files.
It's not like reset definition only used in DTS files.
If the pin definition header file place arch/arm64/boot/dts/amlogic, so 
the driver C file needs to be defined again. I don't see examples of how 
a C file applies a DTS header file.

Neil

quoted

quoted

Neil

quoted

On 2024/10/21 23:27, Krzysztof Kozlowski wrote:

quoted

[ EXTERNAL EMAIL ]

On 21/10/2024 12:38, neil.armstrong@linaro.org wrote:

quoted

quoted

quoted

====><=================
+/* Standard port */
+#define GPIOB_START        0
+#define GPIOB_NUM  14
+
+#define GPIOD_START        (GPIOB_START + GPIOB_NUM)
+#define GPIOD_NUM  16
+
+#define GPIOE_START        (GPIOD_START + GPIOD_NUM)
+#define GPIOE_NUM  2
+
+#define GPIOT_START        (GPIOE_START + GPIOE_NUM)
+#define GPIOT_NUM  23
+
+#define GPIOX_START        (GPIOT_START + GPIOT_NUM)
+#define GPIOX_NUM  18
+
+#define PERIPHS_PIN_NUM    (GPIOX_START + GPIOX_NUM)
+
+/* Aobus port */
+#define GPIOAO_START       0
+#define GPIOAO_NUM 7
+
+/* It's a special definition, put at the end, just 1 num */
+#define    GPIO_TEST_N     (GPIOAO_START +  GPIOAO_NUM)
+#define    AOBUS_PIN_NUM   (GPIO_TEST_N + 1)
+
+#define AMLOGIC_GPIO(port, offset) (port##_START + (offset))
====><=================

is exactly what rob asked for, and you nacked it.

No, this is not what was asked, at least according to my 
understanding.
Number of GPIOs is not an ABI. Neither is their relationship, 
where one
starts and other ends.

I confirm this need some work, but it moved the per-pin define to 
start
and ranges, so what did rob expect ?

quoted

Maybe I missed something, but I could not find any users of these 
in the
DTS. Look:

https://lore.kernel.org/all/20241014-a4_pinctrl-v2-3-3e74a65c285e@amlogic.com/ (local)

So you want consumers before the bindings ? strange argument

quoted

Where is any of above defines?

Maybe they will be visible in the consumer code, but I did not 
imagine
such use. You expect:
reset-gpios = <&ctrl GPIOAO_START 1>???

No I expect:
reset-gpios = <&ctrl AMLOGIC_GPIO(B, 0) 1>;

but the macro should go along the dts like we did for the reset 
defines,
so perhaps this is the solution ?

OK, so I said it was not a binding:
https://lore.kernel.org/all/u4afxqc3ludsic4n3hs3r3drg3ftmsbcwfjltic2mb66foo47x@xe57gltl77hq/ (local)

and you here confirm, if I understood you correctly, that it goes with
the DTS like reset defines (I assume non-ID like defines?), so also 
not
a binding?

What are we disagreeing with?

Just to recall, Jerome asked whether you have to now use arbitrary
numbers in DTS and my answer was: not. It's still the same answer.

Best regards,
Krzysztof