From: Mark Brown <broonie@kernel.org>
To: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: alsa-devel@alsa-project.org, linaro-kernel@lists.linaro.org,
Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH] ASoC: si476x: Remove custom register I/O implementation
Date: Thu, 26 Sep 2013 20:43:50 +0100 [thread overview]
Message-ID: <20130926194350.GU19304@sirena.org.uk> (raw)
In-Reply-To: <CAHQ1cqG2Uwhw3M933OPwsX1R=ZrpdmKjsy_DYTL_+CpfQvdVag@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1519 bytes --]
On Thu, Sep 26, 2013 at 12:33:33PM -0700, Andrey Smirnov wrote:
> On Thu, Sep 26, 2013 at 11:34 AM, Mark Brown <broonie@kernel.org> wrote:
> > A better and more idiomatic approach would be to have the MFD manage the
> > cache, making the device cache only when it powers things down. This also
> > allows ASoC to use the standard regmap helpers for the device which helps
> Correct me if my understanding is wrong but using standard helper
> function would mean using hw_write and hw_read from soc-io.c. Looking
> at the source code of those functions I don't believe the are
> performing any sort of locking(once again I may be wrong) and rely on
> regmap_* implementation to do it internally. With si476x driver it is
> not the case and it is important that codec write/read functions
> perform si476x_core_lock(core) before they call regmap functions. If
> that is not done it is possible to wreak havoc on I2C bus by trying to
> access the registers of the codec and doing some V4L2 operations on
> the corresponding radio device.
> Although I completely agree that cache managing should be moved to MFD.
What exactly is the locking you're talking about here? Both regmap and
I/O have locking at those levels, if you try to do a bus interaction
using them it shouldn't conflict with any other register write. If it's
something higher level then shouldn't the locking be higher level too?
The way the code is written it looks like the lock is being held to
ensure there's no race due to a power state change.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2013-09-26 19:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 18:34 [PATCH] ASoC: si476x: Remove custom register I/O implementation Mark Brown
2013-09-26 19:33 ` Andrey Smirnov
2013-09-26 19:43 ` Mark Brown [this message]
2013-09-26 19:58 ` Andrey Smirnov
2013-09-26 20:58 ` Mark Brown
2013-09-26 22:48 ` Andrey Smirnov
2013-09-27 10:07 ` Mark Brown
2013-09-27 15:53 ` Andrey Smirnov
2013-09-27 17:02 ` Mark Brown
2013-09-27 19:28 ` Andrey Smirnov
2013-09-27 19:48 ` Mark Brown
2013-09-28 4:37 ` Andrey Smirnov
2013-09-28 11:53 ` Mark Brown
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=20130926194350.GU19304@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=andrew.smirnov@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linaro-kernel@lists.linaro.org \
/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