From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D626DC43334 for ; Tue, 21 Jun 2022 21:13:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date: In-reply-to:Subject:Cc:To:From:References:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=6dZiQ6+s1F8O47xfaJn707sWyjU3AWPfyFtwVd3C1d8=; b=v51COhqIttM6yCVKQ935+nH//7 RHbB/0JI4pvGrzN8ife5/px4cZkte44iyX0pOspdCpK9VktYVaVWOG78O8k5iM4GIsHyLRWuCPmvG QpJS52TksDHdRuPrrkQsZUe51eoafs6HGulKHyj/jp7w8nrZ7OPJCzZfK3/BNedncAyrE/sCDpGxM xu7QIbZNkLINGw972texaZSj+2fSd7dy7HCxr6Nc3JtYFGSED/eZO2ew+URMLgV7jVqpFaWg740Wx lFSypc344mZ7Dec0MQw/YfxXFz4YK4YDzJpOkS9N2L4ivuZOPkJ/5kIKkb1wMQvZ4J+YUrUSzb+Wr tSijhL8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3lAM-007Gqp-NN; Tue, 21 Jun 2022 21:12:06 +0000 Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o3lAI-007Gnh-2R; Tue, 21 Jun 2022 21:12:03 +0000 Received: by mail-wr1-x436.google.com with SMTP id k22so14196435wrd.6; Tue, 21 Jun 2022 14:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version; bh=5jGRxWa+Hik2xXu28OZInbUMDSK1LmZ28o9a5C6ustA=; b=dBkR+OXnEaZPr9uoaZB+DI5wT1AXufYbc+9qN44d74R1jy7oOaP5glLLgc/hzh3E8m VEYB0O8O8TiK3K0KU8aR4nbUvWWFGE7uePKS5PELYCU4SnEeJA8EVcTkrM2DoduTme8M T2w+A4Oj1CabUPV/iQcD8tJhe3/0P4UoInCNfQd2pdDiq/qrgQ6JtX7yLUUFdykN73bM NtCtwLELefp/0JcgOX6hIfK1mCyMbjfNrGysmUUfiSDKIuEdhMG6diRPWKvISTwtHa9N kgrC4FpslcP3XTRRhPHg48OrMHfSCIL2fPrOOeRY9LvrBNjg8LF3SLUYHP6wXsVMRurd LPAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:from:to:cc:subject:in-reply-to:date :message-id:mime-version; bh=5jGRxWa+Hik2xXu28OZInbUMDSK1LmZ28o9a5C6ustA=; b=3CiFTwtbObiSKtnmWixN6uD5rdMqij8wcUIGfGd08g8v4QrPzHsUgj1AT/trh/dcE1 Xax+sJlH7AT5Lv0Ew8+ul/rNPLhvI0tinTlQWNu0KMqNNmuNULKBHbCkA5hTJ9Ji0BS4 /51BRLOKa3NWbk5RB+W9AT5D63ULBX7pQYLrTNoTsSBV16Tayp+TC6xQJRc/iOrpDDaz YLFtpSJlgxhfleqni7qJBQWKr/f00heVpaqSBlELnatjj7k+GSkD0daCuxpXpmL0mFRk 3ctELRYByFvVh6PiAmPTeyOFHFb4UWYn0u52b749QQehixTm63Eucjim4YK2bKKbBRZD jcbQ== X-Gm-Message-State: AJIora+ry5Lh+en+zdpk/z4uPCpOCtBZi8mx31JO7buoxyaV3/MWeMFI Io7xAApxVEgYLrtUWiY8fLs= X-Google-Smtp-Source: AGRyM1uWGscZnGaavVg/uIQYsRslzM5t54de/BLxZBl+KXB10CZYw57ndf/q8EV3SUZ+AQYy58rh1w== X-Received: by 2002:adf:fb10:0:b0:207:af88:1eb9 with SMTP id c16-20020adffb10000000b00207af881eb9mr30853557wrr.238.1655845918233; Tue, 21 Jun 2022 14:11:58 -0700 (PDT) Received: from localhost (92.40.168.122.threembb.co.uk. [92.40.168.122]) by smtp.gmail.com with ESMTPSA id bv27-20020a0560001f1b00b0021b84ac7a05sm7979960wrb.0.2022.06.21.14.11.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jun 2022 14:11:57 -0700 (PDT) References: <20220620200644.1961936-1-aidanmacdonald.0x0@gmail.com> <20220620200644.1961936-16-aidanmacdonald.0x0@gmail.com> From: Aidan MacDonald To: Andy Shevchenko Cc: Mark Brown , Andy Gross , Bjorn Andersson , Srinivas Kandagatla , Banajit Goswami , Greg Kroah-Hartman , "Rafael J. Wysocki" , Chanwoo Choi , Krzysztof Kozlowski , Bartlomiej Zolnierkiewicz , MyungJoo Ham , Michael Walle , Linus Walleij , Bartosz Golaszewski , Thomas Gleixner , Marc Zyngier , Lee Jones , Manivannan Sadhasivam , Cristian Ciocaltea , Chen-Yu Tsai , tharvey@gateworks.com, rjones@gateworks.com, Matti Vaittinen , orsonzhai@gmail.com, baolin.wang7@gmail.com, zhang.lyra@gmail.com, Jernej Skrabec , Samuel Holland , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , Linux Kernel Mailing List , "open list:GPIO SUBSYSTEM" , linux-actions@lists.infradead.org, linux-arm-msm , linux-arm Mailing List , linux-sunxi@lists.linux.dev, ALSA Development Mailing List Subject: Re: [PATCH 15/49] regmap-irq: Change the behavior of mask_writeonly In-reply-to: Date: Tue, 21 Jun 2022 22:13:03 +0100 Message-ID: MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220621_141202_178705_5CA9845A X-CRM114-Status: GOOD ( 17.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Andy Shevchenko writes: > On Mon, Jun 20, 2022 at 10:08 PM Aidan MacDonald > wrote: >> >> No drivers currently use mask_writeonly, and in its current form >> it seems a bit misleading. When set, mask registers will be >> updated with regmap_write_bits() instead of regmap_update_bits(), >> but regmap_write_bits() still does a read-modify-write under the >> hood. It's not a write-only operation. >> >> Performing a simple regmap_write() is probably more useful, since >> it can be used for chips that have separate set & clear registers >> for controlling mask bits. Such registers are normally volatile >> and read as 0, so avoiding a register read minimizes bus traffic. > > Reading your explanations and the code, I would rather think about > fixing the regmap_write_bits() to be writeonly op. That's impossible without special hardware support. > Otherwise it's unclear what's the difference between > regmap_write_bits() vs. regmap_update_bits(). This was not obvious to me either. They're the same except in how they issue the low-level write op -- regmap_update_bits() will only do the write if the new value differs from the current one. regmap_write_bits() will always do a write, even if the new value is the same. I think the problem is lack of documentation. I only figured this out by reading the implementation. >> if (d->chip->mask_writeonly) >> - return regmap_write_bits(d->map, reg, mask, val); >> + return regmap_write(d->map, reg, val & mask); >> else >> return regmap_update_bits(d->map, reg, mask, val); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel