Message ID | 1398342509-10243-14-git-send-email-peter.griffin@linaro.org |
---|---|
State | New |
Headers | show |
On 24/04/14 15:28, Peter Griffin wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The omap lcdc driver has an elaborate mmap_kern function > to map the frame buffer into kernel address space as > write-combined. This uses functions that are only available > on MMU-enabled builds. > > It does seem equivalent to ioremap_wc though, so we should > be able to just use that instead. > > This patch is build-tested only, it needs to be run on real > hardware before applying. I don't have omap1 boards, and I don't know anyone that has. I don't even know if the omap1 fb is working or not... Tony, any idea of omap1's fb? Are you able to test this? Tomi
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]: > On 24/04/14 15:28, Peter Griffin wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > The omap lcdc driver has an elaborate mmap_kern function > > to map the frame buffer into kernel address space as > > write-combined. This uses functions that are only available > > on MMU-enabled builds. > > > > It does seem equivalent to ioremap_wc though, so we should > > be able to just use that instead. > > > > This patch is build-tested only, it needs to be run on real > > hardware before applying. > > I don't have omap1 boards, and I don't know anyone that has. I don't > even know if the omap1 fb is working or not... > > Tony, any idea of omap1's fb? Are you able to test this? I have three omap1 boards in my rack that I use for my boot testing. Tried to enable framebuffer but so far no luck on any of them. So I'm not much of a help here. Looks like the patch should work though.. Aaro & Janusz, care to take a look at the patch in this thread? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]: > > I don't have omap1 boards, and I don't know anyone that has. I don't > > even know if the omap1 fb is working or not... OMAP1 fb is working very well. As a matter of fact, it's much more usable for me than fb on OMAP2/3 - apart from N900 (on which fb is working again with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb in mainline yet. :-( > > Tony, any idea of omap1's fb? Are you able to test this? > > I have three omap1 boards in my rack that I use for my boot > testing. Tried to enable framebuffer but so far no luck on > any of them. So I'm not much of a help here. Looks like the > patch should work though.. > > Aaro & Janusz, care to take a look at the patch in this > thread? I couldn't figure out how to enter this code path. Amstrad E3 & Nokia 770 will take the alloc_fbmem() path & exit, and based on quick look I could not see way to enter mmap_kern(). Is that dead code? A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Aaro Koskinen <aaro.koskinen@iki.fi> [140508 16:09]: > Hi, > > On Thu, May 08, 2014 at 02:53:38PM -0700, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 02:15]: > > > I don't have omap1 boards, and I don't know anyone that has. I don't > > > even know if the omap1 fb is working or not... > > OMAP1 fb is working very well. As a matter of fact, it's much more usable > for me than fb on OMAP2/3 - apart from N900 (on which fb is working again > with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb > in mainline yet. :-( I hear you.. What do you have in the .config for omap1? Would be nice to enable the framebuffer in omap1_defconfig? > > > Tony, any idea of omap1's fb? Are you able to test this? > > > > I have three omap1 boards in my rack that I use for my boot > > testing. Tried to enable framebuffer but so far no luck on > > any of them. So I'm not much of a help here. Looks like the > > patch should work though.. > > > > Aaro & Janusz, care to take a look at the patch in this > > thread? > > I couldn't figure out how to enter this code path. Amstrad E3 & Nokia > 770 will take the alloc_fbmem() path & exit, and based on quick look > I could not see way to enter mmap_kern(). Is that dead code? Could be. It may be something left from when we had code to keep the bootloader logo displayed while booting kernel. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, May 08, 2014 at 04:17:11PM -0700, Tony Lindgren wrote: > > OMAP1 fb is working very well. As a matter of fact, it's much more usable > > for me than fb on OMAP2/3 - apart from N900 (on which fb is working again > > with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb > > in mainline yet. :-( > > I hear you.. What do you have in the .config for omap1? > Would be nice to enable the framebuffer in omap1_defconfig? Looks like the needed stuff is enabled there. Unfortunately I cannot test the full omap1_defconfig because of size limitations. > > > > Tony, any idea of omap1's fb? Are you able to test this? > > > > > > I have three omap1 boards in my rack that I use for my boot > > > testing. Tried to enable framebuffer but so far no luck on > > > any of them. So I'm not much of a help here. Looks like the > > > patch should work though.. > > > > > > Aaro & Janusz, care to take a look at the patch in this > > > thread? > > > > I couldn't figure out how to enter this code path. Amstrad E3 & Nokia > > 770 will take the alloc_fbmem() path & exit, and based on quick look > > I could not see way to enter mmap_kern(). Is that dead code? > > Could be. It may be something left from when we had code to keep > the bootloader logo displayed while booting kernel. The support for early fbmem alloc was removed in 2011 (1e434f9318efc3dddc0c0b8d2071712668154c2b, OMAPFB: remove early mem alloc from old omapfb), so I think we can safely delete this code. I can prepare & test a patch for this. A. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Aaro Koskinen <aaro.koskinen@iki.fi> [140509 14:26]: > Hi, > > On Thu, May 08, 2014 at 04:17:11PM -0700, Tony Lindgren wrote: > > > OMAP1 fb is working very well. As a matter of fact, it's much more usable > > > for me than fb on OMAP2/3 - apart from N900 (on which fb is working again > > > with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb > > > in mainline yet. :-( > > > > I hear you.. What do you have in the .config for omap1? > > Would be nice to enable the framebuffer in omap1_defconfig? > > Looks like the needed stuff is enabled there. Unfortunately I cannot > test the full omap1_defconfig because of size limitations. OK maybe it's just a question of loading the backlight modules. > > > > > Tony, any idea of omap1's fb? Are you able to test this? > > > > > > > > I have three omap1 boards in my rack that I use for my boot > > > > testing. Tried to enable framebuffer but so far no luck on > > > > any of them. So I'm not much of a help here. Looks like the > > > > patch should work though.. > > > > > > > > Aaro & Janusz, care to take a look at the patch in this > > > > thread? > > > > > > I couldn't figure out how to enter this code path. Amstrad E3 & Nokia > > > 770 will take the alloc_fbmem() path & exit, and based on quick look > > > I could not see way to enter mmap_kern(). Is that dead code? > > > > Could be. It may be something left from when we had code to keep > > the bootloader logo displayed while booting kernel. > > The support for early fbmem alloc was removed in 2011 > (1e434f9318efc3dddc0c0b8d2071712668154c2b, OMAPFB: remove early mem > alloc from old omapfb), so I think we can safely delete this code. > I can prepare & test a patch for this. OK thanks that makes sense to me. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/video/fbdev/omap/lcdc.c b/drivers/video/fbdev/omap/lcdc.c index b52f625..40e8200 100644 --- a/drivers/video/fbdev/omap/lcdc.c +++ b/drivers/video/fbdev/omap/lcdc.c @@ -613,29 +613,11 @@ static void lcdc_dma_handler(u16 status, void *data) static int mmap_kern(void) { - struct vm_struct *kvma; - struct vm_area_struct vma; - pgprot_t pgprot; - unsigned long vaddr; - - kvma = get_vm_area(lcdc.vram_size, VM_IOREMAP); - if (kvma == NULL) { - dev_err(lcdc.fbdev->dev, "can't get kernel vm area\n"); + void __iomem *vaddr; + + vaddr = ioremap_wc(lcdc.vram_phys, lcdc.vram_size); + if (!vaddr) return -ENOMEM; - } - vma.vm_mm = &init_mm; - - vaddr = (unsigned long)kvma->addr; - vma.vm_start = vaddr; - vma.vm_end = vaddr + lcdc.vram_size; - - pgprot = pgprot_writecombine(pgprot_kernel); - if (io_remap_pfn_range(&vma, vaddr, - lcdc.vram_phys >> PAGE_SHIFT, - lcdc.vram_size, pgprot) < 0) { - dev_err(lcdc.fbdev->dev, "kernel mmap for FB memory failed\n"); - return -EAGAIN; - } lcdc.vram_virt = (void *)vaddr; @@ -644,7 +626,7 @@ static int mmap_kern(void) static void unmap_kern(void) { - vunmap(lcdc.vram_virt); + iounmap(lcdc.vram_virt); } static int alloc_palette_ram(void)