Re: omap DSS fails with tft410 driver panel?
Try adding kernel bootargs, lets say: vram=48M omapfb.vram=0:16M,1:16M,2:16M And see what happens. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
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 eballe...@gmail.com 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 ? I am seeing the same errors on Overo. The video output actually works, but it appears that this error causes X to close and then restart repeatedly. I'll add the printk's to omapfb_setup_plane() that were requested by Tomi and report back. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On 2012-12-18 10:31, Javier Martinez Canillas wrote: Did you find a solution for this? Not that I know. Also I have this log about a locking dependency: [ 24.690795] [ 24.690826] == [ 24.690826] [ INFO: possible circular locking dependency detected ] [ 24.690826] 3.7.0-00017-g6c2ecfb-dirty #144 Not tainted [ 24.690826] --- I've also seen these. But they don't seem to happen with linux-next (or Linus' current tree). I haven't been able to figure out the reason for the warning, but as they seem to have disappeared, they may be related to something else than omapfb/omapdss. Tomi signature.asc Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
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. 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 signature.asc Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
On 2012-11-27 21:15, Steve Sakoman wrote: During my testing I think I uncovered another issue :-( I set omapdss.def_disp=lcd43 on the kernel command line to see if the behavior changed with the LCD as the default device. What I encountered was a null pointer crash: [3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R [3.488250] Unable to handle kernel NULL pointer dereference at virtual address 0028 [3.496765] pgd = c0004000 [3.499603] [0028] *pgd= [3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM [3.508605] Modules linked in: [3.511810] CPU: 0Not tainted (3.6.0 #1) [3.516357] PC is at dss_mgr_check_timings+0x4/0x30 [3.521484] LR is at dpi_check_timings+0x18/0xb8 [3.526336] pc : [c025df70]lr : [c0260dc0]psr: 4013 [3.526336] sp : dec2bd88 ip : fp : def7e180 [3.538330] r10: def951c0 r9 : def61000 r8 : de41b858 [3.543823] r7 : dec2bdfc r6 : c06c0a50 r5 : dec2be00 r4 : deea1cd4 [3.550659] r3 : dec1ba40 r2 : dec2bdc8 r1 : dec2be00 r0 : [3.557495] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [3.565155] Control: 10c5387d Table: 80004019 DAC: 0015 [3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0) [3.577270] Stack: (0xdec2bd88 to 0xdec2c000) [3.581848] bd80: dec1ba40 c0260dc0 deea1cd4 def7e180 c046a7d0 [3.590423] bda0: deea1cd4 c06c0a50 dec2be00 dec2bdfc [3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50 de41b800 c046749c [3.607513] bde0: 003d c0495788 0018 0010 def98640 dec00140 [3.616088] be00: 03000400 dac0 00300020 00040050 0003000f 0001 [3.624664] be20: 0001 c0459380 deea257c c06c0d00 dec2be50 [3.633209] be40: c025cc10 c029a98c c029ae80 dec075d8 de41b800 [3.641784] be60: c06c1200 c06c3098 c06c3090 de41b80c 0002 0001 de41b800 c0689470 [3.650360] be80: def99148 def99148 dec2beb8 c01371c4 dec1ba40 def99148 decdf208 [3.658935] bea0: def95240 c0137e24 c0054e18 0003 decdf208 [3.667510] bec0: c06e25dc c06c3098 c06e25dc c06e25dc c029c728 009e c068920c [3.676055] bee0: c029d830 c029d81c c029c514 c06e25dc c06c3098 c06c3098 c06c30cc [3.684631] bf00: c06e25dc c029c790 dec2bf18 c06e25dc c029aa9c dec077d8 decd9670 [3.693176] bf20: c06e25dc c06e25dc c06e8868 def95240 c029bb2c c05a9b18 c05a9b18 [3.701751] bf40: c06e25dc 0001 c06a0c9c c0710300 009e c029ccb4 c06e25c8 [3.710296] bf60: 0001 c06a0c9c c0710300 009e c068920c c029daa4 0007 c06967d8 [3.718872] bf80: c06a0c9c c0689234 dec2a000 c0008654 c068920c 976c0d2e c06a0cc4 0008 [3.727447] bfa0: 0007 c06967d8 c06a0c9c c0710300 009e c0669160 c06967e0 c06698d8 [3.735992] bfc0: 0007 0007 c0669160 0013 c06697a0 [3.744567] bfe0: c000eea8 0013 c000eea8 fff7 dffefffe [3.753143] [c025df70] (dss_mgr_check_timings+0x4/0x30) from [c0260dc0] (dpi_check_timings+0x18/0xb8) [3.763183] [c0260dc0] (dpi_check_timings+0x18/0xb8) from [c026e738] (tfp410_check_timings+0x28/0x3c) [3.773223] [c026e738] (tfp410_check_timings+0x28/0x3c) from [c046749c] (omapfb_parse_def_modes+0x338/0x3f4) [3.783905] [c046749c] (omapfb_parse_def_modes+0x338/0x3f4) from [c0689470] (omapfb_probe+0x210/0x600) [3.794036] [c0689470] (omapfb_probe+0x210/0x600) from [c029d830] (platform_drv_probe+0x14/0x18) [3.803619] [c029d830] (platform_drv_probe+0x14/0x18) from [c029c514] (driver_probe_device+0x11c/0x330) [3.813812] [c029c514] (driver_probe_device+0x11c/0x330) from [c029c790] (__driver_attach+0x68/0x8c) [3.823760] [c029c790] (__driver_attach+0x68/0x8c) from [c029aa9c] (bus_for_each_dev+0x48/0x80) [3.833251] [c029aa9c] (bus_for_each_dev+0x48/0x80) from [c029bb2c] (bus_add_driver+0xf0/0x248) [3.842742] [c029bb2c] (bus_add_driver+0xf0/0x248) from [c029ccb4] (driver_register+0x9c/0x12c) [3.852203] [c029ccb4] (driver_register+0x9c/0x12c) from [c029daa4] (platform_driver_probe+0x18/0x9c) [3.862243] [c029daa4] (platform_driver_probe+0x18/0x9c) from [c0689234] (omapfb_init+0x28/0x54) [3.871826] [c0689234] (omapfb_init+0x28/0x54) from [c0008654] (do_one_initcall+0x90/0x160) [3.880950] [c0008654] (do_one_initcall+0x90/0x160) from [c06698d8] (kernel_init+0x138/0x1f8) [3.890228] [c06698d8] (kernel_init+0x138/0x1f8) from [c000eea8] (kernel_thread_exit+0x0/0x8) [3.899566] Code: e3e00015 e8bd8010 c05d88aa e92d4008 (e5900028) [3.906097] ---[ end trace 38f657b10d460537 ]--- It seems that dss_mgr_check_timings is being called with a
Re: omap DSS fails with tft410 driver panel?
2012/11/29 Tomi Valkeinen tomi.valkei...@ti.com: On 2012-11-27 21:15, Steve Sakoman wrote: During my testing I think I uncovered another issue :-( I set omapdss.def_disp=lcd43 on the kernel command line to see if the behavior changed with the LCD as the default device. What I encountered was a null pointer crash: [3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R [3.488250] Unable to handle kernel NULL pointer dereference at virtual address 0028 [3.496765] pgd = c0004000 [3.499603] [0028] *pgd= [3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM [3.508605] Modules linked in: [3.511810] CPU: 0Not tainted (3.6.0 #1) [3.516357] PC is at dss_mgr_check_timings+0x4/0x30 [3.521484] LR is at dpi_check_timings+0x18/0xb8 [3.526336] pc : [c025df70]lr : [c0260dc0]psr: 4013 [3.526336] sp : dec2bd88 ip : fp : def7e180 [3.538330] r10: def951c0 r9 : def61000 r8 : de41b858 [3.543823] r7 : dec2bdfc r6 : c06c0a50 r5 : dec2be00 r4 : deea1cd4 [3.550659] r3 : dec1ba40 r2 : dec2bdc8 r1 : dec2be00 r0 : [3.557495] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [3.565155] Control: 10c5387d Table: 80004019 DAC: 0015 [3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0) [3.577270] Stack: (0xdec2bd88 to 0xdec2c000) [3.581848] bd80: dec1ba40 c0260dc0 deea1cd4 def7e180 c046a7d0 [3.590423] bda0: deea1cd4 c06c0a50 dec2be00 dec2bdfc [3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50 de41b800 c046749c [3.607513] bde0: 003d c0495788 0018 0010 def98640 dec00140 [3.616088] be00: 03000400 dac0 00300020 00040050 0003000f 0001 [3.624664] be20: 0001 c0459380 deea257c c06c0d00 dec2be50 [3.633209] be40: c025cc10 c029a98c c029ae80 dec075d8 de41b800 [3.641784] be60: c06c1200 c06c3098 c06c3090 de41b80c 0002 0001 de41b800 c0689470 [3.650360] be80: def99148 def99148 dec2beb8 c01371c4 dec1ba40 def99148 decdf208 [3.658935] bea0: def95240 c0137e24 c0054e18 0003 decdf208 [3.667510] bec0: c06e25dc c06c3098 c06e25dc c06e25dc c029c728 009e c068920c [3.676055] bee0: c029d830 c029d81c c029c514 c06e25dc c06c3098 c06c3098 c06c30cc [3.684631] bf00: c06e25dc c029c790 dec2bf18 c06e25dc c029aa9c dec077d8 decd9670 [3.693176] bf20: c06e25dc c06e25dc c06e8868 def95240 c029bb2c c05a9b18 c05a9b18 [3.701751] bf40: c06e25dc 0001 c06a0c9c c0710300 009e c029ccb4 c06e25c8 [3.710296] bf60: 0001 c06a0c9c c0710300 009e c068920c c029daa4 0007 c06967d8 [3.718872] bf80: c06a0c9c c0689234 dec2a000 c0008654 c068920c 976c0d2e c06a0cc4 0008 [3.727447] bfa0: 0007 c06967d8 c06a0c9c c0710300 009e c0669160 c06967e0 c06698d8 [3.735992] bfc0: 0007 0007 c0669160 0013 c06697a0 [3.744567] bfe0: c000eea8 0013 c000eea8 fff7 dffefffe [3.753143] [c025df70] (dss_mgr_check_timings+0x4/0x30) from [c0260dc0] (dpi_check_timings+0x18/0xb8) [3.763183] [c0260dc0] (dpi_check_timings+0x18/0xb8) from [c026e738] (tfp410_check_timings+0x28/0x3c) [3.773223] [c026e738] (tfp410_check_timings+0x28/0x3c) from [c046749c] (omapfb_parse_def_modes+0x338/0x3f4) [3.783905] [c046749c] (omapfb_parse_def_modes+0x338/0x3f4) from [c0689470] (omapfb_probe+0x210/0x600) [3.794036] [c0689470] (omapfb_probe+0x210/0x600) from [c029d830] (platform_drv_probe+0x14/0x18) [3.803619] [c029d830] (platform_drv_probe+0x14/0x18) from [c029c514] (driver_probe_device+0x11c/0x330) [3.813812] [c029c514] (driver_probe_device+0x11c/0x330) from [c029c790] (__driver_attach+0x68/0x8c) [3.823760] [c029c790] (__driver_attach+0x68/0x8c) from [c029aa9c] (bus_for_each_dev+0x48/0x80) [3.833251] [c029aa9c] (bus_for_each_dev+0x48/0x80) from [c029bb2c] (bus_add_driver+0xf0/0x248) [3.842742] [c029bb2c] (bus_add_driver+0xf0/0x248) from [c029ccb4] (driver_register+0x9c/0x12c) [3.852203] [c029ccb4] (driver_register+0x9c/0x12c) from [c029daa4] (platform_driver_probe+0x18/0x9c) [3.862243] [c029daa4] (platform_driver_probe+0x18/0x9c) from [c0689234] (omapfb_init+0x28/0x54) [3.871826] [c0689234] (omapfb_init+0x28/0x54) from [c0008654] (do_one_initcall+0x90/0x160) [3.880950] [c0008654] (do_one_initcall+0x90/0x160) from [c06698d8] (kernel_init+0x138/0x1f8) [3.890228] [c06698d8] (kernel_init+0x138/0x1f8) from [c000eea8] (kernel_thread_exit+0x0/0x8) [3.899566] Code: e3e00015 e8bd8010 c05d88aa e92d4008 (e5900028) [3.906097] ---[ end trace 38f657b10d460537 ]--- It seems
Re: omap DSS fails with tft410 driver panel?
On Thu, Nov 29, 2012 at 3:22 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2012-11-27 21:15, Steve Sakoman wrote: It seems that dss_mgr_check_timings is being called with a null dssdev-manager. Other than the fact that there should be a null pointer check in the code, it seems that this is a regression since it used to be possible to switch the default display in this fashion. Is this no longer allowed? It is allowed. Which kernel is that? I tried v3.7-rc4 and the current omapdss master, both work for me with overo + lcd43 add on. It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9) Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On Thu, Nov 29, 2012 at 3:33 AM, Enric Balletbo Serra eballe...@gmail.com wrote: Sorry for the delay, I also can't reproduce the issue, I think is related due I upgrated the X server to a newer version. I would recover my old rootfs to try to reproduce the issue... I am using xorg-server-1.11.2, which version have you switched to? Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
2012/11/29 Steve Sakoman sako...@gmail.com: On Thu, Nov 29, 2012 at 3:33 AM, Enric Balletbo Serra eballe...@gmail.com wrote: Sorry for the delay, I also can't reproduce the issue, I think is related due I upgrated the X server to a newer version. I would recover my old rootfs to try to reproduce the issue... I am using xorg-server-1.11.2, which version have you switched to? I'm using version 1.13.0, but now I'm not sure if I have solved the problem using this version or updating the kernel. I need to check. Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On 2012-11-29 16:18, Steve Sakoman wrote: On Thu, Nov 29, 2012 at 3:22 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 2012-11-27 21:15, Steve Sakoman wrote: It seems that dss_mgr_check_timings is being called with a null dssdev-manager. Other than the fact that there should be a null pointer check in the code, it seems that this is a regression since it used to be possible to switch the default display in this fashion. Is this no longer allowed? It is allowed. Which kernel is that? I tried v3.7-rc4 and the current omapdss master, both work for me with overo + lcd43 add on. It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9) Still can't reproduce. So does the null pointer deref happen at boot time? What display related kernel boot options do you have? This looks funny, considering lcd43 is a bit smaller lcd: [3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R Tomi signature.asc Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9) Still can't reproduce. So does the null pointer deref happen at boot time? What display related kernel boot options do you have? This looks funny, considering lcd43 is a bit smaller lcd: Yes, it happens at boot time. The boot options: [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=500 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapdss.def_disp=lcd43 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait My DSS config options: # # Frame buffer hardware drivers # # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_TMIO is not set # CONFIG_FB_SMSCUFX is not set # CONFIG_FB_UDL is not set # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_BROADSHEET is not set # CONFIG_FB_AUO_K190X is not set CONFIG_OMAP2_VRAM=y CONFIG_OMAP2_VRFB=y CONFIG_OMAP2_DSS=y CONFIG_OMAP2_VRAM_SIZE=12 CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y # CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set CONFIG_OMAP2_DSS_DPI=y # CONFIG_OMAP2_DSS_RFBI is not set CONFIG_OMAP2_DSS_VENC=y # CONFIG_OMAP2_DSS_SDI is not set CONFIG_OMAP2_DSS_DSI=y CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 CONFIG_OMAP2_DSS_SLEEP_AFTER_VENC_RESET=y CONFIG_FB_OMAP2=y CONFIG_FB_OMAP2_DEBUG_SUPPORT=y CONFIG_FB_OMAP2_NUM_FBS=3 # # OMAP2/3 Display Device Drivers # CONFIG_PANEL_GENERIC_DPI=y CONFIG_PANEL_TFP410=y CONFIG_PANEL_LGPHILIPS_LB035Q02=y CONFIG_PANEL_SHARP_LS037V7DW01=y # CONFIG_PANEL_NEC_NL8048HL11_01B is not set # CONFIG_PANEL_PICODLP is not set # CONFIG_PANEL_TAAL is not set # CONFIG_PANEL_TPO_TD043MTEA1 is not set # CONFIG_EXYNOS_VIDEO is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m # CONFIG_LCD_L4F00242T03 is not set # CONFIG_LCD_LMS283GF05 is not set # CONFIG_LCD_LTV350QV is not set # CONFIG_LCD_TDO24M is not set # CONFIG_LCD_VGG2432A4 is not set # CONFIG_LCD_PLATFORM is not set # CONFIG_LCD_S6E63M0 is not set # CONFIG_LCD_LD9040 is not set # CONFIG_LCD_AMS369FG06 is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_GENERIC=m # CONFIG_BACKLIGHT_ADP8860 is not set # CONFIG_BACKLIGHT_ADP8870 is not set # CONFIG_BACKLIGHT_LP855X is not set # CONFIG_BACKLIGHT_PANDORA is not set Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On 2012-11-29 16:53, Steve Sakoman wrote: On Thu, Nov 29, 2012 at 6:31 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: It is stock Linux 3.6 (i.e. commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9) Still can't reproduce. So does the null pointer deref happen at boot time? What display related kernel boot options do you have? This looks funny, considering lcd43 is a bit smaller lcd: Yes, it happens at boot time. The boot options: [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=500 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapdss.def_disp=lcd43 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Ok, now I see it. It happens because DVI is not configured to be used, but you have DVI video mode specified in the command line. I'll study this further and make a fix. Tomi signature.asc Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
On 2012-11-23 17:20, Steve Sakoman wrote:
On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
put a printk at dss/apply.c:dss_olv_set_info, and print ovl-id and
info-paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
the point where it sets info.paddr, as I think that's the only place
where omapfb sets paddr.
OK, did that and here is what I get when starting up gdm, prior to
that all is normal
root@omap3-multi:~# systemctl start gdm.service
Starting Gnome Display Manager...
Started Gnome Display Manager [ OK
]
root@omap3-multi:~# [ 83.475128] omapfb_setup_plane entry
[ 83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
[ 83.485809] omapfb_setup_overlay: setting info.paddr = 9f40
[ 83.492431] dss_ovl_set_info entry
[ 83.496307] ovl-id = 0
[ 83.499267] info-paddr = 9f40
[ 83.503601] omapfb_setup_plane: return success
[ 83.508697] omapfb_setup_plane entry
[ 83.513153] dss_ovl_set_info entry
[ 83.516723] ovl-id = 2
[ 83.520111] info-paddr = 0
[ 83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0
[ 83.530426] omapfb_setup_plane: !pi-enabled ovl-set_overlay_info
[ 83.537414] dss_ovl_set_info entry
[ 83.540985] ovl-id = 2
[ 83.544250] info-paddr = 0
[ 83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0
repeats as X dies and restarts
I don't know what's going on there, why the paddr is suddenly zero.
Looking at the log from Enric, SETUP_PLANE works fine just fine, and
then, for no reason, next SETUP_PLANE fails, and the log doesn't show
anything much happening between.
However, I think omapdss may have been more permissive in the past,
allowing paddr 0 if the overlay is disabled. I could add that back, but
I'd rather first understand what's happening here.
From the above it seems that the first SETUP_PLANE is for ovl-id = 0
and then those that fail are for ovl-id =2.
No idea what is going on in user space, but maybe this will mean
something to you :-)
Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?
Anyway, I guess it's a valid thing to configure the overlay with
paddr == 0 when the overlay is disabled. In fact, paddr == 0 check
is in any case quite limited, as if the board's physical memory
doesn't contain the given paddr, the DSS HW will fail just as it
would for paddr 0. So the paddr == 0 check is more of a sanity check
than a comprehensive test.
Can you try the following patch:
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 45f4994..e271e28 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev)
int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info)
{
- if (info-paddr == 0) {
- DSSERR(check_overlay: paddr cannot be 0\n);
- return -EINVAL;
- }
-
if ((ovl-caps OMAP_DSS_OVL_CAP_SCALE) == 0) {
if (info-out_width != 0 info-width != info-out_width) {
DSSERR(check_overlay: overlay %d doesn't support
Tomi
signature.asc
Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
On Tue, Nov 27, 2012 at 3:32 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?
That was my guess too, and after some digging I am fairly certain this
is the case.
Anyway, I guess it's a valid thing to configure the overlay with
paddr == 0 when the overlay is disabled. In fact, paddr == 0 check
is in any case quite limited, as if the board's physical memory
doesn't contain the given paddr, the DSS HW will fail just as it
would for paddr 0. So the paddr == 0 check is more of a sanity check
than a comprehensive test.
Can you try the following patch:
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 45f4994..e271e28 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev)
int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info)
{
- if (info-paddr == 0) {
- DSSERR(check_overlay: paddr cannot be 0\n);
- return -EINVAL;
- }
-
if ((ovl-caps OMAP_DSS_OVL_CAP_SCALE) == 0) {
if (info-out_width != 0 info-width != info-out_width) {
DSSERR(check_overlay: overlay %d doesn't support
I tried something similar over the weekend (just removed the return so
I still got the error printout) and found that the simple_check failed
in 2 more places.
Here is the patch I ended up with to get a successful simple_check:
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -610,7 +610,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
{
if (info-paddr == 0) {
DSSERR(check_overlay: paddr cannot be 0\n);
-return -EINVAL;
+//return -EINVAL;
}
if ((ovl-caps OMAP_DSS_OVL_CAP_SCALE) == 0) {
@@ -630,7 +630,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
if ((ovl-supported_modes info-color_mode) == 0) {
DSSERR(check_overlay: overlay %d doesn't support mode %d\n,
ovl-id, info-color_mode);
-return -EINVAL;
+//return -EINVAL;
}
if (info-zorder = omap_dss_get_num_overlays()) {
@@ -641,7 +641,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
if (dss_feat_rotation_type_supported(info-rotation_type) == 0) {
DSSERR(check_overlay: rotation type %d not supported\n,
info-rotation_type);
-return -EINVAL;
+//return -EINVAL;
}
return 0;
After digging a little more it turned out that the continual
restarting of X wasn't due to the above error, but to a build system
glitch. So the above issue doesn't block a basic X session.
I checked XVideo both with and without the above patch and it is
broken in both cases. I'm beginning to suspect that this might be a
user space bug and will do a little investigation.
Because of this I don't think any dss changes should be made at this point.
During my testing I think I uncovered another issue :-(
I set omapdss.def_disp=lcd43 on the kernel command line to see if the
behavior changed with the LCD as the default device.
What I encountered was a null pointer crash:
[3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R
[3.488250] Unable to handle kernel NULL pointer dereference at
virtual address 0028
[3.496765] pgd = c0004000
[3.499603] [0028] *pgd=
[3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM
[3.508605] Modules linked in:
[3.511810] CPU: 0Not tainted (3.6.0 #1)
[3.516357] PC is at dss_mgr_check_timings+0x4/0x30
[3.521484] LR is at dpi_check_timings+0x18/0xb8
[3.526336] pc : [c025df70]lr : [c0260dc0]psr: 4013
[3.526336] sp : dec2bd88 ip : fp : def7e180
[3.538330] r10: def951c0 r9 : def61000 r8 : de41b858
[3.543823] r7 : dec2bdfc r6 : c06c0a50 r5 : dec2be00 r4 : deea1cd4
[3.550659] r3 : dec1ba40 r2 : dec2bdc8 r1 : dec2be00 r0 :
[3.557495] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[3.565155] Control: 10c5387d Table: 80004019 DAC: 0015
[3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0)
[3.577270] Stack: (0xdec2bd88 to 0xdec2c000)
[3.581848] bd80: dec1ba40 c0260dc0
deea1cd4 def7e180 c046a7d0
[3.590423] bda0: deea1cd4
c06c0a50 dec2be00 dec2bdfc
[3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50
de41b800 c046749c
[3.607513] bde0: 003d c0495788 0018 0010
def98640 dec00140
[3.616088] be00: 03000400 dac0 00300020 00040050 0003000f
0001
[3.624664] be20: 0001 c0459380 deea257c
c06c0d00 dec2be50
[3.633209] be40: c025cc10 c029a98c c029ae80 dec075d8
Re: omap DSS fails with tft410 driver panel?
On 2012-11-23 08:14, Steve Sakoman wrote:
On Thu, Nov 22, 2012 at 12:47 AM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
I'll add the printk's to omapfb_setup_plane() that were requested by
Tomi and report back.
Today was a holiday, so family obligations didn't allow much time to
look at this.
I did however do a quick build with some printk's in
omapfb_setup_plane() so I could narrow down where to start looking.
I discovered that the error (omapdss OVERLAY error: check_overlay:
paddr cannot be 0) is happening as a result of the
ovl-set_overlay_info() call in the else clause of the code below:
if (pi-enabled) {
r = omapfb_setup_overlay(fbi, ovl, pi-pos_x, pi-pos_y,
pi-out_width, pi-out_height);
if (r) {
printk(omapfb_setup_plane: pi-enabled
omapfb_setup_overlay()\n);
goto undo;
}
} else {
struct omap_overlay_info info;
ovl-get_overlay_info(ovl, info);
info.pos_x = pi-pos_x;
info.pos_y = pi-pos_y;
info.out_width = pi-out_width;
info.out_height = pi-out_height;
r = ovl-set_overlay_info(ovl, info);
if (r) {
printk(omapfb_setup_plane: !pi-enabled
ovl-set_overlay_info failed\n);
goto undo;
}
}
Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
put a printk at dss/apply.c:dss_olv_set_info, and print ovl-id and
info-paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
the point where it sets info.paddr, as I think that's the only place
where omapfb sets paddr.
I don't know what's going on there, why the paddr is suddenly zero.
Looking at the log from Enric, SETUP_PLANE works fine just fine, and
then, for no reason, next SETUP_PLANE fails, and the log doesn't show
anything much happening between.
However, I think omapdss may have been more permissive in the past,
allowing paddr 0 if the overlay is disabled. I could add that back, but
I'd rather first understand what's happening here.
I'll look at this more over as I get time over the coming days.
How can I reproduce this? Is there a downloadable rootfs somewhere that
I could try?
The only downloadable rootfs I have is 3.5 based. I'll try to get a
3.6 image posted in the next couple of days.
Could you also copy full kernel boot log to pastebin or such?
OK, will do that with my next build. I'll assume you want dss
debugging enabled for that.
That's probably not needed. I mostly wanted to know if there's some dss
error/warning seen on the boot. But probably not if the problem happens
in the code above.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you put a printk at dss/apply.c:dss_olv_set_info, and print ovl-id and info-paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at the point where it sets info.paddr, as I think that's the only place where omapfb sets paddr. OK, did that and here is what I get when starting up gdm, prior to that all is normal root@omap3-multi:~# systemctl start gdm.service Starting Gnome Display Manager... Started Gnome Display Manager [ OK ] root@omap3-multi:~# [ 83.475128] omapfb_setup_plane entry [ 83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [ 83.485809] omapfb_setup_overlay: setting info.paddr = 9f40 [ 83.492431] dss_ovl_set_info entry [ 83.496307] ovl-id = 0 [ 83.499267] info-paddr = 9f40 [ 83.503601] omapfb_setup_plane: return success [ 83.508697] omapfb_setup_plane entry [ 83.513153] dss_ovl_set_info entry [ 83.516723] ovl-id = 2 [ 83.520111] info-paddr = 0 [ 83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 83.530426] omapfb_setup_plane: !pi-enabled ovl-set_overlay_info [ 83.537414] dss_ovl_set_info entry [ 83.540985] ovl-id = 2 [ 83.544250] info-paddr = 0 [ 83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0 repeats as X dies and restarts I don't know what's going on there, why the paddr is suddenly zero. Looking at the log from Enric, SETUP_PLANE works fine just fine, and then, for no reason, next SETUP_PLANE fails, and the log doesn't show anything much happening between. However, I think omapdss may have been more permissive in the past, allowing paddr 0 if the overlay is disabled. I could add that back, but I'd rather first understand what's happening here. From the above it seems that the first SETUP_PLANE is for ovl-id = 0 and then those that fail are for ovl-id =2. No idea what is going on in user space, but maybe this will mean something to you :-) Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On 2012-11-22 02:08, Steve Sakoman wrote: On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra eballe...@gmail.com 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? Not that I know. I am seeing the same errors on Overo. The video output actually works, but it appears that this error causes X to close and then restart repeatedly. I'll add the printk's to omapfb_setup_plane() that were requested by Tomi and report back. How can I reproduce this? Is there a downloadable rootfs somewhere that I could try? Could you also copy full kernel boot log to pastebin or such? Tomi signature.asc Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra eballe...@gmail.com 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? I am seeing the same errors on Overo. The video output actually works, but it appears that this error causes X to close and then restart repeatedly. I'll add the printk's to omapfb_setup_plane() that were requested by Tomi and report back. Regards, Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On Thu, Nov 22, 2012 at 12:47 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
I'll add the printk's to omapfb_setup_plane() that were requested by
Tomi and report back.
Today was a holiday, so family obligations didn't allow much time to
look at this.
I did however do a quick build with some printk's in
omapfb_setup_plane() so I could narrow down where to start looking.
I discovered that the error (omapdss OVERLAY error: check_overlay:
paddr cannot be 0) is happening as a result of the
ovl-set_overlay_info() call in the else clause of the code below:
if (pi-enabled) {
r = omapfb_setup_overlay(fbi, ovl, pi-pos_x, pi-pos_y,
pi-out_width, pi-out_height);
if (r) {
printk(omapfb_setup_plane: pi-enabled
omapfb_setup_overlay()\n);
goto undo;
}
} else {
struct omap_overlay_info info;
ovl-get_overlay_info(ovl, info);
info.pos_x = pi-pos_x;
info.pos_y = pi-pos_y;
info.out_width = pi-out_width;
info.out_height = pi-out_height;
r = ovl-set_overlay_info(ovl, info);
if (r) {
printk(omapfb_setup_plane: !pi-enabled
ovl-set_overlay_info failed\n);
goto undo;
}
}
I'll look at this more over as I get time over the coming days.
How can I reproduce this? Is there a downloadable rootfs somewhere that
I could try?
The only downloadable rootfs I have is 3.5 based. I'll try to get a
3.6 image posted in the next couple of days.
Could you also copy full kernel boot log to pastebin or such?
OK, will do that with my next build. I'll assume you want dss
debugging enabled for that.
Steve
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On 2012-10-15 19:08, Enric Balletbo Serra wrote: Hi Tomi, Thanks for your answer. 2012/10/12 Tomi Valkeinen tomi.valkei...@ti.com: On 2012-10-11 18:58, Enric Balletbo Serra wrote: Hi all, 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 Before checking what happens there is a known issue with this ? Works fine for me, although only with a quite minimal test environment. I tried with a minimal environment (without X) and I don't see the error, so looks you've reason and the problem is with my userspace application (X). OTOH, I don't see the video output. I remember that this worked before, but seems now is broken. I'll check mux and others hints to try to solve the problem .. It's not about muxing, but something else. So an earlier kernel works with the exact same userspace and kernel boot arguments? Then we probably have a bug in the kernel driver. But I can't say much from the debug prints, except that probably something goes wrong in the SETUP_PLANE ioctl. If you can, please add debug prints to omapfb-ioctl.c's omapfb_setup_plane() and print out the data in the omapfb_plane_info parameter, and also prints to the error code paths in the function. Tomi signature.asc Description: OpenPGP digital signature
Re: omap DSS fails with tft410 driver panel?
Hi Tomi, Thanks for your answer. 2012/10/12 Tomi Valkeinen tomi.valkei...@ti.com: On 2012-10-11 18:58, Enric Balletbo Serra wrote: Hi all, 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 Before checking what happens there is a known issue with this ? Works fine for me, although only with a quite minimal test environment. I tried with a minimal environment (without X) and I don't see the error, so looks you've reason and the problem is with my userspace application (X). OTOH, I don't see the video output. I remember that this worked before, but seems now is broken. I'll check mux and others hints to try to solve the problem .. Looking at the log, it looks to me that your userspace is trying to configure the overlays, and that somehow leads to the driver getting zero as the fb address. I'm guessing that some wrong value is passed when configuring, or missing some step in configuring. However, It should be the omapfb that rejects configuration that would lead to paddr == 0, not omapdss, so there's definitely bug in the error handling of omapfb. Can you tell me more what's going on there? I presume the error happens when booting? What userspace component is using omapfb in your setup? X? Yes, the error occurs while booting, and the rootfs tries to load X server. If you can, put some debug prints into omapfb-ioctl.c:omapfb_setup_plane to see what code path it takes, and where it goes wrong. First I'll try to get video output without X, then, if you want I can debug this problem if you think it's interesting. Regards, Enric -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap DSS fails with tft410 driver panel?
On 2012-10-11 18:58, Enric Balletbo Serra wrote: Hi all, 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 Before checking what happens there is a known issue with this ? Works fine for me, although only with a quite minimal test environment. Looking at the log, it looks to me that your userspace is trying to configure the overlays, and that somehow leads to the driver getting zero as the fb address. I'm guessing that some wrong value is passed when configuring, or missing some step in configuring. However, It should be the omapfb that rejects configuration that would lead to paddr == 0, not omapdss, so there's definitely bug in the error handling of omapfb. Can you tell me more what's going on there? I presume the error happens when booting? What userspace component is using omapfb in your setup? X? If you can, put some debug prints into omapfb-ioctl.c:omapfb_setup_plane to see what code path it takes, and where it goes wrong. Tomi signature.asc Description: OpenPGP digital signature
