From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Dan O'Donovan <dan@emutex.com>
Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-acpi@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] disable RTS override on LPSS UART with Auto Flow Control
Date: Mon, 20 Mar 2017 16:15:53 +0200 [thread overview]
Message-ID: <20170320141553.GA29812@kuha.fi.intel.com> (raw)
In-Reply-To: <1489587228-10764-1-git-send-email-dan@emutex.com>
On Wed, Mar 15, 2017 at 02:13:48PM +0000, Dan O'Donovan wrote:
> Currently, Auto Flow Control is not working correctly on the Atom
> X5-Z8350 "Cherry Trail" SoC, because an "RTS override" feature is
> enabled in a vendor-specific register in the LPSS UART. The symptom
> is that RTS is not de-asserted as it should be when RTS/CTS flow
> control is enabled and the RX FIFO fills up.
>
> This appears to be introduced by commit 1f47a77c4e49 ("ACPI / LPSS:
> not using UART RTS override with Auto Flow Control").
>
> To _disable_ the RTS override, bit 3 needs to be _set_ in the
> "GENERAL" register at offset 808h. The power-on default is 0. The
> aforementioned commit appears to have assumed the inverse of this.
True. That is what the public documentation for Atom Z8000
(Cherrytrail/Braswell), and also Z36xx-Z37xx (Baytrail) say. The
internal Lynxpoint PCH documentation I used describe the bit
differently, but we should of course follow the public documentation.
The LPSS block housing the UART is in any case the same in all these
products.
After addressing Andy's comments:
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
This should also go to stable.
Thanks,
--
heikki
prev parent reply other threads:[~2017-03-20 14:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 14:13 [PATCH] disable RTS override on LPSS UART with Auto Flow Control Dan O'Donovan
2017-03-15 15:39 ` Andy Shevchenko
2017-03-20 14:15 ` Heikki Krogerus [this message]
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=20170320141553.GA29812@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dan@emutex.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--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
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).