mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Andrew Bresticker <abrestic@chromium.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] regmap: don't use spinlocks with REGCACHE_{RBTREE,COMPRESSED}
Date: Fri, 28 Feb 2014 12:39:35 +0900	[thread overview]
Message-ID: <20140228033935.GF9383@sirena.org.uk> (raw)
In-Reply-To: <CAL1qeaF2RtC--K06qWkMRjBAOzoVfxi845RwZX05QwXS66Ns9Q@mail.gmail.com>

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

On Thu, Feb 27, 2014 at 06:32:53PM -0800, Andrew Bresticker wrote:
> On Thu, Feb 27, 2014 at 3:37 AM, Mark Brown <broonie@kernel.org> wrote:

> > Have all the users been audited to verify that they're actually safe
> > with this?  I just took a quick look at the Tegra drivers and they're
> > doing regmap operations in their trigger operations which is done from
> > atomic context so they should run into problems trying to take mutexes
> > anyway.

> Oops, you're right, I didn't look through all the regmap operations
> carefully enough.  It is in fact the Tegra drivers I've ran into this
> issue with.

Yeah, I suspected it might be :)

> > I think we need to either ensure that all users allocate their caches at
> > probe time (which is fine and is hopefully what the current users are
> > doing), provide a mechanism for them to do cache allocations outside of
> > the spinlock (which sounds hairy) or convert them to flat cache.

> Allocations are made in the write path for rbtree and in both the read
> and write paths for lzo.  I suppose we can pre-allocate everything at
> init time, but I haven't looked too much at that.  For at least the
> Tegra drivers, the best option for now appears to be to convert to a
> flat cache.

OK, that's certainly simple to implement.  Currently to allocate at
startup the standard thing is to supply the hardware defaults as data,
though going through and reading everything should also do the trick.

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

      reply	other threads:[~2014-02-28  3:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27  3:50 Andrew Bresticker
2014-02-27 11:37 ` Mark Brown
2014-02-28  2:32   ` Andrew Bresticker
2014-02-28  3:39     ` 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=20140228033935.GF9383@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=abrestic@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®