On Fri, Dec 21, 2012 at 9:30 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > Hi Steve, > > On Wednesday 21 November 2012 16:08:06 Steve Sakoman wrote: >> On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra >> >> <eballetbo@xxxxxxxxx> wrote: >> > I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to >> > tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi -> tfp410) >> > changes the panel driver used on some boards. I tested current >> > linux-next-20101011 kernel with my IGEPv2 board and DSS fails with >> > >> > following error (see http://pastebin.com/VjPGCQDt for full log) : >> > [ 21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0 >> > [ 21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0 >> > [ 21.236236] omapfb omapfb: setup_plane failed >> >> Was there ever any resolution to this issue? > > Does mainline commit 950e2fb420d54bf0ee0de2fb0f146827a98330bf help ? > Hi Laurent, I just tried today's mainline kernel which has: 950e2fb [media] omap_vout: use omapdss's version instead of cpu_is_* but I still see the log message "omapdss OVERLAY error: check_overlay: paddr cannot be 0" (full log: http://fpaste.org/jOBo/) This doesn't affect the video display though since the framebuffer video is working correctly. Setting CONFIG_FB_OMAP2_NUM_FBS=1 in my .config makes the error message disappear since the paddr is correctly set for the first overlay: [ 3.175842] OMAPFB: allocated VRAM paddr 9e900000, vaddr de900000 [ 3.182891] OMAPFB: paddr 9e900000 Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html