* [PATCH] gpio: document open drain/source behaviour
@ 2016-04-05 14:56 Linus Walleij
2016-04-07 7:34 ` Geert Uytterhoeven
0 siblings, 1 reply; 3+ messages in thread
From: Linus Walleij @ 2016-04-05 14:56 UTC (permalink / raw)
To: linux-gpio, Alexandre Courbot
Cc: Linus Walleij, Michael Hennerich, Nicolas Saenz Julienne,
H. Nikolaus Schaller
This has been a totally undocumented feature for years so add some
generic concepts and documentation about open drain/source, include
some facts on how we now support for hardware.
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
Cc: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Documentation/gpio/driver.txt | 68 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt
index bbeec415f406..4cfcf889efcb 100644
--- a/Documentation/gpio/driver.txt
+++ b/Documentation/gpio/driver.txt
@@ -68,6 +68,74 @@ control callbacks) if it is expected to call GPIO APIs from atomic context
on -RT (inside hard IRQ handlers and similar contexts). Normally this should
not be required.
+
+GPIOs with open drain/source support
+------------------------------------
+
+Open drain (CMOS) or open collector (TTL) is traditionally a way to achieve
+wire-OR on an I/O line, for example a GPIO line, using a single transistor.
+This means the line is not actively driven high, instead you provide the
+drain/collector as output, so when the transistor is not open, it will present
+a high-impedance (tristate) to the external rail. This means it will not
+conflict with other similarly wired I/O lines on the rail, and when accompanied
+with a pull-up resistor, this will tend to high level unless one of the
+transistors on the rail actively pull it down.
+
+Modern electronics very seldom has this kind of single-transistor output
+stage. Instead they usually have a CMOS "totempole" with one N-MOS and one
+P-MOS transistor where one of them drive the line high and one of them drive
+the line low. This is called a push-pull-output. The "totempole" looks like so,
+and shold be familiar to anyone working with electronics:
+
+ VDD
+ |
+ ||--+
+ +--/ ---o|| P-MOS-FET
+ | ||--+
+in --+ +----- out
+ | ||--+
+ +--/ ----|| N-MOS-FET
+ ||--+
+ |
+ GND
+
+You see the little "switches" that enable/disable the P-MOS or N-MOS transistor
+right after the split of the input. As you can see, either transistor will go
+totally numb if this switch is open. That is usually how software-controlled
+open drain/source works.
+
+Some GPIO hardware support open drain / open source configuration. What this
+means in practice is usually that the driver has a push-pull output driver
+stage with one N-MOS and one P-MOS transistor like above, and using software,
+one of the transistors can be disabled, yielding an open drain or open source
+output.
+
+By disabling the P-MOS transistor, the output can be driven between GND and
+high impedance (open drain), and by disabling the N-MOS transistor, the output
+can be driven between VDD and high impedance (open source). In the first case,
+a pull-up resistor is needed on the outgoing rail to complete the circuit, and
+in the second case, a pull-down resistor is needed on the rail.
+
+Hardware that supports open drain or open source or both, can implement a
+special callback in the gpio_chip: .set_single_ended() that takes an enum flag
+telling whether to configure the line as open drain, open source or push-pull.
+This will happen i response to the GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag
+set in the machine file, or coming from other hardware descriptions.
+
+If this state can not be configured in hardware, i.e. if the GPIO hardware does
+not support open drain/open source in hardware, the GPIO library will instead
+use a trick: when a line is set as output, if the line is flagged as open
+drain, and the output value is negative, it will be driven low as usual. But
+if the output value is set to positive, it will instead *NOT* be driven high,
+instead it will be switched to input, as input mode is high impedance, thus
+achieveing a "open drain emulation" of sorts: electrically the behaviour will
+be identical, with the exception of possible hardware glitches when switching
+the mode of the line.
+
+For open source configuration the same principle is used, just that instead
+of actively driving the line low, it is set to input.
+
+
GPIO drivers providing IRQs
---------------------------
It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
--
2.4.3
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] gpio: document open drain/source behaviour
2016-04-05 14:56 [PATCH] gpio: document open drain/source behaviour Linus Walleij
@ 2016-04-07 7:34 ` Geert Uytterhoeven
2016-04-07 7:52 ` H. Nikolaus Schaller
0 siblings, 1 reply; 3+ messages in thread
From: Geert Uytterhoeven @ 2016-04-07 7:34 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio@vger.kernel.org, Alexandre Courbot, Michael Hennerich,
Nicolas Saenz Julienne, H. Nikolaus Schaller
Hi Linus,
On Tue, Apr 5, 2016 at 4:56 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This has been a totally undocumented feature for years so add some
> generic concepts and documentation about open drain/source, include
> some facts on how we now support for hardware.
>
> Cc: Michael Hennerich <michael.hennerich@analog.com>
> Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
> Cc: H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I saw this appear in gpio/for-next, so let's review it ;-)
> --- a/Documentation/gpio/driver.txt
> +++ b/Documentation/gpio/driver.txt
> @@ -68,6 +68,74 @@ control callbacks) if it is expected to call GPIO APIs from atomic context
> on -RT (inside hard IRQ handlers and similar contexts). Normally this should
> not be required.
>
> +
> +GPIOs with open drain/source support
> +------------------------------------
> +
> +Open drain (CMOS) or open collector (TTL) is traditionally a way to achieve
> +wire-OR on an I/O line, for example a GPIO line, using a single transistor.
> +This means the line is not actively driven high, instead you provide the
> +drain/collector as output, so when the transistor is not open, it will present
> +a high-impedance (tristate) to the external rail. This means it will not
> +conflict with other similarly wired I/O lines on the rail, and when accompanied
> +with a pull-up resistor, this will tend to high level unless one of the
> +transistors on the rail actively pull it down.
pulls
> +Modern electronics very seldom has this kind of single-transistor output
> +stage. Instead they usually have a CMOS "totempole" with one N-MOS and one
totem-pole
> +P-MOS transistor where one of them drive the line high and one of them drive
drives ... drives
> +the line low. This is called a push-pull-output. The "totempole" looks like so,
push-pull output (consistency with below) ... totem pole
> +and shold be familiar to anyone working with electronics:
should
> +Hardware that supports open drain or open source or both, can implement a
> +special callback in the gpio_chip: .set_single_ended() that takes an enum flag
> +telling whether to configure the line as open drain, open source or push-pull.
> +This will happen i response to the GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag
in
> +set in the machine file, or coming from other hardware descriptions.
> +
> +If this state can not be configured in hardware, i.e. if the GPIO hardware does
> +not support open drain/open source in hardware, the GPIO library will instead
> +use a trick: when a line is set as output, if the line is flagged as open
> +drain, and the output value is negative, it will be driven low as usual. But
> +if the output value is set to positive, it will instead *NOT* be driven high,
> +instead it will be switched to input, as input mode is high impedance, thus
> +achieveing a "open drain emulation" of sorts: electrically the behaviour will
achieving an
> +be identical, with the exception of possible hardware glitches when switching
> +the mode of the line.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] gpio: document open drain/source behaviour
2016-04-07 7:34 ` Geert Uytterhoeven
@ 2016-04-07 7:52 ` H. Nikolaus Schaller
0 siblings, 0 replies; 3+ messages in thread
From: H. Nikolaus Schaller @ 2016-04-07 7:52 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-gpio@vger.kernel.org, Alexandre Courbot, Michael Hennerich,
Nicolas Saenz Julienne, Geert Uytterhoeven
Hi,
> Am 07.04.2016 um 09:34 schrieb Geert Uytterhoeven <geert@linux-m68k.org>:
>
> Hi Linus,
>
> On Tue, Apr 5, 2016 at 4:56 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> This has been a totally undocumented feature for years so add some
>> generic concepts and documentation about open drain/source, include
>> some facts on how we now support for hardware.
>>
>> Cc: Michael Hennerich <michael.hennerich@analog.com>
>> Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
>> Cc: H. Nikolaus Schaller <hns@goldelico.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> I saw this appear in gpio/for-next, so let's review it ;-)
>
>> --- a/Documentation/gpio/driver.txt
>> +++ b/Documentation/gpio/driver.txt
>> @@ -68,6 +68,74 @@ control callbacks) if it is expected to call GPIO APIs from atomic context
>> on -RT (inside hard IRQ handlers and similar contexts). Normally this should
>> not be required.
>>
>> +
>> +GPIOs with open drain/source support
>> +------------------------------------
>> +
>> +Open drain (CMOS) or open collector (TTL) is traditionally a way to achieve
>> +wire-OR on an I/O line, for example a GPIO line, using a single transistor.
IMHO wired-or is not the standard use case of open-drain GPIOs (under control of a CPU inside a SoC).
They are more used for level shifting. A push-pull driver has a definitive "high level" voltage
while open drains can drive different voltages, e.g. for controlling LEDs or pulling down inputs of
chips with different I/O voltage (as long as they don't burn the SoC).
>> +This means the line is not actively driven high, instead you provide the
>> +drain/collector as output, so when the transistor is not open, it will present
>> +a high-impedance (tristate) to the external rail. This means it will not
>> +conflict with other similarly wired I/O lines on the rail, and when accompanied
>> +with a pull-up resistor, this will tend to high level unless one of the
>> +transistors on the rail actively pull it down.
>
> pulls
Sometimes they are used for gpio bitbang i2c (which is of course a wired-or connection/bus).
>
>
>> +Modern electronics very seldom has this kind of single-transistor output
Modern? Very seldom?
It is still common for peripheral chips and I don't see any trend which justifies "modern" (implying vs. "ancient").
Here, we mainly have a special case that gpios come with an additional transistor and
we want to turn it off because the hardware doesn't want to see it.
If a chip or pin would not be programmable and "general purpose" and needs to be single-ended
that additional transistor would simply not be included in the silicon chip.
>> +stage. Instead they usually have a CMOS "totempole" with one N-MOS and one
same for "usually" which implies a rationale that does not exist. I.e. chip design decisions
are not based on some "common use" but on "need for this specific case".
>
> totem-pole
>
>> +P-MOS transistor where one of them drive the line high and one of them drive
>
> drives ... drives
>
>> +the line low. This is called a push-pull-output. The "totempole" looks like so,
>
> push-pull output (consistency with below) ... totem pole
>
>> +and shold be familiar to anyone working with electronics:
>
> should
>
>> +Hardware that supports open drain or open source or both, can implement a
>> +special callback in the gpio_chip: .set_single_ended() that takes an enum flag
>> +telling whether to configure the line as open drain, open source or push-pull.
>> +This will happen i response to the GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag
>
> in
>
>> +set in the machine file, or coming from other hardware descriptions.
>> +
>> +If this state can not be configured in hardware, i.e. if the GPIO hardware does
>> +not support open drain/open source in hardware, the GPIO library will instead
>> +use a trick: when a line is set as output, if the line is flagged as open
>> +drain, and the output value is negative, it will be driven low as usual. But
>> +if the output value is set to positive, it will instead *NOT* be driven high,
>> +instead it will be switched to input, as input mode is high impedance, thus
>> +achieveing a "open drain emulation" of sorts: electrically the behaviour will
>
> achieving an
>
>> +be identical, with the exception of possible hardware glitches when switching
>> +the mode of the line.
>
> Gr{oetje,eeting}s,
>
> Geert
Hope this helps.
BR,
NIkolaus
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-04-07 7:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-05 14:56 [PATCH] gpio: document open drain/source behaviour Linus Walleij
2016-04-07 7:34 ` Geert Uytterhoeven
2016-04-07 7:52 ` H. Nikolaus Schaller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).