From: Stephen Warren <swarren@wwwdotorg.org>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Stéphane Marchesin" <stephane.marchesin@gmail.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
"Alexander Holler" <holler@ahsoftware.de>,
"Grant Likely" <grant.likely@linaro.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Pawel Moll" <pawel.moll@arm.com>,
"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
"Kumar Gala" <galak@codeaurora.org>,
"Russell King" <linux@arm.linux.org.uk>,
"Alexandre Courbot" <gnurou@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 02/21] ARM: tegra: Add gpio-ranges property
Date: Thu, 28 May 2015 09:50:18 -0600 [thread overview]
Message-ID: <5567393A.6000901@wwwdotorg.org> (raw)
In-Reply-To: <CAAObsKB-ayRd7OB1W9nYBJzvBDK0RZk1U56Gqxn08sHPT5FvzA@mail.gmail.com>
On 05/28/2015 02:26 AM, Tomeu Vizoso wrote:
> On 27 May 2015 at 16:49, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 05/27/2015 08:18 AM, Tomeu Vizoso wrote:
>>>
>>> On 26 May 2015 at 21:41, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>
>>>> On 05/25/2015 08:53 AM, Tomeu Vizoso wrote:
>>>>>
>>>>>
>>>>> Specify how the GPIOs map to the pins in T124, so the dependency is
>>>>> explicit.
>>>>>
>>>>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>>>>> ---
>>>>> arch/arm/boot/dts/tegra124.dtsi | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/tegra124.dtsi
>>>>> b/arch/arm/boot/dts/tegra124.dtsi
>>>>> index 13cc7ca..5d1d35f 100644
>>>>> --- a/arch/arm/boot/dts/tegra124.dtsi
>>>>> +++ b/arch/arm/boot/dts/tegra124.dtsi
>>>>> @@ -254,6 +254,7 @@
>>>>> gpio-controller;
>>>>> #interrupt-cells = <2>;
>>>>> interrupt-controller;
>>>>> + gpio-ranges = <&pinmux 0 0 250>;
>>>>
>>>>
>>>>
>>>> We should be consistent between SoCs. Why not make the same change for
>>>> all
>>>> Tegra SoCs?
>>>>
>>>> I think this change will cause the GPIO subsystem to call into the
>>>> pinctrl
>>>> subsystem and create/add/register a new GPIO<->pinctrl range structure.
>>>> The
>>>> pinctrl driver already does this, so I think we'll end up with two
>>>> duplicate
>>>> entries in the pinctrl device's gpio_ranges list. This probably won't
>>>> cause
>>>> a problem, but I wanted to make sure you'd thought about it to make sure.
>>>
>>>
>>> Actually, I have checked and see that gpio-tegra.c registers 256
>>> gpios, but pinctrl-tegra124.c adds a range of only 251. I don't really
>>> remember where I got the 250 value from, sorry :(
>>>
>>> I don't see how that would cause any concrete problems, but maybe we
>>> should have a single authoritative source (not sure we can do so
>>> without breaking DT ABI though).
>>>
>>>> Right now, I think we get lucky and pinctrl ends up probing first (or at
>>>> least very early) anyway. Somewhat related to this series, I wonder if we
>>>> shouldn't add pinctrl client properties to every node in the Tegra DT
>>>> that
>>>> describes a controller that makes use of external pins that are affected
>>>> by
>>>> the pinmux. Such a change would guarantee this desired probing order. In
>>>> order to preserve the "program the entire pinmux at once" semantics,
>>>> these
>>>> new pinctrl client properties would all need to reference empty states,
>>>> yet
>>>> would still need to exist to represent the dependency.
>>>
>>>
>>> I think so, but aren't almost all those pins used as gpios? If so,
>>> then such a controller's driver will request the gpio it wants which
>>> will cause the gpio driver to be registered (and hopefully probed) if
>>> needed, which in turn will check that the corresponding pinctrl device
>>> has been registered. Or am I missing something?
>>
>>
>> As you say this probably works out fine for pins that are used as GPIOs. I
>> was thinking more about SFIOs. Take an I2C controller, which doesn't use any
>> GPIOs itself. The pinctrl device should be probed before the I2C device, so
>> that the I2C driver can initiate transactions on the I2C bus during its
>> probe if it wanted to (or at least, clients could initiate transactions at
>> any completely arbitrary time as soon as probe was complete).
>
> What is using the SFIO in this case, the I2C master or the I2C client?
The I2C controller a/k/a the I2C master.
> In any case, is the problem you are referring to that ICs may rely on
s/ICs/drivers/ I think.
> a specific pinmux configuration but that's not currently reflected on
> the DT because pinmux configuration happened so early that things just
> worked?
Yes; the dependency of some nodes on pinctrl isn't explicitly called out
in the DT. It's probably not a good idea to have such implicit
dependencies, although I suppose for something so central as pinmux,
maybe it's not terrible, since almost everything depends on it and it's
pretty obvious.
next prev parent reply other threads:[~2015-05-28 15:50 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-25 14:53 [PATCH 00/21] On-demand device registration Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 01/21] regulator: core: Reduce critical area in _regulator_get Tomeu Vizoso
2015-05-25 17:18 ` Mark Brown
2015-05-25 17:45 ` Mark Brown
2015-05-25 14:53 ` [PATCH 02/21] ARM: tegra: Add gpio-ranges property Tomeu Vizoso
2015-05-26 19:41 ` Stephen Warren
2015-05-27 14:18 ` Tomeu Vizoso
2015-05-27 14:49 ` Stephen Warren
2015-05-28 8:26 ` Tomeu Vizoso
2015-05-28 15:50 ` Stephen Warren [this message]
2015-06-16 7:53 ` Tomeu Vizoso
2015-06-02 11:28 ` Linus Walleij
2015-06-02 15:40 ` Stephen Warren
2015-06-16 8:42 ` Tomeu Vizoso
2015-06-16 20:32 ` Stephen Warren
2015-06-17 10:04 ` Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 03/21] ARM: tegra: Register drivers before devices Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 04/21] ARM: EXYNOS: " Tomeu Vizoso
2015-05-26 0:41 ` Krzysztof Kozlowski
2015-05-25 14:53 ` [PATCH 05/21] ARM i.MX6q: " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 06/21] of/platform: Add of_platform_device_ensure() Tomeu Vizoso
2015-05-26 18:56 ` Dmitry Torokhov
2015-05-27 8:04 ` Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 07/21] of/platform: Ensure device registration on lookup Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 08/21] gpio: Probe GPIO drivers on demand Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 09/21] gpio: Probe pinctrl devices " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 10/21] regulator: core: Probe regulators " Tomeu Vizoso
2015-05-25 17:32 ` Mark Brown
2015-05-26 6:17 ` Tomeu Vizoso
2015-05-26 9:36 ` Mark Brown
2015-05-26 15:08 ` Tomeu Vizoso
2015-05-26 16:54 ` Mark Brown
2015-05-26 17:53 ` Tomeu Vizoso
2015-05-26 19:55 ` Mark Brown
2015-05-25 14:53 ` [PATCH 11/21] drm: Probe panels " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 12/21] drm/tegra: Probe dpaux devices " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 13/21] i2c: core: Probe i2c master " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 14/21] pwm: Probe PWM chip " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 15/21] backlight: Probe backlight " Tomeu Vizoso
2015-05-26 7:18 ` Lee Jones
2015-05-26 7:25 ` Sascha Hauer
2015-05-26 8:39 ` Lee Jones
2015-05-26 12:01 ` Tomeu Vizoso
2015-05-26 13:34 ` Lee Jones
2015-05-25 14:53 ` [PATCH 16/21] usb: phy: Probe phy " Tomeu Vizoso
2015-05-26 14:44 ` Felipe Balbi
2015-05-25 14:53 ` [PATCH 17/21] clk: Probe clk providers " Tomeu Vizoso
2015-05-28 6:16 ` Michael Turquette
2015-05-25 14:53 ` [PATCH 18/21] pinctrl: Probe pinctrl devices " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 19/21] phy: core: Probe phy providers " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 20/21] dma: of: Probe DMA controllers " Tomeu Vizoso
2015-05-25 14:53 ` [PATCH 21/21] power-supply: Probe power supplies " Tomeu Vizoso
2015-05-28 4:33 ` [PATCH 00/21] On-demand device registration Rob Herring
2015-06-03 19:57 ` Grygorii.Strashko@linaro.org
2015-06-04 8:39 ` Tomeu Vizoso
2015-06-04 16:51 ` Grygorii.Strashko@linaro.org
2015-06-04 20:39 ` Alexander Holler
2015-06-08 12:26 ` Enrico Weigelt, metux IT consult
2015-06-08 18:14 ` Alexander Holler
2015-06-08 18:18 ` Alexander Holler
2015-06-22 15:23 ` Tomeu Vizoso
2015-06-23 0:01 ` Rob Herring
2015-06-02 8:48 ` Linus Walleij
2015-06-02 10:14 ` Tomeu Vizoso
2015-06-10 7:30 ` Linus Walleij
2015-06-10 10:19 ` Tomeu Vizoso
2015-06-10 12:23 ` Andrzej Hajda
2015-06-11 8:15 ` Linus Walleij
[not found] ` <5577F533.1060007@ahsoftware.de>
2015-06-11 8:12 ` Linus Walleij
2015-06-11 10:17 ` Alexander Holler
2015-06-11 11:24 ` Alexander Holler
2015-06-11 11:49 ` Alexander Holler
2015-06-11 12:30 ` Linus Walleij
2015-06-11 16:40 ` Alexander Holler
2015-06-12 7:25 ` Linus Walleij
2015-06-12 11:19 ` Alexander Holler
2015-06-12 11:36 ` Alexander Holler
2015-06-13 18:27 ` Alexander Holler
2015-06-15 8:58 ` Linus Walleij
2015-06-15 9:42 ` Alexander Holler
2015-06-11 13:09 ` Tomeu Vizoso
2015-06-03 21:12 ` Rob Clark
2015-06-04 21:03 ` Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5567393A.6000901@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=galak@codeaurora.org \
--cc=gnurou@gmail.com \
--cc=grant.likely@linaro.org \
--cc=holler@ahsoftware.de \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=stephane.marchesin@gmail.com \
--cc=thierry.reding@gmail.com \
--cc=tomeu.vizoso@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).