[lkml]   [2001]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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:
if (mtrr)
if (mtrr_add(video_base, video_size, MTRR_TYPE_WRCOMB, 1) == -EINVAL)
printk(KERN_INFO "vesafb: Could not allocate MTRR\n");
printk(KERN_INFO "vesafb: MTRR Write-Combining enabled\n");
#endif /* CONFIG_MTRR */


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:0.101 / U:8.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site