From: David Burg <daviburg@windows.microsoft.com>
To: "t10@t10.org" <t10@t10.org>,
"mtfuji5@avc-pioneer.com"
<mtfuji5@avc-pioneer.com>
CC: Michael Xing <xiaoxing@microsoft.com>,
Frank Shu
<frankshu@windows.microsoft.com>,
David Walp <David.Walp@microsoft.com>,
Ope
Aladekomo <Ope.Aladekomo@microsoft.com>
Date: Fri, 21 Nov 2008 01:22:46 -0800
Subject: SATA AN, Sleep power state and media arrival notification
X-Message-Number: 9338
Formatted message: HTML-formatted message
Hi,
In a conference call with a SATA chipset manufacturer earlier this week the
manufacturer expressed difficulties in the implementation of SATA
Asynchronous Notification (AN) because of the perceived lack of clarity in
the handling of sleep mode in combination with AN. As the manufacturer is not
present on this reflector or the Mt Fuji committee, I am relaying their
issue. However the chipset manufacturer is working with device
manufacturer(s) from Mt Fuji committee and expect that member(s) will be
familiar and supportive of the issue resolution.
The chipset manufacturer is not clear what is the specified device behavior
when the host issues a START/STOP UNIT command with parameters to request
sleep mode.
The first set of questions is regarding the entry to sleep mode. Should a
power state notification be generated? If a power state notification is
generated, should AN be set? If a notification is generated and AN is set,
will the device complete GESN from the host despite been in sleep mode? Does
setting the immediate bit change the behavior of event notification?
The second set of questions is regarding notification while in sleep mode. In
sleep mode, can the user insert an optical media? If the user can, can the
device generate a media arrival event? If so, can AN be posted and will the
device complete GESN from the host despite been in sleep mode?
If the user can insert a media but the device cannot generate a media arrival
event, the manufacturer is concerned by the user experience.
If the user cannot insert a media - for instance if the device is actually
powered off in sleep and the door won't open - can PC vendors really use this
mode for power saving without affecting the user experience?
Microsoft's (not speaking on the manufacturer's behalf now) understanding of
the current Mt Fuji specification is that no event is generated *after*
entering sleep mode. So if the host issues a START/STOP UNIT command with
parameters to request sleep mode with immediate bit set, the command
completes, no event is generated and no command but reset will work after the
START/STOP UNIT command completes.
But if the host issues a START/STOP UNIT command with parameters to request
sleep mode with immediate bit NOT set, the command completes right away, no
power event is posted BUT if a GESN command is still processed while entering
sleep mode, Power Status Field is set to "4h - Sleep - The device is about to
enter sleep state", and AN is not set.
Microsoft's understanding of the device sleep power mode is that it should be
used only if the host itself (sleeps or) hibernates or powers off. Device
sleep power mode should not be used while the host system is active, even if
there is no optical device activity, because user interaction with the device
would not work in sleep power mode (such as opening / closing the tray,
inserting & detection a new media). Instead, standby power mode needs to be
used when the host is active but the device is waiting.
Chipset manufacturer measured however that there is a non-negligible power
consumption saving by entering sleep mode in comparison to standby mode.
Could the device manufacturers on the reflector help clarify the source of
the power consumption in standby mode. What could we do to avoid this power
consumption but still preserve the user experience of opening/closing door
and detecting inserted media?
With regards,
David Burg.