arm64: dts: add all hi6220 uart nodes
Subsystems (2)
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
This patch adds all UART nodes for the Hi6220 SoC. Recently a board[1] has been developed to standardize UART access across all the 96boards consumer edition boards. To use this hardware on HiKey we must configure and enable UART3. However, to ensure backward compatibility we must keep UART0 enabled as well.
I have removed the hard coded clock index values in favor of using the ones already defined in include/dt-bindings/clock/hi6220-clock.h.
This patch was boot tested on top of next-20150929, with both UART configurations.
[1] http://www.seeedstudio.com/depot/96Boards-UART-p-2525.html?ref=newInBazaar
--- arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 4 +++ arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 43 +++++++++++++++++++++++++- 2 files changed, 46 insertions(+), 1 deletion(-)
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4 -0
@@ -18,6 +18,10 @@ aliases { serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; }; chosen {
arch/arm64/boot/dts/hisilicon/hi6220.dtsi +42 -1
56 lines not on this page · raw message
Signature · 1 line
2.1.4
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts line 25
Quoted 8 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Arnd
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 10 lines · Arnd Bergmann
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts line 25
Quoted 7 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };
Quoted 4 lines
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Unless I'm missing something there's only two UARTs brought out on the low speed expansion connector (in addition to the one on the solder pads which is currently supported). We should also adjust the console default to match whatever one of the low speed expansion connector UARTs is being used by the bootloader.
While we're at it there was a recent talk which mentioned a fairly large
amount of functionality that's apparently already "upstream" for this
device but not included in the DT, assuming that means that driver
support is there it would be good to add the corresponding DT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150930/b171b48d/attachment.sig>
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 11 lines · Mark Brown
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };
Quoted 4 lines
Quoted 4 lines
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Thanks for the comment Arnd. Mark's comment below is correct, there are only two UARTs accessible on the LS connection in addition to the one on the board (solder pad).
Is the following definition any clearer?
serial0 = &uart0; // Onboard UART0
serial1 = &uart2; // LS expansion UART0
serial2 = &uart3; // LS expansion UART1
If so, I'll respin this patch.
Quoted 5 lines
Unless I'm missing something there's only two UARTs brought out on the low speed expansion connector (in addition to the one on the solder pads which is currently supported). We should also adjust the console default to match whatever one of the low speed expansion connector UARTs is being used by the bootloader.
Your not missing anything, I should not have added the additional aliases, it is confusing, will remove. The UART boards by default come configured to use UART1 on the LS connector.
+ Peter as he has been submitting u-boot patches recently for the HiKey.
Obviously, both UEFI and u-boot can be configured to use either UART, and at the moment u-boot defaults to using the on board UART. Whereas UEFI is using UART1 on the LS connector. I'm fine with switching the console default to use the UART1 on the LS connector as long as there is agreement to do so.
Quoted 4 lines
While we're at it there was a recent talk which mentioned a fairly large amount of functionality that's apparently already "upstream" for this device but not included in the DT, assuming that means that driver support is there it would be good to add the corresponding DT.
Indeed, I think this comment is targeted to toward the d410c though as there are drivers for eMMC, and microsd drivers upstream but no DT bindings. I do not believe currently this is the case for HiKey.
Cheers,
Tyler
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 21 lines · Tyler Baker
Quoted 11 lines · Mark Brown
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };Quoted 4 lines
Quoted 4 lines
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Thanks for the comment Arnd. Mark's comment below is correct, there are only two UARTs accessible on the LS connection in addition to the one on the board (solder pad).
Quoted 5 lines
Is the following definition any clearer?
serial0 = &uart0; // Onboard UART0
serial1 = &uart2; // LS expansion UART0
serial2 = &uart3; // LS expansion UART1
Yes, but use C style comments.
What about the BT UART?
Quoted 9 lines
If so, I'll respin this patch.
Quoted 5 lines
Unless I'm missing something there's only two UARTs brought out on the low speed expansion connector (in addition to the one on the solder pads which is currently supported). We should also adjust the console default to match whatever one of the low speed expansion connector UARTs is being used by the bootloader.
Quoted 3 lines
Your not missing anything, I should not have added the additional aliases, it is confusing, will remove. The UART boards by default come configured to use UART1 on the LS connector.
Also, the console default should be set in chosen stdout-path so we can move away from having to set it on the kernel command line. Then the aliases don't matter so much, but there may be some work to do to setup a getty correctly.
Quoted 7 lines
+ Peter as he has been submitting u-boot patches recently for the HiKey.
Obviously, both UEFI and u-boot can be configured to use either UART, and at the moment u-boot defaults to using the on board UART. Whereas UEFI is using UART1 on the LS connector. I'm fine with switching the console default to use the UART1 on the LS connector as long as there is agreement to do so.
BTW, u-boot can output to multiple serial ports. I think I gave Peter details on how to do it.
Rob
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 22 lines · Rob Herring
Quoted 21 lines · Tyler Baker
Quoted 11 lines · Mark Brown
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };Quoted 4 lines
Quoted 4 lines
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Thanks for the comment Arnd. Mark's comment below is correct, there are only two UARTs accessible on the LS connection in addition to the one on the board (solder pad).
Quoted 7 lines
Quoted 5 lines
Is the following definition any clearer?
serial0 = &uart0; // Onboard UART0
serial1 = &uart2; // LS expansion UART0
serial2 = &uart3; // LS expansion UART1Yes, but use C style comments.
Ok.
Quoted 1 line
What about the BT UART?
According to the schematic it will use UART1, will add.
Quoted 8 lines
Quoted 8 lines
If so, I'll respin this patch.
Quoted 5 lines
Unless I'm missing something there's only two UARTs brought out on the low speed expansion connector (in addition to the one on the solder pads which is currently supported). We should also adjust the console default to match whatever one of the low speed expansion connector UARTs is being used by the bootloader.
Quoted 8 lines
Quoted 3 lines
Your not missing anything, I should not have added the additional aliases, it is confusing, will remove. The UART boards by default come configured to use UART1 on the LS connector.
Also, the console default should be set in chosen stdout-path so we can move away from having to set it on the kernel command line. Then the aliases don't matter so much, but there may be some work to do to setup a getty correctly.
Ok.
Cheers,
Tyler
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
In reply to Rob HerringQuoted 24 lines · Rob Herring
Quoted 23 lines · Tyler Baker
Quoted 11 lines · Mark Brown
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };Quoted 4 lines
Quoted 4 lines
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Thanks for the comment Arnd. Mark's comment below is correct, there are only two UARTs accessible on the LS connection in addition to the one on the board (solder pad).
Is the following definition any clearer?
Quoted 8 lines
Quoted 3 lines
serial0 = &uart0; // Onboard UART0
serial1 = &uart2; // LS expansion UART0
serial2 = &uart3; // LS expansion UART1Yes, but use C style comments.
What about the BT UART?
Yes, all four uarts are used in hikey board. uar0 is onboard serial uart. uart1 is
BT uart. uart2 & uart3 are connected to low speed expansion board. So Tyler shouldn't decrease any uart from his current patch.
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
In reply to Tyler BakerQuoted 9 lines · Tyler Baker
On 30 September 2015 at 10:31, Mark Brown <[email protected]> wrote:
+ Peter as he has been submitting u-boot patches recently for the HiKey.
Obviously, both UEFI and u-boot can be configured to use either UART, and at the moment u-boot defaults to using the on board UART. Whereas UEFI is using UART1 on the LS connector. I'm fine with switching the console default to use the UART1 on the LS connector as long as there is agreement to do so.
Given that UEFI is switching and the requirement for soldering to get to the on board UART it does seem to make sense, though it will create some pain for current users.
Quoted 8 lines
Quoted 4 lines
While we're at it there was a recent talk which mentioned a fairly large amount of functionality that's apparently already "upstream" for this device but not included in the DT, assuming that means that driver support is there it would be good to add the corresponding DT.
Indeed, I think this comment is targeted to toward the d410c though as there are drivers for eMMC, and microsd drivers upstream but no DT bindings. I do not believe currently this is the case for HiKey.
My understanding is that it applies to both with slightly different
driver sets, the slides aren't online yet (!) but if you look at 10:52
or so in the video we should have SD/eMMC on HiKey in v4.1 with thermal
and CPUfreq added in v4.2. It also looks like there's just some DT
additions needed to enable reset, cpuidle and CPU hotplug using generic
code (mainly the constants for PSCI I expect).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150930/43e93f7a/attachment.sig>
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 24 lines · Mark Brown
Quoted 9 lines · Tyler Baker
On 30 September 2015 at 10:31, Mark Brown <[email protected]> wrote:
+ Peter as he has been submitting u-boot patches recently for the HiKey.
Obviously, both UEFI and u-boot can be configured to use either UART, and at the moment u-boot defaults to using the on board UART. Whereas UEFI is using UART1 on the LS connector. I'm fine with switching the console default to use the UART1 on the LS connector as long as there is agreement to do so.
Given that UEFI is switching and the requirement for soldering to get to the on board UART it does seem to make sense, though it will create some pain for current users.
Quoted 8 lines
Quoted 4 lines
While we're at it there was a recent talk which mentioned a fairly large amount of functionality that's apparently already "upstream" for this device but not included in the DT, assuming that means that driver support is there it would be good to add the corresponding DT.
Indeed, I think this comment is targeted to toward the d410c though as there are drivers for eMMC, and microsd drivers upstream but no DT bindings. I do not believe currently this is the case for HiKey.
Quoted 6 lines
My understanding is that it applies to both with slightly different driver sets, the slides aren't online yet (!) but if you look at 10:52 or so in the video we should have SD/eMMC on HiKey in v4.1 with thermal and CPUfreq added in v4.2. It also looks like there's just some DT additions needed to enable reset, cpuidle and CPU hotplug using generic code (mainly the constants for PSCI I expect).
I just skimmed the video and I see your point. I'll need to investigate a bit but I'm up for sending some follow up patches to get these drivers functioning. First lets get the UART working :)
Cheers,
Tyler
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Hi Tyler, Mark,
Quoted 32 lines · Tyler Baker
Quoted 24 lines · Mark Brown
Quoted 9 lines · Tyler Baker
On 30 September 2015 at 10:31, Mark Brown <[email protected]> wrote:
+ Peter as he has been submitting u-boot patches recently for the HiKey.
Obviously, both UEFI and u-boot can be configured to use either UART, and at the moment u-boot defaults to using the on board UART. Whereas UEFI is using UART1 on the LS connector. I'm fine with switching the console default to use the UART1 on the LS connector as long as there is agreement to do so.
Given that UEFI is switching and the requirement for soldering to get to the on board UART it does seem to make sense, though it will create some pain for current users.
Quoted 8 lines
Quoted 4 lines
While we're at it there was a recent talk which mentioned a fairly large amount of functionality that's apparently already "upstream" for this device but not included in the DT, assuming that means that driver support is there it would be good to add the corresponding DT.
Indeed, I think this comment is targeted to toward the d410c though as there are drivers for eMMC, and microsd drivers upstream but no DT bindings. I do not believe currently this is the case for HiKey.
Quoted 6 lines
My understanding is that it applies to both with slightly different driver sets, the slides aren't online yet (!) but if you look at 10:52 or so in the video we should have SD/eMMC on HiKey in v4.1 with thermal and CPUfreq added in v4.2. It also looks like there's just some DT additions needed to enable reset, cpuidle and CPU hotplug using generic code (mainly the constants for PSCI I expect).
Quoted 3 lines
I just skimmed the video and I see your point. I'll need to investigate a bit but I'm up for sending some follow up patches to get these drivers functioning. First lets get the UART working :)
For Hikey's PM, related patches are ready for upstreaming [1].
Previously i'm waiting for merging mailbox driver, after that i plan to send out all DT patches to enable cpuidle/cpufreq/thermal/suspend in one going. Now pending on mailbox driver's merging.
If you think it's necessary, i could send out patches to enable cpuidle firstly (actually now PSCI has been enabled yet); for cpufreq and thermal features, need wait until mailbox driver has been merged.
[1] https://github.com/Leo-Yan/linux/commits/tracking-hikey-pm
Thanks,
Leo Yan
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 10 lines · Leo Yan
Quoted 8 lines · Tyler Baker
Quoted 6 lines · Mark Brown
My understanding is that it applies to both with slightly different driver sets, the slides aren't online yet (!) but if you look at 10:52 or so in the video we should have SD/eMMC on HiKey in v4.1 with thermal and CPUfreq added in v4.2. It also looks like there's just some DT additions needed to enable reset, cpuidle and CPU hotplug using generic code (mainly the constants for PSCI I expect).
Quoted 7 lines
Quoted 3 lines
I just skimmed the video and I see your point. I'll need to investigate a bit but I'm up for sending some follow up patches to get these drivers functioning. First lets get the UART working :)
If you think it's necessary, i could send out patches to enable cpuidle firstly (actually now PSCI has been enabled yet); for cpufreq and thermal features, need wait until mailbox driver has been merged.
It seems sensible to get the DT bits for functionality that is already
supported on the driver side upstream, that way we get the maximum
functionality available as soon as possible and even if other bits get
problems in review users can take advantage of things that are OK.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151001/e47c3524/attachment.sig>
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 15 lines · Mark Brown
Quoted 13 lines · Leo Yan
Quoted 12 lines · Tyler Baker
Quoted 6 lines · Mark Brown
My understanding is that it applies to both with slightly different driver sets, the slides aren't online yet (!) but if you look at 10:52 or so in the video we should have SD/eMMC on HiKey in v4.1 with thermal and CPUfreq added in v4.2. It also looks like there's just some DT additions needed to enable reset, cpuidle and CPU hotplug using generic code (mainly the constants for PSCI I expect).
I just skimmed the video and I see your point. I'll need to investigate a bit but I'm up for sending some follow up patches to get these drivers functioning. First lets get the UART working :)
Quoted 8 lines
Quoted 3 lines
If you think it's necessary, i could send out patches to enable cpuidle firstly (actually now PSCI has been enabled yet); for cpufreq and thermal features, need wait until mailbox driver has been merged.
It seems sensible to get the DT bits for functionality that is already supported on the driver side upstream, that way we get the maximum functionality available as soon as possible and even if other bits get problems in review users can take advantage of things that are OK.
Okay, i will prepare patches for enabling CPUIdle ASAP.
Thanks,
Leo Yan
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 8 lines · Leo Yan
Quoted 4 lines · Mark Brown
It seems sensible to get the DT bits for functionality that is already supported on the driver side upstream, that way we get the maximum functionality available as soon as possible and even if other bits get problems in review users can take advantage of things that are OK.
Okay, i will prepare patches for enabling CPUIdle ASAP.
Excellent, thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151002/c96700e4/attachment.sig>
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
In reply to Tyler BakerHi Tyler,
Quoted 35 lines · Tyler Baker
Quoted 11 lines · Mark Brown
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };Quoted 4 lines
Quoted 4 lines
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Thanks for the comment Arnd. Mark's comment below is correct, there are only two UARTs accessible on the LS connection in addition to the one on the board (solder pad).
Is the following definition any clearer?
serial0 = &uart0; // Onboard UART0
serial1 = &uart2; // LS expansion UART0
serial2 = &uart3; // LS expansion UART1If so, I'll respin this patch.
Quoted 5 lines
Unless I'm missing something there's only two UARTs brought out on the low speed expansion connector (in addition to the one on the solder pads which is currently supported). We should also adjust the console default to match whatever one of the low speed expansion connector UARTs is being used by the bootloader.
Quoted 5 lines
Your not missing anything, I should not have added the additional aliases, it is confusing, will remove. The UART boards by default come configured to use UART1 on the LS connector.
+ Peter as he has been submitting u-boot patches recently for the HiKey.
Thanks :)
Quoted 6 lines
Obviously, both UEFI and u-boot can be configured to use either UART, and at the moment u-boot defaults to using the on board UART. Whereas UEFI is using UART1 on the LS connector. I'm fine with switching the console default to use the UART1 on the LS connector as long as there is agreement to do so.
Eek... "serial2 = uart3 //UART1"
I sent the following patch
http://lists.denx.de/pipermail/u-boot/2015-September/227465.html
which has been accepted which switches from using UART0 (onboard) to UART3 (LS connector). This matched up with the change made in ATF i.e. both ATF and u-boot were then both outputting on the same UART.
So u-boot has already been migrated over.
regards,
Peter.
PATCH 1/1 arm64: dts: add all hi6220 uart nodes
Quoted 48 lines · Peter Griffin
Hi Tyler,
Quoted 35 lines · Tyler Baker
Quoted 11 lines · Mark Brown
Quoted 9 lines · Arnd Bergmann
Quoted 7 lines · On Tuesday 29 September 2015 13:29:12 Tyler Baker wrote:
aliases { serial0 = &uart0;arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts +4
-0+ serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; };Quoted 4 lines
Quoted 4 lines
In the changelog you mention "both uarts", but here you have five of them. Are they all accessible on the connector? If not, only provide aliases for the ones that are, using numbering that makes most sense for given how one would use the board.
Thanks for the comment Arnd. Mark's comment below is correct, there are only two UARTs accessible on the LS connection in addition to the one on the board (solder pad).
Is the following definition any clearer?
serial0 = &uart0; // Onboard UART0
serial1 = &uart2; // LS expansion UART0
serial2 = &uart3; // LS expansion UART1If so, I'll respin this patch.
Quoted 5 lines
Unless I'm missing something there's only two UARTs brought out on the low speed expansion connector (in addition to the one on the solder pads which is currently supported). We should also adjust the console default to match whatever one of the low speed expansion connector UARTs is being used by the bootloader.
Quoted 5 lines
Your not missing anything, I should not have added the additional aliases, it is confusing, will remove. The UART boards by default come configured to use UART1 on the LS connector.
+ Peter as he has been submitting u-boot patches recently for the HiKey.
Thanks :)
Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Obviously, both UEFI and u-boot can be configured to use either UART, and at the moment u-boot defaults to using the on board UART. Whereas UEFI is using UART1 on the LS connector. I'm fine with switching the console default to use the UART1 on the LS connector as long as there is agreement to do so.
Eek... "serial2 = uart3 //UART1"
Yeah, I fixed this in v2 :)
Quoted 8 lines
I sent the following patch
http://lists.denx.de/pipermail/u-boot/2015-September/227465.htmlwhich has been accepted which switches from using UART0 (onboard) to UART3 (LS connector). This matched up with the change made in ATF i.e. both ATF and u-boot were then both outputting on the same UART.
So u-boot has already been migrated over.
Excellent!
Cheers,
Tyler