[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160111161225.GJ6588@sirena.org.uk>
Date: Mon, 11 Jan 2016 16:12:25 +0000
From: Mark Brown <broonie@...nel.org>
To: Timur Tabi <timur@...i.org>
Cc: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>,
Fabio Estevam <festevam@...il.com>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
Nicolin Chen <nicoleotsuka@...il.com>,
Xiubo Li <Xiubo.Lee@...il.com>,
Liam Girdwood <lgirdwood@...il.com>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults
On Mon, Jan 11, 2016 at 09:45:37AM -0600, Timur Tabi wrote:
> Ok, I'm confused. Granted, all of this regcache stuff was added after I
> stopped working on this driver, so I'm out of the loop. But it appears that
> the regcache cannot properly handle an uninitialized cache. I would expect
> it to know to perform hard reads of any registers that are uninitialized.
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. Most users don't do anything at all in
interrupt context so it's not an issue for them, drivers that want to
use regmap in interrupt context need to handle this.
We can't rely on knowing which registers are valid and which registers
can be read without side effects, it's optional for drivers to provide
that information. Even with that information it's not always clear that
we want to stop and read every single value when we are initialising the
device, that might be excessively slow (remember a lot of regmap devices
are I2C or SPI connected, some with large register maps). We should
have a helper to do that though for drivers where it does make sense.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists