From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>,
Yegor Yefremov <yegorslists@googlemail.com>,
Peter Hurley <peter@hurleysoftware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems
Date: Tue, 09 Aug 2016 19:07:21 +0300 [thread overview]
Message-ID: <1470758841.4887.1.camel@linux.intel.com> (raw)
In-Reply-To: <20160809130229.GN1729@lahna.fi.intel.com>
+Peter
On Tue, 2016-08-09 at 16:02 +0300, Mika Westerberg wrote:
> Hi,
>
> I noticed that with v4.8-rc1 serial console of some of our Broxton
> systems does not work properly anymore. I'm able to see output but
> input
> does not work.
>
> I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
> ("tty/serial/8250: use mctrl_gpio helpers").
Mika, thanks for the detailed analysis.
Yegor, consider this mail as a follow up to [1].
[1] http://www.spinics.net/lists/linux-serial/msg23071.html
>
> The reason why it fails is that in ACPI we do not have names for GPIOs
> (except when _DSD is used) so we use the "idx" to index into _CRS GPIO
> resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
> calling devm_gpiod_get_index_optional() passing "idx" of 0 for each.
> The
> UART device in Broxton has following (simplified) ACPI description:
>
> Device (URT4)
> {
> ...
> Name (_CRS, ResourceTemplate () {
> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
> IoRestrictionOutputOnly,
> "\\_SB.GPO0", 0x00, ResourceConsumer)
> {
> 0x003A
> }
> GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
> IoRestrictionOutputOnly,
> "\\_SB.GPO0", 0x00, ResourceConsumer)
> {
> 0x003D
> }
> })
>
> In this case it finds the first GPIO (0x003A which happens to be RX
> pin
> for that UART), turns it into GPIO which then breaks input for the
> UART
> device. This also breaks systems with bluetooth connected to UART
> (those
> typically have some GPIOs in their _CRS).
>
> Any ideas how to fix this?
>
> We cannot just drop the _CRS index lookup fallback because that would
> break many existing machines out there so maybe we can limit this to
> only DT enabled machines. Or alternatively probe if the property first
> exists before trying to acquire the GPIOs (using
> device_property_present()).
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2016-08-09 16:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 13:02 tty/serial/8250: use mctrl_gpio helpers - Causes problems on ACPI systems Mika Westerberg
2016-08-09 16:07 ` Andy Shevchenko [this message]
2016-08-18 9:15 ` Yegor Yefremov
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=1470758841.4887.1.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=peter@hurleysoftware.com \
--cc=rafael.j.wysocki@intel.com \
--cc=yegorslists@googlemail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.