lkml.org 
[lkml]   [1999]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: MTRR setting and framebuffer driver
David Wragg wrote:
>
> Jeff Garzik <jgarzik@pobox.com> writes:
> > Jamie Lokier wrote:
> > > If we can assume that unregistered physical address space is never
> > > accessed (whatever the bus), it's safe to have MTRRs covering that space
> > > redundantly.
> >
> > I don't think that assumption can be made until all the drivers use the
> > new resource code.
>
> Some of the fb drivers get out of the way when the X server wants to
> talk directly to the graphics hardware, correct? Then in general, that
> assumption doesn't hold even when all drivers register their address
> ranges.

There are two valid cases, no fbdev + X, or fbdev + XF86_FBDev (a
special X server). The third case, fbdev + non-XF86_FBDev server, often
works, but is just asking for trouble.


> But it might work if kernel drivers drop their MTRR allocations when
> the X server takes over.

If the kernel driver allocated MTRRs, it should communicate that to the
Xserver fbdev support module.

Under fbdev, the X server is simply one among any number of graphics
applications. The kernel cannot simply drop its MTRRs when the fbdev
device is opened by a user application. And writing special case code
in fbdev just for X is the wrong way to go, IMHO.

Jeff




--
Custom driver development | Never worry about theory as long
Open source programming | as the machinery does what it's
| supposed to do. -- R. A. Heinlein

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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