From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760866AbcAKQMk (ORCPT ); Mon, 11 Jan 2016 11:12:40 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:47844 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759178AbcAKQMi (ORCPT ); Mon, 11 Jan 2016 11:12:38 -0500 Date: Mon, 11 Jan 2016 16:12:25 +0000 From: Mark Brown To: Timur Tabi Cc: "Maciej S. Szmigiero" , Fabio Estevam , "alsa-devel@alsa-project.org" , Nicolin Chen , Xiubo Li , Liam Girdwood , "linuxppc-dev@lists.ozlabs.org" , linux-kernel Message-ID: <20160111161225.GJ6588@sirena.org.uk> References: <5677107C.60904@maciej.szmigiero.name> <20160111140038.GC6588@sirena.org.uk> <5693B7CC.8000905@maciej.szmigiero.name> <20160111145430.GE6588@sirena.org.uk> <5693CE21.8010009@tabi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JhY86nTAwD/oWhC3" Content-Disposition: inline In-Reply-To: <5693CE21.8010009@tabi.org> X-Cookie: APL hackers do it in the quad. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 3/3] ASoC: fsl_ssi: remove register defaults X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --JhY86nTAwD/oWhC3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. --JhY86nTAwD/oWhC3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWk9RpAAoJECTWi3JdVIfQEPAH/jIOBJmZ1/Z2SFx81KB5qmQH QcGhPJaDgyxMz21DsqXKX7hxg6NNYWVh7yE51QPSDk8nzygvtl/fHNqMXth9blOO 2/7S9BOY3CfYxXQZ9qfu/2Uy4cTgDRauF6TvoH510LQqgu0f6dq8OBfGGngPRsOZ 8wfQCM8k9jaO1L512EULIDiKP29mGmHhHN33tzfPrCDfcXWkoQkAP8/vG/P+xu/p lsrvnCq5hNGMXJi4T8mvykE/JDNKBS1b22A8501j0WYmG6oKO2U3P6/sEYaRAa6B p/qdtrxNM2pKjhJHLavJSSfWFVZdQ6Rl2IwI86G1EFBShyWgnV2OO3p20BwephY= =E/U9 -----END PGP SIGNATURE----- --JhY86nTAwD/oWhC3--