Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4431825pxk; Wed, 30 Sep 2020 02:48:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy+LaXorp1PA9KhglBZTcgig4O25KV4yfUsRToZZhd9AmQxvsATvW4Elr6v997v0jT7lZxZ X-Received: by 2002:a17:906:b790:: with SMTP id dt16mr1838458ejb.33.1601459334739; Wed, 30 Sep 2020 02:48:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601459334; cv=none; d=google.com; s=arc-20160816; b=tOTvZ6BxEoVZtfO0VBpIT8r2Ml6vZbzr4+pE6U8iltEGUCqacy2Ziq7yb1lTYO1Rfz h/wAe5tmO44hH6h5KrhZ5eZdDTH2IP2JR6y9Z9Ovp9sfo53qynpnTjOSxtFrlT2FSwb9 cLuWOIFQazOTROQfuuYuXma9qlXbDQNIIAYphxsslrSypCOiWAnvs6nXomM/YpOVjpm0 LlP7pATKIqYI1Ax9a9XLz5fXKrA8rZgL3GmXEGibXKKd2pdgDlXxNwUGQEumTtPuB2+F 9LUPhbPS1hxqfkAsHqJzLNAjDer7NExmS8iTMqaoQnxJZdbeIOvO1z8WNTaEduJg53+s hxIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=y9ttEkJT1YOblIvecvoaL7ysQOGmPWA7WuaJhcDTjsQ=; b=Y7Cx/Sr/Fbw5GVQKrk8m8+JdDp2Fsu+rhQHMzDoBUCakV+Xa/6vpdHig+n93oNOLSV BHNa3pG7bby7/kvvsAudQixBHFw34xthbWsvsEblm5D59tFHU/yQ105UoGXLVsKMKuSD gDGErTOLwjnGANaoKWsLqJj3BneixnDWg5AqUAJ3B8h1eUs8N37BTFwdfEAIM7/YZqmo 0Mn9N8yNAvBJXFpvflRBsNPDcCD3LQu+jXhJvbEqfsdAG+08qJgxm9mZY7CxbqNTvLTh EMvD1JjJl9AkHQSfT/3qxAdCx/k9Zw/68ocIGZqEN296UiBzA2Qx0DBhpjVzboMfg/3P d5Dg== 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 v2si637270edq.434.2020.09.30.02.48.30; Wed, 30 Sep 2020 02:48:54 -0700 (PDT) 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 S1729077AbgI3JrW (ORCPT + 99 others); Wed, 30 Sep 2020 05:47:22 -0400 Received: from muru.com ([72.249.23.125]:45762 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728999AbgI3JrU (ORCPT ); Wed, 30 Sep 2020 05:47:20 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 7435E810D; Wed, 30 Sep 2020 09:47:20 +0000 (UTC) Date: Wed, 30 Sep 2020 12:47:14 +0300 From: Tony Lindgren To: Trent Piepho Cc: Drew Fustini , Rob Herring , Linus Walleij , Jason Kridner , Robert Nelson , linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio , Christina Quast Subject: Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2 Message-ID: <20200930094714.GR9471@atomide.com> References: <20200924054324.GB9471@atomide.com> <20200924060645.GD9471@atomide.com> <20200924070443.GF9471@atomide.com> <20200930051521.GN9471@atomide.com> <20200930091526.GQ9471@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Trent Piepho [200930 09:34]: > On Wed, Sep 30, 2020 at 2:15 AM Tony Lindgren wrote: > > > > * Trent Piepho [200930 08:35]: > > > The closest thing would be the generic pin config type bindings, which > > > go in the pinctrl driver's nodes, and look like this: > > > &am335x_pinmux { > > > pinctrl_yoyo_reset: yoyogrp { > > > pins = "foo"; > > > function = "gpio"; > > > bias-pull-up; > > > }; > > > }; > > > > There's a bit of a dtb size and boot time issue for adding properties > > for each pin where that needs to be done for several hundred pins :) > > pins is list, multiple pins can be specified at once. Otherwise the > property name would be "pin" and not "pins" There's also a groups > property to refer to multiple pins at once, e.g. > > arch/mips/boot/dts/ingenic/ci20.dts- pins_mmc1: mmc1 { > arch/mips/boot/dts/ingenic/ci20.dts- function = "mmc1"; > arch/mips/boot/dts/ingenic/ci20.dts: groups = > "mmc1-1bit-d", "mmc1-4bit-d"; > arch/mips/boot/dts/ingenic/ci20.dts- bias-disable; > arch/mips/boot/dts/ingenic/ci20.dts- }; > > arch/mips/boot/dts/pic32/pic32mzda_sk.dts- user_leds_s0: user_leds_s0 { > arch/mips/boot/dts/pic32/pic32mzda_sk.dts: pins = "H0", "H1", "H2"; > arch/mips/boot/dts/pic32/pic32mzda_sk.dts- output-low; > arch/mips/boot/dts/pic32/pic32mzda_sk.dts- microchip,digital; > arch/mips/boot/dts/pic32/pic32mzda_sk.dts- }; Right. > > > Is "some additional property for specifying generic conf flags" > > > different from the existing pinctrl-single,bias-pullup, etc. > > > properties? Because splitting the data cell into two parts doesn't > > > make any difference to those. > > > > So with an interrupt style binding with generic pinconf flags we can > > leave out the parsing of multiple properties for each pin. Sure the > > pin is only referenced by the controller like you pointed out but the > > pinconf flags could be generic. > > Where do these flags go? In pinctrl-single,pins? Like: > > pinctrl-single,pins = ; > > But PIN_INPUT_PULLUP is a generic flag? Which is translated into the > proper value by?? Yes that's what I was thinking, something like this with generic flags: pinctrl-single,pins = ; > Or are you talking about replacing the existing pinctrl-0, > pinctrl-names properties with a totally different system that looks > more like gpio and interrupt handles? That would be even better :) Might be just too much to deal with.. In any case the parser code could already be generic if we had generic flags based on #pinctrl-cells. Regards, Tony