[Adding more people and list back in] On 09/29/2012 05:46 AM, Rafael J. Wysocki wrote: > On Friday, September 28, 2012, Aaron Lu wrote: >> On 09/28/2012 07:15 AM, Rafael J. Wysocki wrote: >>> On Thursday, September 27, 2012, Aaron Lu wrote: >>>> On 09/27/2012 05:37 AM, Rafael J. Wysocki wrote: >>>>> >>>>> Say the user has pressed the eject button. What does need to happen so >>>>> that >>>>> the tray is physically ejected? >>>> >>>> The tray is ejected by the ODD itself, host does not have to do anything. >>>> >>>> There is a command(PREVENT_MEDIUM_REMOVAL) to lock the door so that when >>>> user presses the eject button, the tray will not be ejected. This command >>>> is usually sent when we have a disc inside and a user space program >>>> opened the underlying block device(e.g. /dev/sr0) to read/write data. >>>> >>>> And host can also eject the tray by sending a START_STOP_UNIT command >>>> with param LoEj set to 1 and we have a function called sr_tray_move to >>>> do just this. And this is also what I've used to eject the tray after >>>> user wakes up the ODD, as when user presses the eject button when the >>>> ODD is in zero power state, it can't eject the tray as usual, so host >>>> software will need to do this, that's the reason I need to know such >>>> information: >>>> When ODD is resumed, is it because user wakes it up? >>> >>> But START_STOP_UNIT eventually causes ata_scsi_start_stop_xlat() to be >> >> You are following ata case, while the ODD is an atapi device :-) >> The translation function is atapi_xlat, but that doesn't affect the idea >> here. >> >>> executed, so I wonder if we really need to go up through the SCSI stack >>> to send that command to the drive from there? It should be possible >>> to issue STANDBY/READ VERIFY to the device directly from libata if >>> an eject event is signaled through a GPE. >> >> Yes, this is possible. >> Though it doesn't feel very cool, since I have no idea if the ODD is a >> tray type or slot type in ATA layer and I'll blindly send this command >> to it then, not a problem maybe. > > It would be good to verify if that works for slot devices, if possible.
The ACPI GPE event is triggered when user inserts a disc into a slot type ODD, and if I send an eject command to it, the disc will be ejected, which is wrong. I need to know the loading mechanism(tray type or slot type) of the ODD to decide if I should send this command. > >> And what do you think of moving the acpi notification code to sr? >> http://marc.info/?l=linux-pm&m=134873904332704&w=4 > > I don't think this is a good idea, quite frankly. sr seems to be a too > generic place for that. Does this mean sr can only have code that is useful to all devices it manages? i.e. If a piece of code enables a feature for a special kind of ODD(like the sata based ZPODD), it shouldn't be done in sr? > > Ideally, the whole ZPODD handling should not be visible to the SCSI layer, I can see 2 problems: - Don't know its loading machanism so we have the problem above; - Need to send command to find out if ODD is zero power ready somewhere in ata layer, this implies the device is doing IO after it is runtime suspended in scsi layer. > perhaps except the "no_polling" flag disabling the polling that may be > useful for other purposes in principle. I hope so, let's hear what other people has to say. > > I'm not sure if it's possible at this point, but if not we need to know > very precisely why not. There is nothing in theory stopping us from doing this in ata layer. For the loading mechanism, we can always send an ATAPI command to figure it out. So gentlemen, I need your opinions on where this ZPODD code should live before I can continue this work, thanks. -Aaron -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
