Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp253846pxh; Tue, 9 Nov 2021 10:09:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJyVaEx1Wb2Fx7kyk6Niq0KgrmlDzNISj+U/gCQqMEegpNSTT0yisdOwebB8pUXuArMcDOLQ X-Received: by 2002:a05:6402:14c3:: with SMTP id f3mr12607653edx.67.1636481393012; Tue, 09 Nov 2021 10:09:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636481393; cv=none; d=google.com; s=arc-20160816; b=aInOioAKVCc2hADXyoyI6MHIjkY/23DsldYM6NxPjDQRVh3jxcb6IejqL5JS5A/ZX8 vG6qwOrUlJpbJfzjnMtbr/jDDXKJrgW9CcFSp+HK2cWejCbLMhtz2jAbRKHuOdGOUsFh o+WP1MjLEckca84zctJYW1Ca1zxqGsJLi5BtC0dwrr+UbrvIHlH1B1HbvWcmwS4rNCD+ p5X2ocDdOFdMwWE5+mOsN4bhpKYVUkm1VOodtsYeL2dGKAhqrJb/iTsBbGPVOLVFDar5 MvzaJOKyeEaRko8f5mAlOEIG20CldDBWNQ4ElxsLsES6ETKcUaREprtYWbLJ4fyZniJe ikSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=Bi+4EcCOJ07EIdzMMOuINB1xKKX7YpFZJOF2Giniox8=; b=fd01GIRBHaUuKWqNImiXf8P5Z0zcSt35eI/r/1w0PbZOF+KRspneuMPvam6/wuzVD5 8bSiOf3x2+1APGdxF0/MUQW5cgg0NX2XKLvvCxMuS05MMk2fNmKxGZB8isV/HsE6PVrG +NtUudg20wxuE1m/ab+/JBSL38vqyZPY6F++VUnHuPoqSORr7AcepkseHDDdtKRDGNl/ UN2G12zdNxdhtZAgZz5bInbkQc+zRTNbdilqqFyRvohZVhOhaJ3CbDigBePulLLljhWd ApPCMobKotc06jBVBBHbUaTqEz2RIYLmfFqDo84OX1EhS9Et+g8BoztfptV6hjwWMlZu E1QQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m13si37529506edd.437.2021.11.09.10.09.27; Tue, 09 Nov 2021 10:09:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243126AbhKIJnD (ORCPT + 99 others); Tue, 9 Nov 2021 04:43:03 -0500 Received: from mail-pl1-f179.google.com ([209.85.214.179]:34764 "EHLO mail-pl1-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230383AbhKIJnC (ORCPT ); Tue, 9 Nov 2021 04:43:02 -0500 Received: by mail-pl1-f179.google.com with SMTP id r5so19927556pls.1; Tue, 09 Nov 2021 01:40:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bi+4EcCOJ07EIdzMMOuINB1xKKX7YpFZJOF2Giniox8=; b=Q55Gv9AZ1Ugbxj4x5W4sh7u9Joz9zFr3LMOdPK0nMvb5VE5pbjemU8jCTkXm9pOwWj OLCrLLgH9sCsCKYpnj6bFX8Ud5Bm8Ga6TAmMlOeZekokmTc2eYo18PCBaVaEAhJrEFQS a/i4TUPm+e3GiYF6q+3Mw/Hk4ygumLMtC+9rGL/5dPTLMKSmPRcpD1r6tLG/0BxoUwSG C/ftZn4iDEQnZ56fxHr9/lksupY1emkwE5Og7NKd3t3f2s3npabO7Si9VYjoY1kbGiz8 rdfN96iigTo33bhhJmoeb4NOCmp6liDdHKufAYLJrMeDtLY2gM/wTJCE8OTR4NVWoPZQ rMoQ== X-Gm-Message-State: AOAM530VoiI9qefsOqeF34Z09oWvJy6Re5G4E2wQoqtufM6bREFJoMwR sCzF+BMX2L0VNLEc7/L/+Xt2hq+IlbCu72VyAxs= X-Received: by 2002:a17:90b:4b0e:: with SMTP id lx14mr4174899pjb.160.1636450816945; Tue, 09 Nov 2021 01:40:16 -0800 (PST) MIME-Version: 1.0 References: <20211102161125.1144023-1-kernel@esmil.dk> <20211102161125.1144023-13-kernel@esmil.dk> In-Reply-To: From: Emil Renner Berthing Date: Tue, 9 Nov 2021 10:40:05 +0100 Message-ID: Subject: Re: [PATCH v3 12/16] pinctrl: starfive: Add pinctrl driver for StarFive SoCs To: Andy Shevchenko Cc: Linus Walleij , linux-riscv , devicetree , linux-clk , "open list:GPIO SUBSYSTEM" , "open list:SERIAL DRIVERS" , Palmer Dabbelt , Paul Walmsley , Rob Herring , Michael Turquette , Stephen Boyd , Thomas Gleixner , Marc Zyngier , Philipp Zabel , Greg Kroah-Hartman , Daniel Lezcano , Andy Shevchenko , Jiri Slaby , Maximilian Luz , Sagar Kadam , Drew Fustini , Geert Uytterhoeven , Michael Zhu , Fu Wei , Anup Patel , Atish Patra , Matteo Croce , Linux Kernel Mailing List , Huan Feng Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 9 Nov 2021 at 10:34, Andy Shevchenko wrote: > On Tue, Nov 9, 2021 at 11:21 AM Emil Renner Berthing wrote: > > On Tue, 9 Nov 2021 at 02:01, Linus Walleij wrote: > > > On Tue, Nov 2, 2021 at 9:08 PM Andy Shevchenko > > > wrote: > > ... > > > > > Linus any comments on this code (sorry if I missed your reply)? The > > > > idea behind above is to skip all settings from the same category and > > > > apply only the last one, e.g. if we have "bias set to X", ..., "bias > > > > disable", ..., "bias set to Y", the hardware will see only the last > > > > operation, i.e. "bias set to Y". I think it may not be the best > > > > approach (theoretically?) since the hardware definitely may behave > > > > differently on the other side in case of such series of the > > > > configurations (yes, I have seen some interesting implementations of > > > > the touchpad / touchscreen GPIOs that may be affected). > > > > > > That sounds weird. I think we need to look at how other drivers > > > deal with this. > > > > > > To me it seems more natural that > > > starfive_padctl_rmw(sfp, group->pins[i], mask, value); > > > would get called at the end of each iteration of the > > > for (i = 0; i < num_configs; i++) loop. > > > > That would work, but when the loop is done the end result would be > > exactly the same. > > It seems we interpret the term "result" differently. The result when > we talking about GPIOs is the series of pin state changes incl. > configuration. This is how it should be recognized when programming > hardware. > > > The only difference is that the above would rapidly > > "blink" the different states during the loop until it arrives at the > > result. This would certainly be different, but it can never be the > > intended behaviour and only a side-effect on how the pinctrl framework > > works. > > Is it? That's what I'm trying to get an answer to. If you may > guarantee this (the keywords "intended behaviour" and "side effect"), > I wouldn't object. > > > The order the different states are blinked depends entirely on > > how the pinctrl framework parses the device tree. I still think it > > would be more natural to cleanly go to the end result without this > > blinking. Hmm.. but if going through the different states is what you want, then wouldn't you need the device tree to have an ordered list of the states rather than just a single node and also a way to tune how long time the different states are blinked?