From: Karl Beldan <karl.beldan@gmail.com>
To: Mark Brown <broonie@sirena.org.uk>
Cc: Eric Miao <eric.miao@marvell.com>,
alsa-devel@alsa-project.org,
Russell King <linux@arm.linux.org.uk>,
linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>,
Matthieu Dumont <matthieu.dumont@mobile-devices.fr>
Subject: Re: [PATCH 2/4] pxa2xx-i2s: Handle SACR1_DRPL and SACR1_DREC separately
Date: Tue, 12 May 2009 11:59:03 +0200 [thread overview]
Message-ID: <4A094867.2010600@gmail.com> (raw)
In-Reply-To: <20090512085838.GB29889@sirena.org.uk>
Mark Brown wrote:
> On Tue, May 12, 2009 at 12:00:33AM +0200, Karl Beldan wrote:
>
>> Then it is perfectly normal since reset enables both REC and RPL, 2/4 needs 1/4.
>> The current tree disables the clocks anytime one function is disabled.
>
> That doesn't seem to tie up - I can see the initialisation changing the
> behaviour on first run but it seems surprising that this should happen
> on subsequent runs too. Alternatively, is your initialisation patch
> safe to apply by itself?
>
Well 2/4 stops the clocks only if both REC and RPL are disabled.
Without 1/4 you end up with REC enabled at startup.
In a scenario where you have never used REC you end up RPLing with REC always on.
REC being on at shutdown(),clocks won't stop.
>> I resent 1/4 and will make it 1/5 with the whole serie once everything is Clear.
>
> As previously discussed you need to rework the patch to not do the reset
> on initial probe not when the module is loaded, you need to address this
> rather than reposting.
>
The patch in question is moving the reset in probe rather than module init - with comment updated.
What is wrong ?
> I'll try to find time to re-review the series but I'm going to need to
> sit down with the datasheet and check this in much more detail.
For 1/4 and 2/4 there should not be great need, Really.
--
Karl
next prev parent reply other threads:[~2009-05-12 9:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-07 23:53 [PATCH 2/4] pxa2xx-i2s: Handle SACR1_DRPL and SACR1_DREC separately Karl Beldan
2009-05-08 10:42 ` Mark Brown
2009-05-08 19:24 ` Karl Beldan
2009-05-11 19:05 ` Mark Brown
2009-05-11 19:43 ` Karl Beldan
2009-05-11 21:07 ` Mark Brown
2009-05-11 22:00 ` Karl Beldan
2009-05-12 8:58 ` Mark Brown
2009-05-12 9:59 ` Karl Beldan [this message]
2009-05-12 10:32 ` Mark Brown
2009-05-12 12:38 ` Karl Beldan
2009-05-12 14:34 ` Mark Brown
2009-05-12 16:02 ` Mark Brown
2009-05-12 17:43 ` Karl Beldan
2009-05-12 21:50 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2009-05-13 20:04 Karl Beldan
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=4A094867.2010600@gmail.com \
--to=karl.beldan@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@sirena.org.uk \
--cc=eric.miao@marvell.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux@arm.linux.org.uk \
--cc=matthieu.dumont@mobile-devices.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.