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 mechanism for anything destined
> for pmp==15.  If it works.  The Marvell proprietary driver
> has some kludgey status polling wrapped around their own use of it.
> 
> One of the chip errata apparently requires this anyway for doing
> the READ_LOG_EXT commands after a device error, so perhaps it will
> work out to be useful in more ways.

Hmmm...

> Speaking of which.. I would like to sort out the "freeze" stuff,
> so that the sata_mv EH doesn't lock out the PMP commands as it
> does today.
> 
> Can you recap what a LLD should be doing in the presence of a PM
> for EH purposes?  Eg. media error on a PMP drive, so what core
> ATA functions should the sata_mv EH interrupt handler be calling,
> and in what sequence.. so that the libata-pmp/eh code can still
> succeed in it's queries to the PM?

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 gonna
cause irq storm, no need to freeze.  The only command EH issues before
resetting which can use DMA protocol is READ_LOG_EXT.  Maybe there needs
to be a way to force PIO protocol for READ_LOG_EXT.  Other than that, if
no-data and PIO-only commands work fine, EH autopsy should work fine.

> Like I noted before, sata_mv will need to eventually hard reset
> the channel regardless, but it does seem permitted to use PIO
> or vendor-unique-FIS PIO (with polling for either) in the interim.

Just set ATA_EH_HARDRESET (which will soon become ATA_EH_RESET with
prefer-COMRESET patchset) from the interrupt handler before requesting EH.

Thanks.

-- 
tejun
-
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

Reply via email to