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

[Mark Lord <liml@rtr.ca>]

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.