* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-12 10:26 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-12 10:26 UTC (permalink / raw) To: Tony Lindgren, Paul Walmsley, Benoît Cousson Cc: Archit Taneja, linux-omap, linux-arm-kernel, Tomi Valkeinen Hi, This patch adds hwmod data for omap5 display subsystem. I have tested this on omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the mainline is missing omap5 HDMI driver. I do see this when booting: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_dsi1: cannot be enabled for reset (3) omap_hwmod: dss_dsi2: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) But at least DSI works just fine. Tomi Archit Taneja (1): ARM: OMAP5: Add omap5 DSS related hwmod data arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) -- 1.8.3.2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-12 10:26 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-12 10:26 UTC (permalink / raw) To: linux-arm-kernel Hi, This patch adds hwmod data for omap5 display subsystem. I have tested this on omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the mainline is missing omap5 HDMI driver. I do see this when booting: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_dsi1: cannot be enabled for reset (3) omap_hwmod: dss_dsi2: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) But at least DSI works just fine. Tomi Archit Taneja (1): ARM: OMAP5: Add omap5 DSS related hwmod data arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) -- 1.8.3.2 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: Add omap5 DSS related hwmod data 2014-03-12 10:26 ` Tomi Valkeinen @ 2014-03-12 10:26 ` Tomi Valkeinen -1 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-12 10:26 UTC (permalink / raw) To: Tony Lindgren, Paul Walmsley, Benoît Cousson Cc: Archit Taneja, linux-omap, linux-arm-kernel, Tomi Valkeinen From: Archit Taneja <archit@ti.com> Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more or less similar to omap4 hwmod data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c index e297d6231c3a..c7d33ae26282 100644 --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c @@ -334,6 +334,235 @@ static struct omap_hwmod omap54xx_dmic_hwmod = { }; /* + * 'dss' class + * display sub-system + */ +static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = { + .rev_offs = 0x0000, + .syss_offs = 0x0014, + .sysc_flags = SYSS_HAS_RESET_STATUS, +}; + +static struct omap_hwmod_class omap54xx_dss_hwmod_class = { + .name = "dss", + .sysc = &omap54xx_dss_sysc, + .reset = omap_dss_reset, +}; + +/* dss */ +static struct omap_hwmod_opt_clk dss_opt_clks[] = { + { .role = "32khz_clk", .clk = "dss_32khz_clk" }, + { .role = "sys_clk", .clk = "dss_sys_clk" }, + { .role = "hdmi_clk", .clk = "dss_48mhz_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_hwmod = { + .name = "dss_core", + .class = &omap54xx_dss_hwmod_class, + .clkdm_name = "dss_clkdm", + .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET, + .modulemode = MODULEMODE_SWCTRL, + }, + }, + .opt_clks = dss_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks), +}; + +/* + * 'dispc' class + * display controller + */ + +static struct omap_hwmod_class_sysconfig omap54xx_dispc_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .syss_offs = 0x0014, + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY | + SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE | + SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET | + SYSS_HAS_RESET_STATUS), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | + MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap54xx_dispc_hwmod_class = { + .name = "dispc", + .sysc = &omap54xx_dispc_sysc, +}; + +/* dss_dispc */ +static struct omap_hwmod_opt_clk dss_dispc_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +/* dss_dispc dev_attr */ +static struct omap_dss_dispc_dev_attr dss_dispc_dev_attr = { + .has_framedonetv_irq = 1, + .manager_count = 4, +}; + +static struct omap_hwmod omap54xx_dss_dispc_hwmod = { + .name = "dss_dispc", + .class = &omap54xx_dispc_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_dispc_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_dispc_opt_clks), + .dev_attr = &dss_dispc_dev_attr, +}; + +/* + * 'dsi1' class + * display serial interface controller + */ + +static struct omap_hwmod_class_sysconfig omap54xx_dsi1_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .syss_offs = 0x0014, + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY | + SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap54xx_dsi1_hwmod_class = { + .name = "dsi1", + .sysc = &omap54xx_dsi1_sysc, +}; + +/* dss_dsi1_a */ +static struct omap_hwmod_opt_clk dss_dsi1_a_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = { + .name = "dss_dsi1", + .class = &omap54xx_dsi1_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_dsi1_a_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_dsi1_a_opt_clks), +}; + +/* dss_dsi1_c */ +static struct omap_hwmod_opt_clk dss_dsi1_c_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_dsi1_c_hwmod = { + .name = "dss_dsi2", + .class = &omap54xx_dsi1_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_dsi1_c_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_dsi1_c_opt_clks), +}; + +/* + * 'hdmi' class + * hdmi controller + */ + +static struct omap_hwmod_class_sysconfig omap54xx_hdmi_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | + SIDLE_SMART_WKUP), + .sysc_fields = &omap_hwmod_sysc_type2, +}; + +static struct omap_hwmod_class omap54xx_hdmi_hwmod_class = { + .name = "hdmi", + .sysc = &omap54xx_hdmi_sysc, +}; + +static struct omap_hwmod_opt_clk dss_hdmi_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_hdmi_hwmod = { + .name = "dss_hdmi", + .class = &omap54xx_hdmi_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_48mhz_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_hdmi_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks), +}; + +/* + * 'rfbi' class + * remote frame buffer interface + */ + +static struct omap_hwmod_class_sysconfig omap54xx_rfbi_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .syss_offs = 0x0014, + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap54xx_rfbi_hwmod_class = { + .name = "rfbi", + .sysc = &omap54xx_rfbi_sysc, +}; + +/* dss_rfbi */ +static struct omap_hwmod_opt_clk dss_rfbi_opt_clks[] = { + { .role = "ick", .clk = "l3_iclk_div" }, +}; + +static struct omap_hwmod omap54xx_dss_rfbi_hwmod = { + .name = "dss_rfbi", + .class = &omap54xx_rfbi_hwmod_class, + .clkdm_name = "dss_clkdm", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_rfbi_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_rfbi_opt_clks), +}; + +/* * 'emif' class * external memory interface no1 (wrapper) */ @@ -1893,6 +2122,54 @@ static struct omap_hwmod_ocp_if omap54xx_l4_abe__dmic = { .user = OCP_USER_MPU, }; +/* l3_main_2 -> dss */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_dispc */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_dispc = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_dispc_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_dsi1_a */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_dsi1_a = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_dsi1_a_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_dsi1_c */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_dsi1_c = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_dsi1_c_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_hdmi */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_hdmi = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_hdmi_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_rfbi */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_rfbi = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_rfbi_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + /* mpu -> emif1 */ static struct omap_hwmod_ocp_if omap54xx_mpu__emif1 = { .master = &omap54xx_mpu_hwmod, @@ -2345,6 +2622,12 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = { &omap54xx_l4_wkup__counter_32k, &omap54xx_l4_cfg__dma_system, &omap54xx_l4_abe__dmic, + &omap54xx_l3_main_2__dss, + &omap54xx_l3_main_2__dss_dispc, + &omap54xx_l3_main_2__dss_dsi1_a, + &omap54xx_l3_main_2__dss_dsi1_c, + &omap54xx_l3_main_2__dss_hdmi, + &omap54xx_l3_main_2__dss_rfbi, &omap54xx_mpu__emif1, &omap54xx_mpu__emif2, &omap54xx_l4_wkup__gpio1, -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: Add omap5 DSS related hwmod data @ 2014-03-12 10:26 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-12 10:26 UTC (permalink / raw) To: linux-arm-kernel From: Archit Taneja <archit@ti.com> Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more or less similar to omap4 hwmod data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c index e297d6231c3a..c7d33ae26282 100644 --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c @@ -334,6 +334,235 @@ static struct omap_hwmod omap54xx_dmic_hwmod = { }; /* + * 'dss' class + * display sub-system + */ +static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = { + .rev_offs = 0x0000, + .syss_offs = 0x0014, + .sysc_flags = SYSS_HAS_RESET_STATUS, +}; + +static struct omap_hwmod_class omap54xx_dss_hwmod_class = { + .name = "dss", + .sysc = &omap54xx_dss_sysc, + .reset = omap_dss_reset, +}; + +/* dss */ +static struct omap_hwmod_opt_clk dss_opt_clks[] = { + { .role = "32khz_clk", .clk = "dss_32khz_clk" }, + { .role = "sys_clk", .clk = "dss_sys_clk" }, + { .role = "hdmi_clk", .clk = "dss_48mhz_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_hwmod = { + .name = "dss_core", + .class = &omap54xx_dss_hwmod_class, + .clkdm_name = "dss_clkdm", + .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET, + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET, + .modulemode = MODULEMODE_SWCTRL, + }, + }, + .opt_clks = dss_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks), +}; + +/* + * 'dispc' class + * display controller + */ + +static struct omap_hwmod_class_sysconfig omap54xx_dispc_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .syss_offs = 0x0014, + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY | + SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE | + SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET | + SYSS_HAS_RESET_STATUS), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | + MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap54xx_dispc_hwmod_class = { + .name = "dispc", + .sysc = &omap54xx_dispc_sysc, +}; + +/* dss_dispc */ +static struct omap_hwmod_opt_clk dss_dispc_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +/* dss_dispc dev_attr */ +static struct omap_dss_dispc_dev_attr dss_dispc_dev_attr = { + .has_framedonetv_irq = 1, + .manager_count = 4, +}; + +static struct omap_hwmod omap54xx_dss_dispc_hwmod = { + .name = "dss_dispc", + .class = &omap54xx_dispc_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_dispc_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_dispc_opt_clks), + .dev_attr = &dss_dispc_dev_attr, +}; + +/* + * 'dsi1' class + * display serial interface controller + */ + +static struct omap_hwmod_class_sysconfig omap54xx_dsi1_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .syss_offs = 0x0014, + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY | + SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap54xx_dsi1_hwmod_class = { + .name = "dsi1", + .sysc = &omap54xx_dsi1_sysc, +}; + +/* dss_dsi1_a */ +static struct omap_hwmod_opt_clk dss_dsi1_a_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = { + .name = "dss_dsi1", + .class = &omap54xx_dsi1_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_dsi1_a_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_dsi1_a_opt_clks), +}; + +/* dss_dsi1_c */ +static struct omap_hwmod_opt_clk dss_dsi1_c_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_dsi1_c_hwmod = { + .name = "dss_dsi2", + .class = &omap54xx_dsi1_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_dss_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_dsi1_c_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_dsi1_c_opt_clks), +}; + +/* + * 'hdmi' class + * hdmi controller + */ + +static struct omap_hwmod_class_sysconfig omap54xx_hdmi_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | + SIDLE_SMART_WKUP), + .sysc_fields = &omap_hwmod_sysc_type2, +}; + +static struct omap_hwmod_class omap54xx_hdmi_hwmod_class = { + .name = "hdmi", + .sysc = &omap54xx_hdmi_sysc, +}; + +static struct omap_hwmod_opt_clk dss_hdmi_opt_clks[] = { + { .role = "sys_clk", .clk = "dss_sys_clk" }, +}; + +static struct omap_hwmod omap54xx_dss_hdmi_hwmod = { + .name = "dss_hdmi", + .class = &omap54xx_hdmi_hwmod_class, + .clkdm_name = "dss_clkdm", + .main_clk = "dss_48mhz_clk", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_hdmi_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks), +}; + +/* + * 'rfbi' class + * remote frame buffer interface + */ + +static struct omap_hwmod_class_sysconfig omap54xx_rfbi_sysc = { + .rev_offs = 0x0000, + .sysc_offs = 0x0010, + .syss_offs = 0x0014, + .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE | + SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS), + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .sysc_fields = &omap_hwmod_sysc_type1, +}; + +static struct omap_hwmod_class omap54xx_rfbi_hwmod_class = { + .name = "rfbi", + .sysc = &omap54xx_rfbi_sysc, +}; + +/* dss_rfbi */ +static struct omap_hwmod_opt_clk dss_rfbi_opt_clks[] = { + { .role = "ick", .clk = "l3_iclk_div" }, +}; + +static struct omap_hwmod omap54xx_dss_rfbi_hwmod = { + .name = "dss_rfbi", + .class = &omap54xx_rfbi_hwmod_class, + .clkdm_name = "dss_clkdm", + .prcm = { + .omap4 = { + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + }, + }, + .opt_clks = dss_rfbi_opt_clks, + .opt_clks_cnt = ARRAY_SIZE(dss_rfbi_opt_clks), +}; + +/* * 'emif' class * external memory interface no1 (wrapper) */ @@ -1893,6 +2122,54 @@ static struct omap_hwmod_ocp_if omap54xx_l4_abe__dmic = { .user = OCP_USER_MPU, }; +/* l3_main_2 -> dss */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_dispc */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_dispc = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_dispc_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_dsi1_a */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_dsi1_a = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_dsi1_a_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_dsi1_c */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_dsi1_c = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_dsi1_c_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_hdmi */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_hdmi = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_hdmi_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + +/* l3_main_2 -> dss_rfbi */ +static struct omap_hwmod_ocp_if omap54xx_l3_main_2__dss_rfbi = { + .master = &omap54xx_l3_main_2_hwmod, + .slave = &omap54xx_dss_rfbi_hwmod, + .clk = "l3_iclk_div", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + /* mpu -> emif1 */ static struct omap_hwmod_ocp_if omap54xx_mpu__emif1 = { .master = &omap54xx_mpu_hwmod, @@ -2345,6 +2622,12 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = { &omap54xx_l4_wkup__counter_32k, &omap54xx_l4_cfg__dma_system, &omap54xx_l4_abe__dmic, + &omap54xx_l3_main_2__dss, + &omap54xx_l3_main_2__dss_dispc, + &omap54xx_l3_main_2__dss_dsi1_a, + &omap54xx_l3_main_2__dss_dsi1_c, + &omap54xx_l3_main_2__dss_hdmi, + &omap54xx_l3_main_2__dss_rfbi, &omap54xx_mpu__emif1, &omap54xx_mpu__emif2, &omap54xx_l4_wkup__gpio1, -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-12 10:26 ` Tomi Valkeinen @ 2014-03-12 10:33 ` Tomi Valkeinen -1 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-12 10:33 UTC (permalink / raw) To: Tony Lindgren, Paul Walmsley, Benoît Cousson Cc: Archit Taneja, linux-omap, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 1014 bytes --] On 12/03/14 12:26, Tomi Valkeinen wrote: > Hi, > > This patch adds hwmod data for omap5 display subsystem. I have tested this on > omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the > mainline is missing omap5 HDMI driver. > > I do see this when booting: > > omap_hwmod: dss_dispc: cannot be enabled for reset (3) > omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > > But at least DSI works just fine. Oh, I forgot to say that I tested this on top of the DSS DT branch, and unpublished omap5 and omap5-uevm display patches. So if applied to the current mainline, the hwmods are not used at all (except the reset at boot time, I think). But if this gets merged for 3.15, it'll make adding omap5 DSS support easier for 3.16 as the HWMOD data is already there. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-12 10:33 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-12 10:33 UTC (permalink / raw) To: linux-arm-kernel On 12/03/14 12:26, Tomi Valkeinen wrote: > Hi, > > This patch adds hwmod data for omap5 display subsystem. I have tested this on > omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the > mainline is missing omap5 HDMI driver. > > I do see this when booting: > > omap_hwmod: dss_dispc: cannot be enabled for reset (3) > omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > > But at least DSI works just fine. Oh, I forgot to say that I tested this on top of the DSS DT branch, and unpublished omap5 and omap5-uevm display patches. So if applied to the current mainline, the hwmods are not used at all (except the reset at boot time, I think). But if this gets merged for 3.15, it'll make adding omap5 DSS support easier for 3.16 as the HWMOD data is already there. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140312/73433334/attachment.sig> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-12 10:33 ` Tomi Valkeinen @ 2014-03-16 11:41 ` Dmitry Lifshitz -1 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-16 11:41 UTC (permalink / raw) To: Tomi Valkeinen Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel Hi Tomi, (resending in the text format) Where can I get those unpublished omap5 and omap5-uevm display patches to test the video out with this patch? I'll appreciate your assistance in additional setup (like required uEvm .dts changes and DSI panel connection short guide). Thanks you in advance, Dmitry Lifshitz On 03/12/2014 12:33 PM, Tomi Valkeinen wrote: > On 12/03/14 12:26, Tomi Valkeinen wrote: >> Hi, >> >> This patch adds hwmod data for omap5 display subsystem. I have tested this on >> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the >> mainline is missing omap5 HDMI driver. >> >> I do see this when booting: >> >> omap_hwmod: dss_dispc: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >> >> But at least DSI works just fine. > Oh, I forgot to say that I tested this on top of the DSS DT branch, and > unpublished omap5 and omap5-uevm display patches. So if applied to the > current mainline, the hwmods are not used at all (except the reset at > boot time, I think). > > But if this gets merged for 3.15, it'll make adding omap5 DSS support > easier for 3.16 as the HWMOD data is already there. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-16 11:41 ` Dmitry Lifshitz 0 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-16 11:41 UTC (permalink / raw) To: linux-arm-kernel Hi Tomi, (resending in the text format) Where can I get those unpublished omap5 and omap5-uevm display patches to test the video out with this patch? I'll appreciate your assistance in additional setup (like required uEvm .dts changes and DSI panel connection short guide). Thanks you in advance, Dmitry Lifshitz On 03/12/2014 12:33 PM, Tomi Valkeinen wrote: > On 12/03/14 12:26, Tomi Valkeinen wrote: >> Hi, >> >> This patch adds hwmod data for omap5 display subsystem. I have tested this on >> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the >> mainline is missing omap5 HDMI driver. >> >> I do see this when booting: >> >> omap_hwmod: dss_dispc: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >> >> But at least DSI works just fine. > Oh, I forgot to say that I tested this on top of the DSS DT branch, and > unpublished omap5 and omap5-uevm display patches. So if applied to the > current mainline, the hwmods are not used at all (except the reset at > boot time, I think). > > But if this gets merged for 3.15, it'll make adding omap5 DSS support > easier for 3.16 as the HWMOD data is already there. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-16 11:41 ` Dmitry Lifshitz @ 2014-03-17 6:13 ` Tomi Valkeinen -1 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-17 6:13 UTC (permalink / raw) To: Dmitry Lifshitz Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 530 bytes --] On 16/03/14 13:41, Dmitry Lifshitz wrote: > Hi Tomi, > > (resending in the text format) > > Where can I get those unpublished omap5 and omap5-uevm display patches > to test the video out with this patch? > I'll appreciate your assistance in additional setup (like required uEvm > .dts changes and DSI panel connection short guide). git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-pyra I've since added omap5 hdmi support, so omap5-uevm's hdmi output works on that branch. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-17 6:13 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-17 6:13 UTC (permalink / raw) To: linux-arm-kernel On 16/03/14 13:41, Dmitry Lifshitz wrote: > Hi Tomi, > > (resending in the text format) > > Where can I get those unpublished omap5 and omap5-uevm display patches > to test the video out with this patch? > I'll appreciate your assistance in additional setup (like required uEvm > .dts changes and DSI panel connection short guide). git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-pyra I've since added omap5 hdmi support, so omap5-uevm's hdmi output works on that branch. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140317/880b9b13/attachment.sig> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-17 6:13 ` Tomi Valkeinen @ 2014-03-17 13:22 ` Dmitry Lifshitz -1 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-17 13:22 UTC (permalink / raw) To: Tomi Valkeinen Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel Hi Tomi, Thank you for the feedback. We have OMAP5 based board with no ESD & Level Translator chip. So, I made a quick hack in tpd12s015 driver to skip using un-relevant GPIOs. I've copied DSS DT structure from uEmv board *.dts. However the HDMI output is not activate yet. Here is some debug output: root@cm-debian:~# dmesg | grep -i dss [ 0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) [ 0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) [ 0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) [ 0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) [ 0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) [ 0.325392] DSS: set fck to 192000000 [ 0.325400] DSS: dss_runtime_get [ 0.325427] DSS: dss_restore_context [ 0.325445] OMAP DSS rev 6.1 [ 0.325450] DSS: dss_runtime_put [ 0.325456] DSS: dss_save_context [ 0.325461] DSS: context saved [ 0.325707] DSS: dss_restore_context [ 0.325711] DSS: context restored [ 0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 [ 0.325838] DSS: dss_save_context [ 0.325843] DSS: context saved I do not use uEvm BSP u-Boot. I'm forking from this source: git://git.denx.de/u-boot-ti.git Perhaps I'm missing some clocks initialization? What are the correct bootargs for activating HDMI video output? Thank you in advance for the assistance, Dmitry On 03/17/2014 08:13 AM, Tomi Valkeinen wrote: > On 16/03/14 13:41, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> (resending in the text format) >> >> Where can I get those unpublished omap5 and omap5-uevm display patches >> to test the video out with this patch? >> I'll appreciate your assistance in additional setup (like required uEvm >> .dts changes and DSI panel connection short guide). > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git > work/dss-dt-pyra > > I've since added omap5 hdmi support, so omap5-uevm's hdmi output works > on that branch. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-17 13:22 ` Dmitry Lifshitz 0 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-17 13:22 UTC (permalink / raw) To: linux-arm-kernel Hi Tomi, Thank you for the feedback. We have OMAP5 based board with no ESD & Level Translator chip. So, I made a quick hack in tpd12s015 driver to skip using un-relevant GPIOs. I've copied DSS DT structure from uEmv board *.dts. However the HDMI output is not activate yet. Here is some debug output: root at cm-debian:~# dmesg | grep -i dss [ 0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) [ 0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) [ 0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) [ 0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) [ 0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) [ 0.325392] DSS: set fck to 192000000 [ 0.325400] DSS: dss_runtime_get [ 0.325427] DSS: dss_restore_context [ 0.325445] OMAP DSS rev 6.1 [ 0.325450] DSS: dss_runtime_put [ 0.325456] DSS: dss_save_context [ 0.325461] DSS: context saved [ 0.325707] DSS: dss_restore_context [ 0.325711] DSS: context restored [ 0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 [ 0.325838] DSS: dss_save_context [ 0.325843] DSS: context saved I do not use uEvm BSP u-Boot. I'm forking from this source: git://git.denx.de/u-boot-ti.git Perhaps I'm missing some clocks initialization? What are the correct bootargs for activating HDMI video output? Thank you in advance for the assistance, Dmitry On 03/17/2014 08:13 AM, Tomi Valkeinen wrote: > On 16/03/14 13:41, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> (resending in the text format) >> >> Where can I get those unpublished omap5 and omap5-uevm display patches >> to test the video out with this patch? >> I'll appreciate your assistance in additional setup (like required uEvm >> .dts changes and DSI panel connection short guide). > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git > work/dss-dt-pyra > > I've since added omap5 hdmi support, so omap5-uevm's hdmi output works > on that branch. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-17 13:22 ` Dmitry Lifshitz @ 2014-03-17 13:28 ` Tomi Valkeinen -1 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-17 13:28 UTC (permalink / raw) To: Dmitry Lifshitz Cc: Paul Walmsley, Tony Lindgren, Archit Taneja, Benoît Cousson, linux-omap, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 1806 bytes --] On 17/03/14 15:22, Dmitry Lifshitz wrote: > Hi Tomi, > > Thank you for the feedback. > > We have OMAP5 based board with no ESD & Level Translator chip. > So, I made a quick hack in tpd12s015 driver to skip using un-relevant > GPIOs. If you don't have tpd12s015 on your board, don't modify it. Remove it from your board's dts file totally. > I've copied DSS DT structure from uEmv board *.dts. > However the HDMI output is not activate yet. > > Here is some debug output: > > root@cm-debian:~# dmesg | grep -i dss > [ 0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) > [ 0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > [ 0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > [ 0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > [ 0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > [ 0.325392] DSS: set fck to 192000000 > [ 0.325400] DSS: dss_runtime_get > [ 0.325427] DSS: dss_restore_context > [ 0.325445] OMAP DSS rev 6.1 > [ 0.325450] DSS: dss_runtime_put > [ 0.325456] DSS: dss_save_context > [ 0.325461] DSS: context saved > [ 0.325707] DSS: dss_restore_context > [ 0.325711] DSS: context restored > [ 0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 > [ 0.325838] DSS: dss_save_context > [ 0.325843] DSS: context saved > > > I do not use uEvm BSP u-Boot. I'm forking from this source: > git://git.denx.de/u-boot-ti.git > > Perhaps I'm missing some clocks initialization? > What are the correct bootargs for activating HDMI video output? HDMI is the only output on the uevm, and if your board is similar, no boot args are needed. But, of course, you need omapfb or omapdrm to manage the display. Tomi [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-17 13:28 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-17 13:28 UTC (permalink / raw) To: linux-arm-kernel On 17/03/14 15:22, Dmitry Lifshitz wrote: > Hi Tomi, > > Thank you for the feedback. > > We have OMAP5 based board with no ESD & Level Translator chip. > So, I made a quick hack in tpd12s015 driver to skip using un-relevant > GPIOs. If you don't have tpd12s015 on your board, don't modify it. Remove it from your board's dts file totally. > I've copied DSS DT structure from uEmv board *.dts. > However the HDMI output is not activate yet. > > Here is some debug output: > > root at cm-debian:~# dmesg | grep -i dss > [ 0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) > [ 0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > [ 0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > [ 0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > [ 0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > [ 0.325392] DSS: set fck to 192000000 > [ 0.325400] DSS: dss_runtime_get > [ 0.325427] DSS: dss_restore_context > [ 0.325445] OMAP DSS rev 6.1 > [ 0.325450] DSS: dss_runtime_put > [ 0.325456] DSS: dss_save_context > [ 0.325461] DSS: context saved > [ 0.325707] DSS: dss_restore_context > [ 0.325711] DSS: context restored > [ 0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 > [ 0.325838] DSS: dss_save_context > [ 0.325843] DSS: context saved > > > I do not use uEvm BSP u-Boot. I'm forking from this source: > git://git.denx.de/u-boot-ti.git > > Perhaps I'm missing some clocks initialization? > What are the correct bootargs for activating HDMI video output? HDMI is the only output on the uevm, and if your board is similar, no boot args are needed. But, of course, you need omapfb or omapdrm to manage the display. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140317/dcbd20db/attachment.sig> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-17 13:28 ` Tomi Valkeinen @ 2014-03-17 14:22 ` Dmitry Lifshitz -1 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-17 14:22 UTC (permalink / raw) To: Tomi Valkeinen Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel Hi Tomi, Unfortunately, I have a lack of experience with DT DSS stuff. How should I define the endpoints and the connector in my case? Please, could you provide some reference. Regarding omapfb, is it sufficient to turn it on in the Kernel config? Thanks, Dmitry On 03/17/2014 03:28 PM, Tomi Valkeinen wrote: > On 17/03/14 15:22, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> Thank you for the feedback. >> >> We have OMAP5 based board with no ESD & Level Translator chip. >> So, I made a quick hack in tpd12s015 driver to skip using un-relevant >> GPIOs. > If you don't have tpd12s015 on your board, don't modify it. Remove it > from your board's dts file totally. > >> I've copied DSS DT structure from uEmv board *.dts. >> However the HDMI output is not activate yet. >> >> Here is some debug output: >> >> root@cm-debian:~# dmesg | grep -i dss >> [ 0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) >> [ 0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >> [ 0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >> [ 0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >> [ 0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >> [ 0.325392] DSS: set fck to 192000000 >> [ 0.325400] DSS: dss_runtime_get >> [ 0.325427] DSS: dss_restore_context >> [ 0.325445] OMAP DSS rev 6.1 >> [ 0.325450] DSS: dss_runtime_put >> [ 0.325456] DSS: dss_save_context >> [ 0.325461] DSS: context saved >> [ 0.325707] DSS: dss_restore_context >> [ 0.325711] DSS: context restored >> [ 0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 >> [ 0.325838] DSS: dss_save_context >> [ 0.325843] DSS: context saved >> >> >> I do not use uEvm BSP u-Boot. I'm forking from this source: >> git://git.denx.de/u-boot-ti.git >> >> Perhaps I'm missing some clocks initialization? >> What are the correct bootargs for activating HDMI video output? > HDMI is the only output on the uevm, and if your board is similar, no > boot args are needed. But, of course, you need omapfb or omapdrm to > manage the display. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-17 14:22 ` Dmitry Lifshitz 0 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-17 14:22 UTC (permalink / raw) To: linux-arm-kernel Hi Tomi, Unfortunately, I have a lack of experience with DT DSS stuff. How should I define the endpoints and the connector in my case? Please, could you provide some reference. Regarding omapfb, is it sufficient to turn it on in the Kernel config? Thanks, Dmitry On 03/17/2014 03:28 PM, Tomi Valkeinen wrote: > On 17/03/14 15:22, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> Thank you for the feedback. >> >> We have OMAP5 based board with no ESD & Level Translator chip. >> So, I made a quick hack in tpd12s015 driver to skip using un-relevant >> GPIOs. > If you don't have tpd12s015 on your board, don't modify it. Remove it > from your board's dts file totally. > >> I've copied DSS DT structure from uEmv board *.dts. >> However the HDMI output is not activate yet. >> >> Here is some debug output: >> >> root at cm-debian:~# dmesg | grep -i dss >> [ 0.040554] omap_hwmod: dss_dispc: cannot be enabled for reset (3) >> [ 0.043135] omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >> [ 0.045725] omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >> [ 0.048311] omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >> [ 0.050888] omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >> [ 0.325392] DSS: set fck to 192000000 >> [ 0.325400] DSS: dss_runtime_get >> [ 0.325427] DSS: dss_restore_context >> [ 0.325445] OMAP DSS rev 6.1 >> [ 0.325450] DSS: dss_runtime_put >> [ 0.325456] DSS: dss_save_context >> [ 0.325461] DSS: context saved >> [ 0.325707] DSS: dss_restore_context >> [ 0.325711] DSS: context restored >> [ 0.325746] omapdss_dispc 58001000.dispc: OMAP DISPC rev 5.1 >> [ 0.325838] DSS: dss_save_context >> [ 0.325843] DSS: context saved >> >> >> I do not use uEvm BSP u-Boot. I'm forking from this source: >> git://git.denx.de/u-boot-ti.git >> >> Perhaps I'm missing some clocks initialization? >> What are the correct bootargs for activating HDMI video output? > HDMI is the only output on the uevm, and if your board is similar, no > boot args are needed. But, of course, you need omapfb or omapdrm to > manage the display. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-17 14:22 ` Dmitry Lifshitz @ 2014-03-18 5:29 ` Tomi Valkeinen -1 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-18 5:29 UTC (permalink / raw) To: Dmitry Lifshitz Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 652 bytes --] On 17/03/14 16:22, Dmitry Lifshitz wrote: > Hi Tomi, > > Unfortunately, I have a lack of experience with DT DSS stuff. > > How should I define the endpoints and the connector in my case? > Please, could you provide some reference. See Documentation/devicetree/bindings/media/video-interfaces.txt for a description of the ports and endpoints. If your board is similar to uevm except you don't have the tpd12s015, then you just need to remove the tpd12s015 from the .dts file, and connect the OMAP's HDMI output directly to the connector. > Regarding omapfb, is it sufficient to turn it on in the Kernel config? Yes. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-18 5:29 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-18 5:29 UTC (permalink / raw) To: linux-arm-kernel On 17/03/14 16:22, Dmitry Lifshitz wrote: > Hi Tomi, > > Unfortunately, I have a lack of experience with DT DSS stuff. > > How should I define the endpoints and the connector in my case? > Please, could you provide some reference. See Documentation/devicetree/bindings/media/video-interfaces.txt for a description of the ports and endpoints. If your board is similar to uevm except you don't have the tpd12s015, then you just need to remove the tpd12s015 from the .dts file, and connect the OMAP's HDMI output directly to the connector. > Regarding omapfb, is it sufficient to turn it on in the Kernel config? Yes. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140318/1e2da321/attachment.sig> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-18 5:29 ` Tomi Valkeinen @ 2014-03-18 8:19 ` Dmitry Lifshitz -1 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-18 8:19 UTC (permalink / raw) To: Tomi Valkeinen Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel Hi Tomi, Thank you a lot for your assistance. Here are my relevant DT nodes: / { aliases { display0 = &hdmi0; }; hdmi0: connector@0 { compatible = "hdmi-connector"; label = "hdmi"; type = "b"; hdmi_connector_in: endpoint { remote-endpoint = <&hdmi_out>; }; }; }; &dss { status = "ok"; }; &hdmi { status = "ok"; vdda-supply = <&ldo4_reg>; pinctrl-names = "default"; pinctrl-0 = <&dss_hdmi_pins>; hdmi_out: endpoint { remote-endpoint = <&hdmi_connector_in>; }; }; I have the following kernel crash (caused by missing .detect callback): [ 10.885320] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 10.893825] pgd = ed787240 [ 10.896670] [00000000] *pgd=00000000 [ 10.900427] Internal error: Oops: 80000205 [#1] SMP ARM [ 10.905883] Modules linked in: phy_omap_usb2 omapdrm(+) drm_kms_helper connector_hdmi omap4_keypad matrix_keymap omapdss fb_sys_fops omap_ocp2scp rtc_palmas spi_omap2_mcspi [ 10.922032] CPU: 1 PID: 333 Comm: modprobe Tainted: G W 3.14.0-rc4-cm-t54-test-suit+ #111 [ 10.931486] task: ece1e040 ti: ecea2000 task.ti: ecea2000 [ 10.937122] PC is at 0x0 [ 10.939771] LR is at hdmic_detect+0x14/0x18 [connector_hdmi] [ 10.945681] pc : [<00000000>] lr : [<bf1531c4>] psr: a0000013 [ 10.945681] sp : ecea3d50 ip : bf173158 fp : 00000000 [ 10.957664] r10: 00000800 r9 : 00000800 r8 : 00000004 [ 10.963118] r7 : bf17317c r6 : ecdf0400 r5 : ed6d4000 r4 : ed6d402c [ 10.969932] r3 : 00000000 r2 : bf15c7cc r1 : bf0437d0 r0 : bf059470 [ 10.976754] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 10.984207] Control: 30c5387d Table: ad787240 DAC: 55555555 [ 10.990209] Process modprobe (pid: 333, stack limit = 0xecea2248) [ 10.996574] Stack: (0xecea3d50 to 0xecea4000) [ 11.001123] 3d40: bf1531b0 bf16a134 bf16a118 bf158abc [ 11.009664] 3d60: 00000004 c0b5ae60 00000000 00000001 ece4ae00 00000000 00000800 00000800 [ 11.018203] 3d80: bf17a000 00000020 00000000 bf15b7b8 00000020 ece4ae00 ece4ae00 ecdf0400 [ 11.026751] 3da0: ed69b940 bf175978 00000000 bf16bfa4 0000081f ecdf0400 ed69b940 00000000 [ 11.035288] 3dc0: 00000000 bf167bbc 00000000 00000000 00000000 ecdf0400 00000000 00000000 [ 11.043828] 3de0: 00000000 c03afef8 c0a876a0 bf17586c ecdf0400 c03b179c c08dffd4 c01d641c [ 11.052365] 3e00: c03b1818 c0978eac c0a876b0 bf175978 c0a876b0 c03cc6c4 c03cc6ac c0b5af2c [ 11.060902] 3e20: bf175978 c03ca8cc c0a876b0 bf175978 c0a876e4 00000000 c0020f04 c03cab64 [ 11.069442] 3e40: 00000000 c0a876b0 bf175978 c03cac08 bf175978 00000000 c03cab7c c03c92dc [ 11.077983] 3e60: edcd45dc eddcb234 bf175978 ece13480 c0ab8d48 c03ca1b8 bf1740d4 c0020f04 [ 11.086524] 3e80: bf175978 bf175978 00000000 ecea2000 00000000 c03cb264 c03cbd54 c0a7e510 [ 11.095067] 3ea0: ecea2000 c0008788 000000d0 f02aefff 00000000 c0158bc0 c0003020 f02af000 [ 11.103608] 3ec0: 00000000 bf175b24 c0a93b14 00000000 00000001 bf175b24 00000000 00000000 [ 11.112156] 3ee0: 00000001 c00dc9ec c00dcdbc fffffffb 00000000 c072932c c0a92348 00000000 [ 11.120702] 3f00: c0a92348 00000000 bf175b24 c0072830 00000000 bd94362e 00000000 bf175b24 [ 11.129244] 3f20: 00400100 ecea2000 00000080 c0020f04 ecea2000 00000000 00000000 c07137b4 [ 11.137785] 3f40: 0001dfea b6d5b000 b6fa7114 0001dfea b6d5b000 c00bad0c f0290000 0001dfea [ 11.146323] 3f60: f02a29bc f02a2821 f02ab674 0000ecf0 00010510 00000000 00000000 00000000 [ 11.154860] 3f80: 00000027 00000028 0000001c 00000020 00000012 00000000 b87d23f8 00060000 [ 11.163409] 3fa0: b87d2280 c0020d80 b87d23f8 00060000 b6d5b000 0001dfea b6fa7114 b6d5b000 [ 11.171954] 3fc0: b87d23f8 00060000 b87d2280 00000080 b87d4c60 0001dfea b6fa7114 00000000 [ 11.180494] 3fe0: 00000000 bee169cc b6f9e190 b6f02e04 60000010 b6d5b000 00000000 00000000 [ 11.189071] [<bf1531c4>] (hdmic_detect [connector_hdmi]) from [<bf16a134>] (omap_connector_detect+0x1c/0x58 [omapdrm]) [ 11.200274] [<bf16a134>] (omap_connector_detect [omapdrm]) from [<bf158abc>] (drm_helper_probe_single_connector_modes+0x2b0/0x33c [drm_kms_helper]) [ 11.214089] [<bf158abc>] (drm_helper_probe_single_connector_modes [drm_kms_helper]) from [<bf15b7b8>] (drm_fb_helper_initial_config+0x5c/0xac [drm_kms_helper]) [ 11.229011] [<bf15b7b8>] (drm_fb_helper_initial_config [drm_kms_helper]) from [<bf16bfa4>] (omap_fbdev_init+0x90/0xc4 [omapdrm]) [ 11.241126] [<bf16bfa4>] (omap_fbdev_init [omapdrm]) from [<bf167bbc>] (dev_load+0xcc/0x148 [omapdrm]) [ 11.250861] [<bf167bbc>] (dev_load [omapdrm]) from [<c03afef8>] (drm_dev_register+0x78/0x138) [ 11.259776] [<c03afef8>] (drm_dev_register) from [<c03b179c>] (drm_get_platform_dev+0x50/0xa4) [ 11.268785] [<c03b179c>] (drm_get_platform_dev) from [<c03cc6c4>] (platform_drv_probe+0x18/0x48) [ 11.277968] [<c03cc6c4>] (platform_drv_probe) from [<c03ca8cc>] (really_probe+0x80/0x208) [ 11.286516] [<c03ca8cc>] (really_probe) from [<c03cab64>] (driver_probe_device+0x30/0x48) [ 11.295071] [<c03cab64>] (driver_probe_device) from [<c03cac08>] (__driver_attach+0x8c/0x90) [ 11.303881] [<c03cac08>] (__driver_attach) from [<c03c92dc>] (bus_for_each_dev+0x54/0x88) [ 11.312422] [<c03c92dc>] (bus_for_each_dev) from [<c03ca1b8>] (bus_add_driver+0xe4/0x1d8) [ 11.320957] [<c03ca1b8>] (bus_add_driver) from [<c03cb264>] (driver_register+0x78/0xf4) [ 11.329323] [<c03cb264>] (driver_register) from [<c0008788>] (do_one_initcall+0x44/0x174) [ 11.337876] [<c0008788>] (do_one_initcall) from [<c07137b4>] (do_init_module+0x48/0x17c) [ 11.346331] [<c07137b4>] (do_init_module) from [<c00bad0c>] (SyS_init_module+0x64/0x6c) [ 11.354690] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] (ret_fast_syscall+0x0/0x30) While using FBDEV I have the following issue: root@cm-debian:~# modprobe omapfb [ 27.524419] ------------[ cut here ]------------ [ 27.529256] WARNING: CPU: 1 PID: 2087 at /home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492 __alloc_pages_nodemask+0x268/0x83c() [ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2 connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp rtc_palmas spi_omap2_mcspi [ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W 3.14.0-rc4-cm-t54-test-suit+ #108 [ 27.572677] [<c00280ac>] (unwind_backtrace) from [<c0024eb0>] (show_stack+0x10/0x14) [ 27.580786] [<c0024eb0>] (show_stack) from [<c06fc434>] (dump_stack+0x70/0x88) [ 27.588341] [<c06fc434>] (dump_stack) from [<c004d8e8>] (warn_slowpath_common+0x70/0x88) [ 27.596815] [<c004d8e8>] (warn_slowpath_common) from [<c004d91c>] (warn_slowpath_null+0x1c/0x24) [ 27.606004] [<c004d91c>] (warn_slowpath_null) from [<c01135ec>] (__alloc_pages_nodemask+0x268/0x83c) [ 27.615562] [<c01135ec>] (__alloc_pages_nodemask) from [<c002cd78>] (__dma_alloc_buffer.isra.16+0x2c/0xdc) [ 27.625661] [<c002cd78>] (__dma_alloc_buffer.isra.16) from [<c002ce40>] (__alloc_remap_buffer.isra.19+0x18/0xcc) [ 27.636300] [<c002ce40>] (__alloc_remap_buffer.isra.19) from [<c002d248>] (__dma_alloc+0x110/0x138) [ 27.645757] [<c002d248>] (__dma_alloc) from [<c002d3fc>] (arm_dma_alloc+0xb0/0xd8) [ 27.653686] [<c002d3fc>] (arm_dma_alloc) from [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb]) [ 27.663911] [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24 [omapfb]) from [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb]) [ 27.676759] [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25 [omapfb]) from [<bf1b21fc>] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb]) [ 27.689419] [<bf1b21fc>] (omapfb_allocate_all_fbs [omapfb]) from [<bf1b30f8>] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb]) [ 27.701432] [<bf1b30f8>] (omapfb_create_framebuffers [omapfb]) from [<bf1b3fdc>] (omapfb_probe+0x28c/0x41c [omapfb]) [ 27.712446] [<bf1b3fdc>] (omapfb_probe [omapfb]) from [<c03ab844>] (platform_drv_probe+0x18/0x48) [ 27.721728] [<c03ab844>] (platform_drv_probe) from [<c03a9a4c>] (really_probe+0x80/0x208) [ 27.730284] [<c03a9a4c>] (really_probe) from [<c03a9ce4>] (driver_probe_device+0x30/0x48) [ 27.738834] [<c03a9ce4>] (driver_probe_device) from [<c03a9d88>] (__driver_attach+0x8c/0x90) [ 27.747661] [<c03a9d88>] (__driver_attach) from [<c03a845c>] (bus_for_each_dev+0x54/0x88) [ 27.756220] [<c03a845c>] (bus_for_each_dev) from [<c03a9338>] (bus_add_driver+0xe4/0x1d8) [ 27.764778] [<c03a9338>] (bus_add_driver) from [<c03aa3e4>] (driver_register+0x78/0xf4) [ 27.773148] [<c03aa3e4>] (driver_register) from [<c0008788>] (do_one_initcall+0x44/0x174) [ 27.781703] [<c0008788>] (do_one_initcall) from [<c06f2934>] (do_init_module+0x48/0x17c) [ 27.790172] [<c06f2934>] (do_init_module) from [<c00bad0c>] (SyS_init_module+0x64/0x6c) [ 27.798546] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] (ret_fast_syscall+0x0/0x30) [ 27.807015] ---[ end trace 842d286115ab739d ]--- [ 27.811849] omapfb omapfb: failed to allocate framebuffer [ 27.817490] omapfb omapfb: failed to allocate fbmem [ 27.822746] omapfb omapfb: failed to setup omapfb [ 27.827710] omapfb: probe of omapfb failed with error -12 Regards, Dmitry On 03/18/2014 07:29 AM, Tomi Valkeinen wrote: > On 17/03/14 16:22, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> Unfortunately, I have a lack of experience with DT DSS stuff. >> >> How should I define the endpoints and the connector in my case? >> Please, could you provide some reference. > See Documentation/devicetree/bindings/media/video-interfaces.txt for a > description of the ports and endpoints. > > If your board is similar to uevm except you don't have the tpd12s015, > then you just need to remove the tpd12s015 from the .dts file, and > connect the OMAP's HDMI output directly to the connector. > >> Regarding omapfb, is it sufficient to turn it on in the Kernel config? > Yes. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-18 8:19 ` Dmitry Lifshitz 0 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-18 8:19 UTC (permalink / raw) To: linux-arm-kernel Hi Tomi, Thank you a lot for your assistance. Here are my relevant DT nodes: / { aliases { display0 = &hdmi0; }; hdmi0: connector at 0 { compatible = "hdmi-connector"; label = "hdmi"; type = "b"; hdmi_connector_in: endpoint { remote-endpoint = <&hdmi_out>; }; }; }; &dss { status = "ok"; }; &hdmi { status = "ok"; vdda-supply = <&ldo4_reg>; pinctrl-names = "default"; pinctrl-0 = <&dss_hdmi_pins>; hdmi_out: endpoint { remote-endpoint = <&hdmi_connector_in>; }; }; I have the following kernel crash (caused by missing .detect callback): [ 10.885320] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 10.893825] pgd = ed787240 [ 10.896670] [00000000] *pgd=00000000 [ 10.900427] Internal error: Oops: 80000205 [#1] SMP ARM [ 10.905883] Modules linked in: phy_omap_usb2 omapdrm(+) drm_kms_helper connector_hdmi omap4_keypad matrix_keymap omapdss fb_sys_fops omap_ocp2scp rtc_palmas spi_omap2_mcspi [ 10.922032] CPU: 1 PID: 333 Comm: modprobe Tainted: G W 3.14.0-rc4-cm-t54-test-suit+ #111 [ 10.931486] task: ece1e040 ti: ecea2000 task.ti: ecea2000 [ 10.937122] PC is at 0x0 [ 10.939771] LR is at hdmic_detect+0x14/0x18 [connector_hdmi] [ 10.945681] pc : [<00000000>] lr : [<bf1531c4>] psr: a0000013 [ 10.945681] sp : ecea3d50 ip : bf173158 fp : 00000000 [ 10.957664] r10: 00000800 r9 : 00000800 r8 : 00000004 [ 10.963118] r7 : bf17317c r6 : ecdf0400 r5 : ed6d4000 r4 : ed6d402c [ 10.969932] r3 : 00000000 r2 : bf15c7cc r1 : bf0437d0 r0 : bf059470 [ 10.976754] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 10.984207] Control: 30c5387d Table: ad787240 DAC: 55555555 [ 10.990209] Process modprobe (pid: 333, stack limit = 0xecea2248) [ 10.996574] Stack: (0xecea3d50 to 0xecea4000) [ 11.001123] 3d40: bf1531b0 bf16a134 bf16a118 bf158abc [ 11.009664] 3d60: 00000004 c0b5ae60 00000000 00000001 ece4ae00 00000000 00000800 00000800 [ 11.018203] 3d80: bf17a000 00000020 00000000 bf15b7b8 00000020 ece4ae00 ece4ae00 ecdf0400 [ 11.026751] 3da0: ed69b940 bf175978 00000000 bf16bfa4 0000081f ecdf0400 ed69b940 00000000 [ 11.035288] 3dc0: 00000000 bf167bbc 00000000 00000000 00000000 ecdf0400 00000000 00000000 [ 11.043828] 3de0: 00000000 c03afef8 c0a876a0 bf17586c ecdf0400 c03b179c c08dffd4 c01d641c [ 11.052365] 3e00: c03b1818 c0978eac c0a876b0 bf175978 c0a876b0 c03cc6c4 c03cc6ac c0b5af2c [ 11.060902] 3e20: bf175978 c03ca8cc c0a876b0 bf175978 c0a876e4 00000000 c0020f04 c03cab64 [ 11.069442] 3e40: 00000000 c0a876b0 bf175978 c03cac08 bf175978 00000000 c03cab7c c03c92dc [ 11.077983] 3e60: edcd45dc eddcb234 bf175978 ece13480 c0ab8d48 c03ca1b8 bf1740d4 c0020f04 [ 11.086524] 3e80: bf175978 bf175978 00000000 ecea2000 00000000 c03cb264 c03cbd54 c0a7e510 [ 11.095067] 3ea0: ecea2000 c0008788 000000d0 f02aefff 00000000 c0158bc0 c0003020 f02af000 [ 11.103608] 3ec0: 00000000 bf175b24 c0a93b14 00000000 00000001 bf175b24 00000000 00000000 [ 11.112156] 3ee0: 00000001 c00dc9ec c00dcdbc fffffffb 00000000 c072932c c0a92348 00000000 [ 11.120702] 3f00: c0a92348 00000000 bf175b24 c0072830 00000000 bd94362e 00000000 bf175b24 [ 11.129244] 3f20: 00400100 ecea2000 00000080 c0020f04 ecea2000 00000000 00000000 c07137b4 [ 11.137785] 3f40: 0001dfea b6d5b000 b6fa7114 0001dfea b6d5b000 c00bad0c f0290000 0001dfea [ 11.146323] 3f60: f02a29bc f02a2821 f02ab674 0000ecf0 00010510 00000000 00000000 00000000 [ 11.154860] 3f80: 00000027 00000028 0000001c 00000020 00000012 00000000 b87d23f8 00060000 [ 11.163409] 3fa0: b87d2280 c0020d80 b87d23f8 00060000 b6d5b000 0001dfea b6fa7114 b6d5b000 [ 11.171954] 3fc0: b87d23f8 00060000 b87d2280 00000080 b87d4c60 0001dfea b6fa7114 00000000 [ 11.180494] 3fe0: 00000000 bee169cc b6f9e190 b6f02e04 60000010 b6d5b000 00000000 00000000 [ 11.189071] [<bf1531c4>] (hdmic_detect [connector_hdmi]) from [<bf16a134>] (omap_connector_detect+0x1c/0x58 [omapdrm]) [ 11.200274] [<bf16a134>] (omap_connector_detect [omapdrm]) from [<bf158abc>] (drm_helper_probe_single_connector_modes+0x2b0/0x33c [drm_kms_helper]) [ 11.214089] [<bf158abc>] (drm_helper_probe_single_connector_modes [drm_kms_helper]) from [<bf15b7b8>] (drm_fb_helper_initial_config+0x5c/0xac [drm_kms_helper]) [ 11.229011] [<bf15b7b8>] (drm_fb_helper_initial_config [drm_kms_helper]) from [<bf16bfa4>] (omap_fbdev_init+0x90/0xc4 [omapdrm]) [ 11.241126] [<bf16bfa4>] (omap_fbdev_init [omapdrm]) from [<bf167bbc>] (dev_load+0xcc/0x148 [omapdrm]) [ 11.250861] [<bf167bbc>] (dev_load [omapdrm]) from [<c03afef8>] (drm_dev_register+0x78/0x138) [ 11.259776] [<c03afef8>] (drm_dev_register) from [<c03b179c>] (drm_get_platform_dev+0x50/0xa4) [ 11.268785] [<c03b179c>] (drm_get_platform_dev) from [<c03cc6c4>] (platform_drv_probe+0x18/0x48) [ 11.277968] [<c03cc6c4>] (platform_drv_probe) from [<c03ca8cc>] (really_probe+0x80/0x208) [ 11.286516] [<c03ca8cc>] (really_probe) from [<c03cab64>] (driver_probe_device+0x30/0x48) [ 11.295071] [<c03cab64>] (driver_probe_device) from [<c03cac08>] (__driver_attach+0x8c/0x90) [ 11.303881] [<c03cac08>] (__driver_attach) from [<c03c92dc>] (bus_for_each_dev+0x54/0x88) [ 11.312422] [<c03c92dc>] (bus_for_each_dev) from [<c03ca1b8>] (bus_add_driver+0xe4/0x1d8) [ 11.320957] [<c03ca1b8>] (bus_add_driver) from [<c03cb264>] (driver_register+0x78/0xf4) [ 11.329323] [<c03cb264>] (driver_register) from [<c0008788>] (do_one_initcall+0x44/0x174) [ 11.337876] [<c0008788>] (do_one_initcall) from [<c07137b4>] (do_init_module+0x48/0x17c) [ 11.346331] [<c07137b4>] (do_init_module) from [<c00bad0c>] (SyS_init_module+0x64/0x6c) [ 11.354690] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] (ret_fast_syscall+0x0/0x30) While using FBDEV I have the following issue: root at cm-debian:~# modprobe omapfb [ 27.524419] ------------[ cut here ]------------ [ 27.529256] WARNING: CPU: 1 PID: 2087 at /home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492 __alloc_pages_nodemask+0x268/0x83c() [ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2 connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp rtc_palmas spi_omap2_mcspi [ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W 3.14.0-rc4-cm-t54-test-suit+ #108 [ 27.572677] [<c00280ac>] (unwind_backtrace) from [<c0024eb0>] (show_stack+0x10/0x14) [ 27.580786] [<c0024eb0>] (show_stack) from [<c06fc434>] (dump_stack+0x70/0x88) [ 27.588341] [<c06fc434>] (dump_stack) from [<c004d8e8>] (warn_slowpath_common+0x70/0x88) [ 27.596815] [<c004d8e8>] (warn_slowpath_common) from [<c004d91c>] (warn_slowpath_null+0x1c/0x24) [ 27.606004] [<c004d91c>] (warn_slowpath_null) from [<c01135ec>] (__alloc_pages_nodemask+0x268/0x83c) [ 27.615562] [<c01135ec>] (__alloc_pages_nodemask) from [<c002cd78>] (__dma_alloc_buffer.isra.16+0x2c/0xdc) [ 27.625661] [<c002cd78>] (__dma_alloc_buffer.isra.16) from [<c002ce40>] (__alloc_remap_buffer.isra.19+0x18/0xcc) [ 27.636300] [<c002ce40>] (__alloc_remap_buffer.isra.19) from [<c002d248>] (__dma_alloc+0x110/0x138) [ 27.645757] [<c002d248>] (__dma_alloc) from [<c002d3fc>] (arm_dma_alloc+0xb0/0xd8) [ 27.653686] [<c002d3fc>] (arm_dma_alloc) from [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb]) [ 27.663911] [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24 [omapfb]) from [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb]) [ 27.676759] [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25 [omapfb]) from [<bf1b21fc>] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb]) [ 27.689419] [<bf1b21fc>] (omapfb_allocate_all_fbs [omapfb]) from [<bf1b30f8>] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb]) [ 27.701432] [<bf1b30f8>] (omapfb_create_framebuffers [omapfb]) from [<bf1b3fdc>] (omapfb_probe+0x28c/0x41c [omapfb]) [ 27.712446] [<bf1b3fdc>] (omapfb_probe [omapfb]) from [<c03ab844>] (platform_drv_probe+0x18/0x48) [ 27.721728] [<c03ab844>] (platform_drv_probe) from [<c03a9a4c>] (really_probe+0x80/0x208) [ 27.730284] [<c03a9a4c>] (really_probe) from [<c03a9ce4>] (driver_probe_device+0x30/0x48) [ 27.738834] [<c03a9ce4>] (driver_probe_device) from [<c03a9d88>] (__driver_attach+0x8c/0x90) [ 27.747661] [<c03a9d88>] (__driver_attach) from [<c03a845c>] (bus_for_each_dev+0x54/0x88) [ 27.756220] [<c03a845c>] (bus_for_each_dev) from [<c03a9338>] (bus_add_driver+0xe4/0x1d8) [ 27.764778] [<c03a9338>] (bus_add_driver) from [<c03aa3e4>] (driver_register+0x78/0xf4) [ 27.773148] [<c03aa3e4>] (driver_register) from [<c0008788>] (do_one_initcall+0x44/0x174) [ 27.781703] [<c0008788>] (do_one_initcall) from [<c06f2934>] (do_init_module+0x48/0x17c) [ 27.790172] [<c06f2934>] (do_init_module) from [<c00bad0c>] (SyS_init_module+0x64/0x6c) [ 27.798546] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] (ret_fast_syscall+0x0/0x30) [ 27.807015] ---[ end trace 842d286115ab739d ]--- [ 27.811849] omapfb omapfb: failed to allocate framebuffer [ 27.817490] omapfb omapfb: failed to allocate fbmem [ 27.822746] omapfb omapfb: failed to setup omapfb [ 27.827710] omapfb: probe of omapfb failed with error -12 Regards, Dmitry On 03/18/2014 07:29 AM, Tomi Valkeinen wrote: > On 17/03/14 16:22, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> Unfortunately, I have a lack of experience with DT DSS stuff. >> >> How should I define the endpoints and the connector in my case? >> Please, could you provide some reference. > See Documentation/devicetree/bindings/media/video-interfaces.txt for a > description of the ports and endpoints. > > If your board is similar to uevm except you don't have the tpd12s015, > then you just need to remove the tpd12s015 from the .dts file, and > connect the OMAP's HDMI output directly to the connector. > >> Regarding omapfb, is it sufficient to turn it on in the Kernel config? > Yes. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-18 8:19 ` Dmitry Lifshitz @ 2014-03-18 8:37 ` Tomi Valkeinen -1 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-18 8:37 UTC (permalink / raw) To: Dmitry Lifshitz Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 5151 bytes --] On 18/03/14 10:19, Dmitry Lifshitz wrote: > Hi Tomi, > > Thank you a lot for your assistance. > > Here are my relevant DT nodes: > > / { > aliases { > display0 = &hdmi0; > }; > > hdmi0: connector@0 { > compatible = "hdmi-connector"; > label = "hdmi"; > > type = "b"; > > hdmi_connector_in: endpoint { > remote-endpoint = <&hdmi_out>; > }; > }; > }; > > &dss { > status = "ok"; > }; > > &hdmi { > status = "ok"; > vdda-supply = <&ldo4_reg>; > > pinctrl-names = "default"; > pinctrl-0 = <&dss_hdmi_pins>; > > hdmi_out: endpoint { > remote-endpoint = <&hdmi_connector_in>; > }; > }; The above looks fine. > I have the following kernel crash (caused by missing .detect callback): Yes, it seems the hdmi driver is missing detect, as there's no support in there for the detection at the moment. You can add the function to omap5.c, and return true always. How does the HPD work on your board? On uevm, the ESD/Level shifter chip handles HPD, which is the only supported way at the moment. > While using FBDEV I have the following issue: > > root@cm-debian:~# modprobe omapfb > [ 27.524419] ------------[ cut here ]------------ > [ 27.529256] WARNING: CPU: 1 PID: 2087 at > /home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492 > __alloc_pages_nodemask+0x268/0x83c() > [ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt > cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2 > connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp > rtc_palmas spi_omap2_mcspi > [ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W > 3.14.0-rc4-cm-t54-test-suit+ #108 > [ 27.572677] [<c00280ac>] (unwind_backtrace) from [<c0024eb0>] > (show_stack+0x10/0x14) > [ 27.580786] [<c0024eb0>] (show_stack) from [<c06fc434>] > (dump_stack+0x70/0x88) > [ 27.588341] [<c06fc434>] (dump_stack) from [<c004d8e8>] > (warn_slowpath_common+0x70/0x88) > [ 27.596815] [<c004d8e8>] (warn_slowpath_common) from [<c004d91c>] > (warn_slowpath_null+0x1c/0x24) > [ 27.606004] [<c004d91c>] (warn_slowpath_null) from [<c01135ec>] > (__alloc_pages_nodemask+0x268/0x83c) > [ 27.615562] [<c01135ec>] (__alloc_pages_nodemask) from [<c002cd78>] > (__dma_alloc_buffer.isra.16+0x2c/0xdc) > [ 27.625661] [<c002cd78>] (__dma_alloc_buffer.isra.16) from > [<c002ce40>] (__alloc_remap_buffer.isra.19+0x18/0xcc) > [ 27.636300] [<c002ce40>] (__alloc_remap_buffer.isra.19) from > [<c002d248>] (__dma_alloc+0x110/0x138) > [ 27.645757] [<c002d248>] (__dma_alloc) from [<c002d3fc>] > (arm_dma_alloc+0xb0/0xd8) > [ 27.653686] [<c002d3fc>] (arm_dma_alloc) from [<bf1b1f74>] > (omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb]) > [ 27.663911] [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24 [omapfb]) from > [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb]) > [ 27.676759] [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25 > [omapfb]) from [<bf1b21fc>] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb]) > [ 27.689419] [<bf1b21fc>] (omapfb_allocate_all_fbs [omapfb]) from > [<bf1b30f8>] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb]) > [ 27.701432] [<bf1b30f8>] (omapfb_create_framebuffers [omapfb]) from > [<bf1b3fdc>] (omapfb_probe+0x28c/0x41c [omapfb]) > [ 27.712446] [<bf1b3fdc>] (omapfb_probe [omapfb]) from [<c03ab844>] > (platform_drv_probe+0x18/0x48) > [ 27.721728] [<c03ab844>] (platform_drv_probe) from [<c03a9a4c>] > (really_probe+0x80/0x208) > [ 27.730284] [<c03a9a4c>] (really_probe) from [<c03a9ce4>] > (driver_probe_device+0x30/0x48) > [ 27.738834] [<c03a9ce4>] (driver_probe_device) from [<c03a9d88>] > (__driver_attach+0x8c/0x90) > [ 27.747661] [<c03a9d88>] (__driver_attach) from [<c03a845c>] > (bus_for_each_dev+0x54/0x88) > [ 27.756220] [<c03a845c>] (bus_for_each_dev) from [<c03a9338>] > (bus_add_driver+0xe4/0x1d8) > [ 27.764778] [<c03a9338>] (bus_add_driver) from [<c03aa3e4>] > (driver_register+0x78/0xf4) > [ 27.773148] [<c03aa3e4>] (driver_register) from [<c0008788>] > (do_one_initcall+0x44/0x174) > [ 27.781703] [<c0008788>] (do_one_initcall) from [<c06f2934>] > (do_init_module+0x48/0x17c) > [ 27.790172] [<c06f2934>] (do_init_module) from [<c00bad0c>] > (SyS_init_module+0x64/0x6c) > [ 27.798546] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] > (ret_fast_syscall+0x0/0x30) > [ 27.807015] ---[ end trace 842d286115ab739d ]--- > [ 27.811849] omapfb omapfb: failed to allocate framebuffer > [ 27.817490] omapfb omapfb: failed to allocate fbmem > [ 27.822746] omapfb omapfb: failed to setup omapfb > [ 27.827710] omapfb: probe of omapfb failed with error -12 Hmm, do you have CMA enabled? Maybe something like: CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=32 CONFIG_CMA_SIZE_SEL_MBYTES=y And if you have omap5-uevm, you could first try that one to see if you get the branch working. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 901 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-18 8:37 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-03-18 8:37 UTC (permalink / raw) To: linux-arm-kernel On 18/03/14 10:19, Dmitry Lifshitz wrote: > Hi Tomi, > > Thank you a lot for your assistance. > > Here are my relevant DT nodes: > > / { > aliases { > display0 = &hdmi0; > }; > > hdmi0: connector at 0 { > compatible = "hdmi-connector"; > label = "hdmi"; > > type = "b"; > > hdmi_connector_in: endpoint { > remote-endpoint = <&hdmi_out>; > }; > }; > }; > > &dss { > status = "ok"; > }; > > &hdmi { > status = "ok"; > vdda-supply = <&ldo4_reg>; > > pinctrl-names = "default"; > pinctrl-0 = <&dss_hdmi_pins>; > > hdmi_out: endpoint { > remote-endpoint = <&hdmi_connector_in>; > }; > }; The above looks fine. > I have the following kernel crash (caused by missing .detect callback): Yes, it seems the hdmi driver is missing detect, as there's no support in there for the detection at the moment. You can add the function to omap5.c, and return true always. How does the HPD work on your board? On uevm, the ESD/Level shifter chip handles HPD, which is the only supported way at the moment. > While using FBDEV I have the following issue: > > root at cm-debian:~# modprobe omapfb > [ 27.524419] ------------[ cut here ]------------ > [ 27.529256] WARNING: CPU: 1 PID: 2087 at > /home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492 > __alloc_pages_nodemask+0x268/0x83c() > [ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt > cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2 > connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp > rtc_palmas spi_omap2_mcspi > [ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W > 3.14.0-rc4-cm-t54-test-suit+ #108 > [ 27.572677] [<c00280ac>] (unwind_backtrace) from [<c0024eb0>] > (show_stack+0x10/0x14) > [ 27.580786] [<c0024eb0>] (show_stack) from [<c06fc434>] > (dump_stack+0x70/0x88) > [ 27.588341] [<c06fc434>] (dump_stack) from [<c004d8e8>] > (warn_slowpath_common+0x70/0x88) > [ 27.596815] [<c004d8e8>] (warn_slowpath_common) from [<c004d91c>] > (warn_slowpath_null+0x1c/0x24) > [ 27.606004] [<c004d91c>] (warn_slowpath_null) from [<c01135ec>] > (__alloc_pages_nodemask+0x268/0x83c) > [ 27.615562] [<c01135ec>] (__alloc_pages_nodemask) from [<c002cd78>] > (__dma_alloc_buffer.isra.16+0x2c/0xdc) > [ 27.625661] [<c002cd78>] (__dma_alloc_buffer.isra.16) from > [<c002ce40>] (__alloc_remap_buffer.isra.19+0x18/0xcc) > [ 27.636300] [<c002ce40>] (__alloc_remap_buffer.isra.19) from > [<c002d248>] (__dma_alloc+0x110/0x138) > [ 27.645757] [<c002d248>] (__dma_alloc) from [<c002d3fc>] > (arm_dma_alloc+0xb0/0xd8) > [ 27.653686] [<c002d3fc>] (arm_dma_alloc) from [<bf1b1f74>] > (omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb]) > [ 27.663911] [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24 [omapfb]) from > [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb]) > [ 27.676759] [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25 > [omapfb]) from [<bf1b21fc>] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb]) > [ 27.689419] [<bf1b21fc>] (omapfb_allocate_all_fbs [omapfb]) from > [<bf1b30f8>] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb]) > [ 27.701432] [<bf1b30f8>] (omapfb_create_framebuffers [omapfb]) from > [<bf1b3fdc>] (omapfb_probe+0x28c/0x41c [omapfb]) > [ 27.712446] [<bf1b3fdc>] (omapfb_probe [omapfb]) from [<c03ab844>] > (platform_drv_probe+0x18/0x48) > [ 27.721728] [<c03ab844>] (platform_drv_probe) from [<c03a9a4c>] > (really_probe+0x80/0x208) > [ 27.730284] [<c03a9a4c>] (really_probe) from [<c03a9ce4>] > (driver_probe_device+0x30/0x48) > [ 27.738834] [<c03a9ce4>] (driver_probe_device) from [<c03a9d88>] > (__driver_attach+0x8c/0x90) > [ 27.747661] [<c03a9d88>] (__driver_attach) from [<c03a845c>] > (bus_for_each_dev+0x54/0x88) > [ 27.756220] [<c03a845c>] (bus_for_each_dev) from [<c03a9338>] > (bus_add_driver+0xe4/0x1d8) > [ 27.764778] [<c03a9338>] (bus_add_driver) from [<c03aa3e4>] > (driver_register+0x78/0xf4) > [ 27.773148] [<c03aa3e4>] (driver_register) from [<c0008788>] > (do_one_initcall+0x44/0x174) > [ 27.781703] [<c0008788>] (do_one_initcall) from [<c06f2934>] > (do_init_module+0x48/0x17c) > [ 27.790172] [<c06f2934>] (do_init_module) from [<c00bad0c>] > (SyS_init_module+0x64/0x6c) > [ 27.798546] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] > (ret_fast_syscall+0x0/0x30) > [ 27.807015] ---[ end trace 842d286115ab739d ]--- > [ 27.811849] omapfb omapfb: failed to allocate framebuffer > [ 27.817490] omapfb omapfb: failed to allocate fbmem > [ 27.822746] omapfb omapfb: failed to setup omapfb > [ 27.827710] omapfb: probe of omapfb failed with error -12 Hmm, do you have CMA enabled? Maybe something like: CONFIG_DMA_CMA=y CONFIG_CMA_SIZE_MBYTES=32 CONFIG_CMA_SIZE_SEL_MBYTES=y And if you have omap5-uevm, you could first try that one to see if you get the branch working. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140318/f7e2f86c/attachment.sig> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-18 8:37 ` Tomi Valkeinen @ 2014-03-18 12:23 ` Dmitry Lifshitz -1 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-18 12:23 UTC (permalink / raw) To: Tomi Valkeinen Cc: Tony Lindgren, Paul Walmsley, Benoît Cousson, Archit Taneja, linux-omap, linux-arm-kernel Hi Tomi, I've activated HDMI output with omapfb. Thank you very much ! Some minor issue are observed: * the colors are inverted. * DRM seems to be loaded with no failures, however there is no output. HPD connector pin is connected to HDMI_HPD/GPIO7_193. In addition we have DVI output (uses TFP410 encoder to convert DPI to DVI). TFP410 is not connected to I2C and its PD always on. I tried to turn DVI support using omap4-panda-common.dtsi as the reference (with OMAP5 specific pinmux, of course), however it fails. Does it supposed to work? Please, could you share the .config you are using with uEvm? Thank you in advance, Dmitry On 03/18/2014 10:37 AM, Tomi Valkeinen wrote: > On 18/03/14 10:19, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> Thank you a lot for your assistance. >> >> Here are my relevant DT nodes: >> >> / { >> aliases { >> display0 = &hdmi0; >> }; >> >> hdmi0: connector@0 { >> compatible = "hdmi-connector"; >> label = "hdmi"; >> >> type = "b"; >> >> hdmi_connector_in: endpoint { >> remote-endpoint = <&hdmi_out>; >> }; >> }; >> }; >> >> &dss { >> status = "ok"; >> }; >> >> &hdmi { >> status = "ok"; >> vdda-supply = <&ldo4_reg>; >> >> pinctrl-names = "default"; >> pinctrl-0 = <&dss_hdmi_pins>; >> >> hdmi_out: endpoint { >> remote-endpoint = <&hdmi_connector_in>; >> }; >> }; > The above looks fine. > >> I have the following kernel crash (caused by missing .detect callback): > Yes, it seems the hdmi driver is missing detect, as there's no support > in there for the detection at the moment. You can add the function to > omap5.c, and return true always. > > How does the HPD work on your board? On uevm, the ESD/Level shifter chip > handles HPD, which is the only supported way at the moment. > >> While using FBDEV I have the following issue: >> >> root@cm-debian:~# modprobe omapfb >> [ 27.524419] ------------[ cut here ]------------ >> [ 27.529256] WARNING: CPU: 1 PID: 2087 at >> /home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492 >> __alloc_pages_nodemask+0x268/0x83c() >> [ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt >> cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2 >> connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp >> rtc_palmas spi_omap2_mcspi >> [ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W >> 3.14.0-rc4-cm-t54-test-suit+ #108 >> [ 27.572677] [<c00280ac>] (unwind_backtrace) from [<c0024eb0>] >> (show_stack+0x10/0x14) >> [ 27.580786] [<c0024eb0>] (show_stack) from [<c06fc434>] >> (dump_stack+0x70/0x88) >> [ 27.588341] [<c06fc434>] (dump_stack) from [<c004d8e8>] >> (warn_slowpath_common+0x70/0x88) >> [ 27.596815] [<c004d8e8>] (warn_slowpath_common) from [<c004d91c>] >> (warn_slowpath_null+0x1c/0x24) >> [ 27.606004] [<c004d91c>] (warn_slowpath_null) from [<c01135ec>] >> (__alloc_pages_nodemask+0x268/0x83c) >> [ 27.615562] [<c01135ec>] (__alloc_pages_nodemask) from [<c002cd78>] >> (__dma_alloc_buffer.isra.16+0x2c/0xdc) >> [ 27.625661] [<c002cd78>] (__dma_alloc_buffer.isra.16) from >> [<c002ce40>] (__alloc_remap_buffer.isra.19+0x18/0xcc) >> [ 27.636300] [<c002ce40>] (__alloc_remap_buffer.isra.19) from >> [<c002d248>] (__dma_alloc+0x110/0x138) >> [ 27.645757] [<c002d248>] (__dma_alloc) from [<c002d3fc>] >> (arm_dma_alloc+0xb0/0xd8) >> [ 27.653686] [<c002d3fc>] (arm_dma_alloc) from [<bf1b1f74>] >> (omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb]) >> [ 27.663911] [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24 [omapfb]) from >> [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb]) >> [ 27.676759] [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25 >> [omapfb]) from [<bf1b21fc>] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb]) >> [ 27.689419] [<bf1b21fc>] (omapfb_allocate_all_fbs [omapfb]) from >> [<bf1b30f8>] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb]) >> [ 27.701432] [<bf1b30f8>] (omapfb_create_framebuffers [omapfb]) from >> [<bf1b3fdc>] (omapfb_probe+0x28c/0x41c [omapfb]) >> [ 27.712446] [<bf1b3fdc>] (omapfb_probe [omapfb]) from [<c03ab844>] >> (platform_drv_probe+0x18/0x48) >> [ 27.721728] [<c03ab844>] (platform_drv_probe) from [<c03a9a4c>] >> (really_probe+0x80/0x208) >> [ 27.730284] [<c03a9a4c>] (really_probe) from [<c03a9ce4>] >> (driver_probe_device+0x30/0x48) >> [ 27.738834] [<c03a9ce4>] (driver_probe_device) from [<c03a9d88>] >> (__driver_attach+0x8c/0x90) >> [ 27.747661] [<c03a9d88>] (__driver_attach) from [<c03a845c>] >> (bus_for_each_dev+0x54/0x88) >> [ 27.756220] [<c03a845c>] (bus_for_each_dev) from [<c03a9338>] >> (bus_add_driver+0xe4/0x1d8) >> [ 27.764778] [<c03a9338>] (bus_add_driver) from [<c03aa3e4>] >> (driver_register+0x78/0xf4) >> [ 27.773148] [<c03aa3e4>] (driver_register) from [<c0008788>] >> (do_one_initcall+0x44/0x174) >> [ 27.781703] [<c0008788>] (do_one_initcall) from [<c06f2934>] >> (do_init_module+0x48/0x17c) >> [ 27.790172] [<c06f2934>] (do_init_module) from [<c00bad0c>] >> (SyS_init_module+0x64/0x6c) >> [ 27.798546] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] >> (ret_fast_syscall+0x0/0x30) >> [ 27.807015] ---[ end trace 842d286115ab739d ]--- >> [ 27.811849] omapfb omapfb: failed to allocate framebuffer >> [ 27.817490] omapfb omapfb: failed to allocate fbmem >> [ 27.822746] omapfb omapfb: failed to setup omapfb >> [ 27.827710] omapfb: probe of omapfb failed with error -12 > Hmm, do you have CMA enabled? Maybe something like: > > CONFIG_DMA_CMA=y > CONFIG_CMA_SIZE_MBYTES=32 > CONFIG_CMA_SIZE_SEL_MBYTES=y > > And if you have omap5-uevm, you could first try that one to see if you > get the branch working. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-03-18 12:23 ` Dmitry Lifshitz 0 siblings, 0 replies; 43+ messages in thread From: Dmitry Lifshitz @ 2014-03-18 12:23 UTC (permalink / raw) To: linux-arm-kernel Hi Tomi, I've activated HDMI output with omapfb. Thank you very much ! Some minor issue are observed: * the colors are inverted. * DRM seems to be loaded with no failures, however there is no output. HPD connector pin is connected to HDMI_HPD/GPIO7_193. In addition we have DVI output (uses TFP410 encoder to convert DPI to DVI). TFP410 is not connected to I2C and its PD always on. I tried to turn DVI support using omap4-panda-common.dtsi as the reference (with OMAP5 specific pinmux, of course), however it fails. Does it supposed to work? Please, could you share the .config you are using with uEvm? Thank you in advance, Dmitry On 03/18/2014 10:37 AM, Tomi Valkeinen wrote: > On 18/03/14 10:19, Dmitry Lifshitz wrote: >> Hi Tomi, >> >> Thank you a lot for your assistance. >> >> Here are my relevant DT nodes: >> >> / { >> aliases { >> display0 = &hdmi0; >> }; >> >> hdmi0: connector at 0 { >> compatible = "hdmi-connector"; >> label = "hdmi"; >> >> type = "b"; >> >> hdmi_connector_in: endpoint { >> remote-endpoint = <&hdmi_out>; >> }; >> }; >> }; >> >> &dss { >> status = "ok"; >> }; >> >> &hdmi { >> status = "ok"; >> vdda-supply = <&ldo4_reg>; >> >> pinctrl-names = "default"; >> pinctrl-0 = <&dss_hdmi_pins>; >> >> hdmi_out: endpoint { >> remote-endpoint = <&hdmi_connector_in>; >> }; >> }; > The above looks fine. > >> I have the following kernel crash (caused by missing .detect callback): > Yes, it seems the hdmi driver is missing detect, as there's no support > in there for the detection at the moment. You can add the function to > omap5.c, and return true always. > > How does the HPD work on your board? On uevm, the ESD/Level shifter chip > handles HPD, which is the only supported way at the moment. > >> While using FBDEV I have the following issue: >> >> root at cm-debian:~# modprobe omapfb >> [ 27.524419] ------------[ cut here ]------------ >> [ 27.529256] WARNING: CPU: 1 PID: 2087 at >> /home/lifshitz/workroot/OMAP5-eewiki/omap5-kernel/mm/page_alloc.c:2492 >> __alloc_pages_nodemask+0x268/0x83c() >> [ 27.543164] Modules linked in: omapfb(+) cfbcopyarea cfbimgblt >> cfbfillrect bnep rfcomm bluetooth 6lowpan_iphc phy_omap_usb2 >> connector_hdmi omapdss omap4_keypad matrix_keymap omap_ocp2scp >> rtc_palmas spi_omap2_mcspi >> [ 27.563113] CPU: 1 PID: 2087 Comm: modprobe Tainted: G W >> 3.14.0-rc4-cm-t54-test-suit+ #108 >> [ 27.572677] [<c00280ac>] (unwind_backtrace) from [<c0024eb0>] >> (show_stack+0x10/0x14) >> [ 27.580786] [<c0024eb0>] (show_stack) from [<c06fc434>] >> (dump_stack+0x70/0x88) >> [ 27.588341] [<c06fc434>] (dump_stack) from [<c004d8e8>] >> (warn_slowpath_common+0x70/0x88) >> [ 27.596815] [<c004d8e8>] (warn_slowpath_common) from [<c004d91c>] >> (warn_slowpath_null+0x1c/0x24) >> [ 27.606004] [<c004d91c>] (warn_slowpath_null) from [<c01135ec>] >> (__alloc_pages_nodemask+0x268/0x83c) >> [ 27.615562] [<c01135ec>] (__alloc_pages_nodemask) from [<c002cd78>] >> (__dma_alloc_buffer.isra.16+0x2c/0xdc) >> [ 27.625661] [<c002cd78>] (__dma_alloc_buffer.isra.16) from >> [<c002ce40>] (__alloc_remap_buffer.isra.19+0x18/0xcc) >> [ 27.636300] [<c002ce40>] (__alloc_remap_buffer.isra.19) from >> [<c002d248>] (__dma_alloc+0x110/0x138) >> [ 27.645757] [<c002d248>] (__dma_alloc) from [<c002d3fc>] >> (arm_dma_alloc+0xb0/0xd8) >> [ 27.653686] [<c002d3fc>] (arm_dma_alloc) from [<bf1b1f74>] >> (omapfb_alloc_fbmem.isra.24+0xc8/0x158 [omapfb]) >> [ 27.663911] [<bf1b1f74>] (omapfb_alloc_fbmem.isra.24 [omapfb]) from >> [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25+0xec/0xfc [omapfb]) >> [ 27.676759] [<bf1b7078>] (omapfb_alloc_fbmem_display.isra.25 >> [omapfb]) from [<bf1b21fc>] (omapfb_allocate_all_fbs+0xf4/0x174 [omapfb]) >> [ 27.689419] [<bf1b21fc>] (omapfb_allocate_all_fbs [omapfb]) from >> [<bf1b30f8>] (omapfb_create_framebuffers+0x1fc/0x524 [omapfb]) >> [ 27.701432] [<bf1b30f8>] (omapfb_create_framebuffers [omapfb]) from >> [<bf1b3fdc>] (omapfb_probe+0x28c/0x41c [omapfb]) >> [ 27.712446] [<bf1b3fdc>] (omapfb_probe [omapfb]) from [<c03ab844>] >> (platform_drv_probe+0x18/0x48) >> [ 27.721728] [<c03ab844>] (platform_drv_probe) from [<c03a9a4c>] >> (really_probe+0x80/0x208) >> [ 27.730284] [<c03a9a4c>] (really_probe) from [<c03a9ce4>] >> (driver_probe_device+0x30/0x48) >> [ 27.738834] [<c03a9ce4>] (driver_probe_device) from [<c03a9d88>] >> (__driver_attach+0x8c/0x90) >> [ 27.747661] [<c03a9d88>] (__driver_attach) from [<c03a845c>] >> (bus_for_each_dev+0x54/0x88) >> [ 27.756220] [<c03a845c>] (bus_for_each_dev) from [<c03a9338>] >> (bus_add_driver+0xe4/0x1d8) >> [ 27.764778] [<c03a9338>] (bus_add_driver) from [<c03aa3e4>] >> (driver_register+0x78/0xf4) >> [ 27.773148] [<c03aa3e4>] (driver_register) from [<c0008788>] >> (do_one_initcall+0x44/0x174) >> [ 27.781703] [<c0008788>] (do_one_initcall) from [<c06f2934>] >> (do_init_module+0x48/0x17c) >> [ 27.790172] [<c06f2934>] (do_init_module) from [<c00bad0c>] >> (SyS_init_module+0x64/0x6c) >> [ 27.798546] [<c00bad0c>] (SyS_init_module) from [<c0020d80>] >> (ret_fast_syscall+0x0/0x30) >> [ 27.807015] ---[ end trace 842d286115ab739d ]--- >> [ 27.811849] omapfb omapfb: failed to allocate framebuffer >> [ 27.817490] omapfb omapfb: failed to allocate fbmem >> [ 27.822746] omapfb omapfb: failed to setup omapfb >> [ 27.827710] omapfb: probe of omapfb failed with error -12 > Hmm, do you have CMA enabled? Maybe something like: > > CONFIG_DMA_CMA=y > CONFIG_CMA_SIZE_MBYTES=32 > CONFIG_CMA_SIZE_SEL_MBYTES=y > > And if you have omap5-uevm, you could first try that one to see if you > get the branch working. > > Tomi > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-03-12 10:26 ` Tomi Valkeinen @ 2014-05-08 4:37 ` Paul Walmsley -1 siblings, 0 replies; 43+ messages in thread From: Paul Walmsley @ 2014-05-08 4:37 UTC (permalink / raw) To: Tomi Valkeinen, Archit Taneja Cc: Tony Lindgren, Benoît Cousson, linux-omap, linux-arm-kernel Hi, On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > This patch adds hwmod data for omap5 display subsystem. I have tested this on > omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the > mainline is missing omap5 HDMI driver. > > I do see this when booting: > > omap_hwmod: dss_dispc: cannot be enabled for reset (3) > omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > > But at least DSI works just fine. Am looking at this for v3.16. But I think someone needs to take a look at those warnings and figure out why they are happening. Is the soc_ops.wait_target_ready() call failing in omap_hwmod.c:_enable() ? - Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-05-08 4:37 ` Paul Walmsley 0 siblings, 0 replies; 43+ messages in thread From: Paul Walmsley @ 2014-05-08 4:37 UTC (permalink / raw) To: linux-arm-kernel Hi, On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > This patch adds hwmod data for omap5 display subsystem. I have tested this on > omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the > mainline is missing omap5 HDMI driver. > > I do see this when booting: > > omap_hwmod: dss_dispc: cannot be enabled for reset (3) > omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > > But at least DSI works just fine. Am looking at this for v3.16. But I think someone needs to take a look at those warnings and figure out why they are happening. Is the soc_ops.wait_target_ready() call failing in omap_hwmod.c:_enable() ? - Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-05-08 4:37 ` Paul Walmsley @ 2014-05-08 5:48 ` Archit Taneja -1 siblings, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-05-08 5:48 UTC (permalink / raw) To: Paul Walmsley, Tomi Valkeinen Cc: Tony Lindgren, Benoît Cousson, linux-omap, linux-arm-kernel Hi Paul, On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: > Hi, > > On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > >> This patch adds hwmod data for omap5 display subsystem. I have tested this on >> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the >> mainline is missing omap5 HDMI driver. >> >> I do see this when booting: >> >> omap_hwmod: dss_dispc: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >> >> But at least DSI works just fine. > > Am looking at this for v3.16. But I think someone needs to take a look at > those warnings and figure out why they are happening. We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. The rest of the dss hwmods don't touch MODULEMODE. Therefore, these hwmods cannot be enabled independently, and reset. We don't face this issue in the omapdss driver since the platform devices corresponding to these hwmods have their parent as the platform device corresponding to 'dss_core'. This parent child-relation ensures that 'dss_core' is enabled when the a child calls a pm_runtime_get function. The problem is that we have multiple hwmods which use the same MODULEMODE bit. There is no use-counting done when it comes to enabling/disabling modulemode. If there was such a thing, we could have provided MODULEMODE flags even for the children hwmods. > > Is the soc_ops.wait_target_ready() call failing in omap_hwmod.c:_enable() > ? Yes, that's the one that fails. We have the same DSS in OMAP4, but we don't see the issue there. That's because we have modeled the MODULEMODE bits as a fake interface clock. That lets us enable hwmods independently, but it messes up DSS PM as it breaks some rules related to the sequence in which the opt-clocks and MODULEMODE bits need to be disabled. We would want to change OMAP4 to work the way as above too, with the cost of having these prints above. Archit ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-05-08 5:48 ` Archit Taneja 0 siblings, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-05-08 5:48 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: > Hi, > > On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > >> This patch adds hwmod data for omap5 display subsystem. I have tested this on >> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the >> mainline is missing omap5 HDMI driver. >> >> I do see this when booting: >> >> omap_hwmod: dss_dispc: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >> >> But at least DSI works just fine. > > Am looking at this for v3.16. But I think someone needs to take a look at > those warnings and figure out why they are happening. We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. The rest of the dss hwmods don't touch MODULEMODE. Therefore, these hwmods cannot be enabled independently, and reset. We don't face this issue in the omapdss driver since the platform devices corresponding to these hwmods have their parent as the platform device corresponding to 'dss_core'. This parent child-relation ensures that 'dss_core' is enabled when the a child calls a pm_runtime_get function. The problem is that we have multiple hwmods which use the same MODULEMODE bit. There is no use-counting done when it comes to enabling/disabling modulemode. If there was such a thing, we could have provided MODULEMODE flags even for the children hwmods. > > Is the soc_ops.wait_target_ready() call failing in omap_hwmod.c:_enable() > ? Yes, that's the one that fails. We have the same DSS in OMAP4, but we don't see the issue there. That's because we have modeled the MODULEMODE bits as a fake interface clock. That lets us enable hwmods independently, but it messes up DSS PM as it breaks some rules related to the sequence in which the opt-clocks and MODULEMODE bits need to be disabled. We would want to change OMAP4 to work the way as above too, with the cost of having these prints above. Archit ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-05-08 5:48 ` Archit Taneja @ 2014-05-08 16:01 ` Paul Walmsley -1 siblings, 0 replies; 43+ messages in thread From: Paul Walmsley @ 2014-05-08 16:01 UTC (permalink / raw) To: Archit Taneja Cc: Tomi Valkeinen, Tony Lindgren, Benoît Cousson, linux-omap, linux-arm-kernel Hi Archit, On Thu, 8 May 2014, Archit Taneja wrote: > Hi Paul, > > On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: > > Hi, > > > > On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > > > > > This patch adds hwmod data for omap5 display subsystem. I have tested this > > > on > > > omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, > > > as the > > > mainline is missing omap5 HDMI driver. > > > > > > I do see this when booting: > > > > > > omap_hwmod: dss_dispc: cannot be enabled for reset (3) > > > omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > > > omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > > > omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > > > omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > > > > > > But at least DSI works just fine. > > > > Am looking at this for v3.16. But I think someone needs to take a look at > > those warnings and figure out why they are happening. > > We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. > The rest of the dss hwmods don't touch MODULEMODE. > > Therefore, these hwmods cannot be enabled independently, and reset. > > We don't face this issue in the omapdss driver since the platform devices > corresponding to these hwmods have their parent as the platform device > corresponding to 'dss_core'. This parent child-relation ensures that > 'dss_core' is enabled when the a child calls a pm_runtime_get function. > > The problem is that we have multiple hwmods which use the same MODULEMODE bit. > There is no use-counting done when it comes to enabling/disabling modulemode. > If there was such a thing, we could have provided MODULEMODE flags even for > the children hwmods. Thanks for the summary. This is indeed a long-overdue item for the hwmod core code. Can you please patch the hwmod core code to add this? I'd suggest making the use-counting functionality conditional on a hwmod flag that you can set for all of the DSS hwmods. (Ideally, the core code would detect that several modules share the same MODULEMODE bits, and automatically set it for those cases, but that seems a bit too complex for a first cut.) - Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-05-08 16:01 ` Paul Walmsley 0 siblings, 0 replies; 43+ messages in thread From: Paul Walmsley @ 2014-05-08 16:01 UTC (permalink / raw) To: linux-arm-kernel Hi Archit, On Thu, 8 May 2014, Archit Taneja wrote: > Hi Paul, > > On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: > > Hi, > > > > On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > > > > > This patch adds hwmod data for omap5 display subsystem. I have tested this > > > on > > > omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, > > > as the > > > mainline is missing omap5 HDMI driver. > > > > > > I do see this when booting: > > > > > > omap_hwmod: dss_dispc: cannot be enabled for reset (3) > > > omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > > > omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > > > omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > > > omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > > > > > > But at least DSI works just fine. > > > > Am looking at this for v3.16. But I think someone needs to take a look at > > those warnings and figure out why they are happening. > > We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. > The rest of the dss hwmods don't touch MODULEMODE. > > Therefore, these hwmods cannot be enabled independently, and reset. > > We don't face this issue in the omapdss driver since the platform devices > corresponding to these hwmods have their parent as the platform device > corresponding to 'dss_core'. This parent child-relation ensures that > 'dss_core' is enabled when the a child calls a pm_runtime_get function. > > The problem is that we have multiple hwmods which use the same MODULEMODE bit. > There is no use-counting done when it comes to enabling/disabling modulemode. > If there was such a thing, we could have provided MODULEMODE flags even for > the children hwmods. Thanks for the summary. This is indeed a long-overdue item for the hwmod core code. Can you please patch the hwmod core code to add this? I'd suggest making the use-counting functionality conditional on a hwmod flag that you can set for all of the DSS hwmods. (Ideally, the core code would detect that several modules share the same MODULEMODE bits, and automatically set it for those cases, but that seems a bit too complex for a first cut.) - Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-05-08 16:01 ` Paul Walmsley @ 2014-05-09 6:19 ` Archit Taneja -1 siblings, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-05-09 6:19 UTC (permalink / raw) To: Paul Walmsley Cc: Tomi Valkeinen, Tony Lindgren, Benoît Cousson, linux-omap, linux-arm-kernel Hi Paul, On Thursday 08 May 2014 09:31 PM, Paul Walmsley wrote: <snip> >> The problem is that we have multiple hwmods which use the same MODULEMODE bit. >> There is no use-counting done when it comes to enabling/disabling modulemode. >> If there was such a thing, we could have provided MODULEMODE flags even for >> the children hwmods. > > Thanks for the summary. This is indeed a long-overdue item for the hwmod > core code. Can you please patch the hwmod core code to add this? I'd > suggest making the use-counting functionality conditional on a hwmod flag > that you can set for all of the DSS hwmods. (Ideally, the core code would > detect that several modules share the same MODULEMODE bits, and > automatically set it for those cases, but that seems a bit too complex for > a first cut.) Sure, I can work on this. Archit ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-05-09 6:19 ` Archit Taneja 0 siblings, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-05-09 6:19 UTC (permalink / raw) To: linux-arm-kernel Hi Paul, On Thursday 08 May 2014 09:31 PM, Paul Walmsley wrote: <snip> >> The problem is that we have multiple hwmods which use the same MODULEMODE bit. >> There is no use-counting done when it comes to enabling/disabling modulemode. >> If there was such a thing, we could have provided MODULEMODE flags even for >> the children hwmods. > > Thanks for the summary. This is indeed a long-overdue item for the hwmod > core code. Can you please patch the hwmod core code to add this? I'd > suggest making the use-counting functionality conditional on a hwmod flag > that you can set for all of the DSS hwmods. (Ideally, the core code would > detect that several modules share the same MODULEMODE bits, and > automatically set it for those cases, but that seems a bit too complex for > a first cut.) Sure, I can work on this. Archit ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-05-08 16:01 ` Paul Walmsley @ 2014-05-09 6:36 ` Tomi Valkeinen -1 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-05-09 6:36 UTC (permalink / raw) To: Paul Walmsley, Archit Taneja Cc: Tony Lindgren, Benoît Cousson, linux-omap, linux-arm-kernel [-- Attachment #1: Type: text/plain, Size: 2498 bytes --] On 08/05/14 19:01, Paul Walmsley wrote: > Hi Archit, > > On Thu, 8 May 2014, Archit Taneja wrote: > >> Hi Paul, >> >> On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: >>> Hi, >>> >>> On Wed, 12 Mar 2014, Tomi Valkeinen wrote: >>> >>>> This patch adds hwmod data for omap5 display subsystem. I have tested this >>>> on >>>> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, >>>> as the >>>> mainline is missing omap5 HDMI driver. >>>> >>>> I do see this when booting: >>>> >>>> omap_hwmod: dss_dispc: cannot be enabled for reset (3) >>>> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >>>> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >>>> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >>>> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >>>> >>>> But at least DSI works just fine. >>> >>> Am looking at this for v3.16. But I think someone needs to take a look at >>> those warnings and figure out why they are happening. >> >> We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. >> The rest of the dss hwmods don't touch MODULEMODE. >> >> Therefore, these hwmods cannot be enabled independently, and reset. >> >> We don't face this issue in the omapdss driver since the platform devices >> corresponding to these hwmods have their parent as the platform device >> corresponding to 'dss_core'. This parent child-relation ensures that >> 'dss_core' is enabled when the a child calls a pm_runtime_get function. >> >> The problem is that we have multiple hwmods which use the same MODULEMODE bit. >> There is no use-counting done when it comes to enabling/disabling modulemode. >> If there was such a thing, we could have provided MODULEMODE flags even for >> the children hwmods. > > Thanks for the summary. This is indeed a long-overdue item for the hwmod > core code. Can you please patch the hwmod core code to add this? I'd > suggest making the use-counting functionality conditional on a hwmod flag > that you can set for all of the DSS hwmods. (Ideally, the core code would > detect that several modules share the same MODULEMODE bits, and > automatically set it for those cases, but that seems a bit too complex for > a first cut.) Can we still go forward with this patch as it is? As far as I understand, the warnings are harmless (more or less), but without this patch we won't have OMAP5 display support. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-05-09 6:36 ` Tomi Valkeinen 0 siblings, 0 replies; 43+ messages in thread From: Tomi Valkeinen @ 2014-05-09 6:36 UTC (permalink / raw) To: linux-arm-kernel On 08/05/14 19:01, Paul Walmsley wrote: > Hi Archit, > > On Thu, 8 May 2014, Archit Taneja wrote: > >> Hi Paul, >> >> On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: >>> Hi, >>> >>> On Wed, 12 Mar 2014, Tomi Valkeinen wrote: >>> >>>> This patch adds hwmod data for omap5 display subsystem. I have tested this >>>> on >>>> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, >>>> as the >>>> mainline is missing omap5 HDMI driver. >>>> >>>> I do see this when booting: >>>> >>>> omap_hwmod: dss_dispc: cannot be enabled for reset (3) >>>> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) >>>> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) >>>> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) >>>> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) >>>> >>>> But at least DSI works just fine. >>> >>> Am looking at this for v3.16. But I think someone needs to take a look at >>> those warnings and figure out why they are happening. >> >> We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. >> The rest of the dss hwmods don't touch MODULEMODE. >> >> Therefore, these hwmods cannot be enabled independently, and reset. >> >> We don't face this issue in the omapdss driver since the platform devices >> corresponding to these hwmods have their parent as the platform device >> corresponding to 'dss_core'. This parent child-relation ensures that >> 'dss_core' is enabled when the a child calls a pm_runtime_get function. >> >> The problem is that we have multiple hwmods which use the same MODULEMODE bit. >> There is no use-counting done when it comes to enabling/disabling modulemode. >> If there was such a thing, we could have provided MODULEMODE flags even for >> the children hwmods. > > Thanks for the summary. This is indeed a long-overdue item for the hwmod > core code. Can you please patch the hwmod core code to add this? I'd > suggest making the use-counting functionality conditional on a hwmod flag > that you can set for all of the DSS hwmods. (Ideally, the core code would > detect that several modules share the same MODULEMODE bits, and > automatically set it for those cases, but that seems a bit too complex for > a first cut.) Can we still go forward with this patch as it is? As far as I understand, the warnings are harmless (more or less), but without this patch we won't have OMAP5 display support. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140509/67aef498/attachment.sig> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] ARM: OMAP5: DSS hwmod data 2014-05-09 6:36 ` Tomi Valkeinen @ 2014-05-14 19:44 ` Paul Walmsley -1 siblings, 0 replies; 43+ messages in thread From: Paul Walmsley @ 2014-05-14 19:44 UTC (permalink / raw) To: Tomi Valkeinen Cc: Archit Taneja, Tony Lindgren, Benoît Cousson, linux-omap, linux-arm-kernel On Fri, 9 May 2014, Tomi Valkeinen wrote: > On 08/05/14 19:01, Paul Walmsley wrote: > > Hi Archit, > > > > On Thu, 8 May 2014, Archit Taneja wrote: > > > >> Hi Paul, > >> > >> On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: > >>> Hi, > >>> > >>> On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > >>> > >>>> This patch adds hwmod data for omap5 display subsystem. I have tested this > >>>> on > >>>> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, > >>>> as the > >>>> mainline is missing omap5 HDMI driver. > >>>> > >>>> I do see this when booting: > >>>> > >>>> omap_hwmod: dss_dispc: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > >>>> > >>>> But at least DSI works just fine. > >>> > >>> Am looking at this for v3.16. But I think someone needs to take a look at > >>> those warnings and figure out why they are happening. > >> > >> We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. > >> The rest of the dss hwmods don't touch MODULEMODE. > >> > >> Therefore, these hwmods cannot be enabled independently, and reset. > >> > >> We don't face this issue in the omapdss driver since the platform devices > >> corresponding to these hwmods have their parent as the platform device > >> corresponding to 'dss_core'. This parent child-relation ensures that > >> 'dss_core' is enabled when the a child calls a pm_runtime_get function. > >> > >> The problem is that we have multiple hwmods which use the same MODULEMODE bit. > >> There is no use-counting done when it comes to enabling/disabling modulemode. > >> If there was such a thing, we could have provided MODULEMODE flags even for > >> the children hwmods. > > > > Thanks for the summary. This is indeed a long-overdue item for the hwmod > > core code. Can you please patch the hwmod core code to add this? I'd > > suggest making the use-counting functionality conditional on a hwmod flag > > that you can set for all of the DSS hwmods. (Ideally, the core code would > > detect that several modules share the same MODULEMODE bits, and > > automatically set it for those cases, but that seems a bit too complex for > > a first cut.) > > Can we still go forward with this patch as it is? As far as I > understand, the warnings are harmless (more or less), but without this > patch we won't have OMAP5 display support. Generally speaking, we try to avoid queuing patches that add warnings, for a few different reasons: 1. end users don't know whether they are serious or not, and could waste time trying to determine whether those warnings are causing other, unrelated problems for them 2. once patches with warnings are merged, even if folks promise to fix them, usually people tend to deprioritize 'closing the loop' on the fixes - so they often never make it back upstream 3. some maintainers search for warnings in their test logs and push back on patches that generate them All that said, you and Archit are pretty good in my experience about following up on issues. And Archit has mentioned that he will be patching the hwmod core code to fix the underlying issue: http://www.spinics.net/lists/arm-kernel/msg329614.html So, at least speaking for myself, I'm willing to queue this patch for 3.16, with the understanding that you all will be patching the hwmod core code to fix the root cause. - Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH] ARM: OMAP5: DSS hwmod data @ 2014-05-14 19:44 ` Paul Walmsley 0 siblings, 0 replies; 43+ messages in thread From: Paul Walmsley @ 2014-05-14 19:44 UTC (permalink / raw) To: linux-arm-kernel On Fri, 9 May 2014, Tomi Valkeinen wrote: > On 08/05/14 19:01, Paul Walmsley wrote: > > Hi Archit, > > > > On Thu, 8 May 2014, Archit Taneja wrote: > > > >> Hi Paul, > >> > >> On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: > >>> Hi, > >>> > >>> On Wed, 12 Mar 2014, Tomi Valkeinen wrote: > >>> > >>>> This patch adds hwmod data for omap5 display subsystem. I have tested this > >>>> on > >>>> omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, > >>>> as the > >>>> mainline is missing omap5 HDMI driver. > >>>> > >>>> I do see this when booting: > >>>> > >>>> omap_hwmod: dss_dispc: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_dsi1: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_dsi2: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_hdmi: cannot be enabled for reset (3) > >>>> omap_hwmod: dss_rfbi: cannot be enabled for reset (3) > >>>> > >>>> But at least DSI works just fine. > >>> > >>> Am looking at this for v3.16. But I think someone needs to take a look at > >>> those warnings and figure out why they are happening. > >> > >> We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. > >> The rest of the dss hwmods don't touch MODULEMODE. > >> > >> Therefore, these hwmods cannot be enabled independently, and reset. > >> > >> We don't face this issue in the omapdss driver since the platform devices > >> corresponding to these hwmods have their parent as the platform device > >> corresponding to 'dss_core'. This parent child-relation ensures that > >> 'dss_core' is enabled when the a child calls a pm_runtime_get function. > >> > >> The problem is that we have multiple hwmods which use the same MODULEMODE bit. > >> There is no use-counting done when it comes to enabling/disabling modulemode. > >> If there was such a thing, we could have provided MODULEMODE flags even for > >> the children hwmods. > > > > Thanks for the summary. This is indeed a long-overdue item for the hwmod > > core code. Can you please patch the hwmod core code to add this? I'd > > suggest making the use-counting functionality conditional on a hwmod flag > > that you can set for all of the DSS hwmods. (Ideally, the core code would > > detect that several modules share the same MODULEMODE bits, and > > automatically set it for those cases, but that seems a bit too complex for > > a first cut.) > > Can we still go forward with this patch as it is? As far as I > understand, the warnings are harmless (more or less), but without this > patch we won't have OMAP5 display support. Generally speaking, we try to avoid queuing patches that add warnings, for a few different reasons: 1. end users don't know whether they are serious or not, and could waste time trying to determine whether those warnings are causing other, unrelated problems for them 2. once patches with warnings are merged, even if folks promise to fix them, usually people tend to deprioritize 'closing the loop' on the fixes - so they often never make it back upstream 3. some maintainers search for warnings in their test logs and push back on patches that generate them All that said, you and Archit are pretty good in my experience about following up on issues. And Archit has mentioned that he will be patching the hwmod core code to fix the underlying issue: http://www.spinics.net/lists/arm-kernel/msg329614.html So, at least speaking for myself, I'm willing to queue this patch for 3.16, with the understanding that you all will be patching the hwmod core code to fix the root cause. - Paul ^ permalink raw reply [flat|nested] 43+ messages in thread
* [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods 2014-05-14 19:44 ` Paul Walmsley (?) @ 2014-05-26 10:44 ` Archit Taneja 2014-05-26 10:44 ` [RFC 2/2] ARM: OMAP5: hwmod data: Make DSS hwmods share MODULEMODE fields Archit Taneja ` (2 more replies) -1 siblings, 3 replies; 43+ messages in thread From: Archit Taneja @ 2014-05-26 10:44 UTC (permalink / raw) To: paul, rnayak; +Cc: tomi.valkeinen, linux-omap, Archit Taneja Generally, IP blocks/modules within a clock domain each have their own CM_x_CLKCTRL register, each having it's own MODULEMODE field to manage the module. DSS clockdoain, however, has multiple modules in it, but only one register named CM_DSS_DSS_CLKCTRL, which contains one MODULEMODE register field. Until now, we defined '.prcm.omap4.modulemode' only for the top level DSS hwmod("dss_core") and didn't define it for other DSS hwmods(like "dss_dispc", "dss_dsi1" and so on). This made the omapdss driver work as the top level DSS platform device and the rest had a parent-child relationship. This ensured that the parent hwmod("dss_core") is enabled if any of the children hwmods are enabled while using omapdss. This method, however, doesn't work when each hwmod is enabled individually. This happens early in boot in omap_hwmod_setup_all, where each hwmod is enabled, and then reset and idled. All the 'children' DSS hwmods fail to enable and reset, since they don't enable modulemode. The way to make such modules work both during initialization and when used by pm runtime API in the driver would be to add refcounting for enabling/disabling the modulemode field. We add a new flag bit for the flag in omap_hwmod_omap4_prcm, which tells omap_hwmod that this hwmod uses a modulemode field shared by other hwmods. We create a struct called 'modulemode_shared'. The hwmod data file should define a static instance of this struct. Each hwmod that uses this modulemode field should hold a pointer to this instance. omap_hwmod's soc enable_module and disable_module ops set the MODULEMODE reigster bits only when the first module using it is enabled, or the last module using it is disabled. We serialize accesses to the struct with a spinlock. Signed-off-by: Archit Taneja <archit@ti.com> --- arch/arm/mach-omap2/omap_hwmod.c | 123 +++++++++++++++++++++++++++++++++------ arch/arm/mach-omap2/omap_hwmod.h | 38 +++++++++--- 2 files changed, 133 insertions(+), 28 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 66c60fe..b42718d 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -973,17 +973,33 @@ static void _disable_optional_clocks(struct omap_hwmod *oh) */ static void _omap4_enable_module(struct omap_hwmod *oh) { + unsigned long flags; + struct modulemode_shared *mmode = NULL; + bool enable = true; + if (!oh->clkdm || !oh->prcm.omap4.modulemode) return; pr_debug("omap_hwmod: %s: %s: %d\n", oh->name, __func__, oh->prcm.omap4.modulemode); - omap4_cminst_module_enable(oh->prcm.omap4.modulemode, - oh->clkdm->prcm_partition, - oh->clkdm->cm_inst, - oh->clkdm->clkdm_offs, - oh->prcm.omap4.clkctrl_offs); + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { + mmode = oh->prcm.omap4.modulemode_ref; + + spin_lock_irqsave(&mmode->lock, flags); + + enable = mmode->refcnt++ == 0; + } + + if (enable) + omap4_cminst_module_enable(oh->prcm.omap4.modulemode, + oh->clkdm->prcm_partition, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + if (mmode) + spin_unlock_irqrestore(&mmode->lock, flags); } /** @@ -995,15 +1011,32 @@ static void _omap4_enable_module(struct omap_hwmod *oh) */ static void _am33xx_enable_module(struct omap_hwmod *oh) { + unsigned long flags; + struct modulemode_shared *mmode = NULL; + bool enable = true; + if (!oh->clkdm || !oh->prcm.omap4.modulemode) return; pr_debug("omap_hwmod: %s: %s: %d\n", oh->name, __func__, oh->prcm.omap4.modulemode); - am33xx_cm_module_enable(oh->prcm.omap4.modulemode, oh->clkdm->cm_inst, - oh->clkdm->clkdm_offs, - oh->prcm.omap4.clkctrl_offs); + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { + mmode = oh->prcm.omap4.modulemode_ref; + + spin_lock_irqsave(&mmode->lock, flags); + + enable = mmode->refcnt++ == 0; + } + + if (enable) + am33xx_cm_module_enable(oh->prcm.omap4.modulemode, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + if (mmode) + spin_unlock_irqrestore(&mmode->lock, flags); } /** @@ -1846,6 +1879,9 @@ static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh) static int _omap4_disable_module(struct omap_hwmod *oh) { int v; + unsigned long flags; + struct modulemode_shared *mmode = NULL; + bool disable = true; if (!oh->clkdm || !oh->prcm.omap4.modulemode) return -EINVAL; @@ -1859,15 +1895,30 @@ static int _omap4_disable_module(struct omap_hwmod *oh) pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__); - omap4_cminst_module_disable(oh->clkdm->prcm_partition, + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { + mmode = oh->prcm.omap4.modulemode_ref; + + spin_lock_irqsave(&mmode->lock, flags); + + WARN_ON(mmode->refcnt == 0); + + disable = --mmode->refcnt == 0; + } + + if (disable) { + omap4_cminst_module_disable(oh->clkdm->prcm_partition, oh->clkdm->cm_inst, oh->clkdm->clkdm_offs, oh->prcm.omap4.clkctrl_offs); - v = _omap4_wait_target_disable(oh); - if (v) - pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", - oh->name); + v = _omap4_wait_target_disable(oh); + if (v) + pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", + oh->name); + } + + if (mmode) + spin_unlock_irqrestore(&mmode->lock, flags); return 0; } @@ -1882,6 +1933,9 @@ static int _omap4_disable_module(struct omap_hwmod *oh) static int _am33xx_disable_module(struct omap_hwmod *oh) { int v; + unsigned long flags; + struct modulemode_shared *mmode = NULL; + bool disable = true; if (!oh->clkdm || !oh->prcm.omap4.modulemode) return -EINVAL; @@ -1891,13 +1945,28 @@ static int _am33xx_disable_module(struct omap_hwmod *oh) if (_are_any_hardreset_lines_asserted(oh)) return 0; - am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs, - oh->prcm.omap4.clkctrl_offs); + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { + mmode = oh->prcm.omap4.modulemode_ref; - v = _am33xx_wait_target_disable(oh); - if (v) - pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", - oh->name); + spin_lock_irqsave(&mmode->lock, flags); + + WARN_ON(mmode->refcnt == 0); + + disable = --mmode->refcnt == 0; + } + + if (disable) { + am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + v = _am33xx_wait_target_disable(oh); + if (v) + pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", + oh->name); + } + + if (mmode) + spin_unlock_irqrestore(&mmode->lock, flags); return 0; } @@ -2751,6 +2820,13 @@ static int __init _register(struct omap_hwmod *oh) if (_lookup(oh->name)) return -EEXIST; + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED && + !oh->prcm.omap4.modulemode_ref) { + pr_err("omap_hwmod: %s shares modulemode, but doesn't hold a ref to it\n", + oh->name); + return -EINVAL; + } + list_add_tail(&oh->node, &omap_hwmod_list); INIT_LIST_HEAD(&oh->master_ports); @@ -2759,6 +2835,15 @@ static int __init _register(struct omap_hwmod *oh) oh->_state = _HWMOD_STATE_REGISTERED; + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { + struct modulemode_shared *mmode = oh->prcm.omap4.modulemode_ref; + + if (!mmode->registered) { + spin_lock_init(&mmode->lock); + mmode->registered = true; + } + } + /* * XXX Rather than doing a strcmp(), this should test a flag * set in the hwmod data, inserted by the autogenerator code. diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h index 0f97d63..64c2af6 100644 --- a/arch/arm/mach-omap2/omap_hwmod.h +++ b/arch/arm/mach-omap2/omap_hwmod.h @@ -432,13 +432,31 @@ struct omap_hwmod_omap2_prcm { }; /* + * struct for managing modulemode field shared accross IP blocks + * @lock: spinlock to searilze enables/disables performed by different + * hwmods sharing the same modulemode field + * @refcnt: keep a refcount of the enabled hwmods using this modulemode + * field + * @registered: a flag to track whether the struct has been registered + */ +struct modulemode_shared { + spinlock_t lock; + unsigned refcnt; + bool registered; +}; + +/* * Possible values for struct omap_hwmod_omap4_prcm.flags * * HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT: Some IP blocks don't have a PRCM * module-level context loss register associated with them; this * flag bit should be set in those cases + * HWMOD_OMAP4_MODULEMODE_SHARED: Some IP blocks belonging to the same + * clock domain may have a shared MODULEMODE field; this flag bit + * should be set in those cases */ #define HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT (1 << 0) +#define HWMOD_OMAP4_MODULEMODE_SHARED (1 << 1) /** * struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data @@ -450,6 +468,7 @@ struct omap_hwmod_omap2_prcm { * @submodule_wkdep_bit: bit shift of the WKDEP range * @flags: PRCM register capabilities for this IP block * @modulemode: allowable modulemodes + * @modulemode_ref: pointer to modulemode struct shared by multiple hwmods * @context_lost_counter: Count of module level context lost * * If @lostcontext_mask is not defined, context loss check code uses @@ -458,15 +477,16 @@ struct omap_hwmod_omap2_prcm { * more hwmods. */ struct omap_hwmod_omap4_prcm { - u16 clkctrl_offs; - u16 rstctrl_offs; - u16 rstst_offs; - u16 context_offs; - u32 lostcontext_mask; - u8 submodule_wkdep_bit; - u8 modulemode; - u8 flags; - int context_lost_counter; + u16 clkctrl_offs; + u16 rstctrl_offs; + u16 rstst_offs; + u16 context_offs; + u32 lostcontext_mask; + u8 submodule_wkdep_bit; + u8 modulemode; + struct modulemode_shared *modulemode_ref; + u8 flags; + int context_lost_counter; }; -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC 2/2] ARM: OMAP5: hwmod data: Make DSS hwmods share MODULEMODE fields 2014-05-26 10:44 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja @ 2014-05-26 10:44 ` Archit Taneja 2014-05-27 10:20 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Rajendra Nayak 2014-06-17 9:54 ` [RFC v2 0/2] arm: omap2+: hwmod: Allow hwmods to share same modulemode register filed Archit Taneja 2 siblings, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-05-26 10:44 UTC (permalink / raw) To: paul, rnayak; +Cc: tomi.valkeinen, linux-omap, Archit Taneja This is an example which shows how to use new 'shared modulemode' flag. DSS hwmods share the MODULEMODE field. Add the new HWMOD_OMAP4_MODULEMODE_SHARED flag, and create a modulemode_shared struct which the DSS hwmods refer to. This will allow the hwmods to reset properly during boot, and not break things when the DSS driver runs. (Note: hdmi and rfbi hwmods still don't reset properly as they don't have their mainclks as dss_dss_clk, this will be fixed later). Signed-off-by: Archit Taneja <archit@ti.com> --- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 46 +++++++++++++++++++++--------- 1 file changed, 33 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c index e8bdd7a..762d61f 100644 --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c @@ -337,6 +337,9 @@ static struct omap_hwmod omap54xx_dmic_hwmod = { * 'dss' class * display sub-system */ + +static struct modulemode_shared dss_modulemode_ref; + static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = { .rev_offs = 0x0000, .syss_offs = 0x0014, @@ -364,9 +367,11 @@ static struct omap_hwmod omap54xx_dss_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET, - .modulemode = MODULEMODE_SWCTRL, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET, + .modulemode = MODULEMODE_SWCTRL, + .flags = HWMOD_OMAP4_MODULEMODE_SHARED, + .modulemode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_opt_clks, @@ -414,8 +419,11 @@ static struct omap_hwmod omap54xx_dss_dispc_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT | + HWMOD_OMAP4_MODULEMODE_SHARED, + .modulemode = MODULEMODE_SWCTRL, + .modulemode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_dispc_opt_clks, @@ -456,8 +464,11 @@ static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT | + HWMOD_OMAP4_MODULEMODE_SHARED, + .modulemode = MODULEMODE_SWCTRL, + .modulemode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_dsi1_a_opt_clks, @@ -476,8 +487,11 @@ static struct omap_hwmod omap54xx_dss_dsi1_c_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT | + HWMOD_OMAP4_MODULEMODE_SHARED, + .modulemode = MODULEMODE_SWCTRL, + .modulemode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_dsi1_c_opt_clks, @@ -515,8 +529,11 @@ static struct omap_hwmod omap54xx_dss_hdmi_hwmod = { .main_clk = "dss_48mhz_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT | + HWMOD_OMAP4_MODULEMODE_SHARED, + .modulemode = MODULEMODE_SWCTRL, + .modulemode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_hdmi_opt_clks, @@ -554,8 +571,11 @@ static struct omap_hwmod omap54xx_dss_rfbi_hwmod = { .clkdm_name = "dss_clkdm", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT | + HWMOD_OMAP4_MODULEMODE_SHARED, + .modulemode = MODULEMODE_SWCTRL, + .modulemode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_rfbi_opt_clks, -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods 2014-05-26 10:44 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja 2014-05-26 10:44 ` [RFC 2/2] ARM: OMAP5: hwmod data: Make DSS hwmods share MODULEMODE fields Archit Taneja @ 2014-05-27 10:20 ` Rajendra Nayak 2014-05-27 10:49 ` Archit Taneja 2014-06-17 9:54 ` [RFC v2 0/2] arm: omap2+: hwmod: Allow hwmods to share same modulemode register filed Archit Taneja 2 siblings, 1 reply; 43+ messages in thread From: Rajendra Nayak @ 2014-05-27 10:20 UTC (permalink / raw) To: Archit Taneja; +Cc: paul, tomi.valkeinen, linux-omap On Monday 26 May 2014 04:14 PM, Archit Taneja wrote: > Generally, IP blocks/modules within a clock domain each have their own > CM_x_CLKCTRL register, each having it's own MODULEMODE field to manage the > module. > > DSS clockdoain, however, has multiple modules in it, but only one register > named CM_DSS_DSS_CLKCTRL, which contains one MODULEMODE register field. > > Until now, we defined '.prcm.omap4.modulemode' only for the top level DSS > hwmod("dss_core") and didn't define it for other DSS hwmods(like "dss_dispc", > "dss_dsi1" and so on). This made the omapdss driver work as the top level DSS > platform device and the rest had a parent-child relationship. This ensured that > the parent hwmod("dss_core") is enabled if any of the children hwmods are > enabled while using omapdss. > > This method, however, doesn't work when each hwmod is enabled individually. > This happens early in boot in omap_hwmod_setup_all, where each hwmod is enabled, > and then reset and idled. All the 'children' DSS hwmods fail to enable and > reset, since they don't enable modulemode. > > The way to make such modules work both during initialization and when used by > pm runtime API in the driver would be to add refcounting for enabling/disabling > the modulemode field. > > We add a new flag bit for the flag in omap_hwmod_omap4_prcm, which tells > omap_hwmod that this hwmod uses a modulemode field shared by other hwmods. > > We create a struct called 'modulemode_shared'. The hwmod data file should define > a static instance of this struct. Each hwmod that uses this modulemode field > should hold a pointer to this instance. > > omap_hwmod's soc enable_module and disable_module ops set the MODULEMODE > reigster bits only when the first module using it is enabled, or the last module > using it is disabled. We serialize accesses to the struct with a spinlock. > > Signed-off-by: Archit Taneja <archit@ti.com> > --- > arch/arm/mach-omap2/omap_hwmod.c | 123 +++++++++++++++++++++++++++++++++------ > arch/arm/mach-omap2/omap_hwmod.h | 38 +++++++++--- > 2 files changed, 133 insertions(+), 28 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c > index 66c60fe..b42718d 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.c > +++ b/arch/arm/mach-omap2/omap_hwmod.c > @@ -973,17 +973,33 @@ static void _disable_optional_clocks(struct omap_hwmod *oh) > */ > static void _omap4_enable_module(struct omap_hwmod *oh) > { > + unsigned long flags; > + struct modulemode_shared *mmode = NULL; > + bool enable = true; > + > if (!oh->clkdm || !oh->prcm.omap4.modulemode) > return; > > pr_debug("omap_hwmod: %s: %s: %d\n", > oh->name, __func__, oh->prcm.omap4.modulemode); > > - omap4_cminst_module_enable(oh->prcm.omap4.modulemode, > - oh->clkdm->prcm_partition, > - oh->clkdm->cm_inst, > - oh->clkdm->clkdm_offs, > - oh->prcm.omap4.clkctrl_offs); > + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { > + mmode = oh->prcm.omap4.modulemode_ref; > + > + spin_lock_irqsave(&mmode->lock, flags); > + > + enable = mmode->refcnt++ == 0; > + } > + > + if (enable) > + omap4_cminst_module_enable(oh->prcm.omap4.modulemode, > + oh->clkdm->prcm_partition, > + oh->clkdm->cm_inst, > + oh->clkdm->clkdm_offs, > + oh->prcm.omap4.clkctrl_offs); > + > + if (mmode) > + spin_unlock_irqrestore(&mmode->lock, flags); > } > > /** > @@ -995,15 +1011,32 @@ static void _omap4_enable_module(struct omap_hwmod *oh) > */ > static void _am33xx_enable_module(struct omap_hwmod *oh) > { > + unsigned long flags; > + struct modulemode_shared *mmode = NULL; > + bool enable = true; > + > if (!oh->clkdm || !oh->prcm.omap4.modulemode) > return; > > pr_debug("omap_hwmod: %s: %s: %d\n", > oh->name, __func__, oh->prcm.omap4.modulemode); > > - am33xx_cm_module_enable(oh->prcm.omap4.modulemode, oh->clkdm->cm_inst, > - oh->clkdm->clkdm_offs, > - oh->prcm.omap4.clkctrl_offs); > + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { > + mmode = oh->prcm.omap4.modulemode_ref; > + > + spin_lock_irqsave(&mmode->lock, flags); > + > + enable = mmode->refcnt++ == 0; > + } > + > + if (enable) > + am33xx_cm_module_enable(oh->prcm.omap4.modulemode, > + oh->clkdm->cm_inst, > + oh->clkdm->clkdm_offs, > + oh->prcm.omap4.clkctrl_offs); > + > + if (mmode) > + spin_unlock_irqrestore(&mmode->lock, flags); > } > > /** > @@ -1846,6 +1879,9 @@ static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh) > static int _omap4_disable_module(struct omap_hwmod *oh) > { > int v; > + unsigned long flags; > + struct modulemode_shared *mmode = NULL; > + bool disable = true; > > if (!oh->clkdm || !oh->prcm.omap4.modulemode) > return -EINVAL; > @@ -1859,15 +1895,30 @@ static int _omap4_disable_module(struct omap_hwmod *oh) > > pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__); > > - omap4_cminst_module_disable(oh->clkdm->prcm_partition, > + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { > + mmode = oh->prcm.omap4.modulemode_ref; > + > + spin_lock_irqsave(&mmode->lock, flags); > + > + WARN_ON(mmode->refcnt == 0); > + > + disable = --mmode->refcnt == 0; > + } > + > + if (disable) { > + omap4_cminst_module_disable(oh->clkdm->prcm_partition, > oh->clkdm->cm_inst, > oh->clkdm->clkdm_offs, > oh->prcm.omap4.clkctrl_offs); > > - v = _omap4_wait_target_disable(oh); > - if (v) > - pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", > - oh->name); > + v = _omap4_wait_target_disable(oh); > + if (v) > + pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", > + oh->name); > + } > + > + if (mmode) > + spin_unlock_irqrestore(&mmode->lock, flags); > > return 0; > } > @@ -1882,6 +1933,9 @@ static int _omap4_disable_module(struct omap_hwmod *oh) > static int _am33xx_disable_module(struct omap_hwmod *oh) > { > int v; > + unsigned long flags; > + struct modulemode_shared *mmode = NULL; > + bool disable = true; > > if (!oh->clkdm || !oh->prcm.omap4.modulemode) > return -EINVAL; > @@ -1891,13 +1945,28 @@ static int _am33xx_disable_module(struct omap_hwmod *oh) > if (_are_any_hardreset_lines_asserted(oh)) > return 0; > > - am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs, > - oh->prcm.omap4.clkctrl_offs); > + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { > + mmode = oh->prcm.omap4.modulemode_ref; > > - v = _am33xx_wait_target_disable(oh); > - if (v) > - pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", > - oh->name); > + spin_lock_irqsave(&mmode->lock, flags); > + > + WARN_ON(mmode->refcnt == 0); > + > + disable = --mmode->refcnt == 0; > + } > + > + if (disable) { > + am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs, > + oh->prcm.omap4.clkctrl_offs); > + > + v = _am33xx_wait_target_disable(oh); > + if (v) > + pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", > + oh->name); > + } > + > + if (mmode) > + spin_unlock_irqrestore(&mmode->lock, flags); > > return 0; > } > @@ -2751,6 +2820,13 @@ static int __init _register(struct omap_hwmod *oh) > if (_lookup(oh->name)) > return -EEXIST; > > + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED && > + !oh->prcm.omap4.modulemode_ref) { You might also want to check for someone populating a modulemode_ref but failing to populate the flag? Alternatively, Since you expect a modulemode_ref to be always available for all modules which share modulemode, that in itself can be used to identify such modules without the need of an additional flag? > + pr_err("omap_hwmod: %s shares modulemode, but doesn't hold a ref to it\n", > + oh->name); > + return -EINVAL; > + } > + > list_add_tail(&oh->node, &omap_hwmod_list); > > INIT_LIST_HEAD(&oh->master_ports); > @@ -2759,6 +2835,15 @@ static int __init _register(struct omap_hwmod *oh) > > oh->_state = _HWMOD_STATE_REGISTERED; > > + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { > + struct modulemode_shared *mmode = oh->prcm.omap4.modulemode_ref; > + > + if (!mmode->registered) { > + spin_lock_init(&mmode->lock); > + mmode->registered = true; If this is only used to keep track of the spin_lock being initialized, maybe it'll be more readable if you just call it mmode->spin_lock_init = true. > + } > + } > + > /* > * XXX Rather than doing a strcmp(), this should test a flag > * set in the hwmod data, inserted by the autogenerator code. > diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h > index 0f97d63..64c2af6 100644 > --- a/arch/arm/mach-omap2/omap_hwmod.h > +++ b/arch/arm/mach-omap2/omap_hwmod.h > @@ -432,13 +432,31 @@ struct omap_hwmod_omap2_prcm { > }; > > /* > + * struct for managing modulemode field shared accross IP blocks > + * @lock: spinlock to searilze enables/disables performed by different > + * hwmods sharing the same modulemode field > + * @refcnt: keep a refcount of the enabled hwmods using this modulemode > + * field > + * @registered: a flag to track whether the struct has been registered > + */ > +struct modulemode_shared { > + spinlock_t lock; > + unsigned refcnt; > + bool registered; > +}; > + > +/* > * Possible values for struct omap_hwmod_omap4_prcm.flags > * > * HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT: Some IP blocks don't have a PRCM > * module-level context loss register associated with them; this > * flag bit should be set in those cases > + * HWMOD_OMAP4_MODULEMODE_SHARED: Some IP blocks belonging to the same > + * clock domain may have a shared MODULEMODE field; this flag bit > + * should be set in those cases > */ > #define HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT (1 << 0) > +#define HWMOD_OMAP4_MODULEMODE_SHARED (1 << 1) > > /** > * struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data > @@ -450,6 +468,7 @@ struct omap_hwmod_omap2_prcm { > * @submodule_wkdep_bit: bit shift of the WKDEP range > * @flags: PRCM register capabilities for this IP block > * @modulemode: allowable modulemodes > + * @modulemode_ref: pointer to modulemode struct shared by multiple hwmods > * @context_lost_counter: Count of module level context lost > * > * If @lostcontext_mask is not defined, context loss check code uses > @@ -458,15 +477,16 @@ struct omap_hwmod_omap2_prcm { > * more hwmods. > */ > struct omap_hwmod_omap4_prcm { > - u16 clkctrl_offs; > - u16 rstctrl_offs; > - u16 rstst_offs; > - u16 context_offs; > - u32 lostcontext_mask; > - u8 submodule_wkdep_bit; > - u8 modulemode; > - u8 flags; > - int context_lost_counter; > + u16 clkctrl_offs; > + u16 rstctrl_offs; > + u16 rstst_offs; > + u16 context_offs; > + u32 lostcontext_mask; > + u8 submodule_wkdep_bit; > + u8 modulemode; > + struct modulemode_shared *modulemode_ref; > + u8 flags; > + int context_lost_counter; > }; > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods 2014-05-27 10:20 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Rajendra Nayak @ 2014-05-27 10:49 ` Archit Taneja 0 siblings, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-05-27 10:49 UTC (permalink / raw) To: Rajendra Nayak; +Cc: paul, tomi.valkeinen, linux-omap Hi, On Tuesday 27 May 2014 03:50 PM, Rajendra Nayak wrote: > On Monday 26 May 2014 04:14 PM, Archit Taneja wrote: >> Generally, IP blocks/modules within a clock domain each have their own >> CM_x_CLKCTRL register, each having it's own MODULEMODE field to manage the >> module. <snip> >> @@ -2751,6 +2820,13 @@ static int __init _register(struct omap_hwmod *oh) >> if (_lookup(oh->name)) >> return -EEXIST; >> >> + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED && >> + !oh->prcm.omap4.modulemode_ref) { > > You might also want to check for someone populating a modulemode_ref but > failing to populate the flag? > > Alternatively, Since you expect a modulemode_ref to be always available for all modules which > share modulemode, that in itself can be used to identify such modules without the > need of an additional flag? It does seem redundant to have a flag at the moment. But the flag make things more visible. 'prcm.omap4.modulemode' seems to work without a flag too, so I suppose I'll remove the flag. > >> + pr_err("omap_hwmod: %s shares modulemode, but doesn't hold a ref to it\n", >> + oh->name); >> + return -EINVAL; >> + } >> + >> list_add_tail(&oh->node, &omap_hwmod_list); >> >> INIT_LIST_HEAD(&oh->master_ports); >> @@ -2759,6 +2835,15 @@ static int __init _register(struct omap_hwmod *oh) >> >> oh->_state = _HWMOD_STATE_REGISTERED; >> >> + if (oh->prcm.omap4.flags & HWMOD_OMAP4_MODULEMODE_SHARED) { >> + struct modulemode_shared *mmode = oh->prcm.omap4.modulemode_ref; >> + >> + if (!mmode->registered) { >> + spin_lock_init(&mmode->lock); >> + mmode->registered = true; > > If this is only used to keep track of the spin_lock being initialized, maybe it'll be > more readable if you just call it mmode->spin_lock_init = true. Yes, I'll fix this. Archit ^ permalink raw reply [flat|nested] 43+ messages in thread
* [RFC v2 0/2] arm: omap2+: hwmod: Allow hwmods to share same modulemode register filed 2014-05-26 10:44 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja 2014-05-26 10:44 ` [RFC 2/2] ARM: OMAP5: hwmod data: Make DSS hwmods share MODULEMODE fields Archit Taneja 2014-05-27 10:20 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Rajendra Nayak @ 2014-06-17 9:54 ` Archit Taneja 2014-06-17 9:54 ` [RFC v2 1/2] arm: omap2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja 2014-06-17 9:54 ` [RFC v2 2/2] arm: omap5 hwmod data: Example: Make DSS hwmods share MODULEMODE fields Archit Taneja 2 siblings, 2 replies; 43+ messages in thread From: Archit Taneja @ 2014-06-17 9:54 UTC (permalink / raw) To: paul, rnayak; +Cc: linux-omap, Archit Taneja IP blocks within a clock domain generally come with their own CM_X_CLKCTRL registers, each having it's own MODULEMODE field to manage the module. This is not the case for DSS, though. DSS contains contains sub modules, each of which are represented by hwmods, but DSS itself has only one register CM_DSS_DSS_CLKCTRL. Add a way to allow multiple hwmods to share the same MODULEMODE fiels. This means that MODULEMODE operation should be disabled only when the last hwmod using it is disabled. Changes in v2: - The OMAP4 PRCM hwmod flag to show that this hwmod is shared was found redundant, and therefore, removed. - Some of the struct names are shortened, and members are named more appropriately. Archit Taneja (2): arm: omap2+: hwmod: Add refcounting for modulemode shared by multiple hwmods arm: omap5 hwmod data: Example: Make DSS hwmods share MODULEMODE fields arch/arm/mach-omap2/omap_hwmod.c | 145 +++++++++++++++++++++++++---- arch/arm/mach-omap2/omap_hwmod.h | 35 +++++-- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 40 +++++--- 3 files changed, 180 insertions(+), 40 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 43+ messages in thread
* [RFC v2 1/2] arm: omap2+: hwmod: Add refcounting for modulemode shared by multiple hwmods 2014-06-17 9:54 ` [RFC v2 0/2] arm: omap2+: hwmod: Allow hwmods to share same modulemode register filed Archit Taneja @ 2014-06-17 9:54 ` Archit Taneja 2014-06-17 9:54 ` [RFC v2 2/2] arm: omap5 hwmod data: Example: Make DSS hwmods share MODULEMODE fields Archit Taneja 1 sibling, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-06-17 9:54 UTC (permalink / raw) To: paul, rnayak; +Cc: linux-omap, Archit Taneja Generally, IP blocks/modules within a clock domain come with their own CM_x_CLKCTRL registers, each having it's own MODULEMODE field to manage the module. DSS clockdomain, however, has multiple modules in it, but only one register named CM_DSS_DSS_CLKCTRL, which contains one MODULEMODE register field. Until now, we defined modulemode only for the top level DSS hwmod("dss_core") and didn't define it for other DSS hwmods(like "dss_dispc", "dss_dsi1" and so on). This made the omapdss driver work as the top level DSS platform device and the rest had a parent-child relationship, and ensured that the parent hwmod("dss_core") is enabled if any of the children hwmods are enabled. This method, however, doesn't work when each hwmod is enabled individually. When hwmods are set up in omap_hwmod_setup_all, each hwmod is individually enabled, followed by a reset and idle. All the 'children' DSS hwmods fail to enable as they don't enable modulemode. The way to make such modules work both during initialization and when used by pm runtime API in the driver is be to add refcounting for enabling/disabling modulemode. We create a struct called 'mmode_shared'. The hwmod data file should define an instance of this struct. Each hwmod that uses this modulemode field should hold a pointer to this instance. omap_hwmod's soc enable_module and disable_module ops set the MODULEMODE reigster bits only when the first module using it is enabled, or the last module using it is disabled. We serialize accesses to the struct with a spinlock. Signed-off-by: Archit Taneja <archit@ti.com> --- arch/arm/mach-omap2/omap_hwmod.c | 145 ++++++++++++++++++++++++++++++++++----- arch/arm/mach-omap2/omap_hwmod.h | 35 +++++++--- 2 files changed, 153 insertions(+), 27 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index f7bb435..2b036e3 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1,3 +1,4 @@ + /* * omap_hwmod implementation for OMAP2/3/4 * @@ -973,17 +974,38 @@ static void _disable_optional_clocks(struct omap_hwmod *oh) */ static void _omap4_enable_module(struct omap_hwmod *oh) { + struct mmode_shared *mmode; + if (!oh->clkdm || !oh->prcm.omap4.modulemode) return; pr_debug("omap_hwmod: %s: %s: %d\n", oh->name, __func__, oh->prcm.omap4.modulemode); - omap4_cminst_module_enable(oh->prcm.omap4.modulemode, - oh->clkdm->prcm_partition, - oh->clkdm->cm_inst, - oh->clkdm->clkdm_offs, - oh->prcm.omap4.clkctrl_offs); + mmode = oh->prcm.omap4.mmode_ref; + if (mmode) { + bool enable; + unsigned long flags; + + spin_lock_irqsave(&mmode->lock, flags); + + enable = mmode->refcnt++ == 0; + + if (enable) + omap4_cminst_module_enable(oh->prcm.omap4.modulemode, + oh->clkdm->prcm_partition, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + spin_unlock_irqrestore(&mmode->lock, flags); + } else { + omap4_cminst_module_enable(oh->prcm.omap4.modulemode, + oh->clkdm->prcm_partition, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + } } /** @@ -995,15 +1017,36 @@ static void _omap4_enable_module(struct omap_hwmod *oh) */ static void _am33xx_enable_module(struct omap_hwmod *oh) { + struct mmode_shared *mmode; + if (!oh->clkdm || !oh->prcm.omap4.modulemode) return; pr_debug("omap_hwmod: %s: %s: %d\n", oh->name, __func__, oh->prcm.omap4.modulemode); - am33xx_cm_module_enable(oh->prcm.omap4.modulemode, oh->clkdm->cm_inst, - oh->clkdm->clkdm_offs, - oh->prcm.omap4.clkctrl_offs); + mmode = oh->prcm.omap4.mmode_ref; + if (mmode) { + bool enable; + unsigned long flags; + + spin_lock_irqsave(&mmode->lock, flags); + + enable = mmode->refcnt++ == 0; + + if (enable) + am33xx_cm_module_enable(oh->prcm.omap4.modulemode, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + spin_unlock_irqrestore(&mmode->lock, flags); + } else { + am33xx_cm_module_enable(oh->prcm.omap4.modulemode, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + } } /** @@ -1845,7 +1888,8 @@ static bool _are_any_hardreset_lines_asserted(struct omap_hwmod *oh) */ static int _omap4_disable_module(struct omap_hwmod *oh) { - int v; + int v = 0; + struct mmode_shared *mmode; if (!oh->clkdm || !oh->prcm.omap4.modulemode) return -EINVAL; @@ -1859,12 +1903,36 @@ static int _omap4_disable_module(struct omap_hwmod *oh) pr_debug("omap_hwmod: %s: %s\n", oh->name, __func__); - omap4_cminst_module_disable(oh->clkdm->prcm_partition, - oh->clkdm->cm_inst, - oh->clkdm->clkdm_offs, - oh->prcm.omap4.clkctrl_offs); + mmode = oh->prcm.omap4.mmode_ref; + if (mmode) { + bool disable; + unsigned long flags; + + spin_lock_irqsave(&mmode->lock, flags); + + WARN_ON(mmode->refcnt == 0); + + disable = --mmode->refcnt == 0; + + if (disable) { + omap4_cminst_module_disable(oh->clkdm->prcm_partition, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + v = _omap4_wait_target_disable(oh); + } + + spin_unlock_irqrestore(&mmode->lock, flags); + } else { + omap4_cminst_module_disable(oh->clkdm->prcm_partition, + oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + v = _omap4_wait_target_disable(oh); + } - v = _omap4_wait_target_disable(oh); if (v) pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", oh->name); @@ -1881,7 +1949,8 @@ static int _omap4_disable_module(struct omap_hwmod *oh) */ static int _am33xx_disable_module(struct omap_hwmod *oh) { - int v; + int v = 0; + struct mmode_shared *mmode; if (!oh->clkdm || !oh->prcm.omap4.modulemode) return -EINVAL; @@ -1891,10 +1960,34 @@ static int _am33xx_disable_module(struct omap_hwmod *oh) if (_are_any_hardreset_lines_asserted(oh)) return 0; - am33xx_cm_module_disable(oh->clkdm->cm_inst, oh->clkdm->clkdm_offs, - oh->prcm.omap4.clkctrl_offs); + mmode = oh->prcm.omap4.mmode_ref; + if (mmode) { + bool disable; + unsigned long flags; + + spin_lock_irqsave(&mmode->lock, flags); + + WARN_ON(mmode->refcnt == 0); + + disable = --mmode->refcnt == 0; + + if (disable) { + am33xx_cm_module_disable(oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + v = _am33xx_wait_target_disable(oh); + } + + spin_unlock_irqrestore(&mmode->lock, flags); + } else { + am33xx_cm_module_disable(oh->clkdm->cm_inst, + oh->clkdm->clkdm_offs, + oh->prcm.omap4.clkctrl_offs); + + v = _am33xx_wait_target_disable(oh); + } - v = _am33xx_wait_target_disable(oh); if (v) pr_warn("omap_hwmod: %s: _wait_target_disable failed\n", oh->name); @@ -2751,6 +2844,12 @@ static int __init _register(struct omap_hwmod *oh) if (_lookup(oh->name)) return -EEXIST; + if (oh->prcm.omap4.mmode_ref && !oh->prcm.omap4.modulemode) { + pr_err("omap_hwmod: %s shares modulemode, but doesn't specify any modulemode control type\n", + oh->name); + return -EINVAL; + } + list_add_tail(&oh->node, &omap_hwmod_list); INIT_LIST_HEAD(&oh->master_ports); @@ -2759,6 +2858,16 @@ static int __init _register(struct omap_hwmod *oh) oh->_state = _HWMOD_STATE_REGISTERED; + if (oh->prcm.omap4.mmode_ref) { + struct mmode_shared *mmode = oh->prcm.omap4.mmode_ref; + + if (!mmode->inited) { + spin_lock_init(&mmode->lock); + mmode->refcnt = 0; + mmode->inited = true; + } + } + /* * XXX Rather than doing a strcmp(), this should test a flag * set in the hwmod data, inserted by the autogenerator code. diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h index 0f97d63..ff6ec56 100644 --- a/arch/arm/mach-omap2/omap_hwmod.h +++ b/arch/arm/mach-omap2/omap_hwmod.h @@ -432,6 +432,21 @@ struct omap_hwmod_omap2_prcm { }; /* + * struct for managing modulemode field shared accross IP blocks + * @lock: spinlock to searilze enables/disables performed by different + * hwmods sharing the same modulemode field + * @refcnt: keep a refcount of the enabled hwmods using this modulemode + * field + * @inited: a flag to track whether the struct has been initialized or + * not + */ +struct mmode_shared { + spinlock_t lock; + unsigned refcnt; + bool inited; +}; + +/* * Possible values for struct omap_hwmod_omap4_prcm.flags * * HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT: Some IP blocks don't have a PRCM @@ -450,6 +465,7 @@ struct omap_hwmod_omap2_prcm { * @submodule_wkdep_bit: bit shift of the WKDEP range * @flags: PRCM register capabilities for this IP block * @modulemode: allowable modulemodes + * @mmode_ref: pointer to modulemode struct shared by multiple hwmods * @context_lost_counter: Count of module level context lost * * If @lostcontext_mask is not defined, context loss check code uses @@ -458,15 +474,16 @@ struct omap_hwmod_omap2_prcm { * more hwmods. */ struct omap_hwmod_omap4_prcm { - u16 clkctrl_offs; - u16 rstctrl_offs; - u16 rstst_offs; - u16 context_offs; - u32 lostcontext_mask; - u8 submodule_wkdep_bit; - u8 modulemode; - u8 flags; - int context_lost_counter; + u16 clkctrl_offs; + u16 rstctrl_offs; + u16 rstst_offs; + u16 context_offs; + u32 lostcontext_mask; + u8 submodule_wkdep_bit; + u8 modulemode; + struct mmode_shared *mmode_ref; + u8 flags; + int context_lost_counter; }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [RFC v2 2/2] arm: omap5 hwmod data: Example: Make DSS hwmods share MODULEMODE fields 2014-06-17 9:54 ` [RFC v2 0/2] arm: omap2+: hwmod: Allow hwmods to share same modulemode register filed Archit Taneja 2014-06-17 9:54 ` [RFC v2 1/2] arm: omap2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja @ 2014-06-17 9:54 ` Archit Taneja 1 sibling, 0 replies; 43+ messages in thread From: Archit Taneja @ 2014-06-17 9:54 UTC (permalink / raw) To: paul, rnayak; +Cc: linux-omap, Archit Taneja DSS hwmods share the MODULEMODE field. Create a new 'mmode_shared' struct which the DSS hwmods refer to. This will allow the hwmods to reset properly during boot, and not break things when the omapdss module is inserted. (Note: hdmi and rfbi hwmods still don't reset properly as they don't have their mainclks as dss_dss_clk, this needs to be changed later). Signed-off-by: Archit Taneja <archit@ti.com> --- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 40 ++++++++++++++++++++---------- 1 file changed, 27 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c index 290213f..e855cf5 100644 --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c @@ -337,6 +337,9 @@ static struct omap_hwmod omap54xx_dmic_hwmod = { * 'dss' class * display sub-system */ + +static struct mmode_shared dss_modulemode_ref; + static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = { .rev_offs = 0x0000, .syss_offs = 0x0014, @@ -364,9 +367,10 @@ static struct omap_hwmod omap54xx_dss_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET, - .modulemode = MODULEMODE_SWCTRL, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET, + .modulemode = MODULEMODE_SWCTRL, + .mmode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_opt_clks, @@ -414,8 +418,10 @@ static struct omap_hwmod omap54xx_dss_dispc_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .modulemode = MODULEMODE_SWCTRL, + .mmode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_dispc_opt_clks, @@ -456,8 +462,10 @@ static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .modulemode = MODULEMODE_SWCTRL, + .mmode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_dsi1_a_opt_clks, @@ -476,8 +484,10 @@ static struct omap_hwmod omap54xx_dss_dsi1_c_hwmod = { .main_clk = "dss_dss_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .modulemode = MODULEMODE_SWCTRL, + .mmode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_dsi1_c_opt_clks, @@ -515,8 +525,10 @@ static struct omap_hwmod omap54xx_dss_hdmi_hwmod = { .main_clk = "dss_48mhz_clk", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .modulemode = MODULEMODE_SWCTRL, + .mmode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_hdmi_opt_clks, @@ -554,8 +566,10 @@ static struct omap_hwmod omap54xx_dss_rfbi_hwmod = { .clkdm_name = "dss_clkdm", .prcm = { .omap4 = { - .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, - .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET, + .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT, + .modulemode = MODULEMODE_SWCTRL, + .mmode_ref = &dss_modulemode_ref, }, }, .opt_clks = dss_rfbi_opt_clks, -- 1.9.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
end of thread, other threads:[~2014-06-17 9:56 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-03-12 10:26 [PATCH] ARM: OMAP5: DSS hwmod data Tomi Valkeinen 2014-03-12 10:26 ` Tomi Valkeinen 2014-03-12 10:26 ` [PATCH] ARM: OMAP5: Add omap5 DSS related " Tomi Valkeinen 2014-03-12 10:26 ` Tomi Valkeinen 2014-03-12 10:33 ` [PATCH] ARM: OMAP5: DSS " Tomi Valkeinen 2014-03-12 10:33 ` Tomi Valkeinen 2014-03-16 11:41 ` Dmitry Lifshitz 2014-03-16 11:41 ` Dmitry Lifshitz 2014-03-17 6:13 ` Tomi Valkeinen 2014-03-17 6:13 ` Tomi Valkeinen 2014-03-17 13:22 ` Dmitry Lifshitz 2014-03-17 13:22 ` Dmitry Lifshitz 2014-03-17 13:28 ` Tomi Valkeinen 2014-03-17 13:28 ` Tomi Valkeinen 2014-03-17 14:22 ` Dmitry Lifshitz 2014-03-17 14:22 ` Dmitry Lifshitz 2014-03-18 5:29 ` Tomi Valkeinen 2014-03-18 5:29 ` Tomi Valkeinen 2014-03-18 8:19 ` Dmitry Lifshitz 2014-03-18 8:19 ` Dmitry Lifshitz 2014-03-18 8:37 ` Tomi Valkeinen 2014-03-18 8:37 ` Tomi Valkeinen 2014-03-18 12:23 ` Dmitry Lifshitz 2014-03-18 12:23 ` Dmitry Lifshitz 2014-05-08 4:37 ` Paul Walmsley 2014-05-08 4:37 ` Paul Walmsley 2014-05-08 5:48 ` Archit Taneja 2014-05-08 5:48 ` Archit Taneja 2014-05-08 16:01 ` Paul Walmsley 2014-05-08 16:01 ` Paul Walmsley 2014-05-09 6:19 ` Archit Taneja 2014-05-09 6:19 ` Archit Taneja 2014-05-09 6:36 ` Tomi Valkeinen 2014-05-09 6:36 ` Tomi Valkeinen 2014-05-14 19:44 ` Paul Walmsley 2014-05-14 19:44 ` Paul Walmsley 2014-05-26 10:44 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja 2014-05-26 10:44 ` [RFC 2/2] ARM: OMAP5: hwmod data: Make DSS hwmods share MODULEMODE fields Archit Taneja 2014-05-27 10:20 ` [RFC 1/2] ARM: OMAP2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Rajendra Nayak 2014-05-27 10:49 ` Archit Taneja 2014-06-17 9:54 ` [RFC v2 0/2] arm: omap2+: hwmod: Allow hwmods to share same modulemode register filed Archit Taneja 2014-06-17 9:54 ` [RFC v2 1/2] arm: omap2+: hwmod: Add refcounting for modulemode shared by multiple hwmods Archit Taneja 2014-06-17 9:54 ` [RFC v2 2/2] arm: omap5 hwmod data: Example: Make DSS hwmods share MODULEMODE fields Archit Taneja
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.