From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756014AbbCCOyq (ORCPT ); Tue, 3 Mar 2015 09:54:46 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:48131 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751592AbbCCOyp (ORCPT ); Tue, 3 Mar 2015 09:54:45 -0500 Date: Tue, 3 Mar 2015 14:54:38 +0000 From: Mark Brown To: Takashi Iwai Cc: linux-kernel@vger.kernel.org Message-ID: <20150303145438.GY21293@sirena.org.uk> References: <20150302182418.GD21293@sirena.org.uk> <20150303090929.GG21293@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IwyQ6WrKeVEwkA62" Content-Disposition: inline In-Reply-To: X-Cookie: My LESLIE GORE record is BROKEN ... 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: regcache_sync() errors for read-only registers cache 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 --IwyQ6WrKeVEwkA62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 03, 2015 at 10:22:59AM +0100, Takashi Iwai wrote: > Mark Brown wrote: > > > The --scissors option of git am is your friend. > > That's still pain. > But it's still better than sending two mails even if you don't know > whether it's the right patch. It's even not tag as an RFC. The patch > was there just as a reference. I actually find it harder to work with TBH - it breaks up the mail to have the extra stuff around the code in there and it's harder to apply if it's OK. During a discussion it feels more natural to just have the diff hunk with the mail text around it instead. > > Well, it's either that or adding the values read back from the chip to > > the defaults. > For fixing the single rw, it's easy in either way (although the latter > sounds bad from the performance POV). But what about the block rw? Why should adding something to the defaults hurt performance (it should just be a one time cost to insert the default which we've got a reasonable chance of making back later)? I guess if there's a lot of these registers it'll add up but they're pretty rare, usually it's a few ID and revision registers and anything else is volatile so wouldn't get cached at all. Block I/O can just get the same fix I think, the logic is basically the same it's just what we do with differences that changes. > > > regmap_wrietable() call in _regmap_write(). > > It's superfluous with respect to what? Still a bit confused, sorry. > regmap_writeable() is called twice in that code path with my patch. > First before calling _regmap_write() and again in _regmap_write(). > The second call is superfluous in this code path although it's needed > for other paths. > regmap_writeable() isn't usually that heavy, but it's still > suboptimal. Oh, right. The two checks are logically distinct to me - the check in _write() is more of an assert than something that's expected to go off, anything relying on it is in trouble, while the one in the cache sync is there as part of normal operation. If anyone cared about performance to that extent it probably ought to be a build option to even check though since the I/O is generally so slow and it's rare to implement writeable at all it doesn't normally matter. --IwyQ6WrKeVEwkA62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJU9csuAAoJECTWi3JdVIfQIBgH/11lttOsREg/jtCHneLv9kBr 5Iic2/b/23A2gZTtBuzRwwBrnmV0dJX0vuCI7p4H694UTHs3qA1glQMX54WgZjYK PjDbAb/YNBD8ZCV9+TOFPHHGeEF64kSEH45exvIJ8d5BETRUG0H2/UKcXBduTbso s6wXG+1Td0ElppxWGJgDhea3vfj4JEWD+MbZjz8NVZ/L7fc4wQsYIHOJye0u35Ty I3nzeofrcPCrlPJpRyJhp++cIyJid3iGyLB0qJ3/gDUjOrY80YPHJfmZrubKKiy3 qA/yZsUCz0h35SM5AKDAv34YjBMK+BEAfXo3i8iMqbLva60mmh3CdLvky5/qg8A= =8H2f -----END PGP SIGNATURE----- --IwyQ6WrKeVEwkA62--