OMAPDSS: OMAP5 display support
Subsystems (7)
cover OMAPDSS: OMAP5 display support
Hi,
This series implements OMAP5 display support. The series is based on -rc2.
Tested on OMAP5 uEVM with HDMI output, and OMAP5 uEVM with a custom DSI panel (patches for the panel are not included here).
Tomi
Archit Taneja (4):
ARM: OMAP: hwmod: OMAP5 DSS hwmod data
OMAPDSS: HDMI: support larger register offsets for OMAP5 HDMI core
OMAPDSS: HDMI: PHY changes for OMAP5
OMAPDSS: HDMI: PLL changes for OMAP5
Tomi Valkeinen (19):
OMAPDSS: HDMI: lane config support
Doc/DT: ti,omap4-dss: hdmi lanes
OMAPDSS: HDMI4: set regulator voltage to 1.8V
OMAPDSS: DSI: set regulator voltage to 1.8V
ARM: OMAP: add OMAP5 DSI muxing
ARM: OMAP: add detection of omap5-dss
ARM: dts: omap5-clocks.dtsi: add dss iclk
ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk
ARM: dts: omap5.dtsi: add DSS nodes
ARM: dts: omap5-uevm.dts: add tca6424a
ARM: dts: omap5-uevm.dts: add display nodes
OMAPDSS: DSS & DISPC DT support for OMAP5
OMAPDSS: features: fix OMAP5 features
OMAPDSS: DPI: fix LCD3 DSI source
OMAPDSS: DSI: Add OMAP5 DSI module IDs
OMAPDSS: HDMI: improve Makefile
OMAPDSS: HDMI: move irq & phy pwr handling
OMAPDSS: HDMI: Add OMAP5 HDMI support
Doc/DT: Add OMAP5 DSS DT bindings
.../devicetree/bindings/video/ti,omap4-dss.txt | 4 + .../devicetree/bindings/video/ti,omap5-dss.txt | 96 +++ arch/arm/boot/dts/omap5-uevm.dts | 89 ++ arch/arm/boot/dts/omap5.dtsi | 70 ++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 9 + arch/arm/mach-omap2/display.c | 39 +- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +++++++ drivers/video/fbdev/omap2/dss/Kconfig | 22 +- drivers/video/fbdev/omap2/dss/Makefile | 6 +- drivers/video/fbdev/omap2/dss/core.c | 6 + drivers/video/fbdev/omap2/dss/dispc.c | 1 + drivers/video/fbdev/omap2/dss/dpi.c | 2 + drivers/video/fbdev/omap2/dss/dsi.c | 17 + drivers/video/fbdev/omap2/dss/dss.c | 1 + drivers/video/fbdev/omap2/dss/dss.h | 3 + drivers/video/fbdev/omap2/dss/dss_features.c | 3 +- drivers/video/fbdev/omap2/dss/hdmi.h | 17 +- drivers/video/fbdev/omap2/dss/hdmi4.c | 113 ++- drivers/video/fbdev/omap2/dss/hdmi5.c | 829 ++++++++++++++++++ drivers/video/fbdev/omap2/dss/hdmi5_core.c | 922 +++++++++++++++++++++ drivers/video/fbdev/omap2/dss/hdmi5_core.h | 306 +++++++ drivers/video/fbdev/omap2/dss/hdmi_common.c | 41 + drivers/video/fbdev/omap2/dss/hdmi_phy.c | 231 ++++-- drivers/video/fbdev/omap2/dss/hdmi_pll.c | 81 +- drivers/video/fbdev/omap2/dss/hdmi_wp.c | 2 +- 25 files changed, 3111 insertions(+), 82 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/ti,omap5-dss.txt create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5.c create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5_core.c create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5_core.h
Signature · 1 line
1.9.1
PATCH 1/23 OMAPDSS: HDMI: lane config support
Add support to configure the pins used for the HDMI lanes. The order and polarity of the lanes can be defined in the DT data.
--- drivers/video/fbdev/omap2/dss/hdmi.h | 6 ++ drivers/video/fbdev/omap2/dss/hdmi4.c | 28 +++++++++ drivers/video/fbdev/omap2/dss/hdmi_common.c | 41 +++++++++++++ drivers/video/fbdev/omap2/dss/hdmi_phy.c | 94 ++++++++++++++++++++++++++++- 4 files changed, 167 insertions(+), 2 deletions(-)
drivers/video/fbdev/omap2/dss/hdmi.h +6 -0
@@ -352,6 +352,9 @@ struct hdmi_phy_data {void __iomem *base;int irq; + +u8 lane_function[4 ]; +u8 lane_polarity[4 ]; };struct hdmi_core_data {
@@ -422,11 +425,14 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,void hdmi_phy_disable (struct hdmi_phy_data *phy,struct hdmi_wp_data *wp);void hdmi_phy_dump (struct hdmi_phy_data *phy,struct seq_file *s);int hdmi_phy_init (struct platform_device *pdev,struct hdmi_phy_data *phy); +int hdmi_phy_parse_lanes (struct hdmi_phy_data *phy,const u32 *lanes);/* HDMI common funcs */ const struct hdmi_config *hdmi_default_timing (void );const struct hdmi_config *hdmi_get_timings (int mode,int code);struct hdmi_cm hdmi_get_code (struct omap_video_timings *timing); +int hdmi_parse_lanes_of (struct platform_device *pdev,struct device_node *ep, +struct hdmi_phy_data *phy);#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO )int hdmi_compute_acr (u32 pclk,u32 sample_freq,u32 *n,u32 *cts);
drivers/video/fbdev/omap2/dss/hdmi4.c +28 -0
@@ -600,6 +600,28 @@ static void __exit hdmi_uninit_output(struct platform_device *pdev)omapdss_unregister_output (out); } +static int hdmi_probe_of (struct platform_device *pdev) +{ +struct device_node *node = pdev->dev.of_node; +struct device_node *ep; +int r; + + ep =omapdss_of_get_first_endpoint (node); +if (!ep) +return 0 ; + + r =hdmi_parse_lanes_of (pdev, ep, &hdmi.phy); +if (r) + goto err; + +of_node_put (ep); +return 0 ; + +err: +of_node_put (ep); +return r; +} +/* HDMI HW IP initialisation */ static int omapdss_hdmihw_probe (struct platform_device *pdev) {
@@ -609,6 +631,12 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)mutex_init (&hdmi.lock); +if (pdev->dev.of_node) { + r =hdmi_probe_of (pdev); +if (r) +return r; + } + r =hdmi_wp_init (pdev, &hdmi.wp);if (r)return r;
drivers/video/fbdev/omap2/dss/hdmi_common.c +41 -0
53 lines not on this page · raw message
drivers/video/fbdev/omap2/dss/hdmi_phy.c +92 -2
106 lines not on this page · raw message
Signature · 1 line
1.9.1
PATCH 1/23 OMAPDSS: HDMI: lane config support
Hi,
Quoted 46 lines · Tomi Valkeinen
Add support to configure the pins used for the HDMI lanes. The order and polarity of the lanes can be defined in the DT data.
Signed-off-by Tomi Valkeinen <[email protected]>---
drivers/video/fbdev/omap2/dss/hdmi_phy.c +40
-0+static void hdmi_phy_configure_lanes (struct hdmi_phy_data *phy) +{ +static const u16 pad_cfg_list[] = { +0x0123 , +0x0132 , +0x0312 , +0x0321 , +0x0231 , +0x0213 , +0x1023 , +0x1032 , +0x3012 , +0x3021 , +0x2031 , +0x2013 , +0x1203 , +0x1302 , +0x3102 , +0x3201 , +0x2301 , +0x2103 , +0x1230 , +0x1320 , +0x3120 , +0x3210 , +0x2310 , +0x2130 , + }; + +u16 lane_cfg =0 ; +int i; +unsigned lane_cfg_val; +u16 pol_val =0 ; + +for (i =0 ; i <4 ; ++i) + lane_cfg |= phy->lane_function[i] << ((3 - i) *4 ); + + pol_val |= phy->lane_polarity[0 ] <<0 ; + pol_val |= phy->lane_polarity[1 ] <<3 ; + pol_val |= phy->lane_polarity[2 ] <<2 ;
drivers/video/fbdev/omap2/dss/hdmi_phy.c static irqreturn_t hdmi_irq_handler(int irq, void *data) · line 147
Quoted 10 lines
drivers/video/fbdev/omap2/dss/hdmi_phy.c +10
-0+ pol_val |= phy->lane_polarity[3 ] <<1 ; + +for (i =0 ; i <ARRAY_SIZE (pad_cfg_list); ++i) +if (pad_cfg_list[i] == lane_cfg) +break ; + +if (WARN_ON (i ==ARRAY_SIZE (pad_cfg_list))) + i =0 ; + + lane_cfg_val = i;
I spent some time to see if we could get create lane_cfg_val without having the table above, looks like there is no pattern at all in the register field.
Quoted 9 lines
drivers/video/fbdev/omap2/dss/hdmi_phy.c +5
-0+ +REG_FLD_MOD (phy->base,HDMI_TXPHY_PAD_CFG_CTRL , lane_cfg_val,26 ,22 ); +REG_FLD_MOD (phy->base,HDMI_TXPHY_PAD_CFG_CTRL , pol_val,30 ,27 ); +} +int hdmi_phy_enable (struct hdmi_phy_data *phy,struct hdmi_wp_data *wp,struct hdmi_config *cfg) {
drivers/video/fbdev/omap2/dss/hdmi_phy.c int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp, · line 96
Quoted 5 lines
drivers/video/fbdev/omap2/dss/hdmi_phy.c +0
-2@@ -92,8 +183,7 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp,/* Setup max LDO voltage */ REG_FLD_MOD (phy->base,HDMI_TXPHY_POWER_CTRL ,0xB ,3 ,0 ); -/* Write to phy address 3 to change the polarity control */ -REG_FLD_MOD (phy->base,HDMI_TXPHY_PAD_CFG_CTRL ,0x1 ,27 ,27 );
wow, didn't realize it was hardcoded like this.
Archit
PATCH 1/23 OMAPDSS: HDMI: lane config support
Quoted 3 lines · Archit Taneja
I spent some time to see if we could get create
lane_cfg_valwithout having the table above, looks like there is no pattern at all in the register field.
There is a pattern, but I wasn't able to figure out a formula to model it. And as the array was not very long, and was easy to create with copy paste and search-replace from the TRM, I thought it's just simplest way to do it.
Quoted 14 lines
Quoted 14 lines
(quoted diff) +2
-0+ + REG_FLD_MOD(phy->base, HDMI_TXPHY_PAD_CFG_CTRL, lane_cfg_val, 26,22);
drivers/video/fbdev/omap2/dss/hdmi_phy.c +3
-0+REG_FLD_MOD (phy->base,HDMI_TXPHY_PAD_CFG_CTRL , pol_val,30 ,27 ); +} +int hdmi_phy_enable (struct hdmi_phy_data *phy,struct hdmi_wp_data *wp,struct hdmi_config *cfg) {@@ -92,8 +183,7 @@ int hdmi_phy_enable(struct hdmi_phy_data *phy,struct hdmi_wp_data *wp,/* Setup max LDO voltage */ REG_FLD_MOD(phy->base, HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
Quoted 6 lines
drivers/video/fbdev/omap2/dss/hdmi_phy.c int hdmi_phy_enable(struct hdmi_phy_data *phy, struct hdmi_wp_data *wp, · line 96
Quoted 2 lines
drivers/video/fbdev/omap2/dss/hdmi_phy.c +0
-2-/* Write to phy address 3 to change the polarity control */ -REG_FLD_MOD (phy->base,HDMI_TXPHY_PAD_CFG_CTRL ,0x1 ,27 ,27 );wow, didn't realize it was hardcoded like this.
Reviewed-by Archit Taneja <[email protected]?
Thanks!
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/20140425/78769b28/attachment.sig>
PATCH 2/23 Doc/DT: ti,omap4-dss: hdmi lanes
In reply to Tomi ValkeinenAdd documentation for defining HDMI lane functions and polarities.
--- Documentation/devicetree/bindings/video/ti,omap4-dss.txt | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/devicetree/bindings/video/ti,omap4-dss.txt +4 -0
@@ -109,3 +109,7 @@ Required properties: Optional nodes: - Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7)
Signature · 1 line
1.9.1
PATCH 3/23 OMAPDSS: HDMI4: set regulator voltage to 1.8V
In reply to Tomi ValkeinenSet the HDMI vdda regulator voltage to the required 1.8V.
This is required for the case when the regulator in the DT data defines a range of allowed voltages. In this case it's required to set the voltage, as otherwise enabling the voltage fails.
--- drivers/video/fbdev/omap2/dss/hdmi4.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/video/fbdev/omap2/dss/hdmi4.c +10 -0
@@ -83,6 +83,7 @@ static void hdmi_runtime_put(void)static int hdmi_init_regulator (void ) { +int r;struct regulator *reg;if (hdmi.vdda_hdmi_dac_reg !=NULL )
@@ -96,6 +97,15 @@ static int hdmi_init_regulator(void)return PTR_ERR (reg); } +if (regulator_can_change_voltage (reg)) { + r =regulator_set_voltage (reg,1800000 ,1800000 ); +if (r) { +devm_regulator_put (reg); +DSSWARN ("can't set the regulator voltage\n" ); +return r; + } + } + hdmi.vdda_hdmi_dac_reg = reg;return 0 ;
Signature · 1 line
1.9.1
PATCH 4/23 OMAPDSS: DSI: set regulator voltage to 1.8V
In reply to Tomi ValkeinenSet the DSI vdd regulator voltage to the required 1.8V.
This is required for the case when the regulator in the DT data defines a range of allowed voltages. In this case it's required to set the voltage, as otherwise enabling the voltage fails.
--- drivers/video/fbdev/omap2/dss/dsi.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/video/fbdev/omap2/dss/dsi.c +10 -0
@@ -1161,6 +1161,7 @@ static int dsi_regulator_init(struct platform_device *dsidev) {struct dsi_data *dsi =dsi_get_dsidrv_data (dsidev);struct regulator *vdds_dsi; +int r;if (dsi->vdds_dsi_reg !=NULL )return 0 ;
@@ -1173,6 +1174,15 @@ static int dsi_regulator_init(struct platform_device *dsidev)return PTR_ERR (vdds_dsi); } +if (regulator_can_change_voltage (vdds_dsi)) { + r =regulator_set_voltage (vdds_dsi,1800000 ,1800000 ); +if (r) { +devm_regulator_put (vdds_dsi); +DSSERR ("can't set the DSI regulator voltage\n" ); +return r; + } + } + dsi->vdds_dsi_reg = vdds_dsi;return 0 ;
Signature · 1 line
1.9.1
PATCH 5/23 ARM: OMAP: hwmod: OMAP5 DSS hwmod data
In reply to Tomi ValkeinenFrom: Archit Taneja <[email protected]>
Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more or less similar to omap4 hwmod data.
--- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+)
arch/arm/mach-omap2/omap_hwmod_54xx_data.c +283 -0
@@ -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) */
@@ -1974,6 +2203,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,
@@ -2427,6 +2704,12 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] __initdata = { &omap54xx_l4_cfg__dma_system, &omap54xx_l4_abe__dmic, &omap54xx_l4_cfg__mmu_dsp, + &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,
Signature · 1 line
1.9.1
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
In reply to Tomi ValkeinenAdd support to set OMAP5 DSI pin muxing.
--- arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)
arch/arm/mach-omap2/display.c +34 -1
@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)return 0 ; } +#define CONTROL_PAD_BASE 0x4A002800 +#define CONTROL_DSIPHY 0x614 + +static int omap5_dsi_mux_pads (int dsi_id,unsigned lanes) +{ +u32 enable_mask, enable_shift, reg; +void __iomem *ctrl_pad_base =NULL ; + + ctrl_pad_base =ioremap (CONTROL_PAD_BASE ,SZ_4K ); +if (!ctrl_pad_base) +return -ENXIO ; + +if (dsi_id ==0 ) { + enable_mask =OMAP4_DSI1_LANEENABLE_MASK ; + enable_shift =OMAP4_DSI1_LANEENABLE_SHIFT ; + }else if (dsi_id ==1 ) { + enable_mask =OMAP4_DSI2_LANEENABLE_MASK ; + enable_shift =OMAP4_DSI2_LANEENABLE_SHIFT ; + }else { +return -ENODEV ; + } + + reg =__raw_readl (ctrl_pad_base +CONTROL_DSIPHY ); + reg &= ~enable_mask; + reg |= (lanes << enable_shift) & enable_mask; +__raw_writel (reg, ctrl_pad_base +CONTROL_DSIPHY ); + +return 0 ; +} +static int omap_dsi_enable_pads (int dsi_id,unsigned lane_mask) {if (cpu_is_omap44xx ())return omap4_dsi_mux_pads (dsi_id, lane_mask); - +else if (soc_is_omap54xx ()) +return omap5_dsi_mux_pads (dsi_id, lane_mask);return 0 ; }
@@ -149,6 +180,8 @@ static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask) {if (cpu_is_omap44xx ())omap4_dsi_mux_pads (dsi_id,0 ); +else if (soc_is_omap54xx ()) +omap5_dsi_mux_pads (dsi_id,0 ); }static int omap_dss_set_min_bus_tput (struct device *dev,unsigned long tput)
Signature · 1 line
1.9.1
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Hi,
Quoted 13 lines · Tomi Valkeinen
Add support to set OMAP5 DSI pin muxing.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)arch/arm/mach-omap2/display.c +0
-0
arch/arm/mach-omap2/display.c static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) · line 142
Quoted 6 lines
arch/arm/mach-omap2/display.c +3
-0@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)return 0 ; } +#define CONTROL_PAD_BASE 0x4A002800 +#define CONTROL_DSIPHY 0x614 +
I guess this is something we can move to our driver, and use sysconf to get the register from DT.
Archit
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 21 lines · Archit Taneja
Hi,
Quoted 18 lines · Tomi Valkeinen
Add support to set OMAP5 DSI pin muxing.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)arch/arm/mach-omap2/display.c +0
-0@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)return 0 ; }
Quoted 6 lines
arch/arm/mach-omap2/display.c static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) · line 142
Quoted 3 lines
arch/arm/mach-omap2/display.c +3
-0+#define CONTROL_PAD_BASE 0x4A002800 +#define CONTROL_DSIPHY 0x614 +I guess this is something we can move to our driver, and use sysconf to get the register from DT.
I just copied the same method as used for OMAP4.
I guess sysconf is an option. But I really dislike the idea of moving omap control module code to a display driver... I'm not sure what other options we have, though. Maybe an OMAP DSI specific pinctrl driver?
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/20140425/ef09216a/attachment.sig>
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 29 lines · Tomi Valkeinen
Quoted 21 lines · Archit Taneja
Hi,
Quoted 18 lines · Tomi Valkeinen
Add support to set OMAP5 DSI pin muxing.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)arch/arm/mach-omap2/display.c +0
-0@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)return 0 ; }Quoted 6 lines
arch/arm/mach-omap2/display.c static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) · line 142
Quoted 3 lines
arch/arm/mach-omap2/display.c +3
-0+#define CONTROL_PAD_BASE 0x4A002800 +#define CONTROL_DSIPHY 0x614 +I guess this is something we can move to our driver, and use sysconf to get the register from DT.
Quoted 5 lines
I just copied the same method as used for OMAP4.
I guess sysconf is an option. But I really dislike the idea of moving omap control module code to a display driver... I'm not sure what other options we have, though. Maybe an OMAP DSI specific pinctrl driver?
OMAP4 has CONTROL_DSIPHY for configuring both lane enable/disbale, and pull up/down, but OMAP5 has normal PAD_CONF registers for DSI lines(2 pins per register) for configuring pull up/down, and CONTROL_DSIPHY for lane enable/disable.
We would have a very messed up pinctrl driver, but it would probably be better than doing all this stuff in the driver.
Archit
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 37 lines · Archit Taneja
Quoted 30 lines · Tomi Valkeinen
Quoted 22 lines · Archit Taneja
Hi,
Quoted 19 lines · Tomi Valkeinen
Add support to set OMAP5 DSI pin muxing.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)arch/arm/mach-omap2/display.c +0
-0@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)return 0 ; }Quoted 6 lines
arch/arm/mach-omap2/display.c static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) · line 142
Quoted 3 lines
arch/arm/mach-omap2/display.c +3
-0+#define CONTROL_PAD_BASE 0x4A002800 +#define CONTROL_DSIPHY 0x614 +I guess this is something we can move to our driver, and use sysconf to get the register from DT.
Quoted 5 lines
I just copied the same method as used for OMAP4.
I guess sysconf is an option. But I really dislike the idea of moving omap control module code to a display driver... I'm not sure what other options we have, though. Maybe an OMAP DSI specific pinctrl driver?
Quoted 7 lines
OMAP4 has
CONTROL_DSIPHYfor configuring both lane enable/disbale, and pull up/down, but OMAP5 has normalPAD_CONFregisters for DSI lines(2 pins per register) for configuring pull up/down, andCONTROL_DSIPHYfor lane enable/disable.We would have a very messed up pinctrl driver, but it would probably be better than doing all this stuff in the driver.
Actually, this patch is not good. I should've looked at the code more carefully =).
This one does ioremap every time the function is called, which could be done multiple times.
And I think omap4_ctrl_pad_readl() can be used to access the registers. Like this (not tested):
#define OMAP5_CONTROL_DSIPHY 0x614
static int omap5_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift, reg;
if (dsi_id == 0) {
enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
} else if (dsi_id == 1) {
enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
} else {
return -ENODEV;
}
reg = omap4_ctrl_pad_readl(OMAP5_CONTROL_DSIPHY);
reg &= ~enable_mask;
reg |= (lanes << enable_shift) & enable_mask;
omap4_ctrl_pad_writel(reg, OMAP5_CONTROL_DSIPHY);
return 0;
}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/20140425/7f6fc7a2/attachment.sig>
Tony Lindgren
maintainerPATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 71 lines · Tomi Valkeinen
Quoted 37 lines · Archit Taneja
Quoted 30 lines · Tomi Valkeinen
Quoted 22 lines · Archit Taneja
Hi,
Quoted 19 lines · Tomi Valkeinen
Add support to set OMAP5 DSI pin muxing.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/mach-omap2/display.c | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-)arch/arm/mach-omap2/display.c +0
-0@@ -137,11 +137,42 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)return 0 ; }Quoted 6 lines
arch/arm/mach-omap2/display.c static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes) · line 142
Quoted 3 lines
arch/arm/mach-omap2/display.c +3
-0+#define CONTROL_PAD_BASE 0x4A002800 +#define CONTROL_DSIPHY 0x614 +I guess this is something we can move to our driver, and use sysconf to get the register from DT.
Quoted 5 lines
I just copied the same method as used for OMAP4.
I guess sysconf is an option. But I really dislike the idea of moving omap control module code to a display driver... I'm not sure what other options we have, though. Maybe an OMAP DSI specific pinctrl driver?
Quoted 7 lines
OMAP4 has
CONTROL_DSIPHYfor configuring both lane enable/disbale, and pull up/down, but OMAP5 has normalPAD_CONFregisters for DSI lines(2 pins per register) for configuring pull up/down, andCONTROL_DSIPHYfor lane enable/disable.We would have a very messed up pinctrl driver, but it would probably be better than doing all this stuff in the driver.
Actually, this patch is not good. I should've looked at the code more carefully =).
This one does ioremap every time the function is called, which could be done multiple times.
And I think
omap4_ctrl_pad_readl()can be used to access the registers. Like this (not tested):#define
OMAP5_CONTROL_DSIPHY0x614static int
omap5_dsi_mux_pads(int dsi_id, unsigned lanes){ u32 enable_mask, enable_shift, reg; if (dsi_id == 0) { enable_mask = OMAP4_DSI1_LANEENABLE_MASK; enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT; } else if (dsi_id == 1) { enable_mask = OMAP4_DSI2_LANEENABLE_MASK; enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT; } else { return -ENODEV; }
Quoted 7 lines
reg = omap4_ctrl_pad_readl(OMAP5_CONTROL_DSIPHY); reg &= ~enable_mask; reg |= (lanes << enable_shift) & enable_mask; omap4_ctrl_pad_writel(reg, OMAP5_CONTROL_DSIPHY); return 0; }
Chances are any mux register in the syscon area already works with pinctrl-single,pins or pinctrl-single,bits option. The ones in the padconf area should be already mapped so the driver just has to request them.
Regards,
Tony
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 4 lines · Tony Lindgren
Chances are any mux register in the syscon area already works with pinctrl-single,pins or pinctrl-single,bits option. The ones in the padconf area should be already mapped so the driver just has to request them.
If using the padconf (say omap4_padconf_global for omap4), doesn't that mean we need to have platform specific bits in the driver? Isn't that something we've been trying to remove all the time?
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/20140428/4bea3d89/attachment.sig>
Tony Lindgren
maintainerPATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 10 lines · Tomi Valkeinen
Quoted 4 lines · Tony Lindgren
Chances are any mux register in the syscon area already works with pinctrl-single,pins or pinctrl-single,bits option. The ones in the padconf area should be already mapped so the driver just has to request them.
If using the padconf (say
omap4_padconf_globalfor omap4), doesn't that mean we need to have platform specific bits in the driver? Isn't that something we've been trying to remove all the time?
No, it's all done in a Linux generic way during driver probe, see drivers/base/pinctrl.c. You just need to define the default pins in the .dts files. If you need dynamic remuxing in the driver, you can define other named states that the driver can then toggle with pinctrl_select_state().
Regards,
Tony
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 12 lines · Tony Lindgren
Quoted 10 lines · Tomi Valkeinen
Quoted 4 lines · Tony Lindgren
Chances are any mux register in the syscon area already works with pinctrl-single,pins or pinctrl-single,bits option. The ones in the padconf area should be already mapped so the driver just has to request them.
If using the padconf (say
omap4_padconf_globalfor omap4), doesn't that mean we need to have platform specific bits in the driver? Isn't that something we've been trying to remove all the time?
Quoted 5 lines
No, it's all done in a Linux generic way during driver probe, see
drivers/base/pinctrl.c. You just need to define the default pins in the .dts files. If you need dynamic remuxing in the driver, you can define other named states that the driver can then toggle withpinctrl_select_state().
omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it.
Pinctrl-single cannot be used for CONTROL_DSIPHY register, as the register contents are a bit funny and DSI1 and DSI2 bits are mixed together. And CONTROL_DSIPHY is already in the memory region defined by the omap4_padconf_global, so I guess it wouldn't be good to map parts of the same memory region in a pinctrl node.
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/20140429/78e8b482/attachment.sig>
Tony Lindgren
maintainerPATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 19 lines · Tomi Valkeinen
Quoted 12 lines · Tony Lindgren
Quoted 10 lines · Tomi Valkeinen
Quoted 4 lines · Tony Lindgren
Chances are any mux register in the syscon area already works with pinctrl-single,pins or pinctrl-single,bits option. The ones in the padconf area should be already mapped so the driver just has to request them.
If using the padconf (say
omap4_padconf_globalfor omap4), doesn't that mean we need to have platform specific bits in the driver? Isn't that something we've been trying to remove all the time?Quoted 5 lines
No, it's all done in a Linux generic way during driver probe, see
drivers/base/pinctrl.c. You just need to define the default pins in the .dts files. If you need dynamic remuxing in the driver, you can define other named states that the driver can then toggle withpinctrl_select_state().
Quoted 3 lines
omap4_padconf_globalis a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it.
That would be probably best set up the same way we have already set up for example omap4_padconf_global: tisyscon at 4a1005a0. Then drivers can access it using regmap, see how drivers/regulator/pbias-regulator.c sets up the pbias regulator with regmap for MMC.
Quoted 5 lines
Pinctrl-single cannot be used for
CONTROL_DSIPHYregister, as the register contents are a bit funny and DSI1 and DSI2 bits are mixed together. AndCONTROL_DSIPHYis already in the memory region defined by theomap4_padconf_global, so I guess it wouldn't be good to map parts of the same memory region in a pinctrl node.
If it's more than a mux, then it should not be set up as a pinctrl register. Looks like CONTROL_DSIPHY is already available for drivers via regmap as it falls into the *_padconf_global mappings for omap4 and omap5.
Regards,
Tony
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 8 lines · Tony Lindgren
Quoted 3 lines
omap4_padconf_globalis a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it.That would be probably best set up the same way we have already set up for example
omap4_padconf_global: tisyscon at4a1005a0. Then drivers can access it using regmap, see howdrivers/regulator/pbias-regulator.csets up the pbias regulator with regmap for MMC.
Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong?
I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver.
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/20140429/ec3a6b0c/attachment.sig>
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 11 lines · Tomi Valkeinen
Quoted 8 lines · Tony Lindgren
Quoted 3 lines
omap4_padconf_globalis a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it.That would be probably best set up the same way we have already set up for example
omap4_padconf_global: tisyscon at4a1005a0. Then drivers can access it using regmap, see howdrivers/regulator/pbias-regulator.csets up the pbias regulator with regmap for MMC.
Quoted 6 lines
Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong?
I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver.
Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver.
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/20140429/a1aa03e7/attachment.sig>
Tony Lindgren
maintainerPATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 12 lines · Tomi Valkeinen
Quoted 11 lines · Tomi Valkeinen
Quoted 8 lines · Tony Lindgren
Quoted 3 lines
omap4_padconf_globalis a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it.That would be probably best set up the same way we have already set up for example
omap4_padconf_global: tisyscon at4a1005a0. Then drivers can access it using regmap, see howdrivers/regulator/pbias-regulator.csets up the pbias regulator with regmap for MMC.
Quoted 6 lines
Quoted 6 lines
Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong?
I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver.
Anything using the system control module registers should be a separate driver. And it should ideally be implemeting some Linux generic framework that the consumer driver can then use. That leaves out the need to export custom functions.
I guess we don't have a PHY framework for displays though, so how about just a separate minimal driver under drivers/video/omap2 that uses the syscon?
Quoted 2 lines
Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver.
Don't you get all you need in the compatible string? Something like compatible ti,dss-phy-omap5?
Regards,
Tony
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Tomi Valkeinen
Quoted 14 lines · Tomi Valkeinen
Quoted 8 lines · Tony Lindgren
Quoted 3 lines
omap4_padconf_globalis a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it.That would be probably best set up the same way we have already set up for example
omap4_padconf_global: tisyscon at4a1005a0. Then drivers can access it using regmap, see howdrivers/regulator/pbias-regulator.csets up the pbias regulator with regmap for MMC.Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong?
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver.
Anything using the system control module registers should be a separate driver. And it should ideally be implemeting some Linux generic framework that the consumer driver can then use. That leaves out the need to export custom functions.
Ok.
Quoted 3 lines
I guess we don't have a PHY framework for displays though, so how about just a separate minimal driver under
drivers/video/omap2that uses the syscon?
Well, this one is not really about DSI PHY. The CONTROL_DSIPHY register is not in the DSI PHY block, but in the control module, and it is used to enable/disable the pins (for omap4/5) and to set pull up/down for the pins (only for omap4). Oddly, for omap5, there's also a normal padconfig register for the DSI pins, but not so for omap4.
To me it looks like a pad config register. I don't know why there's a separate odd register for it and it's not using the normal padconfig system.
I'd like to use the pinctrl framework for it, but the pinctrl-single cannot handle such a funny register. So, if "Anything using the system control module registers should be a separate driver", then I guess I need to write a pinctrl driver for this single register?
Quoted 5 lines
Quoted 2 lines
Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver.
Don't you get all you need in the compatible string? Something like compatible ti,dss-phy-omap5?
We do use different compatible strings for different major versions of the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could be used on some other SoC, with different control stuff.
We could use separate compatible string for each SoC that uses DSS, but then we're really encoding the SoC version into the compatible string, not DSS version.
Of course, if there will be a separate driver managing the CONTROL_DSIPHY register, then that one should use compatible string specific to the SoC, as it's not a DSS driver at all.
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/20140430/e2251baa/attachment.sig>
Tony Lindgren
maintainerPATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 38 lines · Tomi Valkeinen
Quoted 16 lines · Tony Lindgren
Quoted 15 lines · Tomi Valkeinen
Quoted 14 lines · Tomi Valkeinen
Quoted 8 lines · Tony Lindgren
Quoted 3 lines
omap4_padconf_globalis a syscon node, not pinctrl. As syscon just gives a raw regmap to its memory area, the driver needs to know about the OMAP control registers to use it.That would be probably best set up the same way we have already set up for example
omap4_padconf_global: tisyscon at4a1005a0. Then drivers can access it using regmap, see howdrivers/regulator/pbias-regulator.csets up the pbias regulator with regmap for MMC.Right, but it means that the driver will contain platform specific code for all the omap revisions it supports. Isn't that wrong?
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
I already have a patch for DSI that uses the syscon-method, and it works fine. But it's quite ugly, imo, to fiddle with the OMAP control registers in a driver.
Anything using the system control module registers should be a separate driver. And it should ideally be implemeting some Linux generic framework that the consumer driver can then use. That leaves out the need to export custom functions.
Ok.
Quoted 3 lines
I guess we don't have a PHY framework for displays though, so how about just a separate minimal driver under
drivers/video/omap2that uses the syscon?Well, this one is not really about DSI PHY. The
CONTROL_DSIPHYregister is not in the DSI PHY block, but in the control module, and it is used to enable/disable the pins (for omap4/5) and to set pull up/down for the pins (only for omap4). Oddly, for omap5, there's also a normal padconfig register for the DSI pins, but not so for omap4.
Quoted 7 lines
To me it looks like a pad config register. I don't know why there's a separate odd register for it and it's not using the normal padconfig system.
I'd like to use the pinctrl framework for it, but the pinctrl-single cannot handle such a funny register. So, if "Anything using the system control module registers should be a separate driver", then I guess I need to write a pinctrl driver for this single register?
Have you checked out pinctrl-single,bits binding? That should allow you to map random bits in a single register to a pinctrl driver instance.
Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver.
Don't you get all you need in the compatible string? Something like compatible ti,dss-phy-omap5?
We do use different compatible strings for different major versions of the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could be used on some other SoC, with different control stuff.
Quoted 7 lines
We could use separate compatible string for each SoC that uses DSS, but then we're really encoding the SoC version into the compatible string, not DSS version.
Of course, if there will be a separate driver managing the
CONTROL_DSIPHYregister, then that one should use compatible string specific to the SoC, as it's not a DSS driver at all.
Yeah probably using pinctrl-single,bits, or a separate driver with syscon makes most sense here.
Regards,
Tony
PATCH 6/23 ARM: OMAP: add OMAP5 DSI muxing
Quoted 3 lines · Tony Lindgren
Have you checked out pinctrl-single,bits binding? That should allow you to map random bits in a single register to a pinctrl driver instance.
If I recall right, the problem there was that we have one register, which has bits for two separate devices, and the bits are mixed up. i.e. not 16 upper bits for one, 16 lower for the other, but 5 bits for one device, the next 5 bits for the other, then again few bits for the first, etc.
pinctrl-single,bits didn't like it that.
Quoted 14 lines
Quoted 14 lines
Quoted 5 lines
Quoted 2 lines
Oh, also, if I do that, I need to know both the SoC version and the DSS version in the driver.
Don't you get all you need in the compatible string? Something like compatible ti,dss-phy-omap5?
We do use different compatible strings for different major versions of the DSS blocks, like ti,omap5-dsi. But that exactly same DSS block could be used on some other SoC, with different control stuff.
We could use separate compatible string for each SoC that uses DSS, but then we're really encoding the SoC version into the compatible string, not DSS version.
Quoted 6 lines
Quoted 3 lines
Of course, if there will be a separate driver managing the
CONTROL_DSIPHYregister, then that one should use compatible string specific to the SoC, as it's not a DSS driver at all.Yeah probably using pinctrl-single,bits, or a separate driver with syscon makes most sense here.
Yep, I'll have to come up with something.
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/20140502/7a4db19a/attachment.sig>
PATCH 7/23 ARM: OMAP: add detection of omap5-dss
In reply to Tomi ValkeinenAdd detection of omap5-dss nodes so that the related devices get initialized.
--- arch/arm/mach-omap2/display.c | 4 ++++ 1 file changed, 4 insertions(+)
arch/arm/mach-omap2/display.c +4 -0
@@ -665,6 +665,10 @@ struct device_node * __init omapdss_find_dss_of_node(void)if (node)return node; + node =of_find_compatible_node (NULL ,NULL ,"ti,omap5-dss" ); +if (node) +return node; +return NULL ; }
Signature · 1 line
1.9.1
PATCH 8/23 ARM: dts: omap5-clocks.dtsi: add dss iclk
In reply to Tomi ValkeinenAdd missing DSS interface clock node.
Note: The TRM says DSS's interface clock is DSS_L3_GICLK, but it is not clear to me from reading the TRM and looking at the arch/arm/boot/dts/omap54xx-clocks.dtsi whether using 'l3_iclk_div' as the parent for 'dss_l3_iclk' is the correct clock.
The clock is explicitly used only by the RFBI, and we don't have any boards using the RFBI, so I have no means to test it.
--- arch/arm/boot/dts/omap54xx-clocks.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/arm/boot/dts/omap54xx-clocks.dtsi +8 -0
@@ -418,6 +418,14 @@ clock-div = <1>; }; + dss_l3_iclk: dss_l3_iclk { + #clock-cells = <0>; + compatible = "fixed-factor-clock"; + clocks = <&l3_iclk_div>; + clock-mult = <1>; + clock-div = <1>; + }; + slimbus1_slimbus_clk: slimbus1_slimbus_clk { #clock-cells = <0>; compatible = "ti,gate-clock";
Signature · 1 line
1.9.1
PATCH 9/23 ARM: dts: omap5-clocks.dtsi: add ti, set-rate-parent to dss_dss_clk
In reply to Tomi ValkeinenAdd ti,set-rate-parent to dss_dss_clk so that the DSS driver can set the rate.
--- arch/arm/boot/dts/omap54xx-clocks.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm/boot/dts/omap54xx-clocks.dtsi +1 -0
@@ -859,6 +859,7 @@ clocks = <&dpll_per_h12x2_ck>; ti,bit-shift = <8>; reg = <0x1420>; + ti,set-rate-parent; }; dss_sys_clk: dss_sys_clk {
Signature · 1 line
1.9.1
PATCH 10/23 ARM: dts: omap5.dtsi: add DSS nodes
In reply to Tomi ValkeinenAdd OMAP5 DSS nodes to omap5.dtsi.
--- arch/arm/boot/dts/omap5.dtsi | 70 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+)
arch/arm/boot/dts/omap5.dtsi +70 -0
@@ -863,6 +863,76 @@ #thermal-sensor-cells = <1>; }; + + dss: dss at 58000000 { + compatible = "ti,omap5-dss"; + reg = <0x58000000 0x80>; + status = "disabled"; + ti,hwmods = "dss_core"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dispc at 58001000 { + compatible = "ti,omap5-dispc"; + reg = <0x58001000 0x1000>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + ti,hwmods = "dss_dispc"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + }; + + rfbi: encoder at 58002000 { + compatible = "ti,omap5-rfbi"; + reg = <0x58002000 0x100>; + status = "disabled"; + ti,hwmods = "dss_rfbi"; + clocks = <&dss_dss_clk>, <&dss_l3_iclk>; + clock-names = "fck", "ick"; + }; + + dsi1: encoder at 58004000 { + compatible = "ti,omap5-dsi"; + reg = <0x58004000 0x200>, + <0x58004200 0x40>, + <0x58004300 0x40>; + reg-names = "proto", "phy", "pll"; + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + ti,hwmods = "dss_dsi1"; + clocks = <&dss_dss_clk>, <&dss_sys_clk>; + clock-names = "fck", "sys_clk"; + }; + + dsi2: encoder at 58005000 { + compatible = "ti,omap5-dsi"; + reg = <0x58009000 0x200>, + <0x58009200 0x40>, + <0x58009300 0x40>; + reg-names = "proto", "phy", "pll"; + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + ti,hwmods = "dss_dsi2"; + clocks = <&dss_dss_clk>, <&dss_sys_clk>; + clock-names = "fck", "sys_clk"; + }; + + hdmi: encoder at 58060000 { + compatible = "ti,omap5-hdmi"; + reg = <0x58040000 0x400>, + <0x58040200 0x80>, + <0x58040300 0x80>, + <0x58060000 0x19000>; + reg-names = "wp", "pll", "phy", "core"; + interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + ti,hwmods = "dss_hdmi"; + clocks = <&dss_48mhz_clk>, <&dss_sys_clk>; + clock-names = "fck", "sys_clk"; + }; + }; }; };
Signature · 1 line
1.9.1
PATCH 11/23 ARM: dts: omap5-uevm.dts: add tca6424a
In reply to Tomi Valkeinenomap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
--- arch/arm/boot/dts/omap5-uevm.dts | 7 +++++++ 1 file changed, 7 insertions(+)
arch/arm/boot/dts/omap5-uevm.dts +7 -0
@@ -434,6 +434,13 @@ pinctrl-0 = <&i2c5_pins>; clock-frequency = <400000>; + + tca6424a: tca6424a at 22 { + compatible = "ti,tca6424"; + reg = <0x22>; + gpio-controller; + #gpio-cells = <2>; + }; }; &mcbsp3 {
Signature · 1 line
1.9.1
PATCH 11/23 ARM: dts: omap5-uevm.dts: add tca6424a
Hello.
Quoted 13 lines · Tomi Valkeinen
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/boot/dts/omap5-uevm.dts | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm/boot/dts/omap5-uevm.dts +0
-0
arch/arm/boot/dts/omap5-uevm.dts line 438
Quoted 5 lines
arch/arm/boot/dts/omap5-uevm.dts +2
-0@@ -434,6 +434,13 @@ pinctrl-0 = <&i2c5_pins>; clock-frequency = <400000>; + + tca6424a: tca6424a at 22 {
The ePAPR standard [1] says: "The name of a node should be somewhat generic,
reflecting the function of the device and not its precise programming model. If appropriate, the name should be one of the following choices:
[...]
- gpio;"
arch/arm/boot/dts/omap5-uevm.dts line 444
Quoted 6 lines
arch/arm/boot/dts/omap5-uevm.dts +5
-0+ compatible = "ti,tca6424"; + reg = <0x22>; + gpio-controller; + #gpio-cells = <2>; + }; };
[1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
WBR, Sergei
PATCH 11/23 ARM: dts: omap5-uevm.dts: add tca6424a
Quoted 20 lines · Sergei Shtylyov
Hello.
Quoted 16 lines · Tomi Valkeinen
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/boot/dts/omap5-uevm.dts | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm/boot/dts/omap5-uevm.dts +0
-0@@ -434,6 +434,13 @@ pinctrl-0 = <&i2c5_pins>;
Quoted 11 lines
arch/arm/boot/dts/omap5-uevm.dts line 438
Quoted 3 lines
arch/arm/boot/dts/omap5-uevm.dts +2
-0clock-frequency = <400000>; + + tca6424a: tca6424a at 22 {The ePAPR standard [1] says: "The name of a node should be somewhat
generic,
reflecting the function of the device and not its precise programming model.
If appropriate, the name should be one of the following choices:
[...]
- gpio;"
Right. I wonder what the name should be... "gpio" is out, as the name should be more specific. We already have gpio1-8, which are the gpio banks from the SoC. It could be 'gpio9', but that makes it sound it's just one more SoC gpio bank. 'gpio-expander1'?
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/20140424/3bf9345d/attachment.sig>
PATCH 11/23 ARM: dts: omap5-uevm.dts: add tca6424a
Hello.
Quoted 28 lines · Tomi Valkeinen
Quoted 16 lines
Quoted 16 lines
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by Tomi Valkeinen <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/boot/dts/omap5-uevm.dts | 7 +++++++ 1 file changed, 7 insertions(+)arch/arm/boot/dts/omap5-uevm.dts +0
-0@@ -434,6 +434,13 @@ pinctrl-0 = <&i2c5_pins>;Quoted 11 lines
arch/arm/boot/dts/omap5-uevm.dts line 438
Quoted 3 lines
arch/arm/boot/dts/omap5-uevm.dts +2
-0clock-frequency = <400000>; + + tca6424a: tca6424a at 22 {The ePAPR standard [1] says: "The name of a node should be somewhat
generic,
reflecting the function of the device and not its precise programming model.
If appropriate, the name should be one of the following choices:
[...]
- gpio;"
Quoted 2 lines
Right. I wonder what the name should be... "gpio" is out, as the name should be more specific.
No, it's not out. The name should be "gpio at 22", I think it would be unique.
Quoted 2 lines
We already have gpio1-8, which are the gpio
banks from the SoC.
I don't understand why you are indexing the names while you probably have
the address part after @ that makes them unique already.
Quoted 1 line
Tomi
WBR, Sergei
PATCH 11/23 ARM: dts: omap5-uevm.dts: add tca6424a
Quoted 11 lines · Sergei Shtylyov
Quoted 2 lines
Right. I wonder what the name should be... "gpio" is out, as the name should be more specific.
No, it's not out. The name should be "gpio at 22", I think it would be
unique.Quoted 2 lines
We already have gpio1-8, which are the gpio
banks from the SoC.I don't understand why you are indexing the names while you probably
have the address part after @ that makes them unique already.
Ah sorry for the confusion, I misunderstood. I was talking about the label, not the name, of the node.
So the labels for the gpio banks are 'gpio2' etc. The names are 'gpio at 123456' etc. And yes, here the name should be 'gpio at 22' as you said.
I didn't see any rules about the labels in the ePARP doc, so I guess 'tca6424a' would be a valid one. Maybe not a good one, though, especially if there are multiple tca6424a chips on the board (I need to check).
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/20140425/48f2728c/attachment.sig>
PATCH 12/23 ARM: dts: omap5-uevm.dts: add display nodes
In reply to Tomi Valkeinenomap5-uevm has a single HDMI output. Add the necessary display information, including pinmuxing.
--- arch/arm/boot/dts/omap5-uevm.dts | 82 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+)
arch/arm/boot/dts/omap5-uevm.dts +82 -0
@@ -183,6 +183,19 @@ >; }; + dss_hdmi_pins: pinmux_dss_hdmi_pins { + pinctrl-single,pins = < + 0x0fc (PIN_INPUT_PULLUP | MUX_MODE0) /* hdmi_cec.hdmi_cec */ + 0x100 (PIN_INPUT | MUX_MODE0) /* hdmi_ddc_scl.hdmi_ddc_scl */ + 0x102 (PIN_INPUT | MUX_MODE0) /* hdmi_ddc_sda.hdmi_ddc_sda */ + >; + }; + + tpd12s015_pins: pinmux_tpd12s015_pins { + pinctrl-single,pins = < + 0x0fe (PIN_INPUT_PULLDOWN | MUX_MODE6) /* hdmi_hpd.gpio7_193 */ + >; + }; }; &omap5_pmx_wkup {
@@ -498,3 +511,72 @@ &cpu0 { cpu0-supply = <&smps123_reg>; }; + +/ { + aliases { + display0 = &hdmi0; + }; + + tpd12s015: encoder at 0 { + compatible = "ti,tpd12s015"; + + pinctrl-names = "default"; + pinctrl-0 = <&tpd12s015_pins>; + + gpios = <&tca6424a 0 GPIO_ACTIVE_HIGH>, /* TCA6424A P01, CT CP HPD */ + <&tca6424a 1 GPIO_ACTIVE_HIGH>, /* TCA6424A P00, LS OE */ + <&gpio7 1 GPIO_ACTIVE_HIGH>; /* GPIO 193, HPD */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port at 0 { + reg = <0>; + + tpd12s015_in: endpoint at 0 { + remote-endpoint = <&hdmi_out>; + }; + }; + + port at 1 { + reg = <1>; + + tpd12s015_out: endpoint at 0 { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; + + hdmi0: connector at 0 { + compatible = "hdmi-connector"; + label = "hdmi"; + + type = "b"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; + }; +}; + +&dss { + status = "ok"; +}; + +&hdmi { + status = "ok"; + vdda-supply = <&ldo4_reg>; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_hdmi_pins>; + + port { + hdmi_out: endpoint { + remote-endpoint = <&tpd12s015_in>; + }; + }; +};
Signature · 1 line
1.9.1
PATCH 13/23 OMAPDSS: DSS & DISPC DT support for OMAP5
In reply to Tomi ValkeinenAdd omap5 entries to dispc's and dss's of_device_id tables.
--- drivers/video/fbdev/omap2/dss/dispc.c | 1 + drivers/video/fbdev/omap2/dss/dss.c | 1 + 2 files changed, 2 insertions(+)
drivers/video/fbdev/omap2/dss/dispc.c +1 -0
@@ -3829,6 +3829,7 @@ static const struct of_device_id dispc_of_match[] = { { .compatible = "ti,omap2-dispc", }, { .compatible = "ti,omap3-dispc", }, { .compatible = "ti,omap4-dispc", }, + { .compatible = "ti,omap5-dispc", }, {}, };
drivers/video/fbdev/omap2/dss/dss.c +1 -0
@@ -946,6 +946,7 @@ static const struct of_device_id dss_of_match[] = { { .compatible = "ti,omap2-dss", }, { .compatible = "ti,omap3-dss", }, { .compatible = "ti,omap4-dss", }, + { .compatible = "ti,omap5-dss", }, {}, };
Signature · 1 line
1.9.1
PATCH 14/23 OMAPDSS: features: fix OMAP5 features
In reply to Tomi ValkeinenOMAP5 has LCD3 overlay manager, and total 4 overlay managers. These are not correctly defined in the dss features. Fix them.
--- drivers/video/fbdev/omap2/dss/dss_features.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/video/fbdev/omap2/dss/dss_features.c +2 -1
@@ -595,6 +595,7 @@ static const enum dss_feat_id omap4_dss_feat_list[] = {static const enum dss_feat_id omap5_dss_feat_list[] = {FEAT_MGR_LCD2 , +FEAT_MGR_LCD3 ,FEAT_CORE_CLK_DIV ,FEAT_LCD_CLK_SRC ,FEAT_DSI_DCS_CMD_CONFIG_VC ,
@@ -777,7 +778,7 @@ static const struct omap_dss_features omap5_dss_features = { .features = omap5_dss_feat_list, .num_features = ARRAY_SIZE(omap5_dss_feat_list), - .num_mgrs = 3, + .num_mgrs = 4, .num_ovls = 4, .supported_displays = omap5_dss_supported_displays, .supported_outputs = omap5_dss_supported_outputs,
Signature · 1 line
1.9.1
PATCH 15/23 OMAPDSS: DPI: fix LCD3 DSI source
In reply to Tomi ValkeinenAt the moment the dpi driver does not handle LCD3 clock source at all.
LCD3 channel gets the DSI PLL clock from DSI2 instance. Add support for LCD3's clock source in the dpi driver.
--- drivers/video/fbdev/omap2/dss/dpi.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/video/fbdev/omap2/dss/dpi.c +2 -0
@@ -103,6 +103,8 @@ static enum omap_dss_clk_source dpi_get_alt_clk_src(enum omap_channel channel)return OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ;case OMAP_DSS_CHANNEL_LCD2 :return OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC ; +case OMAP_DSS_CHANNEL_LCD3 : +return OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC ;default :/* this shouldn't happen */ WARN_ON (1 );
Signature · 1 line
1.9.1
PATCH 16/23 OMAPDSS: DSI: Add OMAP5 DSI module IDs
In reply to Tomi ValkeinenAdd OMAP5 DSI module ID support to the OMAP DSI driver.
--- drivers/video/fbdev/omap2/dss/dsi.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/video/fbdev/omap2/dss/dsi.c +7 -0
@@ -5733,9 +5733,16 @@ static const struct dsi_module_id_data dsi_of_data_omap4[] = { { }, }; +static const struct dsi_module_id_data dsi_of_data_omap5[] = { + { .address =0x58004000 , .id =0 , }, + { .address =0x58009000 , .id =1 , }, + { }, +}; +static const struct of_device_id dsi_of_match[] = { { .compatible ="ti,omap3-dsi" , .data = dsi_of_data_omap3, }, { .compatible ="ti,omap4-dsi" , .data = dsi_of_data_omap4, }, + { .compatible ="ti,omap5-dsi" , .data = dsi_of_data_omap5, }, {}, };
Signature · 1 line
1.9.1
PATCH 17/23 OMAPDSS: HDMI: improve Makefile
In reply to Tomi ValkeinenWe'll soon add support for OMAP5 HDMI, which uses some of the same files as OMAP4 HDMI does.
This patch adds a new config entry "OMAP2_DSS_HDMI_COMMON", which both OMAP4 and OMAP5 HDMI config entries can select. OMAP2_DSS_HDMI_COMMON will cause the common HDMI files to be compiled.
--- drivers/video/fbdev/omap2/dss/Kconfig | 9 ++++++--- drivers/video/fbdev/omap2/dss/Makefile | 5 +++-- 2 files changed, 9 insertions(+), 5 deletions(-)
drivers/video/fbdev/omap2/dss/Kconfig +6 -3
@@ -59,12 +59,15 @@ config OMAP2_DSS_VENC help OMAP Video Encoder support for S-Video and composite TV-out. +config OMAP2_DSS_HDMI_COMMON + bool + config OMAP4_DSS_HDMI - bool "HDMI support" + bool "HDMI support for OMAP4" default y + select OMAP2_DSS_HDMI_COMMON help - HDMI Interface. This adds the High Definition Multimedia Interface. - See http://www.hdmi.org/ for HDMI specification. + HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO bool
drivers/video/fbdev/omap2/dss/Makefile +3 -2
@@ -10,6 +10,7 @@ omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o -omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi_common.o hdmi_wp.o hdmi_pll.o \ - hdmi_phy.o hdmi4_core.o +omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \ + hdmi_phy.o +omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
Signature · 1 line
1.9.1
PATCH 18/23 OMAPDSS: HDMI: move irq & phy pwr handling
In reply to Tomi ValkeinenHDMI IRQ handling was moved into hdmi_phy.c when restructuring the HDMI driver. While this worked fine, it's not correct.
The HDMI IRQ handling should be either in the hdmi_wp, or in the main hdmi driver. This patch moves the handling to the main hdmi driver, as I feel it's a more appropriate choice.
This move also requires changing the handling of the PHY power, as that was partly handled in the IRQ handler. The PHY power is handled via the WP module. An option would be to give HDMI PHY driver function pointers that it could use to manage the PHY power, but as the PHY power is not needed to access the PHY registers, the handling was also moved to the main HDMI driver. This could be changed later if need be.
Note that there's slightly similar power issue with the PLL: the HDMI PLLs power is also handled via the WP module. For now, the PLL power handling is still done inside the PLL driver.
--- drivers/video/fbdev/omap2/dss/hdmi.h | 6 +-- drivers/video/fbdev/omap2/dss/hdmi4.c | 75 +++++++++++++++++++++++++++++--- drivers/video/fbdev/omap2/dss/hdmi_phy.c | 70 +---------------------------- 3 files changed, 71 insertions(+), 80 deletions(-)
drivers/video/fbdev/omap2/dss/hdmi.h +1 -5
@@ -351,8 +351,6 @@ struct hdmi_pll_data {struct hdmi_phy_data {void __iomem *base; -int irq; -u8 lane_function[4 ];u8 lane_polarity[4 ]; };
@@ -420,9 +418,7 @@ void hdmi_pll_compute(struct hdmi_pll_data *pll, unsigned long clkin, int phy);int hdmi_pll_init (struct platform_device *pdev,struct hdmi_pll_data *pll);/* HDMI PHY funcs */ -int hdmi_phy_enable (struct hdmi_phy_data *phy,struct hdmi_wp_data *wp, -struct hdmi_config *cfg); -void hdmi_phy_disable (struct hdmi_phy_data *phy,struct hdmi_wp_data *wp); +int hdmi_phy_configure (struct hdmi_phy_data *phy,struct hdmi_config *cfg);void hdmi_phy_dump (struct hdmi_phy_data *phy,struct seq_file *s);int hdmi_phy_init (struct platform_device *pdev,struct hdmi_phy_data *phy);int hdmi_phy_parse_lanes (struct hdmi_phy_data *phy,const u32 *lanes);
drivers/video/fbdev/omap2/dss/hdmi4.c +69 -6
133 lines not on this page · raw message
drivers/video/fbdev/omap2/dss/hdmi_phy.c +1 -69
97 lines not on this page · raw message
Signature · 1 line
1.9.1
PATCH 19/23 OMAPDSS: HDMI: support larger register offsets for OMAP5 HDMI core
In reply to Tomi ValkeinenFrom: Archit Taneja <[email protected]>
The HDMI core IP on OMAP5 has a wider address range for registers. The offsets for the later registers can't fit into the u16 type currently used for hdmi register read and write functions. Use u32 for offsets instead.
--- drivers/video/fbdev/omap2/dss/hdmi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/video/fbdev/omap2/dss/hdmi.h +2 -2
@@ -361,13 +361,13 @@ struct hdmi_core_data {struct hdmi_core_infoframe_avi avi_cfg; }; -static inline void hdmi_write_reg (void __iomem *base_addr,const u16 idx, +static inline void hdmi_write_reg (void __iomem *base_addr,const u32 idx,u32 val) {__raw_writel (val, base_addr + idx); } -static inline u32 hdmi_read_reg (void __iomem *base_addr,const u16 idx) +static inline u32 hdmi_read_reg (void __iomem *base_addr,const u32 idx) {return __raw_readl (base_addr + idx); }
Signature · 1 line
1.9.1
PATCH 20/23 OMAPDSS: HDMI: PHY changes for OMAP5
In reply to Tomi ValkeinenFrom: Archit Taneja <[email protected]>
OMAP5 HDMI PHY has some differences compared to OMAP4 HDMI PHY. This patch creates a features struct which help the driver configure the PHY based on what SoC it is.
Some of the features aren't currenlty used, but will come in use later.
--- drivers/video/fbdev/omap2/dss/hdmi.h | 1 + drivers/video/fbdev/omap2/dss/hdmi_phy.c | 95 +++++++++++++++++++++++++++++++- 2 files changed, 94 insertions(+), 2 deletions(-)
drivers/video/fbdev/omap2/dss/hdmi.h +1 -0
@@ -80,6 +80,7 @@#define HDMI_TXPHY_DIGITAL_CTRL 0x4#define HDMI_TXPHY_POWER_CTRL 0x8#define HDMI_TXPHY_PAD_CFG_CTRL 0xC +#define HDMI_TXPHY_BIST_CONTROL 0x1Cenum hdmi_pll_pwr {HDMI_PLLPWRCMD_ALLOFF =0 ,
drivers/video/fbdev/omap2/dss/hdmi_phy.c +93 -2
143 lines not on this page · raw message
Signature · 1 line
1.9.1
PATCH 21/23 OMAPDSS: HDMI: PLL changes for OMAP5
In reply to Tomi ValkeinenFrom: Archit Taneja <[email protected]>
Add a features struct to differentiate between the HDMI PLLs on OMAP4 and OMAP5. The OMAP5 PLL is more sensitive when it comes to locking. We need to ensure that the DCO freq isn't too low for lower pixel clocks.
Modify the PLL computation slightly to ensure the HDMI PLL locks for lower frequencies. This will be later replaced by a more complex computation which makes sure all the PLL constraints are met.
--- drivers/video/fbdev/omap2/dss/hdmi_pll.c | 81 +++++++++++++++++++++++++++++++- 1 file changed, 79 insertions(+), 2 deletions(-)
drivers/video/fbdev/omap2/dss/hdmi_pll.c +79 -2
@@ -23,6 +23,18 @@#define HDMI_DEFAULT_REGN 16#define HDMI_DEFAULT_REGM2 1 +struct hdmi_pll_features { +bool sys_reset; +/* this is a hack, need to replace it with a better computation of M2 */ +bool bound_dcofreq; +unsigned long fint_min, fint_max; +u16 regm_max; +unsigned long dcofreq_low_min, dcofreq_low_max; +unsigned long dcofreq_high_min, dcofreq_high_max; +}; + +static const struct hdmi_pll_features *pll_feat; +void hdmi_pll_dump (struct hdmi_pll_data *pll,struct seq_file *s) {#define DUMPPLL (r) seq_printf(s, "%-35s %08x\n", #r,\
@@ -57,7 +69,11 @@ void hdmi_pll_compute(struct hdmi_pll_data *pll, unsigned long clkin, int phy) refclk = clkin / pi->regn; - pi->regm2 =HDMI_DEFAULT_REGM2 ; +/* temorary hack to make sure DCO freq isn't calculated too low */ +if (pll_feat->bound_dcofreq && phy <=65000 ) + pi->regm2 =3 ; +else + pi->regm2 =HDMI_DEFAULT_REGM2 ;/* * multiplier is pixel_clk/ref_clk
@@ -154,7 +170,7 @@ static int hdmi_pll_config(struct hdmi_pll_data *pll)static int hdmi_pll_reset (struct hdmi_pll_data *pll) {/* SYSRESET controlled by power FSM */ -REG_FLD_MOD (pll->base,PLLCTRL_PLL_CONTROL ,0x0 ,3 ,3 ); +REG_FLD_MOD (pll->base,PLLCTRL_PLL_CONTROL , pll_feat->sys_reset,3 ,3 );/* READ 0x0 reset is in progress */ if (hdmi_wait_for_bit_change(pll->base, PLLCTRL_PLL_STATUS, 0, 0, 1)
@@ -197,11 +213,72 @@ void hdmi_pll_disable(struct hdmi_pll_data *pll, struct hdmi_wp_data *wp)#define PLL_OFFSET 0x200#define PLL_SIZE 0x100 +static const struct hdmi_pll_features omap44xx_pll_feats = { + .sys_reset = false, + .bound_dcofreq = false, + .fint_min =500000 , + .fint_max =2500000 , + .regm_max =4095 , + .dcofreq_low_min =500000000 , + .dcofreq_low_max =1000000000 , + .dcofreq_high_min =1000000000 , + .dcofreq_high_max =2000000000 , +}; + +static const struct hdmi_pll_features omap54xx_pll_feats = { + .sys_reset = true, + .bound_dcofreq = true, + .fint_min =620000 , + .fint_max =2500000 , + .regm_max =2046 , + .dcofreq_low_min =750000000 , + .dcofreq_low_max =1500000000 , + .dcofreq_high_min =1250000000 , + .dcofreq_high_max =2500000000UL , +}; + +static int hdmi_pll_init_features (struct platform_device *pdev) +{ +struct hdmi_pll_features *dst; +const struct hdmi_pll_features *src; + + dst =devm_kzalloc (&pdev->dev,sizeof (*dst),GFP_KERNEL ); +if (!dst) { +dev_err (&pdev->dev,"Failed to allocate HDMI PHY Features\n" ); +return -ENOMEM ; + } + +switch (omapdss_get_version ()) { +case OMAPDSS_VER_OMAP4430_ES1 : +case OMAPDSS_VER_OMAP4430_ES2 : +case OMAPDSS_VER_OMAP4 : + src = &omap44xx_pll_feats; +break ; + +case OMAPDSS_VER_OMAP5 : + src = &omap54xx_pll_feats; +break ; + +default : +return -ENODEV ; + } + +memcpy (dst, src,sizeof (*dst)); + pll_feat = dst; + +return 0 ; +} +int hdmi_pll_init (struct platform_device *pdev,struct hdmi_pll_data *pll) { +int r;struct resource *res;struct resource temp_res; + r =hdmi_pll_init_features (pdev); +if (r) +return r; + res =platform_get_resource_byname (pdev,IORESOURCE_MEM ,"pll" );if (!res) {DSSDBG ("can't get PLL mem resource by name\n" );
Signature · 1 line
1.9.1
PATCH 22/23 OMAPDSS: HDMI: Add OMAP5 HDMI support
In reply to Tomi ValkeinenThis adds a new driver to omapdss for OMAP5 HDMI. However, the new driver uses common HDMI files which are shared with OMAP4 HDMI driver.
OMAP5 HDMI has a different HDMI core IP compared to OMAP4, but has very similar PLL and PHY IPs which can be handled with common code.
--- drivers/video/fbdev/omap2/dss/Kconfig | 13 + drivers/video/fbdev/omap2/dss/Makefile | 1 + drivers/video/fbdev/omap2/dss/core.c | 6 + drivers/video/fbdev/omap2/dss/dss.h | 3 + drivers/video/fbdev/omap2/dss/hdmi.h | 2 +- drivers/video/fbdev/omap2/dss/hdmi5.c | 829 ++++++++++++++++++++++++++ drivers/video/fbdev/omap2/dss/hdmi5_core.c | 922 +++++++++++++++++++++++++++++ drivers/video/fbdev/omap2/dss/hdmi5_core.h | 306 ++++++++++ drivers/video/fbdev/omap2/dss/hdmi_wp.c | 2 +- 9 files changed, 2082 insertions(+), 2 deletions(-) create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5.c create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5_core.c create mode 100644 drivers/video/fbdev/omap2/dss/hdmi5_core.h
drivers/video/fbdev/omap2/dss/Kconfig +13 -0
@@ -72,6 +72,19 @@ config OMAP4_DSS_HDMI config OMAP4_DSS_HDMI_AUDIO bool +config OMAP5_DSS_HDMI + bool "HDMI support for OMAP5" + default n + select OMAP2_DSS_HDMI_COMMON + help + HDMI Interface for OMAP5 and similar cores. This adds the High + Definition Multimedia Interface. See http://www.hdmi.org/ for HDMI + specification. + +config OMAP5_DSS_HDMI_AUDIO + depends on OMAP5_DSS_HDMI + bool + config OMAP2_DSS_SDI bool "SDI support" default n
drivers/video/fbdev/omap2/dss/Makefile +1 -0
@@ -13,4 +13,5 @@ omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \ hdmi_phy.o omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o +omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
drivers/video/fbdev/omap2/dss/core.c +6 -0
@@ -268,6 +268,9 @@ static int (*dss_output_drv_reg_funcs[])(void) __initdata = {#ifdef CONFIG_OMAP4_DSS_HDMI hdmi4_init_platform_driver,#endif +#ifdef CONFIG_OMAP5_DSS_HDMI + hdmi5_init_platform_driver, +#endif };static void (*dss_output_drv_unreg_funcs[])(void ) __exitdata = {
@@ -289,6 +292,9 @@ static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {#ifdef CONFIG_OMAP4_DSS_HDMI hdmi4_uninit_platform_driver,#endif +#ifdef CONFIG_OMAP5_DSS_HDMI + hdmi5_uninit_platform_driver, +#endif };static bool dss_output_drv_loaded[ARRAY_SIZE (dss_output_drv_reg_funcs)];
drivers/video/fbdev/omap2/dss/dss.h +3 -0
@@ -419,6 +419,9 @@ void venc_uninit_platform_driver(void) __exit;int hdmi4_init_platform_driver (void )__init ; void hdmi4_uninit_platform_driver(void) __exit; +int hdmi5_init_platform_driver (void )__init ; +void hdmi5_uninit_platform_driver(void) __exit; +/* RFBI */ int rfbi_init_platform_driver (void )__init ; void rfbi_uninit_platform_driver(void) __exit;
drivers/video/fbdev/omap2/dss/hdmi.h +1 -1
@@ -431,7 +431,7 @@ struct hdmi_cm hdmi_get_code(struct omap_video_timings *timing);int hdmi_parse_lanes_of (struct platform_device *pdev,struct device_node *ep,struct hdmi_phy_data *phy); -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO ) +#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO ) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO )int hdmi_compute_acr (u32 pclk,u32 sample_freq,u32 *n,u32 *cts);int hdmi_wp_audio_enable (struct hdmi_wp_data *wp,bool enable);int hdmi_wp_audio_core_req_enable (struct hdmi_wp_data *wp,bool enable);
drivers/video/fbdev/omap2/dss/hdmi5.c new file +829 -0
829 lines not on this page · raw message
drivers/video/fbdev/omap2/dss/hdmi5_core.c new file +922 -0
922 lines not on this page · raw message
drivers/video/fbdev/omap2/dss/hdmi5_core.h new file +306 -0
306 lines not on this page · raw message
drivers/video/fbdev/omap2/dss/hdmi_wp.c +1 -1
@@ -185,7 +185,7 @@ void hdmi_wp_init_vid_fmt_timings(struct hdmi_video_format *video_fmt, timings->interlace = param->timings.interlace; } -#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO ) +#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO ) || defined(CONFIG_OMAP5_DSS_HDMI_AUDIO )void hdmi_wp_audio_config_format (struct hdmi_wp_data *wp,struct hdmi_audio_format *aud_fmt) {
Signature · 1 line
1.9.1
PATCH 23/23 Doc/DT: Add OMAP5 DSS DT bindings
In reply to Tomi ValkeinenAdd DT binding documentation for OMAP5 Display Subsystem.
--- .../devicetree/bindings/video/ti,omap5-dss.txt | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/ti,omap5-dss.txt
Documentation/devicetree/bindings/video/ti,omap5-dss.txt new file +96 -0
@@ -0,0 +1,96 @@ +Texas Instruments OMAP5 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap5-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap5-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap5-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +DSI +--- + +Required properties: +- compatible: "ti,omap5-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" or "dss_dsi2" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI +---- + +Required properties: +- compatible: "ti,omap5-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7)
Signature · 1 line
1.9.1