Tejun Heo wrote:
The following things are needed for a LLD to support PMP.
..
I think that's about it. Feel free to ask if something isn't clear.
..
I think we need better semantics around sata_scr_{read,write}(),
or more specifically
These need to be moved into ata_port_operations
so that LLDs can wrap them to properly manage
the host controller's global link->pmp value.
The problem I've been debugging here for the past 24hrs,
is that sata_mv sets the pmp number globally in hardware,
but then libata does a call to sata_scr_read()
which causes it to change. Without ever changing it back.
Subsequent accesses of shadow registers now point at
the pmp==15 instead of the original PM port.
Doh! No wonder device detection fails for me.
The LLD needs a way to properly manage the current pmp selection,
without having to clone all of the reset logic from libata-core.
I'd like to just re-use that code, but I cannot if it's going
to muck up the pmp selection.
I *think* ata_link_online() is my immediate problem.
It gets called from inside ata_std_softreset(),
and it invokes sata_scr_read().
This prevents me from re-using ata_std_softreset(),
and all of the non-exported functions that *it* calls.
There's very little that's special in the LLD for pmp support,
but the amount of code required seems huge, just to cope with
this simple problem caused.
Ugh.
If sata_scr_{read,write}() were in ata_port_operations,
then I could wrap them to save/restore the original pmp value.
But I'm not sure if that would result in a race against
other command-issue paths on the same port (?).
Tejun ???
For now, I'll try to hack it into sata_mv locally, somehow.
Suggestions?
-
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
