Re: ahci_start_engine compliance with AHCI spec
From: Tejun Heo
Date: Thu Jul 21 2011 - 04:49:34 EST
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@xxxxxxxxxx> wrote:
> > On Fri, Jul 08, 2011 at 04:01:17PM -0700, Brian Norris wrote:
> >> I'm not sure if the "error_handler" and "hard reset" processes are
> >> intended for initialization...as I said I'm a little new!
> > That's how it's supposed to work. EH is integral part of probing
> > sequence.
> I began to suspect that was the case. It just seemed awkward that the
> expected operation includes a code path named "error".
Heh, well, SCSI called it error_handler but inside ATA I usually call
it exception handler and probing / hot plugging / etc are exceptional
cases compared to boring sending and receiving of bits to already
attached devices. ;)
> >> I have a few other questions:
> >> What operation could be putting devices in DRQ or BSY states during
> >> initialization but before ahci_start_engine?
> > Hmmm... I have no idea, maybe it has something to do with the first
> > D2H Reg FIS device sends after link gets reset during controller init?
> OK, I'll try to track that one down, but I think that DRQ is set much
> earlier in the initialization than that and won't be cleared until
> between ahci_power_up() and ahci_start_engine() - I tried
> wait-and-poll at several different points in the process to understand
> the HBA/device initialization process.
> > 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".
> > 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/