[PATCH v2 06/10] OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP
From: 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
---
drivers/video/omap2/dss/Makefile |2 +-
drivers/video/omap2/dss/hdmi.c | 737 ---
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 770
.../video/omap2/dss/{hdmi.h => hdmi_ti_4xxx_ip.h} |9 +-
include/video/omaphdmi.h |7 +
5 files changed, 783 insertions(+), 742 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..3ffe98f 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_omap4_panel.o hdmi_ti_4xxx_ip.o
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index e9e07e2..8baf4cf 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_WP0x0
@@ -161,56 +160,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 ip_data->base_wp;
-}
-
-static inline void __iomem *hdmi_phy_base(struct hdmi_ip_data *ip_data)
-{
- return ip_data->base_wp + ip_data->phy_offset;
-}
-
-static inline void __iomem *hdmi_pll_base(struct hdmi_ip_data *ip_data)
-{
- return ip_data->base_wp + ip_data->pll_offset;
-}
-
-static inline void __iomem *hdmi_av_base(struct hdmi_ip_data *ip_data)
-{
- return ip_data->base_wp + ip_data->core_av_offset;
-}
-
-static inline void __iomem *hdmi_core_sys_base(struct hdmi_ip_data *ip_data)
-{
- return ip_data->base_wp + ip_data->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++ > 1)
- return !val;
- }
- return val;
-}
-
static int hdmi_runtime_get(void)
{
int r;
@@ -239,315 +188,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)
-{
- u32 r;
- void __iomem *pll_base = hdmi_pll_base(ip_data);
- struct hdmi_pll_info *fmt = &ip_data->pll_data;
-
- /* PLL start always use manual mode */
- REG_FLD_MOD(pll_base, PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
-
- r = hdmi_read_reg(pll_base, 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(pll_base, PLLCTRL_CFG1, r);
-
- r = hdmi_read_reg(pll_base, 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 (fmt->dcofreq) {
- /* divider programming for frequency beyond 1000Mhz */
- REG_FLD_MOD(pll_base, PLLCTRL_CFG3, fmt->regsd, 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(pll_base, PLLCTRL_CFG2, r);
-
- r = hdmi_read_reg(pll_base, PLLCTRL_CFG4);
- r = FLD_MOD(r, fmt->regm2, 24, 18);
- r = FLD_MOD(r, fmt->regmf, 17, 0);
-
- hdmi_write_reg(pll_base, PLLCTRL_CFG4, r);
-
- /* go now */
- REG_FLD_MOD(pll_base, PLLCTRL_PLL_GO, 0x1, 0, 0);
-
- /* wait for bit change */
- if (hdmi_wait_for_bit_change(pll_base, PLLCTRL_PLL_GO,
- 0, 0, 1) != 1) {
- DSSERR("PLL GO bit not set\n");
- return -ETIMEDOUT;
- }
-
[PATCH v2 10/10] OMAP4: DSS: Rename hdmi_omap4_panel.c to hdmi_panel.c
From: 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
---
drivers/video/omap2/dss/Makefile |2 +-
.../omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename drivers/video/omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} (100%)
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 3ffe98f..5fd9ed4 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_ti_4xxx_ip.o
+ hdmi_panel.o hdmi_ti_4xxx_ip.o
diff --git a/drivers/video/omap2/dss/hdmi_omap4_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
similarity index 100%
rename from drivers/video/omap2/dss/hdmi_omap4_panel.c
rename to drivers/video/omap2/dss/hdmi_panel.c
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/10] OMAP4: DSS2: HDMI: Function pointer approach to call
From: Mythri P K
To make the current hdmi DSS driver compatible with future OMAP with different
IP blocks , add HDMI as a feature in dss_features and abstract the internal
function in hdmi dss driver.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/dss_features.c | 24 +++-
drivers/video/omap2/dss/dss_features.h |1 +
drivers/video/omap2/dss/hdmi.c | 22 +++---
include/video/omapdss.h| 19 +++
include/video/omaphdmi.h |1 +
5 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index b63c5f8..edf2929 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -429,6 +429,26 @@ static const struct omap_dss_features omap4_dss_features =
{
.burst_size_unit = 16,
};
+const struct omap_hdmi_ip_driver *omap_hdmi_functions;
+
+/* HDMI OMAP4 Functions*/
+const struct omap_hdmi_ip_driver omap4_hdmi_functions = {
+
+ .video_configure= hdmi_basic_configure,
+ .phy_enable = hdmi_phy_enable,
+ .phy_disable= hdmi_phy_disable,
+ .read_edid = read_edid,
+ .pll_enable = hdmi_pll_enable,
+ .pll_disable= hdmi_pll_disable,
+ .video_enable = hdmi_wp_video_start,
+};
+
+void dss_hdmi_features_init(struct hdmi_ip_data *ip_data)
+{
+ if (cpu_is_omap44xx())
+ ip_data->hdmi_ops = &omap4_hdmi_functions;
+}
+
/* Functions returning values related to a DSS feature */
int dss_feat_get_num_mgrs(void)
{
@@ -512,8 +532,10 @@ void dss_features_init(void)
omap_current_dss_features = &omap3430_dss_features;
else if (omap_rev() == OMAP4430_REV_ES1_0)
omap_current_dss_features = &omap4430_es1_0_dss_features;
- else if (cpu_is_omap44xx())
+ else if (cpu_is_omap44xx()) {
omap_current_dss_features = &omap4_dss_features;
+ omap_hdmi_functions = &omap4_hdmi_functions;
+ }
else
DSSWARN("Unsupported OMAP version");
}
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index 4271e96..ca64b21 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -99,4 +99,5 @@ u32 dss_feat_get_burst_size_unit(void); /* in
bytes */
bool dss_has_feature(enum dss_feat_id id);
void dss_feat_get_reg_field(enum dss_feat_reg_field id, u8 *start, u8 *end);
void dss_features_init(void);
+void dss_hdmi_features_init(struct hdmi_ip_data *ip_data);
#endif
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index fb7d66f..c508cf6 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -184,7 +184,7 @@ static void hdmi_runtime_put(void)
int hdmi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG("init_display\n");
-
+ dss_hdmi_features_init(&hdmi.hdmi_data);
return 0;
}
@@ -364,8 +364,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.hdmi_data, hdmi.edid,
- HDMI_EDID_MAX_LENGTH);
+ ret = hdmi.hdmi_data.hdmi_ops->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 */
@@ -475,16 +475,16 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi_compute_pll(dssdev, phy, &hdmi.hdmi_data.pll_data);
- hdmi_wp_video_start(&hdmi.hdmi_data, 0);
+ hdmi.hdmi_data.hdmi_ops->video_enable(&hdmi.hdmi_data, 0);
/* config the PLL and PHY hdmi_set_pll_pwrfirst */
- r = hdmi_pll_enable(&hdmi.hdmi_data);
+ r = hdmi.hdmi_data.hdmi_ops->pll_enable(&hdmi.hdmi_data);
if (r) {
DSSDBG("Failed to lock PLL\n");
goto err;
}
- r = hdmi_phy_enable(&hdmi.hdmi_data);
+ r = hdmi.hdmi_data.hdmi_ops->phy_enable(&hdmi.hdmi_data);
if (r) {
DSSDBG("Failed to start PHY\n");
goto err;
@@ -492,7 +492,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi.hdmi_data.cfg.cm.mode = hdmi.mode;
hdmi.hdmi_data.cfg.cm.code = hdmi.code;
- hdmi_basic_configure(&hdmi.hdmi_data);
+ hdmi.hdmi_data.hdmi_ops->video_configure(&hdmi.hdmi_data);
/* Make selection of HDMI in DSS */
dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
@@ -514,7 +514,7 @@ static int hdmi_power_on(struct omap_dss_device *dss
[PATCH v2 09/10] MAP4: DSS: HDMI: Rename the functions in HDMI IP
From: 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
---
drivers/video/omap2/dss/dss_features.c| 14 +++---
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 15 ---
include/video/omaphdmi.h | 15 ---
3 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index edf2929..c1ef0d6 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -434,13 +434,13 @@ const struct omap_hdmi_ip_driver *omap_hdmi_functions;
/* HDMI OMAP4 Functions*/
const struct omap_hdmi_ip_driver omap4_hdmi_functions = {
- .video_configure= hdmi_basic_configure,
- .phy_enable = hdmi_phy_enable,
- .phy_disable= hdmi_phy_disable,
- .read_edid = read_edid,
- .pll_enable = hdmi_pll_enable,
- .pll_disable= hdmi_pll_disable,
- .video_enable = hdmi_wp_video_start,
+ .video_configure= hdmi_ti_4xxx_basic_configure,
+ .phy_enable = hdmi_ti_4xxx_phy_enable,
+ .phy_disable= hdmi_ti_4xxx_phy_disable,
+ .read_edid = hdmi_ti_4xxx_read_edid,
+ .pll_enable = hdmi_ti_4xxx_pll_enable,
+ .pll_disable= hdmi_ti_4xxx_pll_disable,
+ .video_enable = hdmi_ti_4xxx_wp_video_start,
};
void dss_hdmi_features_init(struct hdmi_ip_data *ip_data)
diff --git a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
index f64e06c..3ce99b0 100644
--- a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
+++ b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
@@ -194,7 +194,7 @@ static int hdmi_pll_reset(struct hdmi_ip_data *ip_data)
return 0;
}
-int hdmi_pll_enable(struct hdmi_ip_data *ip_data)
+int hdmi_ti_4xxx_pll_enable(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
@@ -220,12 +220,12 @@ int hdmi_pll_enable(struct hdmi_ip_data *ip_data)
return 0;
}
-void hdmi_pll_disable(struct hdmi_ip_data *ip_data)
+void hdmi_ti_4xxx_pll_disable(struct hdmi_ip_data *ip_data)
{
hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
}
-int hdmi_phy_enable(struct hdmi_ip_data *ip_data)
+int hdmi_ti_4xxx_phy_enable(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
void __iomem *phy_base = hdmi_phy_base(ip_data);
@@ -262,7 +262,7 @@ int hdmi_phy_enable(struct hdmi_ip_data *ip_data)
return 0;
}
-void hdmi_phy_disable(struct hdmi_ip_data *ip_data)
+void hdmi_ti_4xxx_phy_disable(struct hdmi_ip_data *ip_data)
{
hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
}
@@ -368,7 +368,8 @@ 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 hdmi_ti_4xxx_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;
@@ -621,7 +622,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);
}
@@ -688,7 +689,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)
{
/* HDMI */
struct omap_video_timings video_timing;
diff --git a/include/video/omaphdmi.h b/include/video/omaphdmi.h
index a740237..9548284 100644
--- a/include/video/omaphdmi.h
+++ b/include/video/omaphdmi.h
@@ -84,11 +84,12 @@ struct hdmi_ip_data {
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
};
-int hdmi_phy_enable(struct hdmi_ip_data *ip_data);
-void hdmi_phy_disable(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_enable(struct hdmi_ip_data *ip_data);
-void hdmi_pll_disable(struct hdmi_ip_data *ip_data);
-void hdmi_basic_configure(struct hdmi_ip_data *ip_data);
+int hdmi_ti_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
+void hdmi_ti_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
+int hdmi_ti_4xxx_read_edid(struct hdmi_ip_data *ip_data,
+
[PATCH v2 01/10] OMAP4: DSS: HDMI: HDMI clean up to pass base_address
From: 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
---
drivers/video/omap2/dss/hdmi.c | 501 +++-
drivers/video/omap2/dss/hdmi.h | 292
2 files changed, 435 insertions(+), 358 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index b8e02e4..544f93e 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_WP0x0
+#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];
@@ -145,21 +151,49 @@ 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 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 ip_data->base_wp + ip_data->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 ip_data->base_wp + ip_data->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 ip_data->base_wp + ip_data->core_av_offset;
+}
+
+static inline void __iomem *hdmi_core_sys_base(struct hdmi_ip_data *ip_data)
+{
+ return ip_data->base_wp + ip_data->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++ > 1)
return !val;
@@ -195,21 +229,23 @@ 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;
+ void __iomem *pll_base = hdmi_pll_base(ip_data);
/* PLL start always use manual mode */
- REG_FLD_MOD(PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
+ REG_FLD_MOD(pll_base, PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
- r = hdmi_read_reg(PLLCTRL_CFG1);
+ r = hdmi_read_reg(pll_base, 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(pll_base, PLLCTRL_CFG1, r);
- r = hdmi_read_reg(PLLCTRL_CFG2);
+ r = hdmi_read_reg(pll_base, PLLCTRL_CFG2);
r = FLD_MOD(r, 0x0, 12, 12); /* PLL_HIGHFREQ divide by 2 */
r = FLD_MOD(r, 0x1, 13, 13); /* PLL_REFEN */
@@ -217,38 +253,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(pll_base, 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(pll_base, PLLCTRL_CFG2, r);
- r = hdmi_read_reg(PLLCTRL_CFG4);
+ r = hdmi_read_reg(pll_base, 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(p
[PATCH v2 07/10] OMAP4: DSS2: HDMI: Provide a wrapper API to configure
From: Mythri P K
Instead of DSS knowing of the interior IP driver function provide
a wrapper API to configure.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/hdmi.c|8
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 11 ---
include/video/omaphdmi.h |8
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 8baf4cf..fb7d66f 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -478,13 +478,13 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi_wp_video_start(&hdmi.hdmi_data, 0);
/* config the PLL and PHY hdmi_set_pll_pwrfirst */
- r = hdmi_pll_program(&hdmi.hdmi_data);
+ r = hdmi_pll_enable(&hdmi.hdmi_data);
if (r) {
DSSDBG("Failed to lock PLL\n");
goto err;
}
- r = hdmi_phy_init(&hdmi.hdmi_data);
+ r = hdmi_phy_enable(&hdmi.hdmi_data);
if (r) {
DSSDBG("Failed to start PHY\n");
goto err;
@@ -527,8 +527,8 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
dispc_mgr_enable(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_phy_disable(&hdmi.hdmi_data);
+ hdmi_pll_disable(&hdmi.hdmi_data);
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 a582522..f64e06c 100644
--- a/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
+++ b/drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
@@ -194,7 +194,7 @@ 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_pll_enable(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
@@ -220,7 +220,12 @@ int hdmi_pll_program(struct hdmi_ip_data *ip_data)
return 0;
}
-int hdmi_phy_init(struct hdmi_ip_data *ip_data)
+void hdmi_pll_disable(struct hdmi_ip_data *ip_data)
+{
+ hdmi_set_pll_pwr(ip_data, HDMI_PLLPWRCMD_ALLOFF);
+}
+
+int hdmi_phy_enable(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
void __iomem *phy_base = hdmi_phy_base(ip_data);
@@ -257,7 +262,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_phy_disable(struct hdmi_ip_data *ip_data)
{
hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
}
diff --git a/include/video/omaphdmi.h b/include/video/omaphdmi.h
index 9d4bc36..88b1ccb 100644
--- a/include/video/omaphdmi.h
+++ b/include/video/omaphdmi.h
@@ -83,11 +83,11 @@ struct hdmi_ip_data {
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
};
-int hdmi_phy_init(struct hdmi_ip_data *ip_data);
-void hdmi_phy_off(struct hdmi_ip_data *ip_data);
+int hdmi_phy_enable(struct hdmi_ip_data *ip_data);
+void hdmi_phy_disable(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_set_pll_pwr(struct hdmi_ip_data *ip_data, enum hdmi_pll_pwr val);
+int hdmi_pll_enable(struct hdmi_ip_data *ip_data);
+void hdmi_pll_disable(struct hdmi_ip_data *ip_data);
void hdmi_basic_configure(struct hdmi_ip_data *ip_data);
#endif
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/10] OMAP4: DSS: HDMI: Move the common header file
From: 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
---
drivers/video/omap2/dss/dss.h | 10 -
drivers/video/omap2/dss/hdmi.c |1 +
drivers/video/omap2/dss/hdmi.h | 53
include/video/omaphdmi.h | 86
4 files changed, 87 insertions(+), 63 deletions(-)
create mode 100644 include/video/omaphdmi.h
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index a095a62..7c9565f 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -150,16 +150,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 ba1ad06..39d1a7e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
#include
diff --git a/drivers/video/omap2/dss/hdmi.h b/drivers/video/omap2/dss/hdmi.h
index 7046ff3..0a3342b 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi.h
@@ -198,39 +198,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,
@@ -266,11 +239,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,
@@ -571,27 +539,6 @@ struct hdmi_video_interface {
int tm; /* Timing mode */
};
-struct hdmi_cm {
- int code;
- int mode;
-};
-
-struct hdmi_config {
- struct hdmi_timings timings;
- u16 interlace;
- struct hdmi_cm cm;
-};
-
-struct hdmi_ip_data {
- void __iomem*base_wp; /* HDMI wrapper */
- unsigned long core_sys_offset;
- unsigned long core_av_offset;
- unsigned long pll_offset;
- unsigned long phy_offset;
- struct hdmi_config cfg;
- struct hdmi_pll_info pll_data;
-};
-
struct hdmi_audio_format {
enum hdmi_stereo_channels stereo_channels;
u8 active_chnnls_msk;
diff --git a/include/video/omaphdmi.h b/include/video/omaphdmi.h
new file mode 100644
index 000..bd51529
--- /dev/null
+++ b/include/video/omaphdmi.h
@@ -0,0 +1,86 @@
+/*
+ * omaphdmi.h
+ *
+ * HDMI driver definition for TI OMAP4, DM81xx, DM38xx 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
[PATCH v2 05/10] OMAP4 : DSS : HDMI : Move the EDID portion from HDMI
From: 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
---
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 39d1a7e..e9e07e2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -50,6 +50,16 @@
#define HDMI_PLLCTRL 0x200
#define HDMI_PHY 0x300
+/* HDMI EDID Length move this */
+#define HDMI_EDID_MAX_LENGTH 256
+#define EDID_TIMING_DESCRIPTOR_SIZE0x12
+#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 0a3342b..4b0fab3 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_CTRLHDMI_REG(0xC)
-/* HDMI EDID Length */
-#define HDMI_EDID_MAX_LENGTH 256
-#define EDID_TIMING_DESCRIPTOR_SIZE0x12
-#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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/10] OMAP4: DSS: HDMI: Move pll and video configuration
From: Mythri P K
As the pll and the video configuration info are part of the ip_data those
structures are moved to the ip_data strtucure.Also the functions are modified
accordingly to take care of this movement.
Signed-off-by: Mythri P K
---
drivers/video/omap2/dss/hdmi.c | 34 +++---
drivers/video/omap2/dss/hdmi.h | 18 ++
2 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 544f93e..084a47e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -59,7 +59,6 @@ static struct {
u8 edid[HDMI_EDID_MAX_LENGTH];
u8 edid_set;
bool custom_set;
- struct hdmi_config cfg;
struct clk *sys_clk;
} hdmi;
@@ -230,11 +229,11 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
}
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)
+ enum hdmi_clk_refsel refsel)
{
u32 r;
void __iomem *pll_base = hdmi_pll_base(ip_data);
+ struct hdmi_pll_info *fmt = &ip_data->pll_data;
/* PLL start always use manual mode */
REG_FLD_MOD(pll_base, PLLCTRL_PLL_CONTROL, 0x0, 0, 0);
@@ -251,9 +250,9 @@ static int hdmi_pll_init(struct hdmi_ip_data *ip_data,
r = FLD_MOD(r, 0x1, 13, 13); /* PLL_REFEN */
r = FLD_MOD(r, 0x0, 14, 14); /* PHY_CLKINEN de-assert during locking */
- if (dcofreq) {
+ if (fmt->dcofreq) {
/* divider programming for frequency beyond 1000Mhz */
- REG_FLD_MOD(pll_base, PLLCTRL_CFG3, sd, 17, 10);
+ REG_FLD_MOD(pll_base, PLLCTRL_CFG3, fmt->regsd, 17, 10);
r = FLD_MOD(r, 0x4, 3, 1); /* 1000MHz and 2000MHz */
} else {
r = FLD_MOD(r, 0x2, 3, 1); /* 500MHz and 1000MHz */
@@ -379,8 +378,7 @@ static int hdmi_phy_init(struct hdmi_ip_data *ip_data)
return 0;
}
-static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
- struct hdmi_pll_info *fmt)
+static int hdmi_pll_program(struct hdmi_ip_data *ip_data)
{
u16 r = 0;
enum hdmi_clk_refsel refsel;
@@ -399,7 +397,7 @@ static int hdmi_pll_program(struct hdmi_ip_data *ip_data,
refsel = HDMI_REFSEL_SYSCLK;
- r = hdmi_pll_init(ip_data, refsel, fmt->dcofreq, fmt, fmt->regsd);
+ r = hdmi_pll_init(ip_data, refsel);
if (r)
return r;
@@ -1015,8 +1013,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);
}
-static void hdmi_basic_configure(struct hdmi_ip_data *ip_data,
- struct hdmi_config *cfg)
+static void hdmi_basic_configure(struct hdmi_ip_data *ip_data)
{
/* HDMI */
struct omap_video_timings video_timing;
@@ -1026,6 +1023,7 @@ static void hdmi_basic_configure(struct hdmi_ip_data
*ip_data,
struct hdmi_core_infoframe_avi avi_cfg;
struct hdmi_core_video_config v_core_cfg;
struct hdmi_core_packet_enable_repeat repeat_cfg;
+ struct hdmi_config *cfg = &ip_data->cfg;
hdmi_wp_init(&video_timing, &video_format,
&video_interface);
@@ -1034,8 +1032,7 @@ static void hdmi_basic_configure(struct hdmi_ip_data
*ip_data,
&avi_cfg,
&repeat_cfg);
- hdmi_wp_video_init_format(&video_format,
- &video_timing, cfg);
+ hdmi_wp_video_init_format(&video_format, &video_timing, cfg);
hdmi_wp_video_config_timing(ip_data, &video_timing);
@@ -1161,7 +1158,6 @@ static void hdmi_compute_pll(struct omap_dss_device
*dssdev, int phy,
static int hdmi_power_on(struct omap_dss_device *dssdev)
{
int r, code = 0;
- struct hdmi_pll_info pll_data;
struct omap_video_timings *p;
unsigned long phy;
@@ -1183,16 +1179,16 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
}
code = get_timings_index();
dssdev->panel.timings = cea_vesa_timings[code].timings;
- update_hdmi_timings(&hdmi.cfg, p, code);
+ update_hdmi_timings(&hdmi.hdmi_data.cfg, p, code);
phy = p->pixel_clock;
- hdmi_compute_pll(dssdev, phy, &pll_data);
+ hdmi_compute_pll(dssdev, phy, &hdmi.hdmi_data.pll_data);
hdmi_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_pll_program(&hdmi.hdmi_data);
if (r) {
DSSDBG("Failed to lock PLL\n");
goto err;
@@ -1204,9 +1200,9 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
goto err;
}
- hdmi.cfg.cm.mode = hdmi.mode;
- hdmi.cfg.cm.code = hdmi.code;
-
[PATCH v2 03/10] OMAP4: DSS: HDMI: Use specific HDMI timings structure
From: 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
---
drivers/video/omap2/dss/hdmi.c | 22 +++---
drivers/video/omap2/dss/hdmi.h | 15 ++-
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 084a47e..ba1ad06 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -537,6 +537,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;
@@ -561,7 +575,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");
@@ -719,7 +733,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,
@@ -1178,7 +1193,8 @@ 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.hdmi_data.cfg, p, code);
phy = p->pixel_clock;
diff --git a/drivers/video/omap2/dss/hdmi.h b/drivers/video/omap2/dss/hdmi.h
index c0f4c2a..7046ff3 100644
--- a/drivers/video/omap2/dss/hdmi.h
+++ b/drivers/video/omap2/dss/hdmi.h
@@ -198,9 +198,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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/10]HDMI: Split hdmi.c in DSS to seperate OMAP dependent
From: Mythri P K
HDMI IP block is common between TI OMAP4 Procerssor and Netra processor although
the Display subsytem is different.Also the IP block in future OMAP may differ
from the one existing in OMAP4. Thus to reuse the code between these two
processors , and maintain the multi omap build functionality in DSS.
HDMI IP dependant code is seperated out from hdmi.c and moved to
new library file hdmi_ti_4xxx_ip.c.From the DSS dependent HDMI code only the
function pointer to functionality/features offered by HDMI is called.
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 patch series is based on Tomi's LO-DSS2 master branch.
changes since V1: Function pointer approach to call the HDMI IP functions from
DSS HDMI
Mythri P K (10):
OMAP4: DSS: HDMI: HDMI clean up to pass base_address dynamically
to IP dependant functions of HDMI
OMAP4: DSS: HDMI: Move pll and video configuration info to ip_data
structure
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 : DSS : HDMI : Move the EDID portion from HDMI IP header
OMAP4: DSS2: HDMI: Split the HDMI driver to DSS and IP
specific portion.
OMAP4: DSS2: HDMI: Provide a wrapper API to configure PLL and
PHY configuration
OMAP4: DSS2: HDMI: Function pointer approach to call HDMI IP
driver function from DSS
MAP4: DSS: HDMI: Rename the functions in HDMI IP library to IP
specific name
OMAP4: DSS: Rename hdmi_omap4_panel.c to hdmi_panel.c
drivers/video/omap2/dss/Makefile |2 +-
drivers/video/omap2/dss/dss.h | 10 -
drivers/video/omap2/dss/dss_features.c | 24 +-
drivers/video/omap2/dss/dss_features.h |1 +
drivers/video/omap2/dss/hdmi.c | 925 +++-
drivers/video/omap2/dss/hdmi.h | 631 -
.../omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} |0
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c | 776
drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h | 582
include/video/omapdss.h| 19 +
include/video/omaphdmi.h | 95 ++
11 files changed, 1642 insertions(+), 1423 deletions(-)
delete mode 100644 drivers/video/omap2/dss/hdmi.h
rename drivers/video/omap2/dss/{hdmi_omap4_panel.c => hdmi_panel.c} (100%)
create mode 100644 drivers/video/omap2/dss/hdmi_ti_4xxx_ip.c
create mode 100644 drivers/video/omap2/dss/hdmi_ti_4xxx_ip.h
create mode 100644 include/video/omaphdmi.h
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/6] usb: musb: Add support for ti81xx platform
Hi, > On Fri, Aug 26, 2011 at 04:41:48PM +0530, Ajay Kumar Gupta wrote: > > @@ -57,6 +58,10 @@ config USB_MUSB_AM35X > > tristate "AM35x" > > depends on ARCH_OMAP > > > > +config USB_MUSB_TI81XX > > + bool "TI81XX" > > + depends on SOC_OMAPTI81XX > > this *must* be tristate. I can't emphasize enough how important this > is. Ok. > > > diff --git a/drivers/usb/musb/musb_core.c > > b/drivers/usb/musb/musb_core.c index 20a2873..07f3faf 100644 > > --- a/drivers/usb/musb/musb_core.c > > +++ b/drivers/usb/musb/musb_core.c > > @@ -1014,7 +1014,9 @@ static void musb_shutdown(struct > platform_device *pdev) > > || defined(CONFIG_USB_MUSB_OMAP2PLUS) \ > > || defined(CONFIG_USB_MUSB_OMAP2PLUS_MODULE)\ > > || defined(CONFIG_USB_MUSB_AM35X) \ > > - || defined(CONFIG_USB_MUSB_AM35X_MODULE) > > + || defined(CONFIG_USB_MUSB_AM35X_MODULE)\ > > + || defined(CONFIG_USB_MUSB_TI81XX) \ > > + || defined(CONFIG_USB_MUSB_TI81XX_MODULE) > > we really need to find a better way to handle this :-( How about passing the mode info from musb_config (musb->config->fifo_mode), same way as musb->config->fifo_cfg Infact I think, we can kill musb->config->fifo_cfg and have only musb->config->mode as in this way all the fifo tables will be at one place and should help in maintenance. > > > diff --git a/drivers/usb/musb/ti81xx.c b/drivers/usb/musb/ti81xx.c > new > > file mode 100644 index 000..f95774e > > --- /dev/null > > +++ b/drivers/usb/musb/ti81xx.c > > I still think this should be part of am35x.c It really look like they > are very similar. Wrapper registers are different but I will see on this and provide you details On how the merged file would look like. I am afraid that we may have to use Either #ifdef or cpu_is_xxx(). > > on monday I'll read the rest of the file. Ok. Ajay > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] OMAP3+ Clock Fixes
Hi Jon, On Thu, 7 Jul 2011, Jon Hunter wrote: > Various clock fixes for OMAP3 and OMAP4 devices. Just doublechecking on these patches, some of them don't have Signed-off-by:'s from you. Seems like we should add those? best regards, - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] OMAP4: Add missing clock divider for OCP_ABE_ICLK
Hi Benoît, Jon,
On Wed, 27 Jul 2011, Cousson, Benoit wrote:
> On 7/15/2011 4:34 PM, Hunter, Jon wrote:
> > On 7/15/2011 3:21, Paul Walmsley wrote:
> > > On Thu, 14 Jul 2011, Jon Hunter wrote:
> > >
> > > > From: Jon Hunter
> > > >
> > > > The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
> > > > parent clock of the AESS_FCLK is the ABE_FCLK...
> > > >
> > > > ABE_FCLK --> AESS_FCLK --> OCP_ABE_ICLK
> > > >
> > > > The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
> > > > determine their operational frequency. However, the dividers for
> > > > the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
> > > > which is the CM1_ABE_AESS_CLKCTRL[24] bit.> When this bit is set to
> > > > 0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
> > > > Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
> > > > and the OCP_ABE_ICLK is 1.
> > >
> > > Sigh. This type of hardware design makes software design difficult :-(
> >
> > Hopefully, because this is a interface clock the impact is really
> > minimal...more below...
> >
> > > > The above relationship between the AESS_FCLK and OCP_ABE_ICLK
> > > > dividers ensure that the OCP_ABE_ICLK clock is always half the
> > > > frequency of the ABE_CLK...
> > > >
> > > > OCP_ABE_ICLK = ABE_FCLK/2
> > > >
> > > > The divider for the OCP_ABE_ICLK is currently missing so add a
> > > > divider that will ensure the OCP_ABE_ICLK frequency is always half
> > > > the ABE_FCLK frequency.
> > > >
> > > > Signed-off-by: Jon Hunter
> > > > ---
> > > >arch/arm/mach-omap2/clock44xx_data.c | 16 +++-
> > > >1 files changed, 15 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-omap2/clock44xx_data.c
> > > > b/arch/arm/mach-omap2/clock44xx_data.c
> > > > index 8c96567..6e158ce 100644
> > > > --- a/arch/arm/mach-omap2/clock44xx_data.c
> > > > +++ b/arch/arm/mach-omap2/clock44xx_data.c
> > > > @@ -1301,11 +1301,25 @@ static struct clk mcasp3_fclk = {
> > > > .recalc =&followparent_recalc,
> > > >};
> > > >
> > > > +static const struct clksel_rate div2_2to1_rates[] = {
> > > > + { .div = 1, .val = 1, .flags = RATE_IN_4430 },
> > > > + { .div = 2, .val = 0, .flags = RATE_IN_4430 },
> > > > + { .div = 0 },
> > > > +};
> > > > +
> > > > +static const struct clksel ocp_abe_iclk_div[] = {
> > > > + { .parent =&aess_fclk, .rates = div2_2to1_rates },
> > > > + { .parent = NULL },
> > > > +};
> > > > +
> > > >static struct clk ocp_abe_iclk = {
> > > > .name = "ocp_abe_iclk",
> > > > .parent =&aess_fclk,
> > > > + .clksel = ocp_abe_iclk_div,
> > > > + .clksel_reg = OMAP4430_CM1_ABE_AESS_CLKCTRL,
> > > > + .clksel_mask= OMAP4430_CLKSEL_AESS_FCLK_MASK,
> > > > .ops=&clkops_null,
> > > > - .recalc =&followparent_recalc,
> > > > + .recalc =&omap2_clksel_recalc,
> > > >};
> > > >
> > > >static struct clk per_abe_24m_fclk = {
> > >
> > > I guess the reason that this patch can get away with this is because it
> > > doesn't allow software to change the rate of ocp_abe_iclk, and the
> > > ocp_abe_iclk is a child of aess_fclk, so when aess_fclk is changed, it
> > > will recalc ocp_abe_iclk.
> > >
> > > Benoît, what do you think? Is this a reasonable approach for the script?
> > > Or do we need to deal with some kind of 'linked clock' implementation...
> >
> > If you want my two cents on this matter, I would say that...
> >
> > 1). People should not need to configure the "ocp_abe_iclk" clock
> > directly, because regardless of the divider setting it is always 1/2 the
> > "abe_fclk". In other words, only the "aess_fclk" frequency is really
> > changing because of the divider and the above relationship ensures that
> > the "ocp_abe_iclk" is always the same frequency. So a user only cares
> > about the "aess_fclk" frequency and the "ocp_abe_iclk" frequency is
> > handled for them.
> >
> > 2). The "ocp_abe_iclk" is an interface clock and is not a parent to any
> > other functional clock and therefore, is not driving any internal logic
> > in a peripheral which would have a direct impact of the speed of that
> > peripheral.
>
> Since both dividers are linked, I exposed only one to SW on purpose to avoid
> conflict and confusion.
> As you said, we should and can only take care of the intermediate clock node.
>
> The only drawback of not linking both nodes is that the clock rate of the
> ocp_abe_iclk will be wrong if the parent clksel is changed.
> So if the recalc is working well your patch should fix that.
>
> My only concern is to find a way to generate that kind of hacky clock node:-(
>
> > However, there does appear to be another bug here in the
> > clock44xx_data.c as it shows that the "ocp_abe_iclk" is parent to the
> > "slimbus1_fck" which I believe is incorrect. According to the TRM, the
> > the ocp_abe_iclk i
Re: How to handle named resources with DT?
Hi, one case that I forgot to mention: On Sun, 28 Aug 2011, Paul Walmsley wrote: > Several upstream device drivers get their DMA request line IDs from the > device data format[14][15][16]. But more drivers should be doing this > than currently are[17]: > > - the device driver author may have hardcoded the DMA request line ID, > assuming it would never change > > - DMA could be broken on the device due to hardware bugs, so it is unused > > - the driver author may just never have gotten around to implementing DMA, > or was reassigned to another project, or couldn't figure it out > > - the device may have its own internal DMA controller logic, so support > for an external DMA controller was simply never added - the driver may be using software-initiated DMA, which doesn't use a DMA request line, nor does it rely on the device to start or stop DMA. Instead, the CPU reprograms the DMA controller when the driver receives an interrupt - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: fix update qtd->token in qh_append_tds
On Mon, 29 Aug 2011, Russell King - ARM Linux wrote: > On Sun, Aug 28, 2011 at 01:00:07PM -0400, Alan Stern wrote: > > It won't do that. All it will do is guarantee that the CPU writes out > > dumy->hw_token before it writes out or reads in any values executed > > after the mb. > > You're right from the perspective of how things are defined today. However, > that isn't how things work on ARM. > > With ARMv6 and ARMv7, we have weak memory ordering. This includes so > called "DMA coherent" memory. This means that the architecture does not > guarantee the order of writes to DMA coherent memory (which is non- > cacheable normal memory) without an intervening 'data synchronization > barrier' (dsb). Even that may not be sufficient without also poking > at the L2 cache controller. > > We get around some of that by ensuring that our MMIO read/write macros > contain the necessary barriers to ensure that DMA memory is up to date > before the DMA agent is programmed. However, this doesn't cater for > agents which continue to run in the background. > > These agents will need some kind of barrier to ensure that the write > becomes visible - there's no way to get around that. Maybe we need > yet another new barrier macro... Hmmm. Although the semantics of the various mb() macros were originally defined only for inter-CPU synchronization, I believe they are also supposed to work for guaranteeing the order of accesses to DMA-coherent memory. If that's not the case with ARM, something is seriously wrong. (Maybe I'm wrong about this, but if I am then there's currently _no_ way for the kernel to order DMA-coherent accesses on ARM.) You know better than I do what is needed to resolve the ordering issue. However, contrary to what the original patch description said, this isn't entirely a matter of making the write visible to the host controller: No doubt in time the write will eventually become visible anyway. It's a matter of making the write become visible reasonably quickly and in the correct order with respect to other writes. Is this extra L2-cache "poke" needed for proper ordering, or is it needed merely to flush the write out to memory in a timely manner? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Sun, Aug 28, 2011 at 05:06:43PM -0600, Paul Walmsley wrote: > DMA resource data are usually DMA request line ID numbers. Not always. On ARMs development platforms, we ended up using strings - because we've ended up with a DMA controller with N request signals, where the first three request signals come from a MUX which assigns them to other devices in the system. An opaque number doesn't hack it because you start having to define arbitary ranges for such things, and that very quickly starts getting you into sticky problems when you have to work out that request signal S1 is routed through mux M1 which is connected to DMA request signal D1, and if M1 is in use, then maybe M2 can be used instead which routes to DMA request signal D2. The idea that DMA should be small integers is very limiting. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: fix update qtd->token in qh_append_tds
On Sun, Aug 28, 2011 at 01:00:07PM -0400, Alan Stern wrote: > It won't do that. All it will do is guarantee that the CPU writes out > dumy->hw_token before it writes out or reads in any values executed > after the mb. You're right from the perspective of how things are defined today. However, that isn't how things work on ARM. With ARMv6 and ARMv7, we have weak memory ordering. This includes so called "DMA coherent" memory. This means that the architecture does not guarantee the order of writes to DMA coherent memory (which is non- cacheable normal memory) without an intervening 'data synchronization barrier' (dsb). Even that may not be sufficient without also poking at the L2 cache controller. We get around some of that by ensuring that our MMIO read/write macros contain the necessary barriers to ensure that DMA memory is up to date before the DMA agent is programmed. However, this doesn't cater for agents which continue to run in the background. These agents will need some kind of barrier to ensure that the write becomes visible - there's no way to get around that. Maybe we need yet another new barrier macro... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Sun, 28 Aug 2011, David Gibson wrote: > I've never been very clear on what exactly DMA resources cover, DMA resource data are usually DMA request line ID numbers. DMA request lines are dedicated, unidirectional hardware signals from I/O devices to one or more independent DMA controllers[1][2][3]. Request lines indicate when the device is ready to accept data from the DMA controller, or, when the device has data ready for the DMA controller to fetch. On a given DMA controller, each request line has its own unique ID number[4][5][6]. During a DMA transfer, the I/O device asserts or deasserts its DMA request lines as its FIFOs fill or drain[7][8]. This will pause or resume the DMA transfer, if the DMA controller is programmed with the correct DMA request line IDs[9][10][11][12]. In a hardware-synchronized DMA transfer, the DMA controller must be controlled by the device because it is not good to read from an empty device FIFO, or to write to a full device FIFO. There aren't many sane courses of action in those circumstances with most interconnects and DMA controllers. So in terms of Linux kernel code, the driver needs the DMA request line ID numbers so it and the DMA code can program the DMA controller to synchronize DMA transfers with the I/O device(s). Like hardware IRQ IDs, these DMA request line IDs are properties of a DMA controller itself, but are associated with individual I/O devices. And like IRQ IDs, these DMA request line ID mappings may change from chip version to chip version[13], even for the same IP block. So it is useful for device data formats to provide DMA request line IDs dynamically. Several upstream device drivers get their DMA request line IDs from the device data format[14][15][16]. But more drivers should be doing this than currently are[17]: - the device driver author may have hardcoded the DMA request line ID, assuming it would never change - DMA could be broken on the device due to hardware bugs, so it is unused - the driver author may just never have gotten around to implementing DMA, or was reassigned to another project, or couldn't figure it out - the device may have its own internal DMA controller logic, so support for an external DMA controller was simply never added When looking at a driver, it may not be obvious which of the cases apply. (N.B., I/O device IP blocks that contain their own dedicated DMA controllers that are specialized to transfer only to memory don't need DMA request lines.) - Paul All code citations below are of Linux v3.1-rc3. 1. A DMA controller's view of DMA request lines. Figure 9-4, "SDMA Controller Integration". _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 2. A simple device's view of DMA request lines, only connected to one DMA controller. Figure 22-17, "MMC/SD/SDIO1 Integration". _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 3. A device's view of its DMA request lines connected to two separate DMA controllers, and thus with distinct numbering. Note also that the device refers to its signals with strings, while the DMA controllers refer to the same signals with ID numbers. Figure 21-16, "McBSP1 Integration". _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 4. Table 5-1 "Peripheral Addresses and Selectors". _RMI Alchemy Au1550 Security Network Processor Data Book Revision E_. May 2007. Available from http://www.poeticmonkey.com/ebay/semiconductors/cpus/au1550/au1550_db_0507e.pdf 5. Table 6-7 "Priority and Default Mapping of Peripheral to DMA". _ADSP-BF51x Blackfin Processor Hardware Reference Preliminary Revision 0.1_ (January 2009). Available from http://www.analog.com/static/imported-files/processor_manuals/bf51x_hwr_rev_0-1.pdf 6. Table 16-5 "sDMA Controller Request Mapping". _OMAP4460 Multimedia Device Silicon Revision 1.x Version H (Public Version) (SWPU235H)_. Available from http://focus.ti.com/pdfs/wtbu/OMAP4460_ES1.x_PUBLIC_TRM_vH.zip 7. A really nice illustration of the interaction between a FIFO and DMA request line during DMA receive. Figure 17-25 "Receive FIFO DMA Request Generation (32 Characters)". _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZR.zip 8. A similarly good illustration of the interaction between a FIFO and DMA request line during DMA transmit. Figure 17-26 "Transmit FIFO DMA Request Generation (56 Spaces)". _OMAP34xx Multimedia Device Silicon Revision 3.1.x Version R (SWPU223R)_ (public version). http://foc
Re: [PATCH] usb: ehci: fix update qtd->token in qh_append_tds
On Sun, 28 Aug 2011, Ming Lei wrote: > > I've been following this whole discussion. �I didn't understand the > > idea behind the original patch, and I don't understand this. �What > > reason is there for adding a memory barrier after the "dummy->hw_token > > = token" line? �Such a barrier would not accomplish anything useful, > > because there are no later memory accesses which need to be ordered > > with respect to that line. > > Here, mb is used to synchronize between writing of CPU and reading of > ehci HC, see below: A memory barrier never synchronizes events between two processors (for example, between the CPU and HC). It only affects ordering for the processor it executes on. That's why you always have to use memory barriers in pairs for inter-CPU synchronization: one memory barrier instruction for each CPU. > CPU EHCI > dummy->hw_token = token; > mb > read > dummy->hw_token > > The mb() introduced was supposed to be used to make sure that EHCI > can see the correct value of dummy->hw_token. It won't do that. All it will do is guarantee that the CPU writes out dumy->hw_token before it writes out or reads in any values executed after the mb. > If EHCI can't get the correct > hw_token in time, it will work badly, such as irq delay or irq lost which may > be > caused by mistaken 'IOC' or 'total bytes to transfer' in hw_token. No. All that will happen is that the HC will execute the qTD a little later, when it does read the correct hw_token. No IRQs will be lost, and there will be no mistaken IOC or "total bytes to transfer" values. > This is just > what the patch is to fix. The patch won't fix this. You're trying to force the CPU to write out dummy->hw_token more quickly. A memory barrier won't do that. And even if the CPU does write out the value more quickly, that doesn't guarantee it will be in time for the HC to see the new value right away. > But I think the above is still not correct, and the correct way may be > like below: > > CPU EHCI > dummy->hw_token = token; > wmb > qh->hw->hw_qtd_next = QTD_NEXT(ehci, dummy->qtd_dma); If you do this write, you will corrupt the hardware list. You _must_ _not_ modify the hardware fields of an active QH. Besides, qh_link_async() calls qh_refresh() -> qh_update(), which does this already. And it does this correctly, with the appropriate checks to make sure the QH isn't active. > fetch > next qtd from qh->hw->hw_qtd_next > read > qtd->hw_token > > The problem is that qh has already linked dummy into its queue before(as did > in > qh_update), so even after 'dummy->hw_token = token;' is executed on CPU, EHCI > still may not fetch the up-to-date value of the qtd(dummy in here), > and this should > be the root cause, IMO. There's no way to fix this. The CPU and the HC are independent. The HC is allowed to cache values whenever it likes (within certain limits). If it has already cached an old value from the qTD, there's no way to force it to use a new value. You just have to wait until it refreshes its cache. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Power management fixes for 3.1
Hi Linus, Please pull power management fixes for 3.1 from: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-fixes They include: * Fixes related to the sh-sci driver which uses runtime PM helpers in such a way that they may be run with interrupts off, but it doesn't tell the core about that (so the core happily enables interrupts when they should be off), and which also causes pm_clk_suspend() and pm_clk_resume() to be run with interrupts off (so they shouldn't use a mutex). * shi7372 LCDC suspend fix from Magnus Damm. * OMAP suspend callbacks fix from Kevin Hilman. * Runtime PM documentation correction. Thanks! Documentation/power/runtime_pm.txt |3 +- arch/arm/mach-shmobile/board-ap4evb.c |1 + arch/arm/mach-shmobile/board-mackerel.c |1 + arch/arm/mach-shmobile/clock-sh7372.c |2 + arch/arm/plat-omap/omap_device.c|3 +- drivers/base/power/clock_ops.c | 40 +-- drivers/tty/serial/sh-sci.c |1 + 7 files changed, 30 insertions(+), 21 deletions(-) --- Kevin Hilman (1): OMAP: omap_device: only override _noirq methods, not normal suspend/resume Magnus Damm (2): ARM: mach-shmobile: sh7372 LCDC1 suspend fix ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental) Rafael J. Wysocki (3): PM: Use spinlock instead of mutex in clock management functions sh-sci / PM: Use power.irq_safe PM / Runtime: Correct documentation of pm_runtime_irq_safe() -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/12] use nonblock mmc requests to minimize latency
On 28 August 2011 13:11, Russell King - ARM Linux
wrote:
> On Sun, Aug 28, 2011 at 12:50:54PM +0200, Per Forlin wrote:
>> On 26 August 2011 18:28, Santosh wrote:
>> > + Balaji,
>> >
>> > On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote:
>> >>
>> >> I'm not sure who's responsible for this, but the nonblocking MMC stuff is
>> >> broken on OMAPs HSMMC:
>> >>
>> >> mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response
>> >> 0x900, card status 0xb00
>> >> mmcblk0: retrying using single block read
>> >> [ cut here ]
>> >> WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811
>> >> check_unmap+0x1ac/0x764()
>> >> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
>> >> it has not allocated [device address=0x80933000] [size=20480
>> >> bytes]
>> >> Modules linked in:
>> >> Backtrace:
>> >> [] (dump_backtrace+0x0/0x10c) from []
>> >> (dump_stack+0x18/0x1c)
>> >> r7:c1abfcb8 r6:c0186248 r5:c037de51 r4:032b
>> >> [] (dump_stack+0x0/0x1c) from []
>> >> (warn_slowpath_common+0x58/0x70)
>> >> [] (warn_slowpath_common+0x0/0x70) from []
>> >> (warn_slowpath_fmt+0x38/0x40)
>> >> r8:c1abfd50 r7: r6:5000 r5: r4:80933000
>> >> [] (warn_slowpath_fmt+0x0/0x40) from []
>> >> (check_unmap+0x1ac/0x764)
>> >> r3:c0367d55 r2:c037e24d
>> >> [] (check_unmap+0x0/0x764) from []
>> >> (debug_dma_unmap_sg+0x100/0x134)
>> >> [] (debug_dma_unmap_sg+0x0/0x134) from []
>> >> (dma_unmap_sg+0x24/0x7c)
>> >> [] (dma_unmap_sg+0x0/0x7c) from []
>> >> (omap_hsmmc_post_req+0x48/0x54)
>> >> [] (omap_hsmmc_post_req+0x0/0x54) from []
>> >> (mmc_start_req+0x9c/0x128)
>> >> r4:c1a76000
>> >> [] (mmc_start_req+0x0/0x128) from []
>> >> (mmc_blk_issue_rw_rq+0x80/0x460)
>> >> r8:c1ab5c00 r7:0001 r6:c1ab5824 r5:c1ab5824 r4:c1ab5c00
>> >> [] (mmc_blk_issue_rw_rq+0x0/0x460) from []
>> >> (mmc_blk_issue_rq+0x2cc/0x2fc)
>> >> [] (mmc_blk_issue_rq+0x0/0x2fc) from []
>> >> (mmc_queue_thread+0xa0/0x104)
>> >> [] (mmc_queue_thread+0x0/0x104) from []
>> >> (kthread+0x88/0x90)
>> >> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x618)
>> >> r7:0013 r6:c003d9a4 r5:c0054f04 r4:c1a7bc7c
>> >> ---[ end trace 3314ad56daf5d14f ]---
>> >>
>> >> Luckily thinks continue to work, but clearly releasing DMA mappings which
>> >> drivers don't own is bad news. Unfortunately, I don't have the bandwidth
>> >> to be able to investigate this at present - well, I could do but then I'd
>> >> have to drop working on the OMAP4 vs generic suspend/resume code and learn
>> >> about something I've no current clue about.
>> >>
>> > Please continue your help on generic suspend.
>> >
>> >> Can someone please investigate and fix whatever is broken.
>> >>
>> > Will find somebody to look at this issue.
>> >
>> I had a look at this and my guess is that the same mapped DMA memory
>> is unmapped twice. First the memory is unmapped in
>> omap_hsmmc_dma_cleanup() due to the mmc error, then later in
>> omap_hsmmc_post_req(). Here is a patch to resolve that. I haven't had
>> the chance to test it yet though.
>>
>> ---
>> drivers/mmc/host/omap_hsmmc.c | 7 +--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 21e4a79..7f40767 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct
>> omap_hsmmc_host *host, int errno)
>> host->data->sg_len,
>> omap_hsmmc_get_dma_dir(host, host->data));
>> omap_free_dma(dma_ch);
>> + data->host_cookie = 0;
>> }
>> host->data = NULL;
>> }
>> @@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host
>> *mmc, struct mmc_request *mrq,
>> struct mmc_data *data = mrq->data;
>>
>> if (host->use_dma) {
>> - dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
>> - omap_hsmmc_get_dma_dir(host, data));
>> + if (data->host_cookie)
>> + dma_unmap_sg(mmc_dev(host->mmc), data->sg,
>> + data->sg_len,
>> + omap_hsmmc_get_dma_dir(host, data));
>> data->host_cookie = 0;
>>
>>
>> I also checked the mmci code for this same issue and mmci doesn't have
>> the same bug.
>> MMCI works fine in 3.1-rc2 even though the code is "wrong". I propose
>> this change.
>> @@ -529,7 +529,7 @@ static void mmci_post_request(struct mmc_host
>> *mmc, struct mmc_request *mrq,
>> if (chan) {
>> if (err)
>> dmaengine_terminate_all(chan);
>> - if (err || data->host_cookie)
>> + if (data->host_cookie)
>>
>> I'll post these patches as soon as I have managed to test them or
>> sooner if I get a tested-by.
>
> Looking at MMCI, are you sure
Re: How to handle named resources with DT?
On Sat, Aug 27, 2011 at 08:13:59PM +0200, Arnd Bergmann wrote:
> On Sunday 28 August 2011 00:37:36 David Gibson wrote:
> > On Fri, Aug 26, 2011 at 05:41:29PM +0200, Arnd Bergmann wrote:
> > > On Friday 26 August 2011, Arnd Bergmann wrote:
> > > > On Friday 26 August 2011, David Gibson wrote:
> > > > > If you open code it this way then yes, it's silly. But what about
> > > > > something like this:
> > > > >
> > > > > static struct of_device_id foodevice_of_match[] __devinitdata = {
> > > > > { .compatible = "foocorp,foodevice1234",
> > > > > .resource_names = {"base_regs", "extra_regs", }, },
> > > > > { .compatible = "foocorp,foodevice1239",
> > > > > .resource_names = {"base_regs", "extra_regs", "more_regs",
> > > > > }, },
> > > > > { },
> > > > > };
> > > >
> > > > Hmm, I hadn't thought of that. This looks quite nice indeed. No
> > > > objections
> > > > to this from my side.
> > > >
> > >
> > > Ah well, one objection on second thought:
> > >
> > > This assumes that there is just one type of resource, but named resources
> > > may be used for iomem, ioport and irq resources. If you have multiple
> > > IRQs and multiple IOMEM resources, I don't see how the index in the
> > > resource_names array can be used for both of them.
> >
> > Details, shmetails, so you have both 'reg_names' and 'interrupt_names'.
>
> Right, and I guess we can simply ignore DMA and ioport resources because they
> are extremely rare, right?
Well, remember it's where resources can appear in the DT node that
matters, not what the types are in the platform device. ioports will
typically appear suitably encoded in 'reg', so that's covered. I've
never been very clear on what exactly DMA resources cover, but yeah,
you might need something for dma-reg or other device tree properties.
> One more detail: IIRC struct of_device_id is exported to module_init_tools
> for purposes of autoloading, so changing the structure breaks user
> space.
Ah. That is a bit more of a problem.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 00/12] use nonblock mmc requests to minimize latency
On Sun, Aug 28, 2011 at 12:50:54PM +0200, Per Forlin wrote:
> On 26 August 2011 18:28, Santosh wrote:
> > + Balaji,
> >
> > On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote:
> >>
> >> I'm not sure who's responsible for this, but the nonblocking MMC stuff is
> >> broken on OMAPs HSMMC:
> >>
> >> mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response
> >> 0x900, card status 0xb00
> >> mmcblk0: retrying using single block read
> >> [ cut here ]
> >> WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811
> >> check_unmap+0x1ac/0x764()
> >> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
> >> it has not allocated [device address=0x80933000] [size=20480 bytes]
> >> Modules linked in:
> >> Backtrace:
> >> [] (dump_backtrace+0x0/0x10c) from []
> >> (dump_stack+0x18/0x1c)
> >> r7:c1abfcb8 r6:c0186248 r5:c037de51 r4:032b
> >> [] (dump_stack+0x0/0x1c) from []
> >> (warn_slowpath_common+0x58/0x70)
> >> [] (warn_slowpath_common+0x0/0x70) from []
> >> (warn_slowpath_fmt+0x38/0x40)
> >> r8:c1abfd50 r7: r6:5000 r5: r4:80933000
> >> [] (warn_slowpath_fmt+0x0/0x40) from []
> >> (check_unmap+0x1ac/0x764)
> >> r3:c0367d55 r2:c037e24d
> >> [] (check_unmap+0x0/0x764) from []
> >> (debug_dma_unmap_sg+0x100/0x134)
> >> [] (debug_dma_unmap_sg+0x0/0x134) from []
> >> (dma_unmap_sg+0x24/0x7c)
> >> [] (dma_unmap_sg+0x0/0x7c) from []
> >> (omap_hsmmc_post_req+0x48/0x54)
> >> [] (omap_hsmmc_post_req+0x0/0x54) from []
> >> (mmc_start_req+0x9c/0x128)
> >> r4:c1a76000
> >> [] (mmc_start_req+0x0/0x128) from []
> >> (mmc_blk_issue_rw_rq+0x80/0x460)
> >> r8:c1ab5c00 r7:0001 r6:c1ab5824 r5:c1ab5824 r4:c1ab5c00
> >> [] (mmc_blk_issue_rw_rq+0x0/0x460) from []
> >> (mmc_blk_issue_rq+0x2cc/0x2fc)
> >> [] (mmc_blk_issue_rq+0x0/0x2fc) from []
> >> (mmc_queue_thread+0xa0/0x104)
> >> [] (mmc_queue_thread+0x0/0x104) from []
> >> (kthread+0x88/0x90)
> >> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x618)
> >> r7:0013 r6:c003d9a4 r5:c0054f04 r4:c1a7bc7c
> >> ---[ end trace 3314ad56daf5d14f ]---
> >>
> >> Luckily thinks continue to work, but clearly releasing DMA mappings which
> >> drivers don't own is bad news. Unfortunately, I don't have the bandwidth
> >> to be able to investigate this at present - well, I could do but then I'd
> >> have to drop working on the OMAP4 vs generic suspend/resume code and learn
> >> about something I've no current clue about.
> >>
> > Please continue your help on generic suspend.
> >
> >> Can someone please investigate and fix whatever is broken.
> >>
> > Will find somebody to look at this issue.
> >
> I had a look at this and my guess is that the same mapped DMA memory
> is unmapped twice. First the memory is unmapped in
> omap_hsmmc_dma_cleanup() due to the mmc error, then later in
> omap_hsmmc_post_req(). Here is a patch to resolve that. I haven't had
> the chance to test it yet though.
>
> ---
> drivers/mmc/host/omap_hsmmc.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 21e4a79..7f40767 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct
> omap_hsmmc_host *host, int errno)
> host->data->sg_len,
> omap_hsmmc_get_dma_dir(host, host->data));
> omap_free_dma(dma_ch);
> + data->host_cookie = 0;
> }
> host->data = NULL;
> }
> @@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host
> *mmc, struct mmc_request *mrq,
> struct mmc_data *data = mrq->data;
>
> if (host->use_dma) {
> - dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
> -omap_hsmmc_get_dma_dir(host, data));
> + if (data->host_cookie)
> + dma_unmap_sg(mmc_dev(host->mmc), data->sg,
> +data->sg_len,
> +omap_hsmmc_get_dma_dir(host, data));
> data->host_cookie = 0;
>
>
> I also checked the mmci code for this same issue and mmci doesn't have
> the same bug.
> MMCI works fine in 3.1-rc2 even though the code is "wrong". I propose
> this change.
> @@ -529,7 +529,7 @@ static void mmci_post_request(struct mmc_host
> *mmc, struct mmc_request *mrq,
> if (chan) {
> if (err)
> dmaengine_terminate_all(chan);
> - if (err || data->host_cookie)
> + if (data->host_cookie)
>
> I'll post these patches as soon as I have managed to test them or
> sooner if I get a tested-by.
Looking at MMCI, are you sure all those DMA engine terminate calls are
correct?
For example, why are we terminating all DMA engine transfers in the
post request function? Surely that should've already been
Re: [PATCH v9 00/12] use nonblock mmc requests to minimize latency
On 26 August 2011 18:28, Santosh wrote:
> + Balaji,
>
> On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote:
>>
>> I'm not sure who's responsible for this, but the nonblocking MMC stuff is
>> broken on OMAPs HSMMC:
>>
>> mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response
>> 0x900, card status 0xb00
>> mmcblk0: retrying using single block read
>> [ cut here ]
>> WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811
>> check_unmap+0x1ac/0x764()
>> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
>> it has not allocated [device address=0x80933000] [size=20480 bytes]
>> Modules linked in:
>> Backtrace:
>> [] (dump_backtrace+0x0/0x10c) from []
>> (dump_stack+0x18/0x1c)
>> r7:c1abfcb8 r6:c0186248 r5:c037de51 r4:032b
>> [] (dump_stack+0x0/0x1c) from []
>> (warn_slowpath_common+0x58/0x70)
>> [] (warn_slowpath_common+0x0/0x70) from []
>> (warn_slowpath_fmt+0x38/0x40)
>> r8:c1abfd50 r7: r6:5000 r5: r4:80933000
>> [] (warn_slowpath_fmt+0x0/0x40) from []
>> (check_unmap+0x1ac/0x764)
>> r3:c0367d55 r2:c037e24d
>> [] (check_unmap+0x0/0x764) from []
>> (debug_dma_unmap_sg+0x100/0x134)
>> [] (debug_dma_unmap_sg+0x0/0x134) from []
>> (dma_unmap_sg+0x24/0x7c)
>> [] (dma_unmap_sg+0x0/0x7c) from []
>> (omap_hsmmc_post_req+0x48/0x54)
>> [] (omap_hsmmc_post_req+0x0/0x54) from []
>> (mmc_start_req+0x9c/0x128)
>> r4:c1a76000
>> [] (mmc_start_req+0x0/0x128) from []
>> (mmc_blk_issue_rw_rq+0x80/0x460)
>> r8:c1ab5c00 r7:0001 r6:c1ab5824 r5:c1ab5824 r4:c1ab5c00
>> [] (mmc_blk_issue_rw_rq+0x0/0x460) from []
>> (mmc_blk_issue_rq+0x2cc/0x2fc)
>> [] (mmc_blk_issue_rq+0x0/0x2fc) from []
>> (mmc_queue_thread+0xa0/0x104)
>> [] (mmc_queue_thread+0x0/0x104) from []
>> (kthread+0x88/0x90)
>> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x618)
>> r7:0013 r6:c003d9a4 r5:c0054f04 r4:c1a7bc7c
>> ---[ end trace 3314ad56daf5d14f ]---
>>
>> Luckily thinks continue to work, but clearly releasing DMA mappings which
>> drivers don't own is bad news. Unfortunately, I don't have the bandwidth
>> to be able to investigate this at present - well, I could do but then I'd
>> have to drop working on the OMAP4 vs generic suspend/resume code and learn
>> about something I've no current clue about.
>>
> Please continue your help on generic suspend.
>
>> Can someone please investigate and fix whatever is broken.
>>
> Will find somebody to look at this issue.
>
I had a look at this and my guess is that the same mapped DMA memory
is unmapped twice. First the memory is unmapped in
omap_hsmmc_dma_cleanup() due to the mmc error, then later in
omap_hsmmc_post_req(). Here is a patch to resolve that. I haven't had
the chance to test it yet though.
---
drivers/mmc/host/omap_hsmmc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..7f40767 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
host->data->sg_len,
omap_hsmmc_get_dma_dir(host, host->data));
omap_free_dma(dma_ch);
+ data->host_cookie = 0;
}
host->data = NULL;
}
@@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host
*mmc, struct mmc_request *mrq,
struct mmc_data *data = mrq->data;
if (host->use_dma) {
- dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
-omap_hsmmc_get_dma_dir(host, data));
+ if (data->host_cookie)
+ dma_unmap_sg(mmc_dev(host->mmc), data->sg,
+data->sg_len,
+omap_hsmmc_get_dma_dir(host, data));
data->host_cookie = 0;
I also checked the mmci code for this same issue and mmci doesn't have
the same bug.
MMCI works fine in 3.1-rc2 even though the code is "wrong". I propose
this change.
@@ -529,7 +529,7 @@ static void mmci_post_request(struct mmc_host
*mmc, struct mmc_request *mrq,
if (chan) {
if (err)
dmaengine_terminate_all(chan);
- if (err || data->host_cookie)
+ if (data->host_cookie)
I'll post these patches as soon as I have managed to test them or
sooner if I get a tested-by.
Regards,
Per
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
