mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: lee.jones@linaro.org, sameo@linux.intel.com,
	patches@opensource.wolfsonmicro.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mfd: wm5102: Remove cache_bypass from manual register patching
Date: Sat, 22 Feb 2014 11:47:09 +0900	[thread overview]
Message-ID: <20140222024709.GK25940@sirena.org.uk> (raw)
In-Reply-To: <20140221093855.GC5438@opensource.wolfsonmicro.com>

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

On Fri, Feb 21, 2014 at 09:38:55AM +0000, Charles Keepax wrote:

> I guess there are two parts here applying the hardware patch and
> the manual application of the register patch. Applying the
> hardware patch restores registers once it is finished anyway, and
> the actual patch is applied by the write sequencer so will go
> straight to the hardware. So that really doesn't need the
> cache_bypass.

Yeah, it's only the manually applied bit that cares.

> > Being able to use the regular patch infrastructure would of course be
> > nicer but you're going to need to add a callback to allow you to run the
> > hardware patch in that case.

> I had considered adding bypassed versions of regmap_write and
> read. That way you could ensure that the bypass was only active
> whilst the regmap lock was held and avoid the problem that way.
> What do you think to that idea?

I think that's a reasonable idea, though I see you actually did
something slightly different (which is sensible and in fact there
already).

Thinking about this stuff there's also some ideas I discussed with
Dimitris for the DSP memories where if it were possible to mark only a
section of the register map as cache only the DSP download could be sped
up a little by making the DSP memories cache only during download and
then syncing at the end to do the actual writes.  That way coefficient
writes that change defaults in the firmware would get coalesced and
possibly some writes to adjacent blocks could be combined too.  Probably
not a massive win but it'd be nice.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      parent reply	other threads:[~2014-02-22  2:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-20 16:26 Charles Keepax
2014-02-20 23:30 ` Mark Brown
2014-02-21  9:38   ` Charles Keepax
2014-02-21 11:10     ` Charles Keepax
2014-02-22  2:47     ` Mark Brown [this message]

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=20140222024709.GK25940@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=ckeepax@opensource.wolfsonmicro.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@opensource.wolfsonmicro.com \
    --cc=sameo@linux.intel.com \
    /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

all inboxes | Powered by JetHome®