Tejun Heo wrote:
Hello, Mark.
Mark Lord wrote:
Mark Lord wrote:
An alternative to all this, might be to expose the "select_pmp()"
function shown in the sample code, and have libata-pmp.c call that,
instead of having the new new .pmp_{read,write} functions.
..
I wonder if this might be more viable than first thought.
Say the LLD, be it ata_piix or sata_mv or sata_vw, were to provide
an option ata_operations method for "select_pmp_port(pmp)",
which the core could invoke prior to any direct manipulation
of the shadow registers.
I don't really think that's a good solution. That's the quickest
solution for sata_mv but it just works around more fundamental problem
of assuming SFF behavior in core layer which we need to drop anyway.
...
No, the quickest solution for sata_mv, the one I apparently will now be using,
is to just clone about 250 lines of reset/debouce/probe code from libata-core
and change perhaps five lines of it to work around this issue plus some
chipset errata.
What I was thinking of, before, is the SATA specification which details
use of bits in the SCR to select a PMP port. Pretty much exactly as
this chipset does it, except in the SCR rather than a proprieary port.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
