Hi Arnd and Olof,
Here is a series I want you to apply to ASOC.
I know this series includes DT updates for ARM 32bit and ARM 64bit,
but this is intentional.
Please apply the whole series to one branch.
Otherwise, it would cause a build error and big conflicts.
(some DT files are shared between arch/arm and arch/arm64,
so it is impossible to split the series into two.)
Masahiro Yamada (9):
ARM: dts: uniphier: factor out ranges property of support card
ARM: dts: uniphier: rework UniPhier System Bus nodes
ARM: uniphier: add missing of_node_put()
ARM: dts: uniphier: add reference clock nodes
ARM: dts: uniphier: add EEPROM node for ProXstream2 Gentil board
ARM: dts: uniphier: enable I2C channel 2 of ProXstream2 Gentil board
ARM: dts: uniphier: add PH1-Pro4 Ace board support
ARM: dts: uniphier: add PH1-Pro4 Sanji board support
ARM: dts: uniphier: add @{address} to EEPROM node
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/uniphier-common32.dtsi | 26 +++--
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 8 --
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 4 +
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 8 --
arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts | 113 +++++++++++++++++++++
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 8 --
arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts | 108 ++++++++++++++++++++
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 4 +
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 4 +
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 8 --
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 25 +++--
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 8 --
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 4 +
arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 10 ++
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 4 +
arch/arm/boot/dts/uniphier-ref-daughter.dtsi | 2 +-
arch/arm/boot/dts/uniphier-support-card.dtsi | 5 +-
arch/arm/mach-uniphier/platsmp.c | 12 +--
.../boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 8 --
.../boot/dts/socionext/uniphier-ph1-ld10.dtsi | 18 ++--
21 files changed, 309 insertions(+), 80 deletions(-)
create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-ace.dts
create mode 100644 arch/arm/boot/dts/uniphier-ph1-pro4-sanji.dts
--
1.9.1
This property is used in common by several boards. Move it to the
common place (uniphier-support-card.dtsi). If necessary, each board
can still override the property.
Signed-off-by: Masahiro Yamada <redacted>
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 8 --------
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 8 --------
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 8 --------
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 8 --------
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 8 --------
arch/arm/boot/dts/uniphier-support-card.dtsi | 3 +++
arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 8 --------
7 files changed, 3 insertions(+), 48 deletions(-)
@@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)phys_addr_trom_rsv2_phys;intret;-np=of_find_compatible_node(NULL,NULL,-"socionext,uniphier-system-bus-controller");-ret=of_address_to_resource(np,1,&res);+np=of_find_compatible_node(NULL,NULL,"socionext,uniphier-smpctrl");+ret=of_address_to_resource(np,0,&res);if(ret){-pr_err("failed to get resource of system-bus-controller\n");+pr_err("failed to get resource of uniphier-smpctrl\n");returnret;}-rom_rsv2_phys=res.start+UNIPHIER_SBC_ROM_BOOT_RSV2;+rom_rsv2_phys=res.start+UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;ret=uniphier_smp_copy_trampoline(rom_rsv2_phys);if(ret)
@@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)phys_addr_trom_rsv2_phys;intret;-np=of_find_compatible_node(NULL,NULL,-"socionext,uniphier-system-bus-controller");-ret=of_address_to_resource(np,1,&res);+np=of_find_compatible_node(NULL,NULL,"socionext,uniphier-smpctrl");+ret=of_address_to_resource(np,0,&res);if(ret){-pr_err("failed to get resource of system-bus-controller\n");+pr_err("failed to get resource of uniphier-smpctrl\n");returnret;}-rom_rsv2_phys=res.start+UNIPHIER_SBC_ROM_BOOT_RSV2;+rom_rsv2_phys=res.start+UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;ret=uniphier_smp_copy_trampoline(rom_rsv2_phys);if(ret)
The previous binding has already been released. You can update, but your driver
should be able to handle the previous binding.
So, you still need to keep the old code around.
This has the benefit of breaking the dependency between the code change and the
DT change, so you no longer have to change your platform code at the same time
as the DT to avoid regressions.
Please adjust and resend. I'll hold off applying the series until then, so we
don't have a partially applied series.
Thanks!
-Olof
@@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)phys_addr_trom_rsv2_phys;intret;-np=of_find_compatible_node(NULL,NULL,-"socionext,uniphier-system-bus-controller");-ret=of_address_to_resource(np,1,&res);+np=of_find_compatible_node(NULL,NULL,"socionext,uniphier-smpctrl");+ret=of_address_to_resource(np,0,&res);if(ret){-pr_err("failed to get resource of system-bus-controller\n");+pr_err("failed to get resource of uniphier-smpctrl\n");returnret;}-rom_rsv2_phys=res.start+UNIPHIER_SBC_ROM_BOOT_RSV2;+rom_rsv2_phys=res.start+UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;ret=uniphier_smp_copy_trampoline(rom_rsv2_phys);if(ret)
The previous binding has already been released. You can update, but your driver
should be able to handle the previous binding.
So, you still need to keep the old code around.
This has the benefit of breaking the dependency between the code change and the
DT change, so you no longer have to change your platform code at the same time
as the DT to avoid regressions.
Please adjust and resend. I'll hold off applying the series until then, so we
don't have a partially applied series.
How long do I have to keep the support for the old binding?
[1]
Everyone makes mistakes.
The constraint for the DT-binding is really really painful.
This is how it happened.
At first, I implemented uniphier-system-bus.c based on the old binding.
Then, during the review, Mark suggested me to change the driver design:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387938.html
I followed his suggestion, but I needed to changed the DT-binding as well.
Before that time, the DT and other support code for UniPhier had been
partially merged
in the mainline. So, in the current tree exist two bindings that are
not compatible to
each other. This situation is really a mess.
I want to clean up the code as soon as possible.
[2]
For now, DT is mostly developed in the kernel tree in practice,
while DT is not theoretically only for Linux.
Everybody (at least every user of UniPhier SoCs) uses the combination
of a DTB and a kernel image
generated from the same Linux tree.
I see no reason to use a new DTB + an old kernel image, or vice versa.
[3]
This binding is UniPhier-specific. No impact on other SoC vendors.
Everything is under my control.
For now, I will prepare the logic to support the old binding,
but for the reasons above, please let me drop the support for the old
one some time later.
--
Best Regards
Masahiro Yamada
@@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)phys_addr_trom_rsv2_phys;intret;-np=of_find_compatible_node(NULL,NULL,-"socionext,uniphier-system-bus-controller");-ret=of_address_to_resource(np,1,&res);+np=of_find_compatible_node(NULL,NULL,"socionext,uniphier-smpctrl");+ret=of_address_to_resource(np,0,&res);if(ret){-pr_err("failed to get resource of system-bus-controller\n");+pr_err("failed to get resource of uniphier-smpctrl\n");returnret;}-rom_rsv2_phys=res.start+UNIPHIER_SBC_ROM_BOOT_RSV2;+rom_rsv2_phys=res.start+UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;ret=uniphier_smp_copy_trampoline(rom_rsv2_phys);if(ret)
The previous binding has already been released. You can update, but your driver
should be able to handle the previous binding.
So, you still need to keep the old code around.
This has the benefit of breaking the dependency between the code change and the
DT change, so you no longer have to change your platform code at the same time
as the DT to avoid regressions.
Please adjust and resend. I'll hold off applying the series until then, so we
don't have a partially applied series.
How long do I have to keep the support for the old binding?
You know your platform best -- how many users do you think you have
out there that might have built DTS files based on the old binding?
If there's a good chance there are none, or if you're in good contact
with them and can ask them to update, then you can be more flexible.
[1]
Everyone makes mistakes.
The constraint for the DT-binding is really really painful.
This is how it happened.
At first, I implemented uniphier-system-bus.c based on the old binding.
Then, during the review, Mark suggested me to change the driver design:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387938.html
I followed his suggestion, but I needed to changed the DT-binding as well.
Before that time, the DT and other support code for UniPhier had been
partially merged
in the mainline. So, in the current tree exist two bindings that are
not compatible to
each other. This situation is really a mess.
I want to clean up the code as soon as possible.
Yeah, I understand that it's hard to come up with perfect bindings
from day one, and that's why we sometimes have to play by ear.
It's not a bad idea to get practice on how to solve it -- in this case
it wouldn't really bad that bad. If you use variables to hold the base
addresses, and get them from either binding, you'll only special-case
during probe and not anywhere else in the driver.
The general idea of decoupling DT changes from code changes is also a
good habit.
[2]
For now, DT is mostly developed in the kernel tree in practice,
while DT is not theoretically only for Linux.
Everybody (at least every user of UniPhier SoCs) uses the combination
of a DTB and a kernel image
generated from the same Linux tree.
I see no reason to use a new DTB + an old kernel image, or vice versa.
We're not aiming to support new DTB + old kernel image. The main
problem is if someone has a product DTB that's not yet merged, and you
change the binding, then their DTB might no longer work. It's not a
huge deal, and for most changes it's fairly harmless, but the general
principle still applies.
As I said earlier, you know the users of your platform the best (I
hope :), so you'll have the best feel for whether this is a breakage
they will hurt from or not.
[3]
This binding is UniPhier-specific. No impact on other SoC vendors.
Everything is under my control.
For now, I will prepare the logic to support the old binding,
but for the reasons above, please let me drop the support for the old
one some time later.
Yeah, I'm perfectly fine with not keeping it for a long time. For
example, feel free to remove it next release if you think that will
work for your downstream users.
-Olof
@@ -98,15 +98,14 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)phys_addr_trom_rsv2_phys;intret;-np=of_find_compatible_node(NULL,NULL,-"socionext,uniphier-system-bus-controller");-ret=of_address_to_resource(np,1,&res);+np=of_find_compatible_node(NULL,NULL,"socionext,uniphier-smpctrl");+ret=of_address_to_resource(np,0,&res);if(ret){-pr_err("failed to get resource of system-bus-controller\n");+pr_err("failed to get resource of uniphier-smpctrl\n");returnret;}-rom_rsv2_phys=res.start+UNIPHIER_SBC_ROM_BOOT_RSV2;+rom_rsv2_phys=res.start+UNIPHIER_SMPCTRL_ROM_BOOT_RSV2;ret=uniphier_smp_copy_trampoline(rom_rsv2_phys);if(ret)
The previous binding has already been released. You can update, but your driver
should be able to handle the previous binding.
So, you still need to keep the old code around.
This has the benefit of breaking the dependency between the code change and the
DT change, so you no longer have to change your platform code at the same time
as the DT to avoid regressions.
Please adjust and resend. I'll hold off applying the series until then, so we
don't have a partially applied series.
How long do I have to keep the support for the old binding?
You know your platform best -- how many users do you think you have
out there that might have built DTS files based on the old binding?
If there's a good chance there are none, or if you're in good contact
with them and can ask them to update, then you can be more flexible.
quoted
[1]
Everyone makes mistakes.
The constraint for the DT-binding is really really painful.
This is how it happened.
At first, I implemented uniphier-system-bus.c based on the old binding.
Then, during the review, Mark suggested me to change the driver design:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/387938.html
I followed his suggestion, but I needed to changed the DT-binding as well.
Before that time, the DT and other support code for UniPhier had been
partially merged
in the mainline. So, in the current tree exist two bindings that are
not compatible to
each other. This situation is really a mess.
I want to clean up the code as soon as possible.
Yeah, I understand that it's hard to come up with perfect bindings
from day one, and that's why we sometimes have to play by ear.
It's not a bad idea to get practice on how to solve it -- in this case
it wouldn't really bad that bad. If you use variables to hold the base
addresses, and get them from either binding, you'll only special-case
during probe and not anywhere else in the driver.
The general idea of decoupling DT changes from code changes is also a
good habit.
quoted
[2]
For now, DT is mostly developed in the kernel tree in practice,
while DT is not theoretically only for Linux.
Everybody (at least every user of UniPhier SoCs) uses the combination
of a DTB and a kernel image
generated from the same Linux tree.
I see no reason to use a new DTB + an old kernel image, or vice versa.
We're not aiming to support new DTB + old kernel image. The main
problem is if someone has a product DTB that's not yet merged, and you
change the binding, then their DTB might no longer work. It's not a
huge deal, and for most changes it's fairly harmless, but the general
principle still applies.
As I said earlier, you know the users of your platform the best (I
hope :), so you'll have the best feel for whether this is a breakage
they will hurt from or not.
quoted
[3]
This binding is UniPhier-specific. No impact on other SoC vendors.
Everything is under my control.
For now, I will prepare the logic to support the old binding,
but for the reasons above, please let me drop the support for the old
one some time later.
Yeah, I'm perfectly fine with not keeping it for a long time. For
example, feel free to remove it next release if you think that will
work for your downstream users.
OK, I split the series into two. (DT and non-DT updates)
Thanks.
--
Best Regards
Masahiro Yamada
This board has an EEPROM (STMicroelectronics M24C64-WMN6TP) connected
to the I2C channel 0 of the SoC. Its slave address is 0x54.
Signed-off-by: Masahiro Yamada <redacted>
---
arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 5 +++++
1 file changed, 5 insertions(+)
This is used for on-board inter-connection.
Signed-off-by: Masahiro Yamada <redacted>
---
arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 5 +++++
1 file changed, 5 insertions(+)
This node pointer is allocated by of_find_compatible_node() in this
function. It should be put before exitting this function.
Signed-off-by: Masahiro Yamada <redacted>
---
arch/arm/mach-uniphier/platsmp.c | 1 +
1 file changed, 1 insertion(+)
@@ -100,6 +100,7 @@ static int __init uniphier_smp_prepare_trampoline(unsigned int max_cpus)np=of_find_compatible_node(NULL,NULL,"socionext,uniphier-smpctrl");ret=of_address_to_resource(np,0,&res);+of_node_put(np);if(ret){pr_err("failed to get resource of uniphier-smpctrl\n");returnret;