On Thu, Mar 02, 2023 at 10:54:57AM +0800, Kever Yang wrote:
Hi Linus,
On 2023/2/23 16:59, Linus Walleij wrote:
On Mon, Feb 13, 2023 at 11:28 PM Chris Morgan macroalpha82@gmail.com wrote:
From: Chris Morgan macromorgan@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 test).
Signed-off-by: Chris Morgan macromorgan@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.
Thanks,
- Kever
I think I jumped the gun (sorry, just anxious to get my hardware supported) and it looks like Linux is going in a different direction. I'm going to work with this for now, but once Linux decides on a correct direction I'll update the driver in U-Boot to match the Linux behavior.
Thank you.
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.
Yours, Linus Walleij