Re: [PATCH v9 06/10] ata: zpodd: check zero power ready status

[Aaron Lu <aaron.lu@intel.com>]

On 11/26/2012 01:03 PM, James Bottomley wrote:
> On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
>> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
>>>> I really think we need a way for (auto)pm and event polling to talk to
>>>> each other so that autopm can tell event poll to sod off while pm is
>>>> in effect.  Trying to solve this from inside libata doesn't seem
>>>> right.  The problem, again, seems to be figuring out which hardware
>>>> device maps to which block device.  Hmmm... Any good ideas?
>>>
>>> I've asked the PM people several times about this, because it's a real
>>> problem for almost everything:  PM needs some type of top to bottom
>>> stack view, which the layering isolation we have within storage really
>>> doesn't cope with well.  No real suggestion has been forthcoming.
>>
>> Actually, I think that the particular case in question is really special
>> and the fact that there's the pollig loop that user space is involved in
>> doesn't make things more stratightforward.
>>
>> And PM really doesn't need to see things top to bottom, but the polling
>> needs to know what happens in the PM land.  We need to be able to tell it
>> "from now on tell user space that there are no events here".  The question
>> is where to put that information so that it's accessible to all parts of the
>> stack involved.
> 
> Right, open to suggestions ...
> 
>>> The reason I think it should be emulated (in the acpi layer, not libata,
>>> but as long as it's not in SCSI, I'm not so fussed where it ends up) is
>>> because ZPODD is the software equivalent of ZPREADY, which will be done
>>> in hardware and will be effectively invisible to autopm in the same way
>>> that SCSI (and ATA) power management is mostly invisible.  If we
>>> currently do ZPREADY emulation in the low layer (i.e. ZPODD has exact
>>> ZPREADY emulation), we won't care (except for flipping the sofware bit)
>>> whether the device support ZPODD or ZPREADY and it will all just
>>> work(tm).  The industry expectation is that ZPODD is just a transition
>>> state between current power management and ZPREADY.
>>
>> Well, if you poll a ZPREADY-capable drive, it will go off and on in cycles
>> transparently, but still it won't save as much energy as it can.  We'll need
>> to do something about the polling in that case too, it seems.
> 
> No: with ZPREADY, the device effectively lies to the poll.  The Spec
> says that when it powers off the mechanical pieces, it must reply from
> firmware to a certain preset emulations of SCSI commands and not wake
> from power off.  These commands include TEST UNIT READY and a few
> others, so the device will happily reply to polls while being off (it
> replies with the original state before power was lost).  When you issue
> actual medium access commands, or manually insert or remove media it
> will wake up.
> 
> That's why I think ZPODD should emulate this behaviour.

I suppose you are refering to section 15.3.5?

I don't think the SPEC says what the host software _must_ do, it's
informative. And I agree that when possible, we should emulate the
command without powering up the ODD, but if we can eliminate the noise,
wouldn't that be better?

-Aaron

> 
> James
> 
>