[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7c069b82-c31b-45cc-8cf3-a2181a56c2f5@amlogic.com>
Date: Mon, 28 Oct 2024 17:59:07 +0800
From: Xianwei Zhao <xianwei.zhao@...ogic.com>
To: neil.armstrong@...aro.org, Krzysztof Kozlowski <krzk@...nel.org>,
Jerome Brunet <jbrunet@...libre.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Kevin Hilman <khilman@...libre.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: pinctrl: Add support for Amlogic A4
SoCs
On 2024/10/28 17:46, neil.armstrong@...aro.org wrote:
> [ EXTERNAL EMAIL ]
>
> On 28/10/2024 10:36, Xianwei Zhao wrote:
>> Hi Neil,
>> Thanks for your advice.
>>
>> On 2024/10/28 17:09, neil.armstrong@...aro.org wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On 28/10/2024 10:07, Xianwei Zhao wrote:
>>>> 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
>
>>
>>> Neil
>>>
>>>>
>>>> On 2024/10/21 23:27, Krzysztof Kozlowski wrote:
>>>>> [ EXTERNAL EMAIL ]
>>>>>
>>>>> On 21/10/2024 12:38, neil.armstrong@...aro.org wrote:
>>>>>>>> ====><=================
>>>>>>>> +/* 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 ?
>>>>>>
>>>>>>>
>>>>>>> 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/
>>>>>>
>>>>>> So you want consumers before the bindings ? strange argument
>>>>>>
>>>>>>>
>>>>>>> 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/
>>>>>
>>>>> 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
>>>>>
>>>
>
Powered by blists - more mailing lists