[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN8TOE_dCg6Wi_trE97hXjBPnZi4jpLyoeUEVrbMpgDH-BwKWA@mail.gmail.com>
Date: Thu, 21 Jul 2011 10:13:16 -0700
From: Brian Norris <computersforpeace@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: linux-ide@...r.kernel.org, Valdis.Kletnieks@...edu,
"Rafael J. Wysocki" <rjw@...k.pl>, Jeff Garzik <jgarzik@...ox.com>,
Michael Leun <lkml20100708@...ton.leun.net>,
linux-kernel@...r.kernel.org, Jian Peng <jipeng2005@...il.com>,
Kevin Cernekee <cernekee@...il.com>
Subject: Re: ahci_start_engine compliance with AHCI spec
On Thu, Jul 21, 2011 at 1:49 AM, Tejun Heo <tj@...nel.org> wrote:
> On Mon, Jul 18, 2011 at 11:40:17AM -0700, Brian Norris wrote:
>> On Wed, Jul 13, 2011 at 6:14 AM, Tejun Heo <tj@...nel.org> wrote:
>> > Hmmm... what happens if you don't comment out ahci_start_engine() call
>> > from ahci_start_port()?
>>
>> I wasn't commenting out the ahci_start_engine() from
>> ahci_start_port(). Can you clarify what you mean?
>
> Oh, I meant "what if you comment out..." I wrote that sentence in
> negative and then switched but forgot removing "don't".
OK, well I tried simply commenting out that ahci_start_engine() on
both my special controller and on the Dell E6410 laptop and it worked
just fine (solved my issues and didn't cause any issues on the Dell).
Is this safe? It seems like we end up calling ahci_start_engine() at
the end of the error handling process anyway, so maybe this call is
not really necessary in the first place?
Anyway, I also tried my own fix for this: adding a small delay to wait
for some link recognition at the end of ahci_power_up(). I'm not sure
if this is the greatest, but it also works for both systems I'm
testing. I included the test patch here (based on linux-2.6). BTW, I'm
not sure my mail will be formatted perfectly here. I can resend with
my other mailer if needed.
>> > Is this the same IP block that Jian Peng was using?
>>
>> Yes, it is. I'm taking over some of his work.
>
> Is there any way to detect that particular IP block. It's the only
> one with this problem so maybe we just should treat it specially.
I'm not sure how easy it would be to detect this particular version.
Besides, that is not our first choice solution, as our special-case
fix would not be very well tested for logic bugs.
Brian
---
drivers/ata/libahci.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 41223c7..0c0c444 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -657,6 +657,19 @@ static void ahci_power_up(struct ata_port *ap)
/* wake up link */
writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
+
+ /*
+ * Wait for PxSSTS.DET == 1h or 3h, step 5 of 10.1.1 in
+ * AHCI 1.3 spec. See 10.10.2 for spin-up procedure.
+ */
+ if (ata_wait_register(ap, port_mmio + ahci_scr_offset(ap, SCR_STATUS),
+ 0x01, 0x00, 1, 10)) {
+ /* also wait for DRQ to be cleared */
+ ata_wait_register(ap, port_mmio + PORT_TFDATA, ATA_DRQ,
+ ATA_DRQ, 1, 10);
+
+ /* proceed with step 6, 7 of 10.1.1 in AHCI 1.3 spec? */
+ }
}
static int ahci_set_lpm(struct ata_link *link, enum ata_lpm_policy policy,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists