Re: [PATCH] [RFC] libata: Don't busy-wait for PIO data-in command completion
Damien Le Moal <[email protected]> Tue, 21 Jul 2026 08:56:41 +0900
| Newsgroups | gmane.linux.kernel,gmane.linux.ide |
|---|---|
| Organization | Western Digital Research |
| Message-ID | <[email protected]> |
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 <[email protected]> Applied to for-7.3 with a modified commit title. Thanks! -- Damien Le Moal Western Digital Research