Messages in this thread | | | Date | Sat, 06 Jan 2001 12:08:20 -0500 | From | Bryan Mayland <> | Subject | Re: [PATCH] VESA framebuffer w/MTRR locks 2.4.0 on init |
| |
David Wragg wrote:
> Something like this would be better: > if (mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB, 1) == -EINVAL) { > /* Find the largest power-of-two */ > while (temp_size & (temp_size - 1)) > temp_sze &= (temp_size - 1); > mtrr_add(video_base, temp_size, MTRR_TYPE_WRCOMB, 1); > } > (But this is just a very crude way to work around the inflexibility of > the MTRRs. Rather than cluttering up calls to mtrr_add, it would be > better to fix this properly
I agree. VesaFB is the only code (as far as I know) which attempts to grab an MTRR more than once. The restrictions on MTRR size and alignment are too numerous to attempt a logical resizing in a small amount of code-- especially since the retrictions are different depending on the processor. Might I suggest that the looping code be taken out entirely, perhaps outputting success or failure like: #ifdef CONFIG_MTRR if (mtrr) if (mtrr_add(video_base, video_size, MTRR_TYPE_WRCOMB, 1) == -EINVAL) printk(KERN_INFO "vesafb: Could not allocate MTRR\n"); else printk(KERN_INFO "vesafb: MTRR Write-Combining enabled\n"); #endif /* CONFIG_MTRR */
Bry
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |