[PATCH v4 0/2] OMAPDSS: HDMI: Boardfile cleanup
From: Mythri P K mythr...@ti.com Clean up of boardfiles to have the functions common to differnt boards in a common display file, Also in some OMAP4 boards external pull-up's are enabled thus enabling internal pull up should be a parameter from the boardfile. changes since v3 : Comment improvement to move some portion from boardfile to display. changes since v2 : Make the flag as enum. changes since v1 : Make omap hdmi_init generic to handle different parameters and pass the pull up as a flag instead of int. Mythri P K (2): OMAPDSS: HDMI: Move duplicate code from boardfile OMAPDSS: HDMI: Disable DDC internal pull up arch/arm/mach-omap2/board-4430sdp.c| 23 ++ arch/arm/mach-omap2/board-omap4panda.c | 25 +++- arch/arm/mach-omap2/display.c | 39 include/video/omapdss.h|6 + 4 files changed, 62 insertions(+), 31 deletions(-) -- 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 v4 1/2] OMAPDSS: HDMI: Move duplicate code from boardfile
From: Mythri P K mythr...@ti.com
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c| 16 +---
arch/arm/mach-omap2/board-omap4panda.c | 17 +
arch/arm/mach-omap2/display.c | 23 +++
include/video/omapdss.h|2 ++
4 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 73b1e99..c3bd640 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -595,20 +595,6 @@ static void __init omap_sfh7741prox_init(void)
__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
}
-static void sdp4430_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio sdp4430_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH,hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH,hdmi_gpio_ls_oe },
@@ -838,9 +824,9 @@ static void omap_4430sdp_display_init(void)
pr_err(%s: Could not get display_sel GPIO\n, __func__);
sdp4430_lcd_init();
- sdp4430_hdmi_mux_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
+ omap_hdmi_init();
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index a5b576b..d95df2e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -478,21 +478,6 @@ int __init omap4_panda_dvi_init(void)
return r;
}
-
-static void omap4_panda_hdmi_mux_init(void)
-{
- /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
- omap_mux_init_signal(hdmi_hpd,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_cec,
- OMAP_PIN_INPUT_PULLUP);
- /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
- omap_mux_init_signal(hdmi_ddc_scl,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(hdmi_ddc_sda,
- OMAP_PIN_INPUT_PULLUP);
-}
-
static struct gpio panda_hdmi_gpios[] = {
{ HDMI_GPIO_HPD,GPIOF_OUT_INIT_HIGH, hdmi_gpio_hpd },
{ HDMI_GPIO_LS_OE, GPIOF_OUT_INIT_HIGH, hdmi_gpio_ls_oe },
@@ -555,8 +540,8 @@ void omap4_panda_display_init(void)
if (r)
pr_err(error initializing panda DVI\n);
- omap4_panda_hdmi_mux_init();
omap_display_init(omap4_panda_dss_data);
+ omap_hdmi_init();
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index dce9905..8436088 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -29,6 +29,7 @@
#include plat/omap-pm.h
#include plat/common.h
+#include mux.h
#include control.h
#include display.h
@@ -96,6 +97,20 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
+static void omap4_hdmi_mux_pads()
+{
+ /* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
+ omap_mux_init_signal(hdmi_hpd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_cec,
+ OMAP_PIN_INPUT_PULLUP);
+ /* PAD0_HDMI_DDC_SCL_PAD1_HDMI_DDC_SDA */
+ omap_mux_init_signal(hdmi_ddc_scl,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(hdmi_ddc_sda,
+ OMAP_PIN_INPUT_PULLUP);
+}
+
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
{
u32 enable_mask, enable_shift;
@@ -129,6 +144,14 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
+int omap_hdmi_init(void)
+{
+ if (cpu_is_omap44xx())
+ omap4_hdmi_mux_pads();
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
if (cpu_is_omap44xx())
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 378c7ed..1e11683 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -309,6 +309,8 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
+/* HDMI mux init*/
+extern int omap_hdmi_init(void);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe
[PATCH v4 2/2] OMAPDSS: HDMI: Disable DDC internal pull up
From: Mythri P K mythr...@ti.com
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are external pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@linaro.org
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|9 -
arch/arm/mach-omap2/board-omap4panda.c | 10 +-
arch/arm/mach-omap2/display.c | 22 +++---
include/video/omapdss.h|6 +-
4 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c3bd640..4af874a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -826,7 +826,14 @@ static void omap_4430sdp_display_init(void)
sdp4430_lcd_init();
sdp4430_picodlp_init();
omap_display_init(sdp4430_dss_data);
- omap_hdmi_init();
+ /*
+* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
+* later have external pull up on the HDMI I2C lines
+*/
+ if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
+ omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index d95df2e..00103e3 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -541,7 +541,15 @@ void omap4_panda_display_init(void)
pr_err(error initializing panda DVI\n);
omap_display_init(omap4_panda_dss_data);
- omap_hdmi_init();
+
+ /*
+* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
+* later have external pull up on the HDMI I2C lines
+*/
+ if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
+ omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
+ else
+ omap_hdmi_init(0);
}
static void __init omap4_panda_init(void)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 8436088..ffd9bd9 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -97,8 +97,11 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initdata = {
{ dss_hdmi, omapdss_hdmi, -1 },
};
-static void omap4_hdmi_mux_pads()
+static void omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
{
+ u32 reg;
+ u16 control_i2c_1;
+
/* PAD0_HDMI_HPD_PAD1_HDMI_CEC */
omap_mux_init_signal(hdmi_hpd,
OMAP_PIN_INPUT_PULLUP);
@@ -109,6 +112,19 @@ static void omap4_hdmi_mux_pads()
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal(hdmi_ddc_sda,
OMAP_PIN_INPUT_PULLUP);
+
+ /*
+* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
+* HDMI_DDC_SCL_PULLUPRESX (bit 24) are set to disable
+* internal pull up resistor.
+*/
+ if (flags OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP) {
+ control_i2c_1 = OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_I2C_1;
+ reg = omap4_ctrl_pad_readl(control_i2c_1);
+ reg |= (OMAP4_HDMI_DDC_SDA_PULLUPRESX_MASK |
+ OMAP4_HDMI_DDC_SCL_PULLUPRESX_MASK);
+ omap4_ctrl_pad_writel(reg, control_i2c_1);
+ }
}
static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
@@ -144,10 +160,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
return 0;
}
-int omap_hdmi_init(void)
+int omap_hdmi_init(enum omap_hdmi_flags flags)
{
if (cpu_is_omap44xx())
- omap4_hdmi_mux_pads();
+ omap4_hdmi_mux_pads(flags);
return 0;
}
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 1e11683..05da097 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -200,6 +200,10 @@ enum omap_dss_clk_source {
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI,/* OMAP4: PLL2_CLK2 */
};
+enum omap_hdmi_flags {
+ OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 0,
+};
+
/* RFBI */
struct rfbi_timings {
@@ -310,7 +314,7 @@ struct omap_dss_board_info {
/* Init with the board info */
extern int omap_display_init(struct omap_dss_board_info *board_data);
/* HDMI mux init*/
-extern int omap_hdmi_init(void);
+extern int omap_hdmi_init(enum omap_hdmi_flags flags);
struct omap_display_platform_data {
struct omap_dss_board_info *board_data;
--
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 0/4] OMAPDSS: HDMI: Improve the timings logic in HDMI
From: Mythri P K mythr...@ti.com There are some duplicate timing structure which are not needed thus removing them to clean the code. Also the static mapped timing structure is quite complicated to add new timings, so simplify it by using array indexed method. changes since V1: change of hdmi_find_timing function to return pointer to the timing struct rather than deep copy to timing structure passed as parameter variable name change from temp to timing2 in comparator function. Mythri P K (4): OMAPDSS: HDMI: remove duplicate video interface code OMAPDSS: HDMI: update static timing table OMAPDSS: HDMI: change the timing match logic OMAPDSS: HDMI: remove duplicate code and mode parameter drivers/video/omap2/dss/hdmi.c| 254 + drivers/video/omap2/dss/ti_hdmi.h | 14 +- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 47 ++ drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |7 - 4 files changed, 134 insertions(+), 188 deletions(-) -- 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 1/4] OMAPDSS: HDMI: remove duplicate video interface code
From: Mythri P K mythr...@ti.com
video interface structure is a duplicate structure with parameters which are
already present in ip_data config structure, Thus removing the structure and
modifying corresponding code.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 31 +++-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |7 --
2 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e1a6ce5..403d6fc 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -629,8 +629,7 @@ static void hdmi_core_av_packet_config(struct hdmi_ip_data
*ip_data,
}
static void hdmi_wp_init(struct omap_video_timings *timings,
- struct hdmi_video_format *video_fmt,
- struct hdmi_video_interface *video_int)
+ struct hdmi_video_format *video_fmt)
{
pr_debug(Enter hdmi_wp_init\n);
@@ -645,12 +644,6 @@ static void hdmi_wp_init(struct omap_video_timings
*timings,
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 ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
@@ -687,17 +680,16 @@ static void hdmi_wp_video_config_format(struct
hdmi_ip_data *ip_data,
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)
+static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data)
{
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);
+ r = FLD_MOD(r, ip_data-cfg.timings.vsync_pol, 7, 7);
+ r = FLD_MOD(r, ip_data-cfg.timings.hsync_pol, 6, 6);
+ r = FLD_MOD(r, ip_data-cfg.interlace, 3, 3);
+ r = FLD_MOD(r, 1, 1, 0); /* HDMI_TIMING_MASTER_24BIT */
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
}
@@ -725,15 +717,13 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
/* 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;
struct hdmi_config *cfg = ip_data-cfg;
- hdmi_wp_init(video_timing, video_format,
- video_interface);
+ hdmi_wp_init(video_timing, video_format);
hdmi_core_init(v_core_cfg,
avi_cfg,
@@ -748,12 +738,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
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);
+ hdmi_wp_video_config_interface(ip_data);
/*
* configure core video part
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 2040956..914bec6 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -517,13 +517,6 @@ struct hdmi_video_format {
u32 x_res; /* pixel per line */
};
-struct hdmi_video_interface {
- int vsp;/* Vsync polarity */
- int hsp;/* Hsync polarity */
- int interlacing;
- int tm; /* Timing mode */
-};
-
struct hdmi_audio_format {
enum hdmi_stereo_channels stereo_channels;
u8 active_chnnls_msk;
--
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 4/4] OMAPDSS: HDMI: remove duplicate code and mode parameter
From: Mythri P K mythr...@ti.com
code and mode parameters are already a part of the ip_data structure
so no need to keep the same parameters again in hdmi global structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 6892faa..34f3dae 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -66,8 +66,6 @@ static struct {
struct omap_display_platform_data *pdata;
struct platform_device *pdev;
struct hdmi_ip_data ip_data;
- int code;
- int mode;
struct clk *sys_clk;
} hdmi;
@@ -163,7 +161,7 @@ static const struct hdmi_config *hdmi_find_timing(
const struct hdmi_config *timing, timing1 = { {0}, {0} };
for (i = 0; i len; i++) {
- if (timings_arr[i].cm.code == hdmi.code) {
+ if (timings_arr[i].cm.code == hdmi.ip_data.cfg.cm.code) {
timing = timings_arr[i];
return timing;
}
@@ -176,7 +174,7 @@ static const struct hdmi_config *hdmi_get_timings(void)
{
const struct hdmi_config *timing;
- if (hdmi.mode == 0) {
+ if (hdmi.ip_data.cfg.cm.mode == 0) {
timing = hdmi_find_timing(vesa_timings,
ARRAY_SIZE(vesa_timings));
} else {
@@ -314,9 +312,9 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi.ip_data.cfg = *(hdmi_get_timings());
if (hdmi.ip_data.cfg.timings.x_res == 0) {
/* HDMI code 4 corresponds to 640 * 480 VGA */
- hdmi.code = 4;
+ hdmi.ip_data.cfg.cm.code = 4;
/* DVI mode 1 corresponds to HDMI 0 to DVI */
- hdmi.mode = HDMI_DVI;
+ hdmi.ip_data.cfg.cm.mode = HDMI_DVI;
hdmi.ip_data.cfg = vesa_timings[0];
}
@@ -339,8 +337,6 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
goto err;
}
- hdmi.ip_data.cfg.cm.mode = hdmi.mode;
- hdmi.ip_data.cfg.cm.code = hdmi.code;
hdmi.ip_data.ops-video_configure(hdmi.ip_data);
/* Make selection of HDMI in DSS */
@@ -400,8 +396,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device
*dssdev)
struct hdmi_cm cm;
cm = hdmi_get_code(dssdev-panel.timings);
- hdmi.code = cm.code;
- hdmi.mode = cm.mode;
+ hdmi.ip_data.cfg.cm.code = cm.code;
+ hdmi.ip_data.cfg.cm.mode = cm.mode;
if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE) {
int r;
@@ -667,7 +663,7 @@ static int hdmi_audio_hw_params(struct hdmi_ip_data
*ip_data,
static int hdmi_audio_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
- if (!hdmi.mode) {
+ if (!hdmi.ip_data.cfg.cm.mode) {
pr_err(Current video settings do not support audio.\n);
return -EIO;
}
--
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 3/4] OMAPDSS: HDMI: change the timing match logic
From: Mythri P K mythr...@ti.com
Change the timing match logic, Instead of the statically mapped method
to get the corresponding timings for a given code and mode, move to a
simpler array indexed method. It will help to scale up to add more
timings when needed.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 174 +---
1 files changed, 75 insertions(+), 99 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f76ae47..6892faa 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -58,8 +58,6 @@
#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
-#define OMAP_HDMI_TIMINGS_NB 34
-
#define HDMI_DEFAULT_REGN 16
#define HDMI_DEFAULT_REGM2 1
@@ -88,7 +86,7 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+static const struct hdmi_config cea_timings[] = {
{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
@@ -104,6 +102,8 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+};
+static const struct hdmi_config vesa_timings[] = {
/* VESA From Here */
{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
@@ -126,39 +126,6 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {0x55, HDMI_DVI} }
};
-/*
- * This is a static mapping array which maps the timing values
- * with corresponding CEA / VESA code
- */
-static const int code_index[OMAP_HDMI_TIMINGS_NB] = {
- 1, 19, 4, 2, 37, 6, 21, 20, 5, 16, 17, 29, 31, 35, 32,
- /* --15 CEA 17-- vesa*/
- 4, 9, 0xE, 0x17, 0x1C, 0x27, 0x20, 0x23, 0x10, 0x2A,
- 0X2F, 0x3A, 0X51, 0X52, 0x16, 0x29, 0x39, 0x1B
-};
-
-/*
- * This is reverse static mapping which maps the CEA / VESA code
- * to the corresponding timing values
- */
-static const int code_cea[39] = {
- -1, 0, 3, 3, 2, 8, 5, 5, -1, -1,
- -1, -1, -1, -1, -1, -1, 9, 10, 10, 1,
- 7, 6, 6, -1, -1, -1, -1, -1, -1, 11,
- 11, 12, 14, -1, -1, 13, 13, 4, 4
-};
-
-static const int code_vesa[85] = {
- -1, -1, -1, -1, 15, -1, -1, -1, -1, 16,
- -1, -1, -1, -1, 17, -1, 23, -1, -1, -1,
- -1, -1, 29, 18, -1, -1, -1, 32, 19, -1,
- -1, -1, 21, -1, -1, 22, -1, -1, -1, 20,
- -1, 30, 24, -1, -1, -1, -1, 25, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, 31, 26, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, 27, 28, -1, 33};
-
static int hdmi_runtime_get(void)
{
int r;
@@ -188,82 +155,85 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static int get_timings_index(void)
+static const struct hdmi_config *hdmi_find_timing(
+ const struct hdmi_config *timings_arr,
+ int len)
{
- int code;
+ int i;
+ const struct hdmi_config *timing, timing1 = { {0}, {0} };
- if (hdmi.mode == 0)
- code = code_vesa[hdmi.code];
- else
- code = code_cea[hdmi.code];
+ for (i = 0; i len; i++) {
+ if (timings_arr[i].cm.code == hdmi.code) {
+ timing = timings_arr[i];
+ return timing;
+ }
+ }
+ timing = timing1;
+ return timing;
+}
- if (code == -1) {
- /* HDMI code 4 corresponds to 640 * 480 VGA */
- hdmi.code = 4;
- /* DVI mode 1 corresponds to HDMI 0 to DVI */
- hdmi.mode = HDMI_DVI;
+static const struct hdmi_config *hdmi_get_timings(void)
+{
+ const struct hdmi_config *timing;
- code = code_vesa[hdmi.code];
+ if (hdmi.mode == 0) {
+ timing = hdmi_find_timing(vesa_timings,
+ ARRAY_SIZE(vesa_timings));
+ } else {
+ timing = hdmi_find_timing(cea_timings,
+ ARRAY_SIZE(cea_timings));
+ }
+ return timing;
+}
+
+static bool hdmi_timings_compare(struct omap_video_timings *timing1,
+ const struct hdmi_video_timings *timing2)
+{
+ int timing1_vsync, timing1_hsync, timing2_vsync, timing2_hsync;
+
+ if
[PATCH v2 2/4] OMAPDSS: HDMI: update static timing table
From: Mythri P K mythr...@ti.com
Add the vsync polarity, hsync polarity, interlace to hdmi_video_timings.
Remove the now duplicate structure hdmi_timings.
update the static table structure in HDMI with CEA/VESA code and mode.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c| 96 ++--
drivers/video/omap2/dss/ti_hdmi.h | 14 ++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 20 +++---
3 files changed, 63 insertions(+), 67 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c56378c..f76ae47 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -88,42 +88,42 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_timings cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
- { {640, 480, 25200, 96, 16, 48, 2, 10, 33} , 0 , 0},
- { {1280, 720, 74250, 40, 440, 220, 5, 5, 20}, 1, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1},
- { {720, 480, 27027, 62, 16, 60, 6, 9, 30}, 0, 0},
- { {2880, 576, 108000, 256, 48, 272, 5, 5, 39}, 0, 0},
- { {1440, 240, 27027, 124, 38, 114, 3, 4, 15}, 0, 0},
- { {1440, 288, 27000, 126, 24, 138, 3, 2, 19}, 0, 0},
- { {1920, 540, 74250, 44, 528, 148, 5, 2, 15}, 1, 1},
- { {1920, 540, 74250, 44, 88, 148, 5, 2, 15}, 1, 1},
- { {1920, 1080, 148500, 44, 88, 148, 5, 4, 36}, 1, 1},
- { {720, 576, 27000, 64, 12, 68, 5, 5, 39}, 0, 0},
- { {1440, 576, 54000, 128, 24, 136, 5, 5, 39}, 0, 0},
- { {1920, 1080, 148500, 44, 528, 148, 5, 4, 36}, 1, 1},
- { {2880, 480, 108108, 248, 64, 240, 6, 9, 30}, 0, 0},
- { {1920, 1080, 74250, 44, 638, 148, 5, 4, 36}, 1, 1},
- /* VESA From Here */
- { {640, 480, 25175, 96, 16, 48, 2 , 11, 31}, 0, 0},
- { {800, 600, 4, 128, 40, 88, 4 , 1, 23}, 1, 1},
- { {848, 480, 33750, 112, 16, 112, 8 , 6, 23}, 1, 1},
- { {1280, 768, 79500, 128, 64, 192, 7 , 3, 20}, 1, 0},
- { {1280, 800, 83500, 128, 72, 200, 6 , 3, 22}, 1, 0},
- { {1360, 768, 85500, 112, 64, 256, 6 , 3, 18}, 1, 1},
- { {1280, 960, 108000, 112, 96, 312, 3 , 1, 36}, 1, 1},
- { {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38}, 1, 1},
- { {1024, 768, 65000, 136, 24, 160, 6, 3, 29}, 0, 0},
- { {1400, 1050, 121750, 144, 88, 232, 4, 3, 32}, 1, 0},
- { {1440, 900, 106500, 152, 80, 232, 6, 3, 25}, 1, 0},
- { {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30}, 1, 0},
- { {1366, 768, 85500, 143, 70, 213, 3, 3, 24}, 1, 1},
- { {1920, 1080, 148500, 44, 148, 80, 5, 4, 36}, 1, 1},
- { {1280, 768, 68250, 32, 48, 80, 7, 3, 12}, 0, 1},
- { {1400, 1050, 101000, 32, 48, 80, 4, 3, 23}, 0, 1},
- { {1680, 1050, 119000, 32, 48, 80, 6, 3, 21}, 0, 1},
- { {1280, 800, 79500, 32, 48, 80, 6, 3, 14}, 0, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1}
+static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
+{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 88, 148, 5, 2, 15, 1, 1, 1}, {5, HDMI_HDMI} },
+{ {1440, 240, 27027, 124, 38, 114, 3, 4, 15, 0, 0, 1}, {6, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 88, 148, 5, 4, 36, 1, 1, 0}, {16, HDMI_HDMI} },
+{ {720, 576, 27000, 64, 12, 68, 5, 5, 39, 0, 0, 0}, {17, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 440, 220, 5, 5, 20, 1, 1, 0}, {19, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 528, 148, 5, 2, 15, 1, 1, 1}, {20, HDMI_HDMI} },
+{ {1440, 288, 27000, 126, 24, 138, 3, 2, 19, 0, 0, 1}, {21, HDMI_HDMI} },
+{ {1440, 576, 54000, 128, 24, 136, 5, 5, 39, 0, 0, 0}, {29, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 528, 148, 5, 4, 36, 1, 1, 0}, {31, HDMI_HDMI} },
+{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
+{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
+{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+/* VESA From Here */
+{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
+{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
+{ {848, 480, 33750, 112, 16, 112, 8 , 6, 23, 1, 1, 0}, {0xE, HDMI_DVI} },
+{ {1280, 768, 79500, 128, 64, 192, 7 , 3, 20, 1, 0, 0}, {0x17, HDMI_DVI} },
+{ {1280, 800, 83500, 128, 72, 200, 6 , 3, 22, 1, 0, 0}, {0x1C, HDMI_DVI} },
+{ {1360, 768, 85500, 112, 64, 256, 6 , 3, 18, 1, 1, 0}, {0x27, HDMI_DVI} },
+{ {1280, 960, 108000, 112, 96, 312, 3 , 1, 36, 1, 1, 0}, {0x20, HDMI_DVI} },
+{ {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38, 1, 1, 0}, {0x23, HDMI_DVI} },
+{ {1024, 768, 65000, 136, 24, 160, 6, 3, 29, 0, 0, 0}, {0x10, HDMI_DVI} },
+{ {1400, 1050, 121750, 144, 88, 232, 4, 3, 32, 1, 0, 0}, {0x2A, HDMI_DVI} },
+{ {1440, 900, 106500, 152, 80, 232, 6, 3,
Re: [PATCH v4 03/12] mfd: twl-core: Add initial DT support for twl4030/twl6030
On Thu, Dec 22, 2011 at 03:56:37PM +0100, Benoit Cousson wrote: Add initial device-tree support for twl familly chips. The current version is missing the regulator entries due to the lack of DT regulator bindings for the moment. Only the simple sub-modules that do not depend on platform_data information can be initialized properly. Add irqdomain support. Add documentation for the Texas Instruments TWL Integrated Chip. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Balaji T K balaj...@ti.com Cc: Graeme Gregory g...@slimlogic.co.uk Cc: Samuel Ortiz sa...@linux.intel.com --- diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index f1391c2..f0de088 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -200,6 +200,7 @@ config MENELAUS config TWL4030_CORE bool Texas Instruments TWL4030/TWL5030/TWL6030/TPS659x0 Support depends on I2C=y GENERIC_HARDIRQS + select IRQ_DOMAIN As discussed on linux-next, this breaks powerpc. Drivers cannot select IRQ_DOMAIN, it can only be selected by architectures. Drivers must depend on it instead. -- 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 1/3 REPOST] OMAPDSS: HDMI: Move Avi infoframe structure to
From: Mythri P K mythr...@ti.com
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the ip_data structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h | 42 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |8 +++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 40 ---
3 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 3cf5198..835cfb1 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -108,6 +108,47 @@ struct ti_hdmi_ip_ops {
};
+/*
+ * Refer to section 8.2 in HDMI 1.3 specification for
+ * details about infoframe databytes
+ */
+struct hdmi_core_infoframe_avi {
+ /* Y0, Y1 rgb,yCbCr */
+ u8 db1_format;
+ /* A0 Active information Present */
+ u8 db1_active_info;
+ /* B0, B1 Bar info data valid */
+ u8 db1_bar_info_dv;
+ /* S0, S1 scan information */
+ u8 db1_scan_info;
+ /* C0, C1 colorimetry */
+ u8 db2_colorimetry;
+ /* M0, M1 Aspect ratio (4:3, 16:9) */
+ u8 db2_aspect_ratio;
+ /* R0...R3 Active format aspect ratio */
+ u8 db2_active_fmt_ar;
+ /* ITC IT content. */
+ u8 db3_itc;
+ /* EC0, EC1, EC2 Extended colorimetry */
+ u8 db3_ec;
+ /* Q1, Q0 Quantization range */
+ u8 db3_q_range;
+ /* SC1, SC0 Non-uniform picture scaling */
+ u8 db3_nup_scaling;
+ /* VIC0..6 Video format identification */
+ u8 db4_videocode;
+ /* PR0..PR3 Pixel repetition factor */
+ u8 db5_pixel_repeat;
+ /* Line number end of top bar */
+ u16 db6_7_line_eoftop;
+ /* Line number start of bottom bar */
+ u16 db8_9_line_sofbottom;
+ /* Pixel number end of left bar */
+ u16 db10_11_pixel_eofleft;
+ /* Pixel number start of right bar */
+ u16 db12_13_pixel_sofright;
+};
+
struct hdmi_ip_data {
void __iomem*base_wp; /* HDMI wrapper */
unsigned long core_sys_offset;
@@ -117,6 +158,7 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+ struct hdmi_core_infoframe_avi avi_cfg;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index ccc6254..b66d82e 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -534,12 +534,12 @@ static void hdmi_core_video_config(struct hdmi_ip_data
*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)
+static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data)
{
u32 val;
char sum = 0, checksum = 0;
void __iomem *av_base = hdmi_av_base(ip_data);
+ struct hdmi_core_infoframe_avi info_avi = ip_data-avi_cfg;
sum += 0x82 + 0x002 + 0x00D;
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_TYPE, 0x082);
@@ -718,7 +718,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
struct omap_video_timings video_timing;
struct hdmi_video_format video_format;
/* HDMI core */
- struct hdmi_core_infoframe_avi avi_cfg;
+ struct hdmi_core_infoframe_avi avi_cfg = ip_data-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;
@@ -780,7 +780,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
avi_cfg.db10_11_pixel_eofleft = 0;
avi_cfg.db12_13_pixel_sofright = 0;
- hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
+ hdmi_core_aux_infoframe_avi_config(ip_data);
/* enable/repeat the infoframe */
repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 914bec6..21f1d82 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -450,46 +450,6 @@ struct hdmi_core_video_config {
* Refer to section 8.2 in HDMI 1.3 specification for
* details about infoframe databytes
*/
-struct hdmi_core_infoframe_avi {
- /* Y0, Y1 rgb,yCbCr */
- u8 db1_format;
-
[PATCH 3/3 REPOST] OMAPDSS: HDMI: Add sysfs support to configure
From: Mythri P K mythr...@ti.com
Add sysfs support for the uset space to configure limited range or full range
quantization for HDMI.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h |2 +
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/hdmi.c | 28 +
drivers/video/omap2/dss/hdmi_panel.c | 35 +++-
drivers/video/omap2/dss/ti_hdmi.h |2 +
5 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 6308fc5..cf1f0f9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -498,6 +498,8 @@ int omapdss_hdmi_display_check_timing(struct
omap_dss_device *dssdev,
struct omap_video_timings *timings);
int omapdss_hdmi_read_edid(u8 *buf, int len);
bool omapdss_hdmi_detect(void);
+int omapdss_hdmi_get_range(void);
+int omapdss_hdmi_set_range(int range);
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index b402699..c7e71b9 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -465,6 +465,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.dump_core = ti_hdmi_4xxx_core_dump,
.dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
+ .configure_range= ti_hdmi_4xxx_configure_range,
};
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 34f3dae..3a9a1a2 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -377,6 +377,34 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
hdmi_runtime_put();
}
+int omapdss_hdmi_set_range(int range)
+{
+ int r = 0;
+ enum hdmi_range old_range;
+
+ old_range = hdmi.ip_data.range;
+ hdmi.ip_data.range = range;
+
+ /* HDMI 1.3 section 6.6 VGA (640x480) format requires Full Range */
+ if ((range == 0)
+ ((hdmi.ip_data.cfg.cm.code == 4
+ hdmi.ip_data.cfg.cm.mode == HDMI_DVI) ||
+ (hdmi.ip_data.cfg.cm.code == 1
+ hdmi.ip_data.cfg.cm.mode == HDMI_HDMI)))
+ return -EINVAL;
+
+ r = hdmi.ip_data.ops-configure_range(hdmi.ip_data);
+ if (r)
+ hdmi.ip_data.range = old_range;
+
+ return r;
+}
+
+int omapdss_hdmi_get_range(void)
+{
+ return hdmi.ip_data.range;
+}
+
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index 533d5dc..c0aa922 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -33,6 +33,33 @@ static struct {
struct mutex hdmi_lock;
} hdmi;
+static ssize_t hdmi_range_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int r;
+
+ r = omapdss_hdmi_get_range();
+ return snprintf(buf, PAGE_SIZE, %d\n, r);
+}
+
+static ssize_t hdmi_range_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ unsigned long range;
+ int r = kstrtoul(buf, 0, range);
+
+ if (r || range 1)
+ return -EINVAL;
+
+ r = omapdss_hdmi_set_range(range);
+ if (r)
+ return r;
+
+ return size;
+}
+
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, hdmi_range_show,
hdmi_range_store);
static int hdmi_panel_probe(struct omap_dss_device *dssdev)
{
@@ -41,6 +68,12 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
dssdev-panel.config = OMAP_DSS_LCD_TFT |
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
+ /* sysfs entry to provide user space control to set
+* quantization range
+*/
+ if (device_create_file(dssdev-dev, dev_attr_range))
+ DSSERR(failed to create sysfs file\n);
+
dssdev-panel.timings = (struct omap_video_timings){640, 480, 25175,
96, 16, 48, 2 , 11, 31};
DSSDBG(hdmi_panel_probe x_res= %d y_res = %d\n,
@@ -51,7 +84,7 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
static void hdmi_panel_remove(struct omap_dss_device *dssdev)
{
-
+ device_remove_file(dssdev-dev, dev_attr_range);
}
static int hdmi_panel_enable(struct omap_dss_device *dssdev)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 1b485ee..1f15d74 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -111,6 +111,8 @@ struct ti_hdmi_ip_ops {
void (*dump_phy)(struct
[PATCH 2/3 REPOST] OMAPDSS: HDMI: Add support to configure quantization
From: Mythri P K mythr...@ti.com
Configure the IP to support the limited range and full range quantization
mode. If the full range is configured HDMI transmitter will expand the range
of pixel data from 16-235 to full 8 bit 0-235.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h |7 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 40 +
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 835cfb1..1b485ee 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -42,6 +42,11 @@ enum hdmi_clk_refsel {
HDMI_REFSEL_SYSCLK = 3
};
+enum hdmi_range {
+ HDMI_LIMITED_RANGE = 0,
+ HDMI_FULL_RANGE = 1,
+};
+
/* HDMI timing structure */
struct hdmi_video_timings {
u16 x_res;
@@ -159,6 +164,7 @@ struct hdmi_ip_data {
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
struct hdmi_core_infoframe_avi avi_cfg;
+ enum hdmi_range range;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
@@ -172,5 +178,6 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index b66d82e..a98ce8a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -610,6 +610,46 @@ static void hdmi_core_aux_infoframe_avi_config(struct
hdmi_ip_data *ip_data)
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_CHSUM, checksum);
}
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data)
+{
+ int var;
+
+ switch (ip_data-range) {
+ /*
+* Setting the AVI infroframe to respective limited range
+* 0 if limited range 1 if full range
+*/
+ case HDMI_LIMITED_RANGE:
+ ip_data-avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_LR;
+ hdmi_core_aux_infoframe_avi_config(ip_data);
+ var = hdmi_read_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN);
+ var = FLD_MOD(var, 1, 1, 1);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN, var);
+ break;
+ case HDMI_FULL_RANGE:
+ default:
+ /* HDMI 1.3 section 6.6 YCBCR components shall
+* always be Limited Range
+*/
+ if (ip_data-avi_cfg.db1_format ==
+ HDMI_INFOFRAME_AVI_DB1Y_YUV422) {
+ pr_err(Only limited range is supported for YUV);
+ return -EINVAL;
+ }
+ ip_data-avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_FR;
+ hdmi_core_aux_infoframe_avi_config(ip_data);
+ var = hdmi_read_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_MODE);
+ var = FLD_MOD(var, 1, 4, 4);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_MODE, var);
+ break;
+ }
+ return 0;
+}
+
static void hdmi_core_av_packet_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_packet_enable_repeat repeat_cfg)
{
--
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 1/3 REPOST] OMAPDSS: HDMI: Move Avi infoframe structure to
From: Mythri P K mythr...@ti.com
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the ip_data structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h | 42 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |8 +++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 40 ---
3 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 3cf5198..835cfb1 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -108,6 +108,47 @@ struct ti_hdmi_ip_ops {
};
+/*
+ * Refer to section 8.2 in HDMI 1.3 specification for
+ * details about infoframe databytes
+ */
+struct hdmi_core_infoframe_avi {
+ /* Y0, Y1 rgb,yCbCr */
+ u8 db1_format;
+ /* A0 Active information Present */
+ u8 db1_active_info;
+ /* B0, B1 Bar info data valid */
+ u8 db1_bar_info_dv;
+ /* S0, S1 scan information */
+ u8 db1_scan_info;
+ /* C0, C1 colorimetry */
+ u8 db2_colorimetry;
+ /* M0, M1 Aspect ratio (4:3, 16:9) */
+ u8 db2_aspect_ratio;
+ /* R0...R3 Active format aspect ratio */
+ u8 db2_active_fmt_ar;
+ /* ITC IT content. */
+ u8 db3_itc;
+ /* EC0, EC1, EC2 Extended colorimetry */
+ u8 db3_ec;
+ /* Q1, Q0 Quantization range */
+ u8 db3_q_range;
+ /* SC1, SC0 Non-uniform picture scaling */
+ u8 db3_nup_scaling;
+ /* VIC0..6 Video format identification */
+ u8 db4_videocode;
+ /* PR0..PR3 Pixel repetition factor */
+ u8 db5_pixel_repeat;
+ /* Line number end of top bar */
+ u16 db6_7_line_eoftop;
+ /* Line number start of bottom bar */
+ u16 db8_9_line_sofbottom;
+ /* Pixel number end of left bar */
+ u16 db10_11_pixel_eofleft;
+ /* Pixel number start of right bar */
+ u16 db12_13_pixel_sofright;
+};
+
struct hdmi_ip_data {
void __iomem*base_wp; /* HDMI wrapper */
unsigned long core_sys_offset;
@@ -117,6 +158,7 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+ struct hdmi_core_infoframe_avi avi_cfg;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index ccc6254..b66d82e 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -534,12 +534,12 @@ static void hdmi_core_video_config(struct hdmi_ip_data
*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)
+static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data)
{
u32 val;
char sum = 0, checksum = 0;
void __iomem *av_base = hdmi_av_base(ip_data);
+ struct hdmi_core_infoframe_avi info_avi = ip_data-avi_cfg;
sum += 0x82 + 0x002 + 0x00D;
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_TYPE, 0x082);
@@ -718,7 +718,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
struct omap_video_timings video_timing;
struct hdmi_video_format video_format;
/* HDMI core */
- struct hdmi_core_infoframe_avi avi_cfg;
+ struct hdmi_core_infoframe_avi avi_cfg = ip_data-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;
@@ -780,7 +780,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
avi_cfg.db10_11_pixel_eofleft = 0;
avi_cfg.db12_13_pixel_sofright = 0;
- hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
+ hdmi_core_aux_infoframe_avi_config(ip_data);
/* enable/repeat the infoframe */
repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 914bec6..21f1d82 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -450,46 +450,6 @@ struct hdmi_core_video_config {
* Refer to section 8.2 in HDMI 1.3 specification for
* details about infoframe databytes
*/
-struct hdmi_core_infoframe_avi {
- /* Y0, Y1 rgb,yCbCr */
- u8 db1_format;
-
RE: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
Hello, On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote: [...] - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + !uart_debug) device_init_wakeup(pdev-dev, true); } I was testing this on AM335x and realized that this leads to creation of two 'wakeup' entries for UART. One is created by the tty layer in serial-core.c and the other is created here. Here's what I see on a branch based on Tony's 3.2-rc6: ./sys/devices/platform/omap/omap_uart.0/power/wakeup ./sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup Shouldn't the OMAP serial just enable the 'wakeup' entry created by serial-core.c? Regards, Vaibhav -- 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/2] MFD: TPS65217: Add new mfd device for TPS65217
Hi Mark, +/* All register addresses */ +#define TPS65217_REG_CHIPID 0X00 You should verify this as part of the probe() routine - read it back to make sure it's what's expected, and log the chip revision too in case it is useful for diagnostics. Added chip verification code to mfd probe and printing the regulator ID version number. TPS65217 has two versions A and B. i. TPS65217A - not supporting DVFS on AM335X ii. TPS65217B - supports DVFS on AM335X Right now I am supporting the version B but not A since I am testing DVFS on AM335X. I have BeagleBone with me having TPS65217B, but the CHIPID reads 0x70 (corresponds to TPS65217A)! I am discussing with hardware folks on what to do about this, but for now I will skip interpreting the CHIPID. I can print it out for reference though. Thanks AnilKumar -- 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 v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
Hi Vaibhav, On Mon, Jan 2, 2012 at 2:55 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: Hello, On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote: [...] - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + !uart_debug) device_init_wakeup(pdev-dev, true); } I was testing this on AM335x and realized that this leads to creation of two 'wakeup' entries for UART. One is created by the tty layer in serial-core.c and the other is created here. Here's what I see on a branch based on Tony's 3.2-rc6: ./sys/devices/platform/omap/omap_uart.0/power/wakeup ./sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup Shouldn't the OMAP serial just enable the 'wakeup' entry created by serial-core.c? currently runtime pm is available from omap-serial device and not from tty_dev. Setting tty_dev wakeup is to use irq_wakeup from suspend available from serail_core layer which I think we are not using for omap-uart and we use pad wakeup from suspend path. Also omap-uart.x/power/wakeup is used to gate uart clocks using runtime PM api's in omap-serial driver. -- Thanks, Govindraj.R -- 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/2] MFD: TPS65217: Add new mfd device for TPS65217
On Mon, Jan 02, 2012 at 09:48:40AM +, AnilKumar, Chimata wrote: I am discussing with hardware folks on what to do about this, but for now I will skip interpreting the CHIPID. I can print it out for reference though. Logging for diagnostics is probably enough - it'll verify that register access to the device and mean that the value is available if it's useful for debugging problems. -- 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 v2 2/4] ASoC: cx20442: add bias control over a platform provided regulator
On Fri, Dec 30, 2011 at 04:04:54AM +0100, Janusz Krzysztofik wrote: Now that a regulator device for controlling the codec chip reset state over a platform agnostic regulator API is available on the only board using this driver so far, extend the driver with a bias control function which will request virtual power to the codec chip from that virtual regulator, and will supersede the present implementation existing at the sound card level. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- 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 v2 4/4] ASoC: OMAP: ams-delta: drop .set_bias_level callback
On Fri, Dec 30, 2011 at 04:04:56AM +0100, Janusz Krzysztofik wrote: This functionality has just been implemented in the cx20442 codec driver, no need to keep it here duplicated. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- 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 0/2] Add TI TPS65217 PMIC driver support
TPS65217 power management IC supports various features, like Battery charger, white LED driver along with basic regulator Functionality. This patch set adds support as an MFD device into the kernel to facilitate adding additional drivers on top of it. This device is used on one of AM335x platform (BeagleBone), and details about board can be accessed at - http://beagleboard.org/bone Device Spec and related documents can be accessed from - http://www.ti.com/product/tps65217b Changes form V1: - Incorporated all Mark Brown's review commets * MFD read/writes API's modifed to use regmap read/writes * kzalloc() changed to devm_kzalloc() * Converted voltage tables to function calls * set_voltage() changed to set_voltage_sel() - cleaned-up the code little bit AnilKumar Ch (2): MFD: TPS65217: Add new mfd device for TPS65217 TPS65217: Add tps65217 regulator driver drivers/mfd/Kconfig| 15 + drivers/mfd/Makefile |1 + drivers/mfd/tps65217.c | 199 ++ drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/tps65217-regulator.c | 459 include/linux/mfd/tps65217.h | 271 +++ 7 files changed, 955 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/tps65217.c create mode 100644 drivers/regulator/tps65217-regulator.c create mode 100644 include/linux/mfd/tps65217.h -- 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 1/2] MFD: TPS65217: Add new mfd device for TPS65217
The TPS65217 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators
- White LED
- USB battery charger
This patch adds support for tps65217 mfd device. At this time only
the regulator functionality is made available.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/mfd/Kconfig | 15 +++
drivers/mfd/Makefile |1 +
drivers/mfd/tps65217.c | 199 +++
include/linux/mfd/tps65217.h | 271 ++
4 files changed, 486 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/tps65217.c
create mode 100644 include/linux/mfd/tps65217.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f1391c2..d2c55e8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -142,6 +142,21 @@ config TPS6507X
This driver can also be built as a module. If so, the module
will be called tps6507x.
+config MFD_TPS65217
+ tristate TPS65217 Power Management / White LED chips
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the TPS65217 series of
+ Power Management / White LED chips.
+ These include voltage regulators, lithium ion/polymer battery
+ charger, wled and other features that are often used in portable
+ devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called tps65217.
+
config MFD_TPS6586X
bool TPS6586x Power Management chips
depends on I2C=y GPIOLIB GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b2292eb..7a6d111 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_MFD_WM8994) += wm8994-core.o wm8994-irq.o
obj-$(CONFIG_TPS6105X) += tps6105x.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_TPS6507X) += tps6507x.o
+obj-$(CONFIG_MFD_TPS65217) += tps65217.o
obj-$(CONFIG_MFD_TPS65910) += tps65910.o tps65910-irq.o
tps65912-objs := tps65912-core.o tps65912-irq.o
obj-$(CONFIG_MFD_TPS65912) += tps65912.o
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
new file mode 100644
index 000..3a96d70
--- /dev/null
+++ b/drivers/mfd/tps65217.c
@@ -0,0 +1,199 @@
+/*
+ * tps65217.c
+ *
+ * TPS65217 chip family multi-function driver
+ *
+ * Copyright (C) 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 as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/types.h
+#include linux/platform_device.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/err.h
+
+#include linux/mfd/core.h
+#include linux/mfd/tps65217.h
+
+/**
+ * tps65217_reg_read: Read a single tps65217 register.
+ *
+ * @tps: Device to read from.
+ * @reg: Register to read.
+ * @val: Contians the value
+ */
+int tps65217_reg_read(struct tps65217 *tps, unsigned int reg,
+ unsigned int *val)
+{
+ return regmap_read(tps-regmap, reg, val);
+}
+EXPORT_SYMBOL_GPL(tps65217_reg_read);
+
+/**
+ * tps65217_reg_write: Write a single tps65217 register.
+ *
+ * @tps65217: Device to write to.
+ * @reg: Register to write to.
+ * @val: Value to write.
+ * @level: Password protected level
+ */
+int tps65217_reg_write(struct tps65217 *tps, unsigned int reg,
+ unsigned int val, unsigned int level)
+{
+ int err;
+ unsigned int xor_reg_val;
+
+ switch (level) {
+ case TPS65217_PROTECT_NONE:
+ return regmap_write(tps-regmap, reg, val);
+ case TPS65217_PROTECT_L1:
+ xor_reg_val = reg ^ TPS65217_PASSWORD_REGS_UNLOCK;
+ err = regmap_write(tps-regmap, TPS65217_REG_PASSWORD,
+ xor_reg_val);
+ if (err 0)
+ return err;
+
+ return regmap_write(tps-regmap, reg, val);
+ case TPS65217_PROTECT_L2:
+ xor_reg_val = reg ^ TPS65217_PASSWORD_REGS_UNLOCK;
+ err = regmap_write(tps-regmap, TPS65217_REG_PASSWORD,
+ xor_reg_val);
+ if (err 0)
+ return err;
+ err = regmap_write(tps-regmap, reg, val);
+
[PATCH V2 2/2] TPS65217: Add tps65217 regulator driver
This patch adds tps65217 PMIC as a regulator
The regulator module consists of 3 DCDCs and 4 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/regulator/Kconfig |9 +
drivers/regulator/Makefile |1 +
drivers/regulator/tps65217-regulator.c | 459
3 files changed, 469 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/tps65217-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 9713b1b..9fcc919 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -259,6 +259,15 @@ config REGULATOR_TPS6507X
three step-down converters and two general-purpose LDO voltage
regulators.
It supports TI's software based Class-2 SmartReflex implementation.
+config REGULATOR_TPS65217
+ tristate TI TPS65217 Power regulators
+ depends on (I2C MFD_TPS65217)
+ help
+ This driver supports TPS65217 voltage regulator chips. TPS65217
+ provides three step-down converters and four general-purpose LDO
+ voltage regulators. It supports software based voltage control
+ for different voltage domains
+
config REGULATOR_TPS65912
tristate TI TPS65912 Power regulator
depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 93a6318..aeae546 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o
obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
obj-$(CONFIG_REGULATOR_TPS6507X) += tps6507x-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65217) += tps65217-regulator.o
obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
diff --git a/drivers/regulator/tps65217-regulator.c
b/drivers/regulator/tps65217-regulator.c
new file mode 100644
index 000..65540ff
--- /dev/null
+++ b/drivers/regulator/tps65217-regulator.c
@@ -0,0 +1,459 @@
+/*
+ * tps65217-regulator.c
+ *
+ * Regulator driver for TPS65217 PMIC
+ *
+ * Copyright (C) 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 as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/mfd/tps65217.h
+
+#define TPS65217_REGULATOR(_name, _id, _ops, _n) \
+ { \
+ .name = _name,\
+ .id = _id, \
+ .ops= _ops,\
+ .n_voltages = _n, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ } \
+
+#define TPS65217_INFO(_name, _fun, _n, _emsk, _vreg, _vmsk)\
+ { \
+ .name = _name,\
+ .tps_range = _fun, \
+ .table_len = _n, \
+ .enable_mask= _emsk,\
+ .set_vout_reg = _vreg,\
+ .set_vout_mask = _vmsk,\
+ }
+
+static unsigned int tps65217_vsel_to_uv_range0(unsigned int vsel)
+{
+ unsigned int uV = 0;
+
+ if (vsel = 24)
+ uV = ((vsel * 25000) + 90);
+ else if (vsel 24 vsel = 52)
+ uV = (((vsel - 24) * 5) + 150);
+ else if (vsel 52 vsel = 56)
+ uV = (((vsel - 52) * 10) + 290);
+ else
+ uV = 330;
+
+ return uV;
+}
+
+static unsigned int tps65217_vsel_to_uv_range1(unsigned int vsel)
+{
+ unsigned int uV = 0;
+
+ if (vsel = 2)
+ uV = ((vsel * 10) + 100);
+ else if (vsel 2 vsel = 6)
+ uV = (((vsel - 2) * 5) + 120);
+ else if (vsel 6 vsel = 9)
+ uV = (((vsel - 6) * 10) + 140);
+
Re: [PATCH V2 2/2] TPS65217: Add tps65217 regulator driver
On Mon, Jan 02, 2012 at 06:18:42PM +0530, AnilKumar Ch wrote:
This patch adds tps65217 PMIC as a regulator
Use subject lines appropriate for the subsystem you're submitting
against.
+config REGULATOR_TPS65217
+ tristate TI TPS65217 Power regulators
+ depends on (I2C MFD_TPS65217)
Should only depend on the MFD, there's no direct I2C usage.
+static unsigned int tps65217_vsel_to_uv_range0(unsigned int vsel)
+{
+ unsigned int uV = 0;
+
+ if (vsel = 24)
+ uV = ((vsel * 25000) + 90);
+ else if (vsel 24 vsel = 52)
+ uV = (((vsel - 24) * 5) + 150);
+ else if (vsel 52 vsel = 56)
+ uV = (((vsel - 52) * 10) + 290);
No need for the checks as this is already taken care of by being in
the else clause.
+static unsigned int tps65217_vsel_to_uv_range2(unsigned int vsel)
+{
+ unsigned int uV = 0;
+
+ if (vsel = 8)
+ uV = ((vsel * 5) + 150);
+ else if (vsel 9 vsel = 13)
+ uV = (((vsel - 8) * 10) + 190);
+ else if (vsel 13)
+ uV = (((vsel - 13) * 5) + 240);
+
+ return uV;
In all of these functions there ought to be a check to make sure vsel
isn't out of range and return an error if it is.
+static int tps65217_pmic_set_bits(struct tps65217 *tps, unsigned int reg,
+ unsigned int mask, unsigned int val, unsigned int level)
+{
To repeat what I said when reviewing the previous version of the patch
things like this shouldn't be open coded in individual function drivers,
they should be in the MFD driver. There is *nothing* PMIC specific
about register access.
I've stopped reading at this point.
--
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: It looks like snd-soc-rx51 only works as built-in, not as a module
On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Fri, Dec 30, 2011 at 10:00:55PM +0200, Felipe Contreras wrote: On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote: That should not be required, the modules should be loadable in any order. Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51. That is compltelely orthogonal to what you were saying above about the ordering of module loading. Not really, because if both are compiled as modules, snd_soc_tlv320aic3x will always be loaded first (automatically by udev). Which is relevant because...? To repeat, the ordering of module loading is totally ortogonal as any ordering of modules is supported. You appear to be totally ignoring what I am writing here. One thing how things _should_ be, and another is how things actually _are_. Right now snd-soc-rx51 doesn't work if it's loaded before snd_soc_tlv320aic3x. Period. That means that *right now*, snd-soc-rx51 works fine with udev, because snd_soc_tlv320aic3x will be loaded at boot time. Now, if snd-soc-rx51 is converted and loaded automatically by udev as well, the issues might appear again. The reason the driver is not loaded automatically is that the OMAP machine drivers have not been converted to platform devices. Well, if that's the case then there's a real issue. There doesn't seem to be a MODULE_DEPENDS(), or anything like that. A MODULE_DEPENDS() would also be irrelevant here. Ok. snd-soc-rx51 seems to depend on snd_soc_tlv320aic3x through codec_dai_name, and codec_name, and so on. I don't know how this dependency is supposed to work out. All the drivers should load via the normal driver instantiation mechainsms and when they're all there they'll get matched together. Ok, I hope so. -- Felipe Contreras -- 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: It looks like snd-soc-rx51 only works as built-in, not as a module
On Mon, Jan 02, 2012 at 08:33:03PM +0200, Felipe Contreras wrote: On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown Which is relevant because...? To repeat, the ordering of module loading is totally ortogonal as any ordering of modules is supported. You appear to be totally ignoring what I am writing here. One thing how things _should_ be, and another is how things actually _are_. Right now snd-soc-rx51 doesn't work if it's loaded before snd_soc_tlv320aic3x. Period. Can you provide logs showing this (with debug logging enabled in soc-core)? If this is happening it's a very serious issue, though I am rather surprised that nobody else has noticed such an issue since the usual instantiation order would have the card appear before the CODEC (due to the fact that the card is normally a platform device) and the structure of the code makes it difficult to imagine a failure path. That means that *right now*, snd-soc-rx51 works fine with udev, because snd_soc_tlv320aic3x will be loaded at boot time. Now, if snd-soc-rx51 is converted and loaded automatically by udev as well, the issues might appear again. Not if we look at and resolve the actual issue. Once again, any instantation ordering should be supported. I really don't understand why you keep on talking about fixing the module ordering, -- 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] omap_hsmmc - use threaded irq handler for card-detect.
Hi Neil, On Fri, Dec 30 2011, Kishore Kadiyala wrote: On Thu, Dec 29, 2011 at 8:35 PM, NeilBrown ne...@suse.de wrote: As the card-detect irq handler just schedules work to be done by a thread, we can use request_threaded_irq to do much of the work for us. This means that interrupts which arrive by handle_nested_irq actually work. Reviewed-by: Felipe Balbi ba...@ti.com Tested-by: Grazvydas Ignotas nota...@gmail.com Signed-off-by: NeilBrown ne...@suse.de I have done some thing similar but didn't pushed it :-( Anyways Acked-by: Kishore Kadiyala kishorek.kadiy...@gmail.com Pushed with Kishore's ACK to mmc-next for 3.3, thanks. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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: It looks like snd-soc-rx51 only works as built-in, not as a module
Felipe Contreras felipe.contre...@gmail.com writes: On Sat, Dec 31, 2011 at 2:59 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Fri, Dec 30, 2011 at 10:00:55PM +0200, Felipe Contreras wrote: On Thu, Dec 29, 2011 at 11:54 PM, Mark Brown On Thu, Dec 29, 2011 at 11:51:11PM +0200, Felipe Contreras wrote: That should not be required, the modules should be loadable in any order. Yes, but udev loads snd_soc_tlv320aic3x, not snd-soc-rx51. That is compltelely orthogonal to what you were saying above about the ordering of module loading. Not really, because if both are compiled as modules, snd_soc_tlv320aic3x will always be loaded first (automatically by udev). Which is relevant because...? To repeat, the ordering of module loading is totally ortogonal as any ordering of modules is supported. You appear to be totally ignoring what I am writing here. One thing how things _should_ be, and another is how things actually _are_. Right now snd-soc-rx51 doesn't work if it's loaded before snd_soc_tlv320aic3x. Period. That means that *right now*, snd-soc-rx51 works fine with udev, because snd_soc_tlv320aic3x will be loaded at boot time. Now, if snd-soc-rx51 is converted and loaded automatically by udev as well, the issues might appear again. The reason the driver is not loaded automatically is that the OMAP machine drivers have not been converted to platform devices. Well, if that's the case then there's a real issue. There doesn't seem to be a MODULE_DEPENDS(), or anything like that. A MODULE_DEPENDS() would also be irrelevant here. Ok. snd-soc-rx51 seems to depend on snd_soc_tlv320aic3x through codec_dai_name, and codec_name, and so on. I don't know how this dependency is supposed to work out. All the drivers should load via the normal driver instantiation mechainsms and when they're all there they'll get matched together. Ok, I hope so. Does this patch change anything? http://article.gmane.org/gmane.linux.alsa.devel/89052 -- Måns Rullgård m...@mansr.com -- 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 5/5] bq27x00 - don't report power-supply change so often.
On Sat, 31 Dec 2011 12:27:43 +0100 Lars-Peter Clausen l...@metafoo.de wrote:
On 12/30/2011 12:13 PM, Grazvydas Ignotas wrote:
CCing Lars who added this. I vaguely recall something about generating
events to make some battery monitors update but I forget the details
now, maybe it was about something else. Also CCing Anton (the
maintainer).
On Fri, Dec 30, 2011 at 2:58 AM, NeilBrown ne...@suse.de wrote:
A power_supply_changed should only be reported on significant changes
such as transition between charging and not. Incremental changes
such as charge increasing should not be reported - that can easily
be polled for.
Well, you can also poll for those significant changes, too. The point of
adding this was to have a centralized point where polling takes place instead
of letting each battery monitor do this on its own. Though if, as you wrote in
the cover letter, the some properties change every time the values are read it
might makes sense to exclude these from the comparison. On the other hand one
event every 6 minutes doesn't really sound harmful and I would suspect that
battery monitors will use a similar interval when manually polling the device.
Hi,
That is a very good point. user-space could poll for all of the changes and
polling the kernel provides no real benefit.
I don't really see the problem with each battery monitor doing their own
polling. At least that way they would have control over when polling
happens.
Polling every 6 minutes does not really seem like a lot - except that
polling at all in the kernel should be avoided. If the system is idle and
has managed to get into a lower power state, waking up just to check on the
battery would be the wrong thing to do.
A battery monitor could notice that no-one cared (e.g. A X11 client not
getting any 'expose' events) and could stop polling. The kernel cannot do
that.
However the part of the current code that really bothered me was that a
'change' event is generated every time anyone polls the battery status - but
at most every 5 seconds. These extra change events really aren't wanted.
I think we should always be cautious of adding change events. They are
not there just to report when any detail changed, else a 'keyboard' device
would report a 'change' event on every keystroke.
The main purpose of uevents are to report 'add' and 'remove' of devices.
'change' is for situations where a device changes in a way that is very
similar to an 'add' or a 'remove' but isn't implemented as a new device.
A simple example is inserting a CD into a CD drive. Before the device
couldn't do anything useful, now it can. It is a new medium, which is
almost like a new device but just not implemented that way. So it deserves a
change event.
Or when a power supply gets plugged in. We really have a new thing here -
we have added power. But as the power isn't a device we cannot have an
'add' uevent, so we have a 'change' uevent on the power supply.
So I would be in favour of removing the in-kernel polling altogether.
That puts complete control where it belongs: is the app that is monitoring
the battery.
Thoughts??
Thanks,
NeilBrown
- Lars
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/bq27x00_battery.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/power/bq27x00_battery.c
b/drivers/power/bq27x00_battery.c
index bb16f5b..7993a17 100644
--- a/drivers/power/bq27x00_battery.c
+++ b/drivers/power/bq27x00_battery.c
@@ -57,11 +57,15 @@
#define BQ27000_FLAG_CHGS BIT(7)
#define BQ27000_FLAG_FCBIT(5)
+#define BQ27000_FLAGS_IMPORTANT
(BQ27000_FLAG_FC|BQ27000_FLAG_CHGS|BIT(31))
+
#define BQ27500_REG_SOC0x2C
#define BQ27500_REG_DCAP 0x3C /* Design capacity */
#define BQ27500_FLAG_DSC BIT(0)
#define BQ27500_FLAG_FCBIT(9)
+#define BQ27500_FLAGS_IMPORTANT
(BQ27500_FLAG_FC|BQ27500_FLAG_DSC|BIT(31))
+
#define BQ27000_RS 20 /* Resistor sense */
struct bq27x00_device_info;
@@ -259,6 +263,7 @@ static void bq27x00_update(struct bq27x00_device_info
*di)
{
struct bq27x00_reg_cache cache = {0, };
bool is_bq27500 = di-chip == BQ27500;
+ int flags_changed;
cache.flags = bq27x00_read(di, BQ27x00_REG_FLAGS, is_bq27500);
if (cache.flags = 0) {
@@ -280,10 +285,14 @@ static void bq27x00_update(struct
bq27x00_device_info *di)
/* Ignore current_now which is a snapshot of the current battery
state
* and is likely to be different even between two consecutive reads
*/
- if (memcmp(di-cache, cache, sizeof(cache) - sizeof(int)) != 0) {
- di-cache = cache;
+ flags_changed = di-cache.flags ^ cache.flags;
+ di-cache =
Re: [PATCH 0/4] OMAPDSS/ASoC: Repair broken HDMI audio in K3.2-rcX
Hi Mythri, Mark, On Thu, 2011-12-29 at 18:48 +, Mark Brown wrote: On Thu, Dec 29, 2011 at 03:26:48PM +0530, K, Mythri P wrote: We could not also try to move the ASoC HDMI audio codec driver from DSS to sound, but this is good for now. You should certainly send the driver for review on the ALSA list... Yes, the goal is to move the ASoC OMAP4 HDMI codec to sound for K3.3. I will submit to the ALSA list when I have a first draft. Thanks, Ricardo -- 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 V2 2/2] TPS65217: Add tps65217 regulator driver
Hi Mark,
On Mon, Jan 02, 2012 at 18:46:48, Mark Brown wrote:
On Mon, Jan 02, 2012 at 06:18:42PM +0530, AnilKumar Ch wrote:
This patch adds tps65217 PMIC as a regulator
Use subject lines appropriate for the subsystem you're submitting
against.
+config REGULATOR_TPS65217
+ tristate TI TPS65217 Power regulators
+ depends on (I2C MFD_TPS65217)
Should only depend on the MFD, there's no direct I2C usage.
Agree, removed I2C
+static unsigned int tps65217_vsel_to_uv_range0(unsigned int vsel)
+{
+ unsigned int uV = 0;
+
+ if (vsel = 24)
+ uV = ((vsel * 25000) + 90);
+ else if (vsel 24 vsel = 52)
+ uV = (((vsel - 24) * 5) + 150);
+ else if (vsel 52 vsel = 56)
+ uV = (((vsel - 52) * 10) + 290);
No need for the checks as this is already taken care of by being in
the else clause.
Changed
+static unsigned int tps65217_vsel_to_uv_range2(unsigned int vsel)
+{
+ unsigned int uV = 0;
+
+ if (vsel = 8)
+ uV = ((vsel * 5) + 150);
+ else if (vsel 9 vsel = 13)
+ uV = (((vsel - 8) * 10) + 190);
+ else if (vsel 13)
+ uV = (((vsel - 13) * 5) + 240);
+
+ return uV;
In all of these functions there ought to be a check to make sure vsel
isn't out of range and return an error if it is.
Added error checks as well.
+static int tps65217_pmic_set_bits(struct tps65217 *tps, unsigned int reg,
+ unsigned int mask, unsigned int val, unsigned int level)
+{
To repeat what I said when reviewing the previous version of the patch
things like this shouldn't be open coded in individual function drivers,
they should be in the MFD driver. There is *nothing* PMIC specific
about register access.
I've stopped reading at this point.
Mark sorry about this, password protected writes/update bits are required
only for regulator so I put it in regulator driver. I got your point, will
be moved to MFD driver.
Thanks for your patience here.
Regards,
AnilKumar
--
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 RFC] MFD: OMAP: USB: Make the runtime functions depend on CONFIG_PM_RUNTIME
Currently the runtime functions are compiled regardless
of CONFIG_PM_RUNTIME flag. This patch intends to fix the same by
using SET_RUNTIME_PM_OPS.
Cc : Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
applies on Tony's ehci branch.
Compile tested only.
drivers/mfd/omap-usb-host.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 3f565ef..ef72ebe 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -887,8 +887,8 @@ static int __devexit usbhs_omap_remove(struct
platform_device *pdev)
}
static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
- .runtime_suspend= usbhs_runtime_suspend,
- .runtime_resume = usbhs_runtime_resume,
+ SET_RUNTIME_PM_OPS(usbhs_runtime_suspend,
+ usbhs_runtime_resume, NULL)
};
static struct platform_driver usbhs_omap_driver = {
--
1.7.1
--
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
