From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Mark Brown <broonie@sirena.org.uk>
Cc: alsa-devel@alsa-project.org, eric miao <eric.y.miao@gmail.com>,
linux-arm-kernel@lists.arm.linux.org.uk,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: SoC pxa2xx-ac97 + wm9705 + touchscreen suspend/resume
Date: Tue, 31 Mar 2009 19:37:55 +0100 [thread overview]
Message-ID: <20090331183755.GA27451@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20090331103048.GC11800@sirena.org.uk>
On Tue, Mar 31, 2009 at 11:30:48AM +0100, Mark Brown wrote:
> On Mon, Mar 30, 2009 at 11:37:20PM +0100, Russell King - ARM Linux wrote:
> > 1. when suspend occurs, we turn the AC97 link off by setting the
> > GCR_ACLINK_OFF bit, and stopping the functional units clock.
>
> > Setting GCR to '2' (to release cold reset) using devmem2 starts things
> > moving again, shutting up this warning.
>
> Hrm, I suspect this is a result of the second issue.
>
> > 2. maybe as a result of the above problem, the wm9705 touchscreen
> > driver doesn't reinitialize, causing loss of touchscreen. Unbinding
> > and re-binding the driver restores the touchscreen, but with a very
> > long lag between touching the screen and it being registered.
>
> > I bring (2) up because I notice that the resume actions in (1) are
> > deferred. Given that codecs have shared functions (such as
> > touchscreens) need to access the codec from their own resume
> > functions, how can this deferral be safe?
>
> Other multi-function devices shouldn't have this problem since they
> will not be relying on ASoC to resume their control interface (most
> likely they will be using MFD to share the device). It's not safe for
> AC97 devices, though.
>
> We only really need the deferral for non-AC97 devices - it's there since
> some I2C buses are very slow and non-AC97 codecs often have large
> numbers of registers to restore and require delays to bring the codec up
> cleanly leading to a substantial impact on overall resume time.
>
> Could you let me know if the patch below works, please? I've not fully
> tested it myself yet.
I don't think this is the complete story. Sometime between 2.6.27 and
2.6.29, the structure below /sys/devices/platform/soc-audio changed
(the ac97 codec moved to the top level.)
This clearly isn't right. We want to resume the host side of the link
first, followed by the AC97 codec, followed by any sub drivers next.
The way to guarantee that is to ensure that the parenting of the devices
is correct.
In other words, this structure:
/sys/devices/platform/soc-audio/ac97-device/sub-devices-eg-touchscreen
I'm not sure where wm9705-ts currently appears in the device tree (I
need to resume the device, and sort out its resume quirks so that I can
see the sysfs layout... but I'm absolutely sure that the ac97 device
appears at /sys/devices/platform/ which is definitely wrong.
next prev parent reply other threads:[~2009-03-31 18:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 22:37 SoC pxa2xx-ac97 + wm9705 + touchscreen suspend/resume Russell King - ARM Linux
2009-03-31 10:30 ` Mark Brown
2009-03-31 18:37 ` Russell King - ARM Linux [this message]
2009-03-31 19:15 ` Mark Brown
2009-04-02 11:55 ` Russell King - ARM Linux
2009-04-02 12:33 ` Mark Brown
2009-04-01 19:27 ` Mark Brown
2009-04-02 12:13 ` Russell King - ARM Linux
2009-04-02 12:18 ` Mark Brown
2009-04-02 12:38 ` Russell King - ARM Linux
2009-04-02 13:31 ` Russell King - ARM Linux
2009-04-02 14:12 ` Mark Brown
2009-04-02 14:40 ` Russell King - ARM Linux
2009-04-02 14:53 ` Mark Brown
2009-04-02 15:09 ` Russell King - ARM Linux
2009-04-02 15:22 ` Mark Brown
2009-04-18 9:11 ` Russell King - ARM Linux
2009-04-18 9:47 ` Mark Brown
2009-04-02 16:13 ` Ian Molton
2009-03-31 15:51 ` Liam Girdwood
2009-03-31 20:58 ` Ian Molton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090331183755.GA27451@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@sirena.org.uk \
--cc=eric.y.miao@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=lrg@slimlogic.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox