Re: sata suspend resume ...

Re: sata suspend resume ...

[Jeff Garzik]

Hugh Dickins wrote:
> --- 2.6.17-rc2/drivers/scsi/libata-core.c	2006-04-19 09:14:11.000000000 +0100
> +++ linux/drivers/scsi/libata-core.c	2006-04-21 20:55:48.000000000 +0100
> @@ -4288,6 +4288,7 @@ int ata_device_resume(struct ata_port *a
>  {
>  	if (ap->flags & ATA_FLAG_SUSPENDED) {
>  		ap->flags &= ~ATA_FLAG_SUSPENDED;
> +		ata_busy_sleep(ap, ATA_TMOUT_BOOT_QUICK, ATA_TMOUT_BOOT);
>  		ata_set_mode(ap);
>  	}


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.

In contrast, ata_busy_sleep() sticks its hands deep into the host state 
machine, and gives the tree a good hard shake.  :)  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.

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.

	Jeff

Re: sata suspend resume ...

[Hugh Dickins]

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

Re: sata suspend resume ...

[Hugh Dickins]

On Sun, 23 Apr 2006, Hugh Dickins wrote:
> On Fri, 21 Apr 2006, Jeff Garzik wrote:
> 
> > 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.

I'm glad to report that my ata_busy_sleep is already unnecessary in
2.6.17-rc2-mm1 (and probably in at least -rc1-mm3 before it): unlike in
2.6.17-rc3, T43p resumes reliably from RAM with unpatched libata-core.c.
Something has gone seriously right!  Thanks...

Hugh