[PATCH V2 1/9] gpio: gpio-rockchip: parse gpio-ranges for bank id
kever.yang at rock-chips.com
Thu Mar 2 03:54:57 CET 2023
On 2023/2/23 16:59, Linus Walleij wrote:
> On Mon, Feb 13, 2023 at 11:28 PM Chris Morgan <macroalpha82 at gmail.com> wrote:
>> From: Chris Morgan <macromorgan at hotmail.com>
>> Use the new devicetree property of gpio-ranges to determine the GPIO
>> bank ID. Preserve the "old" way of doing things too, so that boards
>> can be migrated and tested gradually (I only have a 3566 and 3326 to
>> Signed-off-by: Chris Morgan <macromorgan at hotmail.com>
> gpio-ranges are not supposed to be used like this, because there is
> no semantic restrictions on how gpio-ranges are set up. For example:
> gpio-ranges = <&pfc 0 0 32>;
> that looks nice for this usecase, and I guess this is something
> like what you have but then look at this from arch/arm/boot/dts/hi3620.dtsi:
> gpio-ranges = < &pmx0 0 14 1 &pmx0 1 15 1 &pmx0 2 16 1
> &pmx0 3 16 1 &pmx0 4 16 1 &pmx0 5 16 1
> &pmx0 6 16 1 &pmx0 7 16 1>;
I can understand the gpio-ranges and pinctrl framework are flexible
enough for different hardware.
Rockchip SoC do not have this kind of GPIO/PINMUX hardware, one bank
GPIO is always
in one pinctrl/ioc for now, so this driver do work for rockchip platform
in U-Boot for now.
> This is perfectly fine as well. Ranges can start anywhere in the hardware
> offsets and go anywhere, and be set up in smaller chunks however
> the author of the DTS file wants it.
> I am pretty sure the same discontiguous
> ranges can be encoded into the rk_gpio relevant DTS files as well,
> so this is not a good solution to your problem.
> What has been used in the past is just some unique hardware ID in the
> device tree, so I would just add that.
> Linus Walleij
More information about the U-Boot