Hi Peter,
On 1/3/23 13:54, Peter Robinson wrote:
Hi Quentin,
On 10/25/22 09:52, Peter Robinson wrote:
[...]
gpio0: gpio0@ff720000 {
gpio0: gpio@ff720000 {Thanks for looking at this update, I myself was playing with this for all Rockchip devices but it's really not that easy to do unfortunately.
Please note that this will break the gpio driver, c.f. the logic here: https://urldefense.com/v3/__https://source.denx.de/u-boot/u-boot/-/blob/mast...
If you check v2 of this patch series I've currnently dropped this patch for now.
Please DO NOT use the logic used in the kernel, it's broken and works by chance and will not work in U-Boot.
I'm tempted to add a new DT property like: rockchip,gpio-controller = <0>; in gpio0, rockchip,gpio-controller = <1>; in gpio1, etc....
I don't think U-boot cares too much about DT backward compatibility so this wouldn't be much of a problem. It's a different issue in the Linux kernel but that's not the place to discuss this :)
Well we do because for a SystemReady IR platform the firmware provides the DT and that's not a differnt DT to the one used in U-Boot.
So what ever that gets added in U-Boot needs to go upstream else it will just end up in a world of pain. Ultimately one way or the other this problem is going to have to be solved in U-Boot too.
I guess that's what Simon was working on in the last few months? c.f. https://lore.kernel.org/u-boot/20221102031312.216353-1-sjg@chromium.org/
Is the plan to get rid of those -u-boot.dtsi and have those properties replaced with the ones specified in the link above, directly in DTS in the Linux kernel? Otherwise I'm quite curious on how you plan to achieve this for SystemReady IR platforms? Or are you using U-Boot's DT for the kernel?
For now, like Jagan suggested, we could have those U-Boot-specific properties in the -u-boot.dtsi, if there's a need for a new DT property (which the kernel probably won't go for since that would break backward compatibility).
Another thought I had was to just check the register address of the gpio controller and do the mapping in the driver directly. Not nice, but the most straightforward fix I think.
Kever: what's the Rockchip plan here to sort this out?
I've notified Heiko about the shortcomings of the kernel implementation but unless the probe order of the gpio controllers in the pinctrl node is not stable or someone specifies gpio aliases which aren't matching the same numbering scheme as the SoC GPIO controllers, there is no hurry to fix it.
Cheers, Quentin