On Wed, 26 May 2010 15:50:28 +0200 Anatolij Gustschin <agust@xxxxxxx> wrote: > On Wed, 26 May 2010 20:13:16 +0900 > Ben Dooks <ben@xxxxxxxxxxxx> wrote: > > > On 26/05/10 18:57, Anatolij Gustschin wrote: > > > Add driver specific mmap function to be able to mmap > > > frame buffer on PPC440SPe/PPC440EPx platforms. This > > > is needed because mmaping of the 36-bit physical > > > address of the frame buffer or MMIO is not supported > > > in generic fb_mmap(). > > > > Surely this is something we should be fixing in the > > main fb layer? > > We need to store phys addresses > 32-bit somewhere. Changing > smem_start and mmio_start of the struct fb_fix_screeninfo to > unsigned long long would break user space compatibility. gaaah, that was a big screwup. What are we doing passing these addresses to and from userspace? > How about adding smem_start_high and mmio_start_high to the > struct fb_fix_screeninfo for the purpose of storing upper > address bits? Bit ugly. fb_fix_screeninfo32 is presently treated as "thing for communicating with userspace" as well as "thing for kernel runtime use". We could separate these functions, and treat fb_fix_screeninfo32 as purely a userspace communication format. Copy the fields in and out when we talk to userspace. Obviously the simpler implementation would be to create a new fb_fix_screeninfo32_user. And change the fb_fix_screeninfo32 fields to dma_addr_t or whatever. What a pita. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
