ARM: imx6q: add support for IRAM
PATCH 1/1 ARM: imx6q: add support for IRAM
--- arch/arm/boot/dts/imx6q.dtsi | 7 +++++++ arch/arm/mach-imx/Kconfig | 1 + arch/arm/mach-imx/clock-imx6q.c | 3 ++- arch/arm/mach-imx/mach-imx6q.c | 17 +++++++++++++++++ 4 files changed, 27 insertions(+), 1 deletions(-)
arch/arm/boot/dts/imx6q.dtsi +7 -0
@@ -80,6 +80,13 @@ }; }; + ocram at 00900000 { + compatible = "fsl,imx6q-iram"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x00900000 0x40000>; + }; + soc { #address-cells = <1>; #size-cells = <1>;
arch/arm/mach-imx/Kconfig +1 -0
@@ -841,6 +841,7 @@ config SOC_IMX6Q select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC + select IRAM_ALLOC select USE_OF help
arch/arm/mach-imx/clock-imx6q.c +2 -1
@@ -1777,6 +1777,7 @@ DEF_CLK(mmdc_ch0_axi_clk, CCGR3, CG10, &periph_clk, &mmdc_ch0_ipg_clk);DEF_CLK (mmdc_ch1_ipg_clk,CCGR3 ,CG13 , &ipg_clk,NULL );DEF_CLK (mmdc_ch1_axi_clk,CCGR3 ,CG11 , &periph2_clk, &mmdc_ch1_ipg_clk);DEF_CLK (openvg_axi_clk,CCGR3 ,CG13 , &axi_clk,NULL ); +DEF_CLK (ocram_clk,CCGR3 ,CG14 , &ahb_clk,NULL );DEF_CLK (pwm1_clk,CCGR4 ,CG8 , &ipg_perclk,NULL );DEF_CLK (pwm2_clk,CCGR4 ,CG9 , &ipg_perclk,NULL );DEF_CLK (pwm3_clk,CCGR4 ,CG10 , &ipg_perclk,NULL );
@@ -1982,7 +1983,7 @@ int __init mx6q_clocks_init(void)/* only keep necessary clocks on */ writel_relaxed (0x3 <<CG0 |0x3 <<CG1 |0x3 <<CG2 ,CCGR0 );writel_relaxed (0x3 <<CG8 |0x3 <<CG9 |0x3 <<CG10 ,CCGR2 ); -writel_relaxed (0x3 <<CG10 |0x3 <<CG12 ,CCGR3 ); +writel_relaxed (0x3 <<CG10 |0x3 <<CG12 |0x1 <<CG14 ,CCGR3 );writel_relaxed (0x3 <<CG4 |0x3 <<CG6 |0x3 <<CG7 ,CCGR4 );writel_relaxed (0x3 <<CG0 ,CCGR5 );writel_relaxed (0 ,CCGR6 );
arch/arm/mach-imx/mach-imx6q.c +17 -0
@@ -27,6 +27,7 @@#include <asm/mach/time.h> #include <mach/common.h> #include <mach/hardware.h> +#include <mach/iram.h> void imx6q_restart (char mode,const char *cmd) {
@@ -73,6 +74,21 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)return 0 ; } +static int imx6q_init_iram (void ) +{ +struct device_node *np; +struct resource res; + + np =of_find_compatible_node (NULL ,NULL ,"fsl,imx6q-iram" ); +if (np) { +if (!of_address_to_resource (np,0 , &res)) +return iram_init (res.start, res.end - res.start +1 ); +else +return 0 ; + }else +return 0 ; +} +static void __init imx6q_init_machine (void ) {if (of_machine_is_compatible ("fsl,imx6q-sabrelite" ))
@@ -81,6 +97,7 @@ static void __init imx6q_init_machine(void)of_platform_populate (NULL , of_default_bus_match_table,NULL ,NULL ); +imx6q_init_iram ();imx6q_pm_init (); }
Signature · 1 line
1.7.4.1
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 14 lines · Jason Chen
Signed-off-by Jason Chen <[email protected]>Signed-off-by Eric Miao <[email protected]>--- arch/arm/boot/dts/imx6q.dtsi | 7 +++++++ arch/arm/mach-imx/Kconfig | 1 + arch/arm/mach-imx/clock-imx6q.c | 3 ++- arch/arm/mach-imx/mach-imx6q.c | 17 +++++++++++++++++ 4 files changed, 27 insertions(+), 1 deletions(-)arch/arm/boot/dts/imx6q.dtsi +0
-0
arch/arm/boot/dts/imx6q.dtsi line 84
Quoted 5 lines
arch/arm/boot/dts/imx6q.dtsi +2
-0@@ -80,6 +80,13 @@ }; }; + ocram at 00900000 { + compatible = "fsl,imx6q-iram";
It should have nothing specific to imx6q, and could be "fsl,iram". Then we can have some common code across different SoCs to match it.
arch/arm/boot/dts/imx6q.dtsi line 89
Quoted 5 lines
arch/arm/boot/dts/imx6q.dtsi +5
-0+ #address-cells = <1>; + #size-cells = <1>; + reg = <0x00900000 0x40000>; + }; +
Would it be better to put this node inside node 'soc', since it's the part of SoC? The bonus point would be that we can save #address-cells and #size-cells for iram node.
Quoted 57 lines
arch/arm/boot/dts/imx6q.dtsi +0
-0soc { #address-cells = <1>; #size-cells = <1>;arch/arm/mach-imx/Kconfig +1
-0@@ -841,6 +841,7 @@ config SOC_IMX6Q select HAVE_IMX_GPC select HAVE_IMX_MMDC select HAVE_IMX_SRC + select IRAM_ALLOC select USE_OF helparch/arm/mach-imx/clock-imx6q.c +2
-1@@ -1777,6 +1777,7 @@ DEF_CLK(mmdc_ch0_axi_clk, CCGR3, CG10, &periph_clk, &mmdc_ch0_ipg_clk);DEF_CLK (mmdc_ch1_ipg_clk,CCGR3 ,CG13 , &ipg_clk,NULL );DEF_CLK (mmdc_ch1_axi_clk,CCGR3 ,CG11 , &periph2_clk, &mmdc_ch1_ipg_clk);DEF_CLK (openvg_axi_clk,CCGR3 ,CG13 , &axi_clk,NULL ); +DEF_CLK (ocram_clk,CCGR3 ,CG14 , &ahb_clk,NULL );DEF_CLK (pwm1_clk,CCGR4 ,CG8 , &ipg_perclk,NULL );DEF_CLK (pwm2_clk,CCGR4 ,CG9 , &ipg_perclk,NULL );DEF_CLK (pwm3_clk,CCGR4 ,CG10 , &ipg_perclk,NULL );@@ -1982,7 +1983,7 @@ int __init mx6q_clocks_init(void)/* only keep necessary clocks on */ writel_relaxed (0x3 <<CG0 |0x3 <<CG1 |0x3 <<CG2 ,CCGR0 );writel_relaxed (0x3 <<CG8 |0x3 <<CG9 |0x3 <<CG10 ,CCGR2 ); -writel_relaxed (0x3 <<CG10 |0x3 <<CG12 ,CCGR3 ); +writel_relaxed (0x3 <<CG10 |0x3 <<CG12 |0x1 <<CG14 ,CCGR3 );writel_relaxed (0x3 <<CG4 |0x3 <<CG6 |0x3 <<CG7 ,CCGR4 );writel_relaxed (0x3 <<CG0 ,CCGR5 );writel_relaxed (0 ,CCGR6 );arch/arm/mach-imx/mach-imx6q.c +6
-0@@ -27,6 +27,7 @@#include <asm/mach/time.h> #include <mach/common.h> #include <mach/hardware.h> +#include <mach/iram.h> void imx6q_restart (char mode,const char *cmd) {@@ -73,6 +74,21 @@ static int ksz9021rn_phy_fixup(struct phy_device *phydev)return 0 ; } +static int imx6q_init_iram (void ) +{ +struct device_node *np; +struct resource res; +
arch/arm/mach-imx/mach-imx6q.c static int ksz9021rn_phy_fixup(struct phy_device *phydev) · line 91
Quoted 10 lines
arch/arm/mach-imx/mach-imx6q.c +10
-0+ np =of_find_compatible_node (NULL ,NULL ,"fsl,imx6q-iram" ); +if (np) { +if (!of_address_to_resource (np,0 , &res)) +return iram_init (res.start, res.end - res.start +1 ); +else +return 0 ; + }else +return 0 ; +} +
This piece of code should not be imx6q specific. Instead, it could become the function iram_of_init() in iram_alloc.c, so that the future soc like imx6dl or whatever that has iram integrated can just can call iram_of_init() to have iram allocator set up.
Signature · 2 lines
Regards, Shawn
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 18 lines · Shawn Guo
Quoted 17 lines · Jason Chen
Signed-off-by Jason Chen <[email protected]>Signed-off-by Eric Miao <[email protected]>--- arch/arm/boot/dts/imx6q.dtsi | 7 +++++++ arch/arm/mach-imx/Kconfig | 1 + arch/arm/mach-imx/clock-imx6q.c | 3 ++- arch/arm/mach-imx/mach-imx6q.c | 17 +++++++++++++++++ 4 files changed, 27 insertions(+), 1 deletions(-)arch/arm/boot/dts/imx6q.dtsi +0
-0@@ -80,6 +80,13 @@ }; };
Quoted 5 lines
arch/arm/boot/dts/imx6q.dtsi line 84
Quoted 2 lines
arch/arm/boot/dts/imx6q.dtsi +2
-0+ ocram at 00900000 { + compatible = "fsl,imx6q-iram";It should have nothing specific to imx6q, and could be "fsl,iram". Then we can have some common code across different SoCs to match it.
Why is this even specific to fsl? Isn't it something that could be specified in a totally generic way?
As I showed with my original set of sram patches, there is not much specific about this on-board RAM: what is specific is how a SoC uses it, and that's up to the rest of the SoC code.
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 25 lines · Russell King - ARM Linux
Quoted 18 lines · Shawn Guo
Quoted 17 lines · Jason Chen
Signed-off-by Jason Chen <[email protected]>Signed-off-by Eric Miao <[email protected]>--- arch/arm/boot/dts/imx6q.dtsi | 7 +++++++ arch/arm/mach-imx/Kconfig | 1 + arch/arm/mach-imx/clock-imx6q.c | 3 ++- arch/arm/mach-imx/mach-imx6q.c | 17 +++++++++++++++++ 4 files changed, 27 insertions(+), 1 deletions(-)arch/arm/boot/dts/imx6q.dtsi +0
-0@@ -80,6 +80,13 @@ }; };Quoted 5 lines
arch/arm/boot/dts/imx6q.dtsi line 84
Quoted 2 lines
arch/arm/boot/dts/imx6q.dtsi +2
-0+ ocram at 00900000 { + compatible = "fsl,imx6q-iram";It should have nothing specific to imx6q, and could be "fsl,iram". Then we can have some common code across different SoCs to match it.
Quoted 7 lines
Why is this even specific to fsl? Isn't it something that could be specified in a totally generic way?
As I showed with my original set of sram patches, there is not much specific about this on-board RAM: what is specific is how a SoC uses it, and that's up to the rest of the SoC code.
As I have not seen any news/updates about the sram consolidation series since May, I did not bring up it here. So what's the state of the series? If it shows up on some stable branch, we would be happy to base the work here on it.
Signature · 2 lines
Regards, Shawn
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 4 lines · Shawn Guo
Quoted 3 lines · Russell King - ARM Linux
Why is this even specific to fsl? Isn't it something that could be specified in a totally generic way?
Quoted 8 lines
Quoted 4 lines
As I showed with my original set of sram patches, there is not much specific about this on-board RAM: what is specific is how a SoC uses it, and that's up to the rest of the SoC code.
As I have not seen any news/updates about the sram consolidation series since May, I did not bring up it here. So what's the state of the series? If it shows up on some stable branch, we would be happy to base the work here on it.
I have no idea; as I've already said, I lost total interest in it.
What I _am_ saying though is that rather than defining some platform specific bindings and continuing that idiotic state of affairs, we have the chance to do things properly now: define a standard set of DT bindings to describe on-board SRAM.
That's something which can be done with or without the sram consolidation stuff.
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 16 lines · Russell King - ARM Linux
Quoted 4 lines · Shawn Guo
Quoted 3 lines · Russell King - ARM Linux
Why is this even specific to fsl? Isn't it something that could be specified in a totally generic way?
Quoted 8 lines
Quoted 4 lines
As I showed with my original set of sram patches, there is not much specific about this on-board RAM: what is specific is how a SoC uses it, and that's up to the rest of the SoC code.
As I have not seen any news/updates about the sram consolidation series since May, I did not bring up it here. So what's the state of the series? If it shows up on some stable branch, we would be happy to base the work here on it.
I have no idea; as I've already said, I lost total interest in it.
Quoted 8 lines
What I _am_ saying though is that rather than defining some platform specific bindings and continuing that idiotic state of affairs, we have the chance to do things properly now: define a standard set of DT bindings to describe on-board SRAM.
That's something which can be done with or without the sram consolidation stuff.
I guess it makes more sense to have a concentrated piece of code backing that DT binding. This can be another reason we should continue the sram consolidation effort?
Signature · 2 lines
Regards, Shawn
PATCH 1/1 ARM: imx6q: add support for IRAM
In reply to Russell King - ARM LinuxQuoted 16 lines · Russell King - ARM Linux
Quoted 4 lines · Shawn Guo
Quoted 3 lines · Russell King - ARM Linux
Why is this even specific to fsl? ?Isn't it something that could be specified in a totally generic way?
Quoted 8 lines
Quoted 4 lines
As I showed with my original set of sram patches, there is not much specific about this on-board RAM: what is specific is how a SoC uses it, and that's up to the rest of the SoC code.
As I have not seen any news/updates about the sram consolidation series since May, I did not bring up it here. ?So what's the state of the series? ?If it shows up on some stable branch, we would be happy to base the work here on it.
I have no idea; as I've already said, I lost total interest in it.
Quoted 7 lines
What I _am_ saying though is that rather than defining some platform specific bindings and continuing that idiotic state of affairs, we have the chance to do things properly now: define a standard set of DT bindings to describe on-board SRAM.
That's something which can be done with or without the sram consolidation stuff.
I second this. It's just a piece of RAM, it should be described the same way irrespective of system or even OS.
On-chip RAM is yet another area where platforms and their maintainers sometimes think they are very different - just like everyone else.
(This connects to the other IRAM patch floating on the list.)
Yours,
Linus Walleij
PATCH 1/1 ARM: imx6q: add support for IRAM
In reply to Jason ChenQuoted 1 line · Jason Chen
+DEF_CLK(ocram_clk, CCGR3, CG14,
&ahb_clk, NULL);
CC arch/arm/mach-imx/clock-imx6q.oarch/arm/mach-imx/clock-imx6q.c:1782:1: warning: ?ocram_clk? defined but not used
Signature · 2 lines
Regards, Shawn
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 5 lines · Shawn Guo
Quoted 1 line · Jason Chen
+DEF_CLK(ocram_clk, CCGR3, CG14,
&ahb_clk, NULL);CC
arch/arm/mach-imx/clock-imx6q.oarch/arm/mach-imx/clock-imx6q.c:1782:1: warning: ?ocram_clk? defined but not used
it should be a dependcy of vpu/sdma who using IRAM, they can be added.
Quoted 10 lines
Signature · 9 lines
-- Regards, Shawn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 7 lines · Jason Chen
Quoted 5 lines · Shawn Guo
Quoted 1 line · Jason Chen
+DEF_CLK(ocram_clk, CCGR3, CG14,
&ahb_clk, NULL);CC
arch/arm/mach-imx/clock-imx6q.oarch/arm/mach-imx/clock-imx6q.c:1782:1: warning: ?ocram_clk? defined but not usedit should be a dependcy of vpu/sdma who using IRAM, they can be added.
My point is your patch should not introduce any warning at any time.
Signature · 2 lines
Regards, Shawn
PATCH 1/1 ARM: imx6q: add support for IRAM
Quoted 10 lines · Shawn Guo
Quoted 7 lines · Jason Chen
Quoted 5 lines · Shawn Guo
Quoted 1 line · Jason Chen
+DEF_CLK(ocram_clk, CCGR3, CG14,
&ahb_clk, NULL);CC
arch/arm/mach-imx/clock-imx6q.oarch/arm/mach-imx/clock-imx6q.c:1782:1: warning: ?ocram_clk? defined but not usedit should be a dependcy of vpu/sdma who using IRAM, they can be added.
My point is your patch should not introduce any warning at any time.
sure, will fix it.
Quoted 4 lines
Signature · 3 lines
-- Regards, Shawn