Re: [PATCH v7 00/18] OMAP2,3: hwmod DSS Adaptation
Hi Kevin, On Fri, Jan 21, 2011 at 10:36 AM, Kevin Hilman khil...@ti.com wrote: Hi Sumit, Sumit Semwal sumit.sem...@ti.com writes: [...] Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. I think this series needs more validation on the other platforms. Getting a visible framebuffer w/tux on all tested platforms seems like a minimal requirement. I gave a test of this on 3530/Beagle with CONFIG_PANEL_GENERIC_DPI=y and driving a DVI monitor, using the following kernel cmdline # cat /proc/cmdline console=ttyO2,115200n8 mpurate=600 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Without your series, I see penguin logo and get a console login on the screen with this boot log (from dmesg |grep -i omapfb): [ 2.651885] OMAPFB: omapfb_init [ 2.652160] OMAPFB: omapfb_probe [ 2.657653] OMAPFB: create 3 framebuffers [ 2.657714] OMAPFB: fb_infos allocated [ 2.657714] OMAPFB: allocating 1572864 bytes for fb 0 [ 2.668212] OMAPFB: allocated VRAM paddr 8f40, vaddr d0a0 [ 2.668243] OMAPFB: region0 phys 8f40 virt d0a0 size=1572864 [ 2.668243] OMAPFB: region1 phys virt (null) size=0 [ 2.668273] OMAPFB: region2 phys virt (null) size=0 [ 2.668273] OMAPFB: fbmems allocated [ 2.668518] OMAPFB: check_fb_var 0 [ 2.668548] OMAPFB: max frame size 1572864, line size 2048 [ 2.668548] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768 [ 2.668579] OMAPFB: set_fb_fix [ 2.669036] OMAPFB: fb_infos initialized [ 2.673522] OMAPFB: set_par(0) [ 2.673614] OMAPFB: set_fb_fix [ 2.673614] OMAPFB: apply_changes, fb 0, ovl 0 [ 2.673645] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [ 2.673645] OMAPFB: paddr 8f40, vaddr d0a0 [ 2.674346] OMAPFB: pan_display(0) [ 2.674346] OMAPFB: setcmap [ 2.674377] OMAPFB: setcmap [ 2.683746] OMAPFB: pan_display(0) [ 2.683776] OMAPFB: setcmap [ 2.692108] OMAPFB: setcmap [ 2.701599] OMAPFB: framebuffers registered [ 2.701629] OMAPFB: apply_changes, fb 0, ovl 0 [ 2.701660] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [ 2.701690] OMAPFB: paddr 8f40, vaddr d0a0 [ 2.701721] OMAPFB: apply_changes, fb 1, ovl 1 [ 2.701751] OMAPFB: apply_changes, fb 2, ovl 2 [ 2.701751] OMAPFB: create_framebuffers done [ 2.702331] OMAPFB: mgr-apply'ed [ 2.704803] OMAPFB: create sysfs for fbs [ 2.704833] OMAPFB: create sysfs for fbs With your series applied (no other changes), I don't see anything on the screen because omapfb_probe() fails: [ 2.519653] OMAPFB: omapfb_init [ 2.519958] OMAPFB: omapfb_probe [ 2.520019] omapfb omapfb: no driver for display [ 2.525115] OMAPFB: free_resources [ 2.525146] OMAPFB: free all fbmem [ 2.525177] omapfb omapfb: failed to setup omapfb which indicates that omap_dss_get_device() is failing in omapfb_probe(). Thanks for testing this out - yes, you're right. I was able to reproduce this here, after getting hold of a beagle from someone, and found out the reason. The patch series misses some updates of device names [they were done for 3430sdp, but left out for other platforms somehow in the version of patches I got from the original authors.] I am updating this now, and will send out an updated patchset in some time. Unfortunately, the platforms available to me right now for testing were rather limited, so I would truly appreciate testing on other platforms not mentioned in the mail. Best regards, ~Sumit. Kevin -- 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: [PATCH v7 00/18] OMAP2,3: hwmod DSS Adaptation
Hi Sumit, Sumit Semwal sumit.sem...@ti.com writes: [...] Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. I think this series needs more validation on the other platforms. Getting a visible framebuffer w/tux on all tested platforms seems like a minimal requirement. I gave a test of this on 3530/Beagle with CONFIG_PANEL_GENERIC_DPI=y and driving a DVI monitor, using the following kernel cmdline # cat /proc/cmdline console=ttyO2,115200n8 mpurate=600 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Without your series, I see penguin logo and get a console login on the screen with this boot log (from dmesg |grep -i omapfb): [2.651885] OMAPFB: omapfb_init [2.652160] OMAPFB: omapfb_probe [2.657653] OMAPFB: create 3 framebuffers [2.657714] OMAPFB: fb_infos allocated [2.657714] OMAPFB: allocating 1572864 bytes for fb 0 [2.668212] OMAPFB: allocated VRAM paddr 8f40, vaddr d0a0 [2.668243] OMAPFB: region0 phys 8f40 virt d0a0 size=1572864 [2.668243] OMAPFB: region1 phys virt (null) size=0 [2.668273] OMAPFB: region2 phys virt (null) size=0 [2.668273] OMAPFB: fbmems allocated [2.668518] OMAPFB: check_fb_var 0 [2.668548] OMAPFB: max frame size 1572864, line size 2048 [2.668548] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768 [2.668579] OMAPFB: set_fb_fix [2.669036] OMAPFB: fb_infos initialized [2.673522] OMAPFB: set_par(0) [2.673614] OMAPFB: set_fb_fix [2.673614] OMAPFB: apply_changes, fb 0, ovl 0 [2.673645] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [2.673645] OMAPFB: paddr 8f40, vaddr d0a0 [2.674346] OMAPFB: pan_display(0) [2.674346] OMAPFB: setcmap [2.674377] OMAPFB: setcmap [2.683746] OMAPFB: pan_display(0) [2.683776] OMAPFB: setcmap [2.692108] OMAPFB: setcmap [2.701599] OMAPFB: framebuffers registered [2.701629] OMAPFB: apply_changes, fb 0, ovl 0 [2.701660] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [2.701690] OMAPFB: paddr 8f40, vaddr d0a0 [2.701721] OMAPFB: apply_changes, fb 1, ovl 1 [2.701751] OMAPFB: apply_changes, fb 2, ovl 2 [2.701751] OMAPFB: create_framebuffers done [2.702331] OMAPFB: mgr-apply'ed [2.704803] OMAPFB: create sysfs for fbs [2.704833] OMAPFB: create sysfs for fbs With your series applied (no other changes), I don't see anything on the screen because omapfb_probe() fails: [2.519653] OMAPFB: omapfb_init [2.519958] OMAPFB: omapfb_probe [2.520019] omapfb omapfb: no driver for display [2.525115] OMAPFB: free_resources [2.525146] OMAPFB: free all fbmem [2.525177] omapfb omapfb: failed to setup omapfb which indicates that omap_dss_get_device() is failing in omapfb_probe(). Kevin -- 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
[PATCH v7 00/18] OMAP2,3: hwmod DSS Adaptation
v7 of the DSS hwmod patch series fixes one issue found in testing after rebase on top of linux-next master (next-20110115 tag). A device rename in patch 05/18 was missed from board-zoom-peripherals.c, which is fixed in this version. A patch mentioned in http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html was needed to get OMAP3 to boot up on top of the said branch. OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design. This patch series decouples the Clocks for DSS in hwmod adaptation changes from this series. Another series would be posted which could be discussed w.r.t clocks in DSS across omap2,3. Removing the SYSCONFIG settings from DSS driver would also be part of these clock changes series and not covered in this series as it depends on some of the omap_hwmod framework changes w.r.t opt clocks handling. Summary of the hwmod DSS design: DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the hwmod class in the hwmod database. Each of these platform drivers' init / deinit are handled from core.c's omap_dss_probe() in the exact sequence as required. No Hardcoding of silicon data: hwmod database abstracts the SOC data like base addr, irq numbers and are implemented in this patch series. Continue to have custom bus for display panels: omap_display driver continues to be a platform driver that registers the custom bus. It also continues to register the display panels(omap_dss_device) on the board to the panel drivers (omap_dss_driver) For Eg: primary lcd device would be registered with lcd panel driver. lcd panel driver if it is on a parallel interface would use library functions exported from dpi.o. if it is on a dsi interface would use library functions exported from dsi platform driver(dsi.o). Clocks: Handling of clocks in DSS only is one of the design approaches, that does not change the existing implementation. If each of the DSS HW IPs had to handle their own clocks, then corresponding clock changes can be requested in the hwmod database as well which is not the current design/implementation. As stated, this would be handled in another series seperately. For Eg: VENC would need 54MCLK which is termed as dss_opt clocks as of now apart for the dss main clocks. Currently VENC driver needs to be aware of this and has to use clk_get/put, clk_enable/disable, since VENC hwmod is not aware of 54MCLK. Current dss driver: --- 1. Omapdss platform driver - initialises necessary Ips dss, dispc. - also initialises Ips like sdi, dsi, venc, rfbi - creates a custom bus and registers the display devices/drivers connected on the board to the custom bus. 2. Suspend/resume of omapdss - in turn sends suspend/resume calls for each of the display devices registered to it. Modified change: --- Platform driver for each DSS HW IP in addition to the software omap_display driver. Omapdss platform driver - initialises necessary h/w IPs' platform drivers [dss, dispc, dsi, venc, rfbi] and software libraries like dpi, sdi. - continues to have a custom bus and registers the display devices and drivers connected on the board to the custom bus. - continues to handle suspend/resume of the display devices registered to the custom bus. DSS platform driver - initialises DSS IP alone - Handles the clocks related to the DSS and other DSSHW IPs like RFBI, DSI, VENC, DISPC. Previously this was a part of omapdss driver in core.c - Continues to handle the DSS IRQs. - No suspend/resume hooks. DISPC platform driver - initialises DISPC IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DISPC library functions. DSI platform driver - initialises DSI IP alone - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide DSI library functions. RFBI, VENC platform drivers - initialises DSI,VENC IPs - Gets the required clock from DSS platform driver. - No suspend/resume hooks. - Continues to provide RFBI and VENC library functions. Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. DSS was built successfully as module, though not tested yet. Changes since v6: - * board-zoom-peripherals.c: Added missing change of device name from omapdss to omap_display. Found during testing on OMAP3630 on top of Changes since v5: 1) Following review comments incorporated: *
