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.
p.
Reply to: