About MMC Send Event
keiji_katata at post.pioneer.co.jp
keiji_katata at post.pioneer.co.jp
Thu Jul 26 05:06:10 PDT 2001
* From the T10 Reflector (t10 at t10.org), posted by:
* keiji_katata at post.pioneer.co.jp
*
Hi Xin Li, (Is this real name?)
The Send Event command is designed for following situation.
1. Device gets an External Request. The External Request requests some work
to device.
2. Device reports the External Request to host via Get Event/Status
Notification Class 3.
3. There are 3 cases.
3-1. If host understands the External Request perfectly, host can send a
set of SCSI command to the device to perform the action specified by the
External Request.
3-2. If host can not understand the External Request but host supports
Class 3 event, host shall issue Send Event command with the External
Request. Then device can perform the action specified by the External
Request.
3-3. If host does not support Class 3 event, there is no way. If persistent
prevent is ON, device shall not perform the action specified by the
External Request. If persistent prevent is OFF, it is vender specific
matter.
This is the original idea of External Event handling. If device does not
support External Request (maybe all), device shall not report "I support
it, but it is a lie." to host to pass the W?Q?. If every device becomes
such a BAD DRIVE, host can not use External Event system in future.
regards,
Keiji Katata
PIONEER CORP.
to: Keiji Katata/Pioneer
cc: mtfuji5 at avc-pioneer.com, t10 at t10.org
subject: Re: About MMC Send Event
Hi, Keiji-san,
Thank you very much for your reply !!
After check the Mt. Fuji Spec and MMC2, MMC3 Spec, as my understanding. The
SEND EVENT command description in both MMC2 and MMC3 were wrong about the
External Event Request(Class 3)(MMC 2 page 268 and MMC3 page 344). It
should be Notification Class 1 Event, This match other description about
the command with Notification Class field in Event Parameter Header and
definition of Operational Request Code (MMC2 page 269, MMC3 page 345). Is
this right?
For Mt. Fuji device, SEND EVENT should be implemented for all device
supported Notification Event Class 3 events. If this requirement apply to
MMC 2 or MMC 3 device? if the device doesn't support both Class 1 and Class
3 event, if it's OK to omit the command ?
Thank you very much,
Xin Li
Senior Firmware Engineer
Oak Technology, Inc.
139 Kifer Court
Sunnyvale, CA 94086
Tel: (408)616-6127
Fax: (408)523-6524
Email: Xinli at oaktech.com
keiji_katata at post.pio
neer.co.jp To: XinLi at oaktech.com
cc: t10 at t10.org,
mtfuji5 at avc-pioneer.com
07/25/2001 01:33 AM Subject: Re: About MMC
Send Event
Hello Xin Li and all,
1. This should be error of document.
2. If unit supports Class 3 Event, the unit shall support Send Event
command. Please refer to Fuji5r13.pdf on page 237. This is original
proposal document and available at <ftp.avc-pioneer.com>.
About OP code, mmc3r10a.pdf 7/12 also has 5Dh.
I propose that Bill chairman of MMC3 should discuss these issues in the
next meeting or should fix document as well.
Best regards,
Keiji Katata
PIONEER CORP.
to: t10 at t10.org
cc: (bcc: Keiji Katata/Pioneer)
subject: About MMC Send Event
* From the T10 Reflector (t10 at t10.org), posted by:
* XinLi at oaktech.com
*
Hi,
I have some questions about MMC2 command SEND EVENT (A2h). Could someone
there help? Thank you in advance!!!
My questions are:
1. In the Specification (NCITS 333, T10/1288D version 11a, August 30,
1999), In the SEND EVENT command description, it says that" Only events of
Class External Request (Class 3) shall be sent via SEND EVENT command"(page
268) . But in the Event Parameter Header(page 269), the field 'Notification
Class" was set to 1h(3bits field). By definition(page 146), the 1h Class is
"Operational Change Request/Notification" class. it conflict with the
command description.
2. SEND EVENT is mandatory command for ATAPI device (page 303), but not all
ATAPI device have front panel with Play, Pause, Rewind, etc. How this
command be implemented without the Class 3 event at all?
By the way, the command op code was wrong in the CDB on page 268. It should
be A2h, not 5Dh. It was also wrong in the MMC 3 Specification( NCTIS XXX
T10/1363-D, revision 09, march 7, 2001).
Thank you!
Xin Li
Senior Firmware Engineer
Oak Technology, Inc.
139 Kifer Court
Sunnyvale, CA 94086
Tel: (408)616-6127
Fax: (408)523-6524
Email: Xinli at oaktech.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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
mailing list