Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp966560imm; Wed, 23 May 2018 08:14:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqWReU9Sr9RQc23UwpAFpnrLvqZvzONEVUugDE33FqHLwkjfj/kPlQ6ZVGBIYZNWdHYqCy/ X-Received: by 2002:a65:608c:: with SMTP id t12-v6mr2596798pgu.182.1527088443174; Wed, 23 May 2018 08:14:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527088443; cv=none; d=google.com; s=arc-20160816; b=jTxY0jn8Y/w1ivegjTe49t3IE0BSdCkGbv5yBQDIUwUFQu+K4jSCHQYf8MS4Iny0Ue JLiaTsNHO4K16aUXYzfhHguKfdhk4CXzFGdpZVRLN/cmDU4xE39AmiQr19e2ncMtCeaM LIz5Sml1w1CKlLlwMpIsMpDQwPtLXTXdDfqypXOfFZGvAxa3aK8rfINmYAlRuoc5AYJf rk04o+LooI/iZmNOpDSJhecOlTCVZoE6zfLOExO1Yfl0MpvD6kfwqmAo5ohQc/xKBCN5 HEmsP/4i7XNb0nbD4/vnPICav+9lodx4l+TB977zdqLmkDfAsJKn3ATAalAF7n/s1r4s gR9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=IlyVaanBj3KKcmcOoXaJY6g5eva2P3EdAd3TrsIZe1M=; b=Lfjy8JOEOaXiJJ7fHS+cXYZo4OL28+bdMIvbxVQ8lgUd3N3qosO9ppUdThm3yWUYge e9Hv/9IlKVka45/1XVRvqCtV/FNkadZ6eYkdxr+BZ7faUn2dezgv+oDeBB4GMJ6b+6+h wqQ8TKSi8sgBkyK/pnP70knqWDU79GoGVnE+oS+3rRXyFLiW6fspsrAPsOyVxYj1iRYh MGCZyFVzVH7DZTpbx8sLNupQ0AhGdG4DlWZICt2OWHBa6fsu2yyTOfFKDRYkEfMDIyD1 NgBRrvvON+s9rU7r3lFrX60dVU07uY2yY6+KpAIf3wKKxHx4AFRwCYklCKFKA5pHPOyE 4gUg== ARC-Authentication-Results: i=1; mx.google.com; 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 o3-v6si18219599pls.64.2018.05.23.08.13.45; Wed, 23 May 2018 08:14:03 -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; 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 S933555AbeEWPM3 (ORCPT + 99 others); Wed, 23 May 2018 11:12:29 -0400 Received: from gloria.sntech.de ([95.129.55.99]:48012 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933522AbeEWPMW (ORCPT ); Wed, 23 May 2018 11:12:22 -0400 Received: from ip9234b5ac.dynamic.kabel-deutschland.de ([146.52.181.172] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1fLVQx-0007bh-GF; Wed, 23 May 2018 17:12:11 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Rob Herring Cc: Levin Du , "open list:ARM/Rockchip SoC..." , Wayne Chou , devicetree@vger.kernel.org, Linus Walleij , "linux-kernel@vger.kernel.org" , "open list:GPIO SUBSYSTEM" , Mark Rutland , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Subject: Re: [PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip Date: Wed, 23 May 2018 17:12:10 +0200 Message-ID: <1685755.J6GI985WX3@diego> In-Reply-To: References: <1526614328-6869-1-git-send-email-djw@t-chip.com.cn> <6ffb43dc-55a5-14eb-eb18-3a731cdaf424@t-chip.com.cn> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, Levin, sorry for being late to the party. Am Mittwoch, 23. Mai 2018, 16:43:07 CEST schrieb Rob Herring: > On Tue, May 22, 2018 at 9:02 PM, Levin Du wrote: > > On 2018-05-23 2:02 AM, Rob Herring wrote: > >> On Fri, May 18, 2018 at 11:52:05AM +0800, djw@t-chip.com.cn wrote: > >>> From: Levin Du > >>> > >>> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs, > >>> which do not belong to the general pinctrl. > >>> > >>> Adding gpio-syscon support makes controlling regulator or > >>> LED using these special pins very easy by reusing existing > >>> drivers, such as gpio-regulator and led-gpio. > >>> > >>> Signed-off-by: Levin Du > >>> > >>> --- > >>> > >>> Changes in v2: > >>> - Rename gpio_syscon10 to gpio_mute in doc > >>> > >>> Changes in v1: > >>> - Refactured for general gpio-syscon usage for Rockchip SoCs. > >>> - Add doc rockchip,gpio-syscon.txt > >>> > >>> .../bindings/gpio/rockchip,gpio-syscon.txt | 41 > >>> > >>> ++++++++++++++++++++++ > >>> > >>> drivers/gpio/gpio-syscon.c | 30 > >>> > >>> ++++++++++++++++ > >>> > >>> 2 files changed, 71 insertions(+) > >>> create mode 100644 > >>> > >>> Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt > >>> b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt > >>> new file mode 100644 > >>> index 0000000..b1b2a67 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt > >>> @@ -0,0 +1,41 @@ > >>> +* Rockchip GPIO support for GRF_SOC_CON registers > >>> + > >>> +Required properties: > >>> +- compatible: Should contain "rockchip,gpio-syscon". > >>> +- gpio-controller: Marks the device node as a gpio controller. > >>> +- #gpio-cells: Should be two. The first cell is the pin number and > >>> + the second cell is used to specify the gpio polarity: > >>> + 0 = Active high, > >>> + 1 = Active low. > >> > >> There's no need for this child node. Just make the parent node a gpio > >> controller. > >> > >> Rob > > > > Hi Rob, it is not clear to me. Do you suggest that the grf node should be > > a > > gpio controller, > > like below? > > > > + grf: syscon at ff100000 { > > + compatible = "rockchip,gpio-syscon", "rockchip,rk3328-grf", > > "syscon", "simple-mfd"; > > Yes, but drop "rockchip,gpio-syscon" and "simple-mfd". I would disagree quite a bit here. The grf are the "general register files", a bunch of registers used for quite a lot of things, and so it seems among other users, also a gpio-controller for some more random pins not controlled through the regular gpio controllers. For a more fully stocked grf, please see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288.dtsi#n855 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399.dtsi#n1338 So the gpio controller should definitly also be a subnode. The gpio in question is called "mute", so I'd think the gpio-syscon driver should just define a "rockchip,rk3328-gpio-mute" compatible and contain all the register voodoo in the driver itself and not define it in the dt. So it should probably look like grf: syscon at ff100000 { compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd"; [all the other syscon sub-devices] gpio_mute: gpio-mute { compatible = "rockchip,rk3328-gpio-mute"; gpio-controller; #gpio-cells = <2>; }; [more other syscon sub-devices] }; Heiko > > + //... > > + gpio-controller; > > + #gpio-cells = <2>; > > + gpio,syscon-dev = <&grf 0x0428 0>; > > And drop this. It may be used in the kernel, but it is not a > documented property. > > > + }; > > > > or just reserve the following case in the doc? > > > > + grf: syscon at ff100000 { > > + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd"; > > + //... > > + }; > > + > > + gpio_mute: gpio-mute { > > + compatible = "rockchip,gpio-syscon"; > > + gpio-controller; > > + #gpio-cells = <2>; > > + gpio,syscon-dev = <&grf 0x0428 0>; > > + }; > > > > > > Thanks > > Levin > > > > -- > > To unsubscribe from this list: send the line "unsubscribe devicetree" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html