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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.