* [PATCH v2 0/2] ARM: OMAP2+: wkup_m3_rproc support patches @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel, linux-omap, devicetree Cc: Ohad Ben-Cohen, Suman Anna, Kevin Hilman, Tony Lindgren, Felipe Balbi, Dave Gerlach Hi, This series adds the mach-omap2 code for the wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires the pdata added with patch 3 of the aforementioned series. The dt patch was previously included as part of the rproc series here [2]. Changes are: v1->v2: -Because the firmware loading has changed, the wkup_m3 node has moved into the soc node and ranges have been added so the device address to virtual address translation can work. -Removed the ti,no-reset-on-init flag as asserting the hard-reset line on init is what the wkup_m3 has by default already. Regards, Dave [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114621.html [2] http://www.spinics.net/lists/arm-kernel/msg387984.html Dave Gerlach (2): ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- arch/arm/mach-omap2/pdata-quirks.c | 13 +++++++++++++ 2 files changed, 26 insertions(+), 8 deletions(-) -- 2.3.0 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 0/2] ARM: OMAP2+: wkup_m3_rproc support patches @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel Hi, This series adds the mach-omap2 code for the wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires the pdata added with patch 3 of the aforementioned series. The dt patch was previously included as part of the rproc series here [2]. Changes are: v1->v2: -Because the firmware loading has changed, the wkup_m3 node has moved into the soc node and ranges have been added so the device address to virtual address translation can work. -Removed the ti,no-reset-on-init flag as asserting the hard-reset line on init is what the wkup_m3 has by default already. Regards, Dave [1] https://www.mail-archive.com/linux-omap at vger.kernel.org/msg114621.html [2] http://www.spinics.net/lists/arm-kernel/msg387984.html Dave Gerlach (2): ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- arch/arm/mach-omap2/pdata-quirks.c | 13 +++++++++++++ 2 files changed, 26 insertions(+), 8 deletions(-) -- 2.3.0 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 0/2] ARM: OMAP2+: wkup_m3_rproc support patches @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel, linux-omap, devicetree Cc: Ohad Ben-Cohen, Suman Anna, Kevin Hilman, Tony Lindgren, Felipe Balbi, Dave Gerlach Hi, This series adds the mach-omap2 code for the wkup_m3_rproc driver submitted here [1]. pdata-quirks patch requires the pdata added with patch 3 of the aforementioned series. The dt patch was previously included as part of the rproc series here [2]. Changes are: v1->v2: -Because the firmware loading has changed, the wkup_m3 node has moved into the soc node and ranges have been added so the device address to virtual address translation can work. -Removed the ti,no-reset-on-init flag as asserting the hard-reset line on init is what the wkup_m3 has by default already. Regards, Dave [1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114621.html [2] http://www.spinics.net/lists/arm-kernel/msg387984.html Dave Gerlach (2): ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- arch/arm/mach-omap2/pdata-quirks.c | 13 +++++++++++++ 2 files changed, 26 insertions(+), 8 deletions(-) -- 2.3.0 ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset 2015-03-05 4:12 ` Dave Gerlach (?) @ 2015-03-05 4:12 ` Dave Gerlach -1 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel, linux-omap, devicetree Cc: Ohad Ben-Cohen, Suman Anna, Kevin Hilman, Tony Lindgren, Felipe Balbi, Dave Gerlach Use pdata-quirks to provide platform data required for reset of the wkup_m3 during boot. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> --- This patch requires the pdata introduced in this patch: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114622.html arch/arm/mach-omap2/pdata-quirks.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c index 190fa43..7a09513 100644 --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -18,6 +18,7 @@ #include <linux/platform_data/pinctrl-single.h> #include <linux/platform_data/iommu-omap.h> +#include <linux/platform_data/wkup_m3.h> #include "common.h" #include "common-board-devices.h" @@ -287,6 +288,14 @@ static void __init omap3_tao3530_legacy_init(void) } #endif /* CONFIG_ARCH_OMAP3 */ +#ifdef CONFIG_SOC_AM33XX +static struct wkup_m3_platform_data wkup_m3_data = { + .reset_name = "wkup_m3", + .assert_reset = omap_device_assert_hardreset, + .deassert_reset = omap_device_deassert_hardreset, +}; +#endif + #ifdef CONFIG_ARCH_OMAP4 static void __init omap4_sdp_legacy_init(void) { @@ -382,6 +391,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = { OF_DEV_AUXDATA("ti,am3517-emac", 0x5c000000, "davinci_emac.0", &am35xx_emac_pdata), #endif +#ifdef CONFIG_SOC_AM33XX + OF_DEV_AUXDATA("ti,am3353-wkup-m3", 0x44d00000, "44d00000.wkup_m3", + &wkup_m3_data), +#endif #ifdef CONFIG_ARCH_OMAP4 OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux", &pcs_pdata), OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux", &pcs_pdata), -- 2.3.0 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel Use pdata-quirks to provide platform data required for reset of the wkup_m3 during boot. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> --- This patch requires the pdata introduced in this patch: https://www.mail-archive.com/linux-omap at vger.kernel.org/msg114622.html arch/arm/mach-omap2/pdata-quirks.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c index 190fa43..7a09513 100644 --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -18,6 +18,7 @@ #include <linux/platform_data/pinctrl-single.h> #include <linux/platform_data/iommu-omap.h> +#include <linux/platform_data/wkup_m3.h> #include "common.h" #include "common-board-devices.h" @@ -287,6 +288,14 @@ static void __init omap3_tao3530_legacy_init(void) } #endif /* CONFIG_ARCH_OMAP3 */ +#ifdef CONFIG_SOC_AM33XX +static struct wkup_m3_platform_data wkup_m3_data = { + .reset_name = "wkup_m3", + .assert_reset = omap_device_assert_hardreset, + .deassert_reset = omap_device_deassert_hardreset, +}; +#endif + #ifdef CONFIG_ARCH_OMAP4 static void __init omap4_sdp_legacy_init(void) { @@ -382,6 +391,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = { OF_DEV_AUXDATA("ti,am3517-emac", 0x5c000000, "davinci_emac.0", &am35xx_emac_pdata), #endif +#ifdef CONFIG_SOC_AM33XX + OF_DEV_AUXDATA("ti,am3353-wkup-m3", 0x44d00000, "44d00000.wkup_m3", + &wkup_m3_data), +#endif #ifdef CONFIG_ARCH_OMAP4 OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux", &pcs_pdata), OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux", &pcs_pdata), -- 2.3.0 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel, linux-omap, devicetree Cc: Ohad Ben-Cohen, Suman Anna, Kevin Hilman, Tony Lindgren, Felipe Balbi, Dave Gerlach Use pdata-quirks to provide platform data required for reset of the wkup_m3 during boot. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> --- This patch requires the pdata introduced in this patch: https://www.mail-archive.com/linux-omap@vger.kernel.org/msg114622.html arch/arm/mach-omap2/pdata-quirks.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c index 190fa43..7a09513 100644 --- a/arch/arm/mach-omap2/pdata-quirks.c +++ b/arch/arm/mach-omap2/pdata-quirks.c @@ -18,6 +18,7 @@ #include <linux/platform_data/pinctrl-single.h> #include <linux/platform_data/iommu-omap.h> +#include <linux/platform_data/wkup_m3.h> #include "common.h" #include "common-board-devices.h" @@ -287,6 +288,14 @@ static void __init omap3_tao3530_legacy_init(void) } #endif /* CONFIG_ARCH_OMAP3 */ +#ifdef CONFIG_SOC_AM33XX +static struct wkup_m3_platform_data wkup_m3_data = { + .reset_name = "wkup_m3", + .assert_reset = omap_device_assert_hardreset, + .deassert_reset = omap_device_deassert_hardreset, +}; +#endif + #ifdef CONFIG_ARCH_OMAP4 static void __init omap4_sdp_legacy_init(void) { @@ -382,6 +391,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = { OF_DEV_AUXDATA("ti,am3517-emac", 0x5c000000, "davinci_emac.0", &am35xx_emac_pdata), #endif +#ifdef CONFIG_SOC_AM33XX + OF_DEV_AUXDATA("ti,am3353-wkup-m3", 0x44d00000, "44d00000.wkup_m3", + &wkup_m3_data), +#endif #ifdef CONFIG_ARCH_OMAP4 OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux", &pcs_pdata), OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux", &pcs_pdata), -- 2.3.0 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel, linux-omap, devicetree Cc: Ohad Ben-Cohen, Suman Anna, Kevin Hilman, Tony Lindgren, Felipe Balbi, Dave Gerlach Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> --- arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index acd3705..086415c 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -77,10 +77,23 @@ */ soc { compatible = "ti,omap-infra"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x44d00000 0x4000>, + <0x80000 0x44d80000 0x2000>; + mpu { compatible = "ti,omap3-mpu"; ti,hwmods = "mpu"; }; + + wkup_m3: wkup_m3@44d00000 { + compatible = "ti,am3353-wkup-m3"; + reg = <0x0 0x4000>, /* M3 UMEM */ + <0x80000 0x2000>; /* M3 DMEM */ + ti,hwmods = "wkup_m3"; + ti,pm-firmware = "am335x-pm-firmware.elf"; + }; }; am33xx_control_module: control_module@4a002000 { @@ -755,14 +768,6 @@ reg = <0x40300000 0x10000>; /* 64k */ }; - wkup_m3: wkup_m3@44d00000 { - compatible = "ti,am3353-wkup-m3"; - reg = <0x44d00000 0x4000 /* M3 UMEM */ - 0x44d80000 0x2000>; /* M3 DMEM */ - ti,hwmods = "wkup_m3"; - ti,no-reset-on-init; - }; - elm: elm@48080000 { compatible = "ti,am3352-elm"; reg = <0x48080000 0x2000>; -- 2.3.0 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> --- arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index acd3705..086415c 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -77,10 +77,23 @@ */ soc { compatible = "ti,omap-infra"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x44d00000 0x4000>, + <0x80000 0x44d80000 0x2000>; + mpu { compatible = "ti,omap3-mpu"; ti,hwmods = "mpu"; }; + + wkup_m3: wkup_m3 at 44d00000 { + compatible = "ti,am3353-wkup-m3"; + reg = <0x0 0x4000>, /* M3 UMEM */ + <0x80000 0x2000>; /* M3 DMEM */ + ti,hwmods = "wkup_m3"; + ti,pm-firmware = "am335x-pm-firmware.elf"; + }; }; am33xx_control_module: control_module at 4a002000 { @@ -755,14 +768,6 @@ reg = <0x40300000 0x10000>; /* 64k */ }; - wkup_m3: wkup_m3 at 44d00000 { - compatible = "ti,am3353-wkup-m3"; - reg = <0x44d00000 0x4000 /* M3 UMEM */ - 0x44d80000 0x2000>; /* M3 DMEM */ - ti,hwmods = "wkup_m3"; - ti,no-reset-on-init; - }; - elm: elm at 48080000 { compatible = "ti,am3352-elm"; reg = <0x48080000 0x2000>; -- 2.3.0 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-05 4:12 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-05 4:12 UTC (permalink / raw) To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-omap-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: Ohad Ben-Cohen, Suman Anna, Kevin Hilman, Tony Lindgren, Felipe Balbi, Dave Gerlach Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> --- arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index acd3705..086415c 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -77,10 +77,23 @@ */ soc { compatible = "ti,omap-infra"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x44d00000 0x4000>, + <0x80000 0x44d80000 0x2000>; + mpu { compatible = "ti,omap3-mpu"; ti,hwmods = "mpu"; }; + + wkup_m3: wkup_m3@44d00000 { + compatible = "ti,am3353-wkup-m3"; + reg = <0x0 0x4000>, /* M3 UMEM */ + <0x80000 0x2000>; /* M3 DMEM */ + ti,hwmods = "wkup_m3"; + ti,pm-firmware = "am335x-pm-firmware.elf"; + }; }; am33xx_control_module: control_module@4a002000 { @@ -755,14 +768,6 @@ reg = <0x40300000 0x10000>; /* 64k */ }; - wkup_m3: wkup_m3@44d00000 { - compatible = "ti,am3353-wkup-m3"; - reg = <0x44d00000 0x4000 /* M3 UMEM */ - 0x44d80000 0x2000>; /* M3 DMEM */ - ti,hwmods = "wkup_m3"; - ti,no-reset-on-init; - }; - elm: elm@48080000 { compatible = "ti,am3352-elm"; reg = <0x48080000 0x2000>; -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-05 4:12 ` Dave Gerlach @ 2015-03-05 15:40 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-05 15:40 UTC (permalink / raw) To: Dave Gerlach Cc: linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Suman Anna, Kevin Hilman, Felipe Balbi * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > Signed-off-by: Suman Anna <s-anna@ti.com> > Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > --- > arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > index acd3705..086415c 100644 > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > @@ -77,10 +77,23 @@ > */ > soc { > compatible = "ti,omap-infra"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x44d00000 0x4000>, > + <0x80000 0x44d80000 0x2000>; > + I think putting the ranges here will cause issues for adding ranges for anything else. How about do something like this instead (untested): ocp { l4_wkup: l4_wkup@44c00000 { compatible = "am335-l4-wkup", "simple-bus"; ranges = <0 0x44c00000 0x3fffff>; wkup_m3: wkup_m3@44d00000 { compatible = "ti,am3353-wkup-m3"; reg = <0x1000000 0x4000>, /* M3 UMEM */ <0x180000 0x2000>; /* M3 DMEM */ ti,hwmods = "wkup_m3"; ti,pm-firmware = "am335x-pm-firmware.elf"; }; ... }; }; That way we can start moving also the other l4_wkup components there eventuallly without having to redo the ranges again for wkup_m3. You can also look at how the scm_conf was done for dm816x.dtsi for an example, and the recent large set of patches posted by Tero. Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-05 15:40 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-05 15:40 UTC (permalink / raw) To: linux-arm-kernel * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > Signed-off-by: Suman Anna <s-anna@ti.com> > Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > --- > arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > index acd3705..086415c 100644 > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > @@ -77,10 +77,23 @@ > */ > soc { > compatible = "ti,omap-infra"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0x0 0x44d00000 0x4000>, > + <0x80000 0x44d80000 0x2000>; > + I think putting the ranges here will cause issues for adding ranges for anything else. How about do something like this instead (untested): ocp { l4_wkup: l4_wkup at 44c00000 { compatible = "am335-l4-wkup", "simple-bus"; ranges = <0 0x44c00000 0x3fffff>; wkup_m3: wkup_m3 at 44d00000 { compatible = "ti,am3353-wkup-m3"; reg = <0x1000000 0x4000>, /* M3 UMEM */ <0x180000 0x2000>; /* M3 DMEM */ ti,hwmods = "wkup_m3"; ti,pm-firmware = "am335x-pm-firmware.elf"; }; ... }; }; That way we can start moving also the other l4_wkup components there eventuallly without having to redo the ranges again for wkup_m3. You can also look at how the scm_conf was done for dm816x.dtsi for an example, and the recent large set of patches posted by Tero. Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-05 15:40 ` Tony Lindgren (?) @ 2015-03-05 16:46 ` Suman Anna -1 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-05 16:46 UTC (permalink / raw) To: Tony Lindgren, Dave Gerlach Cc: linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi On 03/05/2015 09:40 AM, Tony Lindgren wrote: > * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: Dave, Looks like the commit message disappeared during your patch preparation. >> Signed-off-by: Suman Anna <s-anna@ti.com> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >> --- >> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >> 1 file changed, 13 insertions(+), 8 deletions(-) >> >> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >> index acd3705..086415c 100644 >> --- a/arch/arm/boot/dts/am33xx.dtsi >> +++ b/arch/arm/boot/dts/am33xx.dtsi >> @@ -77,10 +77,23 @@ >> */ >> soc { >> compatible = "ti,omap-infra"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0x0 0x44d00000 0x4000>, >> + <0x80000 0x44d80000 0x2000>; >> + > > I think putting the ranges here will cause issues for adding > ranges for anything else. > > How about do something like this instead (untested): > > ocp { > l4_wkup: l4_wkup@44c00000 { > compatible = "am335-l4-wkup", "simple-bus"; > ranges = <0 0x44c00000 0x3fffff>; > > wkup_m3: wkup_m3@44d00000 { > compatible = "ti,am3353-wkup-m3"; > reg = <0x1000000 0x4000>, /* M3 UMEM */ > <0x180000 0x2000>; /* M3 DMEM */ > ti,hwmods = "wkup_m3"; > ti,pm-firmware = "am335x-pm-firmware.elf"; > }; > > ... > }; > }; > > That way we can start moving also the other l4_wkup components there > eventuallly without having to redo the ranges again for wkup_m3. > > You can also look at how the scm_conf was done for dm816x.dtsi for an > example, and the recent large set of patches posted by Tero. > Tony, Thanks, I will take a look at this. I initially tried adding to ocp node directly, but obviously it had issues. But in general, you are ok with the ranges approach right, rather than having to define another property with virtual addresses. These devices are not on a separate bus like PCI, so I placed them in the soc node, and expect only special devices like processors to kinda go under that node. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-05 16:46 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-05 16:46 UTC (permalink / raw) To: linux-arm-kernel On 03/05/2015 09:40 AM, Tony Lindgren wrote: > * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: Dave, Looks like the commit message disappeared during your patch preparation. >> Signed-off-by: Suman Anna <s-anna@ti.com> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >> --- >> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >> 1 file changed, 13 insertions(+), 8 deletions(-) >> >> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >> index acd3705..086415c 100644 >> --- a/arch/arm/boot/dts/am33xx.dtsi >> +++ b/arch/arm/boot/dts/am33xx.dtsi >> @@ -77,10 +77,23 @@ >> */ >> soc { >> compatible = "ti,omap-infra"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0x0 0x44d00000 0x4000>, >> + <0x80000 0x44d80000 0x2000>; >> + > > I think putting the ranges here will cause issues for adding > ranges for anything else. > > How about do something like this instead (untested): > > ocp { > l4_wkup: l4_wkup at 44c00000 { > compatible = "am335-l4-wkup", "simple-bus"; > ranges = <0 0x44c00000 0x3fffff>; > > wkup_m3: wkup_m3 at 44d00000 { > compatible = "ti,am3353-wkup-m3"; > reg = <0x1000000 0x4000>, /* M3 UMEM */ > <0x180000 0x2000>; /* M3 DMEM */ > ti,hwmods = "wkup_m3"; > ti,pm-firmware = "am335x-pm-firmware.elf"; > }; > > ... > }; > }; > > That way we can start moving also the other l4_wkup components there > eventuallly without having to redo the ranges again for wkup_m3. > > You can also look at how the scm_conf was done for dm816x.dtsi for an > example, and the recent large set of patches posted by Tero. > Tony, Thanks, I will take a look at this. I initially tried adding to ocp node directly, but obviously it had issues. But in general, you are ok with the ranges approach right, rather than having to define another property with virtual addresses. These devices are not on a separate bus like PCI, so I placed them in the soc node, and expect only special devices like processors to kinda go under that node. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-05 16:46 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-05 16:46 UTC (permalink / raw) To: Tony Lindgren, Dave Gerlach Cc: linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi On 03/05/2015 09:40 AM, Tony Lindgren wrote: > * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: Dave, Looks like the commit message disappeared during your patch preparation. >> Signed-off-by: Suman Anna <s-anna@ti.com> >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >> --- >> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >> 1 file changed, 13 insertions(+), 8 deletions(-) >> >> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >> index acd3705..086415c 100644 >> --- a/arch/arm/boot/dts/am33xx.dtsi >> +++ b/arch/arm/boot/dts/am33xx.dtsi >> @@ -77,10 +77,23 @@ >> */ >> soc { >> compatible = "ti,omap-infra"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0x0 0x44d00000 0x4000>, >> + <0x80000 0x44d80000 0x2000>; >> + > > I think putting the ranges here will cause issues for adding > ranges for anything else. > > How about do something like this instead (untested): > > ocp { > l4_wkup: l4_wkup@44c00000 { > compatible = "am335-l4-wkup", "simple-bus"; > ranges = <0 0x44c00000 0x3fffff>; > > wkup_m3: wkup_m3@44d00000 { > compatible = "ti,am3353-wkup-m3"; > reg = <0x1000000 0x4000>, /* M3 UMEM */ > <0x180000 0x2000>; /* M3 DMEM */ > ti,hwmods = "wkup_m3"; > ti,pm-firmware = "am335x-pm-firmware.elf"; > }; > > ... > }; > }; > > That way we can start moving also the other l4_wkup components there > eventuallly without having to redo the ranges again for wkup_m3. > > You can also look at how the scm_conf was done for dm816x.dtsi for an > example, and the recent large set of patches posted by Tero. > Tony, Thanks, I will take a look at this. I initially tried adding to ocp node directly, but obviously it had issues. But in general, you are ok with the ranges approach right, rather than having to define another property with virtual addresses. These devices are not on a separate bus like PCI, so I placed them in the soc node, and expect only special devices like processors to kinda go under that node. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-05 16:46 ` Suman Anna @ 2015-03-05 16:57 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-05 16:57 UTC (permalink / raw) To: Suman Anna Cc: Dave Gerlach, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi * Suman Anna <s-anna@ti.com> [150305 08:47]: > On 03/05/2015 09:40 AM, Tony Lindgren wrote: > > * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > Dave, > > Looks like the commit message disappeared during your patch preparation. > > >> Signed-off-by: Suman Anna <s-anna@ti.com> > >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > >> --- > >> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > >> 1 file changed, 13 insertions(+), 8 deletions(-) > >> > >> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > >> index acd3705..086415c 100644 > >> --- a/arch/arm/boot/dts/am33xx.dtsi > >> +++ b/arch/arm/boot/dts/am33xx.dtsi > >> @@ -77,10 +77,23 @@ > >> */ > >> soc { > >> compatible = "ti,omap-infra"; > >> + #address-cells = <1>; > >> + #size-cells = <1>; > >> + ranges = <0x0 0x44d00000 0x4000>, > >> + <0x80000 0x44d80000 0x2000>; > >> + > > > > I think putting the ranges here will cause issues for adding > > ranges for anything else. > > > > How about do something like this instead (untested): > > > > ocp { > > l4_wkup: l4_wkup@44c00000 { > > compatible = "am335-l4-wkup", "simple-bus"; > > ranges = <0 0x44c00000 0x3fffff>; > > > > wkup_m3: wkup_m3@44d00000 { > > compatible = "ti,am3353-wkup-m3"; > > reg = <0x1000000 0x4000>, /* M3 UMEM */ > > <0x180000 0x2000>; /* M3 DMEM */ > > ti,hwmods = "wkup_m3"; > > ti,pm-firmware = "am335x-pm-firmware.elf"; > > }; > > > > ... > > }; > > }; > > > > That way we can start moving also the other l4_wkup components there > > eventuallly without having to redo the ranges again for wkup_m3. > > > > You can also look at how the scm_conf was done for dm816x.dtsi for an > > example, and the recent large set of patches posted by Tero. > > > Tony, > > Thanks, I will take a look at this. I initially tried adding to ocp node > directly, but obviously it had issues. > > But in general, you are ok with the ranges approach right, rather than > having to define another property with virtual addresses. These devices > are not on a separate bus like PCI, so I placed them in the soc node, > and expect only special devices like processors to kinda go under that node. Yes ranges + simple-bus will allow using standard Linux modules no matter where the components move. And then getting the IO resources will behave properly for the drivers without any extra code to deal with the children. Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-05 16:57 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-05 16:57 UTC (permalink / raw) To: linux-arm-kernel * Suman Anna <s-anna@ti.com> [150305 08:47]: > On 03/05/2015 09:40 AM, Tony Lindgren wrote: > > * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > Dave, > > Looks like the commit message disappeared during your patch preparation. > > >> Signed-off-by: Suman Anna <s-anna@ti.com> > >> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > >> --- > >> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > >> 1 file changed, 13 insertions(+), 8 deletions(-) > >> > >> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > >> index acd3705..086415c 100644 > >> --- a/arch/arm/boot/dts/am33xx.dtsi > >> +++ b/arch/arm/boot/dts/am33xx.dtsi > >> @@ -77,10 +77,23 @@ > >> */ > >> soc { > >> compatible = "ti,omap-infra"; > >> + #address-cells = <1>; > >> + #size-cells = <1>; > >> + ranges = <0x0 0x44d00000 0x4000>, > >> + <0x80000 0x44d80000 0x2000>; > >> + > > > > I think putting the ranges here will cause issues for adding > > ranges for anything else. > > > > How about do something like this instead (untested): > > > > ocp { > > l4_wkup: l4_wkup at 44c00000 { > > compatible = "am335-l4-wkup", "simple-bus"; > > ranges = <0 0x44c00000 0x3fffff>; > > > > wkup_m3: wkup_m3 at 44d00000 { > > compatible = "ti,am3353-wkup-m3"; > > reg = <0x1000000 0x4000>, /* M3 UMEM */ > > <0x180000 0x2000>; /* M3 DMEM */ > > ti,hwmods = "wkup_m3"; > > ti,pm-firmware = "am335x-pm-firmware.elf"; > > }; > > > > ... > > }; > > }; > > > > That way we can start moving also the other l4_wkup components there > > eventuallly without having to redo the ranges again for wkup_m3. > > > > You can also look at how the scm_conf was done for dm816x.dtsi for an > > example, and the recent large set of patches posted by Tero. > > > Tony, > > Thanks, I will take a look at this. I initially tried adding to ocp node > directly, but obviously it had issues. > > But in general, you are ok with the ranges approach right, rather than > having to define another property with virtual addresses. These devices > are not on a separate bus like PCI, so I placed them in the soc node, > and expect only special devices like processors to kinda go under that node. Yes ranges + simple-bus will allow using standard Linux modules no matter where the components move. And then getting the IO resources will behave properly for the drivers without any extra code to deal with the children. Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-05 16:57 ` Tony Lindgren (?) @ 2015-03-09 23:59 ` Suman Anna -1 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-09 23:59 UTC (permalink / raw) To: Tony Lindgren Cc: Dave Gerlach, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi Tony, On 03/05/2015 10:57 AM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150305 08:47]: >> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >> Dave, >> >> Looks like the commit message disappeared during your patch preparation. >> >>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>> --- >>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>> index acd3705..086415c 100644 >>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>> @@ -77,10 +77,23 @@ >>>> */ >>>> soc { >>>> compatible = "ti,omap-infra"; >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + ranges = <0x0 0x44d00000 0x4000>, >>>> + <0x80000 0x44d80000 0x2000>; >>>> + >>> >>> I think putting the ranges here will cause issues for adding >>> ranges for anything else. >>> >>> How about do something like this instead (untested): >>> >>> ocp { >>> l4_wkup: l4_wkup@44c00000 { >>> compatible = "am335-l4-wkup", "simple-bus"; >>> ranges = <0 0x44c00000 0x3fffff>; >>> >>> wkup_m3: wkup_m3@44d00000 { >>> compatible = "ti,am3353-wkup-m3"; >>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>> <0x180000 0x2000>; /* M3 DMEM */ >>> ti,hwmods = "wkup_m3"; >>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>> }; >>> >>> ... >>> }; >>> }; >>> >>> That way we can start moving also the other l4_wkup components there >>> eventuallly without having to redo the ranges again for wkup_m3. >>> >>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>> example, and the recent large set of patches posted by Tero. I have taken a look at both the above. The L4_WKUP range includes the PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 etc. What all do we want to move here eventually? Depending on that, we may have to use 2 address cells like in Tero's PRCM cleanup series rather than the single cell translation used by you in dm816x.dtsi so that we can retain the relative addresses w.r.t the existing node bases in the derivative child nodes. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-09 23:59 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-09 23:59 UTC (permalink / raw) To: linux-arm-kernel Tony, On 03/05/2015 10:57 AM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150305 08:47]: >> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >> Dave, >> >> Looks like the commit message disappeared during your patch preparation. >> >>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>> --- >>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>> index acd3705..086415c 100644 >>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>> @@ -77,10 +77,23 @@ >>>> */ >>>> soc { >>>> compatible = "ti,omap-infra"; >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + ranges = <0x0 0x44d00000 0x4000>, >>>> + <0x80000 0x44d80000 0x2000>; >>>> + >>> >>> I think putting the ranges here will cause issues for adding >>> ranges for anything else. >>> >>> How about do something like this instead (untested): >>> >>> ocp { >>> l4_wkup: l4_wkup at 44c00000 { >>> compatible = "am335-l4-wkup", "simple-bus"; >>> ranges = <0 0x44c00000 0x3fffff>; >>> >>> wkup_m3: wkup_m3 at 44d00000 { >>> compatible = "ti,am3353-wkup-m3"; >>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>> <0x180000 0x2000>; /* M3 DMEM */ >>> ti,hwmods = "wkup_m3"; >>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>> }; >>> >>> ... >>> }; >>> }; >>> >>> That way we can start moving also the other l4_wkup components there >>> eventuallly without having to redo the ranges again for wkup_m3. >>> >>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>> example, and the recent large set of patches posted by Tero. I have taken a look at both the above. The L4_WKUP range includes the PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 etc. What all do we want to move here eventually? Depending on that, we may have to use 2 address cells like in Tero's PRCM cleanup series rather than the single cell translation used by you in dm816x.dtsi so that we can retain the relative addresses w.r.t the existing node bases in the derivative child nodes. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-09 23:59 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-09 23:59 UTC (permalink / raw) To: Tony Lindgren Cc: Dave Gerlach, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi Tony, On 03/05/2015 10:57 AM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150305 08:47]: >> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >> Dave, >> >> Looks like the commit message disappeared during your patch preparation. >> >>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>> --- >>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>> index acd3705..086415c 100644 >>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>> @@ -77,10 +77,23 @@ >>>> */ >>>> soc { >>>> compatible = "ti,omap-infra"; >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + ranges = <0x0 0x44d00000 0x4000>, >>>> + <0x80000 0x44d80000 0x2000>; >>>> + >>> >>> I think putting the ranges here will cause issues for adding >>> ranges for anything else. >>> >>> How about do something like this instead (untested): >>> >>> ocp { >>> l4_wkup: l4_wkup@44c00000 { >>> compatible = "am335-l4-wkup", "simple-bus"; >>> ranges = <0 0x44c00000 0x3fffff>; >>> >>> wkup_m3: wkup_m3@44d00000 { >>> compatible = "ti,am3353-wkup-m3"; >>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>> <0x180000 0x2000>; /* M3 DMEM */ >>> ti,hwmods = "wkup_m3"; >>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>> }; >>> >>> ... >>> }; >>> }; >>> >>> That way we can start moving also the other l4_wkup components there >>> eventuallly without having to redo the ranges again for wkup_m3. >>> >>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>> example, and the recent large set of patches posted by Tero. I have taken a look at both the above. The L4_WKUP range includes the PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 etc. What all do we want to move here eventually? Depending on that, we may have to use 2 address cells like in Tero's PRCM cleanup series rather than the single cell translation used by you in dm816x.dtsi so that we can retain the relative addresses w.r.t the existing node bases in the derivative child nodes. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-09 23:59 ` Suman Anna @ 2015-03-10 16:09 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-10 16:09 UTC (permalink / raw) To: Suman Anna Cc: Dave Gerlach, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi * Suman Anna <s-anna@ti.com> [150309 16:59]: > On 03/05/2015 10:57 AM, Tony Lindgren wrote: > > * Suman Anna <s-anna@ti.com> [150305 08:47]: > >> On 03/05/2015 09:40 AM, Tony Lindgren wrote: > >>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > >> Dave, > >> > >> Looks like the commit message disappeared during your patch preparation. > >> > >>>> Signed-off-by: Suman Anna <s-anna@ti.com> > >>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > >>>> --- > >>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > >>>> 1 file changed, 13 insertions(+), 8 deletions(-) > >>>> > >>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > >>>> index acd3705..086415c 100644 > >>>> --- a/arch/arm/boot/dts/am33xx.dtsi > >>>> +++ b/arch/arm/boot/dts/am33xx.dtsi > >>>> @@ -77,10 +77,23 @@ > >>>> */ > >>>> soc { > >>>> compatible = "ti,omap-infra"; > >>>> + #address-cells = <1>; > >>>> + #size-cells = <1>; > >>>> + ranges = <0x0 0x44d00000 0x4000>, > >>>> + <0x80000 0x44d80000 0x2000>; > >>>> + > >>> > >>> I think putting the ranges here will cause issues for adding > >>> ranges for anything else. > >>> > >>> How about do something like this instead (untested): > >>> > >>> ocp { > >>> l4_wkup: l4_wkup@44c00000 { > >>> compatible = "am335-l4-wkup", "simple-bus"; > >>> ranges = <0 0x44c00000 0x3fffff>; > >>> > >>> wkup_m3: wkup_m3@44d00000 { > >>> compatible = "ti,am3353-wkup-m3"; > >>> reg = <0x1000000 0x4000>, /* M3 UMEM */ > >>> <0x180000 0x2000>; /* M3 DMEM */ > >>> ti,hwmods = "wkup_m3"; > >>> ti,pm-firmware = "am335x-pm-firmware.elf"; > >>> }; > >>> > >>> ... > >>> }; > >>> }; > >>> > >>> That way we can start moving also the other l4_wkup components there > >>> eventuallly without having to redo the ranges again for wkup_m3. > >>> > >>> You can also look at how the scm_conf was done for dm816x.dtsi for an > >>> example, and the recent large set of patches posted by Tero. > > I have taken a look at both the above. The L4_WKUP range includes the > PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 > etc. What all do we want to move here eventually? Well eventually all the children of L4_WKUP, but that can be done slowly as some of the drivers have weird hacks and may not work properly if moved around. For example, anything with reg entries for something like SCM area will break as that's not going to be in the L4_WKUP area ny longer :p And that's actually good as it will protect us from spaghetti code automatically later on for new code. > Depending on that, we may have to use 2 address cells like in Tero's > PRCM cleanup series rather than the single cell translation used by > you in dm816x.dtsi so that we can retain the relative addresses > w.r.t the existing node bases in the derivative child nodes. Hmm OK, care to paste a dts snippet example for that? Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-10 16:09 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-10 16:09 UTC (permalink / raw) To: linux-arm-kernel * Suman Anna <s-anna@ti.com> [150309 16:59]: > On 03/05/2015 10:57 AM, Tony Lindgren wrote: > > * Suman Anna <s-anna@ti.com> [150305 08:47]: > >> On 03/05/2015 09:40 AM, Tony Lindgren wrote: > >>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > >> Dave, > >> > >> Looks like the commit message disappeared during your patch preparation. > >> > >>>> Signed-off-by: Suman Anna <s-anna@ti.com> > >>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > >>>> --- > >>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > >>>> 1 file changed, 13 insertions(+), 8 deletions(-) > >>>> > >>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > >>>> index acd3705..086415c 100644 > >>>> --- a/arch/arm/boot/dts/am33xx.dtsi > >>>> +++ b/arch/arm/boot/dts/am33xx.dtsi > >>>> @@ -77,10 +77,23 @@ > >>>> */ > >>>> soc { > >>>> compatible = "ti,omap-infra"; > >>>> + #address-cells = <1>; > >>>> + #size-cells = <1>; > >>>> + ranges = <0x0 0x44d00000 0x4000>, > >>>> + <0x80000 0x44d80000 0x2000>; > >>>> + > >>> > >>> I think putting the ranges here will cause issues for adding > >>> ranges for anything else. > >>> > >>> How about do something like this instead (untested): > >>> > >>> ocp { > >>> l4_wkup: l4_wkup at 44c00000 { > >>> compatible = "am335-l4-wkup", "simple-bus"; > >>> ranges = <0 0x44c00000 0x3fffff>; > >>> > >>> wkup_m3: wkup_m3 at 44d00000 { > >>> compatible = "ti,am3353-wkup-m3"; > >>> reg = <0x1000000 0x4000>, /* M3 UMEM */ > >>> <0x180000 0x2000>; /* M3 DMEM */ > >>> ti,hwmods = "wkup_m3"; > >>> ti,pm-firmware = "am335x-pm-firmware.elf"; > >>> }; > >>> > >>> ... > >>> }; > >>> }; > >>> > >>> That way we can start moving also the other l4_wkup components there > >>> eventuallly without having to redo the ranges again for wkup_m3. > >>> > >>> You can also look at how the scm_conf was done for dm816x.dtsi for an > >>> example, and the recent large set of patches posted by Tero. > > I have taken a look at both the above. The L4_WKUP range includes the > PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 > etc. What all do we want to move here eventually? Well eventually all the children of L4_WKUP, but that can be done slowly as some of the drivers have weird hacks and may not work properly if moved around. For example, anything with reg entries for something like SCM area will break as that's not going to be in the L4_WKUP area ny longer :p And that's actually good as it will protect us from spaghetti code automatically later on for new code. > Depending on that, we may have to use 2 address cells like in Tero's > PRCM cleanup series rather than the single cell translation used by > you in dm816x.dtsi so that we can retain the relative addresses > w.r.t the existing node bases in the derivative child nodes. Hmm OK, care to paste a dts snippet example for that? Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-10 16:09 ` Tony Lindgren (?) @ 2015-03-10 19:55 ` Dave Gerlach -1 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-10 19:55 UTC (permalink / raw) To: Tony Lindgren, Suman Anna Cc: linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi Tony, On 03/10/2015 11:09 AM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150309 16:59]: >> On 03/05/2015 10:57 AM, Tony Lindgren wrote: >>> * Suman Anna <s-anna@ti.com> [150305 08:47]: >>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >>>> Dave, >>>> >>>> Looks like the commit message disappeared during your patch preparation. >>>> >>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>> --- >>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>>>> index acd3705..086415c 100644 >>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>>>> @@ -77,10 +77,23 @@ >>>>>> */ >>>>>> soc { >>>>>> compatible = "ti,omap-infra"; >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <1>; >>>>>> + ranges = <0x0 0x44d00000 0x4000>, >>>>>> + <0x80000 0x44d80000 0x2000>; >>>>>> + >>>>> >>>>> I think putting the ranges here will cause issues for adding >>>>> ranges for anything else. >>>>> >>>>> How about do something like this instead (untested): >>>>> >>>>> ocp { >>>>> l4_wkup: l4_wkup@44c00000 { >>>>> compatible = "am335-l4-wkup", "simple-bus"; >>>>> ranges = <0 0x44c00000 0x3fffff>; >>>>> >>>>> wkup_m3: wkup_m3@44d00000 { >>>>> compatible = "ti,am3353-wkup-m3"; >>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>>>> <0x180000 0x2000>; /* M3 DMEM */ >>>>> ti,hwmods = "wkup_m3"; >>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>>>> }; >>>>> >>>>> ... >>>>> }; >>>>> }; >>>>> >>>>> That way we can start moving also the other l4_wkup components there >>>>> eventuallly without having to redo the ranges again for wkup_m3. >>>>> >>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>>>> example, and the recent large set of patches posted by Tero. >> >> I have taken a look at both the above. The L4_WKUP range includes the >> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 >> etc. What all do we want to move here eventually? > > Well eventually all the children of L4_WKUP, but that can be done > slowly as some of the drivers have weird hacks and may not work > properly if moved around. > > For example, anything with reg entries for something like SCM area will > break as that's not going to be in the L4_WKUP area ny longer :p And > that's actually good as it will protect us from spaghetti code > automatically later on for new code. > >> Depending on that, we may have to use 2 address cells like in Tero's >> PRCM cleanup series rather than the single cell translation used by >> you in dm816x.dtsi so that we can retain the relative addresses >> w.r.t the existing node bases in the derivative child nodes. > > Hmm OK, care to paste a dts snippet example for that? Suman and I have been looking at this together, so I can comment here. An implementation like this is what Suman is referring to: + l4_wkup: l4_wkup@44c00000 { + compatible = "am335-l4-wkup", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x44c00000 0x100000>, + <1 0x0 0x44d00000 0x4000>, + <2 0x80000 0x44d80000 0x2000>; + + wkup_m3: wkup_m3@1,0 { + compatible = "ti,am3353-wkup-m3"; + reg = <1 0x0 0x4000>, /* M3 UMEM */ + <2 0x80000 0x2000>; /* M3 DMEM */ + + ti,hwmods = "wkup_m3"; + ti,pm-firmware = "am335x-pm-firmware.elf"; + }; + }; + The of_* layer automatically translates everything so the pdata-quirks can still match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost entirely as is with this, all cpu addresses are read and mapped correctly but the driver no longer will read the actual device addresses correctly which we need for understanding where to load the firmware sections. These device addresses are being read directly using of_get_address, which reads the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We would need some sort of change there also to get the proper 0x0 and 0x80000 device address values. Just advancing the pointer returned by of_get_address does the trick but this doesn't seem like the cleanest solution. Regards, Dave > > Regards, > > Tony > ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-10 19:55 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-10 19:55 UTC (permalink / raw) To: linux-arm-kernel Tony, On 03/10/2015 11:09 AM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150309 16:59]: >> On 03/05/2015 10:57 AM, Tony Lindgren wrote: >>> * Suman Anna <s-anna@ti.com> [150305 08:47]: >>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >>>> Dave, >>>> >>>> Looks like the commit message disappeared during your patch preparation. >>>> >>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>> --- >>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>>>> index acd3705..086415c 100644 >>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>>>> @@ -77,10 +77,23 @@ >>>>>> */ >>>>>> soc { >>>>>> compatible = "ti,omap-infra"; >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <1>; >>>>>> + ranges = <0x0 0x44d00000 0x4000>, >>>>>> + <0x80000 0x44d80000 0x2000>; >>>>>> + >>>>> >>>>> I think putting the ranges here will cause issues for adding >>>>> ranges for anything else. >>>>> >>>>> How about do something like this instead (untested): >>>>> >>>>> ocp { >>>>> l4_wkup: l4_wkup at 44c00000 { >>>>> compatible = "am335-l4-wkup", "simple-bus"; >>>>> ranges = <0 0x44c00000 0x3fffff>; >>>>> >>>>> wkup_m3: wkup_m3 at 44d00000 { >>>>> compatible = "ti,am3353-wkup-m3"; >>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>>>> <0x180000 0x2000>; /* M3 DMEM */ >>>>> ti,hwmods = "wkup_m3"; >>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>>>> }; >>>>> >>>>> ... >>>>> }; >>>>> }; >>>>> >>>>> That way we can start moving also the other l4_wkup components there >>>>> eventuallly without having to redo the ranges again for wkup_m3. >>>>> >>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>>>> example, and the recent large set of patches posted by Tero. >> >> I have taken a look at both the above. The L4_WKUP range includes the >> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 >> etc. What all do we want to move here eventually? > > Well eventually all the children of L4_WKUP, but that can be done > slowly as some of the drivers have weird hacks and may not work > properly if moved around. > > For example, anything with reg entries for something like SCM area will > break as that's not going to be in the L4_WKUP area ny longer :p And > that's actually good as it will protect us from spaghetti code > automatically later on for new code. > >> Depending on that, we may have to use 2 address cells like in Tero's >> PRCM cleanup series rather than the single cell translation used by >> you in dm816x.dtsi so that we can retain the relative addresses >> w.r.t the existing node bases in the derivative child nodes. > > Hmm OK, care to paste a dts snippet example for that? Suman and I have been looking at this together, so I can comment here. An implementation like this is what Suman is referring to: + l4_wkup: l4_wkup at 44c00000 { + compatible = "am335-l4-wkup", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x44c00000 0x100000>, + <1 0x0 0x44d00000 0x4000>, + <2 0x80000 0x44d80000 0x2000>; + + wkup_m3: wkup_m3 at 1,0 { + compatible = "ti,am3353-wkup-m3"; + reg = <1 0x0 0x4000>, /* M3 UMEM */ + <2 0x80000 0x2000>; /* M3 DMEM */ + + ti,hwmods = "wkup_m3"; + ti,pm-firmware = "am335x-pm-firmware.elf"; + }; + }; + The of_* layer automatically translates everything so the pdata-quirks can still match based on wkup_m3 at 44d00000. The existing wkup_m3_rproc driver works almost entirely as is with this, all cpu addresses are read and mapped correctly but the driver no longer will read the actual device addresses correctly which we need for understanding where to load the firmware sections. These device addresses are being read directly using of_get_address, which reads the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We would need some sort of change there also to get the proper 0x0 and 0x80000 device address values. Just advancing the pointer returned by of_get_address does the trick but this doesn't seem like the cleanest solution. Regards, Dave > > Regards, > > Tony > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-10 19:55 ` Dave Gerlach 0 siblings, 0 replies; 34+ messages in thread From: Dave Gerlach @ 2015-03-10 19:55 UTC (permalink / raw) To: Tony Lindgren, Suman Anna Cc: linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi Tony, On 03/10/2015 11:09 AM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150309 16:59]: >> On 03/05/2015 10:57 AM, Tony Lindgren wrote: >>> * Suman Anna <s-anna@ti.com> [150305 08:47]: >>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >>>> Dave, >>>> >>>> Looks like the commit message disappeared during your patch preparation. >>>> >>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>> --- >>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>>>> index acd3705..086415c 100644 >>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>>>> @@ -77,10 +77,23 @@ >>>>>> */ >>>>>> soc { >>>>>> compatible = "ti,omap-infra"; >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <1>; >>>>>> + ranges = <0x0 0x44d00000 0x4000>, >>>>>> + <0x80000 0x44d80000 0x2000>; >>>>>> + >>>>> >>>>> I think putting the ranges here will cause issues for adding >>>>> ranges for anything else. >>>>> >>>>> How about do something like this instead (untested): >>>>> >>>>> ocp { >>>>> l4_wkup: l4_wkup@44c00000 { >>>>> compatible = "am335-l4-wkup", "simple-bus"; >>>>> ranges = <0 0x44c00000 0x3fffff>; >>>>> >>>>> wkup_m3: wkup_m3@44d00000 { >>>>> compatible = "ti,am3353-wkup-m3"; >>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>>>> <0x180000 0x2000>; /* M3 DMEM */ >>>>> ti,hwmods = "wkup_m3"; >>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>>>> }; >>>>> >>>>> ... >>>>> }; >>>>> }; >>>>> >>>>> That way we can start moving also the other l4_wkup components there >>>>> eventuallly without having to redo the ranges again for wkup_m3. >>>>> >>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>>>> example, and the recent large set of patches posted by Tero. >> >> I have taken a look at both the above. The L4_WKUP range includes the >> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 >> etc. What all do we want to move here eventually? > > Well eventually all the children of L4_WKUP, but that can be done > slowly as some of the drivers have weird hacks and may not work > properly if moved around. > > For example, anything with reg entries for something like SCM area will > break as that's not going to be in the L4_WKUP area ny longer :p And > that's actually good as it will protect us from spaghetti code > automatically later on for new code. > >> Depending on that, we may have to use 2 address cells like in Tero's >> PRCM cleanup series rather than the single cell translation used by >> you in dm816x.dtsi so that we can retain the relative addresses >> w.r.t the existing node bases in the derivative child nodes. > > Hmm OK, care to paste a dts snippet example for that? Suman and I have been looking at this together, so I can comment here. An implementation like this is what Suman is referring to: + l4_wkup: l4_wkup@44c00000 { + compatible = "am335-l4-wkup", "simple-bus"; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x44c00000 0x100000>, + <1 0x0 0x44d00000 0x4000>, + <2 0x80000 0x44d80000 0x2000>; + + wkup_m3: wkup_m3@1,0 { + compatible = "ti,am3353-wkup-m3"; + reg = <1 0x0 0x4000>, /* M3 UMEM */ + <2 0x80000 0x2000>; /* M3 DMEM */ + + ti,hwmods = "wkup_m3"; + ti,pm-firmware = "am335x-pm-firmware.elf"; + }; + }; + The of_* layer automatically translates everything so the pdata-quirks can still match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost entirely as is with this, all cpu addresses are read and mapped correctly but the driver no longer will read the actual device addresses correctly which we need for understanding where to load the firmware sections. These device addresses are being read directly using of_get_address, which reads the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We would need some sort of change there also to get the proper 0x0 and 0x80000 device address values. Just advancing the pointer returned by of_get_address does the trick but this doesn't seem like the cleanest solution. Regards, Dave > > Regards, > > Tony > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-10 19:55 ` Dave Gerlach @ 2015-03-11 16:26 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-11 16:26 UTC (permalink / raw) To: Dave Gerlach Cc: Suman Anna, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: > Tony, > On 03/10/2015 11:09 AM, Tony Lindgren wrote: > > * Suman Anna <s-anna@ti.com> [150309 16:59]: > >> On 03/05/2015 10:57 AM, Tony Lindgren wrote: > >>> * Suman Anna <s-anna@ti.com> [150305 08:47]: > >>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: > >>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > >>>> Dave, > >>>> > >>>> Looks like the commit message disappeared during your patch preparation. > >>>> > >>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> > >>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > >>>>>> --- > >>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > >>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) > >>>>>> > >>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > >>>>>> index acd3705..086415c 100644 > >>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi > >>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi > >>>>>> @@ -77,10 +77,23 @@ > >>>>>> */ > >>>>>> soc { > >>>>>> compatible = "ti,omap-infra"; > >>>>>> + #address-cells = <1>; > >>>>>> + #size-cells = <1>; > >>>>>> + ranges = <0x0 0x44d00000 0x4000>, > >>>>>> + <0x80000 0x44d80000 0x2000>; > >>>>>> + > >>>>> > >>>>> I think putting the ranges here will cause issues for adding > >>>>> ranges for anything else. > >>>>> > >>>>> How about do something like this instead (untested): > >>>>> > >>>>> ocp { > >>>>> l4_wkup: l4_wkup@44c00000 { > >>>>> compatible = "am335-l4-wkup", "simple-bus"; > >>>>> ranges = <0 0x44c00000 0x3fffff>; > >>>>> > >>>>> wkup_m3: wkup_m3@44d00000 { > >>>>> compatible = "ti,am3353-wkup-m3"; > >>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ > >>>>> <0x180000 0x2000>; /* M3 DMEM */ > >>>>> ti,hwmods = "wkup_m3"; > >>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; > >>>>> }; > >>>>> > >>>>> ... > >>>>> }; > >>>>> }; > >>>>> > >>>>> That way we can start moving also the other l4_wkup components there > >>>>> eventuallly without having to redo the ranges again for wkup_m3. > >>>>> > >>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an > >>>>> example, and the recent large set of patches posted by Tero. > >> > >> I have taken a look at both the above. The L4_WKUP range includes the > >> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 > >> etc. What all do we want to move here eventually? > > > > Well eventually all the children of L4_WKUP, but that can be done > > slowly as some of the drivers have weird hacks and may not work > > properly if moved around. > > > > For example, anything with reg entries for something like SCM area will > > break as that's not going to be in the L4_WKUP area ny longer :p And > > that's actually good as it will protect us from spaghetti code > > automatically later on for new code. > > > >> Depending on that, we may have to use 2 address cells like in Tero's > >> PRCM cleanup series rather than the single cell translation used by > >> you in dm816x.dtsi so that we can retain the relative addresses > >> w.r.t the existing node bases in the derivative child nodes. > > > > Hmm OK, care to paste a dts snippet example for that? > > Suman and I have been looking at this together, so I can comment here. An > implementation like this is what Suman is referring to: > > + l4_wkup: l4_wkup@44c00000 { > + compatible = "am335-l4-wkup", "simple-bus"; > + #address-cells = <2>; > + #size-cells = <1>; > + ranges = <0 0 0x44c00000 0x100000>, > + <1 0x0 0x44d00000 0x4000>, > + <2 0x80000 0x44d80000 0x2000>; > + > + wkup_m3: wkup_m3@1,0 { > + compatible = "ti,am3353-wkup-m3"; > + reg = <1 0x0 0x4000>, /* M3 UMEM */ > + <2 0x80000 0x2000>; /* M3 DMEM */ > + > + ti,hwmods = "wkup_m3"; > + ti,pm-firmware = "am335x-pm-firmware.elf"; > + }; > + }; > + > > The of_* layer automatically translates everything so the pdata-quirks can still > match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost > entirely as is with this, all cpu addresses are read and mapped correctly but > the driver no longer will read the actual device addresses correctly which we > need for understanding where to load the firmware sections. OK. I still don't quite understand how these additional ranges make sense for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if it allows you to translate directly to the m3 address space, but is that really the case here? Maybe you should have the ranges in wkup_m3 instead if you want addresses for the m3? > These device addresses are being read directly using of_get_address, which reads > the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We > would need some sort of change there also to get the proper 0x0 and 0x80000 > device address values. Just advancing the pointer returned by of_get_address > does the trick but this doesn't seem like the cleanest solution. I'd assume we have similar uses of range already.. Maybe look at some pcie examples and how they use ranges for the bus address translation? Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-11 16:26 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-11 16:26 UTC (permalink / raw) To: linux-arm-kernel * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: > Tony, > On 03/10/2015 11:09 AM, Tony Lindgren wrote: > > * Suman Anna <s-anna@ti.com> [150309 16:59]: > >> On 03/05/2015 10:57 AM, Tony Lindgren wrote: > >>> * Suman Anna <s-anna@ti.com> [150305 08:47]: > >>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: > >>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: > >>>> Dave, > >>>> > >>>> Looks like the commit message disappeared during your patch preparation. > >>>> > >>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> > >>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > >>>>>> --- > >>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- > >>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) > >>>>>> > >>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > >>>>>> index acd3705..086415c 100644 > >>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi > >>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi > >>>>>> @@ -77,10 +77,23 @@ > >>>>>> */ > >>>>>> soc { > >>>>>> compatible = "ti,omap-infra"; > >>>>>> + #address-cells = <1>; > >>>>>> + #size-cells = <1>; > >>>>>> + ranges = <0x0 0x44d00000 0x4000>, > >>>>>> + <0x80000 0x44d80000 0x2000>; > >>>>>> + > >>>>> > >>>>> I think putting the ranges here will cause issues for adding > >>>>> ranges for anything else. > >>>>> > >>>>> How about do something like this instead (untested): > >>>>> > >>>>> ocp { > >>>>> l4_wkup: l4_wkup at 44c00000 { > >>>>> compatible = "am335-l4-wkup", "simple-bus"; > >>>>> ranges = <0 0x44c00000 0x3fffff>; > >>>>> > >>>>> wkup_m3: wkup_m3 at 44d00000 { > >>>>> compatible = "ti,am3353-wkup-m3"; > >>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ > >>>>> <0x180000 0x2000>; /* M3 DMEM */ > >>>>> ti,hwmods = "wkup_m3"; > >>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; > >>>>> }; > >>>>> > >>>>> ... > >>>>> }; > >>>>> }; > >>>>> > >>>>> That way we can start moving also the other l4_wkup components there > >>>>> eventuallly without having to redo the ranges again for wkup_m3. > >>>>> > >>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an > >>>>> example, and the recent large set of patches posted by Tero. > >> > >> I have taken a look at both the above. The L4_WKUP range includes the > >> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 > >> etc. What all do we want to move here eventually? > > > > Well eventually all the children of L4_WKUP, but that can be done > > slowly as some of the drivers have weird hacks and may not work > > properly if moved around. > > > > For example, anything with reg entries for something like SCM area will > > break as that's not going to be in the L4_WKUP area ny longer :p And > > that's actually good as it will protect us from spaghetti code > > automatically later on for new code. > > > >> Depending on that, we may have to use 2 address cells like in Tero's > >> PRCM cleanup series rather than the single cell translation used by > >> you in dm816x.dtsi so that we can retain the relative addresses > >> w.r.t the existing node bases in the derivative child nodes. > > > > Hmm OK, care to paste a dts snippet example for that? > > Suman and I have been looking at this together, so I can comment here. An > implementation like this is what Suman is referring to: > > + l4_wkup: l4_wkup at 44c00000 { > + compatible = "am335-l4-wkup", "simple-bus"; > + #address-cells = <2>; > + #size-cells = <1>; > + ranges = <0 0 0x44c00000 0x100000>, > + <1 0x0 0x44d00000 0x4000>, > + <2 0x80000 0x44d80000 0x2000>; > + > + wkup_m3: wkup_m3 at 1,0 { > + compatible = "ti,am3353-wkup-m3"; > + reg = <1 0x0 0x4000>, /* M3 UMEM */ > + <2 0x80000 0x2000>; /* M3 DMEM */ > + > + ti,hwmods = "wkup_m3"; > + ti,pm-firmware = "am335x-pm-firmware.elf"; > + }; > + }; > + > > The of_* layer automatically translates everything so the pdata-quirks can still > match based on wkup_m3 at 44d00000. The existing wkup_m3_rproc driver works almost > entirely as is with this, all cpu addresses are read and mapped correctly but > the driver no longer will read the actual device addresses correctly which we > need for understanding where to load the firmware sections. OK. I still don't quite understand how these additional ranges make sense for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if it allows you to translate directly to the m3 address space, but is that really the case here? Maybe you should have the ranges in wkup_m3 instead if you want addresses for the m3? > These device addresses are being read directly using of_get_address, which reads > the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We > would need some sort of change there also to get the proper 0x0 and 0x80000 > device address values. Just advancing the pointer returned by of_get_address > does the trick but this doesn't seem like the cleanest solution. I'd assume we have similar uses of range already.. Maybe look at some pcie examples and how they use ranges for the bus address translation? Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-11 16:26 ` Tony Lindgren (?) @ 2015-03-11 17:18 ` Suman Anna -1 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-11 17:18 UTC (permalink / raw) To: Tony Lindgren, Dave Gerlach Cc: linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi Hi Tony, On 03/11/2015 11:26 AM, Tony Lindgren wrote: > * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: >> Tony, >> On 03/10/2015 11:09 AM, Tony Lindgren wrote: >>> * Suman Anna <s-anna@ti.com> [150309 16:59]: >>>> On 03/05/2015 10:57 AM, Tony Lindgren wrote: >>>>> * Suman Anna <s-anna@ti.com> [150305 08:47]: >>>>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>>>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >>>>>> Dave, >>>>>> >>>>>> Looks like the commit message disappeared during your patch preparation. >>>>>> >>>>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>>>> --- >>>>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>>>>>> >>>>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> index acd3705..086415c 100644 >>>>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> @@ -77,10 +77,23 @@ >>>>>>>> */ >>>>>>>> soc { >>>>>>>> compatible = "ti,omap-infra"; >>>>>>>> + #address-cells = <1>; >>>>>>>> + #size-cells = <1>; >>>>>>>> + ranges = <0x0 0x44d00000 0x4000>, >>>>>>>> + <0x80000 0x44d80000 0x2000>; >>>>>>>> + >>>>>>> >>>>>>> I think putting the ranges here will cause issues for adding >>>>>>> ranges for anything else. >>>>>>> >>>>>>> How about do something like this instead (untested): >>>>>>> >>>>>>> ocp { >>>>>>> l4_wkup: l4_wkup@44c00000 { >>>>>>> compatible = "am335-l4-wkup", "simple-bus"; >>>>>>> ranges = <0 0x44c00000 0x3fffff>; >>>>>>> >>>>>>> wkup_m3: wkup_m3@44d00000 { >>>>>>> compatible = "ti,am3353-wkup-m3"; >>>>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>>>>>> <0x180000 0x2000>; /* M3 DMEM */ >>>>>>> ti,hwmods = "wkup_m3"; >>>>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> That way we can start moving also the other l4_wkup components there >>>>>>> eventuallly without having to redo the ranges again for wkup_m3. >>>>>>> >>>>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>>>>>> example, and the recent large set of patches posted by Tero. >>>> >>>> I have taken a look at both the above. The L4_WKUP range includes the >>>> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 >>>> etc. What all do we want to move here eventually? >>> >>> Well eventually all the children of L4_WKUP, but that can be done >>> slowly as some of the drivers have weird hacks and may not work >>> properly if moved around. >>> >>> For example, anything with reg entries for something like SCM area will >>> break as that's not going to be in the L4_WKUP area ny longer :p And >>> that's actually good as it will protect us from spaghetti code >>> automatically later on for new code. >>> >>>> Depending on that, we may have to use 2 address cells like in Tero's >>>> PRCM cleanup series rather than the single cell translation used by >>>> you in dm816x.dtsi so that we can retain the relative addresses >>>> w.r.t the existing node bases in the derivative child nodes. >>> >>> Hmm OK, care to paste a dts snippet example for that? >> >> Suman and I have been looking at this together, so I can comment here. An >> implementation like this is what Suman is referring to: >> >> + l4_wkup: l4_wkup@44c00000 { >> + compatible = "am335-l4-wkup", "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + ranges = <0 0 0x44c00000 0x100000>, >> + <1 0x0 0x44d00000 0x4000>, >> + <2 0x80000 0x44d80000 0x2000>; Actually, this would be slightly different, something like + ranges = <0 0 0x44c00000 0x100000>, + <1 0 0x44d00000 0x100000>, + <2 0 0x44e00000 0x4000>, + <3 0 0x44e10000 0x2000>; and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. >> + >> + wkup_m3: wkup_m3@1,0 { >> + compatible = "ti,am3353-wkup-m3"; >> + reg = <1 0x0 0x4000>, /* M3 UMEM */ >> + <2 0x80000 0x2000>; /* M3 DMEM */ >> + >> + ti,hwmods = "wkup_m3"; >> + ti,pm-firmware = "am335x-pm-firmware.elf"; >> + }; >> + }; >> + >> >> The of_* layer automatically translates everything so the pdata-quirks can still >> match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost >> entirely as is with this, all cpu addresses are read and mapped correctly but >> the driver no longer will read the actual device addresses correctly which we >> need for understanding where to load the firmware sections. > > OK. I still don't quite understand how these additional ranges make sense > for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if > it allows you to translate directly to the m3 address space, but is that > really the case here? Maybe you should have the ranges in wkup_m3 instead > if you want addresses for the m3? The idea is to introduce an additional address element (first cell in ranges) so that the immediate child nodes bus address is referenced as 0 (second cell) for translation for their child nodes. This is the approach used by the current scm node in Tero's series for OMAP4+. This will work tomorrow if we move the prcm, scrm node under l4_wkup with changes only in those nodes, and have their child nodes reg properties unchanged. I guess you can see the difference between the following two patches from Tero's PRCM series, https://patchwork.kernel.org/patch/5882831/ & https://patchwork.kernel.org/patch/5882841/ regards Suman > >> These device addresses are being read directly using of_get_address, which reads >> the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We >> would need some sort of change there also to get the proper 0x0 and 0x80000 >> device address values. Just advancing the pointer returned by of_get_address >> does the trick but this doesn't seem like the cleanest solution. > > I'd assume we have similar uses of range already.. Maybe look at some pcie > examples and how they use ranges for the bus address translation? > > Regards, > > Tony > ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-11 17:18 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-11 17:18 UTC (permalink / raw) To: linux-arm-kernel Hi Tony, On 03/11/2015 11:26 AM, Tony Lindgren wrote: > * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: >> Tony, >> On 03/10/2015 11:09 AM, Tony Lindgren wrote: >>> * Suman Anna <s-anna@ti.com> [150309 16:59]: >>>> On 03/05/2015 10:57 AM, Tony Lindgren wrote: >>>>> * Suman Anna <s-anna@ti.com> [150305 08:47]: >>>>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>>>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >>>>>> Dave, >>>>>> >>>>>> Looks like the commit message disappeared during your patch preparation. >>>>>> >>>>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>>>> --- >>>>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>>>>>> >>>>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> index acd3705..086415c 100644 >>>>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> @@ -77,10 +77,23 @@ >>>>>>>> */ >>>>>>>> soc { >>>>>>>> compatible = "ti,omap-infra"; >>>>>>>> + #address-cells = <1>; >>>>>>>> + #size-cells = <1>; >>>>>>>> + ranges = <0x0 0x44d00000 0x4000>, >>>>>>>> + <0x80000 0x44d80000 0x2000>; >>>>>>>> + >>>>>>> >>>>>>> I think putting the ranges here will cause issues for adding >>>>>>> ranges for anything else. >>>>>>> >>>>>>> How about do something like this instead (untested): >>>>>>> >>>>>>> ocp { >>>>>>> l4_wkup: l4_wkup at 44c00000 { >>>>>>> compatible = "am335-l4-wkup", "simple-bus"; >>>>>>> ranges = <0 0x44c00000 0x3fffff>; >>>>>>> >>>>>>> wkup_m3: wkup_m3 at 44d00000 { >>>>>>> compatible = "ti,am3353-wkup-m3"; >>>>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>>>>>> <0x180000 0x2000>; /* M3 DMEM */ >>>>>>> ti,hwmods = "wkup_m3"; >>>>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> That way we can start moving also the other l4_wkup components there >>>>>>> eventuallly without having to redo the ranges again for wkup_m3. >>>>>>> >>>>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>>>>>> example, and the recent large set of patches posted by Tero. >>>> >>>> I have taken a look at both the above. The L4_WKUP range includes the >>>> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 >>>> etc. What all do we want to move here eventually? >>> >>> Well eventually all the children of L4_WKUP, but that can be done >>> slowly as some of the drivers have weird hacks and may not work >>> properly if moved around. >>> >>> For example, anything with reg entries for something like SCM area will >>> break as that's not going to be in the L4_WKUP area ny longer :p And >>> that's actually good as it will protect us from spaghetti code >>> automatically later on for new code. >>> >>>> Depending on that, we may have to use 2 address cells like in Tero's >>>> PRCM cleanup series rather than the single cell translation used by >>>> you in dm816x.dtsi so that we can retain the relative addresses >>>> w.r.t the existing node bases in the derivative child nodes. >>> >>> Hmm OK, care to paste a dts snippet example for that? >> >> Suman and I have been looking at this together, so I can comment here. An >> implementation like this is what Suman is referring to: >> >> + l4_wkup: l4_wkup at 44c00000 { >> + compatible = "am335-l4-wkup", "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + ranges = <0 0 0x44c00000 0x100000>, >> + <1 0x0 0x44d00000 0x4000>, >> + <2 0x80000 0x44d80000 0x2000>; Actually, this would be slightly different, something like + ranges = <0 0 0x44c00000 0x100000>, + <1 0 0x44d00000 0x100000>, + <2 0 0x44e00000 0x4000>, + <3 0 0x44e10000 0x2000>; and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. >> + >> + wkup_m3: wkup_m3 at 1,0 { >> + compatible = "ti,am3353-wkup-m3"; >> + reg = <1 0x0 0x4000>, /* M3 UMEM */ >> + <2 0x80000 0x2000>; /* M3 DMEM */ >> + >> + ti,hwmods = "wkup_m3"; >> + ti,pm-firmware = "am335x-pm-firmware.elf"; >> + }; >> + }; >> + >> >> The of_* layer automatically translates everything so the pdata-quirks can still >> match based on wkup_m3 at 44d00000. The existing wkup_m3_rproc driver works almost >> entirely as is with this, all cpu addresses are read and mapped correctly but >> the driver no longer will read the actual device addresses correctly which we >> need for understanding where to load the firmware sections. > > OK. I still don't quite understand how these additional ranges make sense > for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if > it allows you to translate directly to the m3 address space, but is that > really the case here? Maybe you should have the ranges in wkup_m3 instead > if you want addresses for the m3? The idea is to introduce an additional address element (first cell in ranges) so that the immediate child nodes bus address is referenced as 0 (second cell) for translation for their child nodes. This is the approach used by the current scm node in Tero's series for OMAP4+. This will work tomorrow if we move the prcm, scrm node under l4_wkup with changes only in those nodes, and have their child nodes reg properties unchanged. I guess you can see the difference between the following two patches from Tero's PRCM series, https://patchwork.kernel.org/patch/5882831/ & https://patchwork.kernel.org/patch/5882841/ regards Suman > >> These device addresses are being read directly using of_get_address, which reads >> the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We >> would need some sort of change there also to get the proper 0x0 and 0x80000 >> device address values. Just advancing the pointer returned by of_get_address >> does the trick but this doesn't seem like the cleanest solution. > > I'd assume we have similar uses of range already.. Maybe look at some pcie > examples and how they use ranges for the bus address translation? > > Regards, > > Tony > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-11 17:18 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-11 17:18 UTC (permalink / raw) To: Tony Lindgren, Dave Gerlach Cc: linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi Hi Tony, On 03/11/2015 11:26 AM, Tony Lindgren wrote: > * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: >> Tony, >> On 03/10/2015 11:09 AM, Tony Lindgren wrote: >>> * Suman Anna <s-anna@ti.com> [150309 16:59]: >>>> On 03/05/2015 10:57 AM, Tony Lindgren wrote: >>>>> * Suman Anna <s-anna@ti.com> [150305 08:47]: >>>>>> On 03/05/2015 09:40 AM, Tony Lindgren wrote: >>>>>>> * Dave Gerlach <d-gerlach@ti.com> [150304 20:14]: >>>>>> Dave, >>>>>> >>>>>> Looks like the commit message disappeared during your patch preparation. >>>>>> >>>>>>>> Signed-off-by: Suman Anna <s-anna@ti.com> >>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> >>>>>>>> --- >>>>>>>> arch/arm/boot/dts/am33xx.dtsi | 21 +++++++++++++-------- >>>>>>>> 1 file changed, 13 insertions(+), 8 deletions(-) >>>>>>>> >>>>>>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> index acd3705..086415c 100644 >>>>>>>> --- a/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> +++ b/arch/arm/boot/dts/am33xx.dtsi >>>>>>>> @@ -77,10 +77,23 @@ >>>>>>>> */ >>>>>>>> soc { >>>>>>>> compatible = "ti,omap-infra"; >>>>>>>> + #address-cells = <1>; >>>>>>>> + #size-cells = <1>; >>>>>>>> + ranges = <0x0 0x44d00000 0x4000>, >>>>>>>> + <0x80000 0x44d80000 0x2000>; >>>>>>>> + >>>>>>> >>>>>>> I think putting the ranges here will cause issues for adding >>>>>>> ranges for anything else. >>>>>>> >>>>>>> How about do something like this instead (untested): >>>>>>> >>>>>>> ocp { >>>>>>> l4_wkup: l4_wkup@44c00000 { >>>>>>> compatible = "am335-l4-wkup", "simple-bus"; >>>>>>> ranges = <0 0x44c00000 0x3fffff>; >>>>>>> >>>>>>> wkup_m3: wkup_m3@44d00000 { >>>>>>> compatible = "ti,am3353-wkup-m3"; >>>>>>> reg = <0x1000000 0x4000>, /* M3 UMEM */ >>>>>>> <0x180000 0x2000>; /* M3 DMEM */ >>>>>>> ti,hwmods = "wkup_m3"; >>>>>>> ti,pm-firmware = "am335x-pm-firmware.elf"; >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> That way we can start moving also the other l4_wkup components there >>>>>>> eventuallly without having to redo the ranges again for wkup_m3. >>>>>>> >>>>>>> You can also look at how the scm_conf was done for dm816x.dtsi for an >>>>>>> example, and the recent large set of patches posted by Tero. >>>> >>>> I have taken a look at both the above. The L4_WKUP range includes the >>>> PRCM, Control Module, as well as a few peripherals like DMTimer0, UART0 >>>> etc. What all do we want to move here eventually? >>> >>> Well eventually all the children of L4_WKUP, but that can be done >>> slowly as some of the drivers have weird hacks and may not work >>> properly if moved around. >>> >>> For example, anything with reg entries for something like SCM area will >>> break as that's not going to be in the L4_WKUP area ny longer :p And >>> that's actually good as it will protect us from spaghetti code >>> automatically later on for new code. >>> >>>> Depending on that, we may have to use 2 address cells like in Tero's >>>> PRCM cleanup series rather than the single cell translation used by >>>> you in dm816x.dtsi so that we can retain the relative addresses >>>> w.r.t the existing node bases in the derivative child nodes. >>> >>> Hmm OK, care to paste a dts snippet example for that? >> >> Suman and I have been looking at this together, so I can comment here. An >> implementation like this is what Suman is referring to: >> >> + l4_wkup: l4_wkup@44c00000 { >> + compatible = "am335-l4-wkup", "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + ranges = <0 0 0x44c00000 0x100000>, >> + <1 0x0 0x44d00000 0x4000>, >> + <2 0x80000 0x44d80000 0x2000>; Actually, this would be slightly different, something like + ranges = <0 0 0x44c00000 0x100000>, + <1 0 0x44d00000 0x100000>, + <2 0 0x44e00000 0x4000>, + <3 0 0x44e10000 0x2000>; and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. >> + >> + wkup_m3: wkup_m3@1,0 { >> + compatible = "ti,am3353-wkup-m3"; >> + reg = <1 0x0 0x4000>, /* M3 UMEM */ >> + <2 0x80000 0x2000>; /* M3 DMEM */ >> + >> + ti,hwmods = "wkup_m3"; >> + ti,pm-firmware = "am335x-pm-firmware.elf"; >> + }; >> + }; >> + >> >> The of_* layer automatically translates everything so the pdata-quirks can still >> match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost >> entirely as is with this, all cpu addresses are read and mapped correctly but >> the driver no longer will read the actual device addresses correctly which we >> need for understanding where to load the firmware sections. > > OK. I still don't quite understand how these additional ranges make sense > for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if > it allows you to translate directly to the m3 address space, but is that > really the case here? Maybe you should have the ranges in wkup_m3 instead > if you want addresses for the m3? The idea is to introduce an additional address element (first cell in ranges) so that the immediate child nodes bus address is referenced as 0 (second cell) for translation for their child nodes. This is the approach used by the current scm node in Tero's series for OMAP4+. This will work tomorrow if we move the prcm, scrm node under l4_wkup with changes only in those nodes, and have their child nodes reg properties unchanged. I guess you can see the difference between the following two patches from Tero's PRCM series, https://patchwork.kernel.org/patch/5882831/ & https://patchwork.kernel.org/patch/5882841/ regards Suman > >> These device addresses are being read directly using of_get_address, which reads >> the first value in the reg entries which is 1 and 2 now for UMEM and DMEM. We >> would need some sort of change there also to get the proper 0x0 and 0x80000 >> device address values. Just advancing the pointer returned by of_get_address >> does the trick but this doesn't seem like the cleanest solution. > > I'd assume we have similar uses of range already.. Maybe look at some pcie > examples and how they use ranges for the bus address translation? > > Regards, > > Tony > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-11 17:18 ` Suman Anna @ 2015-03-11 17:32 ` Tony Lindgren -1 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-11 17:32 UTC (permalink / raw) To: Suman Anna Cc: Dave Gerlach, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi * Suman Anna <s-anna@ti.com> [150311 10:18]: > On 03/11/2015 11:26 AM, Tony Lindgren wrote: > > * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: > >> Suman and I have been looking at this together, so I can comment here. An > >> implementation like this is what Suman is referring to: > >> > >> + l4_wkup: l4_wkup@44c00000 { > >> + compatible = "am335-l4-wkup", "simple-bus"; > >> + #address-cells = <2>; > >> + #size-cells = <1>; > >> + ranges = <0 0 0x44c00000 0x100000>, > >> + <1 0x0 0x44d00000 0x4000>, > >> + <2 0x80000 0x44d80000 0x2000>; > > Actually, this would be slightly different, something like > + ranges = <0 0 0x44c00000 0x100000>, > + <1 0 0x44d00000 0x100000>, > + <2 0 0x44e00000 0x4000>, > + <3 0 0x44e10000 0x2000>; > > and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. > > >> + > >> + wkup_m3: wkup_m3@1,0 { > >> + compatible = "ti,am3353-wkup-m3"; > >> + reg = <1 0x0 0x4000>, /* M3 UMEM */ > >> + <2 0x80000 0x2000>; /* M3 DMEM */ > >> + > >> + ti,hwmods = "wkup_m3"; > >> + ti,pm-firmware = "am335x-pm-firmware.elf"; > >> + }; > >> + }; > >> + > >> > >> The of_* layer automatically translates everything so the pdata-quirks can still > >> match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost > >> entirely as is with this, all cpu addresses are read and mapped correctly but > >> the driver no longer will read the actual device addresses correctly which we > >> need for understanding where to load the firmware sections. > > > > OK. I still don't quite understand how these additional ranges make sense > > for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if > > it allows you to translate directly to the m3 address space, but is that > > really the case here? Maybe you should have the ranges in wkup_m3 instead > > if you want addresses for the m3? > > The idea is to introduce an additional address element (first cell in > ranges) so that the immediate child nodes bus address is referenced as 0 > (second cell) for translation for their child nodes. This is the > approach used by the current scm node in Tero's series for OMAP4+. This > will work tomorrow if we move the prcm, scrm node under l4_wkup with > changes only in those nodes, and have their child nodes reg properties > unchanged. I guess you can see the difference between the following two > patches from Tero's PRCM series, > https://patchwork.kernel.org/patch/5882831/ & > https://patchwork.kernel.org/patch/5882841/ Well I just commented on Tero on that regarding the dra7 patch. I think we need to have separate scm instances for scm_device, scm_core and scm_wkup instead of doing multiple ranges. This based on looking at for example 5432 TRM "Figure 18-1. Control Module Overview". But here I think it's a different issue. You want to use ranges for getting the m3 address space for the firmware? I'm not convinced we should complicate the ranges for all l4_wkup drivers because of that. Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-11 17:32 ` Tony Lindgren 0 siblings, 0 replies; 34+ messages in thread From: Tony Lindgren @ 2015-03-11 17:32 UTC (permalink / raw) To: linux-arm-kernel * Suman Anna <s-anna@ti.com> [150311 10:18]: > On 03/11/2015 11:26 AM, Tony Lindgren wrote: > > * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: > >> Suman and I have been looking at this together, so I can comment here. An > >> implementation like this is what Suman is referring to: > >> > >> + l4_wkup: l4_wkup at 44c00000 { > >> + compatible = "am335-l4-wkup", "simple-bus"; > >> + #address-cells = <2>; > >> + #size-cells = <1>; > >> + ranges = <0 0 0x44c00000 0x100000>, > >> + <1 0x0 0x44d00000 0x4000>, > >> + <2 0x80000 0x44d80000 0x2000>; > > Actually, this would be slightly different, something like > + ranges = <0 0 0x44c00000 0x100000>, > + <1 0 0x44d00000 0x100000>, > + <2 0 0x44e00000 0x4000>, > + <3 0 0x44e10000 0x2000>; > > and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. > > >> + > >> + wkup_m3: wkup_m3 at 1,0 { > >> + compatible = "ti,am3353-wkup-m3"; > >> + reg = <1 0x0 0x4000>, /* M3 UMEM */ > >> + <2 0x80000 0x2000>; /* M3 DMEM */ > >> + > >> + ti,hwmods = "wkup_m3"; > >> + ti,pm-firmware = "am335x-pm-firmware.elf"; > >> + }; > >> + }; > >> + > >> > >> The of_* layer automatically translates everything so the pdata-quirks can still > >> match based on wkup_m3 at 44d00000. The existing wkup_m3_rproc driver works almost > >> entirely as is with this, all cpu addresses are read and mapped correctly but > >> the driver no longer will read the actual device addresses correctly which we > >> need for understanding where to load the firmware sections. > > > > OK. I still don't quite understand how these additional ranges make sense > > for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if > > it allows you to translate directly to the m3 address space, but is that > > really the case here? Maybe you should have the ranges in wkup_m3 instead > > if you want addresses for the m3? > > The idea is to introduce an additional address element (first cell in > ranges) so that the immediate child nodes bus address is referenced as 0 > (second cell) for translation for their child nodes. This is the > approach used by the current scm node in Tero's series for OMAP4+. This > will work tomorrow if we move the prcm, scrm node under l4_wkup with > changes only in those nodes, and have their child nodes reg properties > unchanged. I guess you can see the difference between the following two > patches from Tero's PRCM series, > https://patchwork.kernel.org/patch/5882831/ & > https://patchwork.kernel.org/patch/5882841/ Well I just commented on Tero on that regarding the dra7 patch. I think we need to have separate scm instances for scm_device, scm_core and scm_wkup instead of doing multiple ranges. This based on looking at for example 5432 TRM "Figure 18-1. Control Module Overview". But here I think it's a different issue. You want to use ranges for getting the m3 address space for the firmware? I'm not convinced we should complicate the ranges for all l4_wkup drivers because of that. Regards, Tony ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges 2015-03-11 17:32 ` Tony Lindgren (?) @ 2015-03-11 19:18 ` Suman Anna -1 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-11 19:18 UTC (permalink / raw) To: Tony Lindgren Cc: Dave Gerlach, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi On 03/11/2015 12:32 PM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150311 10:18]: >> On 03/11/2015 11:26 AM, Tony Lindgren wrote: >>> * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: >>>> Suman and I have been looking at this together, so I can comment here. An >>>> implementation like this is what Suman is referring to: >>>> >>>> + l4_wkup: l4_wkup@44c00000 { >>>> + compatible = "am335-l4-wkup", "simple-bus"; >>>> + #address-cells = <2>; >>>> + #size-cells = <1>; >>>> + ranges = <0 0 0x44c00000 0x100000>, >>>> + <1 0x0 0x44d00000 0x4000>, >>>> + <2 0x80000 0x44d80000 0x2000>; >> >> Actually, this would be slightly different, something like >> + ranges = <0 0 0x44c00000 0x100000>, >> + <1 0 0x44d00000 0x100000>, >> + <2 0 0x44e00000 0x4000>, >> + <3 0 0x44e10000 0x2000>; >> >> and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. >> >>>> + >>>> + wkup_m3: wkup_m3@1,0 { >>>> + compatible = "ti,am3353-wkup-m3"; >>>> + reg = <1 0x0 0x4000>, /* M3 UMEM */ >>>> + <2 0x80000 0x2000>; /* M3 DMEM */ >>>> + >>>> + ti,hwmods = "wkup_m3"; >>>> + ti,pm-firmware = "am335x-pm-firmware.elf"; >>>> + }; >>>> + }; >>>> + >>>> >>>> The of_* layer automatically translates everything so the pdata-quirks can still >>>> match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost >>>> entirely as is with this, all cpu addresses are read and mapped correctly but >>>> the driver no longer will read the actual device addresses correctly which we >>>> need for understanding where to load the firmware sections. >>> >>> OK. I still don't quite understand how these additional ranges make sense >>> for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if >>> it allows you to translate directly to the m3 address space, but is that >>> really the case here? Maybe you should have the ranges in wkup_m3 instead >>> if you want addresses for the m3? >> >> The idea is to introduce an additional address element (first cell in >> ranges) so that the immediate child nodes bus address is referenced as 0 >> (second cell) for translation for their child nodes. This is the >> approach used by the current scm node in Tero's series for OMAP4+. This >> will work tomorrow if we move the prcm, scrm node under l4_wkup with >> changes only in those nodes, and have their child nodes reg properties >> unchanged. I guess you can see the difference between the following two >> patches from Tero's PRCM series, >> https://patchwork.kernel.org/patch/5882831/ & >> https://patchwork.kernel.org/patch/5882841/ > > Well I just commented on Tero on that regarding the dra7 patch. I think > we need to have separate scm instances for scm_device, scm_core and > scm_wkup instead of doing multiple ranges. This based on looking at for > example 5432 TRM "Figure 18-1. Control Module Overview". > > But here I think it's a different issue. You want to use ranges for getting > the m3 address space for the firmware? I'm not convinced we should > complicate the ranges for all l4_wkup drivers because of that. Yes, to some extent that's true, as we want to compute the m3 address space using the regs property. In anycase, the wkupm3 driver has to be updated for both approaches, the existing patch wouldn't work as is with the above convention of using 2 address cells. Since the l4_wkup node would be added for the first time, we are trying to see what would be the good approach w.r.t subsequent changes in the DTS if and when we have to move other nodes to be under l4_wkup. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-11 19:18 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-11 19:18 UTC (permalink / raw) To: linux-arm-kernel On 03/11/2015 12:32 PM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150311 10:18]: >> On 03/11/2015 11:26 AM, Tony Lindgren wrote: >>> * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: >>>> Suman and I have been looking at this together, so I can comment here. An >>>> implementation like this is what Suman is referring to: >>>> >>>> + l4_wkup: l4_wkup at 44c00000 { >>>> + compatible = "am335-l4-wkup", "simple-bus"; >>>> + #address-cells = <2>; >>>> + #size-cells = <1>; >>>> + ranges = <0 0 0x44c00000 0x100000>, >>>> + <1 0x0 0x44d00000 0x4000>, >>>> + <2 0x80000 0x44d80000 0x2000>; >> >> Actually, this would be slightly different, something like >> + ranges = <0 0 0x44c00000 0x100000>, >> + <1 0 0x44d00000 0x100000>, >> + <2 0 0x44e00000 0x4000>, >> + <3 0 0x44e10000 0x2000>; >> >> and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. >> >>>> + >>>> + wkup_m3: wkup_m3 at 1,0 { >>>> + compatible = "ti,am3353-wkup-m3"; >>>> + reg = <1 0x0 0x4000>, /* M3 UMEM */ >>>> + <2 0x80000 0x2000>; /* M3 DMEM */ >>>> + >>>> + ti,hwmods = "wkup_m3"; >>>> + ti,pm-firmware = "am335x-pm-firmware.elf"; >>>> + }; >>>> + }; >>>> + >>>> >>>> The of_* layer automatically translates everything so the pdata-quirks can still >>>> match based on wkup_m3 at 44d00000. The existing wkup_m3_rproc driver works almost >>>> entirely as is with this, all cpu addresses are read and mapped correctly but >>>> the driver no longer will read the actual device addresses correctly which we >>>> need for understanding where to load the firmware sections. >>> >>> OK. I still don't quite understand how these additional ranges make sense >>> for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if >>> it allows you to translate directly to the m3 address space, but is that >>> really the case here? Maybe you should have the ranges in wkup_m3 instead >>> if you want addresses for the m3? >> >> The idea is to introduce an additional address element (first cell in >> ranges) so that the immediate child nodes bus address is referenced as 0 >> (second cell) for translation for their child nodes. This is the >> approach used by the current scm node in Tero's series for OMAP4+. This >> will work tomorrow if we move the prcm, scrm node under l4_wkup with >> changes only in those nodes, and have their child nodes reg properties >> unchanged. I guess you can see the difference between the following two >> patches from Tero's PRCM series, >> https://patchwork.kernel.org/patch/5882831/ & >> https://patchwork.kernel.org/patch/5882841/ > > Well I just commented on Tero on that regarding the dra7 patch. I think > we need to have separate scm instances for scm_device, scm_core and > scm_wkup instead of doing multiple ranges. This based on looking at for > example 5432 TRM "Figure 18-1. Control Module Overview". > > But here I think it's a different issue. You want to use ranges for getting > the m3 address space for the firmware? I'm not convinced we should > complicate the ranges for all l4_wkup drivers because of that. Yes, to some extent that's true, as we want to compute the m3 address space using the regs property. In anycase, the wkupm3 driver has to be updated for both approaches, the existing patch wouldn't work as is with the above convention of using 2 address cells. Since the l4_wkup node would be added for the first time, we are trying to see what would be the good approach w.r.t subsequent changes in the DTS if and when we have to move other nodes to be under l4_wkup. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges @ 2015-03-11 19:18 ` Suman Anna 0 siblings, 0 replies; 34+ messages in thread From: Suman Anna @ 2015-03-11 19:18 UTC (permalink / raw) To: Tony Lindgren Cc: Dave Gerlach, linux-arm-kernel, linux-kernel, linux-omap, devicetree, Ohad Ben-Cohen, Kevin Hilman, Felipe Balbi On 03/11/2015 12:32 PM, Tony Lindgren wrote: > * Suman Anna <s-anna@ti.com> [150311 10:18]: >> On 03/11/2015 11:26 AM, Tony Lindgren wrote: >>> * Dave Gerlach <d-gerlach@ti.com> [150310 12:55]: >>>> Suman and I have been looking at this together, so I can comment here. An >>>> implementation like this is what Suman is referring to: >>>> >>>> + l4_wkup: l4_wkup@44c00000 { >>>> + compatible = "am335-l4-wkup", "simple-bus"; >>>> + #address-cells = <2>; >>>> + #size-cells = <1>; >>>> + ranges = <0 0 0x44c00000 0x100000>, >>>> + <1 0x0 0x44d00000 0x4000>, >>>> + <2 0x80000 0x44d80000 0x2000>; >> >> Actually, this would be slightly different, something like >> + ranges = <0 0 0x44c00000 0x100000>, >> + <1 0 0x44d00000 0x100000>, >> + <2 0 0x44e00000 0x4000>, >> + <3 0 0x44e10000 0x2000>; >> >> and the M3 DMEM entry below will be adjusted as <1 0x80000 0x2000>. >> >>>> + >>>> + wkup_m3: wkup_m3@1,0 { >>>> + compatible = "ti,am3353-wkup-m3"; >>>> + reg = <1 0x0 0x4000>, /* M3 UMEM */ >>>> + <2 0x80000 0x2000>; /* M3 DMEM */ >>>> + >>>> + ti,hwmods = "wkup_m3"; >>>> + ti,pm-firmware = "am335x-pm-firmware.elf"; >>>> + }; >>>> + }; >>>> + >>>> >>>> The of_* layer automatically translates everything so the pdata-quirks can still >>>> match based on wkup_m3@44d00000. The existing wkup_m3_rproc driver works almost >>>> entirely as is with this, all cpu addresses are read and mapped correctly but >>>> the driver no longer will read the actual device addresses correctly which we >>>> need for understanding where to load the firmware sections. >>> >>> OK. I still don't quite understand how these additional ranges make sense >>> for other drivers connected to the l4_wkup. For wkup_m3, it makes sense if >>> it allows you to translate directly to the m3 address space, but is that >>> really the case here? Maybe you should have the ranges in wkup_m3 instead >>> if you want addresses for the m3? >> >> The idea is to introduce an additional address element (first cell in >> ranges) so that the immediate child nodes bus address is referenced as 0 >> (second cell) for translation for their child nodes. This is the >> approach used by the current scm node in Tero's series for OMAP4+. This >> will work tomorrow if we move the prcm, scrm node under l4_wkup with >> changes only in those nodes, and have their child nodes reg properties >> unchanged. I guess you can see the difference between the following two >> patches from Tero's PRCM series, >> https://patchwork.kernel.org/patch/5882831/ & >> https://patchwork.kernel.org/patch/5882841/ > > Well I just commented on Tero on that regarding the dra7 patch. I think > we need to have separate scm instances for scm_device, scm_core and > scm_wkup instead of doing multiple ranges. This based on looking at for > example 5432 TRM "Figure 18-1. Control Module Overview". > > But here I think it's a different issue. You want to use ranges for getting > the m3 address space for the firmware? I'm not convinced we should > complicate the ranges for all l4_wkup drivers because of that. Yes, to some extent that's true, as we want to compute the m3 address space using the regs property. In anycase, the wkupm3 driver has to be updated for both approaches, the existing patch wouldn't work as is with the above convention of using 2 address cells. Since the l4_wkup node would be added for the first time, we are trying to see what would be the good approach w.r.t subsequent changes in the DTS if and when we have to move other nodes to be under l4_wkup. regards Suman ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2015-03-11 19:19 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-05 4:12 [PATCH v2 0/2] ARM: OMAP2+: wkup_m3_rproc support patches Dave Gerlach 2015-03-05 4:12 ` Dave Gerlach 2015-03-05 4:12 ` Dave Gerlach 2015-03-05 4:12 ` [PATCH v2 1/2] ARM: OMAP2+: Use pdata-quirks for wkup_m3 deassert_hardreset Dave Gerlach 2015-03-05 4:12 ` Dave Gerlach 2015-03-05 4:12 ` Dave Gerlach 2015-03-05 4:12 ` [PATCH v2 2/2] ARM: dts: am33xx: Move wkup_m3 node to soc node and add ranges Dave Gerlach 2015-03-05 4:12 ` Dave Gerlach 2015-03-05 4:12 ` Dave Gerlach 2015-03-05 15:40 ` Tony Lindgren 2015-03-05 15:40 ` Tony Lindgren 2015-03-05 16:46 ` Suman Anna 2015-03-05 16:46 ` Suman Anna 2015-03-05 16:46 ` Suman Anna 2015-03-05 16:57 ` Tony Lindgren 2015-03-05 16:57 ` Tony Lindgren 2015-03-09 23:59 ` Suman Anna 2015-03-09 23:59 ` Suman Anna 2015-03-09 23:59 ` Suman Anna 2015-03-10 16:09 ` Tony Lindgren 2015-03-10 16:09 ` Tony Lindgren 2015-03-10 19:55 ` Dave Gerlach 2015-03-10 19:55 ` Dave Gerlach 2015-03-10 19:55 ` Dave Gerlach 2015-03-11 16:26 ` Tony Lindgren 2015-03-11 16:26 ` Tony Lindgren 2015-03-11 17:18 ` Suman Anna 2015-03-11 17:18 ` Suman Anna 2015-03-11 17:18 ` Suman Anna 2015-03-11 17:32 ` Tony Lindgren 2015-03-11 17:32 ` Tony Lindgren 2015-03-11 19:18 ` Suman Anna 2015-03-11 19:18 ` Suman Anna 2015-03-11 19:18 ` Suman Anna
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.