Re: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Wed, 2012-07-18 at 11:24 -0600, Paul Walmsley wrote: On Wed, 18 Jul 2012, Tero Kristo wrote: On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote: OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will need to know when it lost context to be able to reload it's firmware, no? It looks like current hwmod data doesn't support specific bits to be used for the context declaration, it is only specifying the register offset. Also, the same register is used by aess hwmod, so this will cause a conflict if I take the same register into use. This could be fixed by adding a field for the context bits, but I guess this should be commented upon by someone (Benoit / Paul) before I craft some sort of patch for that. If you need to add a u8 there to specify the bitshift, go ahead and do it. u8 lostmem_bit, perhaps? Mask might be better, as we have RFF / DFF bits, and also if mask is not defined, we can assume we want to check the whole register (current behavior.) I'll add this for next rev. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will
need to know when it lost context to be able to reload it's firmware,
no?
You are right, this should be possible to use. I just searched for
modules which didn't have context_offs defined and added USHRT_MAX
blindly there.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote:
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will
need to know when it lost context to be able to reload it's firmware,
no?
It looks like current hwmod data doesn't support specific bits to be
used for the context declaration, it is only specifying the register
offset. Also, the same register is used by aess hwmod, so this will
cause a conflict if I take the same register into use.
This could be fixed by adding a field for the context bits, but I guess
this should be commented upon by someone (Benoit / Paul) before I craft
some sort of patch for that.
Meanwhile, I will keep the USHRT_MAX here until better solution is
available.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Wed, 18 Jul 2012, Tero Kristo wrote: On Tue, 2012-07-17 at 03:11 -0500, Menon, Nishanth wrote: OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will need to know when it lost context to be able to reload it's firmware, no? It looks like current hwmod data doesn't support specific bits to be used for the context declaration, it is only specifying the register offset. Also, the same register is used by aess hwmod, so this will cause a conflict if I take the same register into use. This could be fixed by adding a field for the context bits, but I guess this should be commented upon by someone (Benoit / Paul) before I craft some sort of patch for that. If you need to add a u8 there to specify the bitshift, go ahead and do it. u8 lostmem_bit, perhaps? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 3/7] ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
On Mon, Jun 11, 2012 at 10:26 AM, Tero Kristo t-kri...@ti.com wrote:
On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relied on the power domain level context status.
Identify all modules that don't support 'context_offs' by marking the
offset as USHRT_MAX. Rest have a valid 'context_offs' populated in
.prcm structure already.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86fc513..828e7b8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -208,6 +208,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP4_CM1_ABE_L4ABE_CLKCTRL_OFFSET,
+ .context_offs = USHRT_MAX,
OMAP4430_RM_ABE_AESS_CONTEXT? why not use LOSTMEM_AESSMEM ? ABE will
need to know when it lost context to be able to reload it's firmware,
no?
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
