Re: [PATCH 0/2] Salvator-X: Add GPIO keys support

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Geert,

(CC'ing Linus)

On Tuesday 15 Nov 2016 08:58:18 Geert Uytterhoeven wrote:
> On Tue, Nov 15, 2016 at 12:59 AM, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 20:47:03 Geert Uytterhoeven wrote:
> >> On Mon, Nov 14, 2016 at 5:44 PM, Laurent Pinchart wrote:
> >>> On Monday 14 Nov 2016 14:47:00 Geert Uytterhoeven wrote:
> >>>> On Mon, Nov 14, 2016 at 2:41 PM, Laurent Pinchart wrote:
> >>>>> On Monday 14 Nov 2016 14:35:26 Geert Uytterhoeven wrote:
> >>>>>> The main reason I haven't sent out a similar series yet is because
> >>>>>> the GPIOs used for the 3 push buttons are shared with the 3 user
> >>>>>> LEDs. For each of them, you have to choose at DT time if you want to
> >>>>>> use them as buttons or as LEDs.
> >>>>>> 
> >>>>>> On ULCB, the same issue is present. For those, we settled on 1 key
> >>>>>> and 2 LEDs...
> >>>>>> 
> >>>>>> Looking forward to more comments...
> >>>>> 
> >>>>> In theory the GPIOs could be shared by the gpio-keys and LED drivers
> >>>>> in open-drain mode. I'm not sure the GPIO subsystem supports that
> >>>>> though.
> >>>> 
> >>>> Been there, done that, cfr. "[RFD] Sharing GPIOs for input (buttons)
> >>>> and output (LEDs)". The result wasn't pretty...
> >>> 
> >>> Wasn't it ? Linus basically told you to use open-drain GPIOs and fix
> >>> the GPIO driver in case it can't read the value of GPIOs configured as
> >>> output in open-drain mode. If didn't shoot the idea down.
> >> 
> >> If I'm not mistaken, the R-Car GPIO block does not support open-drain
> >> GPIO.
> > 
> > Not as such, but we can switch between input and output low, which is
> > basically open-drain.
> > 
> >> Even if it would support it, you cannot read the GPIO while actively
> >> pulling it down.
> > 
> > When actively driving it low you know the value is 0. Only when driving it
> > open do you need to read the value back, and that's easily implemented as
> > the hardware will be configured in input mode then.
> > 
> >> Hence you have to time-multiplex the GPIO to use both LEDs and buttons,
> >> through switching between pulling down and not pulling down (or between
> >> output and input, which is what I did).
> > 
> > No, if you want to use both, you should configure the I/O in open-drain,
> > in which case you have two options:
> > 
> > - Turn the LED on by driving the I/O "high", meaning leaving it floating.
> > The pull-up resistor will turn the MOSFET on, the LED will be lit. When
> > the corresponding button is pressed the I/O will be connected to GND,
> > turning the LED off, and signalling the input.
> > 
> > - Turn the LED off by driving the I/O low. Pressing the button won't have
> > any effect. We need in this case to ignore the input value, which could
> > be done by
>
> Right. I tried to have both ;-)

I'm sorry Dave, I'm afraid you can't do that :-)

> > disabling the I/O interrupt (or just ignoring it).
> 
> IIRC, the R-Car GPIO block will send interrupts in output mode only.

Do you mean input mode only ?

> >> Apart from that, there's also the discrepancy between hardware
> >> description (the GPIO is connected to both buttons and LEDs, hence it
> >> should be described that way in DT)
> > 
> > Correct, this is where a framework change is needed if we want to allow
> > both the GPIO keyboard and LED drivers to request the GPIO.

Linus, would this be acceptable to you ?

> >> and user policy (the user wants to use e.g. the first GPIO as a button,
> >> and the second GPIO as an LED).
> > 
> > That's easy to do, the user will just need to turn the first LED on,
> > allowing full button operation on the I/O.
> 
> Thanks, didn't think of that.

-- 
Regards,

Laurent Pinchart