From: Aaron Lu <aaron.lu@intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Tejun Heo <tj@kernel.org>,
Jeff Garzik <jgarzik@pobox.com>,
Alan Stern <stern@rowland.harvard.edu>, Jeff Wu <jeff.wu@amd.com>,
Aaron Lu <aaron.lwe@gmail.com>,
linux-ide@vger.kernel.org, linux-pm@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status
Date: Tue, 27 Nov 2012 09:41:40 +0800 [thread overview]
Message-ID: <50B41A54.8020905@intel.com> (raw)
In-Reply-To: <1353935850.2523.52.camel@dabdike>
On 11/26/2012 09:17 PM, James Bottomley wrote:
> On Mon, 2012-11-26 at 16:27 +0800, Aaron Lu wrote:
>> Well, ZPREADY is not a power state that we can program the ODD to
>> enter(figure 234 and table 323 of the SPEC), it servers more like an
>> information provided by ODD to host so that host does not need to do TUR
>> and then examine the sense code to decide if zero power ready status is
>> satisfied but simply query ODD if its current power state is ZPREADY.
>> So it's not that we program the device to go into ZPREADY power state
>> and the ODD's power will be omitted.
>>
>> The benefit of a ZPREADY capable ODD is that, when we need to decide if
>> the ODD is in a zero power ready status, we can simply query the ODD by
>> issuing a GET_EVENT_STATUS_NOTIFICATION and check the returned power
>> class events, if it is in ZPREADY power state, then we can omit the
>> power. To support ZPREADY, we just need some change to the zpready
>> funtion, which currently uses sense code to check ZP ready status.
>>
>> So this is my understanding of ZPREADY, and I don't see it as a total
>> different thing with ZPODD, it just changes the way how host senses the
>> zero power ready status. But if I was wrong, please kindly let me know,
>> thanks.
>
> My understanding is that a ZPREADY device may be capable of internal
> power down, meaning it doesn't necessarily need the host to omit the
> power. It depends what the difference is between Sleep and Off is
> (they're deliberately left as implementation defined in the standard, Ch
> 16, but the conditions of sleep are pretty onerous, so it sounds like
> most of the mechanics are powered down).
I Agree that when the ODD is put to Sleep state, it may power down most
of the mechanics, good for power saving. The problem is, we have the 2
seconds poll, and since Sleep state can not process any command, we will
need to bring the ODD out of Sleep state every 2 seconds, is this
feasible? Please note that leaving Sleep state needs full initialization
of the ODD.
ZPODD system(ODD+platform) solves this problem with ACPI, when the ODD
is powered off and any event that may induce a media change event will
generate an ACPI interrupt, so we can stop the poll(though in whatever
way is still in discussion).
So I suppose we need to find a proper way to implement Sleep.
>
> However, if you want to work it similarly to ZPODD, then the timeouts
> automatically transitions to ZPREADY, the device issues an event, we
> trap the event at the low level and omit power.
Yeah, I can do this. Except that I don't quite understand how the device
issues the event to host, by interrupt? My understanding is that, it
will issue this event to itself...and host still needs to use command
GET_EVENT_STATUS_NOTIFICATION to fetch the event, much the same way like
the media related events it emits.
>
> I'm also curious about driving sleep from autopm, since mode page timers
> don't control the sleep transition.
I see. But we will need to work out a sensible way to put the ODD into
that power state, if at all possible.
Thanks,
Aaron
next prev parent reply other threads:[~2012-11-27 1:41 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-09 6:51 [PATCH v9 00/10] ZPODD Patches Aaron Lu
2012-11-09 6:51 ` [PATCH v9 01/10] scsi: sr: support runtime pm Aaron Lu
2012-11-09 6:51 ` [PATCH v9 02/10] ata: zpodd: Add CONFIG_SATA_ZPODD Aaron Lu
2012-11-09 6:51 ` [PATCH v9 03/10] ata: zpodd: identify and init ZPODD devices Aaron Lu
2012-11-12 18:53 ` Tejun Heo
2012-11-14 1:32 ` Aaron Lu
2012-11-18 14:38 ` Tejun Heo
2012-11-19 2:15 ` Aaron Lu
2012-11-09 6:51 ` [PATCH v9 04/10] libata: acpi: move acpi notification code to zpodd Aaron Lu
2012-11-12 18:55 ` Tejun Heo
2012-11-14 1:36 ` Aaron Lu
2012-11-09 6:51 ` [PATCH v9 05/10] libata: separate ATAPI code Aaron Lu
2012-11-12 18:57 ` Tejun Heo
2012-11-13 12:49 ` Aaron Lu
2012-11-18 15:01 ` Tejun Heo
2012-11-19 2:21 ` Aaron Lu
2012-11-19 14:51 ` Tejun Heo
2012-11-09 6:51 ` [PATCH v9 06/10] ata: zpodd: check zero power ready status Aaron Lu
2012-11-12 19:13 ` Tejun Heo
2012-11-13 13:20 ` Aaron Lu
2012-11-14 2:18 ` Aaron Lu
2012-11-18 15:00 ` Tejun Heo
2012-11-19 3:09 ` Aaron Lu
2012-11-19 14:56 ` Tejun Heo
2012-11-19 15:06 ` James Bottomley
2012-11-26 0:33 ` Rafael J. Wysocki
2012-11-26 0:45 ` Aaron Lu
2012-11-26 5:03 ` James Bottomley
2012-11-26 5:09 ` Aaron Lu
2012-11-26 7:32 ` James Bottomley
2012-11-26 8:27 ` Aaron Lu
2012-11-26 13:17 ` James Bottomley
2012-11-26 16:21 ` Alan Stern
2012-11-26 19:15 ` James Bottomley
2012-11-27 1:41 ` Aaron Lu [this message]
2012-11-28 0:51 ` Rafael J. Wysocki
2012-11-28 1:39 ` Tejun Heo
2012-11-28 2:24 ` Aaron Lu
2012-11-28 8:56 ` James Bottomley
2012-12-03 8:13 ` Aaron Lu
2012-12-03 8:25 ` James Bottomley
2012-12-03 8:59 ` Aaron Lu
2012-12-03 16:23 ` Tejun Heo
2012-12-03 18:56 ` Jeff Garzik
2012-12-04 5:04 ` Aaron Lu
2012-12-04 12:11 ` James Bottomley
2012-12-07 6:13 ` Aaron Lu
2012-12-10 3:26 ` Aaron Lu
2012-12-11 5:10 ` Tejun Heo
2012-12-18 8:30 ` Aaron Lu
2012-12-20 6:07 ` Aaron Lu
2012-12-25 17:17 ` Tejun Heo
2012-12-26 1:42 ` Aaron Lu
2012-12-28 21:16 ` Tejun Heo
2013-01-04 1:04 ` Aaron Lu
2012-11-30 8:55 ` Aaron Lu
2012-11-30 11:15 ` Rafael J. Wysocki
2012-11-20 6:00 ` Aaron Lu
2012-11-20 8:59 ` Aaron Lu
2012-11-26 0:50 ` Rafael J. Wysocki
2012-11-26 0:48 ` Aaron Lu
2012-11-26 1:03 ` Rafael J. Wysocki
2012-11-26 1:05 ` Aaron Lu
2012-11-26 1:11 ` Rafael J. Wysocki
2012-11-26 1:09 ` Aaron Lu
2012-11-26 1:22 ` Rafael J. Wysocki
2012-11-26 1:22 ` Aaron Lu
2012-11-26 1:17 ` Aaron Lu
2012-11-09 6:51 ` [PATCH v9 07/10] block: add a new interface to block events Aaron Lu
2012-11-12 19:14 ` Tejun Heo
2012-11-12 19:18 ` Alan Stern
2012-11-12 19:21 ` Tejun Heo
2012-11-12 19:34 ` Alan Stern
2012-11-18 15:05 ` Tejun Heo
2012-11-18 17:41 ` Alan Stern
2012-11-18 21:56 ` Tejun Heo
2012-11-18 21:58 ` Tejun Heo
2012-11-18 23:28 ` Alan Stern
2012-11-18 23:35 ` Tejun Heo
2012-11-19 2:07 ` Alan Stern
2012-11-19 3:21 ` Aaron Lu
2012-11-19 14:50 ` Tejun Heo
2012-11-09 6:52 ` [PATCH v9 08/10] scsi: sr: support (un)block events Aaron Lu
2012-11-09 6:52 ` [PATCH v9 09/10] ata: zpodd: handle power transition of ODD Aaron Lu
2012-11-09 6:52 ` [PATCH v9 10/10] ata: expose pm qos flags to user space for ata device Aaron Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50B41A54.8020905@intel.com \
--to=aaron.lu@intel.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=aaron.lwe@gmail.com \
--cc=jeff.wu@amd.com \
--cc=jgarzik@pobox.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).