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

[Mark Lord <liml@rtr.ca>]

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_svw, 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.

It would really only be needed in perhaps three or four places total
(eg. sata_pmp_read/write, and before writes to the ata "ctl" register).
This could be a reasonably tidy way for the core to keep the LLD
abreast of its intent when accessing things.

I really would like to keep the LLD code small, and have good solid
core routines for non-hardware specific functionality.  All of this stuff
I'm beginning to do with sata_mv would be trivial if I wanted to bloat
the LLD, but really.. only a tiny bit of it need be custom to sata_mv.

The existing SFF reset/probe/pmp stuff is just about exactly what
sata_mv needs.. and I feel a strong desire to not clone/duplicate
that hard-won functionality.

Much of it I can see being shared with other half-and-half chipset drivers
as we add PMP functionality to those.

Maybe that's just the embedded side me showing through?

It is tricky to define the right interfaces, though, as each chipset
does throw its own unique curve balls at us.

I may prototype this select_pmp_port() concept in sata_mv(),
and see how it works out (or not).

Cheers