| Message ID | 20171012192719.15193-4-bparrot@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* 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
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
* 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
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 = {
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(-)