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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16B10C47080 for ; Mon, 31 May 2021 17:19:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0EA7610FC for ; Mon, 31 May 2021 17:19:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232102AbhEaRVA (ORCPT ); Mon, 31 May 2021 13:21:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231916AbhEaRUW (ORCPT ); Mon, 31 May 2021 13:20:22 -0400 Received: from polaris.svanheule.net (polaris.svanheule.net [IPv6:2a00:c98:2060:a004:1::200]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D08FC0431EE for ; Mon, 31 May 2021 08:33:31 -0700 (PDT) Received: from [IPv6:2a02:a03f:eafb:ee01:86ad:a53c:2e83:dd76] (unknown [IPv6:2a02:a03f:eafb:ee01:86ad:a53c:2e83:dd76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: sander@svanheule.net) by polaris.svanheule.net (Postfix) with ESMTPSA id A9BDE206B6B; Mon, 31 May 2021 17:33:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svanheule.net; s=mail1707; t=1622475210; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xiXZatVAB++3a5E7nWSQIMIqvM2fRrnQrEqg5glz/i0=; b=ZIOw1e17uTXiLULKbQJOqFzrCYPbNaJnIwUMlVNBaZ1D7RKUE7EcW92eVBDgxZoO0OL+Gy 2+LQe/2laJYBVX2JuBSWrZWEX/UIcWx9mv1myqK5w3ZLN/OY7HyaepuAB0Mjxid+PTyIa9 hh4u0W1pFk7EUkyEFLRfLR1qI2JrNDwWc0Z8C5H7G8sMj/Z4lPihomUC4sGhGnUx7xUgEq dVY1aEcQyp+BY4HRBdexLehJcBJ2IGudwvWZfgrm0nirPXvAPo/lA7egj7grZHIz3I3681 1baa/NkSeQz84/GSJUu+x8HeDNI+E8rwqSNFIfQX3ODZiauhBvU1313T2xI2kw== Message-ID: <272ac6af4a5ba5df4bb085617c9267e5ece61c19.camel@svanheule.net> Subject: Re: [PATCH 0/5] RTL8231 GPIO expander support From: Sander Vanheule To: Andy Shevchenko , Michael Walle Cc: Hans de Goede , Andrew Lunn , Pavel Machek , Rob Herring , Lee Jones , Mark Brown , Greg Kroah-Hartman , "Rafael J . Wysocki" , Linus Walleij , Bartosz Golaszewski , Linux LED Subsystem , devicetree , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List Date: Mon, 31 May 2021 17:33:27 +0200 In-Reply-To: References: <02bbf73ea8a14119247f07a677993aad2f45b088.camel@svanheule.net> <84352c93f27d7c8b7afea54f3932020e9cd97d02.camel@svanheule.net> <7a9978881e9ec5d4b811fa6e5d355fb6bce6f6d8.camel@svanheule.net> <0047200eecbd7ee480258cc904d6b7ee@walle.cc> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, 2021-05-31 at 14:16 +0300, Andy Shevchenko wrote: > > > On Monday, May 31, 2021, Michael Walle wrote: > > Am 2021-05-31 10:36, schrieb Sander Vanheule: ... > > > The data register rather appears to be implemented as a read-only (pin > > > inputs) > > > register and a write-only (pin outputs) register, aliased on the same > > > register > > > address. > > > > > > > Ahh so this makes more sense. If the data register is really write only > > regardless of the direction mode, then RMW doesn't make any sense at all. > > Please note, that even if regmap caches values, it might be marked as dirty > > and it will re-read the values from hardware. So I don't know if that will > > help you. > > > > So a possible quirk could be > >  GPIO_REGMAP_WRITE_ONLY_DATA_REG (or something like that) > > > > > > Isn’t regmap property to do a such? I don’t think any quirks are needed since hw > works as expected. The HW works as expected, but it is regmap-gpio's assumption that values read from reg_set_base reflect the current output value that fails. I looked a bit more at the provided interface, to see if this can be done with existing regmap functionality. The data registers must not be marked volatile, to ensure cached reads. The pin set function can wrap the RMW in regcache_cache_only + regcache_sync, but this causes visible glitching on my device. The pin input values can be read by wrapping the regmap_read in regcache_cache_bypass guards. If only the regmap's internal lock is used, the RMW cycle is no longer atomic. Inside the cache_only guards you can't read the input data, and inside the cache_bypass guards other register writes cannot be performed, or the cache may get out of sync. regcache_sync_region could be used, but maybe we would then miss other registers that were updated in the meantime. Am I missing something here? It seems to me like the regmap interface can't really accommodate what's required, unless maybe the rtl8231 regmap users perform some manual locking. This all seems terribly complicated compared to using an internal output-value cache inside regmap-gpio. Best, Sander