[RFC] AM35x: Workaround to use generic OMAP3 hwmods

[RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Sanjeev Premi]

This patch implements workaround to reuse the hwmods
defined for OMAP3. Else, the master-slave dependency
cascades into duplicating all of the hwmods.

Without this workaround, the AM3517 EVM fails to boot
due to kernel panic while initializing the SR hwmods.

Until real solution is implemented, this workaround
can be considered.

Signed-off-by: Sanjeev Premi <premi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   66 +++++++++++++++++++++++++++-
 1 files changed, 65 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 800eda4..c8854eb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1670,7 +1670,71 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
 	NULL,
 };
 
+/**
+ * HWMODs specific to AM35x processors
+ * Though they are quite similar to OMAP34xx definitions,
+ * having separate array makes customization easy.
+ */
+static __initdata struct omap_hwmod *am35xx_hwmods[] = {
+	&omap3xxx_l3_main_hwmod,
+	&omap3xxx_l4_core_hwmod,
+	&omap3xxx_l4_per_hwmod,
+	&omap3xxx_l4_wkup_hwmod,
+	&omap3xxx_mpu_hwmod,
+	&omap3xxx_wd_timer2_hwmod,
+	&omap3xxx_uart1_hwmod,
+	&omap3xxx_uart2_hwmod,
+	&omap3xxx_uart3_hwmod,
+	&omap3xxx_uart4_hwmod,
+	&omap3xxx_i2c1_hwmod,
+	&omap3xxx_i2c2_hwmod,
+	&omap3xxx_i2c3_hwmod,
+
+	/* gpio class */
+	&omap3xxx_gpio1_hwmod,
+	&omap3xxx_gpio2_hwmod,
+	&omap3xxx_gpio3_hwmod,
+	&omap3xxx_gpio4_hwmod,
+	&omap3xxx_gpio5_hwmod,
+	&omap3xxx_gpio6_hwmod,
+
+	/* dma_system class*/
+	&omap3xxx_dma_system_hwmod,
+
+	/* mcspi class */
+	&omap34xx_mcspi1,
+	&omap34xx_mcspi2,
+	&omap34xx_mcspi3,
+	&omap34xx_mcspi4,
+	NULL,
+};
+
 int __init omap3xxx_hwmod_init(void)
 {
-	return omap_hwmod_init(omap3xxx_hwmods);
+	if (cpu_is_omap3505() || cpu_is_omap3517()) {
+
+		/* TODO: Find better way to get this done.
+		 *
+		 * AM35xx doesn't support smartreflex. This requires:
+		 * 1) Removing related hwmods from the initialization list.
+		 *    (done).
+		 * 2) Removing omap3_l4_core__sr1 and omap3_l4_core__sr2
+		 *    from omap3xxx_l4_core_slaves.
+		 *    This, however, has cascading effect on all hwmods,
+		 *    due to master-slave relations between these hwmods.
+		 *
+		 * Instead of duplicating contents of this file, updating
+		 * the structure to restrict slave count to 1; and setting
+		 * address of omap3_l4_core__sr1 & omap3_l4_core__sr2 to
+		 * NULL should be a reasonable workaround.
+		 */
+		omap3xxx_l4_core_slaves[1] = NULL;
+		omap3xxx_l4_core_slaves[2] = NULL;
+
+		omap3xxx_l4_core_hwmod.slaves_cnt = 1;
+
+		return omap_hwmod_init(am35xx_hwmods);
+	} else {
+		return omap_hwmod_init(omap3xxx_hwmods);
+	}
 }
-- 
1.7.2.2

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Cousson, Benoit]

Hi Sanjeev,

On 2/25/2011 2:48 PM, Premi, Sanjeev wrote:
> This patch implements workaround to reuse the hwmods
> defined for OMAP3. Else, the master-slave dependency
> cascades into duplicating all of the hwmods.
>
> Without this workaround, the AM3517 EVM fails to boot
> due to kernel panic while initializing the SR hwmods.
> Until real solution is implemented, this workaround
> can be considered.
>
> Signed-off-by: Sanjeev Premi<premi@ti.com>

Could you try to put Paul and me in CC for such hwmod related email?
I almost missed it due to the increasing rate of email on l-o nowadays.

> ---
>   arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   66 +++++++++++++++++++++++++++-
>   1 files changed, 65 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 800eda4..c8854eb 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -1670,7 +1670,71 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
>   	NULL,
>   };
>
> +/**
> + * HWMODs specific to AM35x processors
> + * Though they are quite similar to OMAP34xx definitions,
> + * having separate array makes customization easy.
> + */
> +static __initdata struct omap_hwmod *am35xx_hwmods[] = {
> +	&omap3xxx_l3_main_hwmod,
> +	&omap3xxx_l4_core_hwmod,
> +	&omap3xxx_l4_per_hwmod,
> +	&omap3xxx_l4_wkup_hwmod,
> +	&omap3xxx_mpu_hwmod,
> +	&omap3xxx_wd_timer2_hwmod,
> +	&omap3xxx_uart1_hwmod,
> +	&omap3xxx_uart2_hwmod,
> +	&omap3xxx_uart3_hwmod,
> +	&omap3xxx_uart4_hwmod,
> +	&omap3xxx_i2c1_hwmod,
> +	&omap3xxx_i2c2_hwmod,
> +	&omap3xxx_i2c3_hwmod,
> +
> +	/* gpio class */
> +	&omap3xxx_gpio1_hwmod,
> +	&omap3xxx_gpio2_hwmod,
> +	&omap3xxx_gpio3_hwmod,
> +	&omap3xxx_gpio4_hwmod,
> +	&omap3xxx_gpio5_hwmod,
> +	&omap3xxx_gpio6_hwmod,
> +
> +	/* dma_system class*/
> +	&omap3xxx_dma_system_hwmod,
> +
> +	/* mcspi class */
> +	&omap34xx_mcspi1,
> +	&omap34xx_mcspi2,
> +	&omap34xx_mcspi3,
> +	&omap34xx_mcspi4,
> +	NULL,
> +};
> +
>   int __init omap3xxx_hwmod_init(void)
>   {
> -	return omap_hwmod_init(omap3xxx_hwmods);
> +	if (cpu_is_omap3505() || cpu_is_omap3517()) {
> +
> +		/* TODO: Find better way to get this done.
> +		 *
> +		 * AM35xx doesn't support smartreflex. This requires:
> +		 * 1) Removing related hwmods from the initialization list.
> +		 *    (done).
> +		 * 2) Removing omap3_l4_core__sr1 and omap3_l4_core__sr2
> +		 *    from omap3xxx_l4_core_slaves.
> +		 *    This, however, has cascading effect on all hwmods,
> +		 *    due to master-slave relations between these hwmods.
> +		 *
> +		 * Instead of duplicating contents of this file, updating
> +		 * the structure to restrict slave count to 1; and setting
> +		 * address of omap3_l4_core__sr1&  omap3_l4_core__sr2 to
> +		 * NULL should be a reasonable workaround.
> +		 */
> +		omap3xxx_l4_core_slaves[1] = NULL;
> +		omap3xxx_l4_core_slaves[2] = NULL;

OK, this is not your fault, but it appears that these entries are wrong 
in the original omap_hwmod_3xxx_data.c file.
The l4_core does not have any slave port toward smartreflex, this is the 
opposite, l4_core does have 2 master ports toward smartreflex.

Since these master ports from interconnect generated some annoying 
circular reference during OMAP4 generation, I simply removed them.
There are not used for the moment, and you can still build that relation 
using the slave port from the IP.

So by removing directly these relations in the original file, that 
should simplify your life. The patch do fix that is below.
I just built it so if you can give a try it will be nice.

Thanks,
Benoit

---
 From 09506eedef901af0fa19ddb48f486ce4ef353645 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Fri, 25 Feb 2011 17:46:33 +0100
Subject: [PATCH] OMAP3: hwmod data: Remove masters port links for 
interconnects.

Master ports from interconnect are generating some annoying circular
references that become tricky to handle if we have to dynamically
remove some IP on some variant platforms.
Since they are not used for the moment, and since we can still build
that relation using the reverse relation (slave port from the IP
toward master port of the interconnect), let remove them for the
moment like it is done on OMAP4.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   28 
----------------------------
  1 files changed, 0 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 7fa2dfb..0e7d43f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -463,26 +463,12 @@ static struct omap_hwmod_ocp_if 
*am35xx_usbhsotg_slaves[] = {
  /* Slave interfaces on the L4_CORE interconnect */
  static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
  	&omap3xxx_l3_main__l4_core,
-	&omap3_l4_core__sr1,
-	&omap3_l4_core__sr2,
-};
-
-/* Master interfaces on the L4_CORE interconnect */
-static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
-	&omap3xxx_l4_core__l4_wkup,
-	&omap3_l4_core__uart1,
-	&omap3_l4_core__uart2,
-	&omap3_l4_core__i2c1,
-	&omap3_l4_core__i2c2,
-	&omap3_l4_core__i2c3,
  };

  /* L4 CORE */
  static struct omap_hwmod omap3xxx_l4_core_hwmod = {
  	.name		= "l4_core",
  	.class		= &l4_hwmod_class,
-	.masters	= omap3xxx_l4_core_masters,
-	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_core_masters),
  	.slaves		= omap3xxx_l4_core_slaves,
  	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_core_slaves),
  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
@@ -494,18 +480,10 @@ static struct omap_hwmod_ocp_if 
*omap3xxx_l4_per_slaves[] = {
  	&omap3xxx_l3_main__l4_per,
  };

-/* Master interfaces on the L4_PER interconnect */
-static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[] = {
-	&omap3_l4_per__uart3,
-	&omap3_l4_per__uart4,
-};
-
  /* L4 PER */
  static struct omap_hwmod omap3xxx_l4_per_hwmod = {
  	.name		= "l4_per",
  	.class		= &l4_hwmod_class,
-	.masters	= omap3xxx_l4_per_masters,
-	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_per_masters),
  	.slaves		= omap3xxx_l4_per_slaves,
  	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_per_slaves),
  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
@@ -517,16 +495,10 @@ static struct omap_hwmod_ocp_if 
*omap3xxx_l4_wkup_slaves[] = {
  	&omap3xxx_l4_core__l4_wkup,
  };

-/* Master interfaces on the L4_WKUP interconnect */
-static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
-};
-
  /* L4 WKUP */
  static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
  	.name		= "l4_wkup",
  	.class		= &l4_hwmod_class,
-	.masters	= omap3xxx_l4_wkup_masters,
-	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
  	.slaves		= omap3xxx_l4_wkup_slaves,
  	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
-- 
1.7.0.4

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3691 bytes --]

Hi Benoît,

one question about this.

On Fri, 25 Feb 2011, Cousson, Benoit wrote:

> From 09506eedef901af0fa19ddb48f486ce4ef353645 Mon Sep 17 00:00:00 2001
> From: Benoit Cousson <b-cousson@ti.com>
> Date: Fri, 25 Feb 2011 17:46:33 +0100
> Subject: [PATCH] OMAP3: hwmod data: Remove masters port links for
> interconnects.
> 
> Master ports from interconnect are generating some annoying circular
> references that become tricky to handle if we have to dynamically
> remove some IP on some variant platforms.
> Since they are not used for the moment, and since we can still build
> that relation using the reverse relation (slave port from the IP
> toward master port of the interconnect), let remove them for the
> moment like it is done on OMAP4.
> 
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   28
> ----------------------------
>  1 files changed, 0 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 7fa2dfb..0e7d43f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -463,26 +463,12 @@ static struct omap_hwmod_ocp_if
> *am35xx_usbhsotg_slaves[] = {
>  /* Slave interfaces on the L4_CORE interconnect */
>  static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
>  	&omap3xxx_l3_main__l4_core,
> -	&omap3_l4_core__sr1,
> -	&omap3_l4_core__sr2,

Is there some reason why these SR OCP slaves are removed?

> -};
> -
> -/* Master interfaces on the L4_CORE interconnect */
> -static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
> -	&omap3xxx_l4_core__l4_wkup,
> -	&omap3_l4_core__uart1,
> -	&omap3_l4_core__uart2,
> -	&omap3_l4_core__i2c1,
> -	&omap3_l4_core__i2c2,
> -	&omap3_l4_core__i2c3,
>  };
> 
>  /* L4 CORE */
>  static struct omap_hwmod omap3xxx_l4_core_hwmod = {
>  	.name		= "l4_core",
>  	.class		= &l4_hwmod_class,
> -	.masters	= omap3xxx_l4_core_masters,
> -	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_core_masters),
>  	.slaves		= omap3xxx_l4_core_slaves,
>  	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_core_slaves),
>  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
> @@ -494,18 +480,10 @@ static struct omap_hwmod_ocp_if
> *omap3xxx_l4_per_slaves[] = {
>  	&omap3xxx_l3_main__l4_per,
>  };
> 
> -/* Master interfaces on the L4_PER interconnect */
> -static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[] = {
> -	&omap3_l4_per__uart3,
> -	&omap3_l4_per__uart4,
> -};
> -
>  /* L4 PER */
>  static struct omap_hwmod omap3xxx_l4_per_hwmod = {
>  	.name		= "l4_per",
>  	.class		= &l4_hwmod_class,
> -	.masters	= omap3xxx_l4_per_masters,
> -	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_per_masters),
>  	.slaves		= omap3xxx_l4_per_slaves,
>  	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_per_slaves),
>  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
> @@ -517,16 +495,10 @@ static struct omap_hwmod_ocp_if
> *omap3xxx_l4_wkup_slaves[] = {
>  	&omap3xxx_l4_core__l4_wkup,
>  };
> 
> -/* Master interfaces on the L4_WKUP interconnect */
> -static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
> -};
> -
>  /* L4 WKUP */
>  static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
>  	.name		= "l4_wkup",
>  	.class		= &l4_hwmod_class,
> -	.masters	= omap3xxx_l4_wkup_masters,
> -	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
>  	.slaves		= omap3xxx_l4_wkup_slaves,
>  	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
>  	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
> -- 
> 1.7.0.4
> 


- Paul

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Paul Walmsley]

On Thu, 3 Mar 2011, Paul Walmsley wrote:

> On Fri, 25 Feb 2011, Cousson, Benoit wrote:
> 
> >  static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
> >  	&omap3xxx_l3_main__l4_core,
> > -	&omap3_l4_core__sr1,
> > -	&omap3_l4_core__sr2,

Never mind, I see the issue now...


- Paul

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Cousson, Benoit]

Hi Paul,

On 3/4/2011 12:53 AM, Paul Walmsley wrote:
> On Thu, 3 Mar 2011, Paul Walmsley wrote:
>
>> On Fri, 25 Feb 2011, Cousson, Benoit wrote:
>>
>>>   static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
>>>   	&omap3xxx_l3_main__l4_core,
>>> -	&omap3_l4_core__sr1,
>>> -	&omap3_l4_core__sr2,
>
> Never mind, I see the issue now...

It was simply wrong as explained in the answer to Sanjeev.
I do agree that the changelog does not say anything about it, sorry 
about that.

BTW, do you want me to re-send that patch properly and not hidden in 
previous email thread with Sanjeev?

Thanks
Benoit

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1110 bytes --]

Hi Benoît,

On Fri, 4 Mar 2011, Cousson, Benoit wrote:

> On 3/4/2011 12:53 AM, Paul Walmsley wrote:
> > On Thu, 3 Mar 2011, Paul Walmsley wrote:
> > 
> > > On Fri, 25 Feb 2011, Cousson, Benoit wrote:
> > > 
> > > >   static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
> > > >   	&omap3xxx_l3_main__l4_core,
> > > > -	&omap3_l4_core__sr1,
> > > > -	&omap3_l4_core__sr2,
> > 
> > Never mind, I see the issue now...
> 
> It was simply wrong as explained in the answer to Sanjeev.
> I do agree that the changelog does not say anything about it, sorry about
> that.
> 
> BTW, do you want me to re-send that patch properly and not hidden in previous
> email thread with Sanjeev?

I guess the best thing to do would be to split that patch into two 
patches: one which drops the bogus omap3xxx_l4_core_slaves entries, and 
the other that removes the interconnect masters.  If you have the 
opportunity, it might be good to extend the latter to 2420/2430 also.
Am not sure that getting rid of these is a good idea in the long run, but 
am fine with doing it for now.


- Paul

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 519 bytes --]


Hi,

I just queued a patch to fix the SmartReflex problem.  It's the part that 
fixes the incorrect data:

    http://marc.info/?l=linux-omap&m=129972435510631&w=2

Benoît, if you are happy with it, care to send an Acked-by:?  Also, I 
guess we should revisit the other part of your patch at some point.

Sanjeev, now AM3517 shouldn't need that nasty hack any more.  I hope you 
won't need a separate array for AM35xx hwmods, either.  I guess we need to 
clean up the OMAP3 id.c revision bits.


- Paul

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Cousson, Benoit]

Salut Paul,

On 3/10/2011 3:37 AM, Paul Walmsley wrote:
>
> Hi,
>
> I just queued a patch to fix the SmartReflex problem.  It's the part that
> fixes the incorrect data:
>
>      http://marc.info/?l=linux-omap&m=129972435510631&w=2
>
> Benoît, if you are happy with it, care to send an Acked-by:?  Also, I
> guess we should revisit the other part of your patch at some point.

I'm almost fine with it, but if you do not want to remove the other 
masters ports of the interconnect, then you should move SR ocp_if from 
slaves to masters first, like it was supposed to be during the 
introduction of the SR data?

And then remove all the interconnect master list in a second patch?

Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Cousson, Benoit]

On 3/10/2011 9:39 AM, Cousson, Benoit wrote:
> Salut Paul,
> 
> On 3/10/2011 3:37 AM, Paul Walmsley wrote:
>>
>> Hi,
>>
>> I just queued a patch to fix the SmartReflex problem.  It's the part that
>> fixes the incorrect data:
>>
>>       http://marc.info/?l=linux-omap&m=129972435510631&w=2
>>
>> Benoît, if you are happy with it, care to send an Acked-by:?  Also, I
>> guess we should revisit the other part of your patch at some point.
> 
> I'm almost fine with it, but if you do not want to remove the other
> masters ports of the interconnect, then you should move SR ocp_if from
> slaves to masters first, like it was supposed to be during the
> introduction of the SR data?
> 
> And then remove all the interconnect master list in a second patch?

Please find below the 2 patches, rebased on top of the latest omap-for-linus.

git://gitorious.org/omap-pm/linux.git for_2.6.39/omap3_hwmod_data

Regards,
Benoit

---
From b9ccf8afe2d2eafe18f90d2925f8464313fe0b56 Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Thu, 10 Mar 2011 10:53:15 +0100
Subject: [PATCH 1/2] OMAP3: hwmod data: Fix incorrect SmartReflex -> L4 CORE interconnect links
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit d34427267186827dfd62bd8cf726601fffb22534 ("OMAP3: PM: Adding
smartreflex hwmod data") added data that claims that the L4 CORE has
two slave interfaces that originate from the SmartReflex modules,
omap3_l4_core__sr1 and omap3_l4_core__sr2.  But as those two data
structure records show, it's L4 CORE that has a master port towards
SR1 and SR2.
Move the incorrect data from slaves list to master list.

Based on a path by Paul Walmsley <paul@pwsan.com>

    https://patchwork.kernel.org/patch/623171/

That is based on a patch by Benoît Cousson <b-cousson@ti.com>:

    https://patchwork.kernel.org/patch/590561/

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Thara Gopinath <thara@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c4ca005..dec329f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -491,8 +491,6 @@ static struct omap_hwmod_ocp_if *am35xx_usbhsotg_slaves[] = {
 /* Slave interfaces on the L4_CORE interconnect */
 static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
 	&omap3xxx_l3_main__l4_core,
-	&omap3_l4_core__sr1,
-	&omap3_l4_core__sr2,
 };
 
 /* Master interfaces on the L4_CORE interconnect */
@@ -503,6 +501,8 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
 	&omap3_l4_core__i2c1,
 	&omap3_l4_core__i2c2,
 	&omap3_l4_core__i2c3,
+	&omap3_l4_core__sr1,
+	&omap3_l4_core__sr2,
 };
 
 /* L4 CORE */
-- 
1.7.0.4

---
From 478f478bc1a58f97f09fd2048488bafdfa9d8fce Mon Sep 17 00:00:00 2001
From: Benoit Cousson <b-cousson@ti.com>
Date: Fri, 25 Feb 2011 17:46:33 +0100
Subject: [PATCH 2/2] OMAP3: hwmod data: Remove masters port links for interconnects.

Master ports from interconnect are generating some annoying circular
references that become tricky to handle if we have to dynamically
remove some IP on some variant platforms.
Since they are not used for the moment, and since we can still build
that relation using the reverse relation (slave port from the IP
toward master port of the interconnect), let remove them for the
moment like it is done on OMAP4.

Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   28 ----------------------------
 1 files changed, 0 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index dec329f..229eb94 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -493,24 +493,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_core_slaves[] = {
 	&omap3xxx_l3_main__l4_core,
 };
 
-/* Master interfaces on the L4_CORE interconnect */
-static struct omap_hwmod_ocp_if *omap3xxx_l4_core_masters[] = {
-	&omap3xxx_l4_core__l4_wkup,
-	&omap3_l4_core__uart1,
-	&omap3_l4_core__uart2,
-	&omap3_l4_core__i2c1,
-	&omap3_l4_core__i2c2,
-	&omap3_l4_core__i2c3,
-	&omap3_l4_core__sr1,
-	&omap3_l4_core__sr2,
-};
-
 /* L4 CORE */
 static struct omap_hwmod omap3xxx_l4_core_hwmod = {
 	.name		= "l4_core",
 	.class		= &l4_hwmod_class,
-	.masters	= omap3xxx_l4_core_masters,
-	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_core_masters),
 	.slaves		= omap3xxx_l4_core_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_core_slaves),
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
@@ -522,18 +508,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_per_slaves[] = {
 	&omap3xxx_l3_main__l4_per,
 };
 
-/* Master interfaces on the L4_PER interconnect */
-static struct omap_hwmod_ocp_if *omap3xxx_l4_per_masters[] = {
-	&omap3_l4_per__uart3,
-	&omap3_l4_per__uart4,
-};
-
 /* L4 PER */
 static struct omap_hwmod omap3xxx_l4_per_hwmod = {
 	.name		= "l4_per",
 	.class		= &l4_hwmod_class,
-	.masters	= omap3xxx_l4_per_masters,
-	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_per_masters),
 	.slaves		= omap3xxx_l4_per_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_per_slaves),
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
@@ -545,16 +523,10 @@ static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_slaves[] = {
 	&omap3xxx_l4_core__l4_wkup,
 };
 
-/* Master interfaces on the L4_WKUP interconnect */
-static struct omap_hwmod_ocp_if *omap3xxx_l4_wkup_masters[] = {
-};
-
 /* L4 WKUP */
 static struct omap_hwmod omap3xxx_l4_wkup_hwmod = {
 	.name		= "l4_wkup",
 	.class		= &l4_hwmod_class,
-	.masters	= omap3xxx_l4_wkup_masters,
-	.masters_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_masters),
 	.slaves		= omap3xxx_l4_wkup_slaves,
 	.slaves_cnt	= ARRAY_SIZE(omap3xxx_l4_wkup_slaves),
 	.omap_chip	= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
-- 
1.7.0.4


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Paul Walmsley]

On Thu, 10 Mar 2011, Cousson, Benoit wrote:

> Please find below the 2 patches, rebased on top of the latest omap-for-linus.
> 
> git://gitorious.org/omap-pm/linux.git for_2.6.39/omap3_hwmod_data

Thanks, pulled for 2.6.39.


- Paul

RE: [RFC] AM35x: Workaround to use generic OMAP3 hwmods

[Premi, Sanjeev]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Thursday, March 10, 2011 8:08 AM
> To: Cousson, Benoit
> Cc: Premi, Sanjeev; linux-omap@vger.kernel.org
> Subject: Re: [RFC] AM35x: Workaround to use generic OMAP3 hwmods
> 
> 
> Hi,
> 
> I just queued a patch to fix the SmartReflex problem.  It's the part that
> fixes the incorrect data:
> 
>     http://marc.info/?l=linux-omap&m=129972435510631&w=2
> 
> Benoît, if you are happy with it, care to send an Acked-by:?  Also, I
> guess we should revisit the other part of your patch at some point.

[sp] Thanks. I will be able to try this fix next week.

> 
> Sanjeev, now AM3517 shouldn't need that nasty hack any more.  I hope you
> won't need a separate array for AM35xx hwmods, either.  I guess we need to
> clean up the OMAP3 id.c revision bits.

 [sp] Let me know what problem you see. I can take a look while trying this
     Patch

~sanjeev

> 
> 
> - Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html