> Gerd Knorr wrote:
> >
> > > The kernel also needs {check,request,release}_mmio for MMIO regions,
> > > just like {check,request,release} region, so that the vesafb driver
> > > won't start writing to a framebuffer already mapped by a driver before
> > > it.
> >
> > [ ... ]
> >
> > > It may be possible to have hardware acceleration in X, if vesafb
> > > correctly specifies the MMIO region.
> >
> > vesafb doesn't know where the mmio regions are, it only knows where the
> > framebuffer memory starts. You will not get accelerated X with vesafb.
>
> Consider the recent S3-specific vesafb hacks.
No. The code I've seen is bad, at least the patches I've seen. The real
mode asm code should'nt switch to graphics mode unless it is really sure
vesafb can handle it. Otherwise you might end up with a non-working
console, which is'nt acceptable.
The S3 vesafb hacks are a nice way to bootstrap a real S3 driver, but
nothing more IMHO. I really don't like the idea to add hardware-specific
hooks to vesafb.
> > And _mmio would'nt work either...
>
> Would you mind elaborating on this? If I have a vesafb hacked to
> support S3 and mmio as above, and a custom S3 driver, wouldn't
> {check,request,release}_mmio, along with the existing
> {check,request,release}_region, help make sure that those two drivers
> don't collide?
If vesafb scans the PCI space for the board which holds the framebuffer
address it has, it can figure out the correct PCI card without much
trouble. But figure out which of the memory regions the mmio area is is
impossible without hardware-specific code (which I don't want to see in
vesafb). For locking this might not be needed, you can simply lock down
all memory regions you'll find. But I'd use some pci device locking
instead of adding {check,request,release}_mmio.
Gerd
--
system("logout");
-
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/