Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2732199imm; Sat, 12 May 2018 19:22:43 -0700 (PDT) X-Google-Smtp-Source: AB8JxZotUV7bbLDdieg64TUuVpNv4SyyArygz+Tbs99R39berj/GARA9oolhM8pvc3OGoV+xXCIE X-Received: by 2002:a17:902:20e5:: with SMTP id v34-v6mr4377215plg.127.1526178163276; Sat, 12 May 2018 19:22:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526178163; cv=none; d=google.com; s=arc-20160816; b=kOJLX3vb3mGEZZs6spW5Aw7ZkvAwv0/YJrKVYvuWCNIo+HdIw8B7zJU50d+nyops09 YY7edossLlN/MFH336ivCU5VJH0knsh1M1iqJ0q+fLilJUEdLVJXKOp5bG2Nrnf51m/a 2hb6og7Sj5oYoRXeYFNmnsi6ZTx8ICsGI0yuEN9+yNawZHoyZUQfSrDMonAkk3WuiYbe 37W3IwUGWOnBBet/TsAgrEh8wavKRJmuTG5mKrVh+v+WO7c6zoi5LDGAuhSXrsN54CFp V5awyp/NIuDIaf2mBW+EuLKoR0x52S7jx+4lOw/J9sOZLxBcnnTLcrjbaG1DZEwAxpvG jGeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=d5eHIDP6WQboPBruMuQQe2+KxwfrNie475v7Hh/o3zo=; b=ohbNNWPyoFBBdxcdJh8iXWHy9Ih9/GbqsVKlWdmpngV14Ne6sstSWb859sLoOWxzjl O7mcY6ooXzubZKQdwU1HEXSB2BpL8ZNHpPxI2t6/CE906HApE5g9oH8JbSZmfeDxhpLS U/YaGCuVZcRhrH4Y3m3tuG+ghIMPjx5YdEf4ECcQA7VUeMZLMVXpbxJzT+j2Mi56sudy OYdxPfEVN2CRuoNWiBk7/dl0THoSb5rSknHsEBGQfJR55aGQBQ/gcf7VIECqacQbZJ90 SHgONs2ZLbh3TOpqJaGDRiu6LH2Xn2hqPn2fRgcpY5ZK2ny36fbzUSBOVm4A5EfIKMT5 UPVQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=PYz/yjV2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h8-v6si6419617pfi.115.2018.05.12.19.22.28; Sat, 12 May 2018 19:22:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=PYz/yjV2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbeEMCWI (ORCPT + 99 others); Sat, 12 May 2018 22:22:08 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:39740 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751654AbeEMCWH (ORCPT ); Sat, 12 May 2018 22:22:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=d5eHIDP6WQboPBruMuQQe2+KxwfrNie475v7Hh/o3zo=; b=PYz/yjV23XssOZou+2hKWnMus +vpBPEtUF8HLp4+nYKx+iwIn6iMEmCcMvFL4Kz1PCz0BhqMkpNmUtLyu4ZZubGsiuVKHx89te2txK gaG1GcfyxtASEBwkeWt4rQiZ7gXk992Ym8NfOrPe92n1Q/O8RHsHSQp6y/q+s6knB1qTk=; Received: from kd111239173184.au-net.ne.jp ([111.239.173.184] helo=finisterre.ee.mobilebroadband) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fHgeE-0005X0-2X; Sun, 13 May 2018 02:22:06 +0000 Received: by finisterre.ee.mobilebroadband (Postfix, from userid 1000) id 2CF0944007A; Sun, 13 May 2018 03:22:02 +0100 (BST) Date: Sun, 13 May 2018 11:22:02 +0900 From: Mark Brown To: Jorge Ramirez-Ortiz Cc: linux-kernel@vger.kernel.org Subject: Re: [RFC] regmap: allow volatile register writes with cached only read maps Message-ID: <20180513022202.GA17611@sirena.org.uk> References: <1525817169-29233-1-git-send-email-jramirez@baylibre.com> <20180509083919.GU13402@sirena.org.uk> <65607fde-d0e9-0f08-3042-f6a58b760896@baylibre.com> <20180511020049.GD949@sirena.org.uk> <7cc158bb-3471-4d8e-d066-2e7f535812eb@baylibre.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <7cc158bb-3471-4d8e-d066-2e7f535812eb@baylibre.com> X-Cookie: Boy! Eucalyptus! User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 11, 2018 at 12:29:42PM +0200, Jorge Ramirez-Ortiz wrote: > On 05/11/2018 04:00 AM, Mark Brown wrote: > > We don't currently suppress writes except when regmap_update_bits() > > notices that the modification was a noop. You probably want to be using > > regmap_write_bits() here instead of regmap_update_bits(), that will > > always do the write. > but isnt that interface at a different level? It's at the level where we suppress writes - the write suppression isn't a feature of the caching, it's something that regmap_update_bits() does if it notices that it won't change anything. It'll happen even if there's no cache at all. > I am not sure if you are asking me to review my patch or just discarding the > RFC and highlighting that I have a configuration problem. I don't understand your patch as-is. > In my use case and what triggered this RFC (config below), an 'amixer set' > might never reach the driver's .reg_write interface even though the register > is configured as volatile (to me this is not consistent since volatile_reg > is being silently ignored). I'm not seeing any inconsistency there. Volatility means the register can't be cached as it might change underneath us, it doesn't have any impact on writes and it's happening at a lower level. Like I say if you absolutely need a write to happen you should be explicitly doing a write, though if you need a write to happen for a noop control change it sounds like there's something weird with that control that's possibly a problem anyway. > So I dont see where/how your recommendation fits; maybe you could clarify a > bit more please? As I've been saying if you explicitly need a write to happen don't use regmap_update_bits(), do something that guarantees you'll get a write like regmap_write() or regmap_write_bits(). --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlr3oUcACgkQJNaLcl1U h9BqWQf+J/FO1A4fGK5nlXvar2tkRXv3Z1XbKO9W6XctjGQv1dwlaROBKIBSOm7V dhIutCcd9m7lONj5Ibqe1Q8BkM3M8L8PkyQxT76d/5nZup6tSVgXD+/CPzVhHF+j EQ7only3SkEUb/vzLQCDhIAghf2+Qk/8BEEQT3JAu5JPXCis8prPRKeD6yt4Sklo vqKS9oHXNJ2c3M8dDeEQajaOPjxj8rCO5akbe2vFyHxIuKMGRSLOv9qJxyMlqRVE fVl4T3aiFNkBA2umWBPyp4v+iB3SFzKezpJRhfGbjr5Z2QzA9zWPy5vew8AyltgJ Ou34KtTScwIb09fAwZzUuBBVQbsFZQ== =Q90z -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr--