* [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
@ 2011-06-17 8:17 Mythri P K
2011-06-17 8:17 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Mythri P K
2011-06-23 9:58 ` [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS Tomi Valkeinen
0 siblings, 2 replies; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
the Display subsytem is different. Thus to reuse the code between these two
processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
generic location out of omap2/dss folder.
This patch series does the split and also renames hdmi_omap4_panel.c to
hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
other OMAP family of processors as well.
This is based on Tomi's DSS pmruntime-v2 branch:
git://gitorious.org/linux-omap-dss2/linux.git
Tree with the patches for verification is available in
http://gitorious.org/~mythripk/linux-omap-dss2/mythripk-linux-lo-dss2/commits/hdmi_pmrumtime
Mythri P K (8):
OMAP4: DSS: HDMI: HDMI clean up to pass base_address dynamically
to IP dependant functions of HDMI
OMAP4 : DSS : HDMI : Move the EDID portion from HDMI IP header
OMAP4: DSS: HDMI: Use specific HDMI timings structure instead of
OMAP DSS timings
OMAP4: DSS: HDMI: Move the common header file definition to
Include/video
OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP specific
portion.
OMAP4: DSS: HDMI: Rename the functions in HDMI IP library to IP
specific name
HDMI: Move HDMI IP Library from OMAP DSS to common Video
directory for IP present in TI OMAP4, TI81xx, TI38xx
Processor
OMAP4: DSS: Rename hdmi_omap4_panel.c to hdmi_panel.c
drivers/video/Kconfig | 7 +
drivers/video/Makefile | 1 +
drivers/video/hdmi_ti_4xxx_ip.c | 803 +++++++++++++++++
drivers/video/hdmi_ti_4xxx_ip.h | 587 +++++++++++++
drivers/video/omap2/dss/Kconfig | 1 +
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss.h | 10 -
drivers/video/omap2/dss/hdmi.c | 919 ++++----------------
drivers/video/omap2/dss/hdmi.h | 631 --------------
.../omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} | 2 +-
include/video/hdmi_ti_4xxx_ip.h | 94 ++
11 files changed, 1641 insertions(+), 1416 deletions(-)
create mode 100644 drivers/video/hdmi_ti_4xxx_ip.c
create mode 100644 drivers/video/hdmi_ti_4xxx_ip.h
delete mode 100644 drivers/video/omap2/dss/hdmi.h
rename drivers/video/omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} (99%)
create mode 100644 include/video/hdmi_ti_4xxx_ip.h
--
1.7.5.4
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
2011-06-17 8:17 [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
2011-06-17 8:17 ` [PATCH 2/8] OMAP4 : DSS : HDMI : Move the EDID portion from HDMI IP Mythri P K
2011-06-20 13:33 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Premi, Sanjeev
2011-06-23 9:58 ` [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS Tomi Valkeinen
1 sibling, 2 replies; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
As the base_address of the HDMI might differ across SoC's, offset of the HDMI
logical blocks and base address got from the platform data are passed
dynamically to the functions that modify HDMI IP registers.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 518 ++++++++++++++++++++++++----------------
drivers/video/omap2/dss/hdmi.h | 292 +++++++++++------------
2 files changed, 452 insertions(+), 358 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 5e5b98b..1d16ee2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -43,11 +43,17 @@
#include "hdmi.h"
#include "dss_features.h"
+#define HDMI_WP 0x0
+#define HDMI_CORE_SYS 0x400
+#define HDMI_CORE_AV 0x900
+#define HDMI_PLLCTRL 0x200
+#define HDMI_PHY 0x300
+
static struct {
struct mutex lock;
struct omap_display_platform_data *pdata;
struct platform_device *pdev;
- void __iomem *base_wp; /* HDMI wrapper */
+ struct hdmi_ip_data hdmi_data;
int code;
int mode;
u8 edid[HDMI_EDID_MAX_LENGTH];
@@ -146,21 +152,51 @@ static const int code_vesa[85] = {
static const u8 edid_header[8] = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0};
-static inline void hdmi_write_reg(const struct hdmi_reg idx, u32 val)
+static inline void hdmi_write_reg(void __iomem *base_addr,
+ const struct hdmi_reg idx, u32 val)
+{
+ __raw_writel(val, base_addr + idx.idx);
+}
+
+static inline u32 hdmi_read_reg(void __iomem *base_addr,
+ const struct hdmi_reg idx)
+{
+ return __raw_readl(base_addr + idx.idx);
+}
+
+static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *) (ip_data->base_wp);
+}
+
+static inline void __iomem *hdmi_phy_base(struct hdmi_ip_data *ip_data)
{
- __raw_writel(val, hdmi.base_wp + idx.idx);
+ return (void __iomem *) (ip_data->base_wp + ip_data->hdmi_phy_offset);
}
-static inline u32 hdmi_read_reg(const struct hdmi_reg idx)
+static inline void __iomem *hdmi_pll_base(struct hdmi_ip_data *ip_data)
{
- return __raw_readl(hdmi.base_wp + idx.idx);
+ return (void __iomem *) (ip_data->base_wp + ip_data->hdmi_pll_offset);
}
-static inline int hdmi_wait_for_bit_change(const struct hdmi_reg idx,
+static inline void __iomem *hdmi_av_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *)
+ (ip_data->base_wp + ip_data->hdmi_core_av_offset);
+}
+
+static inline void __iomem *hdmi_core_sys_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *)
+ (ip_data->base_wp + ip_data->hdmi_core_sys_offset);
+}
+
+static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
+ const struct hdmi_reg idx,
int b2, int b1, u32 val)
{
u32 t = 0;
- while (val != REG_GET(idx, b2, b1)) {
+ while (val != REG_GET(base_addr, idx, b2, b1)) {
udelay(1);
if (t++ > 10000)
return !val;
@@ -225,21 +261,22 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static int hdmi_pll_init(enum hdmi_clk_refsel refsel, int dcofreq,
+static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
+ enum hdmi_clk_refsel refsel, int dcofreq,
struct hdmi_pll_info *fmt, u16 sd)
{
u32 r;
/* PLL start always use manual mode */
- REG_FLD_MOD(PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
- r = hdmi_read_reg(PLLCTRL_CFG1);
+ r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
r = FLD_MOD(r, fmt->regm, 20, 9); /* CFG1_PLL_REGM */
r = FLD_MOD(r, fmt->regn, 8, 1); /* CFG1_PLL_REGN */
- hdmi_write_reg(PLLCTRL_CFG1, r);
+ hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
- r = hdmi_read_reg(PLLCTRL_CFG2);
+ r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2);
r = FLD_MOD(r, 0x0, 12, 12); /* PLL_HIGHFREQ divide by 2 */
r = FLD_MOD(r, 0x1, 13, 13); /* PLL_REFEN */
@@ -247,38 +284,40 @@ static int hdmi_pll_init(enum hdmi_clk_refsel refsel, int dcofreq,
if (dcofreq) {
/* divider programming for frequency beyond 1000Mhz */
- REG_FLD_MOD(PLLCTRL_CFG3, sd, 17, 10);
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_CFG3, sd, 17, 10);
r = FLD_MOD(r, 0x4, 3, 1); /* 1000MHz and 2000MHz */
} else {
r = FLD_MOD(r, 0x2, 3, 1); /* 500MHz and 1000MHz */
}
- hdmi_write_reg(PLLCTRL_CFG2, r);
+ hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2, r);
- r = hdmi_read_reg(PLLCTRL_CFG4);
+ r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4);
r = FLD_MOD(r, fmt->regm2, 24, 18);
r = FLD_MOD(r, fmt->regmf, 17, 0);
- hdmi_write_reg(PLLCTRL_CFG4, r);
+ hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4, r);
/* go now */
- REG_FLD_MOD(PLLCTRL_PLL_GO, 0x1, 0, 0);
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_GO, 0x1, 0, 0);
/* wait for bit change */
- if (hdmi_wait_for_bit_change(PLLCTRL_PLL_GO, 0, 0, 1) != 1) {
+ if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data), PLLCTRL_PLL_GO,
+ 0, 0, 1) != 1) {
DSSERR("PLL GO bit not set\n");
return -ETIMEDOUT;
}
/* Wait till the lock bit is set in PLL status */
- if (hdmi_wait_for_bit_change(PLLCTRL_PLL_STATUS, 1, 1, 1) != 1) {
+ if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data),
+ PLLCTRL_PLL_STATUS, 1, 1, 1) != 1) {
DSSWARN("cannot lock PLL\n");
DSSWARN("CFG1 0x%x\n",
- hdmi_read_reg(PLLCTRL_CFG1));
+ hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1));
DSSWARN("CFG2 0x%x\n",
- hdmi_read_reg(PLLCTRL_CFG2));
+ hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2));
DSSWARN("CFG4 0x%x\n",
- hdmi_read_reg(PLLCTRL_CFG4));
+ hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4));
return -ETIMEDOUT;
}
@@ -288,13 +327,14 @@ static int hdmi_pll_init(enum hdmi_clk_refsel refsel, int dcofreq,
}
/* PHY_PWR_CMD */
-static int hdmi_set_phy_pwr(enum hdmi_phy_pwr val)
+static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr val)
{
/* Command for power control of HDMI PHY */
- REG_FLD_MOD(HDMI_WP_PWR_CTRL, val, 7, 6);
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 7, 6);
/* Status of the power control of HDMI PHY */
- if (hdmi_wait_for_bit_change(HDMI_WP_PWR_CTRL, 5, 4, val) != val) {
+ if (hdmi_wait_for_bit_change(hdmi_wp_base(ip_data),
+ HDMI_WP_PWR_CTRL, 5, 4, val) != val) {
DSSERR("Failed to set PHY power mode to %d\n", val);
return -ETIMEDOUT;
}
@@ -303,13 +343,14 @@ static int hdmi_set_phy_pwr(enum hdmi_phy_pwr val)
}
/* PLL_PWR_CMD */
-static int hdmi_set_pll_pwr(enum hdmi_pll_pwr val)
+int hdmi_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val)
{
/* Command for power control of HDMI PLL */
- REG_FLD_MOD(HDMI_WP_PWR_CTRL, val, 3, 2);
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 3, 2);
/* wait till PHY_PWR_STATUS is set */
- if (hdmi_wait_for_bit_change(HDMI_WP_PWR_CTRL, 1, 0, val) != val) {
+ if (hdmi_wait_for_bit_change(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL,
+ 1, 0, val) != val) {
DSSERR("Failed to set PHY_PWR_STATUS\n");
return -ETIMEDOUT;
}
@@ -317,13 +358,14 @@ static int hdmi_set_pll_pwr(enum hdmi_pll_pwr val)
return 0;
}
-static int hdmi_pll_reset(void)
+static int hdmi_pll_reset(struct hdmi_ip_data *ip_data)
{
/* SYSRESET controlled by power FSM */
- REG_FLD_MOD(PLLCTRL_PLL_CONTROL, 0x0, 3, 3);
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_CONTROL, 0x0, 3, 3);
/* READ 0x0 reset is in progress */
- if (hdmi_wait_for_bit_change(PLLCTRL_PLL_STATUS, 0, 0, 1) != 1) {
+ if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data),
+ PLLCTRL_PLL_STATUS, 0, 0, 1) != 1) {
DSSERR("Failed to sysreset PLL\n");
return -ETIMEDOUT;
}
@@ -331,15 +373,15 @@ static int hdmi_pll_reset(void)
return 0;
}
-static int hdmi_phy_init(void)
+static int hdmi_phy_init(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
- r = hdmi_set_phy_pwr(HDMI_PHYPWRCMD_LDOON);
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
if (r)
return r;
- r = hdmi_set_phy_pwr(HDMI_PHYPWRCMD_TXON);
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
if (r)
return r;
@@ -347,65 +389,69 @@ static int hdmi_phy_init(void)
* Read address 0 in order to get the SCP reset done completed
* Dummy access performed to make sure reset is done
*/
- hdmi_read_reg(HDMI_TXPHY_TX_CTRL);
+ hdmi_read_reg(hdmi_phy_base(ip_data), HDMI_TXPHY_TX_CTRL);
/*
* Write to phy address 0 to configure the clock
* use HFBITCLK write HDMI_TXPHY_TX_CONTROL_FREQOUT field
*/
- REG_FLD_MOD(HDMI_TXPHY_TX_CTRL, 0x1, 31, 30);
+ REG_FLD_MOD(hdmi_phy_base(ip_data), HDMI_TXPHY_TX_CTRL, 0x1, 31, 30);
/* Write to phy address 1 to start HDMI line (TXVALID and TMDSCLKEN) */
- hdmi_write_reg(HDMI_TXPHY_DIGITAL_CTRL, 0xF0000000);
+ hdmi_write_reg(hdmi_phy_base(ip_data),
+ HDMI_TXPHY_DIGITAL_CTRL, 0xF0000000);
/* Setup max LDO voltage */
- REG_FLD_MOD(HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
+ REG_FLD_MOD(hdmi_phy_base(ip_data), HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
/* Write to phy address 3 to change the polarity control */
- REG_FLD_MOD(HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
+ REG_FLD_MOD(hdmi_phy_base(ip_data),
+ HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
return 0;
}
-static int hdmi_pll_program(struct hdmi_pll_info *fmt)
+static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
+ struct hdmi_pll_info *fmt)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
- r = hdmi_set_pll_pwr(HDMI_PLLPWRCMD_ALLOFF);
+ r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
if (r)
return r;
- r = hdmi_set_pll_pwr(HDMI_PLLPWRCMD_BOTHON_ALLCLKS);
+ r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_BOTHON_ALLCLKS);
if (r)
return r;
- r = hdmi_pll_reset();
+ r = hdmi_pll_reset(ip_data);
if (r)
return r;
refsel = HDMI_REFSEL_SYSCLK;
- r = hdmi_pll_init(refsel, fmt->dcofreq, fmt, fmt->regsd);
+ r = hdmi_pll_init(ip_data, refsel, fmt->dcofreq, fmt, fmt->regsd);
if (r)
return r;
return 0;
}
-static void hdmi_phy_off(void)
+static void hdmi_phy_off(struct hdmi_ip_data *ip_data)
{
- hdmi_set_phy_pwr(HDMI_PHYPWRCMD_OFF);
+ hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
}
-static int hdmi_core_ddc_edid(u8 *pedid, int ext)
+static int hdmi_core_ddc_edid(struct hdmi_ip_data *ip_data,
+ u8 *pedid, int ext)
{
u32 i, j;
char checksum = 0;
u32 offset = 0;
/* Turn on CLK for DDC */
- REG_FLD_MOD(HDMI_CORE_AV_DPD, 0x7, 2, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_DPD, 0x7, 2, 0);
/*
* SW HACK : Without the Delay DDC(i2c bus) reads 0 values /
@@ -416,21 +462,23 @@ static int hdmi_core_ddc_edid(u8 *pedid, int ext)
if (!ext) {
/* Clk SCL Devices */
- REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0xA, 3, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_CMD, 0xA, 3, 0);
/* HDMI_CORE_DDC_STATUS_IN_PROG */
- if (hdmi_wait_for_bit_change(HDMI_CORE_DDC_STATUS,
- 4, 4, 0) != 0) {
+ if (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 4, 4, 0) != 0) {
DSSERR("Failed to program DDC\n");
return -ETIMEDOUT;
}
/* Clear FIFO */
- REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x9, 3, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data)
+ , HDMI_CORE_DDC_CMD, 0x9, 3, 0);
/* HDMI_CORE_DDC_STATUS_IN_PROG */
- if (hdmi_wait_for_bit_change(HDMI_CORE_DDC_STATUS,
- 4, 4, 0) != 0) {
+ if (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 4, 4, 0) != 0) {
DSSERR("Failed to program DDC\n");
return -ETIMEDOUT;
}
@@ -441,44 +489,56 @@ static int hdmi_core_ddc_edid(u8 *pedid, int ext)
}
/* Load Segment Address Register */
- REG_FLD_MOD(HDMI_CORE_DDC_SEGM, ext/2, 7, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_SEGM, ext/2, 7, 0);
/* Load Slave Address Register */
- REG_FLD_MOD(HDMI_CORE_DDC_ADDR, 0xA0 >> 1, 7, 1);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_ADDR, 0xA0 >> 1, 7, 1);
/* Load Offset Address Register */
- REG_FLD_MOD(HDMI_CORE_DDC_OFFSET, offset, 7, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_OFFSET, offset, 7, 0);
/* Load Byte Count */
- REG_FLD_MOD(HDMI_CORE_DDC_COUNT1, 0x80, 7, 0);
- REG_FLD_MOD(HDMI_CORE_DDC_COUNT2, 0x0, 1, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_COUNT1, 0x80, 7, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_COUNT2, 0x0, 1, 0);
/* Set DDC_CMD */
if (ext)
- REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x4, 3, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_CMD, 0x4, 3, 0);
else
- REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x2, 3, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_CMD, 0x2, 3, 0);
/* HDMI_CORE_DDC_STATUS_BUS_LOW */
- if (REG_GET(HDMI_CORE_DDC_STATUS, 6, 6) == 1) {
+ if (REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 6, 6) == 1) {
DSSWARN("I2C Bus Low?\n");
return -EIO;
}
/* HDMI_CORE_DDC_STATUS_NO_ACK */
- if (REG_GET(HDMI_CORE_DDC_STATUS, 5, 5) == 1) {
+ if (REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 5, 5) == 1) {
DSSWARN("I2C No Ack\n");
return -EIO;
}
i = ext * 128;
j = 0;
- while (((REG_GET(HDMI_CORE_DDC_STATUS, 4, 4) == 1) ||
- (REG_GET(HDMI_CORE_DDC_STATUS, 2, 2) == 0)) &&
- j < 128) {
+ while (((REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 4, 4) == 1) ||
+ (REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 2, 2) == 0)) && j < 128) {
- if (REG_GET(HDMI_CORE_DDC_STATUS, 2, 2) == 0) {
+ if (REG_GET(hdmi_core_sys_base(ip_data)
+ , HDMI_CORE_DDC_STATUS, 2, 2) == 0) {
/* FIFO not empty */
- pedid[i++] = REG_GET(HDMI_CORE_DDC_DATA, 7, 0);
+ pedid[i++] = REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_DATA, 7, 0);
j++;
}
}
@@ -494,12 +554,12 @@ static int hdmi_core_ddc_edid(u8 *pedid, int ext)
return 0;
}
-static int read_edid(u8 *pedid, u16 max_length)
+static int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
{
int r = 0, n = 0, i = 0;
int max_ext_blocks = (max_length / 128) - 1;
- r = hdmi_core_ddc_edid(pedid, 0);
+ r = hdmi_core_ddc_edid(ip_data, pedid, 0);
if (r) {
return r;
} else {
@@ -515,7 +575,7 @@ static int read_edid(u8 *pedid, u16 max_length)
n = max_ext_blocks;
for (i = 1; i <= n; i++) {
- r = hdmi_core_ddc_edid(pedid, i);
+ r = hdmi_core_ddc_edid(ip_data, pedid, i);
if (r)
return r;
}
@@ -685,8 +745,8 @@ static void hdmi_read_edid(struct omap_video_timings *dp)
memset(hdmi.edid, 0, HDMI_EDID_MAX_LENGTH);
if (!hdmi.edid_set)
- ret = read_edid(hdmi.edid, HDMI_EDID_MAX_LENGTH);
-
+ ret = read_edid(&hdmi.hdmi_data, hdmi.edid,
+ HDMI_EDID_MAX_LENGTH);
if (!ret) {
if (!memcmp(hdmi.edid, edid_header, sizeof(edid_header))) {
/* search for timings of default resolution */
@@ -752,41 +812,43 @@ static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
repeat_cfg->generic_pkt_repeat = 0;
}
-static void hdmi_core_powerdown_disable(void)
+static void hdmi_core_powerdown_disable(struct hdmi_ip_data *ip_data)
{
DSSDBG("Enter hdmi_core_powerdown_disable\n");
- REG_FLD_MOD(HDMI_CORE_CTRL1, 0x0, 0, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, 0x0, 0, 0);
}
-static void hdmi_core_swreset_release(void)
+static void hdmi_core_swreset_release(struct hdmi_ip_data *ip_data)
{
DSSDBG("Enter hdmi_core_swreset_release\n");
- REG_FLD_MOD(HDMI_CORE_SYS_SRST, 0x0, 0, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SRST, 0x0, 0, 0);
}
-static void hdmi_core_swreset_assert(void)
+static void hdmi_core_swreset_assert(struct hdmi_ip_data *ip_data)
{
DSSDBG("Enter hdmi_core_swreset_assert\n");
- REG_FLD_MOD(HDMI_CORE_SYS_SRST, 0x1, 0, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SRST, 0x1, 0, 0);
}
-/* DSS_HDMI_CORE_VIDEO_CONFIG */
-static void hdmi_core_video_config(struct hdmi_core_video_config *cfg)
+/* HDMI_CORE_VIDEO_CONFIG */
+static void hdmi_core_video_config(struct hdmi_ip_data *ip_data,
+ struct hdmi_core_video_config *cfg)
{
u32 r = 0;
/* sys_ctrl1 default configuration not tunable */
- r = hdmi_read_reg(HDMI_CORE_CTRL1);
+ r = hdmi_read_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1);
r = FLD_MOD(r, HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC, 5, 5);
r = FLD_MOD(r, HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC, 4, 4);
r = FLD_MOD(r, HDMI_CORE_CTRL1_BSEL_24BITBUS, 2, 2);
r = FLD_MOD(r, HDMI_CORE_CTRL1_EDGE_RISINGEDGE, 1, 1);
- hdmi_write_reg(HDMI_CORE_CTRL1, r);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, r);
- REG_FLD_MOD(HDMI_CORE_SYS_VID_ACEN, cfg->ip_bus_width, 7, 6);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN, cfg->ip_bus_width, 7, 6);
/* Vid_Mode */
- r = hdmi_read_reg(HDMI_CORE_SYS_VID_MODE);
+ r = hdmi_read_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_VID_MODE);
/* dither truncation configuration */
if (cfg->op_dither_truc > HDMI_OUTPUTTRUNCATION_12BIT) {
@@ -796,106 +858,107 @@ static void hdmi_core_video_config(struct hdmi_core_video_config *cfg)
r = FLD_MOD(r, cfg->op_dither_truc, 7, 6);
r = FLD_MOD(r, 0, 5, 5);
}
- hdmi_write_reg(HDMI_CORE_SYS_VID_MODE, r);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_VID_MODE, r);
/* HDMI_Ctrl */
- r = hdmi_read_reg(HDMI_CORE_AV_HDMI_CTRL);
+ r = hdmi_read_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_HDMI_CTRL);
r = FLD_MOD(r, cfg->deep_color_pkt, 6, 6);
r = FLD_MOD(r, cfg->pkt_mode, 5, 3);
r = FLD_MOD(r, cfg->hdmi_dvi, 0, 0);
- hdmi_write_reg(HDMI_CORE_AV_HDMI_CTRL, r);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_HDMI_CTRL, r);
/* TMDS_CTRL */
- REG_FLD_MOD(HDMI_CORE_SYS_TMDS_CTRL,
- cfg->tclk_sel_clkmult, 6, 5);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_TMDS_CTRL, cfg->tclk_sel_clkmult, 6, 5);
}
-static void hdmi_core_aux_infoframe_avi_config(
+static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_infoframe_avi info_avi)
{
u32 val;
char sum = 0, checksum = 0;
sum += 0x82 + 0x002 + 0x00D;
- hdmi_write_reg(HDMI_CORE_AV_AVI_TYPE, 0x082);
- hdmi_write_reg(HDMI_CORE_AV_AVI_VERS, 0x002);
- hdmi_write_reg(HDMI_CORE_AV_AVI_LEN, 0x00D);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_TYPE, 0x082);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_VERS, 0x002);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_LEN, 0x00D);
val = (info_avi.db1_format << 5) |
(info_avi.db1_active_info << 4) |
(info_avi.db1_bar_info_dv << 2) |
(info_avi.db1_scan_info);
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(0), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(0), val);
sum += val;
val = (info_avi.db2_colorimetry << 6) |
(info_avi.db2_aspect_ratio << 4) |
(info_avi.db2_active_fmt_ar);
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(1), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(1), val);
sum += val;
val = (info_avi.db3_itc << 7) |
(info_avi.db3_ec << 4) |
(info_avi.db3_q_range << 2) |
(info_avi.db3_nup_scaling);
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(2), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(2), val);
sum += val;
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(3), info_avi.db4_videocode);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(3),
+ info_avi.db4_videocode);
sum += info_avi.db4_videocode;
val = info_avi.db5_pixel_repeat;
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(4), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(4), val);
sum += val;
val = info_avi.db6_7_line_eoftop & 0x00FF;
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(5), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(5), val);
sum += val;
val = ((info_avi.db6_7_line_eoftop >> 8) & 0x00FF);
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(6), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(6), val);
sum += val;
val = info_avi.db8_9_line_sofbottom & 0x00FF;
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(7), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(7), val);
sum += val;
val = ((info_avi.db8_9_line_sofbottom >> 8) & 0x00FF);
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(8), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(8), val);
sum += val;
val = info_avi.db10_11_pixel_eofleft & 0x00FF;
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(9), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(9), val);
sum += val;
val = ((info_avi.db10_11_pixel_eofleft >> 8) & 0x00FF);
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(10), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(10), val);
sum += val;
val = info_avi.db12_13_pixel_sofright & 0x00FF;
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(11), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(11), val);
sum += val;
val = ((info_avi.db12_13_pixel_sofright >> 8) & 0x00FF);
- hdmi_write_reg(HDMI_CORE_AV_AVI_DBYTE(12), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(12), val);
sum += val;
checksum = 0x100 - sum;
- hdmi_write_reg(HDMI_CORE_AV_AVI_CHSUM, checksum);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_CHSUM, checksum);
}
-static void hdmi_core_av_packet_config(
+static void hdmi_core_av_packet_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_packet_enable_repeat repeat_cfg)
{
/* enable/repeat the infoframe */
- hdmi_write_reg(HDMI_CORE_AV_PB_CTRL1,
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_PB_CTRL1,
(repeat_cfg.audio_pkt << 5) |
(repeat_cfg.audio_pkt_repeat << 4) |
(repeat_cfg.avi_infoframe << 1) |
(repeat_cfg.avi_infoframe_repeat));
/* enable/repeat the packet */
- hdmi_write_reg(HDMI_CORE_AV_PB_CTRL2,
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_PB_CTRL2,
(repeat_cfg.gen_cntrl_pkt << 3) |
(repeat_cfg.gen_cntrl_pkt_repeat << 2) |
(repeat_cfg.generic_pkt << 1) |
@@ -927,9 +990,9 @@ static void hdmi_wp_init(struct omap_video_timings *timings,
}
-static void hdmi_wp_video_start(bool start)
+static void hdmi_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
{
- REG_FLD_MOD(HDMI_WP_VIDEO_CFG, start, 31, 31);
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, start, 31, 31);
}
static void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
@@ -948,33 +1011,34 @@ static void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
timings->vsw = param->timings.timings.vsw;
}
-static void hdmi_wp_video_config_format(
+static void hdmi_wp_video_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_video_format *video_fmt)
{
u32 l = 0;
- REG_FLD_MOD(HDMI_WP_VIDEO_CFG, video_fmt->packing_mode, 10, 8);
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG,
+ video_fmt->packing_mode, 10, 8);
l |= FLD_VAL(video_fmt->y_res, 31, 16);
l |= FLD_VAL(video_fmt->x_res, 15, 0);
- hdmi_write_reg(HDMI_WP_VIDEO_SIZE, l);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_SIZE, l);
}
-static void hdmi_wp_video_config_interface(
+static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data,
struct hdmi_video_interface *video_int)
{
u32 r;
DSSDBG("Enter hdmi_wp_video_config_interface\n");
- r = hdmi_read_reg(HDMI_WP_VIDEO_CFG);
+ r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG);
r = FLD_MOD(r, video_int->vsp, 7, 7);
r = FLD_MOD(r, video_int->hsp, 6, 6);
r = FLD_MOD(r, video_int->interlacing, 3, 3);
r = FLD_MOD(r, video_int->tm, 1, 0);
- hdmi_write_reg(HDMI_WP_VIDEO_CFG, r);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
}
-static void hdmi_wp_video_config_timing(
+static void hdmi_wp_video_config_timing(struct hdmi_ip_data *ip_data,
struct omap_video_timings *timings)
{
u32 timing_h = 0;
@@ -985,15 +1049,16 @@ static void hdmi_wp_video_config_timing(
timing_h |= FLD_VAL(timings->hbp, 31, 20);
timing_h |= FLD_VAL(timings->hfp, 19, 8);
timing_h |= FLD_VAL(timings->hsw, 7, 0);
- hdmi_write_reg(HDMI_WP_VIDEO_TIMING_H, timing_h);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_TIMING_H, timing_h);
timing_v |= FLD_VAL(timings->vbp, 31, 20);
timing_v |= FLD_VAL(timings->vfp, 19, 8);
timing_v |= FLD_VAL(timings->vsw, 7, 0);
- hdmi_write_reg(HDMI_WP_VIDEO_TIMING_V, timing_v);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_TIMING_V, timing_v);
}
-static void hdmi_basic_configure(struct hdmi_config *cfg)
+static void hdmi_basic_configure(struct hdmi_ip_data *ip_data,
+ struct hdmi_config *cfg)
{
/* HDMI */
struct omap_video_timings video_timing;
@@ -1014,36 +1079,36 @@ static void hdmi_basic_configure(struct hdmi_config *cfg)
hdmi_wp_video_init_format(&video_format,
&video_timing, cfg);
- hdmi_wp_video_config_timing(&video_timing);
+ hdmi_wp_video_config_timing(ip_data, &video_timing);
/* video config */
video_format.packing_mode = HDMI_PACK_24b_RGB_YUV444_YUV422;
- hdmi_wp_video_config_format(&video_format);
+ hdmi_wp_video_config_format(ip_data, &video_format);
video_interface.vsp = cfg->timings.vsync_pol;
video_interface.hsp = cfg->timings.hsync_pol;
video_interface.interlacing = cfg->interlace;
video_interface.tm = 1 ; /* HDMI_TIMING_MASTER_24BIT */
- hdmi_wp_video_config_interface(&video_interface);
+ hdmi_wp_video_config_interface(ip_data, &video_interface);
/*
* configure core video part
* set software reset in the core
*/
- hdmi_core_swreset_assert();
+ hdmi_core_swreset_assert(ip_data);
/* power down off */
- hdmi_core_powerdown_disable();
+ hdmi_core_powerdown_disable(ip_data);
v_core_cfg.pkt_mode = HDMI_PACKETMODE24BITPERPIXEL;
v_core_cfg.hdmi_dvi = cfg->cm.mode;
- hdmi_core_video_config(&v_core_cfg);
+ hdmi_core_video_config(ip_data, &v_core_cfg);
/* release software reset in the core */
- hdmi_core_swreset_release();
+ hdmi_core_swreset_release(ip_data);
/*
* configure packet
@@ -1068,7 +1133,7 @@ static void hdmi_basic_configure(struct hdmi_config *cfg)
avi_cfg.db10_11_pixel_eofleft = 0;
avi_cfg.db12_13_pixel_sofright = 0;
- hdmi_core_aux_infoframe_avi_config(avi_cfg);
+ hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
/* enable/repeat the infoframe */
repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
@@ -1076,7 +1141,7 @@ static void hdmi_basic_configure(struct hdmi_config *cfg)
/* wakeup */
repeat_cfg.audio_pkt = HDMI_PACKETENABLE;
repeat_cfg.audio_pkt_repeat = HDMI_PACKETREPEATON;
- hdmi_core_av_packet_config(repeat_cfg);
+ hdmi_core_av_packet_config(ip_data, repeat_cfg);
}
static void update_hdmi_timings(struct hdmi_config *cfg,
@@ -1166,16 +1231,16 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi_compute_pll(dssdev, phy, &pll_data);
- hdmi_wp_video_start(0);
+ hdmi_wp_video_start(&hdmi.hdmi_data, 0);
- /* config the PLL and PHY first */
- r = hdmi_pll_program(&pll_data);
+ /* config the PLL and PHY hdmi_set_pll_pwrfirst */
+ r = hdmi_pll_program(&hdmi.hdmi_data, &pll_data);
if (r) {
DSSDBG("Failed to lock PLL\n");
goto err;
}
- r = hdmi_phy_init();
+ r = hdmi_phy_init(&hdmi.hdmi_data);
if (r) {
DSSDBG("Failed to start PHY\n");
goto err;
@@ -1183,7 +1248,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi.cfg.cm.mode = hdmi.mode;
hdmi.cfg.cm.code = hdmi.code;
- hdmi_basic_configure(&hdmi.cfg);
+ hdmi_basic_configure(&hdmi.hdmi_data, &hdmi.cfg);
/* Make selection of HDMI in DSS */
dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
@@ -1205,7 +1270,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dispc_enable_channel(OMAP_DSS_CHANNEL_DIGIT, 1);
- hdmi_wp_video_start(1);
+ hdmi_wp_video_start(&hdmi.hdmi_data, 1);
return 0;
err:
@@ -1217,9 +1282,9 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
{
dispc_enable_channel(OMAP_DSS_CHANNEL_DIGIT, 0);
- hdmi_wp_video_start(0);
- hdmi_phy_off();
- hdmi_set_pll_pwr(HDMI_PLLPWRCMD_ALLOFF);
+ hdmi_wp_video_start(&hdmi.hdmi_data, 0);
+ hdmi_phy_off(&hdmi.hdmi_data);
+ hdmi_set_pll_pwr(&hdmi.hdmi_data, HDMI_PLLPWRCMD_ALLOFF);
hdmi_runtime_put();
hdmi.edid_set = 0;
@@ -1311,14 +1376,14 @@ void omapdss_hdmi_display_disable(struct omap_dss_device *dssdev)
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-static void hdmi_wp_audio_config_format(
- struct hdmi_audio_format *aud_fmt)
+static void hdmi_wp_audio_config_format(struct hdmi_ip_data *ip_data,
+ struct hdmi_audio_format *aud_fmt)
{
u32 r;
DSSDBG("Enter hdmi_wp_audio_config_format\n");
- r = hdmi_read_reg(HDMI_WP_AUDIO_CFG);
+ r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CFG);
r = FLD_MOD(r, aud_fmt->stereo_channels, 26, 24);
r = FLD_MOD(r, aud_fmt->active_chnnls_msk, 23, 16);
r = FLD_MOD(r, aud_fmt->en_sig_blk_strt_end, 5, 5);
@@ -1327,68 +1392,81 @@ static void hdmi_wp_audio_config_format(
r = FLD_MOD(r, aud_fmt->sample_order, 2, 2);
r = FLD_MOD(r, aud_fmt->samples_per_word, 1, 1);
r = FLD_MOD(r, aud_fmt->sample_size, 0, 0);
- hdmi_write_reg(HDMI_WP_AUDIO_CFG, r);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CFG, r);
}
-static void hdmi_wp_audio_config_dma(struct hdmi_audio_dma *aud_dma)
+static void hdmi_wp_audio_config_dma(struct hdmi_ip_data *ip_data,
+ struct hdmi_audio_dma *aud_dma)
{
u32 r;
DSSDBG("Enter hdmi_wp_audio_config_dma\n");
- r = hdmi_read_reg(HDMI_WP_AUDIO_CFG2);
+ r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CFG2);
r = FLD_MOD(r, aud_dma->transfer_size, 15, 8);
r = FLD_MOD(r, aud_dma->block_size, 7, 0);
- hdmi_write_reg(HDMI_WP_AUDIO_CFG2, r);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CFG2, r);
- r = hdmi_read_reg(HDMI_WP_AUDIO_CTRL);
+ r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CTRL);
r = FLD_MOD(r, aud_dma->mode, 9, 9);
r = FLD_MOD(r, aud_dma->fifo_threshold, 8, 0);
- hdmi_write_reg(HDMI_WP_AUDIO_CTRL, r);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_AUDIO_CTRL, r);
}
-static void hdmi_core_audio_config(struct hdmi_core_audio_config *cfg)
+static void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
+ struct hdmi_core_audio_config *cfg)
{
u32 r;
/* audio clock recovery parameters */
- r = hdmi_read_reg(HDMI_CORE_AV_ACR_CTRL);
+ r = hdmi_read_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_ACR_CTRL);
r = FLD_MOD(r, cfg->use_mclk, 2, 2);
r = FLD_MOD(r, cfg->en_acr_pkt, 1, 1);
r = FLD_MOD(r, cfg->cts_mode, 0, 0);
- hdmi_write_reg(HDMI_CORE_AV_ACR_CTRL, r);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_ACR_CTRL, r);
- REG_FLD_MOD(HDMI_CORE_AV_N_SVAL1, cfg->n, 7, 0);
- REG_FLD_MOD(HDMI_CORE_AV_N_SVAL2, cfg->n >> 8, 7, 0);
- REG_FLD_MOD(HDMI_CORE_AV_N_SVAL3, cfg->n >> 16, 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_N_SVAL1, cfg->n, 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_N_SVAL2, cfg->n >> 8, 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_N_SVAL3, cfg->n >> 16, 7, 0);
if (cfg->cts_mode == HDMI_AUDIO_CTS_MODE_SW) {
- REG_FLD_MOD(HDMI_CORE_AV_CTS_SVAL1, cfg->cts, 7, 0);
- REG_FLD_MOD(HDMI_CORE_AV_CTS_SVAL2, cfg->cts >> 8, 7, 0);
- REG_FLD_MOD(HDMI_CORE_AV_CTS_SVAL3, cfg->cts >> 16, 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_CTS_SVAL1, cfg->cts, 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_CTS_SVAL2, cfg->cts >> 8, 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_CTS_SVAL3, cfg->cts >> 16, 7, 0);
} else {
/*
* HDMI IP uses this configuration to divide the MCLK to
* update CTS value.
*/
- REG_FLD_MOD(HDMI_CORE_AV_FREQ_SVAL, cfg->mclk_mode, 2, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_FREQ_SVAL, cfg->mclk_mode, 2, 0);
/* Configure clock for audio packets */
- REG_FLD_MOD(HDMI_CORE_AV_AUD_PAR_BUSCLK_1,
- cfg->aud_par_busclk, 7, 0);
- REG_FLD_MOD(HDMI_CORE_AV_AUD_PAR_BUSCLK_2,
- (cfg->aud_par_busclk >> 8), 7, 0);
- REG_FLD_MOD(HDMI_CORE_AV_AUD_PAR_BUSCLK_3,
- (cfg->aud_par_busclk >> 16), 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_AUD_PAR_BUSCLK_1,
+ cfg->aud_par_busclk, 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_AUD_PAR_BUSCLK_2,
+ (cfg->aud_par_busclk >> 8), 7, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_AUD_PAR_BUSCLK_3,
+ (cfg->aud_par_busclk >> 16), 7, 0);
}
/* Override of SPDIF sample frequency with value in I2S_CHST4 */
- REG_FLD_MOD(HDMI_CORE_AV_SPDIF_CTRL, cfg->fs_override, 1, 1);
+ REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_SPDIF_CTRL,
+ cfg->fs_override, 1, 1);
/* I2S parameters */
- REG_FLD_MOD(HDMI_CORE_AV_I2S_CHST4, cfg->freq_sample, 3, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_I2S_CHST4,
+ cfg->freq_sample, 3, 0);
- r = hdmi_read_reg(HDMI_CORE_AV_I2S_IN_CTRL);
+ r = hdmi_read_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_I2S_IN_CTRL);
r = FLD_MOD(r, cfg->i2s_cfg.en_high_bitrate_aud, 7, 7);
r = FLD_MOD(r, cfg->i2s_cfg.sck_edge_mode, 6, 6);
r = FLD_MOD(r, cfg->i2s_cfg.cbit_order, 5, 5);
@@ -1397,27 +1475,29 @@ static void hdmi_core_audio_config(struct hdmi_core_audio_config *cfg)
r = FLD_MOD(r, cfg->i2s_cfg.justification, 2, 2);
r = FLD_MOD(r, cfg->i2s_cfg.direction, 1, 1);
r = FLD_MOD(r, cfg->i2s_cfg.shift, 0, 0);
- hdmi_write_reg(HDMI_CORE_AV_I2S_IN_CTRL, r);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_I2S_IN_CTRL, r);
- r = hdmi_read_reg(HDMI_CORE_AV_I2S_CHST5);
+ r = hdmi_read_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_I2S_CHST5);
r = FLD_MOD(r, cfg->freq_sample, 7, 4);
r = FLD_MOD(r, cfg->i2s_cfg.word_length, 3, 1);
r = FLD_MOD(r, cfg->i2s_cfg.word_max_length, 0, 0);
- hdmi_write_reg(HDMI_CORE_AV_I2S_CHST5, r);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_I2S_CHST5, r);
- REG_FLD_MOD(HDMI_CORE_AV_I2S_IN_LEN, cfg->i2s_cfg.in_length_bits, 3, 0);
+ REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_I2S_IN_LEN,
+ cfg->i2s_cfg.in_length_bits, 3, 0);
/* Audio channels and mode parameters */
- REG_FLD_MOD(HDMI_CORE_AV_HDMI_CTRL, cfg->layout, 2, 1);
- r = hdmi_read_reg(HDMI_CORE_AV_AUD_MODE);
+ REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_HDMI_CTRL,
+ cfg->layout, 2, 1);
+ r = hdmi_read_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_MODE);
r = FLD_MOD(r, cfg->i2s_cfg.active_sds, 7, 4);
r = FLD_MOD(r, cfg->en_dsd_audio, 3, 3);
r = FLD_MOD(r, cfg->en_parallel_aud_input, 2, 2);
r = FLD_MOD(r, cfg->en_spdif, 1, 1);
- hdmi_write_reg(HDMI_CORE_AV_AUD_MODE, r);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_MODE, r);
}
-static void hdmi_core_audio_infoframe_config(
+static void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_infoframe_audio *info_aud)
{
u8 val;
@@ -1428,38 +1508,39 @@ static void hdmi_core_audio_infoframe_config(
* described in HDMI 1.4a Section 8.2.2 specification.
* Checksum calculation is defined in Section 5.3.5.
*/
- hdmi_write_reg(HDMI_CORE_AV_AUDIO_TYPE, 0x84);
- hdmi_write_reg(HDMI_CORE_AV_AUDIO_VERS, 0x01);
- hdmi_write_reg(HDMI_CORE_AV_AUDIO_LEN, 0x0a);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUDIO_TYPE, 0x84);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUDIO_VERS, 0x01);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUDIO_LEN, 0x0a);
sum += 0x84 + 0x001 + 0x00a;
val = (info_aud->db1_coding_type << 4)
| (info_aud->db1_channel_count - 1);
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(0), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(0), val);
sum += val;
val = (info_aud->db2_sample_freq << 2) | info_aud->db2_sample_size;
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(1), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(1), val);
sum += val;
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(2), 0x00);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(2), 0x00);
val = info_aud->db4_channel_alloc;
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(3), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(3), val);
sum += val;
val = (info_aud->db5_downmix_inh << 7) | (info_aud->db5_lsv << 3);
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(4), val);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(4), val);
sum += val;
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(5), 0x00);
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(6), 0x00);
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(7), 0x00);
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(8), 0x00);
- hdmi_write_reg(HDMI_CORE_AV_AUD_DBYTE(9), 0x00);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(5), 0x00);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(6), 0x00);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(7), 0x00);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(8), 0x00);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AUD_DBYTE(9), 0x00);
checksum = 0x100 - sum;
- hdmi_write_reg(HDMI_CORE_AV_AUDIO_CHSUM, checksum);
+ hdmi_write_reg(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_AUDIO_CHSUM, checksum);
/*
* TODO: Add MPEG and SPD enable and repeat cfg when EDID parsing
@@ -1467,7 +1548,8 @@ static void hdmi_core_audio_infoframe_config(
*/
}
-static int hdmi_config_audio_acr(u32 sample_freq, u32 *n, u32 *cts)
+static int hdmi_config_audio_acr(struct hdmi_ip_data *ip_data,
+ u32 sample_freq, u32 *n, u32 *cts)
{
u32 r;
u32 deep_color = 0;
@@ -1479,7 +1561,7 @@ static int hdmi_config_audio_acr(u32 sample_freq, u32 *n, u32 *cts)
* Obtain current deep color configuration. This needed
* to calculate the TMDS clock based on the pixel clock.
*/
- r = REG_GET(HDMI_WP_VIDEO_CFG, 1, 0);
+ r = REG_GET(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, 1, 0);
switch (r) {
case 1: /* No deep color selected */
deep_color = 100;
@@ -1523,7 +1605,8 @@ static int hdmi_config_audio_acr(u32 sample_freq, u32 *n, u32 *cts)
return 0;
}
-static int hdmi_audio_hw_params(struct snd_pcm_substream *substream,
+static int hdmi_audio_hw_params(struct hdmi_ip_data *ip_data,
+ struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
{
@@ -1577,7 +1660,7 @@ static int hdmi_audio_hw_params(struct snd_pcm_substream *substream,
return -EINVAL;
}
- err = hdmi_config_audio_acr(params_rate(params), &n, &cts);
+ err = hdmi_config_audio_acr(ip_data, params_rate(params), &n, &cts);
if (err < 0)
return err;
@@ -1593,8 +1676,8 @@ static int hdmi_audio_hw_params(struct snd_pcm_substream *substream,
audio_dma.mode = HDMI_AUDIO_TRANSF_DMA;
audio_dma.fifo_threshold = 0x20; /* in number of samples */
- hdmi_wp_audio_config_dma(&audio_dma);
- hdmi_wp_audio_config_format(&audio_format);
+ hdmi_wp_audio_config_dma(ip_data, &audio_dma);
+ hdmi_wp_audio_config_format(ip_data, &audio_format);
/*
* I2S config
@@ -1638,7 +1721,7 @@ static int hdmi_audio_hw_params(struct snd_pcm_substream *substream,
/* Use parallel audio interface */
core_cfg.en_parallel_aud_input = true;
- hdmi_core_audio_config(&core_cfg);
+ hdmi_core_audio_config(ip_data, &core_cfg);
/*
* Configure packet
@@ -1652,29 +1735,36 @@ static int hdmi_audio_hw_params(struct snd_pcm_substream *substream,
aud_if_cfg.db5_downmix_inh = false;
aud_if_cfg.db5_lsv = 0;
- hdmi_core_audio_infoframe_config(&aud_if_cfg);
+ hdmi_core_audio_infoframe_config(ip_data, &aud_if_cfg);
return 0;
}
-static int hdmi_audio_trigger(struct snd_pcm_substream *substream, int cmd,
- struct snd_soc_dai *dai)
+static int hdmi_audio_trigger(struct hdmi_ip_data *ip_data,
+ struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
{
int err = 0;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- REG_FLD_MOD(HDMI_CORE_AV_AUD_MODE, 1, 0, 0);
- REG_FLD_MOD(HDMI_WP_AUDIO_CTRL, 1, 31, 31);
- REG_FLD_MOD(HDMI_WP_AUDIO_CTRL, 1, 30, 30);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_AUD_MODE, 1, 0, 0);
+ REG_FLD_MOD(hdmi_wp_base(ip_data),
+ HDMI_WP_AUDIO_CTRL, 1, 31, 31);
+ REG_FLD_MOD(hdmi_wp_base(ip_data),
+ HDMI_WP_AUDIO_CTRL, 1, 30, 30);
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- REG_FLD_MOD(HDMI_CORE_AV_AUD_MODE, 0, 0, 0);
- REG_FLD_MOD(HDMI_WP_AUDIO_CTRL, 0, 30, 30);
- REG_FLD_MOD(HDMI_WP_AUDIO_CTRL, 0, 31, 31);
+ REG_FLD_MOD(hdmi_av_base(ip_data),
+ HDMI_CORE_AV_AUD_MODE, 0, 0, 0);
+ REG_FLD_MOD(hdmi_wp_base(ip_data),
+ HDMI_WP_AUDIO_CTRL, 0, 30, 30);
+ REG_FLD_MOD(hdmi_wp_base(ip_data),
+ HDMI_WP_AUDIO_CTRL, 0, 31, 31);
break;
default:
err = -EINVAL;
@@ -1765,20 +1855,26 @@ static int omapdss_hdmihw_probe(struct platform_device *pdev)
}
/* Base address taken from platform */
- hdmi.base_wp = ioremap(hdmi_mem->start, resource_size(hdmi_mem));
- if (!hdmi.base_wp) {
+ hdmi.hdmi_data.base_wp = ioremap(hdmi_mem->start,
+ resource_size(hdmi_mem));
+ if (!hdmi.hdmi_data.base_wp) {
DSSERR("can't ioremap WP\n");
return -ENOMEM;
}
r = hdmi_get_clocks(pdev);
if (r) {
- iounmap(hdmi.base_wp);
+ iounmap(hdmi.hdmi_data.base_wp);
return r;
}
pm_runtime_enable(&pdev->dev);
+ hdmi.hdmi_data.hdmi_core_sys_offset = HDMI_CORE_SYS;
+ hdmi.hdmi_data.hdmi_core_av_offset = HDMI_CORE_AV;
+ hdmi.hdmi_data.hdmi_pll_offset = HDMI_PLLCTRL;
+ hdmi.hdmi_data.hdmi_phy_offset = HDMI_PHY;
+
hdmi_panel_init();
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
@@ -1808,7 +1904,7 @@ static int omapdss_hdmihw_remove(struct platform_device *pdev)
hdmi_put_clocks();
- iounmap(hdmi.base_wp);
+ iounmap(hdmi.hdmi_data.base_wp);
return 0;
}
diff --git a/drivers/video/omap2/dss/hdmi.h b/drivers/video/omap2/dss/hdmi.h
index c885f9c..2281823 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi.h
@@ -24,174 +24,163 @@
#include <linux/string.h>
#include <video/omapdss.h>
-#define HDMI_WP 0x0
-#define HDMI_CORE_SYS 0x400
-#define HDMI_CORE_AV 0x900
-#define HDMI_PLLCTRL 0x200
-#define HDMI_PHY 0x300
-
struct hdmi_reg { u16 idx; };
#define HDMI_REG(idx) ((const struct hdmi_reg) { idx })
/* HDMI Wrapper */
-#define HDMI_WP_REG(idx) HDMI_REG(HDMI_WP + idx)
-
-#define HDMI_WP_REVISION HDMI_WP_REG(0x0)
-#define HDMI_WP_SYSCONFIG HDMI_WP_REG(0x10)
-#define HDMI_WP_IRQSTATUS_RAW HDMI_WP_REG(0x24)
-#define HDMI_WP_IRQSTATUS HDMI_WP_REG(0x28)
-#define HDMI_WP_PWR_CTRL HDMI_WP_REG(0x40)
-#define HDMI_WP_IRQENABLE_SET HDMI_WP_REG(0x2C)
-#define HDMI_WP_VIDEO_CFG HDMI_WP_REG(0x50)
-#define HDMI_WP_VIDEO_SIZE HDMI_WP_REG(0x60)
-#define HDMI_WP_VIDEO_TIMING_H HDMI_WP_REG(0x68)
-#define HDMI_WP_VIDEO_TIMING_V HDMI_WP_REG(0x6C)
-#define HDMI_WP_WP_CLK HDMI_WP_REG(0x70)
-#define HDMI_WP_AUDIO_CFG HDMI_WP_REG(0x80)
-#define HDMI_WP_AUDIO_CFG2 HDMI_WP_REG(0x84)
-#define HDMI_WP_AUDIO_CTRL HDMI_WP_REG(0x88)
-#define HDMI_WP_AUDIO_DATA HDMI_WP_REG(0x8C)
+
+#define HDMI_WP_REVISION HDMI_REG(0x0)
+#define HDMI_WP_SYSCONFIG HDMI_REG(0x10)
+#define HDMI_WP_IRQSTATUS_RAW HDMI_REG(0x24)
+#define HDMI_WP_IRQSTATUS HDMI_REG(0x28)
+#define HDMI_WP_PWR_CTRL HDMI_REG(0x40)
+#define HDMI_WP_IRQENABLE_SET HDMI_REG(0x2C)
+#define HDMI_WP_VIDEO_CFG HDMI_REG(0x50)
+#define HDMI_WP_VIDEO_SIZE HDMI_REG(0x60)
+#define HDMI_WP_VIDEO_TIMING_H HDMI_REG(0x68)
+#define HDMI_WP_VIDEO_TIMING_V HDMI_REG(0x6C)
+#define HDMI_WP_WP_CLK HDMI_REG(0x70)
+#define HDMI_WP_AUDIO_CFG HDMI_REG(0x80)
+#define HDMI_WP_AUDIO_CFG2 HDMI_REG(0x84)
+#define HDMI_WP_AUDIO_CTRL HDMI_REG(0x88)
+#define HDMI_WP_AUDIO_DATA HDMI_REG(0x8C)
/* HDMI IP Core System */
-#define HDMI_CORE_SYS_REG(idx) HDMI_REG(HDMI_CORE_SYS + idx)
-
-#define HDMI_CORE_SYS_VND_IDL HDMI_CORE_SYS_REG(0x0)
-#define HDMI_CORE_SYS_DEV_IDL HDMI_CORE_SYS_REG(0x8)
-#define HDMI_CORE_SYS_DEV_IDH HDMI_CORE_SYS_REG(0xC)
-#define HDMI_CORE_SYS_DEV_REV HDMI_CORE_SYS_REG(0x10)
-#define HDMI_CORE_SYS_SRST HDMI_CORE_SYS_REG(0x14)
-#define HDMI_CORE_CTRL1 HDMI_CORE_SYS_REG(0x20)
-#define HDMI_CORE_SYS_SYS_STAT HDMI_CORE_SYS_REG(0x24)
-#define HDMI_CORE_SYS_VID_ACEN HDMI_CORE_SYS_REG(0x124)
-#define HDMI_CORE_SYS_VID_MODE HDMI_CORE_SYS_REG(0x128)
-#define HDMI_CORE_SYS_INTR_STATE HDMI_CORE_SYS_REG(0x1C0)
-#define HDMI_CORE_SYS_INTR1 HDMI_CORE_SYS_REG(0x1C4)
-#define HDMI_CORE_SYS_INTR2 HDMI_CORE_SYS_REG(0x1C8)
-#define HDMI_CORE_SYS_INTR3 HDMI_CORE_SYS_REG(0x1CC)
-#define HDMI_CORE_SYS_INTR4 HDMI_CORE_SYS_REG(0x1D0)
-#define HDMI_CORE_SYS_UMASK1 HDMI_CORE_SYS_REG(0x1D4)
-#define HDMI_CORE_SYS_TMDS_CTRL HDMI_CORE_SYS_REG(0x208)
-#define HDMI_CORE_SYS_DE_DLY HDMI_CORE_SYS_REG(0xC8)
-#define HDMI_CORE_SYS_DE_CTRL HDMI_CORE_SYS_REG(0xCC)
-#define HDMI_CORE_SYS_DE_TOP HDMI_CORE_SYS_REG(0xD0)
-#define HDMI_CORE_SYS_DE_CNTL HDMI_CORE_SYS_REG(0xD8)
-#define HDMI_CORE_SYS_DE_CNTH HDMI_CORE_SYS_REG(0xDC)
-#define HDMI_CORE_SYS_DE_LINL HDMI_CORE_SYS_REG(0xE0)
-#define HDMI_CORE_SYS_DE_LINH_1 HDMI_CORE_SYS_REG(0xE4)
+
+#define HDMI_CORE_SYS_VND_IDL HDMI_REG(0x0)
+#define HDMI_CORE_SYS_DEV_IDL HDMI_REG(0x8)
+#define HDMI_CORE_SYS_DEV_IDH HDMI_REG(0xC)
+#define HDMI_CORE_SYS_DEV_REV HDMI_REG(0x10)
+#define HDMI_CORE_SYS_SRST HDMI_REG(0x14)
+#define HDMI_CORE_CTRL1 HDMI_REG(0x20)
+#define HDMI_CORE_SYS_SYS_STAT HDMI_REG(0x24)
+#define HDMI_CORE_SYS_VID_ACEN HDMI_REG(0x124)
+#define HDMI_CORE_SYS_VID_MODE HDMI_REG(0x128)
+#define HDMI_CORE_SYS_INTR_STATE HDMI_REG(0x1C0)
+#define HDMI_CORE_SYS_INTR1 HDMI_REG(0x1C4)
+#define HDMI_CORE_SYS_INTR2 HDMI_REG(0x1C8)
+#define HDMI_CORE_SYS_INTR3 HDMI_REG(0x1CC)
+#define HDMI_CORE_SYS_INTR4 HDMI_REG(0x1D0)
+#define HDMI_CORE_SYS_UMASK1 HDMI_REG(0x1D4)
+#define HDMI_CORE_SYS_TMDS_CTRL HDMI_REG(0x208)
+#define HDMI_CORE_SYS_DE_DLY HDMI_REG(0xC8)
+#define HDMI_CORE_SYS_DE_CTRL HDMI_REG(0xCC)
+#define HDMI_CORE_SYS_DE_TOP HDMI_REG(0xD0)
+#define HDMI_CORE_SYS_DE_CNTL HDMI_REG(0xD8)
+#define HDMI_CORE_SYS_DE_CNTH HDMI_REG(0xDC)
+#define HDMI_CORE_SYS_DE_LINL HDMI_REG(0xE0)
+#define HDMI_CORE_SYS_DE_LINH_1 HDMI_REG(0xE4)
#define HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC 0x1
#define HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC 0x1
#define HDMI_CORE_CTRL1_BSEL_24BITBUS 0x1
#define HDMI_CORE_CTRL1_EDGE_RISINGEDGE 0x1
/* HDMI DDC E-DID */
-#define HDMI_CORE_DDC_CMD HDMI_CORE_SYS_REG(0x3CC)
-#define HDMI_CORE_DDC_STATUS HDMI_CORE_SYS_REG(0x3C8)
-#define HDMI_CORE_DDC_ADDR HDMI_CORE_SYS_REG(0x3B4)
-#define HDMI_CORE_DDC_OFFSET HDMI_CORE_SYS_REG(0x3BC)
-#define HDMI_CORE_DDC_COUNT1 HDMI_CORE_SYS_REG(0x3C0)
-#define HDMI_CORE_DDC_COUNT2 HDMI_CORE_SYS_REG(0x3C4)
-#define HDMI_CORE_DDC_DATA HDMI_CORE_SYS_REG(0x3D0)
-#define HDMI_CORE_DDC_SEGM HDMI_CORE_SYS_REG(0x3B8)
+#define HDMI_CORE_DDC_CMD HDMI_REG(0x3CC)
+#define HDMI_CORE_DDC_STATUS HDMI_REG(0x3C8)
+#define HDMI_CORE_DDC_ADDR HDMI_REG(0x3B4)
+#define HDMI_CORE_DDC_OFFSET HDMI_REG(0x3BC)
+#define HDMI_CORE_DDC_COUNT1 HDMI_REG(0x3C0)
+#define HDMI_CORE_DDC_COUNT2 HDMI_REG(0x3C4)
+#define HDMI_CORE_DDC_DATA HDMI_REG(0x3D0)
+#define HDMI_CORE_DDC_SEGM HDMI_REG(0x3B8)
/* HDMI IP Core Audio Video */
-#define HDMI_CORE_AV_REG(idx) HDMI_REG(HDMI_CORE_AV + idx)
-
-#define HDMI_CORE_AV_HDMI_CTRL HDMI_CORE_AV_REG(0xBC)
-#define HDMI_CORE_AV_DPD HDMI_CORE_AV_REG(0xF4)
-#define HDMI_CORE_AV_PB_CTRL1 HDMI_CORE_AV_REG(0xF8)
-#define HDMI_CORE_AV_PB_CTRL2 HDMI_CORE_AV_REG(0xFC)
-#define HDMI_CORE_AV_AVI_TYPE HDMI_CORE_AV_REG(0x100)
-#define HDMI_CORE_AV_AVI_VERS HDMI_CORE_AV_REG(0x104)
-#define HDMI_CORE_AV_AVI_LEN HDMI_CORE_AV_REG(0x108)
-#define HDMI_CORE_AV_AVI_CHSUM HDMI_CORE_AV_REG(0x10C)
-#define HDMI_CORE_AV_AVI_DBYTE(n) HDMI_CORE_AV_REG(n * 4 + 0x110)
-#define HDMI_CORE_AV_AVI_DBYTE_NELEMS HDMI_CORE_AV_REG(15)
-#define HDMI_CORE_AV_SPD_DBYTE HDMI_CORE_AV_REG(0x190)
-#define HDMI_CORE_AV_SPD_DBYTE_NELEMS HDMI_CORE_AV_REG(27)
-#define HDMI_CORE_AV_AUD_DBYTE(n) HDMI_CORE_AV_REG(n * 4 + 0x210)
-#define HDMI_CORE_AV_AUD_DBYTE_NELEMS HDMI_CORE_AV_REG(10)
-#define HDMI_CORE_AV_MPEG_DBYTE HDMI_CORE_AV_REG(0x290)
-#define HDMI_CORE_AV_MPEG_DBYTE_NELEMS HDMI_CORE_AV_REG(27)
-#define HDMI_CORE_AV_GEN_DBYTE HDMI_CORE_AV_REG(0x300)
-#define HDMI_CORE_AV_GEN_DBYTE_NELEMS HDMI_CORE_AV_REG(31)
-#define HDMI_CORE_AV_GEN2_DBYTE HDMI_CORE_AV_REG(0x380)
-#define HDMI_CORE_AV_GEN2_DBYTE_NELEMS HDMI_CORE_AV_REG(31)
-#define HDMI_CORE_AV_ACR_CTRL HDMI_CORE_AV_REG(0x4)
-#define HDMI_CORE_AV_FREQ_SVAL HDMI_CORE_AV_REG(0x8)
-#define HDMI_CORE_AV_N_SVAL1 HDMI_CORE_AV_REG(0xC)
-#define HDMI_CORE_AV_N_SVAL2 HDMI_CORE_AV_REG(0x10)
-#define HDMI_CORE_AV_N_SVAL3 HDMI_CORE_AV_REG(0x14)
-#define HDMI_CORE_AV_CTS_SVAL1 HDMI_CORE_AV_REG(0x18)
-#define HDMI_CORE_AV_CTS_SVAL2 HDMI_CORE_AV_REG(0x1C)
-#define HDMI_CORE_AV_CTS_SVAL3 HDMI_CORE_AV_REG(0x20)
-#define HDMI_CORE_AV_CTS_HVAL1 HDMI_CORE_AV_REG(0x24)
-#define HDMI_CORE_AV_CTS_HVAL2 HDMI_CORE_AV_REG(0x28)
-#define HDMI_CORE_AV_CTS_HVAL3 HDMI_CORE_AV_REG(0x2C)
-#define HDMI_CORE_AV_AUD_MODE HDMI_CORE_AV_REG(0x50)
-#define HDMI_CORE_AV_SPDIF_CTRL HDMI_CORE_AV_REG(0x54)
-#define HDMI_CORE_AV_HW_SPDIF_FS HDMI_CORE_AV_REG(0x60)
-#define HDMI_CORE_AV_SWAP_I2S HDMI_CORE_AV_REG(0x64)
-#define HDMI_CORE_AV_SPDIF_ERTH HDMI_CORE_AV_REG(0x6C)
-#define HDMI_CORE_AV_I2S_IN_MAP HDMI_CORE_AV_REG(0x70)
-#define HDMI_CORE_AV_I2S_IN_CTRL HDMI_CORE_AV_REG(0x74)
-#define HDMI_CORE_AV_I2S_CHST0 HDMI_CORE_AV_REG(0x78)
-#define HDMI_CORE_AV_I2S_CHST1 HDMI_CORE_AV_REG(0x7C)
-#define HDMI_CORE_AV_I2S_CHST2 HDMI_CORE_AV_REG(0x80)
-#define HDMI_CORE_AV_I2S_CHST4 HDMI_CORE_AV_REG(0x84)
-#define HDMI_CORE_AV_I2S_CHST5 HDMI_CORE_AV_REG(0x88)
-#define HDMI_CORE_AV_ASRC HDMI_CORE_AV_REG(0x8C)
-#define HDMI_CORE_AV_I2S_IN_LEN HDMI_CORE_AV_REG(0x90)
-#define HDMI_CORE_AV_HDMI_CTRL HDMI_CORE_AV_REG(0xBC)
-#define HDMI_CORE_AV_AUDO_TXSTAT HDMI_CORE_AV_REG(0xC0)
-#define HDMI_CORE_AV_AUD_PAR_BUSCLK_1 HDMI_CORE_AV_REG(0xCC)
-#define HDMI_CORE_AV_AUD_PAR_BUSCLK_2 HDMI_CORE_AV_REG(0xD0)
-#define HDMI_CORE_AV_AUD_PAR_BUSCLK_3 HDMI_CORE_AV_REG(0xD4)
-#define HDMI_CORE_AV_TEST_TXCTRL HDMI_CORE_AV_REG(0xF0)
-#define HDMI_CORE_AV_DPD HDMI_CORE_AV_REG(0xF4)
-#define HDMI_CORE_AV_PB_CTRL1 HDMI_CORE_AV_REG(0xF8)
-#define HDMI_CORE_AV_PB_CTRL2 HDMI_CORE_AV_REG(0xFC)
-#define HDMI_CORE_AV_AVI_TYPE HDMI_CORE_AV_REG(0x100)
-#define HDMI_CORE_AV_AVI_VERS HDMI_CORE_AV_REG(0x104)
-#define HDMI_CORE_AV_AVI_LEN HDMI_CORE_AV_REG(0x108)
-#define HDMI_CORE_AV_AVI_CHSUM HDMI_CORE_AV_REG(0x10C)
-#define HDMI_CORE_AV_SPD_TYPE HDMI_CORE_AV_REG(0x180)
-#define HDMI_CORE_AV_SPD_VERS HDMI_CORE_AV_REG(0x184)
-#define HDMI_CORE_AV_SPD_LEN HDMI_CORE_AV_REG(0x188)
-#define HDMI_CORE_AV_SPD_CHSUM HDMI_CORE_AV_REG(0x18C)
-#define HDMI_CORE_AV_AUDIO_TYPE HDMI_CORE_AV_REG(0x200)
-#define HDMI_CORE_AV_AUDIO_VERS HDMI_CORE_AV_REG(0x204)
-#define HDMI_CORE_AV_AUDIO_LEN HDMI_CORE_AV_REG(0x208)
-#define HDMI_CORE_AV_AUDIO_CHSUM HDMI_CORE_AV_REG(0x20C)
-#define HDMI_CORE_AV_MPEG_TYPE HDMI_CORE_AV_REG(0x280)
-#define HDMI_CORE_AV_MPEG_VERS HDMI_CORE_AV_REG(0x284)
-#define HDMI_CORE_AV_MPEG_LEN HDMI_CORE_AV_REG(0x288)
-#define HDMI_CORE_AV_MPEG_CHSUM HDMI_CORE_AV_REG(0x28C)
-#define HDMI_CORE_AV_CP_BYTE1 HDMI_CORE_AV_REG(0x37C)
-#define HDMI_CORE_AV_CEC_ADDR_ID HDMI_CORE_AV_REG(0x3FC)
+
+#define HDMI_CORE_AV_HDMI_CTRL HDMI_REG(0xBC)
+#define HDMI_CORE_AV_DPD HDMI_REG(0xF4)
+#define HDMI_CORE_AV_PB_CTRL1 HDMI_REG(0xF8)
+#define HDMI_CORE_AV_PB_CTRL2 HDMI_REG(0xFC)
+#define HDMI_CORE_AV_AVI_TYPE HDMI_REG(0x100)
+#define HDMI_CORE_AV_AVI_VERS HDMI_REG(0x104)
+#define HDMI_CORE_AV_AVI_LEN HDMI_REG(0x108)
+#define HDMI_CORE_AV_AVI_CHSUM HDMI_REG(0x10C)
+#define HDMI_CORE_AV_AVI_DBYTE(n) HDMI_REG(n * 4 + 0x110)
+#define HDMI_CORE_AV_AVI_DBYTE_NELEMS HDMI_REG(15)
+#define HDMI_CORE_AV_SPD_DBYTE HDMI_REG(0x190)
+#define HDMI_CORE_AV_SPD_DBYTE_NELEMS HDMI_REG(27)
+#define HDMI_CORE_AV_AUD_DBYTE(n) HDMI_REG(n * 4 + 0x210)
+#define HDMI_CORE_AV_AUD_DBYTE_NELEMS HDMI_REG(10)
+#define HDMI_CORE_AV_MPEG_DBYTE HDMI_REG(0x290)
+#define HDMI_CORE_AV_MPEG_DBYTE_NELEMS HDMI_REG(27)
+#define HDMI_CORE_AV_GEN_DBYTE HDMI_REG(0x300)
+#define HDMI_CORE_AV_GEN_DBYTE_NELEMS HDMI_REG(31)
+#define HDMI_CORE_AV_GEN2_DBYTE HDMI_REG(0x380)
+#define HDMI_CORE_AV_GEN2_DBYTE_NELEMS HDMI_REG(31)
+#define HDMI_CORE_AV_ACR_CTRL HDMI_REG(0x4)
+#define HDMI_CORE_AV_FREQ_SVAL HDMI_REG(0x8)
+#define HDMI_CORE_AV_N_SVAL1 HDMI_REG(0xC)
+#define HDMI_CORE_AV_N_SVAL2 HDMI_REG(0x10)
+#define HDMI_CORE_AV_N_SVAL3 HDMI_REG(0x14)
+#define HDMI_CORE_AV_CTS_SVAL1 HDMI_REG(0x18)
+#define HDMI_CORE_AV_CTS_SVAL2 HDMI_REG(0x1C)
+#define HDMI_CORE_AV_CTS_SVAL3 HDMI_REG(0x20)
+#define HDMI_CORE_AV_CTS_HVAL1 HDMI_REG(0x24)
+#define HDMI_CORE_AV_CTS_HVAL2 HDMI_REG(0x28)
+#define HDMI_CORE_AV_CTS_HVAL3 HDMI_REG(0x2C)
+#define HDMI_CORE_AV_AUD_MODE HDMI_REG(0x50)
+#define HDMI_CORE_AV_SPDIF_CTRL HDMI_REG(0x54)
+#define HDMI_CORE_AV_HW_SPDIF_FS HDMI_REG(0x60)
+#define HDMI_CORE_AV_SWAP_I2S HDMI_REG(0x64)
+#define HDMI_CORE_AV_SPDIF_ERTH HDMI_REG(0x6C)
+#define HDMI_CORE_AV_I2S_IN_MAP HDMI_REG(0x70)
+#define HDMI_CORE_AV_I2S_IN_CTRL HDMI_REG(0x74)
+#define HDMI_CORE_AV_I2S_CHST0 HDMI_REG(0x78)
+#define HDMI_CORE_AV_I2S_CHST1 HDMI_REG(0x7C)
+#define HDMI_CORE_AV_I2S_CHST2 HDMI_REG(0x80)
+#define HDMI_CORE_AV_I2S_CHST4 HDMI_REG(0x84)
+#define HDMI_CORE_AV_I2S_CHST5 HDMI_REG(0x88)
+#define HDMI_CORE_AV_ASRC HDMI_REG(0x8C)
+#define HDMI_CORE_AV_I2S_IN_LEN HDMI_REG(0x90)
+#define HDMI_CORE_AV_HDMI_CTRL HDMI_REG(0xBC)
+#define HDMI_CORE_AV_AUDO_TXSTAT HDMI_REG(0xC0)
+#define HDMI_CORE_AV_AUD_PAR_BUSCLK_1 HDMI_REG(0xCC)
+#define HDMI_CORE_AV_AUD_PAR_BUSCLK_2 HDMI_REG(0xD0)
+#define HDMI_CORE_AV_AUD_PAR_BUSCLK_3 HDMI_REG(0xD4)
+#define HDMI_CORE_AV_TEST_TXCTRL HDMI_REG(0xF0)
+#define HDMI_CORE_AV_DPD HDMI_REG(0xF4)
+#define HDMI_CORE_AV_PB_CTRL1 HDMI_REG(0xF8)
+#define HDMI_CORE_AV_PB_CTRL2 HDMI_REG(0xFC)
+#define HDMI_CORE_AV_AVI_TYPE HDMI_REG(0x100)
+#define HDMI_CORE_AV_AVI_VERS HDMI_REG(0x104)
+#define HDMI_CORE_AV_AVI_LEN HDMI_REG(0x108)
+#define HDMI_CORE_AV_AVI_CHSUM HDMI_REG(0x10C)
+#define HDMI_CORE_AV_SPD_TYPE HDMI_REG(0x180)
+#define HDMI_CORE_AV_SPD_VERS HDMI_REG(0x184)
+#define HDMI_CORE_AV_SPD_LEN HDMI_REG(0x188)
+#define HDMI_CORE_AV_SPD_CHSUM HDMI_REG(0x18C)
+#define HDMI_CORE_AV_AUDIO_TYPE HDMI_REG(0x200)
+#define HDMI_CORE_AV_AUDIO_VERS HDMI_REG(0x204)
+#define HDMI_CORE_AV_AUDIO_LEN HDMI_REG(0x208)
+#define HDMI_CORE_AV_AUDIO_CHSUM HDMI_REG(0x20C)
+#define HDMI_CORE_AV_MPEG_TYPE HDMI_REG(0x280)
+#define HDMI_CORE_AV_MPEG_VERS HDMI_REG(0x284)
+#define HDMI_CORE_AV_MPEG_LEN HDMI_REG(0x288)
+#define HDMI_CORE_AV_MPEG_CHSUM HDMI_REG(0x28C)
+#define HDMI_CORE_AV_CP_BYTE1 HDMI_REG(0x37C)
+#define HDMI_CORE_AV_CEC_ADDR_ID HDMI_REG(0x3FC)
#define HDMI_CORE_AV_SPD_DBYTE_ELSIZE 0x4
#define HDMI_CORE_AV_GEN2_DBYTE_ELSIZE 0x4
#define HDMI_CORE_AV_MPEG_DBYTE_ELSIZE 0x4
#define HDMI_CORE_AV_GEN_DBYTE_ELSIZE 0x4
/* PLL */
-#define HDMI_PLL_REG(idx) HDMI_REG(HDMI_PLLCTRL + idx)
-#define PLLCTRL_PLL_CONTROL HDMI_PLL_REG(0x0)
-#define PLLCTRL_PLL_STATUS HDMI_PLL_REG(0x4)
-#define PLLCTRL_PLL_GO HDMI_PLL_REG(0x8)
-#define PLLCTRL_CFG1 HDMI_PLL_REG(0xC)
-#define PLLCTRL_CFG2 HDMI_PLL_REG(0x10)
-#define PLLCTRL_CFG3 HDMI_PLL_REG(0x14)
-#define PLLCTRL_CFG4 HDMI_PLL_REG(0x20)
+#define PLLCTRL_PLL_CONTROL HDMI_REG(0x0)
+#define PLLCTRL_PLL_STATUS HDMI_REG(0x4)
+#define PLLCTRL_PLL_GO HDMI_REG(0x8)
+#define PLLCTRL_CFG1 HDMI_REG(0xC)
+#define PLLCTRL_CFG2 HDMI_REG(0x10)
+#define PLLCTRL_CFG3 HDMI_REG(0x14)
+#define PLLCTRL_CFG4 HDMI_REG(0x20)
/* HDMI PHY */
-#define HDMI_PHY_REG(idx) HDMI_REG(HDMI_PHY + idx)
-#define HDMI_TXPHY_TX_CTRL HDMI_PHY_REG(0x0)
-#define HDMI_TXPHY_DIGITAL_CTRL HDMI_PHY_REG(0x4)
-#define HDMI_TXPHY_POWER_CTRL HDMI_PHY_REG(0x8)
-#define HDMI_TXPHY_PAD_CFG_CTRL HDMI_PHY_REG(0xC)
+#define HDMI_TXPHY_TX_CTRL HDMI_REG(0x0)
+#define HDMI_TXPHY_DIGITAL_CTRL HDMI_REG(0x4)
+#define HDMI_TXPHY_POWER_CTRL HDMI_REG(0x8)
+#define HDMI_TXPHY_PAD_CFG_CTRL HDMI_REG(0xC)
/* HDMI EDID Length */
#define HDMI_EDID_MAX_LENGTH 256
@@ -203,10 +192,11 @@ struct hdmi_reg { u16 idx; };
#define OMAP_HDMI_TIMINGS_NB 34
-#define REG_FLD_MOD(idx, val, start, end) \
- hdmi_write_reg(idx, FLD_MOD(hdmi_read_reg(idx), val, start, end))
-#define REG_GET(idx, start, end) \
- FLD_GET(hdmi_read_reg(idx), start, end)
+#define REG_FLD_MOD(base, idx, val, start, end) \
+ hdmi_write_reg(base, idx, FLD_MOD(hdmi_read_reg(base, idx),\
+ val, start, end))
+#define REG_GET(base, idx, start, end) \
+ FLD_GET(hdmi_read_reg(base, idx), start, end)
/* HDMI timing structure */
struct hdmi_timings {
@@ -568,6 +558,14 @@ struct hdmi_video_interface {
int tm; /* Timing mode */
};
+struct hdmi_ip_data {
+ void __iomem *base_wp; /* HDMI wrapper */
+ unsigned long hdmi_core_sys_offset;
+ unsigned long hdmi_core_av_offset;
+ unsigned long hdmi_pll_offset;
+ unsigned long hdmi_phy_offset;
+};
+
struct hdmi_cm {
int code;
int mode;
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 2/8] OMAP4 : DSS : HDMI : Move the EDID portion from HDMI IP
2011-06-17 8:17 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
2011-06-17 8:17 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Mythri P K
2011-06-20 13:33 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Premi, Sanjeev
1 sibling, 1 reply; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
Clean up to move the EDID definition to hdmi.c from the header file which is IP
dependent.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 10 ++++++++++
drivers/video/omap2/dss/hdmi.h | 10 ----------
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 1d16ee2..4ee879a 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -49,6 +49,16 @@
#define HDMI_PLLCTRL 0x200
#define HDMI_PHY 0x300
+/* HDMI EDID Length move this */
+#define HDMI_EDID_MAX_LENGTH 256
+#define EDID_TIMING_DESCRIPTOR_SIZE 0x12
+#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
+#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
+#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
+#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
+
+#define OMAP_HDMI_TIMINGS_NB 34
+
static struct {
struct mutex lock;
struct omap_display_platform_data *pdata;
diff --git a/drivers/video/omap2/dss/hdmi.h b/drivers/video/omap2/dss/hdmi.h
index 2281823..f57ef4a 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi.h
@@ -182,16 +182,6 @@ struct hdmi_reg { u16 idx; };
#define HDMI_TXPHY_POWER_CTRL HDMI_REG(0x8)
#define HDMI_TXPHY_PAD_CFG_CTRL HDMI_REG(0xC)
-/* HDMI EDID Length */
-#define HDMI_EDID_MAX_LENGTH 256
-#define EDID_TIMING_DESCRIPTOR_SIZE 0x12
-#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
-#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
-#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
-#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
-
-#define OMAP_HDMI_TIMINGS_NB 34
-
#define REG_FLD_MOD(base, idx, val, start, end) \
hdmi_write_reg(base, idx, FLD_MOD(hdmi_read_reg(base, idx),\
val, start, end))
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure
2011-06-17 8:17 ` [PATCH 2/8] OMAP4 : DSS : HDMI : Move the EDID portion from HDMI IP Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
2011-06-17 8:17 ` [PATCH 4/8] OMAP4: DSS: HDMI: Move the common header file definition Mythri P K
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
Define new HDMI timings structure to replace the OMAP DSS timing strucutre in hdmi.c
to have the HDMI include defintion out of DSS.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 23 ++++++++++++++++++++---
drivers/video/omap2/dss/hdmi.h | 15 ++++++++++++++-
2 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 4ee879a..c24d573 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -593,6 +593,20 @@ static int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
return 0;
}
+static void copy_hdmi_to_dss_timings(struct hdmi_video_timings hdmi_timings,
+ struct omap_video_timings *timings)
+{
+ timings->x_res = hdmi_timings.x_res;
+ timings->y_res = hdmi_timings.y_res;
+ timings->pixel_clock = hdmi_timings.pixel_clock;
+ timings->hbp = hdmi_timings.hbp;
+ timings->hfp = hdmi_timings.hfp;
+ timings->hsw = hdmi_timings.hsw;
+ timings->vbp = hdmi_timings.vbp;
+ timings->vfp = hdmi_timings.vfp;
+ timings->vsw = hdmi_timings.vsw;
+}
+
static int get_timings_index(void)
{
int code;
@@ -617,7 +631,7 @@ static struct hdmi_cm hdmi_get_code(struct omap_video_timings *timing)
{
int i = 0, code = -1, temp_vsync = 0, temp_hsync = 0;
int timing_vsync = 0, timing_hsync = 0;
- struct omap_video_timings temp;
+ struct hdmi_video_timings temp;
struct hdmi_cm cm = {-1};
DSSDBG("hdmi_get_code\n");
@@ -775,7 +789,8 @@ static void hdmi_read_edid(struct omap_video_timings *dp)
code = get_timings_index();
- *dp = cea_vesa_timings[code].timings;
+ copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings, dp);
+
}
static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
@@ -1234,7 +1249,9 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi_read_edid(p);
}
code = get_timings_index();
- dssdev->panel.timings = cea_vesa_timings[code].timings;
+ copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings,
+ &dssdev->panel.timings);
+
update_hdmi_timings(&hdmi.cfg, p, code);
phy = p->pixel_clock;
diff --git a/drivers/video/omap2/dss/hdmi.h b/drivers/video/omap2/dss/hdmi.h
index f57ef4a..dcc30b7 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi.h
@@ -188,9 +188,22 @@ struct hdmi_reg { u16 idx; };
#define REG_GET(base, idx, start, end) \
FLD_GET(hdmi_read_reg(base, idx), start, end)
+struct hdmi_video_timings {
+ u16 x_res;
+ u16 y_res;
+ /* Unit: KHz */
+ u32 pixel_clock;
+ u16 hsw;
+ u16 hfp;
+ u16 hbp;
+ u16 vsw;
+ u16 vfp;
+ u16 vbp;
+};
+
/* HDMI timing structure */
struct hdmi_timings {
- struct omap_video_timings timings;
+ struct hdmi_video_timings timings;
int vsync_pol;
int hsync_pol;
};
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 4/8] OMAP4: DSS: HDMI: Move the common header file definition
2011-06-17 8:17 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
2011-06-17 8:17 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Mythri P K
2011-06-20 12:46 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Premi, Sanjeev
2011-06-23 8:30 ` Tomi Valkeinen
2 siblings, 1 reply; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
Some of the header file definitions of HDMI IP are needed by audio driver thus
moving the common defintion to more generic Include/video.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/omap2/dss/dss.h | 10 -----
drivers/video/omap2/dss/hdmi.c | 1 +
drivers/video/omap2/dss/hdmi.h | 51 -----------------------
include/video/hdmi_ti_4xxx_ip.h | 84 +++++++++++++++++++++++++++++++++++++++
4 files changed, 85 insertions(+), 61 deletions(-)
create mode 100644 include/video/hdmi_ti_4xxx_ip.h
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ce17a61..324e982 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -156,16 +156,6 @@ struct dsi_clock_info {
bool use_sys_clk;
};
-/* HDMI PLL structure */
-struct hdmi_pll_info {
- u16 regn;
- u16 regm;
- u32 regmf;
- u16 regm2;
- u16 regsd;
- u16 dcofreq;
-};
-
struct seq_file;
struct platform_device;
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c24d573..1f34f63 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,6 +33,7 @@
#include <linux/pm_runtime.h>
#include <linux/clk.h>
#include <video/omapdss.h>
+#include <video/hdmi_ti_4xxx_ip.h>
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
#include <sound/soc.h>
diff --git a/drivers/video/omap2/dss/hdmi.h b/drivers/video/omap2/dss/hdmi.h
index dcc30b7..4b0fab3 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi.h
@@ -188,39 +188,12 @@ struct hdmi_reg { u16 idx; };
#define REG_GET(base, idx, start, end) \
FLD_GET(hdmi_read_reg(base, idx), start, end)
-struct hdmi_video_timings {
- u16 x_res;
- u16 y_res;
- /* Unit: KHz */
- u32 pixel_clock;
- u16 hsw;
- u16 hfp;
- u16 hbp;
- u16 vsw;
- u16 vfp;
- u16 vbp;
-};
-
-/* HDMI timing structure */
-struct hdmi_timings {
- struct hdmi_video_timings timings;
- int vsync_pol;
- int hsync_pol;
-};
-
enum hdmi_phy_pwr {
HDMI_PHYPWRCMD_OFF = 0,
HDMI_PHYPWRCMD_LDOON = 1,
HDMI_PHYPWRCMD_TXON = 2
};
-enum hdmi_pll_pwr {
- HDMI_PLLPWRCMD_ALLOFF = 0,
- HDMI_PLLPWRCMD_PLLONLY = 1,
- HDMI_PLLPWRCMD_BOTHON_ALLCLKS = 2,
- HDMI_PLLPWRCMD_BOTHON_NOPHYCLK = 3
-};
-
enum hdmi_clk_refsel {
HDMI_REFSEL_PCLK = 0,
HDMI_REFSEL_REF1 = 1,
@@ -256,11 +229,6 @@ enum hdmi_core_packet_mode {
HDMI_PACKETMODE48BITPERPIXEL = 7
};
-enum hdmi_core_hdmi_dvi {
- HDMI_DVI = 0,
- HDMI_HDMI = 1
-};
-
enum hdmi_core_tclkselclkmult {
HDMI_FPLL05IDCK = 0,
HDMI_FPLL10IDCK = 1,
@@ -561,25 +529,6 @@ struct hdmi_video_interface {
int tm; /* Timing mode */
};
-struct hdmi_ip_data {
- void __iomem *base_wp; /* HDMI wrapper */
- unsigned long hdmi_core_sys_offset;
- unsigned long hdmi_core_av_offset;
- unsigned long hdmi_pll_offset;
- unsigned long hdmi_phy_offset;
-};
-
-struct hdmi_cm {
- int code;
- int mode;
-};
-
-struct hdmi_config {
- struct hdmi_timings timings;
- u16 interlace;
- struct hdmi_cm cm;
-};
-
struct hdmi_audio_format {
enum hdmi_stereo_channels stereo_channels;
u8 active_chnnls_msk;
diff --git a/include/video/hdmi_ti_4xxx_ip.h b/include/video/hdmi_ti_4xxx_ip.h
new file mode 100644
index 0000000..49640cd
--- /dev/null
+++ b/include/video/hdmi_ti_4xxx_ip.h
@@ -0,0 +1,84 @@
+/*
+ * hdmi_ti_4xxx_ip.h
+ *
+ * HDMI driver definition for TI OMAP4, TI81xx, TI38xx Processor.
+ *
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _HDMI_TI_4xxx_
+#define _HDMI_TI_4xxx_
+
+enum hdmi_pll_pwr {
+ HDMI_PLLPWRCMD_ALLOFF = 0,
+ HDMI_PLLPWRCMD_PLLONLY = 1,
+ HDMI_PLLPWRCMD_BOTHON_ALLCLKS = 2,
+ HDMI_PLLPWRCMD_BOTHON_NOPHYCLK = 3
+};
+
+enum hdmi_core_hdmi_dvi {
+ HDMI_DVI = 0,
+ HDMI_HDMI = 1
+};
+
+struct hdmi_ip_data {
+ void __iomem *base_wp; /* HDMI wrapper */
+ unsigned long hdmi_core_sys_offset;
+ unsigned long hdmi_core_av_offset;
+ unsigned long hdmi_pll_offset;
+ unsigned long hdmi_phy_offset;
+};
+
+struct hdmi_video_timings {
+ u16 x_res;
+ u16 y_res;
+ /* Unit: KHz */
+ u32 pixel_clock;
+ u16 hsw;
+ u16 hfp;
+ u16 hbp;
+ u16 vsw;
+ u16 vfp;
+ u16 vbp;
+};
+
+/* HDMI timing structure */
+struct hdmi_timings {
+ struct hdmi_video_timings timings;
+ int vsync_pol;
+ int hsync_pol;
+};
+
+struct hdmi_cm {
+ int code;
+ int mode;
+};
+
+struct hdmi_config {
+ struct hdmi_timings timings;
+ u16 interlace;
+ struct hdmi_cm cm;
+};
+
+/* HDMI PLL structure */
+struct hdmi_pll_info {
+ u16 regn;
+ u16 regm;
+ u32 regmf;
+ u16 regm2;
+ u16 regsd;
+ u16 dcofreq;
+};
+#endif
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP
2011-06-17 8:17 ` [PATCH 4/8] OMAP4: DSS: HDMI: Move the common header file definition Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
2011-06-17 8:17 ` [PATCH 6/8] OMAP4: DSS: HDMI: Rename the functions in HDMI IP Mythri P K
2011-06-20 13:48 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Premi, Sanjeev
0 siblings, 2 replies; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
Splitting HDMI IP dependent IP configuring code from HDMI DSS dependent code and
moving to a new IP file.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/omap2/dss/Makefile | 1 +
drivers/video/omap2/dss/hdmi.c | 751 -------------------
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 781 ++++++++++++++++++++
.../video/omap2/dss/{hdmi.h => hdmi_ti_4xxx_ip.h} | 9 +-
include/video/hdmi_ti_4xxx_ip.h | 10 +
5 files changed, 797 insertions(+), 755 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
rename drivers/video/omap2/dss/{hdmi.h => hdmi_ti_4xxx_ip.h} (99%)
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 10d9d3b..cf967e0 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -6,4 +6,5 @@ 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) += hdmi.o \
+ hdmi_ti_4xxx_ip.o \
hdmi_omap4_panel.o
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 1f34f63..1bd98d9 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -41,7 +41,6 @@
#endif
#include "dss.h"
-#include "hdmi.h"
#include "dss_features.h"
#define HDMI_WP 0x0
@@ -163,58 +162,6 @@ static const int code_vesa[85] = {
static const u8 edid_header[8] = {0x0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0};
-static inline void hdmi_write_reg(void __iomem *base_addr,
- const struct hdmi_reg idx, u32 val)
-{
- __raw_writel(val, base_addr + idx.idx);
-}
-
-static inline u32 hdmi_read_reg(void __iomem *base_addr,
- const struct hdmi_reg idx)
-{
- return __raw_readl(base_addr + idx.idx);
-}
-
-static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data *ip_data)
-{
- return (void __iomem *) (ip_data->base_wp);
-}
-
-static inline void __iomem *hdmi_phy_base(struct hdmi_ip_data *ip_data)
-{
- return (void __iomem *) (ip_data->base_wp + ip_data->hdmi_phy_offset);
-}
-
-static inline void __iomem *hdmi_pll_base(struct hdmi_ip_data *ip_data)
-{
- return (void __iomem *) (ip_data->base_wp + ip_data->hdmi_pll_offset);
-}
-
-static inline void __iomem *hdmi_av_base(struct hdmi_ip_data *ip_data)
-{
- return (void __iomem *)
- (ip_data->base_wp + ip_data->hdmi_core_av_offset);
-}
-
-static inline void __iomem *hdmi_core_sys_base(struct hdmi_ip_data *ip_data)
-{
- return (void __iomem *)
- (ip_data->base_wp + ip_data->hdmi_core_sys_offset);
-}
-
-static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
- const struct hdmi_reg idx,
- int b2, int b1, u32 val)
-{
- u32 t = 0;
- while (val != REG_GET(base_addr, idx, b2, b1)) {
- udelay(1);
- if (t++ > 10000)
- return !val;
- }
- return val;
-}
-
static int hdmi_runtime_get(void)
{
int r;
@@ -272,328 +219,6 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
- enum hdmi_clk_refsel refsel, int dcofreq,
- struct hdmi_pll_info *fmt, u16 sd)
-{
- u32 r;
-
- /* PLL start always use manual mode */
- REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
-
- r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
- r = FLD_MOD(r, fmt->regm, 20, 9); /* CFG1_PLL_REGM */
- r = FLD_MOD(r, fmt->regn, 8, 1); /* CFG1_PLL_REGN */
-
- hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
-
- r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2);
-
- r = FLD_MOD(r, 0x0, 12, 12); /* PLL_HIGHFREQ divide by 2 */
- r = FLD_MOD(r, 0x1, 13, 13); /* PLL_REFEN */
- r = FLD_MOD(r, 0x0, 14, 14); /* PHY_CLKINEN de-assert during locking */
-
- if (dcofreq) {
- /* divider programming for frequency beyond 1000Mhz */
- REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_CFG3, sd, 17, 10);
- r = FLD_MOD(r, 0x4, 3, 1); /* 1000MHz and 2000MHz */
- } else {
- r = FLD_MOD(r, 0x2, 3, 1); /* 500MHz and 1000MHz */
- }
-
- hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2, r);
-
- r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4);
- r = FLD_MOD(r, fmt->regm2, 24, 18);
- r = FLD_MOD(r, fmt->regmf, 17, 0);
-
- hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4, r);
-
- /* go now */
- REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_GO, 0x1, 0, 0);
-
- /* wait for bit change */
- if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data), PLLCTRL_PLL_GO,
- 0, 0, 1) != 1) {
- DSSERR("PLL GO bit not set\n");
- return -ETIMEDOUT;
- }
-
- /* Wait till the lock bit is set in PLL status */
- if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data),
- PLLCTRL_PLL_STATUS, 1, 1, 1) != 1) {
- DSSWARN("cannot lock PLL\n");
- DSSWARN("CFG1 0x%x\n",
- hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1));
- DSSWARN("CFG2 0x%x\n",
- hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2));
- DSSWARN("CFG4 0x%x\n",
- hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4));
- return -ETIMEDOUT;
- }
-
- DSSDBG("PLL locked!\n");
-
- return 0;
-}
-
-/* PHY_PWR_CMD */
-static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr val)
-{
- /* Command for power control of HDMI PHY */
- REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 7, 6);
-
- /* Status of the power control of HDMI PHY */
- if (hdmi_wait_for_bit_change(hdmi_wp_base(ip_data),
- HDMI_WP_PWR_CTRL, 5, 4, val) != val) {
- DSSERR("Failed to set PHY power mode to %d\n", val);
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-/* PLL_PWR_CMD */
-int hdmi_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val)
-{
- /* Command for power control of HDMI PLL */
- REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 3, 2);
-
- /* wait till PHY_PWR_STATUS is set */
- if (hdmi_wait_for_bit_change(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL,
- 1, 0, val) != val) {
- DSSERR("Failed to set PHY_PWR_STATUS\n");
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-static int hdmi_pll_reset(struct hdmi_ip_data *ip_data)
-{
- /* SYSRESET controlled by power FSM */
- REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_CONTROL, 0x0, 3, 3);
-
- /* READ 0x0 reset is in progress */
- if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data),
- PLLCTRL_PLL_STATUS, 0, 0, 1) != 1) {
- DSSERR("Failed to sysreset PLL\n");
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-static int hdmi_phy_init(struct hdmi_ip_data *ip_data)
-{
- u16 r = 0;
-
- r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
- if (r)
- return r;
-
- r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- if (r)
- return r;
-
- /*
- * Read address 0 in order to get the SCP reset done completed
- * Dummy access performed to make sure reset is done
- */
- hdmi_read_reg(hdmi_phy_base(ip_data), HDMI_TXPHY_TX_CTRL);
-
- /*
- * Write to phy address 0 to configure the clock
- * use HFBITCLK write HDMI_TXPHY_TX_CONTROL_FREQOUT field
- */
- REG_FLD_MOD(hdmi_phy_base(ip_data), HDMI_TXPHY_TX_CTRL, 0x1, 31, 30);
-
- /* Write to phy address 1 to start HDMI line (TXVALID and TMDSCLKEN) */
- hdmi_write_reg(hdmi_phy_base(ip_data),
- HDMI_TXPHY_DIGITAL_CTRL, 0xF0000000);
-
- /* Setup max LDO voltage */
- REG_FLD_MOD(hdmi_phy_base(ip_data), HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
-
- /* Write to phy address 3 to change the polarity control */
- REG_FLD_MOD(hdmi_phy_base(ip_data),
- HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
-
- return 0;
-}
-
-static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
- struct hdmi_pll_info *fmt)
-{
- u16 r = 0;
- enum hdmi_clk_refsel refsel;
-
- r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
- if (r)
- return r;
-
- r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_BOTHON_ALLCLKS);
- if (r)
- return r;
-
- r = hdmi_pll_reset(ip_data);
- if (r)
- return r;
-
- refsel = HDMI_REFSEL_SYSCLK;
-
- r = hdmi_pll_init(ip_data, refsel, fmt->dcofreq, fmt, fmt->regsd);
- if (r)
- return r;
-
- return 0;
-}
-
-static void hdmi_phy_off(struct hdmi_ip_data *ip_data)
-{
- hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
-}
-
-static int hdmi_core_ddc_edid(struct hdmi_ip_data *ip_data,
- u8 *pedid, int ext)
-{
- u32 i, j;
- char checksum = 0;
- u32 offset = 0;
-
- /* Turn on CLK for DDC */
- REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_DPD, 0x7, 2, 0);
-
- /*
- * SW HACK : Without the Delay DDC(i2c bus) reads 0 values /
- * right shifted values( The behavior is not consistent and seen only
- * with some TV's)
- */
- usleep_range(800, 1000);
-
- if (!ext) {
- /* Clk SCL Devices */
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_CMD, 0xA, 3, 0);
-
- /* HDMI_CORE_DDC_STATUS_IN_PROG */
- if (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_STATUS, 4, 4, 0) != 0) {
- DSSERR("Failed to program DDC\n");
- return -ETIMEDOUT;
- }
-
- /* Clear FIFO */
- REG_FLD_MOD(hdmi_core_sys_base(ip_data)
- , HDMI_CORE_DDC_CMD, 0x9, 3, 0);
-
- /* HDMI_CORE_DDC_STATUS_IN_PROG */
- if (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_STATUS, 4, 4, 0) != 0) {
- DSSERR("Failed to program DDC\n");
- return -ETIMEDOUT;
- }
-
- } else {
- if (ext % 2 != 0)
- offset = 0x80;
- }
-
- /* Load Segment Address Register */
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_SEGM, ext/2, 7, 0);
-
- /* Load Slave Address Register */
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_ADDR, 0xA0 >> 1, 7, 1);
-
- /* Load Offset Address Register */
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_OFFSET, offset, 7, 0);
-
- /* Load Byte Count */
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_COUNT1, 0x80, 7, 0);
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_COUNT2, 0x0, 1, 0);
-
- /* Set DDC_CMD */
- if (ext)
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_CMD, 0x4, 3, 0);
- else
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_CMD, 0x2, 3, 0);
-
- /* HDMI_CORE_DDC_STATUS_BUS_LOW */
- if (REG_GET(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_STATUS, 6, 6) == 1) {
- DSSWARN("I2C Bus Low?\n");
- return -EIO;
- }
- /* HDMI_CORE_DDC_STATUS_NO_ACK */
- if (REG_GET(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_STATUS, 5, 5) == 1) {
- DSSWARN("I2C No Ack\n");
- return -EIO;
- }
-
- i = ext * 128;
- j = 0;
- while (((REG_GET(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_STATUS, 4, 4) == 1) ||
- (REG_GET(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_STATUS, 2, 2) == 0)) && j < 128) {
-
- if (REG_GET(hdmi_core_sys_base(ip_data)
- , HDMI_CORE_DDC_STATUS, 2, 2) == 0) {
- /* FIFO not empty */
- pedid[i++] = REG_GET(hdmi_core_sys_base(ip_data),
- HDMI_CORE_DDC_DATA, 7, 0);
- j++;
- }
- }
-
- for (j = 0; j < 128; j++)
- checksum += pedid[j];
-
- if (checksum != 0) {
- DSSERR("E-EDID checksum failed!!\n");
- return -EIO;
- }
-
- return 0;
-}
-
-static int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
-{
- int r = 0, n = 0, i = 0;
- int max_ext_blocks = (max_length / 128) - 1;
-
- r = hdmi_core_ddc_edid(ip_data, pedid, 0);
- if (r) {
- return r;
- } else {
- n = pedid[0x7e];
-
- /*
- * README: need to comply with max_length set by the caller.
- * Better implementation should be to allocate necessary
- * memory to store EDID according to nb_block field found
- * in first block
- */
- if (n > max_ext_blocks)
- n = max_ext_blocks;
-
- for (i = 1; i <= n; i++) {
- r = hdmi_core_ddc_edid(ip_data, pedid, i);
- if (r)
- return r;
- }
- }
- return 0;
-}
-
static void copy_hdmi_to_dss_timings(struct hdmi_video_timings hdmi_timings,
struct omap_video_timings *timings)
{
@@ -794,382 +419,6 @@ static void hdmi_read_edid(struct omap_video_timings *dp)
}
-static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
- struct hdmi_core_infoframe_avi *avi_cfg,
- struct hdmi_core_packet_enable_repeat *repeat_cfg)
-{
- DSSDBG("Enter hdmi_core_init\n");
-
- /* video core */
- video_cfg->ip_bus_width = HDMI_INPUT_8BIT;
- video_cfg->op_dither_truc = HDMI_OUTPUTTRUNCATION_8BIT;
- video_cfg->deep_color_pkt = HDMI_DEEPCOLORPACKECTDISABLE;
- video_cfg->pkt_mode = HDMI_PACKETMODERESERVEDVALUE;
- video_cfg->hdmi_dvi = HDMI_DVI;
- video_cfg->tclk_sel_clkmult = HDMI_FPLL10IDCK;
-
- /* info frame */
- avi_cfg->db1_format = 0;
- avi_cfg->db1_active_info = 0;
- avi_cfg->db1_bar_info_dv = 0;
- avi_cfg->db1_scan_info = 0;
- avi_cfg->db2_colorimetry = 0;
- avi_cfg->db2_aspect_ratio = 0;
- avi_cfg->db2_active_fmt_ar = 0;
- avi_cfg->db3_itc = 0;
- avi_cfg->db3_ec = 0;
- avi_cfg->db3_q_range = 0;
- avi_cfg->db3_nup_scaling = 0;
- avi_cfg->db4_videocode = 0;
- avi_cfg->db5_pixel_repeat = 0;
- avi_cfg->db6_7_line_eoftop = 0 ;
- avi_cfg->db8_9_line_sofbottom = 0;
- avi_cfg->db10_11_pixel_eofleft = 0;
- avi_cfg->db12_13_pixel_sofright = 0;
-
- /* packet enable and repeat */
- repeat_cfg->audio_pkt = 0;
- repeat_cfg->audio_pkt_repeat = 0;
- repeat_cfg->avi_infoframe = 0;
- repeat_cfg->avi_infoframe_repeat = 0;
- repeat_cfg->gen_cntrl_pkt = 0;
- repeat_cfg->gen_cntrl_pkt_repeat = 0;
- repeat_cfg->generic_pkt = 0;
- repeat_cfg->generic_pkt_repeat = 0;
-}
-
-static void hdmi_core_powerdown_disable(struct hdmi_ip_data *ip_data)
-{
- DSSDBG("Enter hdmi_core_powerdown_disable\n");
- REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, 0x0, 0, 0);
-}
-
-static void hdmi_core_swreset_release(struct hdmi_ip_data *ip_data)
-{
- DSSDBG("Enter hdmi_core_swreset_release\n");
- REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SRST, 0x0, 0, 0);
-}
-
-static void hdmi_core_swreset_assert(struct hdmi_ip_data *ip_data)
-{
- DSSDBG("Enter hdmi_core_swreset_assert\n");
- REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SRST, 0x1, 0, 0);
-}
-
-/* HDMI_CORE_VIDEO_CONFIG */
-static void hdmi_core_video_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_video_config *cfg)
-{
- u32 r = 0;
-
- /* sys_ctrl1 default configuration not tunable */
- r = hdmi_read_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC, 5, 5);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC, 4, 4);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_BSEL_24BITBUS, 2, 2);
- r = FLD_MOD(r, HDMI_CORE_CTRL1_EDGE_RISINGEDGE, 1, 1);
- hdmi_write_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, r);
-
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_SYS_VID_ACEN, cfg->ip_bus_width, 7, 6);
-
- /* Vid_Mode */
- r = hdmi_read_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_VID_MODE);
-
- /* dither truncation configuration */
- if (cfg->op_dither_truc > HDMI_OUTPUTTRUNCATION_12BIT) {
- r = FLD_MOD(r, cfg->op_dither_truc - 3, 7, 6);
- r = FLD_MOD(r, 1, 5, 5);
- } else {
- r = FLD_MOD(r, cfg->op_dither_truc, 7, 6);
- r = FLD_MOD(r, 0, 5, 5);
- }
- hdmi_write_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_VID_MODE, r);
-
- /* HDMI_Ctrl */
- r = hdmi_read_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_HDMI_CTRL);
- r = FLD_MOD(r, cfg->deep_color_pkt, 6, 6);
- r = FLD_MOD(r, cfg->pkt_mode, 5, 3);
- r = FLD_MOD(r, cfg->hdmi_dvi, 0, 0);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_HDMI_CTRL, r);
-
- /* TMDS_CTRL */
- REG_FLD_MOD(hdmi_core_sys_base(ip_data),
- HDMI_CORE_SYS_TMDS_CTRL, cfg->tclk_sel_clkmult, 6, 5);
-}
-
-static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_infoframe_avi info_avi)
-{
- u32 val;
- char sum = 0, checksum = 0;
-
- sum += 0x82 + 0x002 + 0x00D;
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_TYPE, 0x082);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_VERS, 0x002);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_LEN, 0x00D);
-
- val = (info_avi.db1_format << 5) |
- (info_avi.db1_active_info << 4) |
- (info_avi.db1_bar_info_dv << 2) |
- (info_avi.db1_scan_info);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(0), val);
- sum += val;
-
- val = (info_avi.db2_colorimetry << 6) |
- (info_avi.db2_aspect_ratio << 4) |
- (info_avi.db2_active_fmt_ar);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(1), val);
- sum += val;
-
- val = (info_avi.db3_itc << 7) |
- (info_avi.db3_ec << 4) |
- (info_avi.db3_q_range << 2) |
- (info_avi.db3_nup_scaling);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(2), val);
- sum += val;
-
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(3),
- info_avi.db4_videocode);
- sum += info_avi.db4_videocode;
-
- val = info_avi.db5_pixel_repeat;
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(4), val);
- sum += val;
-
- val = info_avi.db6_7_line_eoftop & 0x00FF;
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(5), val);
- sum += val;
-
- val = ((info_avi.db6_7_line_eoftop >> 8) & 0x00FF);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(6), val);
- sum += val;
-
- val = info_avi.db8_9_line_sofbottom & 0x00FF;
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(7), val);
- sum += val;
-
- val = ((info_avi.db8_9_line_sofbottom >> 8) & 0x00FF);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(8), val);
- sum += val;
-
- val = info_avi.db10_11_pixel_eofleft & 0x00FF;
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(9), val);
- sum += val;
-
- val = ((info_avi.db10_11_pixel_eofleft >> 8) & 0x00FF);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(10), val);
- sum += val;
-
- val = info_avi.db12_13_pixel_sofright & 0x00FF;
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(11), val);
- sum += val;
-
- val = ((info_avi.db12_13_pixel_sofright >> 8) & 0x00FF);
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(12), val);
- sum += val;
-
- checksum = 0x100 - sum;
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_CHSUM, checksum);
-}
-
-static void hdmi_core_av_packet_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_packet_enable_repeat repeat_cfg)
-{
- /* enable/repeat the infoframe */
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_PB_CTRL1,
- (repeat_cfg.audio_pkt << 5) |
- (repeat_cfg.audio_pkt_repeat << 4) |
- (repeat_cfg.avi_infoframe << 1) |
- (repeat_cfg.avi_infoframe_repeat));
-
- /* enable/repeat the packet */
- hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_PB_CTRL2,
- (repeat_cfg.gen_cntrl_pkt << 3) |
- (repeat_cfg.gen_cntrl_pkt_repeat << 2) |
- (repeat_cfg.generic_pkt << 1) |
- (repeat_cfg.generic_pkt_repeat));
-}
-
-static void hdmi_wp_init(struct omap_video_timings *timings,
- struct hdmi_video_format *video_fmt,
- struct hdmi_video_interface *video_int)
-{
- DSSDBG("Enter hdmi_wp_init\n");
-
- timings->hbp = 0;
- timings->hfp = 0;
- timings->hsw = 0;
- timings->vbp = 0;
- timings->vfp = 0;
- timings->vsw = 0;
-
- video_fmt->packing_mode = HDMI_PACK_10b_RGB_YUV444;
- video_fmt->y_res = 0;
- video_fmt->x_res = 0;
-
- video_int->vsp = 0;
- video_int->hsp = 0;
-
- video_int->interlacing = 0;
- video_int->tm = 0; /* HDMI_TIMING_SLAVE */
-
-}
-
-static void hdmi_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
-{
- REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, start, 31, 31);
-}
-
-static void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
- struct omap_video_timings *timings, struct hdmi_config *param)
-{
- DSSDBG("Enter hdmi_wp_video_init_format\n");
-
- video_fmt->y_res = param->timings.timings.y_res;
- video_fmt->x_res = param->timings.timings.x_res;
-
- timings->hbp = param->timings.timings.hbp;
- timings->hfp = param->timings.timings.hfp;
- timings->hsw = param->timings.timings.hsw;
- timings->vbp = param->timings.timings.vbp;
- timings->vfp = param->timings.timings.vfp;
- timings->vsw = param->timings.timings.vsw;
-}
-
-static void hdmi_wp_video_config_format(struct hdmi_ip_data *ip_data,
- struct hdmi_video_format *video_fmt)
-{
- u32 l = 0;
-
- REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG,
- video_fmt->packing_mode, 10, 8);
-
- l |= FLD_VAL(video_fmt->y_res, 31, 16);
- l |= FLD_VAL(video_fmt->x_res, 15, 0);
- hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_SIZE, l);
-}
-
-static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data,
- struct hdmi_video_interface *video_int)
-{
- u32 r;
- DSSDBG("Enter hdmi_wp_video_config_interface\n");
-
- r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG);
- r = FLD_MOD(r, video_int->vsp, 7, 7);
- r = FLD_MOD(r, video_int->hsp, 6, 6);
- r = FLD_MOD(r, video_int->interlacing, 3, 3);
- r = FLD_MOD(r, video_int->tm, 1, 0);
- hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
-}
-
-static void hdmi_wp_video_config_timing(struct hdmi_ip_data *ip_data,
- struct omap_video_timings *timings)
-{
- u32 timing_h = 0;
- u32 timing_v = 0;
-
- DSSDBG("Enter hdmi_wp_video_config_timing\n");
-
- timing_h |= FLD_VAL(timings->hbp, 31, 20);
- timing_h |= FLD_VAL(timings->hfp, 19, 8);
- timing_h |= FLD_VAL(timings->hsw, 7, 0);
- hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_TIMING_H, timing_h);
-
- timing_v |= FLD_VAL(timings->vbp, 31, 20);
- timing_v |= FLD_VAL(timings->vfp, 19, 8);
- timing_v |= FLD_VAL(timings->vsw, 7, 0);
- hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_TIMING_V, timing_v);
-}
-
-static void hdmi_basic_configure(struct hdmi_ip_data *ip_data,
- struct hdmi_config *cfg)
-{
- /* HDMI */
- struct omap_video_timings video_timing;
- struct hdmi_video_format video_format;
- struct hdmi_video_interface video_interface;
- /* HDMI core */
- struct hdmi_core_infoframe_avi avi_cfg;
- struct hdmi_core_video_config v_core_cfg;
- struct hdmi_core_packet_enable_repeat repeat_cfg;
-
- hdmi_wp_init(&video_timing, &video_format,
- &video_interface);
-
- hdmi_core_init(&v_core_cfg,
- &avi_cfg,
- &repeat_cfg);
-
- hdmi_wp_video_init_format(&video_format,
- &video_timing, cfg);
-
- hdmi_wp_video_config_timing(ip_data, &video_timing);
-
- /* video config */
- video_format.packing_mode = HDMI_PACK_24b_RGB_YUV444_YUV422;
-
- hdmi_wp_video_config_format(ip_data, &video_format);
-
- video_interface.vsp = cfg->timings.vsync_pol;
- video_interface.hsp = cfg->timings.hsync_pol;
- video_interface.interlacing = cfg->interlace;
- video_interface.tm = 1 ; /* HDMI_TIMING_MASTER_24BIT */
-
- hdmi_wp_video_config_interface(ip_data, &video_interface);
-
- /*
- * configure core video part
- * set software reset in the core
- */
- hdmi_core_swreset_assert(ip_data);
-
- /* power down off */
- hdmi_core_powerdown_disable(ip_data);
-
- v_core_cfg.pkt_mode = HDMI_PACKETMODE24BITPERPIXEL;
- v_core_cfg.hdmi_dvi = cfg->cm.mode;
-
- hdmi_core_video_config(ip_data, &v_core_cfg);
-
- /* release software reset in the core */
- hdmi_core_swreset_release(ip_data);
-
- /*
- * configure packet
- * info frame video see doc CEA861-D page 65
- */
- avi_cfg.db1_format = HDMI_INFOFRAME_AVI_DB1Y_RGB;
- avi_cfg.db1_active_info =
- HDMI_INFOFRAME_AVI_DB1A_ACTIVE_FORMAT_OFF;
- avi_cfg.db1_bar_info_dv = HDMI_INFOFRAME_AVI_DB1B_NO;
- avi_cfg.db1_scan_info = HDMI_INFOFRAME_AVI_DB1S_0;
- avi_cfg.db2_colorimetry = HDMI_INFOFRAME_AVI_DB2C_NO;
- avi_cfg.db2_aspect_ratio = HDMI_INFOFRAME_AVI_DB2M_NO;
- avi_cfg.db2_active_fmt_ar = HDMI_INFOFRAME_AVI_DB2R_SAME;
- avi_cfg.db3_itc = HDMI_INFOFRAME_AVI_DB3ITC_NO;
- avi_cfg.db3_ec = HDMI_INFOFRAME_AVI_DB3EC_XVYUV601;
- avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_DEFAULT;
- avi_cfg.db3_nup_scaling = HDMI_INFOFRAME_AVI_DB3SC_NO;
- avi_cfg.db4_videocode = cfg->cm.code;
- avi_cfg.db5_pixel_repeat = HDMI_INFOFRAME_AVI_DB5PR_NO;
- avi_cfg.db6_7_line_eoftop = 0;
- avi_cfg.db8_9_line_sofbottom = 0;
- avi_cfg.db10_11_pixel_eofleft = 0;
- avi_cfg.db12_13_pixel_sofright = 0;
-
- hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
-
- /* enable/repeat the infoframe */
- repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
- repeat_cfg.avi_infoframe_repeat = HDMI_PACKETREPEATON;
- /* wakeup */
- repeat_cfg.audio_pkt = HDMI_PACKETENABLE;
- repeat_cfg.audio_pkt_repeat = HDMI_PACKETREPEATON;
- hdmi_core_av_packet_config(ip_data, repeat_cfg);
-}
-
static void update_hdmi_timings(struct hdmi_config *cfg,
struct omap_video_timings *timings, int code)
{
diff --git a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
new file mode 100644
index 0000000..b4e8875
--- /dev/null
+++ b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
@@ -0,0 +1,781 @@
+/*
+ * hdmi_ti_4xxx_ip.c
+ *
+ * HDMI TI81xx, TI38xx, TI OMAP4 etc IP driver Library
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Yong Zhi
+ * Mythri pk <mythripk@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+#include <linux/string.h>
+
+#include "hdmi_ti_4xxx_ip.h"
+#include "dss.h"
+
+static inline void hdmi_write_reg(void __iomem *base_addr,
+ const struct hdmi_reg idx, u32 val)
+{
+ __raw_writel(val, base_addr + idx.idx);
+}
+
+static inline u32 hdmi_read_reg(void __iomem *base_addr,
+ const struct hdmi_reg idx)
+{
+ return __raw_readl(base_addr + idx.idx);
+}
+
+static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *) (ip_data->base_wp);
+}
+
+static inline void __iomem *hdmi_phy_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *) (ip_data->base_wp + ip_data->hdmi_phy_offset);
+}
+
+static inline void __iomem *hdmi_pll_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *) (ip_data->base_wp + ip_data->hdmi_pll_offset);
+}
+
+static inline void __iomem *hdmi_av_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *)
+ (ip_data->base_wp + ip_data->hdmi_core_av_offset);
+}
+
+static inline void __iomem *hdmi_core_sys_base(struct hdmi_ip_data *ip_data)
+{
+ return (void __iomem *)
+ (ip_data->base_wp + ip_data->hdmi_core_sys_offset);
+}
+
+static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
+ const struct hdmi_reg idx,
+ int b2, int b1, u32 val)
+{
+ u32 t = 0;
+ while (val != REG_GET(base_addr, idx, b2, b1)) {
+ udelay(1);
+ if (t++ > 10000)
+ return !val;
+ }
+ return val;
+}
+
+static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
+ enum hdmi_clk_refsel refsel, int dcofreq,
+ struct hdmi_pll_info *fmt, u16 sd)
+{
+ u32 r;
+
+ /* PLL start always use manual mode */
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
+
+ r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
+ r = FLD_MOD(r, fmt->regm, 20, 9); /* CFG1_PLL_REGM */
+ r = FLD_MOD(r, fmt->regn, 8, 1); /* CFG1_PLL_REGN */
+
+ hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
+
+ r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2);
+
+ r = FLD_MOD(r, 0x0, 12, 12); /* PLL_HIGHFREQ divide by 2 */
+ r = FLD_MOD(r, 0x1, 13, 13); /* PLL_REFEN */
+ r = FLD_MOD(r, 0x0, 14, 14); /* PHY_CLKINEN de-assert during locking */
+
+ if (dcofreq) {
+ /* divider programming for frequency beyond 1000Mhz */
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_CFG3, sd, 17, 10);
+ r = FLD_MOD(r, 0x4, 3, 1); /* 1000MHz and 2000MHz */
+ } else {
+ r = FLD_MOD(r, 0x2, 3, 1); /* 500MHz and 1000MHz */
+ }
+
+ hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2, r);
+
+ r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4);
+ r = FLD_MOD(r, fmt->regm2, 24, 18);
+ r = FLD_MOD(r, fmt->regmf, 17, 0);
+
+ hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4, r);
+
+ /* go now */
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_GO, 0x1, 0, 0);
+
+ /* wait for bit change */
+ if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data), PLLCTRL_PLL_GO,
+ 0, 0, 1) != 1) {
+ pr_err("PLL GO bit not set\n");
+ return -ETIMEDOUT;
+ }
+
+ /* Wait till the lock bit is set in PLL status */
+ if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data),
+ PLLCTRL_PLL_STATUS, 1, 1, 1) != 1) {
+ pr_err("cannot lock PLL\n");
+ pr_err("CFG1 0x%x\n",
+ hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1));
+ pr_err("CFG2 0x%x\n",
+ hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG2));
+ pr_err("CFG4 0x%x\n",
+ hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG4));
+ return -ETIMEDOUT;
+ }
+
+ pr_debug("PLL locked!\n");
+
+ return 0;
+}
+
+/* PHY_PWR_CMD */
+static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr val)
+{
+ /* Command for power control of HDMI PHY */
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 7, 6);
+
+ /* Status of the power control of HDMI PHY */
+ if (hdmi_wait_for_bit_change(hdmi_wp_base(ip_data),
+ HDMI_WP_PWR_CTRL, 5, 4, val) != val) {
+ pr_err("Failed to set PHY power mode to %d\n", val);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+/* PLL_PWR_CMD */
+int hdmi_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val)
+{
+ /* Command for power control of HDMI PLL */
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 3, 2);
+
+ /* wait till PHY_PWR_STATUS is set */
+if (hdmi_wait_for_bit_change(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL,
+ 1, 0, val) != val) {
+ pr_err("Failed to set PLL_PWR_STATUS\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int hdmi_pll_reset(struct hdmi_ip_data *ip_data)
+{
+ /* SYSRESET controlled by power FSM */
+ REG_FLD_MOD(hdmi_pll_base(ip_data), PLLCTRL_PLL_CONTROL, 0x0, 3, 3);
+
+ /* READ 0x0 reset is in progress */
+ if (hdmi_wait_for_bit_change(hdmi_pll_base(ip_data),
+ PLLCTRL_PLL_STATUS, 0, 0, 1) != 1) {
+ pr_err("Failed to sysreset PLL\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+int hdmi_pll_program(struct hdmi_ip_data *ip_data,
+ struct hdmi_pll_info *fmt)
+{
+ u16 r = 0;
+ enum hdmi_clk_refsel refsel;
+
+ r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
+ if (r)
+ return r;
+
+ r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_BOTHON_ALLCLKS);
+ if (r)
+ return r;
+
+ r = hdmi_pll_reset(ip_data);
+ if (r)
+ return r;
+
+ refsel = HDMI_REFSEL_SYSCLK;
+
+ r = hdmi_pll_init(ip_data, refsel, fmt->dcofreq, fmt, fmt->regsd);
+ if (r)
+ return r;
+
+ return 0;
+}
+
+int hdmi_phy_init(struct hdmi_ip_data *ip_data)
+{
+ u16 r = 0;
+
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ if (r)
+ return r;
+
+ r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
+ if (r)
+ return r;
+
+ /*
+ * Read address 0 in order to get the SCP reset done completed
+ * Dummy access performed to make sure reset is done
+ */
+ hdmi_read_reg(hdmi_phy_base(ip_data), HDMI_TXPHY_TX_CTRL);
+
+ /*
+ * Write to phy address 0 to configure the clock
+ * use HFBITCLK write HDMI_TXPHY_TX_CONTROL_FREQOUT field
+ */
+ REG_FLD_MOD(hdmi_phy_base(ip_data), HDMI_TXPHY_TX_CTRL, 0x1, 31, 30);
+
+ /* Write to phy address 1 to start HDMI line (TXVALID and TMDSCLKEN) */
+ hdmi_write_reg(hdmi_phy_base(ip_data),
+ HDMI_TXPHY_DIGITAL_CTRL, 0xF0000000);
+
+ /* Setup max LDO voltage */
+ REG_FLD_MOD(hdmi_phy_base(ip_data), HDMI_TXPHY_POWER_CTRL, 0xB, 3, 0);
+
+ /* Write to phy address 3 to change the polarity control */
+ REG_FLD_MOD(hdmi_phy_base(ip_data),
+ HDMI_TXPHY_PAD_CFG_CTRL, 0x1, 27, 27);
+
+ return 0;
+}
+
+void hdmi_phy_off(struct hdmi_ip_data *ip_data)
+{
+ hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
+}
+
+static int hdmi_core_ddc_edid(struct hdmi_ip_data *ip_data,
+ u8 *pedid, int ext)
+{
+ u32 i, j;
+ char checksum = 0;
+ u32 offset = 0;
+
+ /* Turn on CLK for DDC */
+ REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_DPD, 0x7, 2, 0);
+
+ /*
+ * SW HACK : Without the Delay DDC(i2c bus) reads 0 values /
+ * right shifted values( The behavior is not consistent and seen only
+ * with some TV's)
+ */
+ usleep_range(800, 1000);
+
+ if (!ext) {
+ /* Clk SCL Devices */
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_CMD, 0xA, 3, 0);
+
+ /* HDMI_CORE_DDC_STATUS_IN_PROG */
+ if (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 4, 4, 0) != 0) {
+ pr_err("Failed to program DDC\n");
+ return -ETIMEDOUT;
+ }
+
+ /* Clear FIFO */
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data)
+ , HDMI_CORE_DDC_CMD, 0x9, 3, 0);
+
+ /* HDMI_CORE_DDC_STATUS_IN_PROG */
+ if (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 4, 4, 0) != 0) {
+ pr_err("Failed to program DDC\n");
+ return -ETIMEDOUT;
+ }
+
+ } else {
+ if (ext % 2 != 0)
+ offset = 0x80;
+ }
+
+ /* Load Segment Address Register */
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_SEGM, ext/2, 7, 0);
+
+ /* Load Slave Address Register */
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_ADDR, 0xA0 >> 1, 7, 1);
+
+ /* Load Offset Address Register */
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_OFFSET, offset, 7, 0);
+
+ /* Load Byte Count */
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_COUNT1, 0x80, 7, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_COUNT2, 0x0, 1, 0);
+
+ /* Set DDC_CMD */
+ if (ext)
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_CMD, 0x4, 3, 0);
+ else
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_CMD, 0x2, 3, 0);
+
+ /* HDMI_CORE_DDC_STATUS_BUS_LOW */
+ if (REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 6, 6) == 1) {
+ pr_err("I2C Bus Low?\n");
+ return -EIO;
+ }
+ /* HDMI_CORE_DDC_STATUS_NO_ACK */
+ if (REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 5, 5) == 1) {
+ pr_err("I2C No Ack\n");
+ return -EIO;
+ }
+
+ i = ext * 128;
+ j = 0;
+ while (((REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 4, 4) == 1) ||
+ (REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_STATUS, 2, 2) == 0)) && j < 128) {
+
+ if (REG_GET(hdmi_core_sys_base(ip_data)
+ , HDMI_CORE_DDC_STATUS, 2, 2) == 0) {
+ /* FIFO not empty */
+ pedid[i++] = REG_GET(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_DDC_DATA, 7, 0);
+ j++;
+ }
+ }
+
+ for (j = 0; j < 128; j++)
+ checksum += pedid[j];
+
+ if (checksum != 0) {
+ pr_err("E-EDID checksum failed!!\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
+{
+ int r = 0, n = 0, i = 0;
+ int max_ext_blocks = (max_length / 128) - 1;
+
+ r = hdmi_core_ddc_edid(ip_data, pedid, 0);
+ if (r) {
+ return r;
+ } else {
+ n = pedid[0x7e];
+
+ /*
+ * README: need to comply with max_length set by the caller.
+ * Better implementation should be to allocate necessary
+ * memory to store EDID according to nb_block field found
+ * in first block
+ */
+ if (n > max_ext_blocks)
+ n = max_ext_blocks;
+
+ for (i = 1; i <= n; i++) {
+ r = hdmi_core_ddc_edid(ip_data, pedid, i);
+ if (r)
+ return r;
+ }
+ }
+ return 0;
+}
+
+static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
+ struct hdmi_core_infoframe_avi *avi_cfg,
+ struct hdmi_core_packet_enable_repeat *repeat_cfg)
+{
+ pr_debug("Enter hdmi_core_init\n");
+
+ /* video core */
+ video_cfg->ip_bus_width = HDMI_INPUT_8BIT;
+ video_cfg->op_dither_truc = HDMI_OUTPUTTRUNCATION_8BIT;
+ video_cfg->deep_color_pkt = HDMI_DEEPCOLORPACKECTDISABLE;
+ video_cfg->pkt_mode = HDMI_PACKETMODERESERVEDVALUE;
+ video_cfg->hdmi_dvi = HDMI_DVI;
+ video_cfg->tclk_sel_clkmult = HDMI_FPLL10IDCK;
+
+ /* info frame */
+ avi_cfg->db1_format = 0;
+ avi_cfg->db1_active_info = 0;
+ avi_cfg->db1_bar_info_dv = 0;
+ avi_cfg->db1_scan_info = 0;
+ avi_cfg->db2_colorimetry = 0;
+ avi_cfg->db2_aspect_ratio = 0;
+ avi_cfg->db2_active_fmt_ar = 0;
+ avi_cfg->db3_itc = 0;
+ avi_cfg->db3_ec = 0;
+ avi_cfg->db3_q_range = 0;
+ avi_cfg->db3_nup_scaling = 0;
+ avi_cfg->db4_videocode = 0;
+ avi_cfg->db5_pixel_repeat = 0;
+ avi_cfg->db6_7_line_eoftop = 0 ;
+ avi_cfg->db8_9_line_sofbottom = 0;
+ avi_cfg->db10_11_pixel_eofleft = 0;
+ avi_cfg->db12_13_pixel_sofright = 0;
+
+ /* packet enable and repeat */
+ repeat_cfg->audio_pkt = 0;
+ repeat_cfg->audio_pkt_repeat = 0;
+ repeat_cfg->avi_infoframe = 0;
+ repeat_cfg->avi_infoframe_repeat = 0;
+ repeat_cfg->gen_cntrl_pkt = 0;
+ repeat_cfg->gen_cntrl_pkt_repeat = 0;
+ repeat_cfg->generic_pkt = 0;
+ repeat_cfg->generic_pkt_repeat = 0;
+}
+
+static void hdmi_core_powerdown_disable(struct hdmi_ip_data *ip_data)
+{
+ pr_debug("Enter hdmi_core_powerdown_disable\n");
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, 0x0, 0, 0);
+}
+
+static void hdmi_core_swreset_release(struct hdmi_ip_data *ip_data)
+{
+ pr_debug("Enter hdmi_core_swreset_release\n");
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SRST, 0x0, 0, 0);
+}
+
+static void hdmi_core_swreset_assert(struct hdmi_ip_data *ip_data)
+{
+ pr_debug("Enter hdmi_core_swreset_assert\n");
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_SRST, 0x1, 0, 0);
+}
+
+/* HDMI_CORE_VIDEO_CONFIG */
+static void hdmi_core_video_config(struct hdmi_ip_data *ip_data,
+ struct hdmi_core_video_config *cfg)
+{
+ u32 r = 0;
+
+ /* sys_ctrl1 default configuration not tunable */
+ r = hdmi_read_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1);
+ r = FLD_MOD(r, HDMI_CORE_CTRL1_VEN_FOLLOWVSYNC, 5, 5);
+ r = FLD_MOD(r, HDMI_CORE_CTRL1_HEN_FOLLOWHSYNC, 4, 4);
+ r = FLD_MOD(r, HDMI_CORE_CTRL1_BSEL_24BITBUS, 2, 2);
+ r = FLD_MOD(r, HDMI_CORE_CTRL1_EDGE_RISINGEDGE, 1, 1);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_CTRL1, r);
+
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN, cfg->ip_bus_width, 7, 6);
+
+ /* Vid_Mode */
+ r = hdmi_read_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_VID_MODE);
+
+ /* dither truncation configuration */
+ if (cfg->op_dither_truc > HDMI_OUTPUTTRUNCATION_12BIT) {
+ r = FLD_MOD(r, cfg->op_dither_truc - 3, 7, 6);
+ r = FLD_MOD(r, 1, 5, 5);
+ } else {
+ r = FLD_MOD(r, cfg->op_dither_truc, 7, 6);
+ r = FLD_MOD(r, 0, 5, 5);
+ }
+ hdmi_write_reg(hdmi_core_sys_base(ip_data), HDMI_CORE_SYS_VID_MODE, r);
+
+ /* HDMI_Ctrl */
+ r = hdmi_read_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_HDMI_CTRL);
+ r = FLD_MOD(r, cfg->deep_color_pkt, 6, 6);
+ r = FLD_MOD(r, cfg->pkt_mode, 5, 3);
+ r = FLD_MOD(r, cfg->hdmi_dvi, 0, 0);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_HDMI_CTRL, r);
+
+ /* TMDS_CTRL */
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_TMDS_CTRL, cfg->tclk_sel_clkmult, 6, 5);
+}
+
+static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data,
+ struct hdmi_core_infoframe_avi info_avi)
+{
+ u32 val;
+ char sum = 0, checksum = 0;
+
+ sum += 0x82 + 0x002 + 0x00D;
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_TYPE, 0x082);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_VERS, 0x002);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_LEN, 0x00D);
+
+ val = (info_avi.db1_format << 5) |
+ (info_avi.db1_active_info << 4) |
+ (info_avi.db1_bar_info_dv << 2) |
+ (info_avi.db1_scan_info);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(0), val);
+ sum += val;
+
+ val = (info_avi.db2_colorimetry << 6) |
+ (info_avi.db2_aspect_ratio << 4) |
+ (info_avi.db2_active_fmt_ar);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(1), val);
+ sum += val;
+
+ val = (info_avi.db3_itc << 7) |
+ (info_avi.db3_ec << 4) |
+ (info_avi.db3_q_range << 2) |
+ (info_avi.db3_nup_scaling);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(2), val);
+ sum += val;
+
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(3),
+ info_avi.db4_videocode);
+ sum += info_avi.db4_videocode;
+
+ val = info_avi.db5_pixel_repeat;
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(4), val);
+ sum += val;
+
+ val = info_avi.db6_7_line_eoftop & 0x00FF;
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(5), val);
+ sum += val;
+
+ val = ((info_avi.db6_7_line_eoftop >> 8) & 0x00FF);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(6), val);
+ sum += val;
+
+ val = info_avi.db8_9_line_sofbottom & 0x00FF;
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(7), val);
+ sum += val;
+
+ val = ((info_avi.db8_9_line_sofbottom >> 8) & 0x00FF);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(8), val);
+ sum += val;
+
+ val = info_avi.db10_11_pixel_eofleft & 0x00FF;
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(9), val);
+ sum += val;
+
+ val = ((info_avi.db10_11_pixel_eofleft >> 8) & 0x00FF);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(10), val);
+ sum += val;
+
+ val = info_avi.db12_13_pixel_sofright & 0x00FF;
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(11), val);
+ sum += val;
+
+ val = ((info_avi.db12_13_pixel_sofright >> 8) & 0x00FF);
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_DBYTE(12), val);
+ sum += val;
+
+ checksum = 0x100 - sum;
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_AVI_CHSUM, checksum);
+}
+
+static void hdmi_core_av_packet_config(struct hdmi_ip_data *ip_data,
+ struct hdmi_core_packet_enable_repeat repeat_cfg)
+{
+ /* enable/repeat the infoframe */
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_PB_CTRL1,
+ (repeat_cfg.audio_pkt << 5) |
+ (repeat_cfg.audio_pkt_repeat << 4) |
+ (repeat_cfg.avi_infoframe << 1) |
+ (repeat_cfg.avi_infoframe_repeat));
+
+ /* enable/repeat the packet */
+ hdmi_write_reg(hdmi_av_base(ip_data), HDMI_CORE_AV_PB_CTRL2,
+ (repeat_cfg.gen_cntrl_pkt << 3) |
+ (repeat_cfg.gen_cntrl_pkt_repeat << 2) |
+ (repeat_cfg.generic_pkt << 1) |
+ (repeat_cfg.generic_pkt_repeat));
+}
+
+static void hdmi_wp_init(struct omap_video_timings *timings,
+ struct hdmi_video_format *video_fmt,
+ struct hdmi_video_interface *video_int)
+{
+ pr_debug("Enter hdmi_wp_init\n");
+
+ timings->hbp = 0;
+ timings->hfp = 0;
+ timings->hsw = 0;
+ timings->vbp = 0;
+ timings->vfp = 0;
+ timings->vsw = 0;
+
+ video_fmt->packing_mode = HDMI_PACK_10b_RGB_YUV444;
+ video_fmt->y_res = 0;
+ video_fmt->x_res = 0;
+
+ video_int->vsp = 0;
+ video_int->hsp = 0;
+
+ video_int->interlacing = 0;
+ video_int->tm = 0; /* HDMI_TIMING_SLAVE */
+
+}
+
+void hdmi_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
+{
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, start, 31, 31);
+}
+
+static void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
+ struct omap_video_timings *timings, struct hdmi_config *param)
+{
+ pr_debug("Enter hdmi_wp_video_init_format\n");
+
+ video_fmt->y_res = param->timings.timings.y_res;
+ video_fmt->x_res = param->timings.timings.x_res;
+
+ timings->hbp = param->timings.timings.hbp;
+ timings->hfp = param->timings.timings.hfp;
+ timings->hsw = param->timings.timings.hsw;
+ timings->vbp = param->timings.timings.vbp;
+ timings->vfp = param->timings.timings.vfp;
+ timings->vsw = param->timings.timings.vsw;
+}
+
+static void hdmi_wp_video_config_format(struct hdmi_ip_data *ip_data,
+ struct hdmi_video_format *video_fmt)
+{
+ u32 l = 0;
+
+ REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG,
+ video_fmt->packing_mode, 10, 8);
+
+ l |= FLD_VAL(video_fmt->y_res, 31, 16);
+ l |= FLD_VAL(video_fmt->x_res, 15, 0);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_SIZE, l);
+}
+
+static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data,
+ struct hdmi_video_interface *video_int)
+{
+ u32 r;
+ pr_debug("Enter hdmi_wp_video_config_interface\n");
+
+ r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG);
+ r = FLD_MOD(r, video_int->vsp, 7, 7);
+ r = FLD_MOD(r, video_int->hsp, 6, 6);
+ r = FLD_MOD(r, video_int->interlacing, 3, 3);
+ r = FLD_MOD(r, video_int->tm, 1, 0);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
+}
+
+static void hdmi_wp_video_config_timing(struct hdmi_ip_data *ip_data,
+ struct omap_video_timings *timings)
+{
+ u32 timing_h = 0;
+ u32 timing_v = 0;
+
+ pr_debug("Enter hdmi_wp_video_config_timing\n");
+
+ timing_h |= FLD_VAL(timings->hbp, 31, 20);
+ timing_h |= FLD_VAL(timings->hfp, 19, 8);
+ timing_h |= FLD_VAL(timings->hsw, 7, 0);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_TIMING_H, timing_h);
+
+ timing_v |= FLD_VAL(timings->vbp, 31, 20);
+ timing_v |= FLD_VAL(timings->vfp, 19, 8);
+ timing_v |= FLD_VAL(timings->vsw, 7, 0);
+ hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_TIMING_V, timing_v);
+}
+
+void hdmi_basic_configure(struct hdmi_ip_data *ip_data,
+ struct hdmi_config *cfg)
+{
+ /* HDMI */
+ struct omap_video_timings video_timing;
+ struct hdmi_video_format video_format;
+ struct hdmi_video_interface video_interface;
+ /* HDMI core */
+ struct hdmi_core_infoframe_avi avi_cfg;
+ struct hdmi_core_video_config v_core_cfg;
+ struct hdmi_core_packet_enable_repeat repeat_cfg;
+
+ hdmi_wp_init(&video_timing, &video_format,
+ &video_interface);
+
+ hdmi_core_init(&v_core_cfg,
+ &avi_cfg,
+ &repeat_cfg);
+
+ hdmi_wp_video_init_format(&video_format, &video_timing, cfg);
+
+ hdmi_wp_video_config_timing(ip_data, &video_timing);
+
+ /* video config */
+ video_format.packing_mode = HDMI_PACK_24b_RGB_YUV444_YUV422;
+
+ hdmi_wp_video_config_format(ip_data, &video_format);
+
+ video_interface.vsp = cfg->timings.vsync_pol;
+ video_interface.hsp = cfg->timings.hsync_pol;
+ video_interface.interlacing = cfg->interlace;
+ video_interface.tm = 1 ; /* HDMI_TIMING_MASTER_24BIT */
+
+ hdmi_wp_video_config_interface(ip_data, &video_interface);
+
+ /*
+ * configure core video part
+ * set software reset in the core
+ */
+ hdmi_core_swreset_assert(ip_data);
+
+ /* power down off */
+ hdmi_core_powerdown_disable(ip_data);
+
+ v_core_cfg.pkt_mode = HDMI_PACKETMODE24BITPERPIXEL;
+ v_core_cfg.hdmi_dvi = cfg->cm.mode;
+
+ hdmi_core_video_config(ip_data, &v_core_cfg);
+
+ /* release software reset in the core */
+ hdmi_core_swreset_release(ip_data);
+
+ /*
+ * configure packet
+ * info frame video see doc CEA861-D page 65
+ */
+ avi_cfg.db1_format = HDMI_INFOFRAME_AVI_DB1Y_RGB;
+ avi_cfg.db1_active_info =
+ HDMI_INFOFRAME_AVI_DB1A_ACTIVE_FORMAT_OFF;
+ avi_cfg.db1_bar_info_dv = HDMI_INFOFRAME_AVI_DB1B_NO;
+ avi_cfg.db1_scan_info = HDMI_INFOFRAME_AVI_DB1S_0;
+ avi_cfg.db2_colorimetry = HDMI_INFOFRAME_AVI_DB2C_NO;
+ avi_cfg.db2_aspect_ratio = HDMI_INFOFRAME_AVI_DB2M_NO;
+ avi_cfg.db2_active_fmt_ar = HDMI_INFOFRAME_AVI_DB2R_SAME;
+ avi_cfg.db3_itc = HDMI_INFOFRAME_AVI_DB3ITC_NO;
+ avi_cfg.db3_ec = HDMI_INFOFRAME_AVI_DB3EC_XVYUV601;
+ avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_DEFAULT;
+ avi_cfg.db3_nup_scaling = HDMI_INFOFRAME_AVI_DB3SC_NO;
+ avi_cfg.db4_videocode = cfg->cm.code;
+ avi_cfg.db5_pixel_repeat = HDMI_INFOFRAME_AVI_DB5PR_NO;
+ avi_cfg.db6_7_line_eoftop = 0;
+ avi_cfg.db8_9_line_sofbottom = 0;
+ avi_cfg.db10_11_pixel_eofleft = 0;
+ avi_cfg.db12_13_pixel_sofright = 0;
+
+ hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
+
+ /* enable/repeat the infoframe */
+ repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
+ repeat_cfg.avi_infoframe_repeat = HDMI_PACKETREPEATON;
+ /* wakeup */
+ repeat_cfg.audio_pkt = HDMI_PACKETENABLE;
+ repeat_cfg.audio_pkt_repeat = HDMI_PACKETREPEATON;
+ hdmi_core_av_packet_config(ip_data, repeat_cfg);
+}
diff --git a/drivers/video/omap2/dss/hdmi.h b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h
similarity index 99%
rename from drivers/video/omap2/dss/hdmi.h
rename to drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h
index 4b0fab3..97e573c 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h
@@ -1,7 +1,7 @@
/*
- * hdmi.h
+ * hdmi_ti_4xxx_ip.h
*
- * HDMI driver definition for TI OMAP4 processors.
+ * HDMI header definition for TI81xx, TI38xx, TI OMAP4 etc processors.
*
* Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/
*
@@ -18,11 +18,12 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#ifndef _OMAP4_DSS_HDMI_H_
-#define _OMAP4_DSS_HDMI_H_
+#ifndef _HDMI_TI_4xxx_H_
+#define _HDMI_TI_4xxx_H_
#include <linux/string.h>
#include <video/omapdss.h>
+#include <video/hdmi_ti_4xxx_ip.h>
struct hdmi_reg { u16 idx; };
diff --git a/include/video/hdmi_ti_4xxx_ip.h b/include/video/hdmi_ti_4xxx_ip.h
index 49640cd..3355f40 100644
--- a/include/video/hdmi_ti_4xxx_ip.h
+++ b/include/video/hdmi_ti_4xxx_ip.h
@@ -81,4 +81,14 @@ struct hdmi_pll_info {
u16 regsd;
u16 dcofreq;
};
+
+int hdmi_phy_init(struct hdmi_ip_data *ip_data);
+void hdmi_phy_off(struct hdmi_ip_data *ip_data);
+int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length);
+void hdmi_wp_video_start(struct hdmi_ip_data *ip_data, bool start);
+int hdmi_pll_program(struct hdmi_ip_data *ip_data,
+ struct hdmi_pll_info *fmt);
+int hdmi_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val);
+void hdmi_basic_configure(struct hdmi_ip_data *ip_data,
+ struct hdmi_config *cfg);
#endif
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 6/8] OMAP4: DSS: HDMI: Rename the functions in HDMI IP
2011-06-17 8:17 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
2011-06-17 8:17 ` [PATCH 7/8] HDMI: Move HDMI IP Library from OMAP DSS to common Mythri P K
2011-06-20 13:48 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Premi, Sanjeev
1 sibling, 1 reply; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
Functions that are included in the generic video include of HDMI TI OMAP4, TI8xx
etc IP library is renamed to have IP specific names so that it will not conflict
with similar function from other IP.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/omap2/dss/hdmi.c | 18 +++++++++---------
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 18 +++++++++---------
include/video/hdmi_ti_4xxx_ip.h | 14 +++++++-------
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 1bd98d9..d42bb5d 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -395,7 +395,7 @@ static void hdmi_read_edid(struct omap_video_timings *dp)
memset(hdmi.edid, 0, HDMI_EDID_MAX_LENGTH);
if (!hdmi.edid_set)
- ret = read_edid(&hdmi.hdmi_data, hdmi.edid,
+ ret = read_ti_4xxx_edid(&hdmi.hdmi_data, hdmi.edid,
HDMI_EDID_MAX_LENGTH);
if (!ret) {
if (!memcmp(hdmi.edid, edid_header, sizeof(edid_header))) {
@@ -508,16 +508,16 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi_compute_pll(dssdev, phy, &pll_data);
- hdmi_wp_video_start(&hdmi.hdmi_data, 0);
+ hdmi_ti_4xxx_wp_video_start(&hdmi.hdmi_data, 0);
/* config the PLL and PHY hdmi_set_pll_pwrfirst */
- r = hdmi_pll_program(&hdmi.hdmi_data, &pll_data);
+ r = hdmi_ti_4xxx_pll_program(&hdmi.hdmi_data, &pll_data);
if (r) {
DSSDBG("Failed to lock PLL\n");
goto err;
}
- r = hdmi_phy_init(&hdmi.hdmi_data);
+ r = hdmi_ti_4xxx_phy_init(&hdmi.hdmi_data);
if (r) {
DSSDBG("Failed to start PHY\n");
goto err;
@@ -525,7 +525,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi.cfg.cm.mode = hdmi.mode;
hdmi.cfg.cm.code = hdmi.code;
- hdmi_basic_configure(&hdmi.hdmi_data, &hdmi.cfg);
+ hdmi_ti_4xxx_basic_configure(&hdmi.hdmi_data, &hdmi.cfg);
/* Make selection of HDMI in DSS */
dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
@@ -547,7 +547,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dispc_enable_channel(OMAP_DSS_CHANNEL_DIGIT, 1);
- hdmi_wp_video_start(&hdmi.hdmi_data, 1);
+ hdmi_ti_4xxx_wp_video_start(&hdmi.hdmi_data, 1);
return 0;
err:
@@ -559,9 +559,9 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
{
dispc_enable_channel(OMAP_DSS_CHANNEL_DIGIT, 0);
- hdmi_wp_video_start(&hdmi.hdmi_data, 0);
- hdmi_phy_off(&hdmi.hdmi_data);
- hdmi_set_pll_pwr(&hdmi.hdmi_data, HDMI_PLLPWRCMD_ALLOFF);
+ hdmi_ti_4xxx_wp_video_start(&hdmi.hdmi_data, 0);
+ hdmi_ti_4xxx_phy_off(&hdmi.hdmi_data);
+ hdmi_ti_4xxx_set_pll_pwr(&hdmi.hdmi_data, HDMI_PLLPWRCMD_ALLOFF);
hdmi_runtime_put();
hdmi.edid_set = 0;
diff --git a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
index b4e8875..51dc2a8 100644
--- a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
+++ b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
@@ -165,7 +165,7 @@ static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr val)
}
/* PLL_PWR_CMD */
-int hdmi_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val)
+int hdmi_ti_4xxx_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val)
{
/* Command for power control of HDMI PLL */
REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 3, 2);
@@ -195,17 +195,17 @@ static int hdmi_pll_reset(struct hdmi_ip_data *ip_data)
return 0;
}
-int hdmi_pll_program(struct hdmi_ip_data *ip_data,
+int hdmi_ti_4xxx_pll_program(struct hdmi_ip_data *ip_data,
struct hdmi_pll_info *fmt)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
- r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
+ r = hdmi_ti_4xxx_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
if (r)
return r;
- r = hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_BOTHON_ALLCLKS);
+ r = hdmi_ti_4xxx_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_BOTHON_ALLCLKS);
if (r)
return r;
@@ -222,7 +222,7 @@ int hdmi_pll_program(struct hdmi_ip_data *ip_data,
return 0;
}
-int hdmi_phy_init(struct hdmi_ip_data *ip_data)
+int hdmi_ti_4xxx_phy_init(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
@@ -260,7 +260,7 @@ int hdmi_phy_init(struct hdmi_ip_data *ip_data)
return 0;
}
-void hdmi_phy_off(struct hdmi_ip_data *ip_data)
+void hdmi_ti_4xxx_phy_off(struct hdmi_ip_data *ip_data)
{
hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
}
@@ -376,7 +376,7 @@ static int hdmi_core_ddc_edid(struct hdmi_ip_data *ip_data,
return 0;
}
-int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
+int read_ti_4xxx_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
{
int r = 0, n = 0, i = 0;
int max_ext_blocks = (max_length / 128) - 1;
@@ -627,7 +627,7 @@ static void hdmi_wp_init(struct omap_video_timings *timings,
}
-void hdmi_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
+void hdmi_ti_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
{
REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, start, 31, 31);
}
@@ -694,7 +694,7 @@ static void hdmi_wp_video_config_timing(struct hdmi_ip_data *ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_TIMING_V, timing_v);
}
-void hdmi_basic_configure(struct hdmi_ip_data *ip_data,
+void hdmi_ti_4xxx_basic_configure(struct hdmi_ip_data *ip_data,
struct hdmi_config *cfg)
{
/* HDMI */
diff --git a/include/video/hdmi_ti_4xxx_ip.h b/include/video/hdmi_ti_4xxx_ip.h
index 3355f40..d354280 100644
--- a/include/video/hdmi_ti_4xxx_ip.h
+++ b/include/video/hdmi_ti_4xxx_ip.h
@@ -82,13 +82,13 @@ struct hdmi_pll_info {
u16 dcofreq;
};
-int hdmi_phy_init(struct hdmi_ip_data *ip_data);
-void hdmi_phy_off(struct hdmi_ip_data *ip_data);
-int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length);
-void hdmi_wp_video_start(struct hdmi_ip_data *ip_data, bool start);
-int hdmi_pll_program(struct hdmi_ip_data *ip_data,
+int hdmi_ti_4xxx_phy_init(struct hdmi_ip_data *ip_data);
+void hdmi_ti_4xxx_phy_off(struct hdmi_ip_data *ip_data);
+int read_ti_4xxx_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length);
+void hdmi_ti_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start);
+int hdmi_ti_4xxx_pll_program(struct hdmi_ip_data *ip_data,
struct hdmi_pll_info *fmt);
-int hdmi_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val);
-void hdmi_basic_configure(struct hdmi_ip_data *ip_data,
+int hdmi_ti_4xxx_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val);
+void hdmi_ti_4xxx_basic_configure(struct hdmi_ip_data *ip_data,
struct hdmi_config *cfg);
#endif
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 7/8] HDMI: Move HDMI IP Library from OMAP DSS to common
2011-06-17 8:17 ` [PATCH 6/8] OMAP4: DSS: HDMI: Rename the functions in HDMI IP Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
2011-06-17 8:17 ` [PATCH 8/8] OMAP4: DSS: Rename hdmi_omap4_panel.c to hdmi_panel.c Mythri P K
0 siblings, 1 reply; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
Moving support of HDMI IP library from OMAP4 DSS directory to Video directory as
HDMI IP present in both TI OMAP4, TI81xx, TI38xx Processor,Thus the library in
DSS can be reused in TI81xx, TI38xx processors.
Although both these processors have different Display subsytem HDMI IP remains
the same , thus to promote the reuse of code across SoC's, IP library named
hdmi_4xxx_ip.c is moved from DSS to video directory.Also functions are renamed
as the module has to export and the function name would be global symbol table,
hence renaming to function name specific to the library module.
With this approach Independent of their(OMAP/TI81xx/TI38xx) respective DSS, generic IP
configurations will be done using this library.
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/Kconfig | 7 ++++++
drivers/video/Makefile | 1 +
drivers/video/{omap2/dss => }/hdmi_ti_4xxx_ip.c | 24 ++++++++++++++++++++++-
drivers/video/{omap2/dss => }/hdmi_ti_4xxx_ip.h | 5 ++++
drivers/video/omap2/dss/Kconfig | 1 +
drivers/video/omap2/dss/Makefile | 1 -
6 files changed, 37 insertions(+), 2 deletions(-)
rename drivers/video/{omap2/dss => }/hdmi_ti_4xxx_ip.c (97%)
rename drivers/video/{omap2/dss => }/hdmi_ti_4xxx_ip.h (98%)
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e6a8d8c..2204fef 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2341,6 +2341,13 @@ config FB_PUV3_UNIGFX
Choose this option if you want to use the Unigfx device as a
framebuffer device. Without the support of PCI & AGP.
+config HDMI_TI_4XXX_IP
+ tristate
+ default n
+ help
+ HDMI Library Interface , for TI OMAP4/Netra IP.
+ See http://www.hdmi.org/ for HDMI specification.
+
source "drivers/video/omap/Kconfig"
source "drivers/video/omap2/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 2ea44b6..3118055 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -133,6 +133,7 @@ obj-$(CONFIG_FB_SH_MOBILE_HDMI) += sh_mobile_hdmi.o
obj-$(CONFIG_FB_SH_MOBILE_LCDC) += sh_mobile_lcdcfb.o
obj-$(CONFIG_FB_OMAP) += omap/
obj-y += omap2/
+obj-$(CONFIG_HDMI_TI_4XXX_IP) += hdmi_ti_4xxx_ip.o
obj-$(CONFIG_XEN_FBDEV_FRONTEND) += xen-fbfront.o
obj-$(CONFIG_FB_CARMINE) += carminefb.o
obj-$(CONFIG_FB_MB862XX) += mb862xx/
diff --git a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c b/drivers/video/hdmi_ti_4xxx_ip.c
similarity index 97%
rename from drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
rename to drivers/video/hdmi_ti_4xxx_ip.c
index 51dc2a8..c8ea145 100644
--- a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
+++ b/drivers/video/hdmi_ti_4xxx_ip.c
@@ -29,7 +29,6 @@
#include <linux/string.h>
#include "hdmi_ti_4xxx_ip.h"
-#include "dss.h"
static inline void hdmi_write_reg(void __iomem *base_addr,
const struct hdmi_reg idx, u32 val)
@@ -179,6 +178,7 @@ if (hdmi_wait_for_bit_change(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL,
return 0;
}
+EXPORT_SYMBOL(hdmi_ti_4xxx_set_pll_pwr);
static int hdmi_pll_reset(struct hdmi_ip_data *ip_data)
{
@@ -264,6 +264,8 @@ void hdmi_ti_4xxx_phy_off(struct hdmi_ip_data *ip_data)
{
hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
}
+EXPORT_SYMBOL(hdmi_ti_4xxx_phy_init);
+EXPORT_SYMBOL(hdmi_ti_4xxx_phy_off);
static int hdmi_core_ddc_edid(struct hdmi_ip_data *ip_data,
u8 *pedid, int ext)
@@ -404,6 +406,7 @@ int read_ti_4xxx_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
}
return 0;
}
+EXPORT_SYMBOL(read_ti_4xxx_edid);
static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
struct hdmi_core_infoframe_avi *avi_cfg,
@@ -631,6 +634,7 @@ void hdmi_ti_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
{
REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, start, 31, 31);
}
+EXPORT_SYMBOL(hdmi_ti_4xxx_wp_video_start);
static void hdmi_wp_video_init_format(struct hdmi_video_format *video_fmt,
struct omap_video_timings *timings, struct hdmi_config *param)
@@ -779,3 +783,21 @@ void hdmi_ti_4xxx_basic_configure(struct hdmi_ip_data *ip_data,
repeat_cfg.audio_pkt_repeat = HDMI_PACKETREPEATON;
hdmi_core_av_packet_config(ip_data, repeat_cfg);
}
+EXPORT_SYMBOL(hdmi_ti_4xxx_basic_configure);
+
+static int __init hdmi_ti_4xxx_init(void)
+{
+ return 0;
+}
+
+static void __exit hdmi_ti_4xxx_exit(void)
+{
+
+}
+
+module_init(hdmi_ti_4xxx_init);
+module_exit(hdmi_ti_4xxx_exit);
+
+MODULE_AUTHOR("Texas Instruments");
+MODULE_DESCRIPTION("hdmi_ti_4xxx_ip module");
+MODULE_LICENSE("GPL");
diff --git a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h b/drivers/video/hdmi_ti_4xxx_ip.h
similarity index 98%
rename from drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h
rename to drivers/video/hdmi_ti_4xxx_ip.h
index 97e573c..b0b8c92 100644
--- a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h
+++ b/drivers/video/hdmi_ti_4xxx_ip.h
@@ -183,6 +183,11 @@ struct hdmi_reg { u16 idx; };
#define HDMI_TXPHY_POWER_CTRL HDMI_REG(0x8)
#define HDMI_TXPHY_PAD_CFG_CTRL HDMI_REG(0xC)
+#define FLD_MASK(start, end) (((1 << ((start) - (end) + 1)) - 1) << (end))
+#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
+#define FLD_GET(val, start, end) (((val) & FLD_MASK(start, end)) >> (end))
+#define FLD_MOD(orig, val, start, end) \
+ (((orig) & ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
#define REG_FLD_MOD(base, idx, val, start, end) \
hdmi_write_reg(base, idx, FLD_MOD(hdmi_read_reg(base, idx),\
val, start, end))
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 0d12524..8f9420e 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -63,6 +63,7 @@ config OMAP2_DSS_VENC
config OMAP4_DSS_HDMI
bool "HDMI support"
depends on ARCH_OMAP4
+ select HDMI_TI_4XXX_IP
default y
help
HDMI Interface. This adds the High Definition Multimedia Interface.
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index cf967e0..10d9d3b 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -6,5 +6,4 @@ 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) += hdmi.o \
- hdmi_ti_4xxx_ip.o \
hdmi_omap4_panel.o
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH 8/8] OMAP4: DSS: Rename hdmi_omap4_panel.c to hdmi_panel.c
2011-06-17 8:17 ` [PATCH 7/8] HDMI: Move HDMI IP Library from OMAP DSS to common Mythri P K
@ 2011-06-17 8:17 ` Mythri P K
0 siblings, 0 replies; 34+ messages in thread
From: Mythri P K @ 2011-06-17 8:17 UTC (permalink / raw)
To: linux-omap, tomi.valkeinen; +Cc: Mythri P K
As the panel driver will remain generic across OMAP's renaming it to
hdmi_panel.c
Signed-off-by: Mythri P K <mythripk@ti.com>
---
drivers/video/omap2/dss/Makefile | 2 +-
.../omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
rename drivers/video/omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} (99%)
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 10d9d3b..37d537c 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -6,4 +6,4 @@ 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) += hdmi.o \
- hdmi_omap4_panel.o
+ hdmi_panel.o
diff --git a/drivers/video/omap2/dss/hdmi_omap4_panel.c b/drivers/video/omap2/dss/hdmi_panel.c
similarity index 99%
rename from drivers/video/omap2/dss/hdmi_omap4_panel.c
rename to drivers/video/omap2/dss/hdmi_panel.c
index 7d4f2bd..e30182f 100644
--- a/drivers/video/omap2/dss/hdmi_omap4_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -1,5 +1,5 @@
/*
- * hdmi_omap4_panel.c
+ * hdmi_panel.c
*
* HDMI library support functions for TI OMAP4 processors.
*
--
1.7.5.4
^ permalink raw reply related [flat|nested] 34+ messages in thread
* RE: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure
2011-06-17 8:17 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Mythri P K
2011-06-17 8:17 ` [PATCH 4/8] OMAP4: DSS: HDMI: Move the common header file definition Mythri P K
@ 2011-06-20 12:46 ` Premi, Sanjeev
2011-06-23 5:45 ` K, Mythri P
2011-06-23 8:30 ` Tomi Valkeinen
2 siblings, 1 reply; 34+ messages in thread
From: Premi, Sanjeev @ 2011-06-20 12:46 UTC (permalink / raw)
To: K, Mythri P, linux-omap, Valkeinen, Tomi
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Friday, June 17, 2011 1:47 PM
> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Cc: K, Mythri P
> Subject: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI
> timings structure
>
> Define new HDMI timings structure to replace the OMAP DSS
> timing strucutre in hdmi.c
[sp] Fix spelling of structure.
> to have the HDMI include defintion out of DSS.
>
> Signed-off-by: Mythri P K <mythripk@ti.com>
> ---
> drivers/video/omap2/dss/hdmi.c | 23 ++++++++++++++++++++---
> drivers/video/omap2/dss/hdmi.h | 15 ++++++++++++++-
> 2 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/hdmi.c
> b/drivers/video/omap2/dss/hdmi.c
> index 4ee879a..c24d573 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -593,6 +593,20 @@ static int read_edid(struct hdmi_ip_data
> *ip_data, u8 *pedid, u16 max_length)
> return 0;
> }
>
> +static void copy_hdmi_to_dss_timings(struct
> hdmi_video_timings hdmi_timings,
> + struct omap_video_timings *timings)
[sp] Assuming that we really need 2 separate structures, suggest
renaming function to "copy_hdmi_timings_to_dss" or
"copy_timings_hdmi_to_dss" for better readability.
> +{
> + timings->x_res = hdmi_timings.x_res;
> + timings->y_res = hdmi_timings.y_res;
> + timings->pixel_clock = hdmi_timings.pixel_clock;
> + timings->hbp = hdmi_timings.hbp;
> + timings->hfp = hdmi_timings.hfp;
> + timings->hsw = hdmi_timings.hsw;
> + timings->vbp = hdmi_timings.vbp;
> + timings->vfp = hdmi_timings.vfp;
> + timings->vsw = hdmi_timings.vsw;
> +}
> +
> static int get_timings_index(void)
> {
> int code;
> @@ -617,7 +631,7 @@ static struct hdmi_cm
> hdmi_get_code(struct omap_video_timings *timing)
> {
> int i = 0, code = -1, temp_vsync = 0, temp_hsync = 0;
> int timing_vsync = 0, timing_hsync = 0;
> - struct omap_video_timings temp;
> + struct hdmi_video_timings temp;
> struct hdmi_cm cm = {-1};
> DSSDBG("hdmi_get_code\n");
>
> @@ -775,7 +789,8 @@ static void hdmi_read_edid(struct
> omap_video_timings *dp)
>
> code = get_timings_index();
>
> - *dp = cea_vesa_timings[code].timings;
> + copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings, dp);
> +
> }
>
> static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
> @@ -1234,7 +1249,9 @@ static int hdmi_power_on(struct
> omap_dss_device *dssdev)
> hdmi_read_edid(p);
> }
> code = get_timings_index();
> - dssdev->panel.timings = cea_vesa_timings[code].timings;
> + copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings,
> + &dssdev->panel.timings);
> +
> update_hdmi_timings(&hdmi.cfg, p, code);
>
> phy = p->pixel_clock;
> diff --git a/drivers/video/omap2/dss/hdmi.h
> b/drivers/video/omap2/dss/hdmi.h
> index f57ef4a..dcc30b7 100644
> --- a/drivers/video/omap2/dss/hdmi.h
> +++ b/drivers/video/omap2/dss/hdmi.h
> @@ -188,9 +188,22 @@ struct hdmi_reg { u16 idx; };
> #define REG_GET(base, idx, start, end) \
> FLD_GET(hdmi_read_reg(base, idx), start, end)
>
> +struct hdmi_video_timings {
> + u16 x_res;
> + u16 y_res;
> + /* Unit: KHz */
> + u32 pixel_clock;
[sp] Could be:
u32 pixel_clock; /* unit: KHz */
> + u16 hsw;
> + u16 hfp;
> + u16 hbp;
> + u16 vsw;
> + u16 vfp;
> + u16 vbp;
> +};
> +
> /* HDMI timing structure */
> struct hdmi_timings {
> - struct omap_video_timings timings;
> + struct hdmi_video_timings timings;
> int vsync_pol;
> int hsync_pol;
> };
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
2011-06-17 8:17 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Mythri P K
2011-06-17 8:17 ` [PATCH 2/8] OMAP4 : DSS : HDMI : Move the EDID portion from HDMI IP Mythri P K
@ 2011-06-20 13:33 ` Premi, Sanjeev
2011-06-23 5:51 ` K, Mythri P
1 sibling, 1 reply; 34+ messages in thread
From: Premi, Sanjeev @ 2011-06-20 13:33 UTC (permalink / raw)
To: K, Mythri P, linux-omap, Valkeinen, Tomi
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Friday, June 17, 2011 1:47 PM
> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Cc: K, Mythri P
> Subject: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass
> base_address
[sp] HDMI appears twice on the subject. One of these can be removed.
Also, it isn't clear (though implied) whose base address is being
passed.
The changes in the patch aren't limited to DSS alone.
See updated to hdmi_core_audio_config(), hdmi_wp_audio_config_format(),
hdmi_wp_audio_config_dma(), etc.
>
> As the base_address of the HDMI might differ across SoC's,
[sp] Is 'base_address' a variable? OR did you mean 'base address'?
> offset of the HDMI
> logical blocks and base address got from the platform data are passed
> dynamically to the functions that modify HDMI IP registers.
[sp] Overall, the sentence can be simplified.
>
> Signed-off-by: Mythri P K <mythripk@ti.com>
> ---
> drivers/video/omap2/dss/hdmi.c | 518
> ++++++++++++++++++++++++----------------
> drivers/video/omap2/dss/hdmi.h | 292 +++++++++++------------
> 2 files changed, 452 insertions(+), 358 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/hdmi.c
> b/drivers/video/omap2/dss/hdmi.c
> index 5e5b98b..1d16ee2 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -43,11 +43,17 @@
> #include "hdmi.h"
> #include "dss_features.h"
>
> +#define HDMI_WP 0x0
> +#define HDMI_CORE_SYS 0x400
> +#define HDMI_CORE_AV 0x900
> +#define HDMI_PLLCTRL 0x200
> +#define HDMI_PHY 0x300
> +
> static struct {
> struct mutex lock;
> struct omap_display_platform_data *pdata;
> struct platform_device *pdev;
> - void __iomem *base_wp; /* HDMI wrapper */
> + struct hdmi_ip_data hdmi_data;
> int code;
> int mode;
> u8 edid[HDMI_EDID_MAX_LENGTH];
> @@ -146,21 +152,51 @@ static const int code_vesa[85] = {
>
> static const u8 edid_header[8] = {0x0, 0xff, 0xff, 0xff,
> 0xff, 0xff, 0xff, 0x0};
>
> -static inline void hdmi_write_reg(const struct hdmi_reg idx, u32 val)
> +static inline void hdmi_write_reg(void __iomem *base_addr,
> + const struct hdmi_reg idx, u32 val)
> +{
> + __raw_writel(val, base_addr + idx.idx);
> +}
> +
> +static inline u32 hdmi_read_reg(void __iomem *base_addr,
> + const struct hdmi_reg idx)
> +{
> + return __raw_readl(base_addr + idx.idx);
> +}
> +
> +static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data
> *ip_data)
> +{
> + return (void __iomem *) (ip_data->base_wp);
> +}
> +
> +static inline void __iomem *hdmi_phy_base(struct
> hdmi_ip_data *ip_data)
> {
> - __raw_writel(val, hdmi.base_wp + idx.idx);
> + return (void __iomem *) (ip_data->base_wp +
> ip_data->hdmi_phy_offset);
> }
>
> -static inline u32 hdmi_read_reg(const struct hdmi_reg idx)
> +static inline void __iomem *hdmi_pll_base(struct
> hdmi_ip_data *ip_data)
> {
> - return __raw_readl(hdmi.base_wp + idx.idx);
> + return (void __iomem *) (ip_data->base_wp +
> ip_data->hdmi_pll_offset);
> }
>
> -static inline int hdmi_wait_for_bit_change(const struct hdmi_reg idx,
> +static inline void __iomem *hdmi_av_base(struct hdmi_ip_data
> *ip_data)
> +{
> + return (void __iomem *)
> + (ip_data->base_wp +
> ip_data->hdmi_core_av_offset);
> +}
> +
> +static inline void __iomem *hdmi_core_sys_base(struct
> hdmi_ip_data *ip_data)
> +{
> + return (void __iomem *)
> + (ip_data->base_wp +
> ip_data->hdmi_core_sys_offset);
> +}
> +
> +static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
> + const struct hdmi_reg idx,
> int b2, int b1, u32 val)
> {
> u32 t = 0;
> - while (val != REG_GET(idx, b2, b1)) {
> + while (val != REG_GET(base_addr, idx, b2, b1)) {
> udelay(1);
> if (t++ > 10000)
> return !val;
> @@ -225,21 +261,22 @@ int hdmi_init_display(struct
> omap_dss_device *dssdev)
> return 0;
> }
>
> -static int hdmi_pll_init(enum hdmi_clk_refsel refsel, int dcofreq,
> +static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
> + enum hdmi_clk_refsel refsel, int dcofreq,
> struct hdmi_pll_info *fmt, u16 sd)
> {
> u32 r;
>
> /* PLL start always use manual mode */
> - REG_FLD_MOD(PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
> + REG_FLD_MOD(hdmi_pll_base(ip_data),
> PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
>
> - r = hdmi_read_reg(PLLCTRL_CFG1);
> + r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
> r = FLD_MOD(r, fmt->regm, 20, 9); /* CFG1_PLL_REGM */
> r = FLD_MOD(r, fmt->regn, 8, 1); /* CFG1_PLL_REGN */
>
> - hdmi_write_reg(PLLCTRL_CFG1, r);
> + hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
[sp] hdmi_pll_base(ip_data) is used at many places withing this
function. Have you checked if saving the result in a local
variable generates any better code than repetitive ADD operation
in the function.
Same comment applies to similar use in other functions
modified in this patch.
[snip]...[snip]
> -static int hdmi_core_ddc_edid(u8 *pedid, int ext)
> +static int hdmi_core_ddc_edid(struct hdmi_ip_data *ip_data,
> + u8 *pedid, int ext)
> {
> u32 i, j;
> char checksum = 0;
> u32 offset = 0;
>
> /* Turn on CLK for DDC */
> - REG_FLD_MOD(HDMI_CORE_AV_DPD, 0x7, 2, 0);
> + REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_DPD, 0x7, 2, 0);
>
> /*
> * SW HACK : Without the Delay DDC(i2c bus) reads 0 values /
> @@ -416,21 +462,23 @@ static int hdmi_core_ddc_edid(u8
> *pedid, int ext)
>
> if (!ext) {
> /* Clk SCL Devices */
> - REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0xA, 3, 0);
> + REG_FLD_MOD(hdmi_core_sys_base(ip_data),
> +
> HDMI_CORE_DDC_CMD, 0xA, 3, 0);
>
> /* HDMI_CORE_DDC_STATUS_IN_PROG */
> - if (hdmi_wait_for_bit_change(HDMI_CORE_DDC_STATUS,
> - 4, 4, 0) != 0) {
> + if
> (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
> + HDMI_CORE_DDC_STATUS,
> 4, 4, 0) != 0) {
> DSSERR("Failed to program DDC\n");
> return -ETIMEDOUT;
> }
>
> /* Clear FIFO */
> - REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x9, 3, 0);
> + REG_FLD_MOD(hdmi_core_sys_base(ip_data)
> + ,
> HDMI_CORE_DDC_CMD, 0x9, 3, 0);
[sp] Misplaced "," at beginning of the line.
[snip]...[snip]
> static void update_hdmi_timings(struct hdmi_config *cfg,
> @@ -1166,16 +1231,16 @@ static int hdmi_power_on(struct
> omap_dss_device *dssdev)
>
> hdmi_compute_pll(dssdev, phy, &pll_data);
>
> - hdmi_wp_video_start(0);
> + hdmi_wp_video_start(&hdmi.hdmi_data, 0);
>
> - /* config the PLL and PHY first */
> - r = hdmi_pll_program(&pll_data);
> + /* config the PLL and PHY hdmi_set_pll_pwrfirst */
[sp] Is the change in comment intended?
[snip]...[snip]
~sanjeev
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP
2011-06-17 8:17 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Mythri P K
2011-06-17 8:17 ` [PATCH 6/8] OMAP4: DSS: HDMI: Rename the functions in HDMI IP Mythri P K
@ 2011-06-20 13:48 ` Premi, Sanjeev
2011-06-23 5:55 ` K, Mythri P
1 sibling, 1 reply; 34+ messages in thread
From: Premi, Sanjeev @ 2011-06-20 13:48 UTC (permalink / raw)
To: K, Mythri P, linux-omap, Valkeinen, Tomi
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of K, Mythri P
> Sent: Friday, June 17, 2011 1:47 PM
> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Cc: K, Mythri P
> Subject: [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver
> to DSS and IP
>
> Splitting HDMI IP dependent IP configuring code from HDMI DSS
> dependent code and
> moving to a new IP file.
>
> Signed-off-by: Mythri P K <mythripk@ti.com>
> ---
> drivers/video/omap2/dss/Makefile | 1 +
> drivers/video/omap2/dss/hdmi.c | 751
> -------------------
> drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 781
> ++++++++++++++++++++
> .../video/omap2/dss/{hdmi.h => hdmi_ti_4xxx_ip.h} | 9 +-
> include/video/hdmi_ti_4xxx_ip.h | 10 +
[sp] Is it okay to have 2 files by same name in two dirs?
'include/video' and 'drivers/.../omap2/dss'.
Compiler won't complain, but my comments is more from readability.
There has to be something characteristically different in these
headers - maybe this should reflect in the names as well.
~sanjeev
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure
2011-06-20 12:46 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Premi, Sanjeev
@ 2011-06-23 5:45 ` K, Mythri P
0 siblings, 0 replies; 34+ messages in thread
From: K, Mythri P @ 2011-06-23 5:45 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap, Valkeinen, Tomi
Hi Sanjeev,
On Mon, Jun 20, 2011 at 6:16 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of K, Mythri P
>> Sent: Friday, June 17, 2011 1:47 PM
>> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
>> Cc: K, Mythri P
>> Subject: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI
>> timings structure
>>
>> Define new HDMI timings structure to replace the OMAP DSS
>> timing strucutre in hdmi.c
>
> [sp] Fix spelling of structure.
>
Thanks will fix it.
>> to have the HDMI include defintion out of DSS.
>>
>> Signed-off-by: Mythri P K <mythripk@ti.com>
>> ---
>> drivers/video/omap2/dss/hdmi.c | 23 ++++++++++++++++++++---
>> drivers/video/omap2/dss/hdmi.h | 15 ++++++++++++++-
>> 2 files changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/hdmi.c
>> b/drivers/video/omap2/dss/hdmi.c
>> index 4ee879a..c24d573 100644
>> --- a/drivers/video/omap2/dss/hdmi.c
>> +++ b/drivers/video/omap2/dss/hdmi.c
>> @@ -593,6 +593,20 @@ static int read_edid(struct hdmi_ip_data
>> *ip_data, u8 *pedid, u16 max_length)
>> return 0;
>> }
>>
>> +static void copy_hdmi_to_dss_timings(struct
>> hdmi_video_timings hdmi_timings,
>> + struct omap_video_timings *timings)
>
> [sp] Assuming that we really need 2 separate structures, suggest
> renaming function to "copy_hdmi_timings_to_dss" or
> "copy_timings_hdmi_to_dss" for better readability.
>
I shall rename.
>> +{
>> + timings->x_res = hdmi_timings.x_res;
>> + timings->y_res = hdmi_timings.y_res;
>> + timings->pixel_clock = hdmi_timings.pixel_clock;
>> + timings->hbp = hdmi_timings.hbp;
>> + timings->hfp = hdmi_timings.hfp;
>> + timings->hsw = hdmi_timings.hsw;
>> + timings->vbp = hdmi_timings.vbp;
>> + timings->vfp = hdmi_timings.vfp;
>> + timings->vsw = hdmi_timings.vsw;
>> +}
>> +
>> static int get_timings_index(void)
>> {
>> int code;
>> @@ -617,7 +631,7 @@ static struct hdmi_cm
>> hdmi_get_code(struct omap_video_timings *timing)
>> {
>> int i = 0, code = -1, temp_vsync = 0, temp_hsync = 0;
>> int timing_vsync = 0, timing_hsync = 0;
>> - struct omap_video_timings temp;
>> + struct hdmi_video_timings temp;
>> struct hdmi_cm cm = {-1};
>> DSSDBG("hdmi_get_code\n");
>>
>> @@ -775,7 +789,8 @@ static void hdmi_read_edid(struct
>> omap_video_timings *dp)
>>
>> code = get_timings_index();
>>
>> - *dp = cea_vesa_timings[code].timings;
>> + copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings, dp);
>> +
>> }
>>
>> static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
>> @@ -1234,7 +1249,9 @@ static int hdmi_power_on(struct
>> omap_dss_device *dssdev)
>> hdmi_read_edid(p);
>> }
>> code = get_timings_index();
>> - dssdev->panel.timings = cea_vesa_timings[code].timings;
>> + copy_hdmi_to_dss_timings(cea_vesa_timings[code].timings,
>> + &dssdev->panel.timings);
>> +
>> update_hdmi_timings(&hdmi.cfg, p, code);
>>
>> phy = p->pixel_clock;
>> diff --git a/drivers/video/omap2/dss/hdmi.h
>> b/drivers/video/omap2/dss/hdmi.h
>> index f57ef4a..dcc30b7 100644
>> --- a/drivers/video/omap2/dss/hdmi.h
>> +++ b/drivers/video/omap2/dss/hdmi.h
>> @@ -188,9 +188,22 @@ struct hdmi_reg { u16 idx; };
>> #define REG_GET(base, idx, start, end) \
>> FLD_GET(hdmi_read_reg(base, idx), start, end)
>>
>> +struct hdmi_video_timings {
>> + u16 x_res;
>> + u16 y_res;
>> + /* Unit: KHz */
>> + u32 pixel_clock;
>
> [sp] Could be:
> u32 pixel_clock; /* unit: KHz */
>
>> + u16 hsw;
>> + u16 hfp;
>> + u16 hbp;
>> + u16 vsw;
>> + u16 vfp;
>> + u16 vbp;
>> +};
>> +
>> /* HDMI timing structure */
>> struct hdmi_timings {
>> - struct omap_video_timings timings;
>> + struct hdmi_video_timings timings;
>> int vsync_pol;
>> int hsync_pol;
>> };
>> --
>> 1.7.5.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
2011-06-20 13:33 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Premi, Sanjeev
@ 2011-06-23 5:51 ` K, Mythri P
2011-06-23 10:30 ` Premi, Sanjeev
0 siblings, 1 reply; 34+ messages in thread
From: K, Mythri P @ 2011-06-23 5:51 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap, Valkeinen, Tomi
Hi Sanjeev,
On Mon, Jun 20, 2011 at 7:03 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of K, Mythri P
>> Sent: Friday, June 17, 2011 1:47 PM
>> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
>> Cc: K, Mythri P
>> Subject: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass
>> base_address
>
> [sp] HDMI appears twice on the subject. One of these can be removed.
> Also, it isn't clear (though implied) whose base address is being
> passed.
>
> The changes in the patch aren't limited to DSS alone.
> See updated to hdmi_core_audio_config(), hdmi_wp_audio_config_format(),
> hdmi_wp_audio_config_dma(), etc.
>
The changes are related to the HDMI driver which as of this patch is
in DSS. You see any concerns ? It is only later that those functions
are moved out .
>>
>> As the base_address of the HDMI might differ across SoC's,
>
> [sp] Is 'base_address' a variable? OR did you mean 'base address'?
>
>> offset of the HDMI
>> logical blocks and base address got from the platform data are passed
>> dynamically to the functions that modify HDMI IP registers.
>
> [sp] Overall, the sentence can be simplified.
>
>>
>> Signed-off-by: Mythri P K <mythripk@ti.com>
>> ---
>> drivers/video/omap2/dss/hdmi.c | 518
>> ++++++++++++++++++++++++----------------
>> drivers/video/omap2/dss/hdmi.h | 292 +++++++++++------------
>> 2 files changed, 452 insertions(+), 358 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/hdmi.c
>> b/drivers/video/omap2/dss/hdmi.c
>> index 5e5b98b..1d16ee2 100644
>> --- a/drivers/video/omap2/dss/hdmi.c
>> +++ b/drivers/video/omap2/dss/hdmi.c
>> @@ -43,11 +43,17 @@
>> #include "hdmi.h"
>> #include "dss_features.h"
>>
>> +#define HDMI_WP 0x0
>> +#define HDMI_CORE_SYS 0x400
>> +#define HDMI_CORE_AV 0x900
>> +#define HDMI_PLLCTRL 0x200
>> +#define HDMI_PHY 0x300
>> +
>> static struct {
>> struct mutex lock;
>> struct omap_display_platform_data *pdata;
>> struct platform_device *pdev;
>> - void __iomem *base_wp; /* HDMI wrapper */
>> + struct hdmi_ip_data hdmi_data;
>> int code;
>> int mode;
>> u8 edid[HDMI_EDID_MAX_LENGTH];
>> @@ -146,21 +152,51 @@ static const int code_vesa[85] = {
>>
>> static const u8 edid_header[8] = {0x0, 0xff, 0xff, 0xff,
>> 0xff, 0xff, 0xff, 0x0};
>>
>> -static inline void hdmi_write_reg(const struct hdmi_reg idx, u32 val)
>> +static inline void hdmi_write_reg(void __iomem *base_addr,
>> + const struct hdmi_reg idx, u32 val)
>> +{
>> + __raw_writel(val, base_addr + idx.idx);
>> +}
>> +
>> +static inline u32 hdmi_read_reg(void __iomem *base_addr,
>> + const struct hdmi_reg idx)
>> +{
>> + return __raw_readl(base_addr + idx.idx);
>> +}
>> +
>> +static inline void __iomem *hdmi_wp_base(struct hdmi_ip_data
>> *ip_data)
>> +{
>> + return (void __iomem *) (ip_data->base_wp);
>> +}
>> +
>> +static inline void __iomem *hdmi_phy_base(struct
>> hdmi_ip_data *ip_data)
>> {
>> - __raw_writel(val, hdmi.base_wp + idx.idx);
>> + return (void __iomem *) (ip_data->base_wp +
>> ip_data->hdmi_phy_offset);
>> }
>>
>> -static inline u32 hdmi_read_reg(const struct hdmi_reg idx)
>> +static inline void __iomem *hdmi_pll_base(struct
>> hdmi_ip_data *ip_data)
>> {
>> - return __raw_readl(hdmi.base_wp + idx.idx);
>> + return (void __iomem *) (ip_data->base_wp +
>> ip_data->hdmi_pll_offset);
>> }
>>
>> -static inline int hdmi_wait_for_bit_change(const struct hdmi_reg idx,
>> +static inline void __iomem *hdmi_av_base(struct hdmi_ip_data
>> *ip_data)
>> +{
>> + return (void __iomem *)
>> + (ip_data->base_wp +
>> ip_data->hdmi_core_av_offset);
>> +}
>> +
>> +static inline void __iomem *hdmi_core_sys_base(struct
>> hdmi_ip_data *ip_data)
>> +{
>> + return (void __iomem *)
>> + (ip_data->base_wp +
>> ip_data->hdmi_core_sys_offset);
>> +}
>> +
>> +static inline int hdmi_wait_for_bit_change(void __iomem *base_addr,
>> + const struct hdmi_reg idx,
>> int b2, int b1, u32 val)
>> {
>> u32 t = 0;
>> - while (val != REG_GET(idx, b2, b1)) {
>> + while (val != REG_GET(base_addr, idx, b2, b1)) {
>> udelay(1);
>> if (t++ > 10000)
>> return !val;
>> @@ -225,21 +261,22 @@ int hdmi_init_display(struct
>> omap_dss_device *dssdev)
>> return 0;
>> }
>>
>> -static int hdmi_pll_init(enum hdmi_clk_refsel refsel, int dcofreq,
>> +static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
>> + enum hdmi_clk_refsel refsel, int dcofreq,
>> struct hdmi_pll_info *fmt, u16 sd)
>> {
>> u32 r;
>>
>> /* PLL start always use manual mode */
>> - REG_FLD_MOD(PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
>> + REG_FLD_MOD(hdmi_pll_base(ip_data),
>> PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
>>
>> - r = hdmi_read_reg(PLLCTRL_CFG1);
>> + r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
>> r = FLD_MOD(r, fmt->regm, 20, 9); /* CFG1_PLL_REGM */
>> r = FLD_MOD(r, fmt->regn, 8, 1); /* CFG1_PLL_REGN */
>>
>> - hdmi_write_reg(PLLCTRL_CFG1, r);
>> + hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
>
> [sp] hdmi_pll_base(ip_data) is used at many places withing this
> function. Have you checked if saving the result in a local
> variable generates any better code than repetitive ADD operation
> in the function.
>
> Same comment applies to similar use in other functions
> modified in this patch.
>
I had this comment from Tomi as well , Yes in some places it makes
sense to have a local variable to save , but then in certain functions
where there are four writes with 3 different base address it doesn't
make sense to add 3 variables.
> [snip]...[snip]
>
>> -static int hdmi_core_ddc_edid(u8 *pedid, int ext)
>> +static int hdmi_core_ddc_edid(struct hdmi_ip_data *ip_data,
>> + u8 *pedid, int ext)
>> {
>> u32 i, j;
>> char checksum = 0;
>> u32 offset = 0;
>>
>> /* Turn on CLK for DDC */
>> - REG_FLD_MOD(HDMI_CORE_AV_DPD, 0x7, 2, 0);
>> + REG_FLD_MOD(hdmi_av_base(ip_data), HDMI_CORE_AV_DPD, 0x7, 2, 0);
>>
>> /*
>> * SW HACK : Without the Delay DDC(i2c bus) reads 0 values /
>> @@ -416,21 +462,23 @@ static int hdmi_core_ddc_edid(u8
>> *pedid, int ext)
>>
>> if (!ext) {
>> /* Clk SCL Devices */
>> - REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0xA, 3, 0);
>> + REG_FLD_MOD(hdmi_core_sys_base(ip_data),
>> +
>> HDMI_CORE_DDC_CMD, 0xA, 3, 0);
>>
>> /* HDMI_CORE_DDC_STATUS_IN_PROG */
>> - if (hdmi_wait_for_bit_change(HDMI_CORE_DDC_STATUS,
>> - 4, 4, 0) != 0) {
>> + if
>> (hdmi_wait_for_bit_change(hdmi_core_sys_base(ip_data),
>> + HDMI_CORE_DDC_STATUS,
>> 4, 4, 0) != 0) {
>> DSSERR("Failed to program DDC\n");
>> return -ETIMEDOUT;
>> }
>>
>> /* Clear FIFO */
>> - REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x9, 3, 0);
>> + REG_FLD_MOD(hdmi_core_sys_base(ip_data)
>> + ,
>> HDMI_CORE_DDC_CMD, 0x9, 3, 0);
>
> [sp] Misplaced "," at beginning of the line.
>
Not a part of the patch i suppose?
> [snip]...[snip]
>
>> static void update_hdmi_timings(struct hdmi_config *cfg,
>> @@ -1166,16 +1231,16 @@ static int hdmi_power_on(struct
>> omap_dss_device *dssdev)
>>
>> hdmi_compute_pll(dssdev, phy, &pll_data);
>>
>> - hdmi_wp_video_start(0);
>> + hdmi_wp_video_start(&hdmi.hdmi_data, 0);
>>
>> - /* config the PLL and PHY first */
>> - r = hdmi_pll_program(&pll_data);
>> + /* config the PLL and PHY hdmi_set_pll_pwrfirst */
>
> [sp] Is the change in comment intended?
I shall remove this as it is unrelated to the patch
>
> [snip]...[snip]
>
> ~sanjeev
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP
2011-06-20 13:48 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Premi, Sanjeev
@ 2011-06-23 5:55 ` K, Mythri P
0 siblings, 0 replies; 34+ messages in thread
From: K, Mythri P @ 2011-06-23 5:55 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap, Valkeinen, Tomi
Hi,
On Mon, Jun 20, 2011 at 7:18 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of K, Mythri P
>> Sent: Friday, June 17, 2011 1:47 PM
>> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
>> Cc: K, Mythri P
>> Subject: [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver
>> to DSS and IP
>>
>> Splitting HDMI IP dependent IP configuring code from HDMI DSS
>> dependent code and
>> moving to a new IP file.
>>
>> Signed-off-by: Mythri P K <mythripk@ti.com>
>> ---
>> drivers/video/omap2/dss/Makefile | 1 +
>> drivers/video/omap2/dss/hdmi.c | 751
>> -------------------
>> drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 781
>> ++++++++++++++++++++
>> .../video/omap2/dss/{hdmi.h => hdmi_ti_4xxx_ip.h} | 9 +-
>> include/video/hdmi_ti_4xxx_ip.h | 10 +
>
> [sp] Is it okay to have 2 files by same name in two dirs?
> 'include/video' and 'drivers/.../omap2/dss'.
> Compiler won't complain, but my comments is more from readability.
> There has to be something characteristically different in these
> headers - maybe this should reflect in the names as well.
>
I have seen some instances of such nomenclature , where one is generic
to be used by other drivers across and is located located in
/include/video and other in local folder restricted to that file. Do
anyone else see an issue ?
> ~sanjeev
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure
2011-06-17 8:17 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Mythri P K
2011-06-17 8:17 ` [PATCH 4/8] OMAP4: DSS: HDMI: Move the common header file definition Mythri P K
2011-06-20 12:46 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Premi, Sanjeev
@ 2011-06-23 8:30 ` Tomi Valkeinen
2011-06-23 8:46 ` K, Mythri P
2 siblings, 1 reply; 34+ messages in thread
From: Tomi Valkeinen @ 2011-06-23 8:30 UTC (permalink / raw)
To: Mythri P K; +Cc: linux-omap
On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
> Define new HDMI timings structure to replace the OMAP DSS timing strucutre in hdmi.c
> to have the HDMI include defintion out of DSS.
>
> Signed-off-by: Mythri P K <mythripk@ti.com>
> ---
> drivers/video/omap2/dss/hdmi.c | 23 ++++++++++++++++++++---
> drivers/video/omap2/dss/hdmi.h | 15 ++++++++++++++-
> 2 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
> index 4ee879a..c24d573 100644
> --- a/drivers/video/omap2/dss/hdmi.c
> +++ b/drivers/video/omap2/dss/hdmi.c
> @@ -593,6 +593,20 @@ static int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
> return 0;
> }
>
> +static void copy_hdmi_to_dss_timings(struct hdmi_video_timings hdmi_timings,
> + struct omap_video_timings *timings)
There's no reason to pass hdmi_timings as a value, so it should be a
pointer.
> +{
> + timings->x_res = hdmi_timings.x_res;
> + timings->y_res = hdmi_timings.y_res;
> + timings->pixel_clock = hdmi_timings.pixel_clock;
> + timings->hbp = hdmi_timings.hbp;
> + timings->hfp = hdmi_timings.hfp;
> + timings->hsw = hdmi_timings.hsw;
> + timings->vbp = hdmi_timings.vbp;
> + timings->vfp = hdmi_timings.vfp;
> + timings->vsw = hdmi_timings.vsw;
> +}
> +
> static int get_timings_index(void)
> {
> int code;
> @@ -617,7 +631,7 @@ static struct hdmi_cm hdmi_get_code(struct omap_video_timings *timing)
> {
> int i = 0, code = -1, temp_vsync = 0, temp_hsync = 0;
> int timing_vsync = 0, timing_hsync = 0;
> - struct omap_video_timings temp;
> + struct hdmi_video_timings temp;
> struct hdmi_cm cm = {-1};
> DSSDBG("hdmi_get_code\n");
>
> @@ -775,7 +789,8 @@ static void hdmi_read_edid(struct omap_video_timings *dp)
"dp" feels a rather odd name for video timings variable. What does it
stand for?
Tomi
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure
2011-06-23 8:30 ` Tomi Valkeinen
@ 2011-06-23 8:46 ` K, Mythri P
0 siblings, 0 replies; 34+ messages in thread
From: K, Mythri P @ 2011-06-23 8:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap
Hi Tomi,
On Thu, Jun 23, 2011 at 2:00 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
>> Define new HDMI timings structure to replace the OMAP DSS timing strucutre in hdmi.c
>> to have the HDMI include defintion out of DSS.
>>
>> Signed-off-by: Mythri P K <mythripk@ti.com>
>> ---
>> drivers/video/omap2/dss/hdmi.c | 23 ++++++++++++++++++++---
>> drivers/video/omap2/dss/hdmi.h | 15 ++++++++++++++-
>> 2 files changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
>> index 4ee879a..c24d573 100644
>> --- a/drivers/video/omap2/dss/hdmi.c
>> +++ b/drivers/video/omap2/dss/hdmi.c
>> @@ -593,6 +593,20 @@ static int read_edid(struct hdmi_ip_data *ip_data, u8 *pedid, u16 max_length)
>> return 0;
>> }
>>
>> +static void copy_hdmi_to_dss_timings(struct hdmi_video_timings hdmi_timings,
>> + struct omap_video_timings *timings)
>
> There's no reason to pass hdmi_timings as a value, so it should be a
> pointer.
As the hdmi_timings is not changed in the function , i passed it by
value, Not a problem to change.
>
>> +{
>> + timings->x_res = hdmi_timings.x_res;
>> + timings->y_res = hdmi_timings.y_res;
>> + timings->pixel_clock = hdmi_timings.pixel_clock;
>> + timings->hbp = hdmi_timings.hbp;
>> + timings->hfp = hdmi_timings.hfp;
>> + timings->hsw = hdmi_timings.hsw;
>> + timings->vbp = hdmi_timings.vbp;
>> + timings->vfp = hdmi_timings.vfp;
>> + timings->vsw = hdmi_timings.vsw;
>> +}
>> +
>> static int get_timings_index(void)
>> {
>> int code;
>> @@ -617,7 +631,7 @@ static struct hdmi_cm hdmi_get_code(struct omap_video_timings *timing)
>> {
>> int i = 0, code = -1, temp_vsync = 0, temp_hsync = 0;
>> int timing_vsync = 0, timing_hsync = 0;
>> - struct omap_video_timings temp;
>> + struct hdmi_video_timings temp;
>> struct hdmi_cm cm = {-1};
>> DSSDBG("hdmi_get_code\n");
>>
>> @@ -775,7 +789,8 @@ static void hdmi_read_edid(struct omap_video_timings *dp)
>
> "dp" feels a rather odd name for video timings variable. What does it
> stand for?
*display pointer, but then it is not a part of this patch.
>
> Tomi
>
>
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-17 8:17 [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS Mythri P K
2011-06-17 8:17 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Mythri P K
@ 2011-06-23 9:58 ` Tomi Valkeinen
2011-06-23 12:05 ` K, Mythri P
1 sibling, 1 reply; 34+ messages in thread
From: Tomi Valkeinen @ 2011-06-23 9:58 UTC (permalink / raw)
To: Mythri P K; +Cc: linux-omap
On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
> HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
> the Display subsytem is different. Thus to reuse the code between these two
> processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
> new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
> generic location out of omap2/dss folder.
>
> This patch series does the split and also renames hdmi_omap4_panel.c to
> hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
> other OMAP family of processors as well.
These comments are based on the branch you have, not to particular
patches:
include/video/hdmi_ti_4xxx_ip.h:
- This file is in a way the most important one, because it's the public
API of the component. So you should be extra careful with this, and see
that everything in it makes sense, and it's clear how it is to be used.
- hdmi_core_hdmi_dvi is defined but not used. Should it be in the
private header?
- hdmi_pll_pwr seems to be very low level thing. It requires the user to
know HW details about the PLL, I don't think it should be visible to the
users. It is used in parameters for hdmi_ti_4xxx_set_pll_pwr(). When is
it supposed to be used? Why is hdmi_ti_4xxx_wp_video_start() not enough?
- The same goes to hdmi_ti_4xxx_pll_program. Who does the PLL
calculations, omapdss driver? Shouldn't the HDMI driver do it, the PLL
is a HDMI HW thing, not DSS HW? Or if they are defined in the board
file, and omapdss just gives them to the HDMI driver, I think the data
should be somehow passed through omapdss without omapdss actively
participating in the PLL programming. This would be easy if the HDMI
would use a platform device/driver model, the data could be passed via
the device data.
- If the PLL calculations have to be done by omapdss, couldn't the
hdmi_pll_info be part of hdmi_config?
- Is hdmi_ti_4xxx_phy_off the counterpart of hdmi_ti_4xxx_phy_init? If
so, the naming could be better to clearly show this. Like init/uninit,
enable/disable, etc.
- Is the "phy" relevant (from the user's point of view) in
hdmi_ti_4xxx_phy_init and off? Or could they be just init and uninit?
- Perhaps hdmi_ti_4xxx_basic_configure could be just configure, there's
no advanced configure or similar.
- is the "wp" important in hdmi_ti_4xxx_wp_video_start?
- read_ti_4xxx_edid() is named differently than the other functions.
drivers/video/hdmi_ti_4xxx_ip.c:
- EXPORT_SYMBOL(hdmi_ti_4xxx_phy_init); is not below the function.
drivers/video/omap2/dss/hdmi.c:
- hdmi_ti_4xxx_set_pll_pwr() is only called in power_off(), but never
enabled. I presume the HDMI driver does that internally. That doesn't
sound like a valid use of the function.
- Looking at hdmi_power_on(), I feel that the API of the HDMI driver
could be simpler. Would it be enough to have just one function to setup
the HDMI, and another to turn the output on?
- omapdss_hdmi_display_set_timing() seems to be broken. It just sets
some variables and calls display_enable().
Tomi
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
2011-06-23 5:51 ` K, Mythri P
@ 2011-06-23 10:30 ` Premi, Sanjeev
2011-06-23 11:00 ` K, Mythri P
0 siblings, 1 reply; 34+ messages in thread
From: Premi, Sanjeev @ 2011-06-23 10:30 UTC (permalink / raw)
To: K, Mythri P; +Cc: linux-omap, Valkeinen, Tomi
> -----Original Message-----
> From: K, Mythri P
> Sent: Thursday, June 23, 2011 11:21 AM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Subject: Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to
> pass base_address
>
> Hi Sanjeev,
>
> On Mon, Jun 20, 2011 at 7:03 PM, Premi, Sanjeev <premi@ti.com> wrote:
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org
> >> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of K, Mythri P
> >> Sent: Friday, June 17, 2011 1:47 PM
> >> To: linux-omap@vger.kernel.org; Valkeinen, Tomi
> >> Cc: K, Mythri P
> >> Subject: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass
> >> base_address
> >
> > [sp] HDMI appears twice on the subject. One of these can be removed.
> > Also, it isn't clear (though implied) whose base
> address is being
> > passed.
> >
> > The changes in the patch aren't limited to DSS alone.
> > See updated to hdmi_core_audio_config(),
> hdmi_wp_audio_config_format(),
> > hdmi_wp_audio_config_dma(), etc.
> >
> The changes are related to the HDMI driver which as of this patch is
> in DSS. You see any concerns ? It is only later that those functions
> are moved out .
[sp] The subject of mail indicates that changes are meant for DSS.
How are the functions I quoted related to DSS? Unless DSS on OMAP4
supports audio...
> >>
> >> - r = hdmi_read_reg(PLLCTRL_CFG1);
> >> + r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
> >> r = FLD_MOD(r, fmt->regm, 20, 9); /* CFG1_PLL_REGM */
> >> r = FLD_MOD(r, fmt->regn, 8, 1); /* CFG1_PLL_REGN */
> >>
> >> - hdmi_write_reg(PLLCTRL_CFG1, r);
> >> + hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
> >
> > [sp] hdmi_pll_base(ip_data) is used at many places withing this
> > function. Have you checked if saving the result in a local
> > variable generates any better code than repetitive ADD operation
> > in the function.
> >
> > Same comment applies to similar use in other functions
> > modified in this patch.
> >
> I had this comment from Tomi as well , Yes in some places it makes
> sense to have a local variable to save , but then in certain functions
> where there are four writes with 3 different base address it doesn't
> make sense to add 3 variables.
[sp] I don't see base address for the IP changing within the function.
so a local variable still makes sense - instead of using CPU cycles
to do reduntant calculations each time.
> > [snip]...[snip]
> >> + ,
> >> HDMI_CORE_DDC_CMD, 0x9, 3, 0);
> >
> > [sp] Misplaced "," at beginning of the line.
> >
> Not a part of the patch i suppose?
[sp] Actually the + indicates it is very much part of the patch.
Ideally it should be at end of prev line.
[quote]
/* Clear FIFO */
- REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x9, 3, 0);
+ REG_FLD_MOD(hdmi_core_sys_base(ip_data)
+ , HDMI_CORE_DDC_CMD, 0x9, 3, 0);
[/quote]
~sanjeev
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
2011-06-23 10:30 ` Premi, Sanjeev
@ 2011-06-23 11:00 ` K, Mythri P
2011-06-23 11:03 ` Premi, Sanjeev
0 siblings, 1 reply; 34+ messages in thread
From: K, Mythri P @ 2011-06-23 11:00 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap, Valkeinen, Tomi
Hi Sanjeev,
<snip>
>> >
>> > The changes in the patch aren't limited to DSS alone.
>> > See updated to hdmi_core_audio_config(),
>> hdmi_wp_audio_config_format(),
>> > hdmi_wp_audio_config_dma(), etc.
>> >
>> The changes are related to the HDMI driver which as of this patch is
>> in DSS. You see any concerns ? It is only later that those functions
>> are moved out .
>
> [sp] The subject of mail indicates that changes are meant for DSS.
> How are the functions I quoted related to DSS? Unless DSS on OMAP4
> supports audio...
>
Some of the Audio configuration for HDMI is part of DSS (as of 2.6.40)
, This patch series is precisely to separate the DSS portion from
non-DSS portion of HDMI.
It would be great if you have a look at the 2.6.40 kernel and this
gitorious tree with my patch set to get a fair idea.
>> >>
>> >> - r = hdmi_read_reg(PLLCTRL_CFG1);
>> >> + r = hdmi_read_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1);
>> >> r = FLD_MOD(r, fmt->regm, 20, 9); /* CFG1_PLL_REGM */
>> >> r = FLD_MOD(r, fmt->regn, 8, 1); /* CFG1_PLL_REGN */
>> >>
>> >> - hdmi_write_reg(PLLCTRL_CFG1, r);
>> >> + hdmi_write_reg(hdmi_pll_base(ip_data), PLLCTRL_CFG1, r);
>> >
>> > [sp] hdmi_pll_base(ip_data) is used at many places withing this
>> > function. Have you checked if saving the result in a local
>> > variable generates any better code than repetitive ADD operation
>> > in the function.
>> >
>> > Same comment applies to similar use in other functions
>> > modified in this patch.
>> >
>> I had this comment from Tomi as well , Yes in some places it makes
>> sense to have a local variable to save , but then in certain functions
>> where there are four writes with 3 different base address it doesn't
>> make sense to add 3 variables.
>
> [sp] I don't see base address for the IP changing within the function.
> so a local variable still makes sense - instead of using CPU cycles
> to do reduntant calculations each time.
I shall make those changes where applicable.
>
>> > [snip]...[snip]
>> >> + ,
>> >> HDMI_CORE_DDC_CMD, 0x9, 3, 0);
>> >
>> > [sp] Misplaced "," at beginning of the line.
>> >
>> Not a part of the patch i suppose?
>
> [sp] Actually the + indicates it is very much part of the patch.
> Ideally it should be at end of prev line.
> [quote]
> /* Clear FIFO */
> - REG_FLD_MOD(HDMI_CORE_DDC_CMD, 0x9, 3, 0);
> + REG_FLD_MOD(hdmi_core_sys_base(ip_data)
> + , HDMI_CORE_DDC_CMD, 0x9, 3, 0);
> [/quote]
>
> ~sanjeev
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* RE: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
2011-06-23 11:00 ` K, Mythri P
@ 2011-06-23 11:03 ` Premi, Sanjeev
2011-06-23 11:09 ` K, Mythri P
0 siblings, 1 reply; 34+ messages in thread
From: Premi, Sanjeev @ 2011-06-23 11:03 UTC (permalink / raw)
To: K, Mythri P; +Cc: linux-omap, Valkeinen, Tomi
> -----Original Message-----
> From: K, Mythri P
> Sent: Thursday, June 23, 2011 4:30 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi
> Subject: Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to
> pass base_address
>
> Hi Sanjeev,
>
> <snip>
> >> >
> >> > The changes in the patch aren't limited to DSS alone.
> >> > See updated to hdmi_core_audio_config(),
> >> hdmi_wp_audio_config_format(),
> >> > hdmi_wp_audio_config_dma(), etc.
> >> >
> >> The changes are related to the HDMI driver which as of
> this patch is
> >> in DSS. You see any concerns ? It is only later that those
> functions
> >> are moved out .
> >
> > [sp] The subject of mail indicates that changes are meant for DSS.
> > How are the functions I quoted related to DSS? Unless
> DSS on OMAP4
> > supports audio...
> >
> Some of the Audio configuration for HDMI is part of DSS (as of 2.6.40)
> , This patch series is precisely to separate the DSS portion from
> non-DSS portion of HDMI.
> It would be great if you have a look at the 2.6.40 kernel and this
> gitorious tree with my patch set to get a fair idea.
>
[sp] Then I suggest dropping "DSS" from the subject.
~sanjeev--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
2011-06-23 11:03 ` Premi, Sanjeev
@ 2011-06-23 11:09 ` K, Mythri P
0 siblings, 0 replies; 34+ messages in thread
From: K, Mythri P @ 2011-06-23 11:09 UTC (permalink / raw)
To: Premi, Sanjeev; +Cc: linux-omap, Valkeinen, Tomi
Hi Sanjeev,
On Thu, Jun 23, 2011 at 4:33 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: K, Mythri P
>> Sent: Thursday, June 23, 2011 4:30 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org; Valkeinen, Tomi
>> Subject: Re: [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to
>> pass base_address
>>
>> Hi Sanjeev,
>>
>> <snip>
>> >> >
>> >> > The changes in the patch aren't limited to DSS alone.
>> >> > See updated to hdmi_core_audio_config(),
>> >> hdmi_wp_audio_config_format(),
>> >> > hdmi_wp_audio_config_dma(), etc.
>> >> >
>> >> The changes are related to the HDMI driver which as of
>> this patch is
>> >> in DSS. You see any concerns ? It is only later that those
>> functions
>> >> are moved out .
>> >
>> > [sp] The subject of mail indicates that changes are meant for DSS.
>> > How are the functions I quoted related to DSS? Unless
>> DSS on OMAP4
>> > supports audio...
>> >
>> Some of the Audio configuration for HDMI is part of DSS (as of 2.6.40)
>> , This patch series is precisely to separate the DSS portion from
>> non-DSS portion of HDMI.
>> It would be great if you have a look at the 2.6.40 kernel and this
>> gitorious tree with my patch set to get a fair idea.
>>
>
> [sp] Then I suggest dropping "DSS" from the subject.
>
The DSS is to indicate that the file that is changed in the current
patch is a part of DSS directory.
> ~sanjeev
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-23 9:58 ` [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS Tomi Valkeinen
@ 2011-06-23 12:05 ` K, Mythri P
2011-06-23 12:31 ` Tomi Valkeinen
0 siblings, 1 reply; 34+ messages in thread
From: K, Mythri P @ 2011-06-23 12:05 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap
Hi Tomi,
On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
>> HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
>> the Display subsytem is different. Thus to reuse the code between these two
>> processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
>> new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
>> generic location out of omap2/dss folder.
>>
>> This patch series does the split and also renames hdmi_omap4_panel.c to
>> hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
>> other OMAP family of processors as well.
>
> These comments are based on the branch you have, not to particular
> patches:
>
> include/video/hdmi_ti_4xxx_ip.h:
>
> - This file is in a way the most important one, because it's the public
> API of the component. So you should be extra careful with this, and see
> that everything in it makes sense, and it's clear how it is to be used.
>
> - hdmi_core_hdmi_dvi is defined but not used. Should it be in the
> private header?
HDMI_HDMI and HDMI_DVI are used everywhere in hdmi.c and hdmi_ti_4xxx_ip.c,
one thing i could do is to add a patch to used this enumerator
instead of int mode ?
>
> - hdmi_pll_pwr seems to be very low level thing. It requires the user to
> know HW details about the PLL, I don't think it should be visible to the
> users. It is used in parameters for hdmi_ti_4xxx_set_pll_pwr(). When is
> it supposed to be used? Why is hdmi_ti_4xxx_wp_video_start() not enough?
>
HDMI has core , PLL and PHY blocks, so user of the ip driver should
configure them separately.
> - The same goes to hdmi_ti_4xxx_pll_program. Who does the PLL
> calculations, omapdss driver? Shouldn't the HDMI driver do it, the PLL
> is a HDMI HW thing, not DSS HW? Or if they are defined in the board
> file, and omapdss just gives them to the HDMI driver, I think the data
> should be somehow passed through omapdss without omapdss actively
> participating in the PLL programming. This would be easy if the HDMI
> would use a platform device/driver model, the data could be passed via
> the device data.
>
> - If the PLL calculations have to be done by omapdss, couldn't the
> hdmi_pll_info be part of hdmi_config?
hdmi_pll_info would be used only once while configuring (power on) ,
Why would we have to store the pll_info then in hdmi_config?
>
> - Is hdmi_ti_4xxx_phy_off the counterpart of hdmi_ti_4xxx_phy_init? If
> so, the naming could be better to clearly show this. Like init/uninit,
> enable/disable, etc.
I shall rename. yes phy_off is counterpart of init , i shall renmane
it to enable ,disable.
>
> - Is the "phy" relevant (from the user's point of view) in
> hdmi_ti_4xxx_phy_init and off? Or could they be just init and uninit?
PHY is a seperate block in HDMI and even from the user point of view
user should be aware of PHY, PLL and core blocks. so phy_init is
relevant.
>
> - Perhaps hdmi_ti_4xxx_basic_configure could be just configure, there's
> no advanced configure or similar.
Well, makes sense but this is the init_configuration(default
configuration) is what was intended in the patch.
>
> - is the "wp" important in hdmi_ti_4xxx_wp_video_start?
>
yes wp == wrapper , so it would be clear to have a wp_video_Start.
> - read_ti_4xxx_edid() is named differently than the other functions.
>
I shall rename to hdmi_ti_4xxx_read_edid.
> drivers/video/hdmi_ti_4xxx_ip.c:
>
> - EXPORT_SYMBOL(hdmi_ti_4xxx_phy_init); is not below the function.
>
> drivers/video/omap2/dss/hdmi.c:
>
> - hdmi_ti_4xxx_set_pll_pwr() is only called in power_off(), but never
> enabled. I presume the HDMI driver does that internally. That doesn't
> sound like a valid use of the function.
It is enabled in hdmi_ti_4xxx_pll_program called from power on.
>
> - Looking at hdmi_power_on(), I feel that the API of the HDMI driver
> could be simpler. Would it be enough to have just one function to setup
> the HDMI, and another to turn the output on?
No , I suppose it is the responsibility of the user of IP driver to
configure PHY , PLL and CORE blocks seperately as we can reuse the PLL
or PHY block in different SOC's as well.
>
> - omapdss_hdmi_display_set_timing() seems to be broken. It just sets
> some variables and calls display_enable().
It sets a variable custom_set , appropriate action will be taken while
configuring timings based on that parameter.
>
> Tomi
>
>
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-23 12:05 ` K, Mythri P
@ 2011-06-23 12:31 ` Tomi Valkeinen
2011-06-27 5:51 ` K, Mythri P
0 siblings, 1 reply; 34+ messages in thread
From: Tomi Valkeinen @ 2011-06-23 12:31 UTC (permalink / raw)
To: K, Mythri P; +Cc: linux-omap
On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
> Hi Tomi,
>
> On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
> >> HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
> >> the Display subsytem is different. Thus to reuse the code between these two
> >> processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
> >> new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
> >> generic location out of omap2/dss folder.
> >>
> >> This patch series does the split and also renames hdmi_omap4_panel.c to
> >> hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
> >> other OMAP family of processors as well.
> >
> > These comments are based on the branch you have, not to particular
> > patches:
> >
> > include/video/hdmi_ti_4xxx_ip.h:
> >
> > - This file is in a way the most important one, because it's the public
> > API of the component. So you should be extra careful with this, and see
> > that everything in it makes sense, and it's clear how it is to be used.
> >
> > - hdmi_core_hdmi_dvi is defined but not used. Should it be in the
> > private header?
>
> HDMI_HDMI and HDMI_DVI are used everywhere in hdmi.c and hdmi_ti_4xxx_ip.c,
> one thing i could do is to add a patch to used this enumerator
> instead of int mode ?
Oh, so the "int mode" in the header is actually "enum hdmi_core_hdmi_dvi
mode"? Using int is obviously wrong, then.
> > - hdmi_pll_pwr seems to be very low level thing. It requires the user to
> > know HW details about the PLL, I don't think it should be visible to the
> > users. It is used in parameters for hdmi_ti_4xxx_set_pll_pwr(). When is
> > it supposed to be used? Why is hdmi_ti_4xxx_wp_video_start() not enough?
> >
> HDMI has core , PLL and PHY blocks, so user of the ip driver should
> configure them separately.
Why? Is there some requirement/benefit to it?
> > - The same goes to hdmi_ti_4xxx_pll_program. Who does the PLL
> > calculations, omapdss driver? Shouldn't the HDMI driver do it, the PLL
> > is a HDMI HW thing, not DSS HW? Or if they are defined in the board
> > file, and omapdss just gives them to the HDMI driver, I think the data
> > should be somehow passed through omapdss without omapdss actively
> > participating in the PLL programming. This would be easy if the HDMI
> > would use a platform device/driver model, the data could be passed via
> > the device data.
Can you comment on this? Why the PLL calculation is not in the HDMI IP
driver?
> > - If the PLL calculations have to be done by omapdss, couldn't the
> > hdmi_pll_info be part of hdmi_config?
>
> hdmi_pll_info would be used only once while configuring (power on) ,
> Why would we have to store the pll_info then in hdmi_config?
Whether you store the hdmi_pll_info or not is HDMI IP driver internal
thing, not related to the API. We're talking about the API here.
Look at the include/video/hdmi_ti_4xxx_ip.h file and think from the
users view point: what is the most obvious and easiest way to use the
API. Then make the HDMI IP driver work with the API.
> > - Is hdmi_ti_4xxx_phy_off the counterpart of hdmi_ti_4xxx_phy_init? If
> > so, the naming could be better to clearly show this. Like init/uninit,
> > enable/disable, etc.
>
> I shall rename. yes phy_off is counterpart of init , i shall renmane
> it to enable ,disable.
> >
> > - Is the "phy" relevant (from the user's point of view) in
> > hdmi_ti_4xxx_phy_init and off? Or could they be just init and uninit?
>
> PHY is a seperate block in HDMI and even from the user point of view
> user should be aware of PHY, PLL and core blocks. so phy_init is
> relevant.
Again, why? Why cannot the user just give the configurations to the HDMI
IP driver, and start it, without knowing anything about PHY/PLL/core.
> > - Perhaps hdmi_ti_4xxx_basic_configure could be just configure, there's
> > no advanced configure or similar.
> Well, makes sense but this is the init_configuration(default
> configuration) is what was intended in the patch.
> >
> > - is the "wp" important in hdmi_ti_4xxx_wp_video_start?
> >
> yes wp == wrapper , so it would be clear to have a wp_video_Start.
Why does the user need to know wp == wrapper? Isn't the function just
about enabling the video output?
> > - read_ti_4xxx_edid() is named differently than the other functions.
> >
> I shall rename to hdmi_ti_4xxx_read_edid.
>
> > drivers/video/hdmi_ti_4xxx_ip.c:
> >
> > - EXPORT_SYMBOL(hdmi_ti_4xxx_phy_init); is not below the function.
> >
> > drivers/video/omap2/dss/hdmi.c:
> >
> > - hdmi_ti_4xxx_set_pll_pwr() is only called in power_off(), but never
> > enabled. I presume the HDMI driver does that internally. That doesn't
> > sound like a valid use of the function.
>
> It is enabled in hdmi_ti_4xxx_pll_program called from power on.
Yes, I can see that. But it's bad usage pattern. Never enable something
in one component, and disable it in another. The same entity has to do
them both.
> > - Looking at hdmi_power_on(), I feel that the API of the HDMI driver
> > could be simpler. Would it be enough to have just one function to setup
> > the HDMI, and another to turn the output on?
> No , I suppose it is the responsibility of the user of IP driver to
> configure PHY , PLL and CORE blocks seperately as we can reuse the PLL
> or PHY block in different SOC's as well.
Well, in that case, shouldn't PHY, PLL and CORE be in separate drivers?
If they are all in one HDMI IP driver, I don't see why the user would
need to know about PHY/PLL/CORE at all. The user just wants to use the
HDMI IP as a whole, doesn't it?
> > - omapdss_hdmi_display_set_timing() seems to be broken. It just sets
> > some variables and calls display_enable().
> It sets a variable custom_set , appropriate action will be taken while
> configuring timings based on that parameter.
This is the same thing as with the use of hdmi_ti_4xxx_set_pll_pwr.
Well, actually not, this is worse. A "set_timing" function which
unconditionally calls omapdss_hdmi_display_enable() makes no sense to
me. Why would set_timing function enable the display? And even more
importantly, omapdss_hdmi_display_enable() won't work correctly if it is
called unevenly related to omapdss_hdmi_display_disable(), which will
happen here.
Tomi
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-23 12:31 ` Tomi Valkeinen
@ 2011-06-27 5:51 ` K, Mythri P
2011-06-27 12:58 ` Tomi Valkeinen
0 siblings, 1 reply; 34+ messages in thread
From: K, Mythri P @ 2011-06-27 5:51 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap
Hi Tomi,
On Thu, Jun 23, 2011 at 6:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
>> Hi Tomi,
>>
>> On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
>> >> HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
>> >> the Display subsytem is different. Thus to reuse the code between these two
>> >> processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
>> >> new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
>> >> generic location out of omap2/dss folder.
>> >>
>> >> This patch series does the split and also renames hdmi_omap4_panel.c to
>> >> hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
>> >> other OMAP family of processors as well.
>> >
>> > These comments are based on the branch you have, not to particular
>> > patches:
>> >
>> > include/video/hdmi_ti_4xxx_ip.h:
>> >
>> > - This file is in a way the most important one, because it's the public
>> > API of the component. So you should be extra careful with this, and see
>> > that everything in it makes sense, and it's clear how it is to be used.
>> >
>> > - hdmi_core_hdmi_dvi is defined but not used. Should it be in the
>> > private header?
>>
>> HDMI_HDMI and HDMI_DVI are used everywhere in hdmi.c and hdmi_ti_4xxx_ip.c,
>> one thing i could do is to add a patch to used this enumerator
>> instead of int mode ?
>
> Oh, so the "int mode" in the header is actually "enum hdmi_core_hdmi_dvi
> mode"? Using int is obviously wrong, then.
sure i shall fix it in a separate patch.
>
>> > - hdmi_pll_pwr seems to be very low level thing. It requires the user to
>> > know HW details about the PLL, I don't think it should be visible to the
>> > users. It is used in parameters for hdmi_ti_4xxx_set_pll_pwr(). When is
>> > it supposed to be used? Why is hdmi_ti_4xxx_wp_video_start() not enough?
>> >
>> HDMI has core , PLL and PHY blocks, so user of the ip driver should
>> configure them separately.
>
> Why? Is there some requirement/benefit to it?
Yes , When the core block is replaced in future OMAP's same PLL and
PHY blocks are used.
>
>> > - The same goes to hdmi_ti_4xxx_pll_program. Who does the PLL
>> > calculations, omapdss driver? Shouldn't the HDMI driver do it, the PLL
>> > is a HDMI HW thing, not DSS HW? Or if they are defined in the board
>> > file, and omapdss just gives them to the HDMI driver, I think the data
>> > should be somehow passed through omapdss without omapdss actively
>> > participating in the PLL programming. This would be easy if the HDMI
>> > would use a platform device/driver model, the data could be passed via
>> > the device data.
>
> Can you comment on this? Why the PLL calculation is not in the HDMI IP
> driver?
The calculation of the PLL would depend on the sysclk freq right ? but
only the TMDS is the concern of HDMI IP block , so i would configure
only the TMDS portion in HDMI IP and calculation in DSS.
>
>> > - If the PLL calculations have to be done by omapdss, couldn't the
>> > hdmi_pll_info be part of hdmi_config?
>>
>> hdmi_pll_info would be used only once while configuring (power on) ,
>> Why would we have to store the pll_info then in hdmi_config?
>
> Whether you store the hdmi_pll_info or not is HDMI IP driver internal
> thing, not related to the API. We're talking about the API here.
>
> Look at the include/video/hdmi_ti_4xxx_ip.h file and think from the
> users view point: what is the most obvious and easiest way to use the
> API. Then make the HDMI IP driver work with the API.
As the pll_info in needed only for config of the PLL block it wouldnt
make sense to store it.[even from API point of view].
>
>> > - Is hdmi_ti_4xxx_phy_off the counterpart of hdmi_ti_4xxx_phy_init? If
>> > so, the naming could be better to clearly show this. Like init/uninit,
>> > enable/disable, etc.
>>
>> I shall rename. yes phy_off is counterpart of init , i shall renmane
>> it to enable ,disable.
>> >
>> > - Is the "phy" relevant (from the user's point of view) in
>> > hdmi_ti_4xxx_phy_init and off? Or could they be just init and uninit?
>>
>> PHY is a seperate block in HDMI and even from the user point of view
>> user should be aware of PHY, PLL and core blocks. so phy_init is
>> relevant.
>
> Again, why? Why cannot the user just give the configurations to the HDMI
> IP driver, and start it, without knowing anything about PHY/PLL/core.
>
Please see the comment above. The PHY , PLL and core blocks are interchangeable.
>> > - Perhaps hdmi_ti_4xxx_basic_configure could be just configure, there's
>> > no advanced configure or similar.
>> Well, makes sense but this is the init_configuration(default
>> configuration) is what was intended in the patch.
>> >
>> > - is the "wp" important in hdmi_ti_4xxx_wp_video_start?
>> >
>> yes wp == wrapper , so it would be clear to have a wp_video_Start.
>
> Why does the user need to know wp == wrapper? Isn't the function just
> about enabling the video output?
Well it is just to distinguish , yes the user doesn't have to know.
>
>> > - read_ti_4xxx_edid() is named differently than the other functions.
>> >
>> I shall rename to hdmi_ti_4xxx_read_edid.
>>
>> > drivers/video/hdmi_ti_4xxx_ip.c:
>> >
>> > - EXPORT_SYMBOL(hdmi_ti_4xxx_phy_init); is not below the function.
>> >
>> > drivers/video/omap2/dss/hdmi.c:
>> >
>> > - hdmi_ti_4xxx_set_pll_pwr() is only called in power_off(), but never
>> > enabled. I presume the HDMI driver does that internally. That doesn't
>> > sound like a valid use of the function.
>>
>> It is enabled in hdmi_ti_4xxx_pll_program called from power on.
>
> Yes, I can see that. But it's bad usage pattern. Never enable something
> in one component, and disable it in another. The same entity has to do
> them both.
>
>> > - Looking at hdmi_power_on(), I feel that the API of the HDMI driver
>> > could be simpler. Would it be enough to have just one function to setup
>> > the HDMI, and another to turn the output on?
>> No , I suppose it is the responsibility of the user of IP driver to
>> configure PHY , PLL and CORE blocks seperately as we can reuse the PLL
>> or PHY block in different SOC's as well.
>
> Well, in that case, shouldn't PHY, PLL and CORE be in separate drivers?
> If they are all in one HDMI IP driver, I don't see why the user would
> need to know about PHY/PLL/CORE at all. The user just wants to use the
> HDMI IP as a whole, doesn't it?
Please see above comment, we could still use the same PLL block in
future OMAP's only replacing the core block so is the case with
PHY.But then it doesnt make sense to split the driver for every 2/3
functions right ? User could still access the PLL and PHY from this IP
where as use the new API's for core?
>
>> > - omapdss_hdmi_display_set_timing() seems to be broken. It just sets
>> > some variables and calls display_enable().
>> It sets a variable custom_set , appropriate action will be taken while
>> configuring timings based on that parameter.
>
> This is the same thing as with the use of hdmi_ti_4xxx_set_pll_pwr.
> Well, actually not, this is worse. A "set_timing" function which
> unconditionally calls omapdss_hdmi_display_enable() makes no sense to
> me. Why would set_timing function enable the display? And even more
> importantly, omapdss_hdmi_display_enable() won't work correctly if it is
> called unevenly related to omapdss_hdmi_display_disable(), which will
> happen here.
>
There is a disable and enable called , This is on the same lines as
other panels,
I shall re check and post different patch in case of any correction,
as i don't see it as a part of this patch series.
> Tomi
>
>
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-27 5:51 ` K, Mythri P
@ 2011-06-27 12:58 ` Tomi Valkeinen
2011-06-29 13:38 ` K, Mythri P
0 siblings, 1 reply; 34+ messages in thread
From: Tomi Valkeinen @ 2011-06-27 12:58 UTC (permalink / raw)
To: K, Mythri P; +Cc: linux-omap
On Mon, 2011-06-27 at 11:21 +0530, K, Mythri P wrote:
> Hi Tomi,
>
> On Thu, Jun 23, 2011 at 6:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
> >> Hi Tomi,
> >>
> >> On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >> > On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
> >> >> HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
> >> >> the Display subsytem is different. Thus to reuse the code between these two
> >> >> processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
> >> >> new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
> >> >> generic location out of omap2/dss folder.
> >> >>
> >> >> This patch series does the split and also renames hdmi_omap4_panel.c to
> >> >> hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
> >> >> other OMAP family of processors as well.
> >> >
> >> > These comments are based on the branch you have, not to particular
> >> > patches:
> >> >
> >> > include/video/hdmi_ti_4xxx_ip.h:
> >> >
> >> > - This file is in a way the most important one, because it's the public
> >> > API of the component. So you should be extra careful with this, and see
> >> > that everything in it makes sense, and it's clear how it is to be used.
> >> >
> >> > - hdmi_core_hdmi_dvi is defined but not used. Should it be in the
> >> > private header?
> >>
> >> HDMI_HDMI and HDMI_DVI are used everywhere in hdmi.c and hdmi_ti_4xxx_ip.c,
> >> one thing i could do is to add a patch to used this enumerator
> >> instead of int mode ?
> >
> > Oh, so the "int mode" in the header is actually "enum hdmi_core_hdmi_dvi
> > mode"? Using int is obviously wrong, then.
> sure i shall fix it in a separate patch.
> >
> >> > - hdmi_pll_pwr seems to be very low level thing. It requires the user to
> >> > know HW details about the PLL, I don't think it should be visible to the
> >> > users. It is used in parameters for hdmi_ti_4xxx_set_pll_pwr(). When is
> >> > it supposed to be used? Why is hdmi_ti_4xxx_wp_video_start() not enough?
> >> >
> >> HDMI has core , PLL and PHY blocks, so user of the ip driver should
> >> configure them separately.
> >
> > Why? Is there some requirement/benefit to it?
>
> Yes , When the core block is replaced in future OMAP's same PLL and
> PHY blocks are used.
That doesn't answer the question why the user should know about the
details of the HW. As far as I see, the user wants basically to
configure, enable and disable the HDMI HW. The user wants to do the same
things, regardless of the HDMI HW blocks used in that particular OMAP.
However, there is a reason why the HDMI PLL should be considered
separately: the PLL can be used as a clock source for DISPC and VENC. So
the API should offer functionality to configure and use the PLL
separately from the HDMI core/phy. But even so, hdmi_pll_pwr feels a bit
too low-level function for this API.
As for HDMI core/phy, is there ever reason to use one but not another?
Or is there a reason to configure them separately? If not, I don't see
why they should be present separately in the API.
> >> > - The same goes to hdmi_ti_4xxx_pll_program. Who does the PLL
> >> > calculations, omapdss driver? Shouldn't the HDMI driver do it, the PLL
> >> > is a HDMI HW thing, not DSS HW? Or if they are defined in the board
> >> > file, and omapdss just gives them to the HDMI driver, I think the data
> >> > should be somehow passed through omapdss without omapdss actively
> >> > participating in the PLL programming. This would be easy if the HDMI
> >> > would use a platform device/driver model, the data could be passed via
> >> > the device data.
> >
> > Can you comment on this? Why the PLL calculation is not in the HDMI IP
> > driver?
> The calculation of the PLL would depend on the sysclk freq right ? but
> only the TMDS is the concern of HDMI IP block , so i would configure
> only the TMDS portion in HDMI IP and calculation in DSS.
The HDMI PLL is part of the HDMI HW, not DSS HW, right? What if the HDMI
PLL used in next OMAP would contain one more divider? Using it would
require writing new calculation code into DSS driver. The PLL dividers
and calculations sound very much like HDMI PLL internal thing, not
something that should be handled in the DSS level.
Yes, PLL calculations depend on the input clock, in this case sys_clk.
So it should be provided to the HDMI code.
> >> > - If the PLL calculations have to be done by omapdss, couldn't the
> >> > hdmi_pll_info be part of hdmi_config?
> >>
> >> hdmi_pll_info would be used only once while configuring (power on) ,
> >> Why would we have to store the pll_info then in hdmi_config?
> >
> > Whether you store the hdmi_pll_info or not is HDMI IP driver internal
> > thing, not related to the API. We're talking about the API here.
> >
> > Look at the include/video/hdmi_ti_4xxx_ip.h file and think from the
> > users view point: what is the most obvious and easiest way to use the
> > API. Then make the HDMI IP driver work with the API.
>
> As the pll_info in needed only for config of the PLL block it wouldnt
> make sense to store it.[even from API point of view].
The API doesn't have anything related to storing the pll_info. If a good
API requires the HDMI driver to store some pieces of information, why
would that be a problem?
> >> > - Is hdmi_ti_4xxx_phy_off the counterpart of hdmi_ti_4xxx_phy_init? If
> >> > so, the naming could be better to clearly show this. Like init/uninit,
> >> > enable/disable, etc.
> >>
> >> I shall rename. yes phy_off is counterpart of init , i shall renmane
> >> it to enable ,disable.
> >> >
> >> > - Is the "phy" relevant (from the user's point of view) in
> >> > hdmi_ti_4xxx_phy_init and off? Or could they be just init and uninit?
> >>
> >> PHY is a seperate block in HDMI and even from the user point of view
> >> user should be aware of PHY, PLL and core blocks. so phy_init is
> >> relevant.
> >
> > Again, why? Why cannot the user just give the configurations to the HDMI
> > IP driver, and start it, without knowing anything about PHY/PLL/core.
> >
> Please see the comment above. The PHY , PLL and core blocks are interchangeable.
I don't see how this answers the question.
If the GPIO hardware on some platform would have three HW blocks that
can be changed depending on the SoC version, we would still just use the
normal GPIO API. Not a GPIO API with separate functions to configure all
those three HW blocks.
> >> > - Perhaps hdmi_ti_4xxx_basic_configure could be just configure, there's
> >> > no advanced configure or similar.
> >> Well, makes sense but this is the init_configuration(default
> >> configuration) is what was intended in the patch.
> >> >
> >> > - is the "wp" important in hdmi_ti_4xxx_wp_video_start?
> >> >
> >> yes wp == wrapper , so it would be clear to have a wp_video_Start.
> >
> > Why does the user need to know wp == wrapper? Isn't the function just
> > about enabling the video output?
> Well it is just to distinguish , yes the user doesn't have to know.
> >
> >> > - read_ti_4xxx_edid() is named differently than the other functions.
> >> >
> >> I shall rename to hdmi_ti_4xxx_read_edid.
> >>
> >> > drivers/video/hdmi_ti_4xxx_ip.c:
> >> >
> >> > - EXPORT_SYMBOL(hdmi_ti_4xxx_phy_init); is not below the function.
> >> >
> >> > drivers/video/omap2/dss/hdmi.c:
> >> >
> >> > - hdmi_ti_4xxx_set_pll_pwr() is only called in power_off(), but never
> >> > enabled. I presume the HDMI driver does that internally. That doesn't
> >> > sound like a valid use of the function.
> >>
> >> It is enabled in hdmi_ti_4xxx_pll_program called from power on.
> >
> > Yes, I can see that. But it's bad usage pattern. Never enable something
> > in one component, and disable it in another. The same entity has to do
> > them both.
> >
> >> > - Looking at hdmi_power_on(), I feel that the API of the HDMI driver
> >> > could be simpler. Would it be enough to have just one function to setup
> >> > the HDMI, and another to turn the output on?
> >> No , I suppose it is the responsibility of the user of IP driver to
> >> configure PHY , PLL and CORE blocks seperately as we can reuse the PLL
> >> or PHY block in different SOC's as well.
> >
> > Well, in that case, shouldn't PHY, PLL and CORE be in separate drivers?
> > If they are all in one HDMI IP driver, I don't see why the user would
> > need to know about PHY/PLL/CORE at all. The user just wants to use the
> > HDMI IP as a whole, doesn't it?
>
> Please see above comment, we could still use the same PLL block in
> future OMAP's only replacing the core block so is the case with
> PHY.But then it doesnt make sense to split the driver for every 2/3
> functions right ? User could still access the PLL and PHY from this IP
> where as use the new API's for core?
But it shouldn't be the user's job to handle that. The user doesn't want
to use a driver for a particular version of the HDMI core. It just wants
to use the HDMI, regardless of what HW blocks are being used on that
particular platform.
> >> > - omapdss_hdmi_display_set_timing() seems to be broken. It just sets
> >> > some variables and calls display_enable().
> >> It sets a variable custom_set , appropriate action will be taken while
> >> configuring timings based on that parameter.
> >
> > This is the same thing as with the use of hdmi_ti_4xxx_set_pll_pwr.
> > Well, actually not, this is worse. A "set_timing" function which
> > unconditionally calls omapdss_hdmi_display_enable() makes no sense to
> > me. Why would set_timing function enable the display? And even more
> > importantly, omapdss_hdmi_display_enable() won't work correctly if it is
> > called unevenly related to omapdss_hdmi_display_disable(), which will
> > happen here.
> >
> There is a disable and enable called , This is on the same lines as
> other panels,
What other panel/interface does it like that? It needs to be fixed also,
then.
The problem is not that enable and disable would not be called. It's how
they are called.
A set_timing function which would disable the interface, configure the
timings, and enable the interface would make sense. A set_timings
function which would require the caller to first disable the interface,
and re-enable it after calling would make sense. A set_timing function
that requires the caller to disable the interface, and then implicitly
enables the interface by its own does not make sense.
I also wonder why the interface needs to be disabled and enabled when
timings are changed. Is there a specific requirement from the HW that
this needs to be done?
> I shall re check and post different patch in case of any correction,
> as i don't see it as a part of this patch series.
Sure. The set_timings issue is not directly related to this split patch
set.
However, I just want to point out that getting this patch set ready may
require more changes than you (or I) had originally in mind. The reason
is that the HDMI API will become public and used by other SoCs. The API
has to be good enough so that we don't need to do major rewrites to all
users of the API later. If this requires making fixes and changes to the
current HDMI driver, that's what needs to be done first.
And it just occurred to me that perhaps our views of the API are a bit
different, and that's why we have differing opinions. I see this API as
something that could be used by OMAP DSS (and equivalent components on
other SoCs) to use the HDMI HW on OMAP4 and any future OMAPs. And
perhaps you see this API more as an API to use the current HDMI HW in
the OMAP4.
While I don't want to take this too far, and try to make a perfect API
(because it'd just fail as we don't have a clear view of the future HW
and the future needs), I would still like to get the API into the
direction where it's not strictly an API to use the current HDMI HW, but
something that can be easily used for later HWs also.
Tomi
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-27 12:58 ` Tomi Valkeinen
@ 2011-06-29 13:38 ` K, Mythri P
2011-06-29 16:21 ` Tomi Valkeinen
0 siblings, 1 reply; 34+ messages in thread
From: K, Mythri P @ 2011-06-29 13:38 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap
Hi Tomi,
On Mon, Jun 27, 2011 at 6:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Mon, 2011-06-27 at 11:21 +0530, K, Mythri P wrote:
>> Hi Tomi,
>>
>> On Thu, Jun 23, 2011 at 6:01 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > On Thu, 2011-06-23 at 17:35 +0530, K, Mythri P wrote:
>> >> Hi Tomi,
>> >>
>> >> On Thu, Jun 23, 2011 at 3:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> >> > On Fri, 2011-06-17 at 13:47 +0530, Mythri P K wrote:
>> >> >> HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
>> >> >> the Display subsytem is different. Thus to reuse the code between these two
>> >> >> processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
>> >> >> new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
>> >> >> generic location out of omap2/dss folder.
>> >> >>
>> >> >> This patch series does the split and also renames hdmi_omap4_panel.c to
>> >> >> hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
>> >> >> other OMAP family of processors as well.
>> >> >
>> >> > These comments are based on the branch you have, not to particular
>> >> > patches:
>> >> >
>> >> > include/video/hdmi_ti_4xxx_ip.h:
>> >> >
>> >> > - This file is in a way the most important one, because it's the public
>> >> > API of the component. So you should be extra careful with this, and see
>> >> > that everything in it makes sense, and it's clear how it is to be used.
>> >> >
>> >> > - hdmi_core_hdmi_dvi is defined but not used. Should it be in the
>> >> > private header?
>> >>
>> >> HDMI_HDMI and HDMI_DVI are used everywhere in hdmi.c and hdmi_ti_4xxx_ip.c,
>> >> one thing i could do is to add a patch to used this enumerator
>> >> instead of int mode ?
>> >
>> > Oh, so the "int mode" in the header is actually "enum hdmi_core_hdmi_dvi
>> > mode"? Using int is obviously wrong, then.
>> sure i shall fix it in a separate patch.
>> >
>> >> > - hdmi_pll_pwr seems to be very low level thing. It requires the user to
>> >> > know HW details about the PLL, I don't think it should be visible to the
>> >> > users. It is used in parameters for hdmi_ti_4xxx_set_pll_pwr(). When is
>> >> > it supposed to be used? Why is hdmi_ti_4xxx_wp_video_start() not enough?
>> >> >
>> >> HDMI has core , PLL and PHY blocks, so user of the ip driver should
>> >> configure them separately.
>> >
>> > Why? Is there some requirement/benefit to it?
>>
>> Yes , When the core block is replaced in future OMAP's same PLL and
>> PHY blocks are used.
>
> That doesn't answer the question why the user should know about the
> details of the HW. As far as I see, the user wants basically to
> configure, enable and disable the HDMI HW. The user wants to do the same
> things, regardless of the HDMI HW blocks used in that particular OMAP.
>
> However, there is a reason why the HDMI PLL should be considered
> separately: the PLL can be used as a clock source for DISPC and VENC. So
> the API should offer functionality to configure and use the PLL
> separately from the HDMI core/phy. But even so, hdmi_pll_pwr feels a bit
> too low-level function for this API.
>
> As for HDMI core/phy, is there ever reason to use one but not another?
> Or is there a reason to configure them separately? If not, I don't see
> why they should be present separately in the API.
>
>> >> > - The same goes to hdmi_ti_4xxx_pll_program. Who does the PLL
>> >> > calculations, omapdss driver? Shouldn't the HDMI driver do it, the PLL
>> >> > is a HDMI HW thing, not DSS HW? Or if they are defined in the board
>> >> > file, and omapdss just gives them to the HDMI driver, I think the data
>> >> > should be somehow passed through omapdss without omapdss actively
>> >> > participating in the PLL programming. This would be easy if the HDMI
>> >> > would use a platform device/driver model, the data could be passed via
>> >> > the device data.
>> >
>> > Can you comment on this? Why the PLL calculation is not in the HDMI IP
>> > driver?
>> The calculation of the PLL would depend on the sysclk freq right ? but
>> only the TMDS is the concern of HDMI IP block , so i would configure
>> only the TMDS portion in HDMI IP and calculation in DSS.
>
> The HDMI PLL is part of the HDMI HW, not DSS HW, right? What if the HDMI
> PLL used in next OMAP would contain one more divider? Using it would
> require writing new calculation code into DSS driver. The PLL dividers
> and calculations sound very much like HDMI PLL internal thing, not
> something that should be handled in the DSS level.
>
> Yes, PLL calculations depend on the input clock, in this case sys_clk.
> So it should be provided to the HDMI code.
>
>> >> > - If the PLL calculations have to be done by omapdss, couldn't the
>> >> > hdmi_pll_info be part of hdmi_config?
>> >>
>> >> hdmi_pll_info would be used only once while configuring (power on) ,
>> >> Why would we have to store the pll_info then in hdmi_config?
>> >
>> > Whether you store the hdmi_pll_info or not is HDMI IP driver internal
>> > thing, not related to the API. We're talking about the API here.
>> >
>> > Look at the include/video/hdmi_ti_4xxx_ip.h file and think from the
>> > users view point: what is the most obvious and easiest way to use the
>> > API. Then make the HDMI IP driver work with the API.
>>
>> As the pll_info in needed only for config of the PLL block it wouldnt
>> make sense to store it.[even from API point of view].
>
> The API doesn't have anything related to storing the pll_info. If a good
> API requires the HDMI driver to store some pieces of information, why
> would that be a problem?
>
>> >> > - Is hdmi_ti_4xxx_phy_off the counterpart of hdmi_ti_4xxx_phy_init? If
>> >> > so, the naming could be better to clearly show this. Like init/uninit,
>> >> > enable/disable, etc.
>> >>
>> >> I shall rename. yes phy_off is counterpart of init , i shall renmane
>> >> it to enable ,disable.
>> >> >
>> >> > - Is the "phy" relevant (from the user's point of view) in
>> >> > hdmi_ti_4xxx_phy_init and off? Or could they be just init and uninit?
>> >>
>> >> PHY is a seperate block in HDMI and even from the user point of view
>> >> user should be aware of PHY, PLL and core blocks. so phy_init is
>> >> relevant.
>> >
>> > Again, why? Why cannot the user just give the configurations to the HDMI
>> > IP driver, and start it, without knowing anything about PHY/PLL/core.
>> >
>> Please see the comment above. The PHY , PLL and core blocks are interchangeable.
>
> I don't see how this answers the question.
>
> If the GPIO hardware on some platform would have three HW blocks that
> can be changed depending on the SoC version, we would still just use the
> normal GPIO API. Not a GPIO API with separate functions to configure all
> those three HW blocks.
>
As the HDMI PLL , PHY and video blocks are logical blocks it would
make sense to have the API's for all and the DSS HDMI (interface
driver - user driver) would make a call to configure this in a
particular sequence to enable HDMI , in case you the call to be
generic across OMAPS in future then we should i either have a funtion
in hdmi.c which will do this sequence and will be aware of underlying
IP , Which doesnt appear to be the solution you prefer but then there
would be a need to have an intermediate file which would take the
common API call(function pointer) and then arbitrate between different
IP's based on the make , Is that what you are suggesting ?
>> >> > - Perhaps hdmi_ti_4xxx_basic_configure could be just configure, there's
>> >> > no advanced configure or similar.
>> >> Well, makes sense but this is the init_configuration(default
>> >> configuration) is what was intended in the patch.
>> >> >
>> >> > - is the "wp" important in hdmi_ti_4xxx_wp_video_start?
>> >> >
>> >> yes wp == wrapper , so it would be clear to have a wp_video_Start.
>> >
>> > Why does the user need to know wp == wrapper? Isn't the function just
>> > about enabling the video output?
>> Well it is just to distinguish , yes the user doesn't have to know.
>> >
>> >> > - read_ti_4xxx_edid() is named differently than the other functions.
>> >> >
>> >> I shall rename to hdmi_ti_4xxx_read_edid.
>> >>
>> >> > drivers/video/hdmi_ti_4xxx_ip.c:
>> >> >
>> >> > - EXPORT_SYMBOL(hdmi_ti_4xxx_phy_init); is not below the function.
>> >> >
>> >> > drivers/video/omap2/dss/hdmi.c:
>> >> >
>> >> > - hdmi_ti_4xxx_set_pll_pwr() is only called in power_off(), but never
>> >> > enabled. I presume the HDMI driver does that internally. That doesn't
>> >> > sound like a valid use of the function.
>> >>
>> >> It is enabled in hdmi_ti_4xxx_pll_program called from power on.
>> >
>> > Yes, I can see that. But it's bad usage pattern. Never enable something
>> > in one component, and disable it in another. The same entity has to do
>> > them both.
>> >
>> >> > - Looking at hdmi_power_on(), I feel that the API of the HDMI driver
>> >> > could be simpler. Would it be enough to have just one function to setup
>> >> > the HDMI, and another to turn the output on?
>> >> No , I suppose it is the responsibility of the user of IP driver to
>> >> configure PHY , PLL and CORE blocks seperately as we can reuse the PLL
>> >> or PHY block in different SOC's as well.
>> >
>> > Well, in that case, shouldn't PHY, PLL and CORE be in separate drivers?
>> > If they are all in one HDMI IP driver, I don't see why the user would
>> > need to know about PHY/PLL/CORE at all. The user just wants to use the
>> > HDMI IP as a whole, doesn't it?
>>
>> Please see above comment, we could still use the same PLL block in
>> future OMAP's only replacing the core block so is the case with
>> PHY.But then it doesnt make sense to split the driver for every 2/3
>> functions right ? User could still access the PLL and PHY from this IP
>> where as use the new API's for core?
>
> But it shouldn't be the user's job to handle that. The user doesn't want
> to use a driver for a particular version of the HDMI core. It just wants
> to use the HDMI, regardless of what HW blocks are being used on that
> particular platform.
>
>> >> > - omapdss_hdmi_display_set_timing() seems to be broken. It just sets
>> >> > some variables and calls display_enable().
>> >> It sets a variable custom_set , appropriate action will be taken while
>> >> configuring timings based on that parameter.
>> >
>> > This is the same thing as with the use of hdmi_ti_4xxx_set_pll_pwr.
>> > Well, actually not, this is worse. A "set_timing" function which
>> > unconditionally calls omapdss_hdmi_display_enable() makes no sense to
>> > me. Why would set_timing function enable the display? And even more
>> > importantly, omapdss_hdmi_display_enable() won't work correctly if it is
>> > called unevenly related to omapdss_hdmi_display_disable(), which will
>> > happen here.
>> >
>> There is a disable and enable called , This is on the same lines as
>> other panels,
>
> What other panel/interface does it like that? It needs to be fixed also,
> then.
>
> The problem is not that enable and disable would not be called. It's how
> they are called.
>
> A set_timing function which would disable the interface, configure the
> timings, and enable the interface would make sense. A set_timings
> function which would require the caller to first disable the interface,
> and re-enable it after calling would make sense. A set_timing function
> that requires the caller to disable the interface, and then implicitly
> enables the interface by its own does not make sense.
>
> I also wonder why the interface needs to be disabled and enabled when
> timings are changed. Is there a specific requirement from the HW that
> this needs to be done?
>
When the timings are changed HDMI PLL has to be reconfigured also the
core block to reflect the new timing. so it has to be re configured.
But can we take that in a seperate thread as i dont see this whole
section as a part of this patch series.
>> I shall re check and post different patch in case of any correction,
>> as i don't see it as a part of this patch series.
>
> Sure. The set_timings issue is not directly related to this split patch
> set.
>
> However, I just want to point out that getting this patch set ready may
> require more changes than you (or I) had originally in mind. The reason
> is that the HDMI API will become public and used by other SoCs. The API
> has to be good enough so that we don't need to do major rewrites to all
> users of the API later. If this requires making fixes and changes to the
> current HDMI driver, that's what needs to be done first.
>
> And it just occurred to me that perhaps our views of the API are a bit
> different, and that's why we have differing opinions. I see this API as
> something that could be used by OMAP DSS (and equivalent components on
> other SoCs) to use the HDMI HW on OMAP4 and any future OMAPs. And
> perhaps you see this API more as an API to use the current HDMI HW in
> the OMAP4.
Tomi , Yes my Idea of this API is for OMAP and Netra series only , I
am unable to envision a common HDMI API library , in that case it
would make more sense to have an intermediate file and have function
pointer , which would take common API calls like hdmi_enable ,
hdmi_avi_confg etc and then arbitrate based on the build. Please let
me know if you have anything else in mind.
>
> While I don't want to take this too far, and try to make a perfect API
> (because it'd just fail as we don't have a clear view of the future HW
> and the future needs), I would still like to get the API into the
> direction where it's not strictly an API to use the current HDMI HW, but
> something that can be easily used for later HWs also.
>
> Tomi
>
>
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-29 13:38 ` K, Mythri P
@ 2011-06-29 16:21 ` Tomi Valkeinen
2011-06-30 17:46 ` K, Mythri P
0 siblings, 1 reply; 34+ messages in thread
From: Tomi Valkeinen @ 2011-06-29 16:21 UTC (permalink / raw)
To: K, Mythri P; +Cc: linux-omap
Hi,
On Wed, 2011-06-29 at 19:08 +0530, K, Mythri P wrote:
> Hi Tomi,
> As the HDMI PLL , PHY and video blocks are logical blocks it would
> make sense to have the API's for all and the DSS HDMI (interface
> driver - user driver) would make a call to configure this in a
> particular sequence to enable HDMI , in case you the call to be
> generic across OMAPS in future then we should i either have a funtion
> in hdmi.c which will do this sequence and will be aware of underlying
> IP , Which doesnt appear to be the solution you prefer but then there
> would be a need to have an intermediate file which would take the
> common API call(function pointer) and then arbitrate between different
> IP's based on the make , Is that what you are suggesting ?
I agree that they are separate blocks, and at some level they need to be
separate with own functions for each. But I don't see why the user needs
to know about it.
For example, consider OMAP DSI. DSI has protocol, PLL and PHY blocks,
and the driver has functions to initialize them, use them etc. But the
user of DSI, in this case panel drivers, do not need to know about it,
and the API exported to the panel drivers does not contain any functions
related to PLL or PHY. The panel drivers just enable the DSI driver and
use it.
So I'm still asking: what benefit does it give to the user that the API
has functions to handle the blocks separately? There has to be a reason
for the functions in the API.
> > And it just occurred to me that perhaps our views of the API are a bit
> > different, and that's why we have differing opinions. I see this API as
> > something that could be used by OMAP DSS (and equivalent components on
> > other SoCs) to use the HDMI HW on OMAP4 and any future OMAPs. And
> > perhaps you see this API more as an API to use the current HDMI HW in
> > the OMAP4.
>
> Tomi , Yes my Idea of this API is for OMAP and Netra series only , I
> am unable to envision a common HDMI API library , in that case it
> would make more sense to have an intermediate file and have function
> pointer , which would take common API calls like hdmi_enable ,
> hdmi_avi_confg etc and then arbitrate based on the build. Please let
> me know if you have anything else in mind.
I didn't mean a generic HDMI API either. I meant a TI HDMI API,
currently for OMAP and Netra. But my comments would be valid even if the
API would be only OMAP DSS internal.
Tomi
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-29 16:21 ` Tomi Valkeinen
@ 2011-06-30 17:46 ` K, Mythri P
2011-07-01 8:51 ` Tomi Valkeinen
0 siblings, 1 reply; 34+ messages in thread
From: K, Mythri P @ 2011-06-30 17:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap
Hi Tomi,
On Wed, Jun 29, 2011 at 9:51 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> On Wed, 2011-06-29 at 19:08 +0530, K, Mythri P wrote:
>> Hi Tomi,
>
>> As the HDMI PLL , PHY and video blocks are logical blocks it would
>> make sense to have the API's for all and the DSS HDMI (interface
>> driver - user driver) would make a call to configure this in a
>> particular sequence to enable HDMI , in case you the call to be
>> generic across OMAPS in future then we should i either have a funtion
>> in hdmi.c which will do this sequence and will be aware of underlying
>> IP , Which doesnt appear to be the solution you prefer but then there
>> would be a need to have an intermediate file which would take the
>> common API call(function pointer) and then arbitrate between different
>> IP's based on the make , Is that what you are suggesting ?
>
> I agree that they are separate blocks, and at some level they need to be
> separate with own functions for each. But I don't see why the user needs
> to know about it.
>
> For example, consider OMAP DSI. DSI has protocol, PLL and PHY blocks,
> and the driver has functions to initialize them, use them etc. But the
> user of DSI, in this case panel drivers, do not need to know about it,
> and the API exported to the panel drivers does not contain any functions
> related to PLL or PHY. The panel drivers just enable the DSI driver and
> use it.
>
> So I'm still asking: what benefit does it give to the user that the API
> has functions to handle the blocks separately? There has to be a reason
> for the functions in the API.
>
It doesnt give any additional benefit but flexibility to change the
blocks (PHY / PLL) indivudally to use a different one.
>> > And it just occurred to me that perhaps our views of the API are a bit
>> > different, and that's why we have differing opinions. I see this API as
>> > something that could be used by OMAP DSS (and equivalent components on
>> > other SoCs) to use the HDMI HW on OMAP4 and any future OMAPs. And
>> > perhaps you see this API more as an API to use the current HDMI HW in
>> > the OMAP4.
>>
>> Tomi , Yes my Idea of this API is for OMAP and Netra series only , I
>> am unable to envision a common HDMI API library , in that case it
>> would make more sense to have an intermediate file and have function
>> pointer , which would take common API calls like hdmi_enable ,
>> hdmi_avi_confg etc and then arbitrate based on the build. Please let
>> me know if you have anything else in mind.
>
> I didn't mean a generic HDMI API either. I meant a TI HDMI API,
> currently for OMAP and Netra. But my comments would be valid even if the
> API would be only OMAP DSS internal.
>
Neither the HDMI DSS driver should be concerned about these PHY/PLL
internal API's nor should the configuration be done in the IP driver
as the IP driver shpuld only provide functionality and should be
flexible enough as across OMAP4 and netra itself there is a
possibility of the PHY block being different , so Now the only
solution i see is to have a intermediate file , whose job is to
provide common API function and based on the CPU switch would be aware
of the IP inside and make appropriate call to IP driver , Does this
sound like a good approach ?
> Tomi
>
>
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-06-30 17:46 ` K, Mythri P
@ 2011-07-01 8:51 ` Tomi Valkeinen
2011-07-01 9:22 ` K, Mythri P
0 siblings, 1 reply; 34+ messages in thread
From: Tomi Valkeinen @ 2011-07-01 8:51 UTC (permalink / raw)
To: K, Mythri P; +Cc: linux-omap
On Thu, 2011-06-30 at 23:16 +0530, K, Mythri P wrote:
> Hi Tomi,
>
> On Wed, Jun 29, 2011 at 9:51 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi,
> >
> > On Wed, 2011-06-29 at 19:08 +0530, K, Mythri P wrote:
> >> Hi Tomi,
> >
> >> As the HDMI PLL , PHY and video blocks are logical blocks it would
> >> make sense to have the API's for all and the DSS HDMI (interface
> >> driver - user driver) would make a call to configure this in a
> >> particular sequence to enable HDMI , in case you the call to be
> >> generic across OMAPS in future then we should i either have a funtion
> >> in hdmi.c which will do this sequence and will be aware of underlying
> >> IP , Which doesnt appear to be the solution you prefer but then there
> >> would be a need to have an intermediate file which would take the
> >> common API call(function pointer) and then arbitrate between different
> >> IP's based on the make , Is that what you are suggesting ?
> >
> > I agree that they are separate blocks, and at some level they need to be
> > separate with own functions for each. But I don't see why the user needs
> > to know about it.
> >
> > For example, consider OMAP DSI. DSI has protocol, PLL and PHY blocks,
> > and the driver has functions to initialize them, use them etc. But the
> > user of DSI, in this case panel drivers, do not need to know about it,
> > and the API exported to the panel drivers does not contain any functions
> > related to PLL or PHY. The panel drivers just enable the DSI driver and
> > use it.
> >
> > So I'm still asking: what benefit does it give to the user that the API
> > has functions to handle the blocks separately? There has to be a reason
> > for the functions in the API.
> >
> It doesnt give any additional benefit but flexibility to change the
> blocks (PHY / PLL) indivudally to use a different one.
Right. But this API is not the right place to implement that
flexibility. If there's no benefit for the user of the API to know about
the details of the HW, it's better hidden. The user just wants to use
the functionality, not know what lies below.
> >> > And it just occurred to me that perhaps our views of the API are a bit
> >> > different, and that's why we have differing opinions. I see this API as
> >> > something that could be used by OMAP DSS (and equivalent components on
> >> > other SoCs) to use the HDMI HW on OMAP4 and any future OMAPs. And
> >> > perhaps you see this API more as an API to use the current HDMI HW in
> >> > the OMAP4.
> >>
> >> Tomi , Yes my Idea of this API is for OMAP and Netra series only , I
> >> am unable to envision a common HDMI API library , in that case it
> >> would make more sense to have an intermediate file and have function
> >> pointer , which would take common API calls like hdmi_enable ,
> >> hdmi_avi_confg etc and then arbitrate based on the build. Please let
> >> me know if you have anything else in mind.
> >
> > I didn't mean a generic HDMI API either. I meant a TI HDMI API,
> > currently for OMAP and Netra. But my comments would be valid even if the
> > API would be only OMAP DSS internal.
> >
> Neither the HDMI DSS driver should be concerned about these PHY/PLL
> internal API's nor should the configuration be done in the IP driver
> as the IP driver shpuld only provide functionality and should be
> flexible enough as across OMAP4 and netra itself there is a
What configuration are you referring to? I don't think the user of the
API (i.e. omapdss) should do any configuration that requires knowledge
of the underlying HDMI HW.
> possibility of the PHY block being different , so Now the only
> solution i see is to have a intermediate file , whose job is to
> provide common API function and based on the CPU switch would be aware
> of the IP inside and make appropriate call to IP driver , Does this
> sound like a good approach ?
I don't see a need for a separate file right now. We have the
hdmi_ti_4xxx_ip.c file which contains code for the HDMI block as a
whole, and could well contain the code that implements the API.
Tomi
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-07-01 8:51 ` Tomi Valkeinen
@ 2011-07-01 9:22 ` K, Mythri P
2011-07-01 11:44 ` Tomi Valkeinen
0 siblings, 1 reply; 34+ messages in thread
From: K, Mythri P @ 2011-07-01 9:22 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap
Hi Tomi,
On Fri, Jul 1, 2011 at 2:21 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Thu, 2011-06-30 at 23:16 +0530, K, Mythri P wrote:
>> Hi Tomi,
>>
>> On Wed, Jun 29, 2011 at 9:51 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> > Hi,
>> >
>> > On Wed, 2011-06-29 at 19:08 +0530, K, Mythri P wrote:
>> >> Hi Tomi,
>> >
>> >> As the HDMI PLL , PHY and video blocks are logical blocks it would
>> >> make sense to have the API's for all and the DSS HDMI (interface
>> >> driver - user driver) would make a call to configure this in a
>> >> particular sequence to enable HDMI , in case you the call to be
>> >> generic across OMAPS in future then we should i either have a funtion
>> >> in hdmi.c which will do this sequence and will be aware of underlying
>> >> IP , Which doesnt appear to be the solution you prefer but then there
>> >> would be a need to have an intermediate file which would take the
>> >> common API call(function pointer) and then arbitrate between different
>> >> IP's based on the make , Is that what you are suggesting ?
>> >
>> > I agree that they are separate blocks, and at some level they need to be
>> > separate with own functions for each. But I don't see why the user needs
>> > to know about it.
>> >
>> > For example, consider OMAP DSI. DSI has protocol, PLL and PHY blocks,
>> > and the driver has functions to initialize them, use them etc. But the
>> > user of DSI, in this case panel drivers, do not need to know about it,
>> > and the API exported to the panel drivers does not contain any functions
>> > related to PLL or PHY. The panel drivers just enable the DSI driver and
>> > use it.
>> >
>> > So I'm still asking: what benefit does it give to the user that the API
>> > has functions to handle the blocks separately? There has to be a reason
>> > for the functions in the API.
>> >
>> It doesnt give any additional benefit but flexibility to change the
>> blocks (PHY / PLL) indivudally to use a different one.
>
> Right. But this API is not the right place to implement that
> flexibility. If there's no benefit for the user of the API to know about
> the details of the HW, it's better hidden. The user just wants to use
> the functionality, not know what lies below.
>
>> >> > And it just occurred to me that perhaps our views of the API are a bit
>> >> > different, and that's why we have differing opinions. I see this API as
>> >> > something that could be used by OMAP DSS (and equivalent components on
>> >> > other SoCs) to use the HDMI HW on OMAP4 and any future OMAPs. And
>> >> > perhaps you see this API more as an API to use the current HDMI HW in
>> >> > the OMAP4.
>> >>
>> >> Tomi , Yes my Idea of this API is for OMAP and Netra series only , I
>> >> am unable to envision a common HDMI API library , in that case it
>> >> would make more sense to have an intermediate file and have function
>> >> pointer , which would take common API calls like hdmi_enable ,
>> >> hdmi_avi_confg etc and then arbitrate based on the build. Please let
>> >> me know if you have anything else in mind.
>> >
>> > I didn't mean a generic HDMI API either. I meant a TI HDMI API,
>> > currently for OMAP and Netra. But my comments would be valid even if the
>> > API would be only OMAP DSS internal.
>> >
>> Neither the HDMI DSS driver should be concerned about these PHY/PLL
>> internal API's nor should the configuration be done in the IP driver
>> as the IP driver shpuld only provide functionality and should be
>> flexible enough as across OMAP4 and netra itself there is a
>
> What configuration are you referring to? I don't think the user of the
> API (i.e. omapdss) should do any configuration that requires knowledge
> of the underlying HDMI HW.
>
>> possibility of the PHY block being different , so Now the only
>> solution i see is to have a intermediate file , whose job is to
>> provide common API function and based on the CPU switch would be aware
>> of the IP inside and make appropriate call to IP driver , Does this
>> sound like a good approach ?
>
> I don't see a need for a separate file right now. We have the
> hdmi_ti_4xxx_ip.c file which contains code for the HDMI block as a
> whole, and could well contain the code that implements the API.
>
if the hdmi_ti_4xxx_ip.c is handling the configuration then how are
we going to handle a scenario where netra uses a different PHY block ,
you suggest to have a #if in the programming sequence within
hdmi_ti_4xxx_ip.c function ?
Also in future OMAP's when are using the PHY and PLL block from
hdmi_ti_4xxx_ip.c , but a different core/video block from
hdmi_ti_5xxx_ip.c then how would hdmi_ti_5xxx_ip.c hdmi_enable be
able to call the PHY and PLL configuration functions from
hdmi_ti_4xxx_ip.c ??
> Tomi
>
>
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-07-01 9:22 ` K, Mythri P
@ 2011-07-01 11:44 ` Tomi Valkeinen
2011-07-01 12:43 ` K, Mythri P
0 siblings, 1 reply; 34+ messages in thread
From: Tomi Valkeinen @ 2011-07-01 11:44 UTC (permalink / raw)
To: K, Mythri P; +Cc: linux-omap
On Fri, 2011-07-01 at 14:52 +0530, K, Mythri P wrote:
> > I don't see a need for a separate file right now. We have the
> > hdmi_ti_4xxx_ip.c file which contains code for the HDMI block as a
> > whole, and could well contain the code that implements the API.
> >
> if the hdmi_ti_4xxx_ip.c is handling the configuration then how are
> we going to handle a scenario where netra uses a different PHY block ,
I wasn't aware that Netra has different HDMI blocks. I understood it's
the same as on OMAP4.
So they have a different PHY driver, but want to use PLL and core parts
of OMAP4 HDMI driver?
> you suggest to have a #if in the programming sequence within
> hdmi_ti_4xxx_ip.c function ?
No, we can't use #ifdefs as the same kernel has to work for both SoCs.
> Also in future OMAP's when are using the PHY and PLL block from
> hdmi_ti_4xxx_ip.c , but a different core/video block from
> hdmi_ti_5xxx_ip.c then how would hdmi_ti_5xxx_ip.c hdmi_enable be
> able to call the PHY and PLL configuration functions from
> hdmi_ti_4xxx_ip.c ??
If the different HDMI blocks will be mixed like that, then we need to
split the blocks to separate files. Otherwise it will get strange if
OMAP5 HDMI code is calling PLL functions from OMAP4 HDMI code.
And on top of those drivers/libs we would have a higher level driver/lib
for the whole HDMI entity, and this higher level driver would implement
the API being discussed. It would then use the lower level drivers/libs,
and be used by OMAP/Netra DSS.
Tomi
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
2011-07-01 11:44 ` Tomi Valkeinen
@ 2011-07-01 12:43 ` K, Mythri P
0 siblings, 0 replies; 34+ messages in thread
From: K, Mythri P @ 2011-07-01 12:43 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap
Hi Tomi,
On Fri, Jul 1, 2011 at 5:14 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On Fri, 2011-07-01 at 14:52 +0530, K, Mythri P wrote:
>
>> > I don't see a need for a separate file right now. We have the
>> > hdmi_ti_4xxx_ip.c file which contains code for the HDMI block as a
>> > whole, and could well contain the code that implements the API.
>> >
>> if the hdmi_ti_4xxx_ip.c is handling the configuration then how are
>> we going to handle a scenario where netra uses a different PHY block ,
>
> I wasn't aware that Netra has different HDMI blocks. I understood it's
> the same as on OMAP4.
>
> So they have a different PHY driver, but want to use PLL and core parts
> of OMAP4 HDMI driver?
>
That was precisely what i was trying to explain for last few threads :-).
>> you suggest to have a #if in the programming sequence within
>> hdmi_ti_4xxx_ip.c function ?
>
> No, we can't use #ifdefs as the same kernel has to work for both SoCs.
>
>> Also in future OMAP's when are using the PHY and PLL block from
>> hdmi_ti_4xxx_ip.c , but a different core/video block from
>> hdmi_ti_5xxx_ip.c then how would hdmi_ti_5xxx_ip.c hdmi_enable be
>> able to call the PHY and PLL configuration functions from
>> hdmi_ti_4xxx_ip.c ??
>
> If the different HDMI blocks will be mixed like that, then we need to
> split the blocks to separate files. Otherwise it will get strange if
> OMAP5 HDMI code is calling PLL functions from OMAP4 HDMI code.
>
> And on top of those drivers/libs we would have a higher level driver/lib
> for the whole HDMI entity, and this higher level driver would implement
> the API being discussed. It would then use the lower level drivers/libs,
> and be used by OMAP/Netra DSS.
>
Splitting that to multiple would be a file overhead , ie creating a
file to just host 2/3 functions.
Also note it is not OMAP5 HDMI code calling OMAP4 HDMI code , It it no
way in relation to OMAP's as such , so these IP drivers be
provisioning for API's , which the intermediate Arbitration lib / file
which can provide the clean handle to user and can handle the sequence
as to what IP functions should be called.
> Tomi
>
>
>
--
Thanks and regards,
Mythri.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS.
@ 2011-06-22 11:55 Mythri P K
0 siblings, 0 replies; 34+ messages in thread
From: Mythri P K @ 2011-06-22 11:55 UTC (permalink / raw)
To: linux-fbdev
HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
the Display subsytem is different. Thus to reuse the code between these two
processors , HDMI IP dependant code is seperated out from hdmi.c and moved to
new library file hdmi_ti_4xxx_ip.c which now resides in /drivers/video a more
generic location out of omap2/dss folder.
This patch series does the split and also renames hdmi_omap4_panel.c to
hdmi_panel.c as that file has nothing specific to OMAP4 and can be reused for
other OMAP family of processors as well.
This is based on Tomi's DSS pmruntime-v2 branch:
git://gitorious.org/linux-omap-dss2/linux.git
Tree with the patches for verification is available in
http://gitorious.org/~mythripk/linux-omap-dss2/mythripk-linux-lo-dss2/commits/hdmi_pmrumtime
Mythri P K (8):
OMAP4: DSS: HDMI: HDMI clean up to pass base_address dynamically
to IP dependant functions of HDMI
OMAP4 : DSS : HDMI : Move the EDID portion from HDMI IP header
OMAP4: DSS: HDMI: Use specific HDMI timings structure instead of
OMAP DSS timings
OMAP4: DSS: HDMI: Move the common header file definition to
Include/video
OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP specific
portion.
OMAP4: DSS: HDMI: Rename the functions in HDMI IP library to IP
specific name
HDMI: Move HDMI IP Library from OMAP DSS to common Video
directory for IP present in TI OMAP4, TI81xx, TI38xx
Processor
OMAP4: DSS: Rename hdmi_omap4_panel.c to hdmi_panel.c
drivers/video/Kconfig | 7 +
drivers/video/Makefile | 1 +
drivers/video/hdmi_ti_4xxx_ip.c | 803 +++++++++++++++++
drivers/video/hdmi_ti_4xxx_ip.h | 587 +++++++++++++
drivers/video/omap2/dss/Kconfig | 1 +
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss.h | 10 -
drivers/video/omap2/dss/hdmi.c | 919 ++++----------------
drivers/video/omap2/dss/hdmi.h | 631 --------------
.../omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} | 2 +-
include/video/hdmi_ti_4xxx_ip.h | 94 ++
11 files changed, 1641 insertions(+), 1416 deletions(-)
create mode 100644 drivers/video/hdmi_ti_4xxx_ip.c
create mode 100644 drivers/video/hdmi_ti_4xxx_ip.h
delete mode 100644 drivers/video/omap2/dss/hdmi.h
rename drivers/video/omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} (99%)
create mode 100644 include/video/hdmi_ti_4xxx_ip.h
--
1.7.5.4
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2011-07-01 12:43 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-17 8:17 [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS Mythri P K
2011-06-17 8:17 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Mythri P K
2011-06-17 8:17 ` [PATCH 2/8] OMAP4 : DSS : HDMI : Move the EDID portion from HDMI IP Mythri P K
2011-06-17 8:17 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Mythri P K
2011-06-17 8:17 ` [PATCH 4/8] OMAP4: DSS: HDMI: Move the common header file definition Mythri P K
2011-06-17 8:17 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Mythri P K
2011-06-17 8:17 ` [PATCH 6/8] OMAP4: DSS: HDMI: Rename the functions in HDMI IP Mythri P K
2011-06-17 8:17 ` [PATCH 7/8] HDMI: Move HDMI IP Library from OMAP DSS to common Mythri P K
2011-06-17 8:17 ` [PATCH 8/8] OMAP4: DSS: Rename hdmi_omap4_panel.c to hdmi_panel.c Mythri P K
2011-06-20 13:48 ` [PATCH 5/8] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP Premi, Sanjeev
2011-06-23 5:55 ` K, Mythri P
2011-06-20 12:46 ` [PATCH 3/8] OMAP4: DSS: HDMI: Use specific HDMI timings structure Premi, Sanjeev
2011-06-23 5:45 ` K, Mythri P
2011-06-23 8:30 ` Tomi Valkeinen
2011-06-23 8:46 ` K, Mythri P
2011-06-20 13:33 ` [PATCH 1/8] OMAP4: DSS: HDMI: HDMI clean up to pass base_address Premi, Sanjeev
2011-06-23 5:51 ` K, Mythri P
2011-06-23 10:30 ` Premi, Sanjeev
2011-06-23 11:00 ` K, Mythri P
2011-06-23 11:03 ` Premi, Sanjeev
2011-06-23 11:09 ` K, Mythri P
2011-06-23 9:58 ` [PATCH 0/8] HDMI: Split hdmi.c to seperate HDMI IP dependant code from DSS Tomi Valkeinen
2011-06-23 12:05 ` K, Mythri P
2011-06-23 12:31 ` Tomi Valkeinen
2011-06-27 5:51 ` K, Mythri P
2011-06-27 12:58 ` Tomi Valkeinen
2011-06-29 13:38 ` K, Mythri P
2011-06-29 16:21 ` Tomi Valkeinen
2011-06-30 17:46 ` K, Mythri P
2011-07-01 8:51 ` Tomi Valkeinen
2011-07-01 9:22 ` K, Mythri P
2011-07-01 11:44 ` Tomi Valkeinen
2011-07-01 12:43 ` K, Mythri P
2011-06-22 11:55 Mythri P K
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.