diff mbox

[PATCH/RFC,v2,00/11] ARM/arm64: renesas: Add SYSC PM Domain DT Support

Message ID 2939018.LGDkKsjeJ3@avalon (mailing list archive)
State New, archived
Headers show

Commit Message

Laurent Pinchart Feb. 28, 2016, 3:04 p.m. UTC
Hi Geert,

On Sunday 28 February 2016 09:55:32 Geert Uytterhoeven wrote:
> On Sat, Feb 27, 2016 at 2:53 AM, Laurent Pinchart wrote:
> > After rebasing this series on top of Simon's latest devel branch, I'm
> > experiencing hard system freezes when using the VSP.
> 
> Is this due to the rebasing? Did it work in
> renesas-drivers-2016-02-16-v4.5-rc4 or renesas-drivers-2016-02-23-v4.5-rc5?

I thought it was, but after further investigations I've been unable to get it
working at all even on my older branches, so I think the problem has always
been there.

> > What makes the problem curious is that PM runtime works fine when the VSP
> > instances are probed, the A3VP power domain is turned on and off correctly
> > for each instance. However, after booting the system, if I try to RPM
> > resume the device, the system hangs.
> > 
> > I've traced this (using printk debugging) down to the SYSCISCR write in
> > rcar_sysc_power(). The value written is 0x00000200, which corresponds to
> > the A3VP power domain, and the resume request completion wait loop
> > doesn't time out.
> 
> So the second write to SYSCISCR in that function locks up the system?

Correct, and only after the kernel has booted, there's a bunch of calls to
rcar_sysc_power() to enable/disable the A3VP power domain at boot time when
the vsp devices are probed, and those don't cause any issue.

> > Does this ring any bell ? Do you have a more recent version of this patch
> > series that I could try ?
> 
> No clue, and no more recent version available yet.
> 
> What do I need to reproduce this?

Compile

git://linuxtv.org/pinchartl/media.git drm/du/vsp1-kms/boards

(.config attached), boot it, and run

# cat /dev/video0

You can apply the following patch to see what's going on.



On my system it prints the following messages during boot when probing the vsp
instances.

[    0.528433] rcar_sysc_power(A3VP, off)
[    0.535317] rcar_sysc_power: will write to SYSISCR
[    0.547713] rcar_sysc_power: wrote to SYSISCR
[    0.549910] rcar_sysc_power(A3VP, on)
[    0.556759] rcar_sysc_power: will write to SYSISCR
[    0.569155] rcar_sysc_power: wrote to SYSISCR
[    0.571386] rcar_sysc_power(A3VP, off)
[    0.578270] rcar_sysc_power: will write to SYSISCR
[    0.590665] rcar_sysc_power: wrote to SYSISCR
[    0.592857] rcar_sysc_power(A3VP, on)
[    0.599698] rcar_sysc_power: will write to SYSISCR
[    0.612094] rcar_sysc_power: wrote to SYSISCR
[    0.614310] rcar_sysc_power(A3VP, off)
[    0.621197] rcar_sysc_power: will write to SYSISCR
[    0.633592] rcar_sysc_power: wrote to SYSISCR
[    0.635783] rcar_sysc_power(A3VP, on)
[    0.642625] rcar_sysc_power: will write to SYSISCR
[    0.655020] rcar_sysc_power: wrote to SYSISCR
[    0.657237] rcar_sysc_power(A3VP, off)
[    0.664120] rcar_sysc_power: will write to SYSISCR
[    0.676515] rcar_sysc_power: wrote to SYSISCR
[    0.678706] rcar_sysc_power(A3VP, on)
[    0.685550] rcar_sysc_power: will write to SYSISCR
[    0.697945] rcar_sysc_power: wrote to SYSISCR
[    0.700133] rcar_sysc_power(A3VP, off)
[    0.707015] rcar_sysc_power: will write to SYSISCR
[    0.719410] rcar_sysc_power: wrote to SYSISCR
[    0.721736] rcar_sysc_power(A3VP, on)
[    0.728583] rcar_sysc_power: will write to SYSISCR
[    0.740978] rcar_sysc_power: wrote to SYSISCR
[    0.743213] rcar_sysc_power(A3VP, off)
[    0.750099] rcar_sysc_power: will write to SYSISCR
[    0.762495] rcar_sysc_power: wrote to SYSISCR
[    0.765445] rcar_sysc_power(A3VP, on)
[    0.772294] rcar_sysc_power: will write to SYSISCR
[    0.784689] rcar_sysc_power: wrote to SYSISCR
[    0.786897] rcar_sysc_power(A3VP, off)
[    0.793783] rcar_sysc_power: will write to SYSISCR
[    0.806178] rcar_sysc_power: wrote to SYSISCR
[    0.808369] rcar_sysc_power(A3VP, on)
[    0.815211] rcar_sysc_power: will write to SYSISCR
[    0.827606] rcar_sysc_power: wrote to SYSISCR
[    0.829845] rcar_sysc_power(A3VP, off)
[    0.836733] rcar_sysc_power: will write to SYSISCR
[    0.849128] rcar_sysc_power: wrote to SYSISCR
[    0.851985] rcar_sysc_power(A3VP, on)
[    0.858829] rcar_sysc_power: will write to SYSISCR
[    0.871224] rcar_sysc_power: wrote to SYSISCR
[    0.873435] rcar_sysc_power(A3VP, off)
[    0.880323] rcar_sysc_power: will write to SYSISCR
[    0.892719] rcar_sysc_power: wrote to SYSISCR
[    0.894911] rcar_sysc_power(A3VP, on)
[    0.901772] rcar_sysc_power: will write to SYSISCR
[    0.914168] rcar_sysc_power: wrote to SYSISCR
[    0.916395] rcar_sysc_power(A3VP, off)
[    0.923278] rcar_sysc_power: will write to SYSISCR
[    0.935673] rcar_sysc_power: wrote to SYSISCR
[    0.938275] rcar_sysc_power(A3VP, on)
[    0.945129] rcar_sysc_power: will write to SYSISCR
[    0.957525] rcar_sysc_power: wrote to SYSISCR
[    0.959729] rcar_sysc_power(A3VP, off)
[    0.966612] rcar_sysc_power: will write to SYSISCR
[    0.979008] rcar_sysc_power: wrote to SYSISCR
[    0.981204] rcar_sysc_power(A3VP, on)
[    0.988044] rcar_sysc_power: will write to SYSISCR
[    1.000440] rcar_sysc_power: wrote to SYSISCR
[    1.002660] rcar_sysc_power(A3VP, off)
[    1.009546] rcar_sysc_power: will write to SYSISCR
[    1.021941] rcar_sysc_power: wrote to SYSISCR
[    1.024540] rcar_sysc_power(A3VP, on)
[    1.031383] rcar_sysc_power: will write to SYSISCR
[    1.043778] rcar_sysc_power: wrote to SYSISCR
[    1.045980] rcar_sysc_power(A3VP, off)
[    1.052865] rcar_sysc_power: will write to SYSISCR
[    1.065261] rcar_sysc_power: wrote to SYSISCR
[    1.067450] rcar_sysc_power(A3VP, on)
[    1.074292] rcar_sysc_power: will write to SYSISCR
[    1.086687] rcar_sysc_power: wrote to SYSISCR
[    1.088910] rcar_sysc_power(A3VP, off)
[    1.095792] rcar_sysc_power: will write to SYSISCR
[    1.108187] rcar_sysc_power: wrote to SYSISCR
[    1.110781] rcar_sysc_power(A3VP, on)
[    1.117628] rcar_sysc_power: will write to SYSISCR
[    1.130023] rcar_sysc_power: wrote to SYSISCR
[    1.132224] rcar_sysc_power(A3VP, off)
[    1.139106] rcar_sysc_power: will write to SYSISCR
[    1.151501] rcar_sysc_power: wrote to SYSISCR


When I cat /dev/video0 I get the following messages in the kernel log

/ # cat /dev/video0
[    4.673226] rcar_sysc_power(A3VP, on)
[    4.680816] rcar_sysc_power: will write to SYSISCR

and the system then freezes.

Comments

Laurent Pinchart Feb. 28, 2016, 7:26 p.m. UTC | #1
Hi Geert,

Here's an update.

On Sunday 28 February 2016 17:04:47 Laurent Pinchart wrote:
> On Sunday 28 February 2016 09:55:32 Geert Uytterhoeven wrote:
> > On Sat, Feb 27, 2016 at 2:53 AM, Laurent Pinchart wrote:
> >> After rebasing this series on top of Simon's latest devel branch, I'm
> >> experiencing hard system freezes when using the VSP.
> > 
> > Is this due to the rebasing? Did it work in
> > renesas-drivers-2016-02-16-v4.5-rc4 or
> > renesas-drivers-2016-02-23-v4.5-rc5?
> 
> I thought it was, but after further investigations I've been unable to get
> it working at all even on my older branches, so I think the problem has
> always been there.
> 
> >> What makes the problem curious is that PM runtime works fine when the
> >> VSP instances are probed, the A3VP power domain is turned on and off
> >> correctly for each instance. However, after booting the system, if I try
> >> to RPM resume the device, the system hangs.
> >> 
> >> I've traced this (using printk debugging) down to the SYSCISCR write in
> >> rcar_sysc_power(). The value written is 0x00000200, which corresponds to
> >> the A3VP power domain, and the resume request completion wait loop
> >> doesn't time out.
> > 
> > So the second write to SYSCISCR in that function locks up the system?
> 
> Correct, and only after the kernel has booted, there's a bunch of calls to
> rcar_sysc_power() to enable/disable the A3VP power domain at boot time when
> the vsp devices are probed, and those don't cause any issue.

I've investigated the problem further, and realized the freeze was caused by 
writing to the PWRONCR_OFFS register, not the SYSCISCR register. It doesn't 
occur immediately though, I had to put longer delays between the register 
writes to locate the faulty one.

Furthermore, I've also realized that commenting out the A3SH power domain from 
DT seemed to fix the problem. Unused power domains are powered off at the end 
of the boot sequence, and it looks like powering A3SH there somehow messes up 
the SYSC and hangs the system the next time a power domain is turned on.

Given that the latest version of the datasheet doesn't document the A3SH power 
domain it would probably be a good idea to remove it, at least until we can 
get more information from the hardware team.
diff mbox

Patch

diff --git a/drivers/soc/renesas/pm-rcar.c b/drivers/soc/renesas/pm-rcar.c
index d1bf8c231540..4a5f00d7f84d 100644
--- a/drivers/soc/renesas/pm-rcar.c
+++ b/drivers/soc/renesas/pm-rcar.c
@@ -139,6 +139,9 @@  static int rcar_sysc_power(const struct rcar_sysc_ch *sysc_ch, bool on)
 	int ret = 0;
 	int k;
 
+	if (sysc_ch->isr_bit == 9)
+		printk(KERN_INFO "%s(A3VP, %s)\n", __func__, on ? "on" : "off");
+
 	spin_lock_irqsave(&rcar_sysc_lock, flags);
 
 	iowrite32(isr_mask, rcar_sysc_base + SYSCISCR);
@@ -172,7 +175,16 @@  static int rcar_sysc_power(const struct rcar_sysc_ch *sysc_ch, bool on)
 	if (k == SYSCISR_RETRIES)
 		ret = -EIO;
 
+	if (sysc_ch->isr_bit == 9) {
+		udelay(5000);
+		printk(KERN_INFO "%s: will write to SYSISCR\n", __func__);
+		udelay(5000);
+	}
 	iowrite32(isr_mask, rcar_sysc_base + SYSCISCR);
+	if (sysc_ch->isr_bit == 9) {
+		udelay(5000);
+		printk(KERN_INFO "%s: wrote to SYSISCR\n", __func__);
+	}
 
  out:
 	spin_unlock_irqrestore(&rcar_sysc_lock, flags);