Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423101AbbD2ReU (ORCPT ); Wed, 29 Apr 2015 13:34:20 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:43045 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966431AbbD2ReR (ORCPT ); Wed, 29 Apr 2015 13:34:17 -0400 Date: Wed, 29 Apr 2015 18:34:02 +0100 From: Mark Brown To: Kevin Cernekee Cc: Liam Girdwood , Lars-Peter Clausen , dgreid@chromium.org, Andrew Bresticker , Olof Johansson , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" Message-ID: <20150429173402.GP22845@sirena.org.uk> References: <1429915008-22015-1-git-send-email-cernekee@chromium.org> <1429915008-22015-2-git-send-email-cernekee@chromium.org> <20150425113235.GA31708@sirena.org.uk> <20150429104042.GB22845@sirena.org.uk> <20150429164632.GO22845@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3VjAXQKlB2CdpQtt" Content-Disposition: inline In-Reply-To: X-Cookie: Your present plans will be successful. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH V2 1/4] regmap: cache: Add "was_reset" argument to regcache_sync_region() 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 Content-Length: 2496 Lines: 64 --3VjAXQKlB2CdpQtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 29, 2015 at 10:02:03AM -0700, Kevin Cernekee wrote: > On Wed, Apr 29, 2015 at 9:46 AM, Mark Brown wrote: > > We just need a single boolean? > Right, so if we add a per-regmap bool that tells us whether the device > has been reset, then in the case of "not reset" we will have to write > every regcache entry out to the device. Even the ones that weren't > touched while in cache_only mode. This makes the "not reset" case > much less efficient than the "reset" case. The immediate point is to provide a useful external interface, the internal optimisation is much less urgent (and it's less clear to me how often we're going to need to do that at all - generally cache only and power loss go together. > BTW, any preferences on naming for the bool or for the renamed > mark_dirty function? Not urgently. Note that I'm *not* suggesting an immediate rename, that's definitely a separate change (which will be a lot more painful to merge due to cross tree issues). > >> i.e. regcache_sync() finds a register value marked "present". How do > >> we know whether we need to write it back to the hardware? For the > >> special case of "cached non default register values immediately after > >> a HW reset" you can mostly figure this out, but if there was no HW > >> reset how do we know which entries changed while the HW was > >> inaccessible? > > In the first instance do we care? > I'm not sure I understand the question. Do we actually care about getting a list of the changed registers that much? --3VjAXQKlB2CdpQtt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVQRYKAAoJECTWi3JdVIfQfYsIAIKxW37dqidzwS5ArJBIpzd9 c5aJ5bmWP+r3aJXEY2NIGvg/lTtELe45uFOFltPfygWogYDxyp8j14Q0lFbBzytP m5o2rm+HmaOxtglvjM1q+qqhdDkDWq7tjuZ1gg05n0GCBt6eZLaV1iJrqQ8gMrgG vV9caW9J61hftHiZLMbTXP7l4bggj3zJmGX6id685iMBqApbpTsXvxJW0bm03tEE 82iQ6qIOvXqBV/DUI7tYZdR8liFcff1p+2l+jXKXtUWz2qL6PzKJ7zusYB9ANDEY kzQpZCPFaCv5o4a0ZC/bIzUjd4+6zmZv6AKfW+PvnUOFBFrMeOxEkOuNL/z4+Tg= =joo2 -----END PGP SIGNATURE----- --3VjAXQKlB2CdpQtt-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/