Re: [PATCH] Configure IDE probe delays

[Tim Bird]

Alan Cox wrote:
> If you want to speed this up then the two bits that the initial proposal
> and Jeff have sensibly come up with are
>
> 1.	Are we doing too many probes

By way of commentary, it *is* possible to reduce the number of probes
using existing kernel command line options (hd<x>=noprobe and
ide<x>=noprobe)  This helps on systems where interfaces or devices
are known not to exist.  This is described in my OLS paper, and I
plan to put up a wiki page with instructions for interested parties,
real soon now... :-)

However, further reducing the number of probes is still a worthy goal.
We'll take a look at this when we get a chance.  Given some
of the feedback on this thread, this sounds like it might be prone
to worse breakage for legacy hardware than simply adjusting the delay
duration.

> 2.	Should we switch to proper reset polling
>
> For certain cases (PPC spin up) we actually have switched to doing drive
> spin up this way...

I'm not sure what this means.  Can someone tell me more about this
or point me to some code?  (Sorry for my ignorance, I'm not an IDE
expert by any means.)

BTW - Any comments on Todd's new patch? (see message with title
"IDE probe delay symbol")  This one doesn't make the value configurable,
but does use a #define (preserving the traditional 50 ms value).  This
at least removes a magic number, and it makes it easier to identify the
msleeps that have historically been related.

With this new patch, nothing changes for the legacy crowd, but it still
makes it easier for RACER_BOYs ;-) to dink with the value.

=============================
Tim Bird
Architecture Group Co-Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
E-mail: tim.bird@xxxxxxxxxxx
=============================
-
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/