From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <tj@kernel.org>
Cc: Brian Norris <computersforpeace@gmail.com>,
linux-ide@vger.kernel.org, Valdis.Kletnieks@vt.edu,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Michael Leun <lkml20100708@newton.leun.net>,
linux-kernel@vger.kernel.org, Jian Peng <jipeng2005@gmail.com>,
Kevin Cernekee <cernekee@gmail.com>
Subject: Re: [PATCH #upstream] ahci: start engine only during soft/hard resets
Date: Sat, 23 Jul 2011 18:12:39 -0400 [thread overview]
Message-ID: <4E2B4757.7040204@pobox.com> (raw)
In-Reply-To: <20110722094126.GI2622@htj.dyndns.org>
On 07/22/2011 05:41 AM, Tejun Heo wrote:
> This is another attempt at fixing the same problem that 270dac35c2
> (libata: ahci_start_engine compliant to AHCI spec) tried to solve.
> Unfortunately, 270dac35c2 created regressions for a lot more common
> controllers and got reverted.
>
> This specific AHCI IP block becomes a brick if the DMA engine is
> started while DRQ is set. It is not possible to avoid the condition
> completely but the most common occurrence is caused by spurious use of
> ahci_start_engine() from ahci_start_port() during init sequence.
>
> DMA engine is started after both soft and hard resets and
> ahci_start_port() is always followed by resets, so there is no reason
> to start DMA engine from ahci_start_port().
>
> This patch removes ahci_start_engine() invocation from
> ahci_start_port(). This change makes failure path of
> ahci_port_suspend() leave engine stopped without following resets.
> This is resolved by replacing ahci_start_port() call with
> ata_port_freeze() which forces resets afterwards, which is the better
> behavior anyway.
>
> Signed-off-by: Tejun Heo<tj@kernel.org>
> Reported-by: Brian Norris<computersforpeace@gmail.com>
> Reported-by: Jian Peng<jipeng2005@gmail.com>
> ---
> Jeff, this needs to be tested for a while in linux-next before sending
> it mainline. Please apply it for 3.1 merge window and let's see
> whether anything explodes.
Stuffed this into branch #upstream-next, which appears periodically for
situations like this. #upstream-next will become #upstream after the
merge window closes.
next prev parent reply other threads:[~2011-07-23 22:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-08 23:01 ahci_start_engine compliance with AHCI spec Brian Norris
2011-07-13 13:14 ` Tejun Heo
2011-07-18 18:40 ` Brian Norris
2011-07-21 8:49 ` Tejun Heo
2011-07-21 17:13 ` Brian Norris
2011-07-22 9:03 ` Tejun Heo
2011-07-22 9:41 ` [PATCH #upstream] ahci: start engine only during soft/hard resets Tejun Heo
2011-07-22 20:41 ` Brian Norris
2011-07-23 22:12 ` Jeff Garzik [this message]
2011-08-03 0:06 ` ahci_start_engine compliance with AHCI spec Brian Norris
2011-08-04 9:44 ` Tejun Heo
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=4E2B4757.7040204@pobox.com \
--to=jgarzik@pobox.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=cernekee@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=jipeng2005@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml20100708@newton.leun.net \
--cc=rjw@sisk.pl \
--cc=tj@kernel.org \
/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).