Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

[Arjan van de Ven]

> Have we done that? Yes. We actually had a "no-hlt" kernel command line 
> flag that literally disabled halting the CPU, because it apparently caused 
> problems for some floppy disk setups (and yes, the main reasonable 
> explanation was some bad DMA interaction, we never figured it out).
> 
> So it might be much better if we instead re-introduced that kind of "DMA 
> latency requirement", and letting different subsystems react to that as 
> they may.


wait.... we HAVE that infrastructure .. see kernel/latency.c ...


> It really can affect more than just cpufreq - I would not be in the 
> *least* surprised if C3 latencies and other things can cause these things 
> too! But even within cpufreq, it's quite likely to hit certain situations 
> more than others.

and kernel/latency.c was designed EXACTLY for that reason. All the USB
layer has to do is to announce it's latency requirement like this:

/* 
 * Some broadcom chips are buggy and can't take more than 5 usec as DMA
 * latency; inform the rest of kernel of this.
 */
if (weird_broadcom_chip())
	set_acceptable_latency("ehci", 5);


and the C-state code will honor it. CPUFREQ doesn't honor it yet but
that's easy to add.. (this assumes the ACPI BIOS informs us correctly
about the cpu behavior, but that's the best we can do obviously unless
you want a table inside the kernel keyed off vendor/model/stepping)




-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

-
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/