Re: [PATCH v10 00/18] OMAP2,3: hwmod DSS Adaptation
On Tue, 2011-01-25 at 09:03 -0800, ext Tony Lindgren wrote: > * Kevin Hilman [110124 13:56]: > > Sumit Semwal writes: > > > > > v10 of the patch series corrects return-error handling from > > > platform_request_irq() > > > based on comments from Sergei Shtylyov and Russell King. > > > [https://patchwork.kernel.org/patch/497911/] > > > > Tony, > > > > Assuming Tomi is OK with this series, I think these are ready to go into > > omap-testing for some broader testing. > > I can merge in Tomi's branch for testing once Tomi is happy with them. I've applied the patch set to my tree: git://gitorious.org/linux-omap-dss2/linux.git master It compiles, but due to this being my last day in Nokia, I don't have equipment to test it. It's also missing my signed-offs. I haven't been able to review the latest versions of the patch set, so these patches may not be the final versions. However, everything looked pretty good a few versions ago, so I don't expect any bigger changes. It's up to Tony if he wants to merge the branch, even if it may not be the very final version. I will get back to these patches when my situation clears up, which may take a bit over a week or so. Tomi -- 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 v10 00/18] OMAP2,3: hwmod DSS Adaptation
* Kevin Hilman [110124 13:56]: > Sumit Semwal writes: > > > v10 of the patch series corrects return-error handling from > > platform_request_irq() > > based on comments from Sergei Shtylyov and Russell King. > > [https://patchwork.kernel.org/patch/497911/] > > Tony, > > Assuming Tomi is OK with this series, I think these are ready to go into > omap-testing for some broader testing. I can merge in Tomi's branch for testing once Tomi is happy with them. Regards, Tony -- 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 v10 00/18] OMAP2,3: hwmod DSS Adaptation
Sumit Semwal writes: > v10 of the patch series corrects return-error handling from > platform_request_irq() > based on comments from Sergei Shtylyov and Russell King. > [https://patchwork.kernel.org/patch/497911/] Tony, Assuming Tomi is OK with this series, I think these are ready to go into omap-testing for some broader testing. Kevin > v9 of this patch series adds reviewed-by and acked-by from Kevin Hilman. > > v8 of the DSS hwmod patch series fixes some issues based on findings of > Kevin Hilman on beagle. > > The VENC platform driver was not getting registered due to missed device > name update for vdda_dac regulator in some board files. This was moved from > 'omap_display' device to 'omap_venc' device in patch 14/18. > > Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs > two > instances - one for dpi, and one for dsi. > > This version corrects the above two for all board files where 'vdda_dac' and > 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18] > > Post this change, boot w/ visible framebuffer and tux was successfully > validated > on beagle, 3430SDP and zoom3. > > 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 linux-next of 20110115. > > OMAP4 hwmod support will be posted after the acceptance of this basic change > in > the dss2 design. > > - > [original patch introduction] > > 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
[PATCH v10 00/18] OMAP2,3: hwmod DSS Adaptation
v10 of the patch series corrects return-error handling from platform_request_irq() based on comments from Sergei Shtylyov and Russell King. [https://patchwork.kernel.org/patch/497911/] v9 of this patch series adds reviewed-by and acked-by from Kevin Hilman. v8 of the DSS hwmod patch series fixes some issues based on findings of Kevin Hilman on beagle. The VENC platform driver was not getting registered due to missed device name update for vdda_dac regulator in some board files. This was moved from 'omap_display' device to 'omap_venc' device in patch 14/18. Also, similarly for DSI platform driver, the regulator name 'vdds_dsi' needs two instances - one for dpi, and one for dsi. This version corrects the above two for all board files where 'vdda_dac' and 'vdds_dsi' regulators are defined. [patches 14/18 and 15/18] Post this change, boot w/ visible framebuffer and tux was successfully validated on beagle, 3430SDP and zoom3. 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 linux-next of 20110115. OMAP4 hwmod support will be posted after the acceptance of this basic change in the dss2 design. - [original patch introduction] 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 - in
