On Wed, Dec 19, 2012 at 9:33 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On 2012-12-18 15:45, Javier Martinez Canillas wrote: >> Hi, >> >> I've tested with the latest stable kernel (Linux 3.7.1) and the video >> output is working correctly with the same user-space components. >> The complete dmesg is here: http://fpaste.org/1Kv4/ >> >> Looking at the logs for both kernels I realized that there are two >> differences main between the working (3.7.1) and non-working >> (mainline) kernel (besides the versions of course): >> >> a) The number of framebuffers created (working 1, non working 3) >> b) The omapfb now uses dma_alloc_attrs to allocate memory instead of >> the now removed OMAP-specific omap_vram_alloc >> >> For a) I built mainline with CONFIG_FB_OMAP2_NUM_FBS=1 and that made >> the error about the overlay paddr being zero disappear (OVERLAY error: >> check_overlay: paddr cannot be 0) but still no video on the screen. > > Ok. I think the reason for that is that the paddr errors come from X > trying to setup the video overlays with paddr 0. The video overlays are > by default on fb1 and fb2, so they are not present if you set the > NUM_FBS to 1. > Yes, that's what I thought, I'll just use CONFIG_FB_OMAP2_NUM_FBS=1 then on my defconfig. >> Conversely I build 3.7.1 with CONFIG_FB_OMAP2_NUM_FBS=3 and even >> though I had the paddr can't be zero error, video is working >> correctly. So it seems that error shouldn't affect the video display. > > Hmm, so do you get any display with 3.8, before X is started, using > plain fb? For example, break the boot before X is started, and do > > cat /dev/urandom > /dev/fb0 > > Do you have an userspace image I could download to reproduce this? > >> For b) I tried to built mainline with CONFIG_CMA=y but it didn't work either. > > I don't think the vram change affects this, except if you see errors > about mem alloc. But yes, I think you should enable CMA with 3.8, > although allocation may work fine for smaller displays even without CMA. > > Tomi > > Hi Tomi, At the end it was a red herring. The problem was not in the kernel but in U-Boot that now only sets the OMAP mux pins of the peripherals that uses. So the DSS OMAP mux pins and the OMAP GPIO line that is used to power up the TFP410 chip has to now be set in the kernel. We will send a patch for the igep0020 board file to fix the issue. Thanks a lot for your help and sorry for the noise! 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
