[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F8EFBC5.1030607@wwwdotorg.org>
Date: Wed, 18 Apr 2012 11:37:09 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Linus Walleij <linus.walleij@...aro.org>
CC: Sascha Hauer <s.hauer@...gutronix.de>,
Dong Aisheng <aisheng.dong@...escale.com>,
"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
Dong Aisheng-B29396 <B29396@...escale.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/1] pinctrl: handle dummy state in core
On 04/18/2012 07:52 AM, Linus Walleij wrote:
> On Wed, Apr 18, 2012 at 2:28 PM, Sascha Hauer <s.hauer@...gutronix.de> wrote:
>
>> Currently Dong Aisheng is working on i.MX6, we have i.MX31, i.MX35,
>> i.MX51 and i.MX53 enabled in the same defconfig. Waiting for all
>> machines turn over at once to pinctrl is illusionary. We have to make
>> drivers work with and without pinctrl. We have a bunch of bad choices:
>>
>> - create a dummy pinctrl for all boards which do not have real pinmux
>> support
>
> Viable compromise.
>
>> - ignore pinctrl_request errors in drivers.
>
> Ugh. Not good.
>
>> - generate and return a dummy pinctrl in the core if no real pinctrl is
>> found.
>>
>> (replace pinctrl with regulators or clocks, it's the same situation, and
>> it's not only i.MX specific)
>
> Since we have dummy regulators, we should not break the design
> pattern creating more confusion.
>
> Stephen can you live with dummy pinctrl handles emitted by the
> core, if explicitly enabled by a Kconfig option?
Yes, I'm happy with the pinctrl core having the ability to "magically"
work when the dummy mapping table entries (or DT entries) are missing,
so long as there is a default-off Kconfig or runtime option that enables
that feature, which I'd expect to be use only for boards/platforms/...
that are "under conversion".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists