Thread (37 messages) 37 messages, 6 authors, 2016-05-11
DORMANTno replies

[PATCH v5 08/17] gpio: port LoCoMo gpio support from old driver

From: Linus Walleij <hidden>
Date: 2016-05-11 08:34:48

On Sun, Jun 14, 2015 at 5:27 PM, Russell King - ARM Linux
[off-list ref] wrote:
[Dmitry]
quoted
+     regmap_write(lg->regmap, LOCOMO_GPO, 0x00);
+     regmap_write(lg->regmap, LOCOMO_GPE, 0x00);
+     regmap_write(lg->regmap, LOCOMO_GPD, 0x00);
+     regmap_write(lg->regmap, LOCOMO_GIE, 0x00);
Do we really want to initialise all outputs like this?  It suffers from
the problem I mention above - it sets all outputs to zero, then sets
them as inputs, which can lead to glitching.  What if (eg) the LCD was
left enabled?  This would mean you're not going through the proper
power-down sequence for the LCD (for example).
This looks dangerous indeed, why did I miss that before.

Is it possible to just leave these registers as-is, or, in case
you want to know at all times their actual states, implement
the .get_direction() callback? They the kernel can explore
the direction and value of the lines.
TBH, I think GPIO needs to have a way to claim output GPIOs _without_
programming their current state for situations like this.  That seems
to have been an oversight in the model for a while now - it's impossible
to claim GPIO outputs without setting their initial value,
It is possible in the new descriptor API, you can claim a GPIO
for a device with (see <linux/gpio/consumer.h>

enum gpiod_flags {
        GPIOD_ASIS      = 0,
(...)

I understand it may be a bit thick to ask to migrate the whole
SA1100 codebase to GPIO descriptors though, I don't know how
many machines and drivers that would affect.

I'd consider a patch retrofitting this into the old
API if it would see some real use case.

Yours,
Linus Walleij
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help