Tejun Heo wrote:
Mark Lord wrote:
But no big deal.  I can clone code and not bother you any more.
In fact, some of the cloned code was already in sata_mv, and I removed
it this past week in my local working copy.  I'll just restore that,
along with another big blob so that we can select pm port where needed.

What a shame.

The order is somewhat reversed here and I can understand why you're
frustrated but I'm just trying to make things look right in long term,
so feel free to bother me. :-) For temporary solution, I'm okay either
way.  I'll clean things up later when the necessary core changes are made.

MMmm.. maybe the "vendor unique FIS" mechanism of the chipset
can save the scenario here.  It would seem to be a reasonable
way to direct a FIS (anything up to 8KB) at a specific pmp,
without changing the "default" pmp on the channel.

I can have qc_issue use that mechanism for anything destined
for pmp==15.  If it works.  The Marvell proprietary driver
has some kludgey status polling wrapped around their own use of it.

One of the chip errata apparently requires this anyway for doing
the READ_LOG_EXT commands after a device error, so perhaps it will
work out to be useful in more ways.

Speaking of which.. I would like to sort out the "freeze" stuff,
so that the sata_mv EH doesn't lock out the PMP commands as it
does today.

Can you recap what a LLD should be doing in the presence of a PM
for EH purposes?  Eg. media error on a PMP drive, so what core
ATA functions should the sata_mv EH interrupt handler be calling,
and in what sequence.. so that the libata-pmp/eh code can still
succeed in it's queries to the PM?

I think James is also interested in a decent explanation of
how to tie into the libata-eh stuff.

Like I noted before, sata_mv will need to eventually hard reset
the channel regardless, but it does seem permitted to use PIO
or vendor-unique-FIS PIO (with polling for either) in the interim.

To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to