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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE93DC54EE9 for ; Tue, 20 Sep 2022 15:17:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231317AbiITPRd (ORCPT ); Tue, 20 Sep 2022 11:17:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231239AbiITPRL (ORCPT ); Tue, 20 Sep 2022 11:17:11 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74B9263F3D for ; Tue, 20 Sep 2022 08:16:54 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id z25so4374997lfr.2 for ; Tue, 20 Sep 2022 08:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=LBJXkuxhmse5P1lyWiiuBqBUGrfjJdoy9vn87fbJbbE=; b=Z8+4YFNvQpl0pK3twnvrjV0GrnqkQyNjD4XoPyfhgQ0kMzL3xC1YdrNlobjz4u0q38 1ZHc3WI5zWPwRyPAiT0x3qVF0tfnsZTAPl0E+d1OgZqXQ1sQSBsb8MltMigMtSqt9p3l QsqpQeQTJ3C+7vcxP9TNIxoorYesosdGLp4anmGPy9K+h4Jp71gIZk7o/nlBoZq0xciT O8AbvGY+uai3Re7ZDT6d2D1Y8u1v3ARaMKpkcmjLFIXufIadSyB2BZmH3v6iok7QpoNd H9NrPUwGlS84FnOGUy9iQiQ1++ZeS7x8yMwqeF+qNNI49iP1WpEohenKwgDWIb8kbr0g bJZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=LBJXkuxhmse5P1lyWiiuBqBUGrfjJdoy9vn87fbJbbE=; b=BsMoN7bstLdUxujCdqLSa7tfxl5U99L35aBHYknr3agrjn2dWIoW47344NXwpBzJw+ drjELr/l+z/hi8nW/ke0aHmZu2a1qcvno2JZh1V1Lt+a7XA0yBFbomwsSqUDD06K1LQN rcd+mgCsWibCJKR3E06jcMzJTJjtP9LLLzLazpZPgEf6SacDgy9f5cbR0L9oxZCVT2yf zszZVg390NRISe3oI+dC93MqgjAhbosZhVk+WVevr+mBcBzkSlUh8UiWF6t0P1egl5Nw NP4PTTNbMOS1HWYeMKQmdvXI5TsbniWJIy97/0nEllO73Jgi9gVWxAuJO0rwy9QrN3Ij i6PA== X-Gm-Message-State: ACrzQf1g/63c5zTWUxwEfEf+B0N7BvrR/7Nm9iDlm7PL3D/vMUmjX/f5 kbfDHDyNsEG+8mCdK4SaArNSSepm/KDUxQ== X-Google-Smtp-Source: AMsMyM6SQUnreP+sl7ZN5I5Dmk/k+y1Uh7VFe8XVZJXlGsEPqcb7RcbafqbaRJ+eNvNUYZ9pOjY5PQ== X-Received: by 2002:a05:6512:32c1:b0:49f:5c95:5146 with SMTP id f1-20020a05651232c100b0049f5c955146mr6050239lfg.469.1663687012826; Tue, 20 Sep 2022 08:16:52 -0700 (PDT) Received: from [192.168.0.21] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id du8-20020a056512298800b00492f0f66956sm351627lfb.284.2022.09.20.08.16.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Sep 2022 08:16:52 -0700 (PDT) Message-ID: Date: Tue, 20 Sep 2022 17:16:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v2 1/2] dt-binding: pinctrl: Add NPCM8XX pinctrl and GPIO documentation Content-Language: en-US To: Tomer Maimon Cc: Rob Herring , Avi Fishman , Tali Perry , Joel Stanley , Patrick Venture , Nancy Yuen , Benjamin Fair , Linus Walleij , Krzysztof Kozlowski , =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= , zhengbin13@huawei.com, OpenBMC Maillist , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , devicetree References: <20220714122322.63663-1-tmaimon77@gmail.com> <20220714122322.63663-2-tmaimon77@gmail.com> <20220718211046.GA3547663-robh@kernel.org> <3981e6e8-d4bb-b13d-7aaa-7aea83ffaad9@linaro.org> <2b0e6e33-ef76-4bd4-8894-53f9a3fe68b4@linaro.org> <6f1ad082-74e4-e4e7-9304-5cdd95cc9f66@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On 20/09/2022 11:27, Tomer Maimon wrote: > On Tue, 20 Sept 2022 at 11:47, Krzysztof Kozlowski > wrote: >> >> On 20/09/2022 10:32, Tomer Maimon wrote: >>> On Tue, 20 Sept 2022 at 11:21, Krzysztof Kozlowski >>> wrote: >>>> >>>> On 20/09/2022 09:59, Tomer Maimon wrote: >>>>>>>>>>> + pinctrl: pinctrl@f0800000 { >>>>>>>>>>> + compatible = "nuvoton,npcm845-pinctrl"; >>>>>>>>>>> + ranges = <0x0 0x0 0xf0010000 0x8000>; >>>>>>>>>>> + #address-cells = <1>; >>>>>>>>>>> + #size-cells = <1>; >>>>>>>>>>> + nuvoton,sysgcr = <&gcr>; >>>>>>>>>>> + >>>>>>>>>>> + gpio0: gpio@f0010000 { >>>>>>>>>> >>>>>>>>>> gpio@0 >>>>>>>>>> >>>>>>>>>> Is this really a child block of the pinctrl? Doesn't really look like it >>>>>>>>>> based on addressess. Where are the pinctrl registers? In the sysgcr? If >>>>>>>>>> so, then pinctrl should be a child of it. But that doesn't really work >>>>>>>>>> too well with gpio child nodes... >>>>>>>>> the pin controller mux is handled by sysgcr this is why the sysgcr in >>>>>>>>> the mother node, >>>>>>>>> and the pin configuration are handled by the GPIO registers. each >>>>>>>>> GPIO bank (child) contains 32 GPIO. >>>>>>>>> this is why the GPIO is the child node. >>>>>>>> >>>>>>>> Then maybe pinctrl should be the sysgcr and expose regmap for other devices? >>>>>>> The pin controller using the sysgcr to handle the pinmux, this is why >>>>>>> the sysgcr is in the mother node, is it problematic? >>>>>> >>>>>> You said pin-controller mux registers are in sysgcr, so it should not be >>>>>> used via syscon. >>>>> Sorry but maybe I missed something. >>>>> the sysgcr is used for miscellaneous features and not only for the pin >>>>> controller mux, this is why it used syscon and defined in the dtsi: >>>>> gcr: system-controller@f0800000 { >>>>> compatible = "nuvoton,npcm845-gcr", "syscon"; >>>>> reg = <0x0 0xf0800000 0x0 0x1000>; >>>>> }; >>>>>> >>>>>> Please provide address map description to convince us that this is >>>>>> correct HW representation. >>>>> GCR (sysgcr) registers 0xf0800000-0xf0801000 - used for miscellaneous >>>>> features, not only pin mux. >>>>> GPIO0 0xf0010000-0xf0011000 >>>>> GPIO1 0xf0011000-0xf0012000 >>>>> ... >>>>> GPIO7 0xf0017000-0xf0018000 >>>>>> >>>> >>>> Then why your pinctrl is in sysgcr IO range? (pinctrl@f0800000) >>> you suggest using pinctrl@0 or pinctrl@f0010000 and not >>> pinctrl@f0800000 because 0xf0800000 is the GCR address that serve >>> miscellaneous features and not only pinmux controller ? >> >> If you have a map like you pasted, then DTS like this: >> >> syscon@f0800000 {} >> pinctrl@f0800000 { >> gpio@f0010000 {} >> } >> >> Is quite weird, don't you think? You have two devices on the same unit >> address which is not allowed. You have child of pinctrl with entirely > O.K. >> different unit address, so how is it its child? > The pinctrl node name will modify the pinctrl@f0010000 the same as the > range property and the start of the child registers,is it fine? We are all busy, so I don't have that much bandwidth to review each of your many solutions and instead poking me with every possible solution, I would prefer if you think a bit how this all should work and look. I don't know if it is fine. Why you should have two devices like this: pinctrl@f0010000 { gpio@f0010000 {} } ??? Instead of one device? Answer such questions to yourself before asking me. Please come with reasonable DTS describing the hardware. Best regards, Krzysztof