From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH] pinctrl: cherryview: Preserve CHV_PADCTRL1_INVRXTX_TXDATA flag on GPIOs
Date: Fri, 4 Sep 2020 22:04:05 +0200 [thread overview]
Message-ID: <993251db-acac-65f3-56fb-c35044ab8080@redhat.com> (raw)
In-Reply-To: <20200904180947.GL1891694@smile.fi.intel.com>
Hi,
On 9/4/20 8:09 PM, Andy Shevchenko wrote:
> On Fri, Sep 04, 2020 at 07:21:41PM +0200, Hans de Goede wrote:
>> One some devices the GPIO should output the inverted value from what
>
>> Fixes: a7d4b171660c ("Input: goodix - add support for getting IRQ + reset GPIOs on Cherry Trail devices")
>
> Hans, a side note. Can you clean up that driver using ACPI GPIO quirks and the
> idea that IRQ line will be retrieved in client->irq?
Nope, the chip uses the IRQ line in a bi-directional manner,
when the chip is reset (by us) the IRQ line is a bootstrap pin
and we need to drive it either high or low to make sure the chip
re-appears on the same i2c-address as it had before. So we need
the get gpiod and then call gpiod_to_irq abstraction so that
we also have the gpiod to call allow calling
gpiod_direction_input() and gpiod_direction_output() on the
irq pin.
And to make things more interesting on some generations x86 hw
(apollo lake) the IRQ is actually listed as an Interrupt resource
in the ACPI device resources (_CRS) and there are GDIX specific
ACPI methods on the ACPI device which directly poke the GPIO
chip to allow setting it high/low (for during reset) or config
it as input. So the goodix.c has its own internal abstraction
around gpiod_direction_input(() and gpiod_direction_output() for
controlling the IRQ pin which does different things on different
x86 hw generations (while also maintaining device-tree compat).
So all in all I'm happy that we have this all working atm
(and it also is reasonably clean already IMHO) and I would
rather not muck with this.
Regards,
Hans
next prev parent reply other threads:[~2020-09-04 20:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 17:21 [PATCH] pinctrl: cherryview: Preserve CHV_PADCTRL1_INVRXTX_TXDATA flag on GPIOs Hans de Goede
2020-09-04 17:44 ` Andy Shevchenko
2020-09-04 17:50 ` Andy Shevchenko
2020-09-04 17:56 ` Andy Shevchenko
2020-09-04 18:09 ` Andy Shevchenko
2020-09-04 20:04 ` Hans de Goede [this message]
2020-09-07 8:42 ` 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=993251db-acac-65f3-56fb-c35044ab8080@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.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;
as well as URLs for NNTP newsgroup(s).