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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 7E2E8C433E7 for ; Fri, 9 Oct 2020 10:02:07 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F3DF22226B for ; Fri, 9 Oct 2020 10:02:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cllfNogl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=microchip.com header.i=@microchip.com header.b="zciX8i+l" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F3DF22226B Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=microchip.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:In-Reply-To:Subject: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=IiJEfzRfl2RyLqJLDFghw5wsXQNo/Rc+jH+/6vl6878=; b=cllfNoglR76+C9sNlB8DgTmYO i7nUF4DGfvYWOcWFG5Bd0J2/gi7/aftKFPBOpIO1nJ1CAVrlhYGN5miOtx9SX+2lPN6H//0TxrawH EZp700UvsXS4Jhamgqf8q7Q0MaIhYZQ8o/2BfQ0khvfDhvjUWYKuk5SBeR46QX51jnNCv2gZwr8At g794uBGFm+/w4A8fYxUkxzi8z290W1AIDnKZ8xQ92G1QUQ5XT6cEZ7m1HYXirtfeEiPCioGgErfD7 DSxmzNpmdnRDxGvj7Tw3B4CE4rP3Df8kMQAHMtQaPqlJwBf9kYues9XfmCzg5Ip25+MxYt86MGHmn 120+tdrTg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQpCl-0006YX-SM; Fri, 09 Oct 2020 10:00:51 +0000 Received: from esa3.microchip.iphmx.com ([68.232.153.233]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQpCj-0006Xc-8l for linux-arm-kernel@lists.infradead.org; Fri, 09 Oct 2020 10:00:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1602237649; x=1633773649; h=references:from:to:cc:subject:in-reply-to:date: message-id:mime-version; bh=r2koRF/+FoeVCXIcl1Bvk7ziipf1D2XLPT0qU0KHzDg=; b=zciX8i+lxUzT65VX+ctDo8cRGCUyN/92eM35c8i/TCzlKVDMMxstGVTA BcwlHr+PQmCosprGCZlrWZew5kNCNTI3bmdXZka/e99pRY7OOPuDmyx7w cn1Lzn0Kywkx6SGZ1/i94eNceDDVwIghr95j3jhhEpi6ToDX9izvbzj2O zbvrK+FR9GYDer0ETLBlOifpiv2nKxP4ziBQcv7s0RYrtyovWw8sq/xG1 d+OI2gHHLrOXYY5nZKBX/iQnLYmZ+qycOXFuxgtjsfeDjyiECrKjiA7gL TkmZ0bc5O0lp1aXhOT+utmixRLeIsJEAP+iX98DZ0+yuAo8NEFLEOMs53 g==; IronPort-SDR: ghWz0aIj1uzQaobiv50hrQZfGc7IJ/f3PL3i5LQhDEys5XsFRlnrIi+7kZiLbnd5AXjfDmE9rd YP6MzHCBmQmwy34XgxJyQ3Cp7nVWPiWIq+UFYwMLkuS6PF+XxEeoQa55iAMKRibOlYdeEXoj+E 0LbBvOhIqnHAGP424wZyndTw4SIFxAEUnZQZ/LdIBnHu7RuwL048bURNrCP+xXNmq+LGGgiWf0 ssgBmBPG2Sb1rTegMzMayw69szmZd2+W70iXF7OSDVlYpOy/h13L11Y1bM/Meq0PLl1xB09gj5 FSY= X-IronPort-AV: E=Sophos;i="5.77,354,1596524400"; d="scan'208";a="94773622" Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa3.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 09 Oct 2020 03:00:46 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 9 Oct 2020 03:00:46 -0700 Received: from soft-dev15.microsemi.net.microchip.com (10.10.115.15) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3 via Frontend Transport; Fri, 9 Oct 2020 03:00:12 -0700 References: <20201008130515.2385825-1-lars.povlsen@microchip.com> <20201008130515.2385825-2-lars.povlsen@microchip.com> From: Lars Povlsen To: Linus Walleij Subject: Re: [PATCH v5 1/3] dt-bindings: pinctrl: Add bindings for pinctrl-microchip-sgpio driver In-Reply-To: Date: Fri, 9 Oct 2020 12:00:43 +0200 Message-ID: <87d01ryb04.fsf@soft-dev15.microsemi.net> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201009_060049_461221_337D205E X-CRM114-Status: GOOD ( 18.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Alexandre Belloni , "linux-kernel@vger.kernel.org" , Microchip Linux Driver Support , "open list:GPIO SUBSYSTEM" , Rob Herring , Lars Povlsen , Linux ARM 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 Linus Walleij writes: > Hi Lars! > > This is overall looking fine. Except for the 3 cell business. I just can't > wrap my head around why that is needed. > > On Thu, Oct 8, 2020 at 3:05 PM Lars Povlsen wrote: > >> + '#gpio-cells': >> + const: 3 > > So at the very least needs a description making it crystal clear why each > cell is needed, and used for since the standard bindings are not used. > > + sgpio_in2: gpio@0 { > + reg = <0>; > + compatible = "microchip,sparx5-sgpio-bank"; > + gpio-controller; > + #gpio-cells = <3>; > + ngpios = <96>; > + }; > > So here reg = 0 and the out port has reg 1. Isn't that what you also put > in the second cell of the GPIO phandle? Then why? The driver > can very well just parse its own reg property and fill that in. Linus, NO! The second cell is the second dimension - NOT the direction. As I wrote previously, the direction is now inherent from the handle, ie. the "reg" value of the handle. The hardware describe a "port" and a "bit index" addressing, where the second cell in gpios = <&sgpio_in2 11 0 GPIO_OUT_LOW>; is the "bit index" - not the "reg" from the phandle. In the example above, note ngpios = <96>; As the "port" is [0; 31], this defines "bit index" to be [0; 2], so the (input) GPIO cells will be: p0b0, p0b1, p0b2 ... p31b0, p31b1, p31b2 being identical to <&sgpio_inX 0 0 GPIO_OUT_LOW> <&sgpio_inX 0 1 GPIO_OUT_LOW> <&sgpio_inX 0 2 GPIO_OUT_LOW> ... <&sgpio_inX 31 0 GPIO_OUT_LOW> <&sgpio_inX 31 1 GPIO_OUT_LOW> <&sgpio_inX 31 2 GPIO_OUT_LOW> ('X' being the SGPIO controller instance). So no, there *really* is a need for a 3-cell GPIO specifier (or whatever its called). Hope this is clearer now... ---Lars > > When you obtain a phandle like that: > > gpios = <&sgpio_in2 11 0 GPIO_OUT_LOW>; > > Isn't that 0 just duplicating the "reg"? Just parse reg when you set up > your driver state and put it as variable in the state container for your > driver state for this particular gpio_chip. No need to get it from > the phandle. > > Yours, > Linus Walleij -- Lars Povlsen, Microchip _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel