> Someone who experiences such timeouts needs to figure out how much
> time it really can take before a command is accepted. Some time ago
> the timeout was increased by the factor of 10, and now the current
> timeout looks being insufficient. It might be a problem with the
> time of specific commands or specific chip revisions. Or some
> hardware is too clever and somehow optimizes those repeated read
> operations, so that they no longer take a fixed number of bus
> cycles.
Shouldn't a udelay(1) always take one microsecond, regardless of
hardware optimizations?
> In short, that patch isn't a real solution. If someone provides me
> with the information which commands times-out and how much time they
> really need, we could have a real solution.
How can I help? Instrument the code by hand with printk statements?
Or is there a better way?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/