devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: neil.armstrong@linaro.org
To: Xianwei Zhao <xianwei.zhao@amlogic.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Jerome Brunet <jbrunet@baylibre.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: pinctrl: Add support for Amlogic A4 SoCs
Date: Mon, 28 Oct 2024 10:09:45 +0100	[thread overview]
Message-ID: <78e6ca30-9fd6-4384-9583-440c485fb8ed@linaro.org> (raw)
In-Reply-To: <24acd645-4094-48aa-82e3-42d30a340884@amlogic.com>

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

Neil

> 
> On 2024/10/21 23:27, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On 21/10/2024 12:38, neil.armstrong@linaro.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
>>


  reply	other threads:[~2024-10-28  9:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-18  8:10 [PATCH v3 0/3] Pinctrl: A4: Add pinctrl driver Xianwei Zhao via B4 Relay
2024-10-18  8:10 ` [PATCH v3 1/3] dt-bindings: pinctrl: Add support for Amlogic A4 SoCs Xianwei Zhao via B4 Relay
2024-10-18  8:28   ` Krzysztof Kozlowski
2024-10-18  8:39     ` Jerome Brunet
2024-10-18  9:01       ` Xianwei Zhao
2024-10-18  9:20         ` Jerome Brunet
2024-10-18 10:13           ` Krzysztof Kozlowski
2024-10-18 12:26             ` Jerome Brunet
2024-10-21  6:31               ` Krzysztof Kozlowski
2024-10-21  6:32                 ` Krzysztof Kozlowski
2024-10-18 12:31             ` Neil Armstrong
2024-10-18 15:31               ` Krzysztof Kozlowski
2024-10-21  7:38                 ` neil.armstrong
2024-10-21  9:56                   ` Krzysztof Kozlowski
2024-10-21 10:38                     ` neil.armstrong
2024-10-21 15:27                       ` Krzysztof Kozlowski
2024-10-28  9:07                         ` Xianwei Zhao
2024-10-28  9:09                           ` neil.armstrong [this message]
2024-10-28  9:36                             ` Xianwei Zhao
2024-10-28  9:46                               ` neil.armstrong
2024-10-28  9:59                                 ` Xianwei Zhao
2024-10-28 10:44                                   ` neil.armstrong
2024-11-08  6:18                                     ` Xianwei Zhao
2024-10-18  8:10 ` [PATCH v3 2/3] pinctrl: meson: Add driver " Xianwei Zhao via B4 Relay
2024-10-18 15:51   ` Christophe JAILLET
2024-10-28  9:46     ` Xianwei Zhao
2024-10-18  8:10 ` [PATCH v3 3/3] arm64: dts: amlogic: a4: add pinctrl node Xianwei Zhao via B4 Relay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=78e6ca30-9fd6-4384-9583-440c485fb8ed@linaro.org \
    --to=neil.armstrong@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=robh@kernel.org \
    --cc=xianwei.zhao@amlogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).