From: Mark Brown <broonie@kernel.org>
To: Timur Tabi <timur@tabi.org>
Cc: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
Fabio Estevam <festevam@gmail.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Nicolin Chen <nicoleotsuka@gmail.com>,
Xiubo Li <Xiubo.Lee@gmail.com>,
Liam Girdwood <lgirdwood@gmail.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
Date: Tue, 12 Jan 2016 01:34:21 +0000 [thread overview]
Message-ID: <20160112013421.GW6588@sirena.org.uk> (raw)
In-Reply-To: <569455AA.4060907@tabi.org>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
On Mon, Jan 11, 2016 at 07:23:54PM -0600, Timur Tabi wrote:
> Mark Brown wrote:
> >regcache handles this fine, it's perfectly happy to just go and allocate
> >the cache as registers get used (this is why the code that's doing the
> >allocation exists...). What is causing problems here is that the first
> >access to the register is happening in interrupt context so we can't do
> >a GFP_KERNEL allocation for it.
> Considering how small and not-sparse the SSI register space is, would using
> REGCACHE_FLAT be appropriate?
Quite possibly (it'll be more efficient and it's intended for such use
cases) but as I said in my other reply that then has the issue that it
implicitly gives default values to all the registers so I'd expect we
still need to handle the cache initialisation explicitly (or
alternatively the hardware sync with the cache on startup).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-01-12 1:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-20 20:33 [PATCH 3/3] ASoC: fsl_ssi: remove register defaults Maciej S. Szmigiero
2015-12-23 13:13 ` Fabio Estevam
2016-01-10 21:36 ` Timur Tabi
2016-01-11 12:04 ` Fabio Estevam
2016-01-11 12:10 ` Fabio Estevam
2016-01-11 13:57 ` Maciej S. Szmigiero
2016-01-11 14:05 ` Fabio Estevam
2016-01-16 23:56 ` Maciej S. Szmigiero
2016-01-17 0:10 ` Timur Tabi
2016-01-17 1:01 ` Maciej S. Szmigiero
2016-01-17 5:16 ` Timur Tabi
2016-01-17 14:16 ` Maciej S. Szmigiero
2016-01-17 14:39 ` Maciej S. Szmigiero
2016-01-17 18:38 ` Timur Tabi
2016-01-17 22:02 ` Maciej S. Szmigiero
2016-01-18 12:51 ` Fabio Estevam
2016-01-18 19:08 ` Maciej S. Szmigiero
2016-01-11 14:00 ` Mark Brown
2016-01-11 14:10 ` Maciej S. Szmigiero
2016-01-11 14:54 ` Mark Brown
2016-01-11 15:45 ` Timur Tabi
2016-01-11 16:12 ` Mark Brown
2016-01-12 1:23 ` Timur Tabi
2016-01-12 1:34 ` Mark Brown [this message]
2016-01-12 1:53 ` Timur Tabi
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=20160112013421.GW6588@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Xiubo.Lee@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=festevam@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mail@maciej.szmigiero.name \
--cc=nicoleotsuka@gmail.com \
--cc=timur@tabi.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;
as well as URLs for NNTP newsgroup(s).