Skip to contentSkip to conversation

i.MX6: imx_ccm is a constant that points to a register set

PATCH New Eric Nelson 2 participants 5 messages Mar 5, 2012 – Mar 7, 2012

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 i.MX6: imx_ccm is a constant that points to a register set

If we're going to use globals to point at register banks, they should be constant and visible.

---
 arch/arm/cpu/armv7/mx6/clock.c           |    2 +-
 arch/arm/include/asm/arch-mx6/imx-regs.h |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/mx6/clock.c +1 -1
index ef98563..eb1f09b 100644
@@ -34,7 +34,7 @@ enum pll_clocks {
 	PLL_ENET,	/* ENET PLL */
 };
 
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct imx_ccm_reg *const imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
 
 void enable_usboh3_clk(unsigned char enable)
 {
arch/arm/include/asm/arch-mx6/imx-regs.h +2 -0
index 3e5c4c2..3eae704 100644
@@ -297,5 +297,7 @@ struct aipstz_regs {
 	u32	opacr4;
 };
 
+extern struct imx_ccm_reg *const imx_ccm ;
+
 #endif /* __ASSEMBLER__*/
 #endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */
Signature · 1 line
1.7.9
#1 lore raw

PATCH 1/1 i.MX6: imx_ccm is a constant that points to a register set

On 05/03/2012 17:34, Eric Nelson wrote:

Hi Eric,

Quoted 3 lines

If we're going to use globals to point at register banks, they should be constant and visible.
---

ok, but why are we going to use global pointers ? We have global constants (in imx-regs.h) and each part of code sets its local copy without using global pointers, that require also some rules and naming conventions to avoid conflicts.

Quoted 9 lines
 arch/arm/cpu/armv7/mx6/clock.c           |    2 +-
 arch/arm/include/asm/arch-mx6/imx-regs.h |    2 ++
 2 files changed, 3 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/mx6/clock.c +0 -0
index ef98563..eb1f09b 100644

arch/arm/cpu/armv7/mx6/clock.c enum pll_clocks { · line 37

Quoted 5 lines
arch/arm/cpu/armv7/mx6/clock.c +1 -1
@@ -34,7 +34,7 @@ enum pll_clocks {
 	PLL_ENET,	/* ENET PLL */
 };
 
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct imx_ccm_reg *const imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;

As far as I see, this is used only in clock.c - and it must be static.

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#2 lore raw

PATCH 1/1 i.MX6: imx_ccm is a constant that points to a register set

Quoted 4 lines · Stefano Babic

On 05/03/2012 17:34, Eric Nelson wrote:

Hi Eric,

Quoted 9 lines
Quoted 3 lines

If we're going to use globals to point at register banks, they should be constant and visible.
---

ok, but why are we going to use global pointers ? We have global constants (in imx-regs.h) and each part of code sets its local copy without using global pointers, that require also some rules and naming conventions to avoid conflicts.

I'm just trying to follow convention here. My preference would be to make these constants visible to the compiler in some way.

Quoted 12 lines
Quoted 12 lines
  arch/arm/cpu/armv7/mx6/clock.c           |    2 +-
  arch/arm/include/asm/arch-mx6/imx-regs.h |    2 ++
  2 files changed, 3 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/mx6/clock.c +0 -0
index ef98563..eb1f09b 100644
@@ -34,7 +34,7 @@ enum pll_clocks {
  	PLL_ENET,	/* ENET PLL */
  };
 
Quoted 5 lines

arch/arm/cpu/armv7/mx6/clock.c enum pll_clocks { · line 37

Quoted 2 lines
arch/arm/cpu/armv7/mx6/clock.c +1 -1
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct imx_ccm_reg *const imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;

As far as I see, this is used only in clock.c - and it must be static.

I ran into this when trying to fix setup_sata() in mx6qsabrelite.c as shown in this patch.

The same sort of question (how to define the register sets) will occur for other register sets.

For the iomux, I used a #define, but that seems wrong too (not least because it isn't UPPERCASE).

	#define iomuxc ((struct iomuxc_base_regs *)IOMUXC_BASE_ADDR)

The other way around this is to hide all register accesses behind the drivers. IOW, add routines for each of the accesses and hide the details in clock.c

	void mx6_enable_sata_clock();
	...

	void mx6_enable_enet_pll();

but there will almost certainly be board-specific tweaks and I'm not sure the extra level of abstraction helps.

Let me know your thoughts about how to structure this stuff.

Regards,

Eric

#3 lore raw

PATCH 1/1 i.MX6: imx_ccm is a constant that points to a register set

On 06/03/2012 15:34, Eric Nelson wrote:

Hi Eric,

Quoted 8 lines
Quoted 5 lines

ok, but why are we going to use global pointers ? We have global constants (in imx-regs.h) and each part of code sets its local copy without using global pointers, that require also some rules and naming conventions to avoid conflicts.

I'm just trying to follow convention here. My preference would be to make these constants visible to the compiler in some way.

At the moment we have not an abstraction layer, but all constants related to physycal addresses are visible because defined in imx-regs.h

Quoted 37 lines
Quoted 14 lines
Quoted 14 lines
  arch/arm/cpu/armv7/mx6/clock.c           |    2 +-
  arch/arm/include/asm/arch-mx6/imx-regs.h |    2 ++
  2 files changed, 3 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/mx6/clock.c +0 -0
index ef98563..eb1f09b 100644
@@ -34,7 +34,7 @@ enum pll_clocks {
      PLL_ENET,    /* ENET PLL */
  };
 
Quoted 6 lines

arch/arm/cpu/armv7/mx6/clock.c enum pll_clocks { · line 38

Quoted 3 lines
arch/arm/cpu/armv7/mx6/clock.c +1 -1
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct imx_ccm_reg *const imx_ccm = (struct imx_ccm_reg
 *)CCM_BASE_ADDR;

As far as I see, this is used only in clock.c - and it must be static.

I ran into this when trying to fix setup_sata() in mx6qsabrelite.c as shown in
this patch.

The same sort of question (how to define the register sets) will occur for other register sets.

For the iomux, I used a #define, but that seems wrong too (not least because it isn't UPPERCASE).

    #define iomuxc ((struct iomuxc_base_regs *)IOMUXC_BASE_ADDR)

The other way around this is to hide all register accesses behind the drivers. IOW, add routines for each of the accesses and hide the details in clock.c

Quoted 7 lines
    void mx6_enable_sata_clock();
    ...

    void mx6_enable_enet_pll();

but there will almost certainly be board-specific tweaks and I'm not sure the extra level of abstraction helps.

Yes - this makes such abstraction difficult. However, we have not such kind of abstraction at the moment, and all boards define local pointers using the global constants. This is the current status for the CCM (clock module) block for all i.MX.

If you see for MX3 / MX5 boards, you see that board files are implementing something like:

struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)MXC_CCM_BASE;

and then they are using the mxc_ccm_reg structure. If we want to abstract this, we should get rid of special peripheral function (a mx6_ function) and write a function callable from other Socs. I do not think it is a good idea to have SOC-related functions (mx5_, mx6_, mx35_...), even if I know that specially for mx31 (the first i.MX SOC merged into U-boot) some cleanup is still required. If we can factorize, then we need a general mxc_enable_sata_clock(), whose implementation could be SOC specific.

Take a look if it is possible to factorize - however, at the moment, I think it is not bad if you define a pointer in your setup_sata() function and then you enable directly the clock.

Best regards,
Stefano Babic

Signature · 5 lines
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
#4 lore raw

PATCH 1/1 i.MX6: imx_ccm is a constant that points to a register set

Quoted 80 lines · Stefano Babic

On 06/03/2012 15:34, Eric Nelson wrote:

Hi Eric,

Quoted 8 lines
Quoted 5 lines

ok, but why are we going to use global pointers ? We have global constants (in imx-regs.h) and each part of code sets its local copy without using global pointers, that require also some rules and naming conventions to avoid conflicts.

I'm just trying to follow convention here. My preference would be to make these constants visible to the compiler in some way.

At the moment we have not an abstraction layer, but all constants related to physycal addresses are visible because defined in imx-regs.h

Quoted 37 lines
Quoted 14 lines
Quoted 14 lines
   arch/arm/cpu/armv7/mx6/clock.c           |    2 +-
   arch/arm/include/asm/arch-mx6/imx-regs.h |    2 ++
   2 files changed, 3 insertions(+), 1 deletions(-)
arch/arm/cpu/armv7/mx6/clock.c +0 -0
index ef98563..eb1f09b 100644
@@ -34,7 +34,7 @@ enum pll_clocks {
       PLL_ENET,    /* ENET PLL */
   };
 
Quoted 6 lines

arch/arm/cpu/armv7/mx6/clock.c enum pll_clocks { · line 38

Quoted 3 lines
arch/arm/cpu/armv7/mx6/clock.c +1 -1
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct imx_ccm_reg *const imx_ccm = (struct imx_ccm_reg
 *)CCM_BASE_ADDR;

As far as I see, this is used only in clock.c - and it must be static.

I ran into this when trying to fix setup_sata() in mx6qsabrelite.c as shown in
this patch.

The same sort of question (how to define the register sets) will occur for other register sets.

For the iomux, I used a #define, but that seems wrong too (not least because it isn't UPPERCASE).

     #define iomuxc ((struct iomuxc_base_regs *)IOMUXC_BASE_ADDR)

The other way around this is to hide all register accesses behind the drivers. IOW, add routines for each of the accesses and hide the details in clock.c

Quoted 7 lines
     void mx6_enable_sata_clock();
     ...

     void mx6_enable_enet_pll();

but there will almost certainly be board-specific tweaks and I'm not sure the extra level of abstraction helps.

Yes - this makes such abstraction difficult. However, we have not such kind of abstraction at the moment, and all boards define local pointers using the global constants. This is the current status for the CCM (clock module) block for all i.MX.

If you see for MX3 / MX5 boards, you see that board files are implementing something like:

struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)MXC_CCM_BASE;

and then they are using the mxc_ccm_reg structure. If we want to abstract this, we should get rid of special peripheral function (a mx6_ function) and write a function callable from other Socs. I do not think it is a good idea to have SOC-related functions (mx5_, mx6_, mx35_...), even if I know that specially for mx31 (the first i.MX SOC merged into U-boot) some cleanup is still required. If we can factorize, then we need a general mxc_enable_sata_clock(), whose implementation could be SOC specific.

Quoted 4 lines

Take a look if it is possible to factorize - however, at the moment, I think it is not bad if you define a pointer in your setup_sata() function and then you enable directly the clock.

Will do.

Quoted 3 lines

Best regards,
Stefano Babic