[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: More shark X news

>So I guess I'll have to learn more about those pagetabel entries. On the
>shark, the main memory is devided in blocks a 8 MB, the first at 0x0800.0000.
>The framebuffer is below that at 0600.0000, I mapped it at 0xd000.0000 for
>now. Can anybody tell me exactly, what remap_pte_range does and what that
>MAP_NR is? Will I have to map the framebuffer somewhere specific to make it
>work? If I must catch the framebuffer _and_ the main memory with
>phys_to_virt, I probably have to make it a function, how much would this
>hurt performance?

The phys_to_virt function is only supposed to work on "real" memory, not the 
framebuffer (except on machines where the framebuffer is drawn from system 
RAM).  Making this a function is not the end of the world - I'm surprised you 
don't already have to do that to cope with your fragmented RAM, actually.

MAP_NR() converts a virtual address into a page number.  It might be more 
intuitive to think of it as

#define MAP_NR(a)	(__pa(a) / PAGE_SIZE)

Again, this is only supposed to work on main memory, not I/O areas.

As to remap_pte_range, I think you will have to be a bit more specific with 
your question.

The address at which the framebuffer is mapped should be pretty much 
irrelevant.  X will create its own mapping anyway (by opening /dev/fb0 
and using mmap) so all you need is the correct physical address in the 
fb var structure.  The virtual mapping of the framebuffer is only used by the 
text console, I think.


Reply to: