MMC3 & Fuji5 R1.3 revise proposal

keiji_katata at post.pioneer.co.jp keiji_katata at post.pioneer.co.jp
Thu Aug 23 05:54:10 PDT 2001




Hello Bill,

Thank you for your reply.

>Proposal 1.a is preferred.  It has the least impact upon the standards.
Me too.

>A class 1 event is required when the device changes...
Exactly. In CDs21 meeting, I find that many members feel it is hard to
implementation.

>There are other ways that the host might choose to respond.  Why..
Because this is the solution for the "4.1 problem" in proposal1.pdf. Read
Buffer Capacity can not help "4.1 problem".

>MMC3 Rev 10c, page 283, lines 6 through 22 describe..
Here is inconsistency. Document says "All other commands shall execute
normally, but may force a SYNCHRONIZE CACHE before executing." Then "WRITE
command may be terminated with CHECK CONDITION" is written. This "may" can
not be valid if a reader is not familiar with CD-R/RW.


By the way, can we discuss these issue in Sep. MMC? Do you have any idea
that help reader of MMC3 document?

Best regards,

Keiji Katata
PIONEER CORP.




reply to mtfuji5 at avc-pioneer.com

to:   mtfuji5 at avc-pioneer.com
cc:   ml.cds21solutions.org, sff_reflector at sun.com (bcc: Keiji
      Katata/Pioneer)
subject:  Re: MMC3 & Fuji5 R1.3 revise proposal


Katata-san,
I respectively give my preferences:



> Hello all,
>
> I would like to ask following questions.
>
> Question 1: allocation length of Get Ev/St Nor command
>
> Which proposal do you like in [proposal 1.a] and [1.b]? In other wording,
> which do you use in your product? We need to decide one of two (or three?
> if you have other proposal).
>





Proposal 1.a is preferred.  It has the least impact upon the standards.



>
> Question 2: making Class 1 event mandatory
>
> Do you implement Class 1 event on your product? How do you think?
> In my proposal, define Cls1Ev bit and define Cls1Ev bit shall be 1 on the
> version of document. Is it correct wording?
>


A class 1 event is required when the device changes from READY to NOT READY
or NOT READY to READY.  The intent of this behavior was to eventually
replace
unit attention conditions.  There are a number of cases where this might
occur.  Perhaps we should define the general behavior more specifically.
We
may then note that this event class is mandatory.


>
> Question 3: 2/4/8 error description
>
> For Buffer overflow control, 2/4/8 error is defined. If device can not
> terminate Write command (FUA=0) immediately, device can report 2/4/8
error.
> Host shall retry the Write command.
> I need better description. Would you give me your idea?
>
> The definition is as follows.
>
> The command that is allowed to report not ready in Table 80 - Not Ready
> Error & Time-out Unit Attention Reporting (by Command) (on page 194) may
be
> terminated with CHECK CONDITION Status, 2/04/08 LOGICAL UNIT NOT READY,
> LONG WRITE IN PROGRESS. While writing is occurring, if Write 10/12
command
> is terminated with CHECK CONDITION Status, 2/04/08 LOGICAL UNIT NOT
READY,
> LONG WRITE IN PROGRESS, host shall issue the same Write 10/12 command
> again. After logical unit becomes ready due to sufficient buffer capacity
> for the Write 10/12 command, the Write 10/12 command shall be performed
> normally. [description 4]
>





There are other ways that the host might choose to respond.  Why should we
force specific behaviour upon the host?



>
> Question 4: drive response during writing
>
> For implicit sync cache, I propose three different descriptions for
> sequential, restricted overwrite and random write. I think this is fit to
> actual implementation. How about your product?
>
> Example Read command during writing after write command:
> sequential recording: 2/4/8 (2/4/7) error (both BUFE=0/1)
> restricted overwrite: wait completion and executed normally
> random write        : wait completion and executed normally
>
> Example non sequential write command during writing after write command:
> sequential recording: 5/21/02 error (both BUFE=0/1)
> restricted overwrite: 2/4/8 error
> random write        : wait completion and executed normally
>





MMC3 Rev 10c, page 283, lines 6 through 22 describe exactly how the device
should respond.  I presume that the latest Fuji document is similar.  Lines
18 through 22 seem to address your specific questions.  Is it not clear?

Kind regards,
Bill McFerrin


>
> Please send me your idea, comment.
>
> Best regards,
>
> Keiji Katata
>
> PIONEER CORP.
>





More information about the T10 mailing list