RE: [PATCH 4/7] arm: dts: r7s72100: Add pin controller node
From: Chris Brandt <Chris.Brandt@renesas.com>
Date: 2017-03-03 13:24:51
Also in:
linux-devicetree, linux-renesas-soc
Hi Geert, On Friday, March 03, 2017, Geert Uytterhoeven wrote:
quoted
Is it possible to change the number of port pins in the board dts file? For example: RZ/A1H: P5_0 - P5_10 RZ/A1L: P5_0 - P5_16That's 17 pins, not 16?
Oops, I meant P5_15 Looking at the parts, here are the differences: RZ/A1H RZ/A1L ------------------ P2_0:15 P2_0:9 P4_0:15 P4_0:7 P5_0:10 P5_0:15 P7_0:15 P7_0:11 P9_0:7 P9_0:5 P10_0:15 none P11_0:15 none
quoted
So, in a rza1l-board.dts file I would put: &port5 { gpio-ranges = <&pinctrl 0 80 16>; } Will this work?Yes, overriding should work. But the number of pins is an SoC-property, not a board-property?
True, but I am trying to figure out how to solve this locally and not make it an upstream problem.
Are the differences between RZ/A1H and RZ/A1L just the number of pins?
Yes/No. Internally, the IP blocks are the same, and located at the same register addresses, but come out to different port pins due to the RZ/A1L having smaller packages. Also, the L has less channels than the H. For example: QSPI: H=2, L=1 LCD: H=2, L=1 SCIF: H=8, L=5 CAN: H=5, L=2 Of course there is some IP that only comes in the H. This is why I didn't want to associate "names" with the pins in a pfc driver. I just wanted the board DT to assign a pin to a 'function number'.
If yes, you could use a hierarchical DTS structure:
rza1h-<board>.dts:
#include "rza1h.dtsi"
// board specifics here
rza1l-<board>.dts:
#include "rza1l.dtsi"
// board specifics here
rza1h.dtsi:
#include "rza.dtsi" // r7s72100.dtsi?
// base SoC overrides
&port5 {
gpio-ranges = <&pinctrl 0 80 11>;
}
rza1l.dtsi:
#include "rza.dtsi" // r7s72100.dtsi?
// base SoC overrides
&port5 {
gpio-ranges = <&pinctrl 0 80 16>;
}
Actual naming of DTS files TBD.
OK, so just put the pin differences in the two files. That's a good idea. But,
then that's 2 more files to add upstream.
As the RZ/A series continues, they might keep doing this kind of thing, so I
don't want to get into the habit of adding more and more DT files.
# I wish there was some type of if-else syntax in Device Tree so in the
board file I could just say:
/ {
model = "RSKRZA1";
compatible = "renesas,rskrza1", "renesas,r7s72100";
variant = "rza1l";
We could also decide to not have rza1h.dtsi, and assume the base dtsi is for RZ/A1H.
Honestly, I'm fine with RZ/A1H being the flagship upstream SoC since it is a superset of all the peripherals in RZ/A1M,/A1L,/A1LU,/A1LC. Meaning, this small difference can be handled in a simple board file addition. I was thinking I was going to post some DT examples on eLinux.org anyway, so one of them would just be this RZ/A1L fix. Cheers Chris