Re: [PATCH] VESA framebuffer w/MTRR locks 2.4.0 on init

[Bryan Mayland <bmayland@leoninedev.com>]

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/