[3/6] ARM: OMAP: DRA7xx: Make CAM clock domain SWSUP only
diff mbox

Message ID 20171012192719.15193-4-bparrot@ti.com
State New
Headers show

Commit Message

Benoit Parrot Oct. 12, 2017, 7:27 p.m. UTC
HWSUP on this domain is only working when VIP1 probes.
If only VIP2 on DRA74x or CAL on DRA72x probes the domain does
not get enabled. This might indicates an issue in the HW Auto
state-machine for this domain.

Work around is to set the CAM domain to use SWSUP only.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
---
 arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Tony Lindgren Oct. 13, 2017, 5:01 p.m. UTC | #1
* Benoit Parrot <bparrot@ti.com> [171012 12:29]:
> HWSUP on this domain is only working when VIP1 probes.
> If only VIP2 on DRA74x or CAL on DRA72x probes the domain does
> not get enabled. This might indicates an issue in the HW Auto
> state-machine for this domain.
>
> Work around is to set the CAM domain to use SWSUP only.

Hmm this you might get fixed automatically by configuring the
parent interconnect target module to use "ti,sysc-omap4" and
adding VIP1 and VIP2 as children to it.

The reason why I suspect it will fix the issue is because
with the parent being "ti,sysc-omap4" with "ti,hwmods" being
in that parent node too, you automatically get PM runtime
refcounting keep the parent active for either child.

Maybe give it a try against today's Linux next and see for
example how it was done for musb:

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

Just use "ti,sysc-omap2" for type1 and "ti,sysc-omap4"
for type2.

Regards,

Tony
--
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
Benoit Parrot Oct. 13, 2017, 5:59 p.m. UTC | #2
Tony Lindgren <tony@atomide.com> wrote on Fri [2017-Oct-13 10:01:13 -0700]:
> * Benoit Parrot <bparrot@ti.com> [171012 12:29]:
> > HWSUP on this domain is only working when VIP1 probes.
> > If only VIP2 on DRA74x or CAL on DRA72x probes the domain does
> > not get enabled. This might indicates an issue in the HW Auto
> > state-machine for this domain.
> >
> > Work around is to set the CAM domain to use SWSUP only.
> 
> Hmm this you might get fixed automatically by configuring the
> parent interconnect target module to use "ti,sysc-omap4" and
> adding VIP1 and VIP2 as children to it.
> 
> The reason why I suspect it will fix the issue is because
> with the parent being "ti,sysc-omap4" with "ti,hwmods" being
> in that parent node too, you automatically get PM runtime
> refcounting keep the parent active for either child.
> 
> Maybe give it a try against today's Linux next and see for
> example how it was done for musb:
> 
> https://patchwork.kernel.org/patch/9978783/
> 
> Just use "ti,sysc-omap2" for type1 and "ti,sysc-omap4"
> for type2.

Hmm interesting, I'll give that a try and if it fixes it.

Benoit

> 
> Regards,
> 
> Tony
--
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
Tony Lindgren Oct. 13, 2017, 6:03 p.m. UTC | #3
* Benoit Parrot <bparrot@ti.com> [171013 11:01]:
> Tony Lindgren <tony@atomide.com> wrote on Fri [2017-Oct-13 10:01:13 -0700]:
> > * Benoit Parrot <bparrot@ti.com> [171012 12:29]:
> > > HWSUP on this domain is only working when VIP1 probes.
> > > If only VIP2 on DRA74x or CAL on DRA72x probes the domain does
> > > not get enabled. This might indicates an issue in the HW Auto
> > > state-machine for this domain.
> > >
> > > Work around is to set the CAM domain to use SWSUP only.
> > 
> > Hmm this you might get fixed automatically by configuring the
> > parent interconnect target module to use "ti,sysc-omap4" and
> > adding VIP1 and VIP2 as children to it.
> > 
> > The reason why I suspect it will fix the issue is because
> > with the parent being "ti,sysc-omap4" with "ti,hwmods" being
> > in that parent node too, you automatically get PM runtime
> > refcounting keep the parent active for either child.
> > 
> > Maybe give it a try against today's Linux next and see for
> > example how it was done for musb:
> > 
> > https://patchwork.kernel.org/patch/9978783/
> > 
> > Just use "ti,sysc-omap2" for type1 and "ti,sysc-omap4"
> > for type2.
> 
> Hmm interesting, I'll give that a try and if it fixes it.

OK great. Note that you need to manually apply "[PATCH] ARM:
head-common.S: Clear lr before jumping to start_kernel()" on
today's next and make sure CONFIG_DRM and CONFIG_DRM_KMS_HELPER
are built-in and not modules if using them.

Regards,

Tony
--
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

Patch
diff mbox

diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c b/arch/arm/mach-omap2/clockdomains7xx_data.c
index 67ebff829cf2..dd37efa2c652 100644
--- a/arch/arm/mach-omap2/clockdomains7xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
@@ -609,7 +609,7 @@  static struct clockdomain cam_7xx_clkdm = {
 	.dep_bit	  = DRA7XX_CAM_STATDEP_SHIFT,
 	.wkdep_srcs	  = cam_wkup_sleep_deps,
 	.sleepdep_srcs	  = cam_wkup_sleep_deps,
-	.flags		  = CLKDM_CAN_HWSUP_SWSUP,
+	.flags		  = CLKDM_CAN_SWSUP,
 };
 
 static struct clockdomain l4per_7xx_clkdm = {