Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966282AbbD2Qqt (ORCPT ); Wed, 29 Apr 2015 12:46:49 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:42994 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751647AbbD2Qqr (ORCPT ); Wed, 29 Apr 2015 12:46:47 -0400 Date: Wed, 29 Apr 2015 17:46:32 +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: <20150429164632.GO22845@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KhnGy1eznWbC2o3B" 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: 2459 Lines: 62 --KhnGy1eznWbC2o3B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 29, 2015 at 07:13:27AM -0700, Kevin Cernekee wrote: > On Wed, Apr 29, 2015 at 3:40 AM, Mark Brown wrote: > > Like I said above we can tell if the hardware was reset because > > mark_dirty() is called. > That covers the public API, but I do not understand how you intended > for this data to be stored in the rbtree if the use of a dirty bitmask > is discouraged. We just need a single boolean? > 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 suggesting that we do anything based on the presence of a cache > > entry, I'm suggesting that we could avoid having to ever cache values > > that never get referenced on a system (which can be a lot of them for > > common use cases) saving us memory. > This seems to be solving a different problem. It sounds like you are > more worried about regcache_sync() writing back lots of default values > for registers that were never touched, than performing unnecessary > writes to a few (actively used) registers that weren't changed while > we were in cache_only mode. Is that accurate? No. This is nothing to do with sync, it's just something that might be nice. --KhnGy1eznWbC2o3B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVQQrnAAoJECTWi3JdVIfQUFcH/0SynwjyXdpOG0FDUKg3hGRt DoXVSeih4qZKgGl6JXcaiDAF2JbXsi66XBkDt45qI7Rpid1TScuczKzy4kSfgalc +vYRwu8/8Z46+F0+9yUuY5GkEDatwqbhXRVpJ4e8afS3fYkyuBy8lTgUw5OWmRgk hvF0mqlfq3F9uw6E0GVMkb65ZiYYIUkYPTGBXWCUSGxNJpknkNyeyN8pdoo7Nn6e 5AoDELu2JjhoB7NpGSPDBoGn6Vo2d5kuXgNgk4BvI/IzXfsQo8KZTBK/ijBPznyB 2QWflf0f8yJVg+6dNHdZ4ydCbUCWlyix++JdDJEoZExEHJPwfU1mSw2d7ZkpzeI= =RIM5 -----END PGP SIGNATURE----- --KhnGy1eznWbC2o3B-- -- 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/