From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Alexandre Courbot <gnurou@gmail.com>,
Lan Tianyu <tianyu.lan@intel.com>, Lv Zheng <lv.zheng@intel.com>,
Alan Cox <alan.cox@intel.com>,
Mathias Nyman <mathias.nyman@linux.intel.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 5/5] gpio / ACPI: Add support for ACPI GPIO operation regions
Date: Thu, 13 Mar 2014 17:18:16 +0200 [thread overview]
Message-ID: <20140313151816.GR5018@intel.com> (raw)
In-Reply-To: <CACRpkdY3z-XGHwn5sQKM-8cKYHzr3_40h53032ETN6PaDW779w@mail.gmail.com>
On Thu, Mar 13, 2014 at 03:32:01PM +0100, Linus Walleij wrote:
> On Mon, Mar 10, 2014 at 1:54 PM, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
>
> Here:
>
> > +static acpi_status
> > +acpi_gpio_adr_space_handler(u32 function, acpi_physical_address address,
> > + u32 bits, u64 *value, void *handler_context,
> > + void *region_context)
> > +{
> > + struct acpi_gpio_chip *achip = region_context;
> > + struct gpio_chip *chip = achip->chip;
> > + struct acpi_resource_gpio *agpio;
> > + struct acpi_resource *ares;
> > + acpi_status status;
> > + bool pull;
>
> Should be named pull_up, right?
Yes.
>
> > + int i;
> > +
> > + status = acpi_buffer_to_resource(achip->conn_info.connection,
> > + achip->conn_info.length, &ares);
> > + if (ACPI_FAILURE(status))
> > + return status;
> > +
> > + if (WARN_ON(ares->type != ACPI_RESOURCE_TYPE_GPIO)) {
> > + ACPI_FREE(ares);
> > + return AE_BAD_PARAMETER;
> > + }
> > +
> > + agpio = &ares->data.gpio;
> > + pull = agpio->pin_config == ACPI_PIN_CONFIG_PULLUP;
>
> So here ACPI tells us that the pin is pulled up.
>
> And I am suspicious since this is strictly speaking pin control business
> and not GPIO, and I won't let pin control stuff sneak into the GPIO
> subsystem under the radar just because I'm not paying close enough
> attention.
This has more to do in finding out what will be the initial value of the
GPIO when we set it to output (given that it is output).
> I have been told that these things are not dynamic (i.e. we only get
> informed that a pin is pulled up/down, we cannot actively change the
> config) is this correct?
As far as I can tell, yes.
> If any sort of advanced pin control business is going to come into
> ACPI a sibling driver in drivers/pinctrl/pinctrl-acpi.c needs to be
> created that can select CONFIG_PINCONF properly reflect this
> stuff in debugfs etc. (Maybe also give proper names on the pins
> since I hear this is coming to ACPI!)
No advanced pin control business, just GPIO stuff :)
> > + if (WARN_ON(agpio->io_restriction == ACPI_IO_RESTRICT_INPUT &&
> > + function == ACPI_WRITE)) {
> > + ACPI_FREE(ares);
> > + return AE_BAD_PARAMETER;
> > + }
> > +
> > + for (i = 0; i < agpio->pin_table_length; i++) {
> > + unsigned pin = agpio->pin_table[i];
> > + struct acpi_gpio_connection *conn;
> > + struct gpio_desc *desc;
> > + bool found;
> > +
> > + desc = gpiochip_get_desc(chip, pin);
> > + if (IS_ERR(desc)) {
> > + status = AE_ERROR;
> > + goto out;
> > + }
> > +
> > + mutex_lock(&achip->conn_lock);
> > +
> > + found = false;
> > + list_for_each_entry(conn, &achip->conns, node) {
> > + if (conn->desc == desc) {
> > + found = true;
> > + break;
> > + }
> > + }
> > + if (!found) {
> > + int ret;
> > +
> > + ret = gpiochip_request_own_desc(desc, "ACPI:OpRegion");
> > + if (ret) {
> > + status = AE_ERROR;
> > + mutex_unlock(&achip->conn_lock);
> > + goto out;
> > + }
> > +
> > + switch (agpio->io_restriction) {
> > + case ACPI_IO_RESTRICT_INPUT:
> > + gpiod_direction_input(desc);
> > + break;
> > + case ACPI_IO_RESTRICT_OUTPUT:
> > + gpiod_direction_output(desc, pull);
>
> Can you explain why the fact that the line is pulled down affects the
> default output value like this? I don't get it.
That's the thing - ACPI doesn't tell us what is the initial value of the
pin. There is no such field in GpioIo() resource.
So I'm assuming here that if it says that the pin is pulled up, the default
value will be high.
> A comment in the code would be needed I think.
>
> This looks more like a typical piece of code for open collector/drain
> (which is already handled by gpiolib) not pull up/down.
>
>
> > + break;
> > + default:
> > + /*
> > + * Assume that the BIOS has configured the
> > + * direction and pull accordingly.
> > + */
> > + break;
> > + }
> > +
> > + conn = kzalloc(sizeof(*conn), GFP_KERNEL);
> > + if (!conn) {
> > + status = AE_NO_MEMORY;
> > + mutex_unlock(&achip->conn_lock);
> > + goto out;
> > + }
> > +
> > + conn->desc = desc;
> > +
> > + list_add_tail(&conn->node, &achip->conns);
> > + }
> > +
> > + mutex_unlock(&achip->conn_lock);
> > +
> > +
> > + if (function == ACPI_WRITE)
> > + gpiod_set_raw_value(desc, !!((1 << i) & *value));
>
> What is this? How can the expression !!((1 << i) possibly evaluate to
> anything else than "true"? I don't get it. Just (desc, *value) seem more
> apropriate.
We are dealing with multiple pins here. So for example if
agpio->pin_table_length == 2 and *value == 0x2 we get:
i == 0: !!((1 << 0) & 0x2) --> false
i == 1: !!((1 << 1) & 0x2) --> true
Maybe
gpiod_set_raw_value(desc, (*value >> i) & 1);
is cleaner?
next prev parent reply other threads:[~2014-03-13 15:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 12:54 [PATCH v2 0/5] gpio / ACPI: Rework ACPI GPIO events and add support for operation regions Mika Westerberg
2014-03-10 12:54 ` [PATCH v2 1/5] gpiolib: Allow GPIO chips to request their own GPIOs Mika Westerberg
2014-03-13 4:46 ` Alexandre Courbot
2014-03-10 12:54 ` [PATCH v2 2/5] gpio / ACPI: Allocate ACPI specific data directly in acpi_gpiochip_add() Mika Westerberg
2014-03-10 12:54 ` [PATCH v2 3/5] gpio / ACPI: Rename acpi_gpio_evt_pin to acpi_gpio_event Mika Westerberg
2014-03-10 12:54 ` [PATCH v2 4/5] gpio / ACPI: Rework ACPI GPIO event handling Mika Westerberg
2014-03-10 12:54 ` [PATCH v2 5/5] gpio / ACPI: Add support for ACPI GPIO operation regions Mika Westerberg
2014-03-13 14:32 ` Linus Walleij
2014-03-13 15:05 ` Cox, Alan
2014-03-14 10:50 ` Linus Walleij
2014-03-13 15:18 ` Mika Westerberg [this message]
2014-03-14 10:53 ` Linus Walleij
2014-03-14 11:11 ` Mika Westerberg
2014-03-14 15:58 ` [PATCH v3 " Mika Westerberg
2014-03-14 16:25 ` Linus Walleij
2014-03-17 9:44 ` Mika Westerberg
2014-03-13 14:17 ` [PATCH v2 0/5] gpio / ACPI: Rework ACPI GPIO events and add support for " Linus Walleij
2014-03-13 17:14 ` Mika Westerberg
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=20140313151816.GR5018@intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=alan.cox@intel.com \
--cc=gnurou@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=rjw@rjwysocki.net \
--cc=tianyu.lan@intel.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox