Tejun Heo wrote:
Mark Lord wrote:
..
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
Hello, Mark.
Mark Lord wrote:
MMmm.. maybe the vendor unique FIS mechanism of the chipset
can save the scenario here. It would seem to be a reasonable
way to direct a FIS (anything up to 8KB) at a specific pmp,
without changing the default pmp on the channel.
I can have qc_issue use that
Tejun Heo wrote:
libata doesn't really put much restrictions on what a LLD should do on
entering EH and if the controller's behavior is predictable, there's no
reason to freeze the port. If the problem is that the DMA engine isn't
usable after PMP error but it's known that the controller isn't
Hello, Mark.
Mark Lord wrote:
libata doesn't really put much restrictions on what a LLD should do on
entering EH and if the controller's behavior is predictable, there's no
reason to freeze the port. If the problem is that the DMA engine isn't
usable after PMP error but it's known that the
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
Jeff Garzik wrote:
Tejun Heo wrote:
Yeah, exactly. I think what needs to be done is to separate out SFF
assumptions from core layer, factor out SFF-proper helpers and use them
to implement LLDs for quasi-SFF controllers.
Thinking long term, I continue to hope that SFF support can eventually
Mark Lord wrote:
Jeff Garzik wrote:
Tejun Heo wrote:
Yeah, exactly. I think what needs to be done is to separate out SFF
assumptions from core layer, factor out SFF-proper helpers and use them
to implement LLDs for quasi-SFF controllers.
Thinking long term, I continue to hope that SFF
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
To repeat myself from threads past...
In particular with the Marvell 6440 (SATA/SAS, drivers/scsi/mvsas.c)
when SATA PMP support is completed, we will want to look at passing
things other than normal ATA commands via -qc_issue.
Although selection isn't necessarily, talking to a PMP is
Mark Lord wrote:
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,
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
Tejun Heo wrote:
Yeah, exactly. I think what needs to be done is to separate out SFF
assumptions from core layer, factor out SFF-proper helpers and use them
to implement LLDs for quasi-SFF controllers.
Thinking long term, I continue to hope that SFF support can eventually
be separate into a
Mark Lord wrote:
Tejun,
Here's a first cut at this for discussion.
You may prefer different names for the invoking functions
inside libata-pmp.c, rather than simply pmp_read() and pmp_write(),
but I've been up too long and couldn't think of a better name.
An alternative to all this, might be
Mark Lord wrote:
Note that, while this does work for sata_mv, I'm still thinking about it.
I'm not totally clear yet (more reading to do) as to how/when
the ATA shadow/taskfile registers get updated to reflect those
for the currently selected pmp..
It would seem that with other parts of
Mark Lord wrote:
Mark Lord wrote:
...
And for that matter, is it possible for sata_pmp_read() to be called
while the link is active with another command ? Not today, it seems,
but what about when hotplug polling gets implemented ?
..
That's the one I'm most concerned about. Should I be?
Hello, Mark.
Mark Lord wrote:
This patch provides two new struct ata_port_operations methods for this,
and modifies the code in libata-pmp to use them if provided.
...
Note that, while this does work for sata_mv, I'm still thinking about it.
I'm not totally clear yet (more reading to do)
Hello, Mark.
Mark Lord wrote:
And for that matter, is it possible for sata_pmp_read() to be called
while the link is active with another command ? Not today, it seems,
but what about when hotplug polling gets implemented ?
..
That's the one I'm most concerned about. Should I be?
...
Tejun Heo wrote:
Yeah, this is an interesting problem. There are basically multiple sets
of TF registers and the SFF way of assuming single set doesn't really
work well and I don't really think adding -pmp_read/write is the
correct long term solution to the problem. We need to confine direct
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
19 matches
Mail list logo
