[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdZYTc2_zQww7NfmTjSZEoiksVwpV3sugXnanoUX135iRA@mail.gmail.com>
Date: Fri, 11 Oct 2013 09:53:53 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Stephen Warren <swarren@...dotorg.org>
Cc: Christian Ruppert <christian.ruppert@...lis.com>,
Patrice CHOTARD <patrice.chotard@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Grant Likely <grant.likely@...retlab.ca>,
Rob Herring <rob.herring@...xeda.com>,
Rob Landley <rob@...dley.net>,
Sascha Leuenberger <sascha.leuenberger@...lis.com>,
Pierrick Hascoet <pierrick.hascoet@...lis.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Alexandre Courbot <acourbot@...dia.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 01/03] Make non-linear GPIO ranges accesible from gpiolib
On Thu, Oct 10, 2013 at 10:49 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 10/09/2013 08:01 AM, Linus Walleij wrote:
>> On Wed, Oct 9, 2013 at 3:28 PM, Christian Ruppert
>> <christian.ruppert@...lis.com> wrote:
>>> On Wed, Oct 09, 2013 at 01:58:35PM +0200, Linus Walleij wrote:
>>>> On Tue, Oct 8, 2013 at 2:25 PM, Christian Ruppert
>>>> <christian.ruppert@...lis.com> wrote:
> ...
>>> Obviously, a driver (no matter for which OS) must be aware of
>>> this hardware property so it can decide which value to write to which
>>> register in order to control the pin mux. If we don't want to split (or
>>> worse: duplicate) that information in the driver and device tree, I see
>>> two alternatives.
>>> 1. Define register offsets, masks and register values and the list of
>>> pins controlled by those register/value pairs in the device tree.
>>
>> This is not a viable alternative of course.
>
> Cough. pinctrl-single. Cough.
Indeed I have had second thoughts about pinctrl-single both
during its inception and later. Especially yesteray when it
sort of popped up that "yeah one register per pin ... then we
have this one extra register on the side to flush the pin settings
out to the IO-ring". (Haven't caught up with that discussion
though.)
It really needs to be kept in its very constrained cage.
For pinctrl-single there are quite a few strings attached,
like the pin can only be controlled by a single register, not
two of them. The indata to the device tree should be
in some nonsensical machine-readable form, not a
human-readable manual, such that the work of writing a
"proper" driver would involve reverse-engineering that
manual.
But it is definately in a grey area.
Yours,
Linus Walleij
--
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