On Tuesday 15 Nov 2016 16:26:11 Laurent Pinchart wrote: > Hi Geert, > > (CC'ing Linus) With Linus' e-mail address fixed. I'll blame my e-mail client that uses incorrect addresses from old e-mails as the top auto-completion options :-/ > 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
