Am 25.09.2015 um 00:11 schrieb Linus Walleij <linus.walleij@xxxxxxxxxx>: > On Wed, Sep 23, 2015 at 11:13 AM, H. Nikolaus Schaller > <hns@xxxxxxxxxxxxx> wrote: > >> 1. add a DT property to specify the list of GPIO pins that are to become >> "open drain" >> 2. if a pin is configured as "open drain", set value by either outputting a >> "0" (low level) or switching to input (high impedance) >> >> Tested on OMAP5 uEVM with TCA6424 and some LEDs connected to 5V. >> >> Signed-off-by: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> > > I understand the approach, but this is the wrong way to do it. > Instead of indicating that a pin on the pin controller should be > open drain, the *consumer* specifying its gpios = <....> should > do this. On a second thought I am no longer sure if that is the right approach. A gpio is for input and output of “0” and “1” values. And a gpio consumer can control if the output should be active or inactive and input. How the output is physically represented (totem-pole or single-ended, high power, low power etc.) is not a property of the gpio itself and there is IMHO no need for the consumer to be able to define (or change) it. On SoC with integrated gpio controllers it is very common to have pinmux definitions completely separated from the gpio controller properties. But the gpio consumer can connect to pinctrl settings to describe that the pin should have certain physical properties. There, it is common to be able to enable/disable pull-up/downs as well. So turning a totem-pole output (as it is available in the tca6424) into an open-drain output is sort of turning off the pull-up transistor. I.e. comparable to a pinmux setting. So such controllers should get the option to define pinctrl. Some chips might have special control registers for doing that while others need the trick to switch between input and output mode but that is driver implementation detail. But I am not sure if this has other implications. > > I just sent a patch adding the bindings because Tony Lindgren > and Grygorii Strashko approached me similar problems so let's > begin with the bindings. > > Implementing it in the kernel requires some elaboration and it's > going to be more complicated than this local approach, but it > will be more generic and reusable so that is what we need to do. > > Yours, > Linus Walleij BR, Nikolaus Schaller-- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
