** This is the quasi-official and semi-temporary T13 email list server. **
Sumit,
The standard should make it clear that in case (2) you always get two
interrupts, one when ready to transfer data and one at the completion of the
command.
Perhaps a little background would be helpful. The original implementations
of ATAPI devices used old ATA interface chips and all of the SERVICE stuff
was done by very slow microprocessors. Therefore, even though the device was
ready to transfer data when it asserted SERV and got back the SERVICE
command, it was a long time before it got DRQ asserted and could actually
begin the transfer. Rather than keep the host in a polling loop all that
time, the enablable SERVICE interrupt was invented.
It was made enablable because it was recognized that eventually people could
put in hardware assists for the SERVICE command so the the data transfer
could be initiated very quickly and it would then be more efficient for the
host to poll rather than sustain an interrupt latency. No thought was ever
given to eliminating the interrupt at command completion.
Hope this helps.
Regards, Pete
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 11, 2001 2:39 PM
> To: '[EMAIL PROTECTED]'
> Subject: [temp t13] Service CMD question
>
>
> ** This is the quasi-official and semi-temporary T13 email
> list server. **
>
>
>
> Does anybody know the correct answer to his inquiry?
> I don't know if this is addressed specifically in the ATA-6 spec.
> thanks in advance for your help
>
> - Sumit
>
>
> We have a question regarding a SERVICE interrupt described in
> ATA6 as following:
>
> ***************************************************************
> 8.50.21 Enable/disable SERVICE interrupt
> Subcommand codes 5Eh and DEh allow a host to enable or disable
> the asserting of an interrupt pending when DRQ is set to one in
> response to a SERVICE command.
> ***************************************************************
>
> Question::
> In the case of (2), is it required that the INTRQ signal be
> asserted necessarily twice? Or is it possible to omit the second
> assertion (at the moment BSY gets low)?
>
>
> We think that this description requires each signal be asserted
> as following chart:
>
> (1)When SERVICE interrupt is disabled
>
> SERVICE Cmd Issue
> |
> | |----------------| Data Xfr
> V___ ___
> BSY __| |________________| |______
> ________________
> DRQ ______| |__________
> ___
> INTRQ ___________________________| |__
>
>
> (2)When SERVICE interrupt is enabled
> ___ ___
> BSY __| |________________| |______
> ________________
> DRQ ______| |__________
> ___ ___
> INTRQ _______| |_______________| |__
>
>
> Question::
> In the case of (2), is it required that the INTRQ signal be
> asserted necessarily twice? Or is it possible to omit the second
> assertion (at the moment BSY gets low)?
>
>
>
> --
> If you have any questions or wish to unsubscribe send a
> message to Hale Landis, [EMAIL PROTECTED] To post to
> this list server send your message to [EMAIL PROTECTED]
>
> For questions concerning Thistle Grove Industries or TGI's
> list services please send email to [EMAIL PROTECTED]
>
>
>
--
If you have any questions or wish to unsubscribe send a
message to Hale Landis, [EMAIL PROTECTED] To post to
this list server send your message to [EMAIL PROTECTED]
For questions concerning Thistle Grove Industries or TGI's
list services please send email to [EMAIL PROTECTED]
