Thread (37 messages) 37 messages, 7 authors, 2008-02-26

Re: new ata_port_operations for .pmp_{read,write} ?

From: Mark Lord <hidden>
Date: 2008-02-25 04:46:19

Tejun Heo wrote:
Hello, Mark.

Mark Lord wrote:
quoted
Mark Lord wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help