lkml.org 
[lkml]   [2012]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] gpio: stmpe: Add DT support for stmpe gpio
From
On Mon, Nov 26, 2012 at 12:28 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Fri, 23 Nov 2012, Shiraz Hashim wrote:

[About st-norequest-mask]
>> This is a board dependent parameter which just informs gpio driver
>> about pins, which must not be requested. It may happen for a stmpe
>> variant where such gpio pins are multiplexed with some other
>> function.
>>
>> Hence it must be part of DT itself.
>
> Doesn't pinctrl normally handle this kind of stuff?

So this is a signal that something might be strange about the
driver architecture at large.

The datasheet for STMPE1601 says:

"The STMPE1601 offers great flexibility, as each
I/O can be configured as input, output or specific
functions."

Hm hm. Well this driver existed before the pin control
system so we have to live with this. We *could* assume
that the above DT property could be set beacause someone
connected a GPIO to ground and trying to use it
would burn the system or something. But if it's actually
dealing with the sideeffects of pinmuxing it's done in the
wrong place.

Apart from the pinctrl API another way to handle these
beasts is what I do in the drivers/mfd/tps6105x.c,
where the hardware is such that you basically always
nail down the hardware for one specific use case
of 3 possible. Then it's done by configuring the root
MFD device.

The crucial question is: can the STMPE controllers be
used for GPIO, PWM, keypad and touchscreen at the
*same time* or are they nailed to *one* usecase during
electronics design?

Yours,
Linus Walleij


\
 
 \ /
  Last update: 2012-12-01 20:41    [W:2.741 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site