From: Jorik Jonker <redacted>
This is v2 of my patch series. Just after sending I noticed the interrupts
of i2c1 were too liberally copy/paste'd. This is fixed in v2.
This series is a follow-up to Martin Ayotte's efforts to add additional UARTS
and I2C ports to the AllWinner H3 SoC DTS files. In this series I explicitly
leave out i2c2, since this is not broken out on my boards, so I cannot verify if
it actually works.
After the patch, one enables for example uart1 on a opi+ like this from u-boot:
=> fdt set /soc/serial at 01c28400 status okay
Regards,
Jorik
Jorik Jonker (7):
dts: sun8i-h3: add pinmux definitions for uart2/uart3
dts: sun8i-h3: add pinmux definitions for i2c0/i2c1
dts: sun8i-h3: add i2c0/i2c1 SoC peripherals
dts: sun8i-h3: add UART1-3 to Orange Pi Plus
dts: sun8i-h3: add UART1-3 to Orange Pi PC
dts: sun8i-h3: add I2C0-1 to Orange Pi Plus
dts: sun8i-h3: add I2C0-1 to Orange Pi PC
arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 25 ++++++++++++++
arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 25 ++++++++++++++
arch/arm/boot/dts/sun8i-h3.dtsi | 50 ++++++++++++++++++++++++++++
3 files changed, 100 insertions(+)
--
2.7.4
From: Jorik Jonker <redacted>
This adds proper pinmux definitions for i2c0 and i2c1. Although H3 has a third
i2c controller, these are not exposed on my boards. If someone actually has a
H3 board with an exposed i2c2, they could add the third.
Signed-off-by: Jorik Jonker <redacted>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
From: Jorik Jonker <redacted>
This enables the i2c0/i2c1 peripherals of the SoC. There is actually a third
controller, but I do not have a board on hands on which i2c2 is exposed in such
a way that I can verify that it works.
Signed-off-by: Jorik Jonker <redacted>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
@@ -161,6 +161,21 @@status="okay";};+&uart1{+pinctrl-names="default";+pinctrl-0=<&uart1_pins_a>;+};++&uart2{+pinctrl-names="default";+pinctrl-0=<&uart2_pins_a>;+};++&uart3{+pinctrl-names="default";+pinctrl-0=<&uart3_pins_a>;+};+&usbphy{/* USB VBUS is always on */status="okay";
On Thu, Sep 1, 2016 at 3:30 AM, [off-list ref] wrote:
From: Jorik Jonker <redacted>
This enables the i2c0/i2c1 peripherals of the SoC. There is actually a third
controller, but I do not have a board on hands on which i2c2 is exposed in such
a way that I can verify that it works.
If they are listed in the manual, and the interrupts, clocks, resets, pins
all exist, that is good enough for me.
On Thu, Sep 1, 2016 at 3:30 AM, [off-list ref] wrote:
quoted hunk
From: Jorik Jonker <redacted>
This adds proper pinmux definitions for i2c0 and i2c1. Although H3 has a third
i2c controller, these are not exposed on my boards. If someone actually has a
H3 board with an exposed i2c2, they could add the third.
Signed-off-by: Jorik Jonker <redacted>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Hi,
(trying again in plaintext, sorry for the HTML spam...)
A bit tricky to reply to two mails in one, as I think my reply relates
to both, but here it goes.
On 1 September 2016 at 04:42, Chen-Yu Tsai [off-list ref] wrote:
On Thu, Sep 1, 2016 at 3:30 AM, [off-list ref] wrote:
quoted
From: Jorik Jonker <redacted>
This enables the i2c0/i2c1 peripherals of the SoC. There is actually a third
controller, but I do not have a board on hands on which i2c2 is exposed in such
a way that I can verify that it works.
If they are listed in the manual, and the interrupts, clocks, resets, pins
all exist, that is good enough for me.
That sounds sensible, I will do that in v3.
These pinmuxes are the only ones possible for each peripheral.
Please drop the _a suffix and the @0 address for both of them.
Agreed. But: I think the same goes for UARTs 0-3, of which 0-1 have a pinmux
following the _a / @0 syntax in current kernel. There are not really options
here, except leaving out RTS/CTS on uarts1-3, which one could do in a
board-specific pinmux.
Moreover, I could put all the pinmux-peripheral associations for H3 in the DTSI,
removing them from the DTS files (including already existing), as the
associations themselves are not really board specific, right?
Best,
Jorik
Unfortunately, these pins can be used for other purposes as well, so
we cannot make force that decision down to our users.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160902/b90f2714/attachment.sig>
On Fri, Sep 02, 2016 at 09:04:25AM +0200, Maxime Ripard wrote:
Unfortunately, these pins can be used for other purposes as well, so
we cannot make force that decision down to our users.
Yes, but since the associated peripheral is disabled, the users are free
to configure other functions/peripherals, right? I mean something like
this in pseudo-DT:
/soc/pio: pinctrl at 01c20800/uart1_pins:
allwinner,pins = "PG6, PG7";
/soc/pio: pinctrl at 01c20800/foo0_pins:
allwinner,pins = "PG6, PG7";
..
/soc/uart1: serial at serial@01c28400:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
/soc/bar:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
Assuming Linux/DT allows this, this would force nothing, only offer
choice and ease of use.
Best,
Jorik
From: Maxime Ripard <hidden> Date: 2016-09-05 19:31:17
Hi Jorik,
On Sat, Sep 03, 2016 at 02:09:32PM +0200, Jorik Jonker wrote:
On Fri, Sep 02, 2016 at 09:04:25AM +0200, Maxime Ripard wrote:
quoted
Unfortunately, these pins can be used for other purposes as well, so
we cannot make force that decision down to our users.
Yes, but since the associated peripheral is disabled, the users are free to
configure other functions/peripherals, right? I mean something like this in
pseudo-DT:
/soc/pio: pinctrl at 01c20800/uart1_pins:
allwinner,pins = "PG6, PG7";
/soc/pio: pinctrl at 01c20800/foo0_pins:
allwinner,pins = "PG6, PG7";
..
/soc/uart1: serial at serial@01c28400:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
/soc/bar:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
Assuming Linux/DT allows this, this would force nothing, only offer choice
and ease of use.
Hmm, sorry, I went over your patches too quickly...
That's a great compromise I think. Chen-Yu, any opinion on this?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160905/5dfc6f12/attachment.sig>
On Tue, Sep 6, 2016 at 3:31 AM, Maxime Ripard
[off-list ref] wrote:
Hi Jorik,
On Sat, Sep 03, 2016 at 02:09:32PM +0200, Jorik Jonker wrote:
quoted
On Fri, Sep 02, 2016 at 09:04:25AM +0200, Maxime Ripard wrote:
quoted
Unfortunately, these pins can be used for other purposes as well, so
we cannot make force that decision down to our users.
Yes, but since the associated peripheral is disabled, the users are free to
configure other functions/peripherals, right? I mean something like this in
pseudo-DT:
/soc/pio: pinctrl at 01c20800/uart1_pins:
allwinner,pins = "PG6, PG7";
/soc/pio: pinctrl at 01c20800/foo0_pins:
allwinner,pins = "PG6, PG7";
..
/soc/uart1: serial at serial@01c28400:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
/soc/bar:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
Assuming Linux/DT allows this, this would force nothing, only offer choice
and ease of use.
Hmm, sorry, I went over your patches too quickly...
That's a great compromise I think. Chen-Yu, any opinion on this?
In short, I'm ok with it. But please put an explicit
status = "disabled";
and probably a comment about how/where the peripheral can be
used in the board dts.
I intended to do this for the Banana Pis. Though my original plan
was to enable Raspberry Pi compatible peripherals by default, and
list the other peripherals that are defined by the vendor as
"disabled".
"Defined by the vendor" means that the vendor has some sort of
document associating the gpio header pins with the peripherals,
as shown in:
http://www.orangepi.org/Docs/Pindefinition.html#CON3_Definition
This should make it easier for the average user to enable the
peripherals. I'm not sure we should list _all_ possible ones
though. That would make the list very large, and some might
end up never being used.
Regards
ChenYu
On Tue, Sep 06, 2016 at 11:04:38AM +0800, Chen-Yu Tsai wrote:
In short, I'm ok with it. But please put an explicit
status = "disabled";
and probably a comment about how/where the peripheral can be
used in the board dts.
Allright, I will do that in v3.
I intended to do this for the Banana Pis. Though my original plan
was to enable Raspberry Pi compatible peripherals by default, and
list the other peripherals that are defined by the vendor as
"disabled".
"Defined by the vendor" means that the vendor has some sort of
document associating the gpio header pins with the peripherals,
as shown in:
http://www.orangepi.org/Docs/Pindefinition.html#CON3_Definition
This should make it easier for the average user to enable the
peripherals. I'm not sure we should list _all_ possible ones
though. That would make the list very large, and some might
end up never being used.
This is exactly what I was thinking, albeit I wanted to go a bit
'bigger': move all unambiguous pinmux/peripheral associations from the
H3 DTS files to the DTSI, complete them with known associations for
which there are drivers, and have all of these disabled. Reduce the
existing blocks in the DTS files to just "status = okay".
Peripherals requiring board-specific things (like emac, USB, voltage
regulators, displays) stay put in the DTS.
It will explodes the scope of my proposed change a bit, but if you are
OK with this, I will gladly do it.
Maxime, Chen-Yu: what do you think of this?
Best,
Jorik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160906/8b3d5987/attachment.sig>
From: Maxime Ripard <hidden> Date: 2016-09-06 20:01:12
On Tue, Sep 06, 2016 at 10:52:02AM +0200, Jorik Jonker wrote:
On Tue, Sep 06, 2016 at 11:04:38AM +0800, Chen-Yu Tsai wrote:
quoted
In short, I'm ok with it. But please put an explicit
status = "disabled";
and probably a comment about how/where the peripheral can be
used in the board dts.
Allright, I will do that in v3.
quoted
I intended to do this for the Banana Pis. Though my original plan
was to enable Raspberry Pi compatible peripherals by default, and
list the other peripherals that are defined by the vendor as
"disabled".
"Defined by the vendor" means that the vendor has some sort of
document associating the gpio header pins with the peripherals,
as shown in:
http://www.orangepi.org/Docs/Pindefinition.html#CON3_Definition
This should make it easier for the average user to enable the
peripherals. I'm not sure we should list _all_ possible ones
though. That would make the list very large, and some might
end up never being used.
This is exactly what I was thinking, albeit I wanted to go a bit 'bigger':
move all unambiguous pinmux/peripheral associations from the H3 DTS files to
the DTSI, complete them with known associations for which there are drivers,
and have all of these disabled. Reduce the existing blocks in the DTS files
to just "status = okay".
Peripherals requiring board-specific things (like emac, USB, voltage
regulators, displays) stay put in the DTS.
It will explodes the scope of my proposed change a bit, but if you are OK
with this, I will gladly do it.
Maxime, Chen-Yu: what do you think of this?
From: Maxime Ripard <hidden> Date: 2016-09-06 20:02:04
On Tue, Sep 06, 2016 at 11:04:38AM +0800, Chen-Yu Tsai wrote:
On Tue, Sep 6, 2016 at 3:31 AM, Maxime Ripard
[off-list ref] wrote:
quoted
Hi Jorik,
On Sat, Sep 03, 2016 at 02:09:32PM +0200, Jorik Jonker wrote:
quoted
On Fri, Sep 02, 2016 at 09:04:25AM +0200, Maxime Ripard wrote:
quoted
Unfortunately, these pins can be used for other purposes as well, so
we cannot make force that decision down to our users.
Yes, but since the associated peripheral is disabled, the users are free to
configure other functions/peripherals, right? I mean something like this in
pseudo-DT:
/soc/pio: pinctrl at 01c20800/uart1_pins:
allwinner,pins = "PG6, PG7";
/soc/pio: pinctrl at 01c20800/foo0_pins:
allwinner,pins = "PG6, PG7";
..
/soc/uart1: serial at serial@01c28400:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
/soc/bar:
pinctrl-0 = <&uart1_pins>;
status = "disabled";
Assuming Linux/DT allows this, this would force nothing, only offer choice
and ease of use.
Hmm, sorry, I went over your patches too quickly...
That's a great compromise I think. Chen-Yu, any opinion on this?
In short, I'm ok with it. But please put an explicit
status = "disabled";
and probably a comment about how/where the peripheral can be
used in the board dts.
I intended to do this for the Banana Pis. Though my original plan
was to enable Raspberry Pi compatible peripherals by default, and
list the other peripherals that are defined by the vendor as
"disabled".
"Defined by the vendor" means that the vendor has some sort of
document associating the gpio header pins with the peripherals,
as shown in:
http://www.orangepi.org/Docs/Pindefinition.html#CON3_Definition
This should make it easier for the average user to enable the
peripherals. I'm not sure we should list _all_ possible ones
though. That would make the list very large, and some might
end up never being used.