Re: [PATCH] [RFC] libata: Don't busy-wait for PIO data-in command completion

[Damien Le Moal <dlemoal@kernel.org>]

On 7/17/26 18:04, Richard Weinberger wrote:
> libata: Don't busy-wait for PIO data-in command completion
> 
> Unlike PIO data-out, the PIO data-in protocol raises no completion
> interrupt, the last interrupt announces the final data block, and once
> the host has drained it from the data register the ending status must
> be obtained synchronously.  ata_sff_hsm_move() does this by spinning
> in ata_wait_idle() for up to 10ms.
> 
> Usually this is not a big deal unless the device is slow.  In my case
> it's a CF card which keeps BSY asserted for multiple milliseconds(!)
> after the final data block.  Since the waiting happens in the
> interrupt handler, under the port lock with interrupts disabled, the
> CPU is hogged for milliseconds on every read command.
> 
> To improve the situation, bound the inline wait to ~100us.  If the
> device is still busy after that, mark the command ATA_TFLAG_POLLING,
> so the interrupt handler won't race for it, and obtain the ending
> status via ata_sff_pio_task(), which sleeps between status checks
> instead of spinning with the lock held.
> 
> Since ata_sff_pio_task() may now finish a data-in command, it must
> wait for both BSY and DRQ to clear at HSM_ST_LAST, matching what
> ata_wait_idle() enforced.
> 
> Signed-off-by: Richard Weinberger <richard@nod.at>

Looks OK to me, but the patch title should be:

ata: libata-sff: Don't busy-wait for PIO data-in command completion

I can change that when applying if you want.

-- 
Damien Le Moal
Western Digital Research