Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-acpi@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-gpio@vger.kernel.org
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: [PATCH v1 3/3] Documentation: firmware-guide: gpio-properties: Clarify initial output state
Date: Wed, 28 Oct 2020 22:51:01 +0200
Message-ID: <20201028205101.47583-3-andriy.shevchenko@linux.intel.com> (raw)
In-Reply-To: <20201028205101.47583-1-andriy.shevchenko@linux.intel.com>

GpioIo() doesn't provide an explicit state for an output pin.
Linux tries to be smart and uses a common sense based on other
parameters. Document how it looks like in the code.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 .../firmware-guide/acpi/gpio-properties.rst   | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst
index 370fe46c6af9..59aad6138b6e 100644
--- a/Documentation/firmware-guide/acpi/gpio-properties.rst
+++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
@@ -61,6 +61,29 @@ must be 0. GpioInt() resource has its own means of defining it.
 In our Bluetooth example the "reset-gpios" refers to the second GpioIo()
 resource, second pin in that resource with the GPIO number of 31.
 
+The GpioIo() resource unfortunately doesn't explicitly provide an initial
+state of the output pin which driver should use during its initialization.
+
+Linux tries to use common sense here and derives the state from the bias
+and polarity settings. The table below shows the expectations:
+
+=========  =============  ==============
+Pull Bias     Polarity     Requested...
+=========  =============  ==============
+Implicit     x            AS IS (assumed firmware configured for us)
+Explicit     x (no _DSD)  as Pull Bias (Up == High, Down == Low),
+                          assuming non-active (Polarity = !Pull Bias)
+Down         Low          as low, assuming active
+Down         High         as low, assuming non-active
+Up           Low          as high, assuming non-active
+Up           High         as high, assuming active
+=========  =============  ==============
+
+That said, for our above example the both GPIOs, since the bias setting
+is explicit and _DSD is present, will be treated as active with a high
+polarity and Linux will configure the pins in this state until a driver
+reprograms them differently.
+
 It is possible to leave holes in the array of GPIOs. This is useful in
 cases like with SPI host controllers where some chip selects may be
 implemented as GPIOs and some as native signals. For example a SPI host
-- 
2.28.0


  parent reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 20:50 [PATCH v1 1/3] Documentation: firmware-guide: gpio-properties: Fix factual mistakes Andy Shevchenko
2020-10-28 20:51 ` [PATCH v1 2/3] Documentation: firmware-guide: gpio-properties: active_low only for GpioIo() Andy Shevchenko
2020-10-28 21:10   ` Ricardo Ribalda
2020-10-29 14:46     ` Andy Shevchenko
2020-10-29 14:54       ` Ricardo Ribalda
2020-10-29 17:17         ` Andy Shevchenko
2020-10-29 17:20           ` Andy Shevchenko
2020-10-29 17:25             ` Andy Shevchenko
2020-10-29 17:32               ` Ricardo Ribalda
2020-10-29 18:09                 ` Ricardo Ribalda
2020-10-29 18:13                   ` Andy Shevchenko
2020-10-29 18:58                     ` Ricardo Ribalda
2020-10-29 19:11                       ` Andy Shevchenko
2020-10-29 18:10                 ` Andy Shevchenko
2020-10-29  8:13   ` Mika Westerberg
2020-10-28 20:51 ` Andy Shevchenko [this message]
2020-10-29  8:16   ` [PATCH v1 3/3] Documentation: firmware-guide: gpio-properties: Clarify initial output state Mika Westerberg
2020-10-29  8:13 ` [PATCH v1 1/3] Documentation: firmware-guide: gpio-properties: Fix factual mistakes Mika Westerberg
2020-10-29 11:10   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201028205101.47583-3-andriy.shevchenko@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git