Re: [PATCH v7 0/6] ZPODD patches

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 24, 2012 at 03:06:11PM +0200, Rafael J. Wysocki wrote:
> On Monday, September 24, 2012, Aaron Lu wrote:
> > On Fri, Sep 21, 2012 at 11:18:27PM +0200, Rafael J. Wysocki wrote:
> > > On Friday, September 21, 2012, Aaron Lu wrote:
> > > > On Thu, Sep 20, 2012 at 10:00:51PM +0200, Rafael J. Wysocki wrote:
> > > > > On Wednesday, September 19, 2012, Aaron Lu wrote:
> > > > > > Thanks Rafael, and if there is any question/problem,
> > > > > > please kindly let me know.
> > > > > 
> > > > > Well, unfortunately my initial review indicates that the patchset is not
> > > > > quite ready to go upstream yet.
> > > > > 
> > > > > I'll send comments in replies to the individual patches, but overall I can
> > > > > say that at this stage of development, when I look at the patches, it should
> > > > > be clear to me not only what is being changed, but _why_ it is being changed
> > > > > in the first place and, secondly, why it is being changed in this particular
> > > > > way.  It's far from that, though.
> > > > 
> > > > I'm adding zero power support for optical disk drive(ZPODD), which is
> > > > made possible with the newly defined device attention(DA) pin introduced
> > > > in SATA 3.1 spec.
> > > > 
> > > > The idea here is to use runtime pm to achieve this, so I basically did 2
> > > > things:
> > > > 1 Add runtime pm support for ODD;
> > > > 2 Add power off support for ODD after it is runtime suspended.
> > > > 
> > > > Patch 2 is runtime pm support for ODD, the reason it is done this way is
> > > > discussed here:
> > > > http://www.spinics.net/lists/linux-scsi/msg61551.html
> > > 
> > > Why isn't it explained in the patch changelog, then?  People should be able
> > > to learn why things are done the way they are done from git logs.
> > > 
> > > > The basic idea is, the ODD will be runtime suspended as long as there is
> > > > nobody using it, that is, no programs opening the block device.
> > > > 
> > > > The ODD will be polled periodically, so it will be runtime resumed
> > > > before checking if there is any events pending and suspended when done.
> > > 
> > > OK.  So what happens if we power off the drive via runtime PM.  Does it
> > > it really make sense to resumie it through polling in that case?
> > 
> > No, this is the reason I introduced the powered_off flag. If set, the
> > poll will simply return without touching the device.
> > 
> > I've tried to do a disk_block_events call on its suspend callback when
> > it is ready to be powered off, but there is a race that I don't know how
> > to solve:
> > pm_runtime_suspend			disk_events_workfn		
> >   scsi_dev_type_suspend			  sr_block_check_events
> >     sr_suspend				    cdrom_check_events
> >       disk_block_events		      	      cdrom_update_events
> >       (this call waits for all		        sr_check_events
> >       running events_checking function	          scsi_autopm_get_device
> >       to return)
> > 
> > Suppose sr_suspend runs first, and then sr_check_events comes in.
> > sr_suspend calls disk_block_events, which waits for sr_check_events,
> > while scsi_autopm_get_device wait for suspend callback to finish,
> > deadlock.
> 
> I need some more time to think about this, stay tuned.

Thanks.

> 
> > > > The only exception is, if we found a disc is just inserted, we will not
> > > > idle it immediately at the end of the poll, reason explained in another
> > > > mail.
> > > > 
> > > > This is the rational I wrote patch 2, and patch 1 is used by patch 2.
> > > > 
> > > > Patch 3 is adding power off support for ODD after it is runtime
> > > > suspended, the condition is specified in section 15:
> > > > ftp://ftp.seagate.com/sff/INF-8090.PDF
> > > > 
> > > > That is, for tray type ODD: no media inside and door closed; for slot
> > > > type ODD: no media inside.
> > > > 
> > > > The is the reason sr_suspend is written, for non-ZPODD capable devices,
> > > > it does nothing; for ZPODD devices, it will check the above condition to
> > > > see if it is ready to be powered off. The ready_to_power_off flag will be
> > > > used by ATA layer to decide if power can be removed.
> > > 
> > > Now, James says he doesn't like the way ready_to_power_off is used.  Sure
> > > enough, it is totally irrelevant to the majority of SCSI devices.  It actually
> > > is totally irrelevant to everything in the SCSI subsystem except for the sr
> > > driver and libata.  So I wonder if you have considered any alternative
> > > way to address the use case at hand?
> > > 
> > > > When in powered off state, if user presses the eject button or insert a
> > > > disc, an ACPI event will be generated and our acpi wake handler will
> > > > pm_runtime_resume the ODD. And if it is a tray type ODD, its tray should
> > > > be ejected(need_eject flag) after powered on. This is patch 3.
> > > 
> > > That sounds reasonable enough, but the role of the powered_off and
> > > need_eject flags could be explained a bit better.  In particular, it would
> > 
> > powered_off: set when the device is powered off, clear otherwise.
> 
> That's pretty clear, but I think this flag should be called no_polling
> or something like this, because that's what it means to the SCSI layer.

Agree.

> 
> > need_eject:
> > First consider how the device will be runtime resumed:
> > 1 Some program opens the block device;
> > 2 Events checking poll when it's not powered off yet;
> > 3 User presses the eject button or inserts a disc into the slot when the
> >   device is in powered off state.
> > And the need_eject flag is for case 3, when the device is in powered off
> > state and user presses the eject button, it will be powered on(through
> > acpi wake notification function) and runtime resumed. In its runtime
> > resume callback, its tray needs to be ejected since user just presses
> > the eject button. The whole process of ZPODD is opaque to the user,
> > he/she doesn't know the ODD lost power so the ODD has to behave exactly
> > like it doesn't lose power.
> 
> Do you think it can be useful for other types of devices, not necessarily
> handled through ACPI?

I can only say that it is useful for ZPODD, if ZPODD someday is used on
another platform that does not use ACPI, the need_eject flag should
still be needed.

As for other scsi devices, I'm not sure.

> 
> > Hi Oliver,
> > This flag is really to say the tray needs to be ejected after runtime
> > resumed, it's not that media change detected. It is possible that user
> > ejects the tray without putting any disc inside and simply close the
> > tray, which doesn't qualify a media change event. And if user does
> > put a disc in, the sr_check_events will find that and report the media
> > change event to user space. Agree?
> > 
> > > be nice to have explained why they have to be present in struct scsi_device,
> > > because they don't seem to be particularly useful for many SCSI devices
> > > that aren't CD drives (the need_eject one in particular).
> > 
> > With your suggestion of pm_platform_power_off_allowed, I suppose
> > powered_off can be eliminated similarly with something like
> > pm_platform_powered_off returning true or false(for ACPI platform,
> > return true when device is in D3 cold state).
> 
> I'm currently thinking that using PM QoS may be a better approach here.

Is it something like a "power_off_allowed" binary constraint?
Then both the sr driver and the user can change the value so that both
the ready_to_power_off and may_power_off is no longer needed.

> 
> > And for the need_eject flag, I don't know if there is a better place for
> > it. The acpi wake notification code resides in libata(where we need to
> > record that this resume is due to user presses the eject button and the
> > tray needs to be ejected after resumed), and the runtime resume callback
> > resides in scsi driver(where we actually eject the tray). Ideally, this
> > flag should sit in scsi_cd structure, but libata does not have access to
> > it.
> 
> Yes, that's the problem that James mentioned.

Right, not easy to find a home for need_eject...

Thanks,
Aaron

> 
> Thanks,
> Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux