[t13] Re: Removable Media Status Notification feature set
keiji_katata at post.pioneer.co.jp
keiji_katata at post.pioneer.co.jp
Tue Apr 13 23:04:10 PDT 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
Sorry for delay of this reply.
C/DVD device has 4 different way to notify the media status to host.
1. Unit Attention notification
6/28/00 "NOT READY TO READY CHANGE, MEDIUM MAY HAVE CHANGED" error is
reported from device to host. SPC defines this 1st way. And all host
software use this way on any removal devices that supports SAM.
2. Media Class Events
MMC device (packet based removal media device other than SBC) reports and
controls its own eject key with GET EVENT/STATUS NOTIFICATION command. Some
major OSs use this 2nd way. The relationship with the 1st way is described.
Then the 1st way and the 2nd way do not have any conflict. This is designed
to improve user experience of multimedia device and multimedia application
with OS help.
3. Removable Media feature set
ATA specification has this 3rd way. ATA device (removal ATA HDD) uses this
3rd way. Unfortunately, the relationship of 3rd way with 1st and 2nd way is
not described in any document. Anyway, in MMC2, member understood that 3rd
way is not necessary for Packet device.
4. Asynchronous Notification
SATA defines this 4th way. It seems that this may be subset of 3rd way. And
this 4th way works only SATA interface. STAT says that the use of
Asynchronous Notification is not described in this document. It should be
described command specification. (What name does the document have?)
The 1st way works well. The 2nd way improves multimedia application problem
with OS help. How 3rd and 4th work with other physical interface layer?
Well.. multimedia device should work with any transport layer, IP, USB,
UWB, IEEE1394, Parallel SCSI, Serial SCSI, ATA, SATA and !@#$.
I think T13 should explain the relationship between 1&2 and 3, between 3
and 4. Who will be volunteer?
Pat LaVarre <p.lavarre at ieee.org>@t13.org on 2004/04/03 05:26:12
$BAw?.<T(J: owner-forum at t13.org
$B08 at h(J: keiji_katata at post.pioneer.co.jp
cc: Forum at t13.org, T10 at t10.org, mtfuji5 at avc-pioneer.com
$B7oL>(J: [t13] Re: Removable Media Status Notification feature set
This message is from the T13 list server.
> Removable Media Status Notification feature
> set of ATA.
Here I suppose we mean the ATA ops x EF 95, x EF 31, and xDA.
I remember WHQL sometimes required the device to support those ops, but
last I checked the relevant WHQL test erroneously required op xA0 03
Packet/ Request Sense to leave the x3F6 & x01 ERR bit unchanged, ouch,
e.g. even in the presence of a UDMA CRC failure.
> I believe that this function is overlapped to SBC/MMC command set
Yes redundant with PDT x05 MMC op x4A
Massively distributed as legacy for PDT x 0E/ 07/ 04/ 00 RBC/ SBC ...
I mis/remember mostly I studied this in the Win 95 B ATAPI that
couldn't copy odd lengths of bytes per cdb. Rumour, be it truth or
slander, says Win XP/ 2K didn't bother with these ATA ops.
Are you saying someone is trying to revive them? Please no?
> and is incomplete to use in product.
Incomplete as you describe below, yes.
> So in MMC/Fuji discussion we were
> concluded that Packet device and its host software does not use this
> feature set in ATA.
> MMC has embedded changer model. SBC/MMC have many different write
> or similar media and device combination status. Removable Media Status
> Notification feature set of ATA cannot cover these items.
> ATA layer persistent prevent, C/DVD class layer persistent prevent and
> application layer prevent may conflict each other.
> I think if T13 group needs to keep this feature in ATA, someone must
> explain this feature in MMC WG.
Accurate doc would be nice, sure.
The design element I maybe most enjoyed was having the host conclude
that an SBC op x2B Seek was an MMC op x2B Seek Immediate which
completed not when x3F6 Status & x40 DRDY rose but instead prematurely
when op xDA set x3F6 Status & x01 ERR rose because the disk was
> And T13 group may need to add some
> descriptions to keep compatibility with SBC/MMC command set.
Can you say more about what you have in mind?
> I'm waiting for any commnet.
Hope this helps.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10