Received: by 10.192.165.148 with SMTP id m20csp5414840imm; Wed, 9 May 2018 04:50:35 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrG4SG2jX3/bm0Pkqe0hv9gKQyG9+ReJxAofePbcHCeU3eqZDCKeSfxvU5ONLqXgEZPSJIN X-Received: by 2002:a17:902:57c6:: with SMTP id g6-v6mr22270737plj.27.1525866635890; Wed, 09 May 2018 04:50:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525866635; cv=none; d=google.com; s=arc-20160816; b=QW2oWfJGlP75crWQS7eg0xz2NokkNvDBhv6alTdd8WgmYtx3fIHhREFNl+zEgcNCmq UWsXfTaxhbQq+9wB7hqTzj8BYkPH66tnVFpIzJ6WFcxHam6ymG0xfyDUf52+A+MsLMxQ 2ekcbdeICm11qiO3jjNBojo54HIhqzmI7CmDCRYASf+LUaU5KupY4UeFsgYXkE7SKk6Z 3OFLNNOa+FEpBz30lFSwDqcAO974Z4qIzxbaqXgzN0p7gK2w96jlsX+yyCjDzOxXcHv/ hCjyI6dcmT+IDkWM9U1WWTDePOVH4RFgsT4ru+lMc9wB9twtbA1pJCYwOZkgD9m1+z2H yx0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=X9UPRtgAX4tH0bHPWPiFPvaND+T/ZqBjFyoTijAcY8k=; b=aZpiyA9FRgkPSayo5LlCC732SpM78NEyBxbST45DdiCYIhrjUGqNj8oqPiqrNomPkO l6Dn4xGSBomB/DDZ/EuTFj8S8pfsYzSqLfRcqfV1LTNCL+y5Jyb9MbIHfGu3EDNEopY4 CgU5vfjRhnTyv7pBrBjW1DOqsw7ogR3ghyGldmyi1bPgX9BY/gcjv3umKi6UNctXhf9H IqLwRAhEc28oHy0asTGdMbCGDWYB+e1fPPPGuSfsBo3gGDauWB/w+a8MUgpx4QkgC75/ NoxV8EC8pV4/0PyZHrPSc8W8rdsUzhYw1/fHmvZJK++G825icWsgv+FgT7idS8j0CibN h5gw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=x39WpEP2; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g30-v6si2417430pgn.529.2018.05.09.04.50.21; Wed, 09 May 2018 04:50:35 -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=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=x39WpEP2; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934774AbeEILt1 (ORCPT + 99 others); Wed, 9 May 2018 07:49:27 -0400 Received: from mail-wr0-f171.google.com ([209.85.128.171]:37249 "EHLO mail-wr0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934508AbeEILtY (ORCPT ); Wed, 9 May 2018 07:49:24 -0400 Received: by mail-wr0-f171.google.com with SMTP id h5-v6so11443884wrm.4 for ; Wed, 09 May 2018 04:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=X9UPRtgAX4tH0bHPWPiFPvaND+T/ZqBjFyoTijAcY8k=; b=x39WpEP2IobbvmCRLQ/QfYpRXTgxqnipsMz7Scx45MrtqmBt6JQzoqLIGduRZeAOn1 xyPGprlQd1D+GjXR9RmL99V5wyG5zROG7Tmxx3daV/IqNATLplTtLOviHZGZVnzK7tOb oSK1/dlgIbNUm2bkNrlejV5RJ1LgB7XJY72psTWZDyUxwtT7UUKV10pilcdxoJL1vxRC Upkyy+ALfV6454JIq3EwOo3EYiHwutRn9UFaMSTmVUfD4N675Fl43c4g++w8DFSBv1GL ULOuK1sXxzLN81XLA0Onm7MlrxvcZwV+gCjal97DOhanJT7Y9WVaksHmUDttMIVbi3Hl tb0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=X9UPRtgAX4tH0bHPWPiFPvaND+T/ZqBjFyoTijAcY8k=; b=SM/S1Z/6IIFwMM9uml+1DnHPS6x5T/VRJonhpiyTAHEK1dyU4sze8vkk25xEudgZP7 i9SgfIHntdsI4/ejc+TbtPz09H3H2VaXhSPVqdp0KR5uUnuQirBfq+LLXjn7B90NVxY+ SPrR6fqm0tyAKBg1SOcYjD7/A9u5l62wgXLeNdbHppE1iTz0wofKLGKSvXItIZgJuKUR dXQG2L6ehpLDcXug6rwAw6r6KkY9lOo6bNxxM36FL3+Fkgye5lyiLe6gPqRMNGh0eHCs EBjt9Upb4tOJn571fEIrDo/5HtVb/HeBOzATbJToCa+lcYesoedw3Tk8UINxXU/sIoVq mEHw== X-Gm-Message-State: ALQs6tC5ZAfMGFRlUpE2DVaCwBXacJE26xWIgdiGsJcdTkYBqnNWpEKZ IqRHes0RCli8dlBILIh+Yqdm7trlZY8= X-Received: by 2002:adf:c54b:: with SMTP id s11-v6mr34687684wrf.46.1525866563145; Wed, 09 May 2018 04:49:23 -0700 (PDT) Received: from [192.168.43.163] ([213.143.48.157]) by smtp.gmail.com with ESMTPSA id y68-v6sm37135814wrb.91.2018.05.09.04.49.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 04:49:22 -0700 (PDT) Subject: Re: [RFC] regmap: allow volatile register writes with cached only read maps To: Mark Brown Cc: linux-kernel@vger.kernel.org References: <1525817169-29233-1-git-send-email-jramirez@baylibre.com> <20180509083919.GU13402@sirena.org.uk> From: Jorge Ramirez-Ortiz Message-ID: <65607fde-d0e9-0f08-3042-f6a58b760896@baylibre.com> Date: Wed, 9 May 2018 13:49:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180509083919.GU13402@sirena.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/09/2018 10:39 AM, Mark Brown wrote: > On Wed, May 09, 2018 at 12:06:09AM +0200, Jorge Ramirez-Ortiz wrote: >> Regmap only allows volatile access to registers when the client >> supports both reads and writes. >> >> This commit bypasses that limitation and enables volatile writes to >> selected registers while maintaining cached accesses on all reads. For >> this, the client does not need to configure the reg_read callback. > I don't understand what voltile access means for write only devices. > Volatile means that we don't read the cache but go direct to the > hardware so if we can't read the hardware that's pretty redundant, a > volatile read that goes to the cache is just a default read. oops, sorry will try to be a bit more clear with an example. This patch tries to support a map that provides: 1. only cached reads: (as a consequence every regmap write must succeed). 2. cached writes: do not access the hardware unless the value differs from what is in the cache already or (3) applies. 3. support for selectable volatile writes: those that will always access the device no matter what the cache holds. Something like this: static const struct regmap_config foo_regmap = { ??? .reg_write??? ??? = foo_write_reg, ??? .reg_bits??? ??? = 32, ??? .val_bits??? ??? = 32, ??? .reg_stride??? ??? = 1, ??? .volatile_reg??? ??? = foo_volatile_reg, ??? .max_register??? ??? = CODEC_ENABLE_DEBUG_CTRL_REG, ??? .reg_defaults??? ??? = foo_reg_defaults, ??? .num_reg_defaults??? = ARRAY_SIZE(foo_reg_defaults), ??? .cache_type??? ??? = REGCACHE_RBTREE, }; I dont think - I could be wrong- that this is something that we can support today since the current code seems to require that the regmap is readable (ie, that it implements reg_read). But it could also be that I am missing something in my config? This is why I sent an RFC instead of a PATCH, because I am not 100% sure that I am not missing something.