This message is from the T13 list server.


Well given the specification totally lacks the three party position, a
general break dowm of the boundaries would be nice coming from Hale.
Even though I think I have a strong grasp of the obvious, there is alway
more to be learned.

The reality is there are three parts and two boundaries, not the 2:1
defined in the specification.

DEVICE -- HBA(host) -- DRIVER(host)

The spec is only telling one about boundaries, and has nothing to do with
implimentation.

Classic example is what to do when an interrupt is asserted?

If you are preemptive operations, all one needs to do ack the intq and
service the thread later.

If one is doing data checking in a pio only, once could sniff the data up
and down the data taskfile register for inband command pattern opcode
callers for DRM things.

Basically what ever the "HOST-DRIVER" wants to do regardless to the SPEC
is/can be totally orthogonal.  There are things I do to test hba-device
pairs which are totalally against the SPEC but that is DRIVER only region
and by definition of the SPEC, the device-hba pair had better do the
correct and proper thing.

ABORT or DIE is the expected response, anything else is violation.

Cheers,


Andre Hedrick
LAD Storage Consulting Group

On Mon, 1 Jul 2002, Ooi, Thien Ern wrote:

> This message is from the T13 list server.
> 
> 
> Hale,
> Splitting them would imply a particular hardware/software partition and
> implementation, which may not be desirable in a specification.  Further,
> host vendors may choose to deviate by automating in hardware, certain
> software functions (eg: polling the status register).   
> 
> Regards,
> T.E. Ooi.
> 
> -----Original Message-----
> From: Hale Landis [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 28, 2002 12:55 PM
> To: T13 List Server
> Subject: [t13] more DMA confustion
> 
> ...
> 
> Maybe we should split the R/W DMA host side and PACKET DMA host side
> diagrams into two diagrams that respectively show what the HOST SIDE
> SOFTWARE and HOST SIDE HARDWARE are expected to do? Or maybe we
> should just add a little more text, like a good high level
> explaination of how DMA works?
> 
> 

Reply via email to