On Saturday, September 29, 2012, Aaron Lu wrote: > [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? If the feature is specific to one special kind of ODD only, then I don't think sr is the right place to add support for it. > > 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; Does using the need_eject flag address this problem somehow? > - 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. There's nothing wrong with accessig suspended devices as long as we know that they will respond. :-) > > 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. I would _try_ to add it at the ATA level. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
