Message-ID: <8cb615cf-1b4e-49ba-91fc-6e1f5f57cd3c@kernel.org>
Date: Mon, 21 Oct 2024 08:31:23 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jerome Brunet <jbrunet@...libre.com>
Cc: Xianwei Zhao <xianwei.zhao@...ogic.com>,
 Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Neil Armstrong <neil.armstrong@...aro.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 18/10/2024 14:26, Jerome Brunet wrote:
> On Fri 18 Oct 2024 at 12:13, Krzysztof Kozlowski <krzk@...nel.org> wrote:
> 
>> On 18/10/2024 11:20, Jerome Brunet wrote:
>>> On Fri 18 Oct 2024 at 17:01, Xianwei Zhao <xianwei.zhao@...ogic.com> wrote:
>>>
>>>> Hi Jerome,
>>>>    Thanks for your reply.
>>>>
>>>> On 2024/10/18 16:39, Jerome Brunet wrote:
>>>>> [ EXTERNAL EMAIL ]
>>>>> On Fri 18 Oct 2024 at 10:28, Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>>>>
>>>>>> On 18/10/2024 10:10, Xianwei Zhao via B4 Relay wrote:
>>>>>>> From: Xianwei Zhao <xianwei.zhao@...ogic.com>
>>>>>>>
>>>>>>> Add the new compatible name for Amlogic A4 pin controller, and add
>>>>>>> a new dt-binding header file which document the detail pin names.
>>>>> the change does not do what is described here. At least the description
>>>>> needs updating.
>>>>>
>>>>
>>>> Will do.
>>>>
>>>>> So if the pin definition is now in the driver, does it mean that pins have
>>>>> to be referenced in DT directly using the made up numbers that are
>>>>> created in pinctrl-amlogic-a4.c at the beginning of patch #2 ?
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>> If that's case, it does not look very easy a read.
>>>>>
>>>>
>>>> It does happen. The pin definition does not fall under the category of
>>>> binding.
>>>>
>>>> https://lore.kernel.org/all/106f4321-59e8-49b9-bad3-eeb57627c921@amlogic.com/
>>>
>>> So the expectation is that people will write something like:
>>>
>>>  reset-gpios = <&gpio 42 GPIO_ACTIVE_LOW>;
>>>
>>> And others will go in the driver to see that is maps to GPIOX_10 ? the number
>>> being completly made up, with no link to anything HW/Datasheet
>>> whatsoever ?
>>>
>>> This is how things should be done now ?
>>
>> Why would you need to do this? Why it cannot be <&gpio 10
>> GPIO_ACTIVE_LOW>, assuming it is GPIO 10?
>>
>> Bindings have absolutely nothing to do with it. You have GPIO 10, not
>> 42, right?
> 
> That's what being proposed here, as far as I can see.
> 
> GPIOX_10 (not GPIO 10) maps to 42. If this goes through, for DTs to be
> valid in any OS, all need to share the same definition. That looks like
> a binding to me.
> 
> On these SOC, gpios in each controller are organized in bank with
> different number of pins. So far, this was represented as single linear
> array and that was not a problem since the mapping was part of the binding.
> 
> Are you suggesting 2 params instead of one ? something like this maybe ?
> 
> reset-gpios = <&gpio BANK_X 10 GPIO_ACTIVE_LOW>;

No, I propose the same as you wrote:
<&gpio 10 GPIO_ACTIVE_LOW>

but I don't mind putting bank there.

> 
> This means this A4 controller will be software incompatible with the
> previous generation. It will need to handled differently eventhough the
> HW is exactly the same.
> 
> Note that some form of binding would still be required to define the
> banks which are referenced by arbitrary letter in doc, not numbers.

Usually banks are considered separate gpio controllers, so numbering
always start from 0 because phandle encodes the bank.

And this is exactly what Rob already asked in v1 review.

Best regards,
Krzysztof

Powered by blists - more mailing lists