Messages in this thread | | | Date | Sun, 23 Apr 2006 13:58:41 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: sata suspend resume ... |
| |
Thanks for taking a look, and replying in such detail, Jeff (I'm afraid you overestimate my understanding of this area!)
On Fri, 21 Apr 2006, Jeff Garzik wrote: > This is helpful to narrow down the problem, but its a bit of a layering > violation. In the current code, all functions called by > ata_device_{suspend,resume}() are high level functions, which uses > ata_qc_issue/ata_qc_complete high level API to address the device.
Ah, that's a pity. I see what you mean.
> In contrast, ata_busy_sleep() sticks its hands deep into the host state > machine, and gives the tree a good hard shake. :)
Though that seems a considerable overstatement: ata_busy_sleep doesn't shake anything, it just hangs around reading and testing a flag (in a bewildering series of slightly different loops). I guess even reading status must be viewed as "a good hard shake" at this upper level.
> Consider that > ata_busy_sleep() doesn't make sense for unusual cases like ATA-over-ethernet > (AoE), or other tunnelled ATA transports. > > It may very well be that ata_busy_sleep() is the proper solution for your > hardware, but it isn't applicable to all hardware.
Can it do harm on any hardware to wait for ATA_BUSY to clear there? Would it be less of a violation to do it in ata_scsi_device_resume? Or should ata_piix.c have its own .resume to add this in? Or....
> So you really want an ata_make_sure_bus_is_awake_and_working() called at that > location. ata_busy_sleep()'s purpose is to bring a PATA-like bus to the > bus-idle state. So, when working on suspend/resume, the software needs to > have points at which the bus state is controlled/queried/asserted.
As you can see from my questions, I haven't a clue around here. So for now I'll just have to keep that ata_busy_sleep with the patches I apply to my kernel, until someone with a clue makes it redundant. And it is now there in the LKML archives for those who find it useful.
Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |