Thread (58 messages) 58 messages, 8 authors, 2012-11-07
STALE4957d

[PATCH 3/9] ARM: Kirkwood: Convert dnskw to pinctrl

From: andrew@lunn.ch (Andrew Lunn)
Date: 2012-10-26 10:24:50

I did look at using the gpio-regulator stuff a while back, and
decided it wasn't quite the right shape. Although I can't remember
why, and it might have changed since.
O.K. I will look at it this weekend.
 
The power-off GPIO registration could happen in dnskw_power_off
instead, or the attempt at a gpio-poweroff driver could be
resurrected (I'd forgotten about it until now).
I dusted the code off last weekend, but ran out of time.  I wanted to
make it also support the pxa use-case.
I could accept dnskw:power:recover is a weirdo configuration option
that should be set in the bootloader / userland rather than the
kernel supporting it. Although it would be nice if the kernel
registered it's purpose. Maybe GPIO pins could be exported by adding
sub-nodes to the GPIO chip, if that's not too hackish?
We need some sort of solution. It is quite common to use GPIO this
way, to enable power, etc. So either we need some form of gpio
regulator, or the ability to set gpio defaults as you said in the gpio
DT node, or fix the ordering so the init function can set them up.
 
quoted
First thing that comes to mind, is it registering them for the correct
GPIO controller. I think with the new setup, pinctrl and gpio are
closely linked, so maybe, its modifying pins on the wrong controller.
Bit of a long shot....
I did wonder that, but then why would turning the LEDs on work fine?
I wonder if both pins are being toggled or something. I'll
investigate further and report back. The two that cause the NAS to
lock up are the only ones on &gpio1 though.
What would they map to on gpio0? NAND? 
The sata0 and sata1 activity leds are definitely MPP20 and
MPP21---I've set them up as GPIO leds before successfully.
O.K.
quoted
[   16.187814] initial MPP regs: 01112222 43303311 55550000 00000000 00000000 00000000 00000000
[   16.187833]   final MPP regs: 01552222 03303311 55550000 00000000 00000000 00000000 00000000

The first line is how uboot setup the MPP pins. The second is after
the init function was called.
initial MPP regs: 01111111 03303311 00551100 00000000 00000000 00000000 00000000
  final MPP regs: 01111111 03303311 00551100 00000000 00000000 00000000 00000000

Although the initial MPP regs is also set by a recompiled u-boot
with ~identical MPP setup code.
It might be useful to generate the same sort of dumps with the new
driver, even if its code just hacked in for testing.

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