lkml.org 
[lkml]   [2013]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 01/03] Make non-linear GPIO ranges accesible from gpiolib
From
On Thu, Oct 10, 2013 at 10:49 PM, Stephen Warren <swarren@wwwdotorg.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@abilis.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@abilis.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


\
 
 \ /
  Last update: 2013-10-11 10:21    [W:1.255 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site