data_xfer too fast? - SATA PIO

data_xfer too fast? - SATA PIO

[Mat Loikkanen]

We've run into the issue of ata_mmio_data_xfer() reading our host
controller's data fifo too fast -- requesting a data word when the fifo was
empty, before the device had sent PIO data (in our observed case somewhere
in the middle of a 512 byte IDENTIFY DEVICE PIO data transfer).  I can't see
any provision in Libata for a case like ours where the processor and bus are
"too fast".  Has anyone run into this issue before?  Any ideas on what we
should do about it?  We can make our host controller to wait-state the bus
... but for how long, what if data never arrives ...  Thanks for any help.

-mat
 
Mat Loikkanen
Synopsys, Inc.

Re: data_xfer too fast? - SATA PIO

[Mark Lord]

Err.. PIO data transfer within a sector (or multiple sector block)
is supposed to be synchronous in hardware.  This means the chip/board
should be using IORDY to stretch the cycle until data can be supplied
within each 256-word interrupt group.

Right?

Mat Loikkanen wrote:
> We've run into the issue of ata_mmio_data_xfer() reading our host
> controller's data fifo too fast -- requesting a data word when the fifo was
> empty, before the device had sent PIO data (in our observed case somewhere
> in the middle of a 512 byte IDENTIFY DEVICE PIO data transfer).  I can't see
> any provision in Libata for a case like ours where the processor and bus are
> "too fast".  Has anyone run into this issue before?  Any ideas on what we
> should do about it?  We can make our host controller to wait-state the bus
> ... but for how long, what if data never arrives ...  Thanks for any help.
> 
> -mat
>  
> Mat Loikkanen
> Synopsys, Inc.

RE: data_xfer too fast? - SATA PIO

[Mat Loikkanen]

Thanks, Mark.  I think the hardware designer plans to do this -- add wait
states on the bus (we sell soft IP, so our controller is on an FPGA on our
test platform).  I wasn't sure if there were any PCI/ISA-isms that were at
play here.  We are ARM AMBA/AHB bus based, targeting embedded applications.

-----Original Message-----
From: Mark Lord

Err.. PIO data transfer within a sector (or multiple sector block)
is supposed to be synchronous in hardware.  This means the chip/board
should be using IORDY to stretch the cycle until data can be supplied
within each 256-word interrupt group.

Right?

Mat Loikkanen wrote:
> We've run into the issue of ata_mmio_data_xfer() reading our host
> controller's data fifo too fast -- requesting a data word when the fifo
was
> empty, before the device had sent PIO data (in our observed case somewhere
> in the middle of a 512 byte IDENTIFY DEVICE PIO data transfer).  I can't
see
> any provision in Libata for a case like ours where the processor and bus
are
> "too fast".  Has anyone run into this issue before?  Any ideas on what we
> should do about it?  We can make our host controller to wait-state the bus
> ... but for how long, what if data never arrives ...  Thanks for any help.
> 
> -mat
>  
> Mat Loikkanen
> Synopsys, Inc.

Re: data_xfer too fast? - SATA PIO

[Benjamin Herrenschmidt]

On Mon, 2005-02-28 at 15:39 -0800, Mat Loikkanen wrote:
> We've run into the issue of ata_mmio_data_xfer() reading our host
> controller's data fifo too fast -- requesting a data word when the fifo was
> empty, before the device had sent PIO data (in our observed case somewhere
> in the middle of a 512 byte IDENTIFY DEVICE PIO data transfer).  I can't see
> any provision in Libata for a case like ours where the processor and bus are
> "too fast".  Has anyone run into this issue before?  Any ideas on what we
> should do about it?  We can make our host controller to wait-state the bus
> ... but for how long, what if data never arrives ...  Thanks for any help.
> 

You should waitstate the bus, with eventually some sanity limit built
into the HW.

Ben.