Re: [RFC 3/4] libata: Remove excess command issue delays

[Alan Cox]

>    Wouldn't it make sense then to handle the "insane" hardware as an 
> exception, not vice versa?

It depends if you want to "fail safe". I'd personally just remove the
pause. We know from over ten years of drivers/ide that it's totally
unneccessary for almost any controller but I am submitting patches based
upon what Jeff seems ot want...

> > As a side effect it also means that those devices using PIO don't end up
> > generating ATA bus cycles in strange places which confuses some hardware.
> >   
> 
>    I thought that's mostly a problem with DMA commands...
> 
> > Saves us about 1mS on a dumb controller,
> 
>    1 ms per command?! Or per what?

per command. I've been using a plain and simple PCMCIA controller to make
the profiles nice and clear - the sff_pause does a read which crosses to
the device and back - that is slow. On some of the SFF style SATA
controllers its very fast so is presumably all cached as you'd expect.

Next time someone claims libata command issue is slower because of the
SCSI layer they should take a second look 8)

> > +	.sff_exec_command	= ata_sff_exec_command_nopost,
> > +	.sff_data_xfer	= 	winbond_data_xfer,
> > +	.cable_detect	= 	ata_cable_40wire,
> > +	.set_piomode	= 	winbond_set_piomode,
> >   
> 
>    What's up with the alignment here, why it's different from the rest 
> of drivers?
>
Just didn't fix up the formatting of that one when I was doing them all.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/