From: Karl Beldan <karl.beldan@gmail.com>
To: Mark Brown <broonie@sirena.org.uk>
Cc: alsa-devel@alsa-project.org,
Russell King <linux@arm.linux.org.uk>,
Matthieu Dumont <matthieu.dumont@mobile-devices.fr>,
liam.girdwood@wolfsonmicro.com, Eric Miao <eric.miao@marvell.com>,
linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH 2/4] pxa2xx-i2s: Handle SACR1_DRPL and SACR1_DREC separately
Date: Tue, 12 May 2009 14:38:19 +0200 [thread overview]
Message-ID: <4A096DBB.1080909@gmail.com> (raw)
In-Reply-To: <20090512103243.GH29889@sirena.org.uk>
Mark Brown wrote:
> On Tue, May 12, 2009 at 11:59:03AM +0200, Karl Beldan wrote:
>> Mark Brown wrote:
>
>>> 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.
>
> Yet they are being stopped by something...
>
You said that clocks are NOT stopped when applying patch 2/4 without 1/4.
I detailed a fairly likely code path.
>>> 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 ?
>
> A repost is where you send exactly the same thing again. When you say
> you're reposting something it means you've not made any changes; if you
> say that's what you're doing and your code has problems that need to be
> fixed it's fairly obvious that all the previous comments are going to
> continue to apply.
>
When I said I 'resent' it, my meaning was not to let you understand that I did not modify it obviously.
>>> 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.
>
> There's been enough stuff with the series that I've got a few alarm
> bells ringing, if only with obscure relationships between the patches.
I could say the same about the current status and handling but I will ask you to point precise points instead, please.
As of the current status of the driver there is not even full duplex, maintainance is likewise.
The patches I am sending are quite easy to discuss.
Could you point what is wrong in the code or comments ?
Nitpicking about "A repost is where you send exactly the same thing again." and talking so much about
pb applying 2/4 without 1/4 really sucks.
I said and am saying my patches improve greatly the code quality/functionnality, if you think otherwise, give tangible reasons and I'll be really happy to discuss/rework/abandon the patches.
Since I have no feedback from Maintainers, I am pinging the original author hoping I won't disturb too much.
--
Karl
next prev parent reply other threads:[~2009-05-12 12:38 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
2009-05-12 10:32 ` Mark Brown
2009-05-12 12:38 ` Karl Beldan [this message]
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=4A096DBB.1080909@gmail.com \
--to=karl.beldan@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@sirena.org.uk \
--cc=eric.miao@marvell.com \
--cc=liam.girdwood@wolfsonmicro.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.