From: Stephen Warren <swarren@wwwdotorg.org>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Rob Herring <robherring2@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Alexandre Courbot <gnurou@gmail.com>
Subject: Re: [PATCH v1 1/3] gpio: defer probe if pinctrl cannot be found
Date: Fri, 10 Jul 2015 09:27:45 -0600 [thread overview]
Message-ID: <559FE471.1030408@wwwdotorg.org> (raw)
In-Reply-To: <CAAObsKBS0OOhPNEAEV5Bh_+WMVWYhuGtGLqaVdCbzxPuT8a_gA@mail.gmail.com>
On 07/10/2015 03:29 AM, Tomeu Vizoso wrote:
> On 1 July 2015 at 19:36, Rob Herring <robherring2@gmail.com> wrote:
>> On Wed, Jul 1, 2015 at 7:45 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>>> When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if
>>> the pin controller isn't available.
>>>
>>> Otherwise, the GPIO range wouldn't be set at all unless the pin
>>> controller probed always before the GPIO chip.
>>>
>>> With this change, the probe of the GPIO chip will be deferred and will
>>> be retried at a later point, hopefully once the pin controller has been
>>> registered and probed already.
>>
>> This will break cases where the pinctrl driver does not exist, but the
>> DT contains pinctrl bindings. We can have similar problems already
>> with clocks though. However, IMO this problem is a bit different in
>> that pinctrl is more likely entirely optional while clocks are often
>> required. You may do all pin setup in bootloader/firmware on some
>> boards and not others. Of course then why put pinctrl in the DT in
>> that case? They could be present just due to how chip vs. board dts
>> files are structured.
>
> I see. My instinct tells me that it would be better if the gpio-ranges
> property was set in the board dts, but I don't really know what each
> mach does with its DTSs.
That doesn't make sense; the mapping between GPIO controller pins and
pin controller pins is a property of the SoC not the board.
next prev parent reply other threads:[~2015-07-10 15:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-01 12:45 [PATCH v1 0/3] Have Tegra's GPIO chip depend explicitly on the pinctrl device Tomeu Vizoso
2015-07-01 12:45 ` Tomeu Vizoso
2015-07-01 12:45 ` [PATCH v1 1/3] gpio: defer probe if pinctrl cannot be found Tomeu Vizoso
2015-07-01 17:36 ` Rob Herring
[not found] ` <CAL_JsqKXODBk4FVB-kiWFHLGFLCwJDjXvpVqOTvuEJubApbVSg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-02 8:59 ` Geert Uytterhoeven
2015-07-02 8:59 ` Geert Uytterhoeven
2015-07-02 15:38 ` Rob Herring
2015-07-10 9:29 ` Tomeu Vizoso
2015-07-10 15:27 ` Stephen Warren [this message]
[not found] ` <559FE471.1030408-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2015-07-10 16:21 ` Tomeu Vizoso
2015-07-10 16:21 ` Tomeu Vizoso
2015-07-10 16:21 ` Tomeu Vizoso
[not found] ` <CAAObsKAav-5-0bZA2XYW4m7eUd9F7yc+9kGvmt_hS-Z0ip=zKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-10 17:07 ` Stephen Warren
2015-07-10 17:07 ` Stephen Warren
[not found] ` <CAAObsKBS0OOhPNEAEV5Bh_+WMVWYhuGtGLqaVdCbzxPuT8a_gA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-10 18:40 ` Rob Herring
2015-07-10 18:40 ` Rob Herring
[not found] ` <1435754753-31307-2-git-send-email-tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2015-07-02 8:49 ` Geert Uytterhoeven
2015-07-02 8:49 ` Geert Uytterhoeven
2015-07-01 12:45 ` [PATCH v1 2/3] pinctrl: tegra: Only set the gpio range if needed Tomeu Vizoso
2015-07-01 12:45 ` [PATCH v1 3/3] ARM: tegra: Add gpio-ranges property Tomeu Vizoso
2015-07-01 12:45 ` Tomeu Vizoso
2015-07-01 12:45 ` Tomeu Vizoso
2015-07-08 20:55 ` Stephen Warren
2015-07-08 20:55 ` Stephen Warren
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=559FE471.1030408@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=devicetree@vger.kernel.org \
--cc=gnurou@gmail.com \
--cc=grant.likely@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=robherring2@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.