lkml.org 
[lkml]   [1998]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Next round of console patches
On Tue, 1 Sep 1998, Vladimir Dergachev wrote:

> > >
> > > card, base_register, length
> >
> > OK, I now see what you're driving at. I haven't looked closely at the
> > FB code, but I had assume that mtrr_add() was called "safely"
> > (i.e. for framebuffer RAM only and not for MMIO registers). I guess
> > that's not the case?
> > So the PCI bus addresses that the FB code finds may well contain MMIO
> > registers?
> > What's the story with cards that would be safe to make the FB
> > write-combining? Do they only have their registers in a separate
> > region? I would have thought that this is generally how it's done with
> > PCI cards?
>
> A good portion of cards map their IO registers in the end of the memory
> aperture. Since the idea of fb is to use VESA call to create the aperture
> and then _dont use_ any registers at all (bc then we would have to know
> what is the specific card we are running) there is no way (apriori) to
> know where we have legal framebuffer space and where we have MMIO
> registers

You have to support multiple IO regions in the hardware drivers in
the kernel using the MMU. That is the only way you can handle cards that
map PCI IO spaces all the hell over the place. KGI can do this easily.
AFAIK, fbdev cannot do it at all - one linear I/O region is all you get.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed


-
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.altern.org/andrebalsa/doc/lkml-faq.html

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