[alsa-devel] AC97 reset fail after suspend
Hi,
I've got following error on Palm LifeDrive and PalmTX after suspend & resume:
pxa2xx_ac97_try_warm_reset: warm reset timeout (GSR=0x0) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x0) pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x44) WM9712 AC97 reset failed could not reset AC97 codec
That completely disable whole AC97 communication, so touchscreen, sound and battery doesn't work any longer.
I also tried this with Treo680 (code will be sent soon). HW is very similar, only codec is different - LD/T5/TX use WM9712, Treo680 use WM9713. On Treo680 there is no problem with that.
Thanks for any hint about that.
Tomas 'Sleep_Walker' Cech
Attaching config for LD/TX and dmesg output.
On Friday 08 of May 2009 01:48:19 Tomas 'Sleep_Walker' Cech wrote:
Hi,
I've got following error on Palm LifeDrive and PalmTX after suspend & resume:
pxa2xx_ac97_try_warm_reset: warm reset timeout (GSR=0x0) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x0) pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x44) WM9712 AC97 reset failed could not reset AC97 codec
That completely disable whole AC97 communication, so touchscreen, sound and battery doesn't work any longer.
I also tried this with Treo680 (code will be sent soon). HW is very similar, only codec is different - LD/T5/TX use WM9712, Treo680 use WM9713. On Treo680 there is no problem with that.
Thanks for any hint about that.
Tomas 'Sleep_Walker' Cech
Attaching config for LD/TX and dmesg output.
added LAK in CC
On Fri, May 08, 2009 at 01:48:19AM +0200, Tomas 'Sleep_Walker' Cech wrote:
I also tried this with Treo680 (code will be sent soon). HW is very similar, only codec is different - LD/T5/TX use WM9712, Treo680 use WM9713. On Treo680 there is no problem with that.
Do you mean that suspend and resume work on the Treo680?
Have you tried the non-ASoC AC97 driver?
Dne pátek 08 Květen 2009 20:04:58 Mark Brown napsal(a):
On Fri, May 08, 2009 at 01:48:19AM +0200, Tomas 'Sleep_Walker' Cech wrote:
I also tried this with Treo680 (code will be sent soon). HW is very similar, only codec is different - LD/T5/TX use WM9712, Treo680 use WM9713. On Treo680 there is no problem with that.
Do you mean that suspend and resume work on the Treo680?
Yes.
Have you tried the non-ASoC AC97 driver?
Yes. Same problem.
Tomas Cech
On Fri, May 08, 2009 at 10:57:37PM +0200, Tomas 'Sleep_Walker' Cech wrote:
Dne pátek 08 Květen 2009 20:04:58 Mark Brown napsal(a):
Have you tried the non-ASoC AC97 driver?
Yes. Same problem.
OK. If this worked in the past would it be possible for you to try running a git bisect to identify where things broke? I can't see anything relevant that jumps out as being relevant in the AC97 driver logs.
On Friday 08 of May 2009 01:48:19 Tomas 'Sleep_Walker' Cech wrote:
Hi,
I've got following error on Palm LifeDrive and PalmTX after suspend & resume:
pxa2xx_ac97_try_warm_reset: warm reset timeout (GSR=0x0) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x0) pxa2xx_ac97_try_cold_reset: cold reset timeout (GSR=0x44) pxa2xx_ac97_read: read error (ac97_reg=0 GSR=0x44) WM9712 AC97 reset failed could not reset AC97 codec
That completely disable whole AC97 communication, so touchscreen, sound and battery doesn't work any longer.
I also tried this with Treo680 (code will be sent soon). HW is very similar, only codec is different - LD/T5/TX use WM9712, Treo680 use WM9713. On Treo680 there is no problem with that.
Thanks for any hint about that.
Tomas 'Sleep_Walker' Cech
Attaching config for LD/TX and dmesg output.
The following patch fixes the issue and should be correct. It's indeed a regression that's not in wm9713, but is in wm9712. Please consider applying.
Hi,
The following patch fixes the issue and should be correct. It's indeed a regression that's not in wm9713, but is in wm9712. Please consider applying.
I already tried to add these lines, but it didn't help. I can't confirm that problem is gone. But I agree that this patch should be applied.
Tomas Cech
On Thu, May 14, 2009 at 03:57:35AM +0200, Marek Vasut wrote:
The following patch fixes the issue and should be correct. It's indeed a regression that's not in wm9713, but is in wm9712. Please consider applying.
Please CC maintainers on patches!
The following patch fixes problem with wm9712 codec being unable to resume from sleep because it doesn't respond after AC97 port was coldreseted (which is done in case the warmreset wasn't successful). The solution uses similar approach as wm9713, that is, do one more warmreset after coldreset.
Are you sure this is required? The WM9713 needs this because the default state on reset is not to clock the AC97 link, a warm reset is needed to start the link. I'll need to check but IIRC the WM9712 runs the link by default and I can't see any changes to this behaviour in the driver changelog.
On Thursday 14 of May 2009 14:32:41 Mark Brown wrote:
On Thu, May 14, 2009 at 03:57:35AM +0200, Marek Vasut wrote:
The following patch fixes the issue and should be correct. It's indeed a regression that's not in wm9713, but is in wm9712. Please consider applying.
Please CC maintainers on patches!
Sorry, it was 4am when I sent this patch, I was a little tired.
The following patch fixes problem with wm9712 codec being unable to resume from sleep because it doesn't respond after AC97 port was coldreseted (which is done in case the warmreset wasn't successful). The solution uses similar approach as wm9713, that is, do one more warmreset after coldreset.
Are you sure this is required? The WM9713 needs this because the default state on reset is not to clock the AC97 link, a warm reset is needed to start the link. I'll need to check but IIRC the WM9712 runs the link by default and I can't see any changes to this behaviour in the driver changelog.
Well without this, the codec doesn't kick in (reading the registers returns all zeros) so I assume that's the same issue as on wm9713.
On Thu, May 14, 2009 at 03:51:37PM +0200, Marek Vasut wrote:
On Thursday 14 of May 2009 14:32:41 Mark Brown wrote:
needed to start the link. I'll need to check but IIRC the WM9712 runs the link by default and I can't see any changes to this behaviour in the driver changelog.
Well without this, the codec doesn't kick in (reading the registers returns all zeros) so I assume that's the same issue as on wm9713.
OK, I've checked - there is actually a resistor strap option on the CODEC to control if the device powers on with the AC97 link enabled or disabled by default. This must be the first Linux device that chooses the second option, I guess. A version of your patch would be good, but it should check for warm reset support in the AC97 controller before it tries to use it since the chip won't always need the warm reset.
On Thu, May 14, 2009 at 03:25:10PM +0100, Mark Brown wrote:
the second option, I guess. A version of your patch would be good, but it should check for warm reset support in the AC97 controller before it tries to use it since the chip won't always need the warm reset.
Oops, it does already - I'll apply it with an updated changelgo explaining what's going on.
participants (4)
-
Marek Vasut -
Mark Brown -
Mark Brown -
Tomas 'Sleep_Walker' Cech