Hi Laurent,
On Tue, Nov 15, 2016 at 12:59 AM, Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> 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 ;-)
> disabling the I/O interrupt (or just ignoring it).
IIRC, the R-Car GPIO block will send interrupts in output 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.
>
>> 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
