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=-17.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 9EB9FC4338F for ; Wed, 18 Aug 2021 09:55:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7C36161058 for ; Wed, 18 Aug 2021 09:55:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233118AbhHRJzs (ORCPT ); Wed, 18 Aug 2021 05:55:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233074AbhHRJzq (ORCPT ); Wed, 18 Aug 2021 05:55:46 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1ED0C061764 for ; Wed, 18 Aug 2021 02:55:11 -0700 (PDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1mGIHn-0002rK-3S; Wed, 18 Aug 2021 11:55:03 +0200 Subject: Re: [PATCH V3 2/3] dt-bindings: gpio: zynqmp: Add binding documentation for modepin To: Michal Simek , Piyush Mehta , arnd@arndb.de, zou_wei@huawei.com, gregkh@linuxfoundation.org, linus.walleij@linaro.org, wendy.liang@xilinx.com, iwamatsu@nigauri.org, bgolaszewski@baylibre.com, robh+dt@kernel.org, rajan.vaja@xilinx.com Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, git@xilinx.com, sgoud@xilinx.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Pengutronix Kernel Team References: <20210818081018.2620544-1-piyush.mehta@xilinx.com> <20210818081018.2620544-3-piyush.mehta@xilinx.com> <5e44ee87-f727-99fd-9860-d3d58a035dc4@pengutronix.de> <50e468b1-9a32-0017-bd6a-8d47c3fa1a9c@xilinx.com> From: Ahmad Fatoum Message-ID: <4a724736-8bb9-a21d-974c-d9598c3d7b37@pengutronix.de> Date: Wed, 18 Aug 2021 11:55:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <50e468b1-9a32-0017-bd6a-8d47c3fa1a9c@xilinx.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-gpio@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On 18.08.21 11:38, Michal Simek wrote: > Hi Ahmad, > > On 8/18/21 11:00 AM, Ahmad Fatoum wrote: >> On 18.08.21 10:10, Piyush Mehta wrote: >>> This patch adds DT binding document for zynqmp modepin GPIO controller. >>> Modepin GPIO controller has four GPIO pins which can be configurable >>> as input or output. >>> >>> Modepin driver is a bridge between the peripheral driver and GPIO pins. >>> It has set and get APIs for accessing GPIO pins, based on the device-tree >>> entry of reset-gpio property in the peripheral driver, every pin can be >>> configured as input/output and trigger GPIO pin. >>> >>> For more information please refer zynqMp TRM link: >>> Link: https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf >>> Chapter 2: Signals, Interfaces, and Pins >>> Table 2-2: Clock, Reset, and Configuration Pins - PS_MODE >>> >>> Signed-off-by: Piyush Mehta >>> Acked-by: Michal Simek >>> --- >>> Changes in v2: >>> - Addressed review comments: Update commit message >>> >>> Review Comments: >>> https://lore.kernel.org/linux-arm-kernel/20210615080553.2021061-2-piyush.mehta@xilinx.com/T/#mbd1fbda813e33b19397b350bde75747c92a0d7e1 >>> https://lore.kernel.org/linux-arm-kernel/20210615080553.2021061-2-piyush.mehta@xilinx.com/T/#me82b1444ab3776162cdb0077dfc9256365c7e736 >>> >>> Changes in v3: >>> - Addressed Rob and Michal review comments: >>> - Update DT example. >>> >>> Review Comments: >>> https://lore.kernel.org/linux-arm-kernel/YRbBnRS0VosXcZWz@robh.at.kernel.org/ >>> https://lore.kernel.org/linux-arm-kernel/d71ad7f9-6972-8cc0-6dfb-b5306c9900d0@xilinx.com/ >>> --- >>> .../bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml | 41 ++++++++++++++++++++++ >>> .../bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml | 43 ++++++++++++++++++++++ >>> 1 file changed, 43 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml >>> new file mode 100644 >>> index 0000000..1442815 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml >>> @@ -0,0 +1,43 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: "http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#" >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#" >>> + >>> +title: ZynqMP Mode Pin GPIO controller >>> + >>> +description: >>> + PS_MODE is 4-bits boot mode pins sampled on POR deassertion. Mode Pin >>> + GPIO controller with configurable from numbers of pins (from 0 to 3 per >>> + PS_MODE). Every pin can be configured as input/output. >> So, at Linux runtime, someone decides to boot the system into e.g. a USB >> recovery mode and then toggles the appropriate GPIOs and does a system >> reset? >> >> If so, are you aware of the reboot mode[1] infrastructure? >> >> A reboot-mode-gpio driver on top of this GPIO controller would allow you >> to describe the supported reboot modes in the device tree and instead of >> exporting GPIOs to userspace, users can then just do >> >> systemctl restart recovery >> >> to toggle the appropriate bits. >> >> Also to be sure: PS_MODE are actual GPIO pins that you could toggle >> board level components with, right? i.e. it's not just a register that >> overrides the values read from the boot mode pins? (In the latter case >> a syscon-reboot-mode without GPIO controller would be the correct >> abstraction). >> >> [1]: drivers/power/reset/reboot-mode.c > > Thanks for these links. I wasn't aware about it. > But this device/IP is not working like this. Changing gpios to certain > state won't ensure that on reboot/reset (done in whatever way) won't > stay on values you chose. Ah, the "PS_MODE is 4-bits boot mode pins sampled on POR deassertion" part misled me. These pins are sampled on startup, but can afterwards be reused via talking to firmware. Thanks for clearing this up. > modepin gpio driver is at BOOT_PIN_CTRL 0xFF5E0250 > > (To be fair if you add additional external chip it could work like this > but I have never seen it). Ye, that would've been strange, that's why I asked. :) > But when you bring this up. Xilinx ZynqMP is providing a way how to > setup alternative boot mode which is done via > BOOT_MODE_USER 0xFF5E0200 > Bit 8 and 15-12. > Then you can setup any bootmode. > > ZynqMP supports couple of modes listed here > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-zynqmp/include/mach/hardware.h#L73 > > but again routing to this register needs to be done via firmware > interface but it should be done via separate driver. Yes. > Is there an option to setup whatever modes you like? > > I mean to simply cover all modes like this? > > mode-jtag = <0>; > mode-sd = <3>; > mode-sd1 = <5>; Yes, you can define the supported modes in the SoC dtsi and boards inherit that and can extend it as necessary. > And then users/customers can say what normal/recovery/test modes are. Yes, that would be nice. But after your clarification, I see that it's unrelated to this patch series. Binding is fine. Question on driver is still applicable. Cheers, Ahmad > > Thanks, > Michal > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | 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=-17.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 54BD8C4338F for ; Wed, 18 Aug 2021 09:57:38 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 2137C6108E for ; Wed, 18 Aug 2021 09:57:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2137C6108E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=sqzop/cObC2x7ATOAe8nKM6+FCdtVbCnEb6YR5DkIEw=; b=LfuDQKNDLTa0Lmhk0fZtQjUS2H xVkSXeNVOg+S1YhE5/bqHaLz+TshZ/f9sQ9afGUXatywkHm3pmaN0Mjz3DzwiLak8SR2bHB3UtMUu GoRRRIStnypfyZvKLp42N6FuBhZkmyH6cnRmE445Gg4OmxX3SBQXi2TagW5HzuPfvEtJBVBh++1Tq dIbQcKezgxkKS7zJFjVIIvMMIau46YugoBvl7HEGsX+9OkFhcX4NL6k+ev9CtnFg4EcghAYpZrb8M GDsMCRHEFEXcIPqbszNf7B4fDFY9DCG06Xh/vZf1DwOWfGZD0C4MSvk6o76AGWJ6NTVZo1c6WFoRm aFheed7g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGIHz-0050fi-Ml; Wed, 18 Aug 2021 09:55:15 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mGIHo-0050ea-WC for linux-arm-kernel@lists.infradead.org; Wed, 18 Aug 2021 09:55:13 +0000 Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1mGIHn-0002rK-3S; Wed, 18 Aug 2021 11:55:03 +0200 Subject: Re: [PATCH V3 2/3] dt-bindings: gpio: zynqmp: Add binding documentation for modepin To: Michal Simek , Piyush Mehta , arnd@arndb.de, zou_wei@huawei.com, gregkh@linuxfoundation.org, linus.walleij@linaro.org, wendy.liang@xilinx.com, iwamatsu@nigauri.org, bgolaszewski@baylibre.com, robh+dt@kernel.org, rajan.vaja@xilinx.com Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, git@xilinx.com, sgoud@xilinx.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Pengutronix Kernel Team References: <20210818081018.2620544-1-piyush.mehta@xilinx.com> <20210818081018.2620544-3-piyush.mehta@xilinx.com> <5e44ee87-f727-99fd-9860-d3d58a035dc4@pengutronix.de> <50e468b1-9a32-0017-bd6a-8d47c3fa1a9c@xilinx.com> From: Ahmad Fatoum Message-ID: <4a724736-8bb9-a21d-974c-d9598c3d7b37@pengutronix.de> Date: Wed, 18 Aug 2021 11:55:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <50e468b1-9a32-0017-bd6a-8d47c3fa1a9c@xilinx.com> Content-Language: en-US X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: a.fatoum@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210818_025505_109447_77F04475 X-CRM114-Status: GOOD ( 40.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On 18.08.21 11:38, Michal Simek wrote: > Hi Ahmad, > > On 8/18/21 11:00 AM, Ahmad Fatoum wrote: >> On 18.08.21 10:10, Piyush Mehta wrote: >>> This patch adds DT binding document for zynqmp modepin GPIO controller. >>> Modepin GPIO controller has four GPIO pins which can be configurable >>> as input or output. >>> >>> Modepin driver is a bridge between the peripheral driver and GPIO pins. >>> It has set and get APIs for accessing GPIO pins, based on the device-tree >>> entry of reset-gpio property in the peripheral driver, every pin can be >>> configured as input/output and trigger GPIO pin. >>> >>> For more information please refer zynqMp TRM link: >>> Link: https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf >>> Chapter 2: Signals, Interfaces, and Pins >>> Table 2-2: Clock, Reset, and Configuration Pins - PS_MODE >>> >>> Signed-off-by: Piyush Mehta >>> Acked-by: Michal Simek >>> --- >>> Changes in v2: >>> - Addressed review comments: Update commit message >>> >>> Review Comments: >>> https://lore.kernel.org/linux-arm-kernel/20210615080553.2021061-2-piyush.mehta@xilinx.com/T/#mbd1fbda813e33b19397b350bde75747c92a0d7e1 >>> https://lore.kernel.org/linux-arm-kernel/20210615080553.2021061-2-piyush.mehta@xilinx.com/T/#me82b1444ab3776162cdb0077dfc9256365c7e736 >>> >>> Changes in v3: >>> - Addressed Rob and Michal review comments: >>> - Update DT example. >>> >>> Review Comments: >>> https://lore.kernel.org/linux-arm-kernel/YRbBnRS0VosXcZWz@robh.at.kernel.org/ >>> https://lore.kernel.org/linux-arm-kernel/d71ad7f9-6972-8cc0-6dfb-b5306c9900d0@xilinx.com/ >>> --- >>> .../bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml | 41 ++++++++++++++++++++++ >>> .../bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml | 43 ++++++++++++++++++++++ >>> 1 file changed, 43 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml >>> new file mode 100644 >>> index 0000000..1442815 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.yaml >>> @@ -0,0 +1,43 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: "http://devicetree.org/schemas/gpio/xlnx,zynqmp-gpio-modepin.yaml#" >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#" >>> + >>> +title: ZynqMP Mode Pin GPIO controller >>> + >>> +description: >>> + PS_MODE is 4-bits boot mode pins sampled on POR deassertion. Mode Pin >>> + GPIO controller with configurable from numbers of pins (from 0 to 3 per >>> + PS_MODE). Every pin can be configured as input/output. >> So, at Linux runtime, someone decides to boot the system into e.g. a USB >> recovery mode and then toggles the appropriate GPIOs and does a system >> reset? >> >> If so, are you aware of the reboot mode[1] infrastructure? >> >> A reboot-mode-gpio driver on top of this GPIO controller would allow you >> to describe the supported reboot modes in the device tree and instead of >> exporting GPIOs to userspace, users can then just do >> >> systemctl restart recovery >> >> to toggle the appropriate bits. >> >> Also to be sure: PS_MODE are actual GPIO pins that you could toggle >> board level components with, right? i.e. it's not just a register that >> overrides the values read from the boot mode pins? (In the latter case >> a syscon-reboot-mode without GPIO controller would be the correct >> abstraction). >> >> [1]: drivers/power/reset/reboot-mode.c > > Thanks for these links. I wasn't aware about it. > But this device/IP is not working like this. Changing gpios to certain > state won't ensure that on reboot/reset (done in whatever way) won't > stay on values you chose. Ah, the "PS_MODE is 4-bits boot mode pins sampled on POR deassertion" part misled me. These pins are sampled on startup, but can afterwards be reused via talking to firmware. Thanks for clearing this up. > modepin gpio driver is at BOOT_PIN_CTRL 0xFF5E0250 > > (To be fair if you add additional external chip it could work like this > but I have never seen it). Ye, that would've been strange, that's why I asked. :) > But when you bring this up. Xilinx ZynqMP is providing a way how to > setup alternative boot mode which is done via > BOOT_MODE_USER 0xFF5E0200 > Bit 8 and 15-12. > Then you can setup any bootmode. > > ZynqMP supports couple of modes listed here > https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-zynqmp/include/mach/hardware.h#L73 > > but again routing to this register needs to be done via firmware > interface but it should be done via separate driver. Yes. > Is there an option to setup whatever modes you like? > > I mean to simply cover all modes like this? > > mode-jtag = <0>; > mode-sd = <3>; > mode-sd1 = <5>; Yes, you can define the supported modes in the SoC dtsi and boards inherit that and can extend it as necessary. > And then users/customers can say what normal/recovery/test modes are. Yes, that would be nice. But after your clarification, I see that it's unrelated to this patch series. Binding is fine. Question on driver is still applicable. Cheers, Ahmad > > Thanks, > Michal > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel