Re: [PATCH 5/5 v4] mfd: omap: usb: Runtime PM support
On Tue, Aug 30, 2011 at 2:17 AM, Kevin Hilman khil...@ti.com wrote: Kevin Hilman khil...@ti.com writes: Keshava Munegowda keshava_mgo...@ti.com writes: From: Keshava Munegowda keshava_mgo...@ti.com The usbhs core driver does not enable/disable the intefrace and fucntional clocks; These clocks are handled by hwmod and runtime pm, hence insted of the clock enable/disable, the runtime pm APIS are used. however,the port clocks are handled by the usbhs core. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com General comment: all usage of pm_runtime_put_sync() can likely be replaced by the asynchronous versions. I don't currently see why the synchronous verions are needed here. Other than that, the runtime PM parts of this look OK to me. After changing to asynchonous puts, feel free to add: Reviewed-by: Kevin Hilman khil...@ti.com oops, this should've been in response to your v8 version. Kevin Also, after a quick glance, it looks like this version of the series addresses the problems seen by Jassi Brar with the TLL reset[1]. Please confirm. Speaking of which, it's helpful to Cc folks who have had comments on previous versions of your series so they are sure they're previous issues are addressed. I've Cc'd Jassi Brar. Thanks, Kevin [1] http://marc.info/?l=linux-omapm=130921260703865w=2 Thanks for review; yes, its reworks of complete runtime pm of usbhs as suggested by Jassi Brar. balbi, sameo this patch series available at the branch kmg-usbhs-pm of code repository : git://gitorious.org/~kmg/mirrors/kmg-usbhs-pm.git Regards Keshava -- 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] mfd: Add PWM1 and PWM2 support to twl6030-pwm
From: Hemanth V heman...@ti.com
Date: Fri, 26 Aug 2011 10:49:29 +0530
Subject: [PATCH] Add PWM1 and PWM2 support to twl6030-pwm driver
This patch adds support for PWM1/PWM2. TWL6030 PWM driver also
supports Indicator LED PWM. Function pointers are defined for
for init, enable, disable and configuration for both Indicator LED
PWM (led_pwm) and PWM1/PWM2 (std_pwm)
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Hemanth V heman...@ti.com
---
drivers/mfd/twl6030-pwm.c | 324 ++--
1 files changed, 309 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl6030-pwm.c b/drivers/mfd/twl6030-pwm.c
index e8fee14..8d9c3f5 100644
--- a/drivers/mfd/twl6030-pwm.c
+++ b/drivers/mfd/twl6030-pwm.c
@@ -5,6 +5,9 @@
* Copyright (C) 2010 Texas Instruments
* Author: Hemanth V heman...@ti.com
*
+ * Added support for PWM1, PWM2
+ * Hemanth V heman...@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.
@@ -36,7 +39,9 @@
#define PWM_CTRL2_CURR_02 (2 4)
/* LED supply source */
+#define PWM_CTRL2_SRC_VBUS (0 2)
#define PWM_CTRL2_SRC_VAC (1 2)
+#define PWM_CTRL2_SRC_EXT (2 2)
/* LED modes */
#define PWM_CTRL2_MODE_HW (0 0)
@@ -45,12 +50,53 @@
#define PWM_CTRL2_MODE_MASK0x3
+/* PWMs supported by driver */
+#define PWM_ID_LED 1
+#define PWM_ID_PWM12
+#define PWM_ID_PWM23
+
+#define LED_PWM1ON 0x00
+#define LED_PWM1OFF0x01
+#define LED_PWM2ON 0x03
+#define LED_PWM2OFF0x04
+#define TWL6030_TOGGLE30x92
+#define PWMSTATUS2 0x94
+
+/* Defines for TOGGLE3 register */
+#define PWM2EN (1 5)
+#define PWM2S (1 4)
+#define PWM2R (1 3)
+#define PWM1EN (1 2)
+#define PWM1S (1 1)
+#define PWM1R (1 0)
+
+/* Defines for PWMSTATUS2 register */
+#define PWM1_CLK_EN(1 1)
+#define PWM2_CLK_EN(1 3)
+#defineTRUE1
+#defineFALSE 0
+
+static DEFINE_MUTEX(pwm_lock);
+static LIST_HEAD(pwm_list);
+
+struct pwm_device;
+
+struct pwm_ops {
+ int (*config)(struct pwm_device *, int, int);
+ int (*enable)(struct pwm_device *);
+ void(*disable)(struct pwm_device *);
+ int (*init)(struct pwm_device *);
+};
+
struct pwm_device {
- const char *label;
- unsigned int pwm_id;
+ struct list_headnode;
+ const char *label;
+ unsigned intpwm_id;
+ unsigned intuse_count;
+ struct pwm_ops *ops;
};
-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+int led_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
{
u8 duty_cycle;
int ret;
@@ -69,9 +115,8 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int
period_ns)
}
return 0;
}
-EXPORT_SYMBOL(pwm_config);
-int pwm_enable(struct pwm_device *pwm)
+int led_pwm_enable(struct pwm_device *pwm)
{
u8 val;
int ret;
@@ -95,9 +140,8 @@ int pwm_enable(struct pwm_device *pwm)
twl_i2c_read_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
return 0;
}
-EXPORT_SYMBOL(pwm_enable);
-void pwm_disable(struct pwm_device *pwm)
+void led_pwm_disable(struct pwm_device *pwm)
{
u8 val;
int ret;
@@ -120,37 +164,284 @@ void pwm_disable(struct pwm_device *pwm)
}
return;
}
-EXPORT_SYMBOL(pwm_disable);
-struct pwm_device *pwm_request(int pwm_id, const char *label)
+int led_pwm_init(struct pwm_device *pwm)
{
u8 val;
int ret;
+
+ val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_02 | PWM_CTRL2_SRC_VBUS |
+ PWM_CTRL2_MODE_HW;
+
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
+
+ return ret;
+}
+
+static struct pwm_ops pwm_led = {
+ .config = led_pwm_config,
+ .enable = led_pwm_enable,
+ .disable = led_pwm_disable,
+ .init = led_pwm_init,
+};
+
+int std_pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
+{
+ int ret = 0, level, pwm_id, reg;
+
+ level = (duty_ns * PWM_CTRL1_MAX) / period_ns;
+ pwm_id = pwm-pwm_id;
+
+ if (pwm_id == PWM_ID_PWM1)
+ reg = LED_PWM1ON;
+ else
+ reg = LED_PWM2ON;
+
+ if (level 1) {
+ if (level == 255)
+ level = 0x7F;
+ else
+ level = (~(level/2)) 0x7F;
+
+ ret = twl_i2c_write_u8(TWL_MODULE_PWM, level, reg);
+ }
+
+ return ret;
+}
+
+void std_pwm_disable(struct pwm_device *pwm)
+{
+
+ int ret, pwm_id;
+ bool pwm1_enabled = FALSE;
+ bool pwm2_enabled =
Re: [GIT PULL v2] OMAP: clock/powerdomain/clockdomain/hwmod: fixes for 3.1-rc
Hi Tony, On Tue, 23 Aug 2011, Paul Walmsley wrote: The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c: Linux 3.1-rc3 (2011-08-22 11:42:53 -0700) are available in the git repository at: git://git.pwsan.com/linux-2.6 prcm-fixes-a-3.1rc Just checking up on this. Any issues with this branch? I've dropped Tomi's patches until the changelogs for those are fixed. Tomi's patches have been queued for 3.2, by the way. Note that for these changes to boot successfully on 3.1-rc3, the following patch is needed: http://marc.info/?l=linux-omapm=131407622527432w=2 And Linus has resolved this problem for 3.1-rc4 with commit 69dd3d8e29e294caaf63eb5e8a72d250279f9e5f (Revert irq: Always set IRQF_ONESHOT if no primary handler is specified). Paul Walmsley (4): OMAP4: clock: re-enable previous clockdomain enable/disable sequence OMAP4: clock: fix compile warning OMAP3: clock: indicate that gpt12_fck and wdt1_fck are in the WKUP clockdomain Merge branches 'pwrdm_clkdm_fixes_3.1rc', 'non_hwmod_compliant_fix_3.1rc', 'omap4_clock_fixes_3.1rc' and 'omap3_clock_fixes_3.1rc' into prcm-fixes-a-3.1rc Rajendra Nayak (1): OMAP: powerdomains: Make all powerdomain target states as ON at init Santosh Shilimkar (1): OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup arch/arm/mach-omap2/clock3xxx_data.c |2 ++ arch/arm/mach-omap2/clock44xx_data.c | 10 +- arch/arm/mach-omap2/clockdomain.c|2 ++ arch/arm/mach-omap2/pm.c |2 -- arch/arm/mach-omap2/powerdomain.c| 25 - 5 files changed, 29 insertions(+), 12 deletions(-) - 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: How to handle named resources with DT?
Hi, On Tue, Aug 30, 2011 at 12:29:12PM +1000, David Gibson wrote: So, I actually agree that in the long term getting resource names in the DT would be a generally good thing. But doing so is a *huge* change in one of the very core semantics of all the DT bindings. It's not something that should be done lightly or quickly. It absolutely should not be tied to how this is handled the longer you take to change, the more complex will it be to change. The longer we spend discussing the validity of _byname(), more boards/archs/whatnot will be converted to DT without _byname() and after a certain amount of them are converted, noone will be willing to change and validate everything again. -- balbi signature.asc Description: Digital signature
[PATCH 00/10] OMAP: DSS2: DSI: Initial DSI video mode support
This provided initial support for DSI Video Mode. The first 6 patches are not directly related to video mode, but they add required features and cleanup for supporting video mode cleanly. Support for a panel driver supporting video mode is not added yet since no OMAP platfrom support in mainline has a video mode panel. The Blaze tablet with the toshiba bridge chip TC358765 is used as an example to validate video mode support. The patches to enable blaze tablet and the bridge chip are provided in the following tree along with the DSI video mode patches: https://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone/commits/video-mode-4 Archit Taneja (10): OMAP: DSS2: Use MIPI DSI transacition types and commands from include/video/mipi_display.h OMAP: DSS2: DSI: Represent L4 and VP as sources of VC instead of modes OMAP: DSS2: Create enum for DSI operation modes OMAP: DSS2: DSI: Introduce generic write functions OMAP: DSS2: DSI: Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2() OMAP: DSS2: DSI: Split dsi_vc_dcs_read() into 2 functions OMAP: DSS2: DSI: Introduce generic read functions OMAP: DSS2: Clean up stallmode and io pad mode selection OMAP: DSS2: Create an enum for DSI pixel formats OMAP: DSS2: DSI Video mode support drivers/video/omap2/displays/panel-taal.c | 47 +-- drivers/video/omap2/dss/dispc.c | 47 +-- drivers/video/omap2/dss/dpi.c |5 +- drivers/video/omap2/dss/dsi.c | 675 ++--- drivers/video/omap2/dss/dss.h | 17 +- drivers/video/omap2/dss/rfbi.c|4 +- drivers/video/omap2/dss/sdi.c |4 +- include/video/omapdss.h | 69 +++- 8 files changed, 636 insertions(+), 232 deletions(-) -- 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 01/10] OMAP: DSS2: Use MIPI DSI transacition types and commands from include/video/mipi_display.h
MIPI DSI Transaction types and DCS commands are currently defined as macros in dsi.c and panel-taal.c, remove these and replace them with enum members defined in include/video/mipi_display.h. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/video/omap2/displays/panel-taal.c | 45 +- drivers/video/omap2/dss/dsi.c | 48 +++- 2 files changed, 35 insertions(+), 58 deletions(-) diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap2/displays/panel-taal.c index 4e888ac..7675687 100644 --- a/drivers/video/omap2/displays/panel-taal.c +++ b/drivers/video/omap2/displays/panel-taal.c @@ -35,26 +35,12 @@ #include video/omapdss.h #include video/omap-panel-nokia-dsi.h +#include video/mipi_display.h /* DSI Virtual channel. Hardcoded for now. */ #define TCH 0 #define DCS_READ_NUM_ERRORS0x05 -#define DCS_READ_POWER_MODE0x0a -#define DCS_READ_MADCTL0x0b -#define DCS_READ_PIXEL_FORMAT 0x0c -#define DCS_RDDSDR 0x0f -#define DCS_SLEEP_IN 0x10 -#define DCS_SLEEP_OUT 0x11 -#define DCS_DISPLAY_OFF0x28 -#define DCS_DISPLAY_ON 0x29 -#define DCS_COLUMN_ADDR0x2a -#define DCS_PAGE_ADDR 0x2b -#define DCS_MEMORY_WRITE 0x2c -#define DCS_TEAR_OFF 0x34 -#define DCS_TEAR_ON0x35 -#define DCS_MEM_ACC_CTRL 0x36 -#define DCS_PIXEL_FORMAT 0x3a #define DCS_BRIGHTNESS 0x51 #define DCS_CTRL_DISPLAY 0x53 #define DCS_WRITE_CABC 0x55 @@ -302,7 +288,7 @@ static int taal_sleep_in(struct taal_data *td) hw_guard_wait(td); - cmd = DCS_SLEEP_IN; + cmd = MIPI_DCS_ENTER_SLEEP_MODE; r = dsi_vc_dcs_write_nosync(td-dssdev, td-channel, cmd, 1); if (r) return r; @@ -321,7 +307,7 @@ static int taal_sleep_out(struct taal_data *td) hw_guard_wait(td); - r = taal_dcs_write_0(td, DCS_SLEEP_OUT); + r = taal_dcs_write_0(td, MIPI_DCS_EXIT_SLEEP_MODE); if (r) return r; @@ -356,7 +342,7 @@ static int taal_set_addr_mode(struct taal_data *td, u8 rotate, bool mirror) u8 mode; int b5, b6, b7; - r = taal_dcs_read_1(td, DCS_READ_MADCTL, mode); + r = taal_dcs_read_1(td, MIPI_DCS_GET_ADDRESS_MODE, mode); if (r) return r; @@ -390,7 +376,7 @@ static int taal_set_addr_mode(struct taal_data *td, u8 rotate, bool mirror) mode = ~((17) | (16) | (15)); mode |= (b7 7) | (b6 6) | (b5 5); - return taal_dcs_write_1(td, DCS_MEM_ACC_CTRL, mode); + return taal_dcs_write_1(td, MIPI_DCS_SET_ADDRESS_MODE, mode); } static int taal_set_update_window(struct taal_data *td, @@ -403,7 +389,7 @@ static int taal_set_update_window(struct taal_data *td, u16 y2 = y + h - 1; u8 buf[5]; - buf[0] = DCS_COLUMN_ADDR; + buf[0] = MIPI_DCS_SET_COLUMN_ADDRESS; buf[1] = (x1 8) 0xff; buf[2] = (x1 0) 0xff; buf[3] = (x2 8) 0xff; @@ -413,7 +399,7 @@ static int taal_set_update_window(struct taal_data *td, if (r) return r; - buf[0] = DCS_PAGE_ADDR; + buf[0] = MIPI_DCS_SET_PAGE_ADDRESS; buf[1] = (y1 8) 0xff; buf[2] = (y1 0) 0xff; buf[3] = (y2 8) 0xff; @@ -1195,7 +1181,8 @@ static int taal_power_on(struct omap_dss_device *dssdev) if (r) goto err; - r = taal_dcs_write_1(td, DCS_PIXEL_FORMAT, 0x7); /* 24bit/pixel */ + r = taal_dcs_write_1(td, MIPI_DCS_SET_PIXEL_FORMAT, + MIPI_DCS_PIXEL_FMT_24BIT); if (r) goto err; @@ -1209,7 +1196,7 @@ static int taal_power_on(struct omap_dss_device *dssdev) goto err; } - r = taal_dcs_write_0(td, DCS_DISPLAY_ON); + r = taal_dcs_write_0(td, MIPI_DCS_SET_DISPLAY_ON); if (r) goto err; @@ -1246,7 +1233,7 @@ static void taal_power_off(struct omap_dss_device *dssdev) struct taal_data *td = dev_get_drvdata(dssdev-dev); int r; - r = taal_dcs_write_0(td, DCS_DISPLAY_OFF); + r = taal_dcs_write_0(td, MIPI_DCS_SET_DISPLAY_OFF); if (!r) r = taal_sleep_in(td); @@ -1529,9 +1516,9 @@ static int _taal_enable_te(struct omap_dss_device *dssdev, bool enable) int r; if (enable) - r = taal_dcs_write_1(td, DCS_TEAR_ON, 0); + r = taal_dcs_write_1(td, MIPI_DCS_SET_TEAR_ON, 0); else - r = taal_dcs_write_0(td, DCS_TEAR_OFF); + r = taal_dcs_write_0(td, MIPI_DCS_SET_TEAR_OFF); if (!panel_data-use_ext_te) omapdss_dsi_enable_te(dssdev, enable); @@ -1851,7 +1838,7 @@ static void taal_esd_work(struct work_struct *work) goto err; } - r = taal_dcs_read_1(td, DCS_RDDSDR, state1); + r =
[PATCH 02/10] OMAP: DSS2: DSI: Represent L4 and VP as sources of VC instead of modes
The enum type dsi_vc_mode is a bit misleading as L4 slave port and video port
are sources to VC rather than the mode of operation. Rename then enum type and
its members. Merge dsi_vc_config_vp() and dsi_vc_config_l4() into a single
function called dsi_vc_config_source() which takes dsi_vc_source enum as an
extra argument.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 72 -
1 files changed, 21 insertions(+), 51 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6735e0c..bdc2c9d 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -217,9 +217,9 @@ enum fifo_size {
DSI_FIFO_SIZE_128 = 4,
};
-enum dsi_vc_mode {
- DSI_VC_MODE_L4 = 0,
- DSI_VC_MODE_VP,
+enum dsi_vc_source {
+ DSI_VC_SOURCE_L4 = 0,
+ DSI_VC_SOURCE_VP,
};
enum dsi_lane {
@@ -272,7 +272,7 @@ struct dsi_data {
struct regulator *vdds_dsi_reg;
struct {
- enum dsi_vc_mode mode;
+ enum dsi_vc_source source;
struct omap_dss_device *dssdev;
enum fifo_size fifo_size;
int vc_id;
@@ -2672,10 +2672,10 @@ static int dsi_sync_vc(struct platform_device *dsidev,
int channel)
if (!dsi_vc_is_enabled(dsidev, channel))
return 0;
- switch (dsi-vc[channel].mode) {
- case DSI_VC_MODE_VP:
+ switch (dsi-vc[channel].source) {
+ case DSI_VC_SOURCE_VP:
return dsi_sync_vc_vp(dsidev, channel);
- case DSI_VC_MODE_L4:
+ case DSI_VC_SOURCE_L4:
return dsi_sync_vc_l4(dsidev, channel);
default:
BUG();
@@ -2729,43 +2729,12 @@ static void dsi_vc_initial_config(struct
platform_device *dsidev, int channel)
dsi_write_reg(dsidev, DSI_VC_CTRL(channel), r);
}
-static int dsi_vc_config_l4(struct platform_device *dsidev, int channel)
+static int dsi_vc_config_source(struct platform_device *dsidev, int channel,
+ enum dsi_vc_source source)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- if (dsi-vc[channel].mode == DSI_VC_MODE_L4)
- return 0;
-
- DSSDBGF(%d, channel);
-
- dsi_sync_vc(dsidev, channel);
-
- dsi_vc_enable(dsidev, channel, 0);
-
- /* VC_BUSY */
- if (wait_for_bit_change(dsidev, DSI_VC_CTRL(channel), 15, 0) != 0) {
- DSSERR(vc(%d) busy when trying to config for L4\n, channel);
- return -EIO;
- }
-
- REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), 0, 1, 1); /* SOURCE, 0 = L4 */
-
- /* DCS_CMD_ENABLE */
- if (dss_has_feature(FEAT_DSI_DCS_CMD_CONFIG_VC))
- REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), 0, 30, 30);
-
- dsi_vc_enable(dsidev, channel, 1);
-
- dsi-vc[channel].mode = DSI_VC_MODE_L4;
-
- return 0;
-}
-
-static int dsi_vc_config_vp(struct platform_device *dsidev, int channel)
-{
- struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
-
- if (dsi-vc[channel].mode == DSI_VC_MODE_VP)
+ if (dsi-vc[channel].source == source)
return 0;
DSSDBGF(%d, channel);
@@ -2780,21 +2749,22 @@ static int dsi_vc_config_vp(struct platform_device
*dsidev, int channel)
return -EIO;
}
- /* SOURCE, 1 = video port */
- REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), 1, 1, 1);
+ /* SOURCE, 0 = L4, 1 = video port */
+ REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), source, 1, 1);
/* DCS_CMD_ENABLE */
- if (dss_has_feature(FEAT_DSI_DCS_CMD_CONFIG_VC))
- REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), 1, 30, 30);
+ if (dss_has_feature(FEAT_DSI_DCS_CMD_CONFIG_VC)) {
+ bool enable = source == DSI_VC_SOURCE_VP;
+ REG_FLD_MOD(dsidev, DSI_VC_CTRL(channel), enable, 30, 30);
+ }
dsi_vc_enable(dsidev, channel, 1);
- dsi-vc[channel].mode = DSI_VC_MODE_VP;
+ dsi-vc[channel].source = source;
return 0;
}
-
void omapdss_dsi_vc_enable_hs(struct omap_dss_device *dssdev, int channel,
bool enable)
{
@@ -3010,7 +2980,7 @@ static int dsi_vc_send_long(struct platform_device
*dsidev, int channel,
return -EINVAL;
}
- dsi_vc_config_l4(dsidev, channel);
+ dsi_vc_config_source(dsidev, channel, DSI_VC_SOURCE_L4);
dsi_vc_write_long_header(dsidev, channel, data_type, len, ecc);
@@ -3069,7 +3039,7 @@ static int dsi_vc_send_short(struct platform_device
*dsidev, int channel,
channel,
data_type, data 0xff, (data 8) 0xff);
- dsi_vc_config_l4(dsidev, channel);
+ dsi_vc_config_source(dsidev, channel, DSI_VC_SOURCE_L4);
if (FLD_GET(dsi_read_reg(dsidev, DSI_VC_CTRL(channel)), 16, 16)) {
DSSERR(ERROR FIFO FULL, aborting
[PATCH 03/10] OMAP: DSS2: Create enum for DSI operation modes
Create an enum for DSI operation modes, use this to set the capabilities of the
device in dsi_init_display().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c |7 ---
include/video/omapdss.h |7 +++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index bdc2c9d..d3bffe8 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4123,9 +4123,10 @@ int dsi_init_display(struct omap_dss_device *dssdev)
DSSDBG(DSI init\n);
- /* XXX these should be figured out dynamically */
- dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
- OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
+ if (dssdev-panel.dsi_mode == OMAP_DSS_DSI_CMD_MODE) {
+ dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
+ OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
+ }
if (dsi-vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 9398dd3..2babe7e 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -129,6 +129,11 @@ enum omap_dss_venc_type {
OMAP_DSS_VENC_TYPE_SVIDEO,
};
+enum omap_dss_dsi_mode {
+ OMAP_DSS_DSI_CMD_MODE = 0,
+ OMAP_DSS_DSI_VIDEO_MODE,
+};
+
enum omap_display_caps {
OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE = 1 0,
OMAP_DSS_DISPLAY_CAP_TEAR_ELIM = 1 1,
@@ -473,6 +478,8 @@ struct omap_dss_device {
int acb;/* ac-bias pin frequency */
enum omap_panel_config config;
+
+ enum omap_dss_dsi_mode dsi_mode;
} panel;
struct {
--
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
[PATCH 04/10] OMAP: DSS2: DSI: Introduce generic write functions
Intoduce enum dss_dsi_content_type to differentiate between DCS and generic
content types.
Introduce short and long packet write functions which use generic
Processor-to-Peripheral transaction types. These are needed by some devices
which may not support corresponding DCS commands. Create common write functions
which allow code reuse between DCS and generic write functions.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 84 +++--
drivers/video/omap2/dss/dss.h |5 ++
include/video/omapdss.h | 12 +-
3 files changed, 87 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d3bffe8..bb55889 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3065,38 +3065,60 @@ int dsi_vc_send_null(struct omap_dss_device *dssdev,
int channel)
}
EXPORT_SYMBOL(dsi_vc_send_null);
-int dsi_vc_dcs_write_nosync(struct omap_dss_device *dssdev, int channel,
- u8 *data, int len)
+static int dsi_vc_write_nosync_common(struct omap_dss_device *dssdev,
+ int channel, u8 *data, int len, enum dss_dsi_content_type type)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
int r;
- BUG_ON(len == 0);
-
- if (len == 1) {
+ if (len == 0) {
+ BUG_ON(type == DSS_DSI_CONTENT_DCS);
r = dsi_vc_send_short(dsidev, channel,
+ MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM, 0, 0);
+ } else if (len == 1) {
+ r = dsi_vc_send_short(dsidev, channel,
+ type == DSS_DSI_CONTENT_GENERIC ?
+ MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM :
MIPI_DSI_DCS_SHORT_WRITE, data[0], 0);
} else if (len == 2) {
r = dsi_vc_send_short(dsidev, channel,
+ type == DSS_DSI_CONTENT_GENERIC ?
+ MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM :
MIPI_DSI_DCS_SHORT_WRITE_PARAM,
data[0] | (data[1] 8), 0);
} else {
- /* 0x39 = DCS Long Write */
- r = dsi_vc_send_long(dsidev, channel, MIPI_DSI_DCS_LONG_WRITE,
- data, len, 0);
+ r = dsi_vc_send_long(dsidev, channel,
+ type == DSS_DSI_CONTENT_GENERIC ?
+ MIPI_DSI_GENERIC_LONG_WRITE :
+ MIPI_DSI_DCS_LONG_WRITE, data, len, 0);
}
return r;
}
+
+int dsi_vc_dcs_write_nosync(struct omap_dss_device *dssdev, int channel,
+ u8 *data, int len)
+{
+ return dsi_vc_write_nosync_common(dssdev, channel, data, len,
+ DSS_DSI_CONTENT_DCS);
+}
EXPORT_SYMBOL(dsi_vc_dcs_write_nosync);
-int dsi_vc_dcs_write(struct omap_dss_device *dssdev, int channel, u8 *data,
- int len)
+int dsi_vc_generic_write_nosync(struct omap_dss_device *dssdev, int channel,
+ u8 *data, int len)
+{
+ return dsi_vc_write_nosync_common(dssdev, channel, data, len,
+ DSS_DSI_CONTENT_GENERIC);
+}
+EXPORT_SYMBOL(dsi_vc_generic_write_nosync);
+
+static int dsi_vc_write_common(struct omap_dss_device *dssdev, int channel,
+ u8 *data, int len, enum dss_dsi_content_type type)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
int r;
- r = dsi_vc_dcs_write_nosync(dssdev, channel, data, len);
+ r = dsi_vc_write_nosync_common(dssdev, channel, data, len, type);
if (r)
goto err;
@@ -3114,18 +3136,39 @@ int dsi_vc_dcs_write(struct omap_dss_device *dssdev,
int channel, u8 *data,
return 0;
err:
- DSSERR(dsi_vc_dcs_write(ch %d, cmd 0x%02x, len %d) failed\n,
+ DSSERR(dsi_vc_write_common(ch %d, cmd 0x%02x, len %d) failed\n,
channel, data[0], len);
return r;
}
+
+int dsi_vc_dcs_write(struct omap_dss_device *dssdev, int channel, u8 *data,
+ int len)
+{
+ return dsi_vc_write_common(dssdev, channel, data, len,
+ DSS_DSI_CONTENT_DCS);
+}
EXPORT_SYMBOL(dsi_vc_dcs_write);
+int dsi_vc_generic_write(struct omap_dss_device *dssdev, int channel, u8 *data,
+ int len)
+{
+ return dsi_vc_write_common(dssdev, channel, data, len,
+ DSS_DSI_CONTENT_GENERIC);
+}
+EXPORT_SYMBOL(dsi_vc_generic_write);
+
int dsi_vc_dcs_write_0(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd)
{
return dsi_vc_dcs_write(dssdev, channel, dcs_cmd, 1);
}
EXPORT_SYMBOL(dsi_vc_dcs_write_0);
+int dsi_vc_generic_write_0(struct omap_dss_device *dssdev, int channel)
+{
+ return dsi_vc_generic_write(dssdev, channel, NULL, 0);
+}
+EXPORT_SYMBOL(dsi_vc_generic_write_0);
[PATCH 05/10] OMAP: DSS2: DSI: Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2()
Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2(), these are used
when the panel is expected to return 1 and 2 bytes respecitvely. This was manily
used for debugging purposes. These functions should be implemented in the panel
driver if needed.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 38 --
include/video/omapdss.h |4
2 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index bb55889..8251647 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3307,44 +3307,6 @@ err:
}
EXPORT_SYMBOL(dsi_vc_dcs_read);
-int dsi_vc_dcs_read_1(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
- u8 *data)
-{
- int r;
-
- r = dsi_vc_dcs_read(dssdev, channel, dcs_cmd, data, 1);
-
- if (r 0)
- return r;
-
- if (r != 1)
- return -EIO;
-
- return 0;
-}
-EXPORT_SYMBOL(dsi_vc_dcs_read_1);
-
-int dsi_vc_dcs_read_2(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
- u8 *data1, u8 *data2)
-{
- u8 buf[2];
- int r;
-
- r = dsi_vc_dcs_read(dssdev, channel, dcs_cmd, buf, 2);
-
- if (r 0)
- return r;
-
- if (r != 2)
- return -EIO;
-
- *data1 = buf[0];
- *data2 = buf[1];
-
- return 0;
-}
-EXPORT_SYMBOL(dsi_vc_dcs_read_2);
-
int dsi_vc_set_max_rx_packet_size(struct omap_dss_device *dssdev, int channel,
u16 len)
{
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 00462cd..af30e1f 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -241,10 +241,6 @@ int dsi_vc_generic_write_nosync(struct omap_dss_device
*dssdev, int channel,
u8 *data, int len);
int dsi_vc_dcs_read(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
u8 *buf, int buflen);
-int dsi_vc_dcs_read_1(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
- u8 *data);
-int dsi_vc_dcs_read_2(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
- u8 *data1, u8 *data2);
int dsi_vc_set_max_rx_packet_size(struct omap_dss_device *dssdev, int channel,
u16 len);
int dsi_vc_send_null(struct omap_dss_device *dssdev, int channel);
--
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
[PATCH 06/10] OMAP: DSS2: DSI: Split dsi_vc_dcs_read() into 2 functions
Split dsi_vc_dcs_read() into the functions:
- dsi_vc_dcs_send_read_request(): This is responsible for sending the short
packet command with the read request.
- dsi_vc_dcs_read_rx_fifo(): This parses the DSI RX fifo of the given virtual
channel, identifies the type of data received, and fills a buffer with the data
provided by the panel.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 61 +
1 files changed, 49 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8251647..c26a914 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3196,25 +3196,34 @@ int dsi_vc_generic_write_2(struct omap_dss_device
*dssdev, int channel,
}
EXPORT_SYMBOL(dsi_vc_generic_write_2);
-int dsi_vc_dcs_read(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
- u8 *buf, int buflen)
+static int dsi_vc_dcs_send_read_request(struct omap_dss_device *dssdev,
+ int channel, u8 dcs_cmd)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- u32 val;
- u8 dt;
int r;
if (dsi-debug_read)
- DSSDBG(dsi_vc_dcs_read(ch%d, dcs_cmd %x)\n, channel, dcs_cmd);
+ DSSDBG(dsi_vc_dcs_send_read_request(ch%d, dcs_cmd %x)\n,
+ channel, dcs_cmd);
r = dsi_vc_send_short(dsidev, channel, MIPI_DSI_DCS_READ, dcs_cmd, 0);
- if (r)
- goto err;
+ if (r) {
+ DSSERR(dsi_vc_dcs_send_read_request(ch %d, cmd 0x%02x)
+failed\n, channel, dcs_cmd);
+ return r;
+ }
- r = dsi_vc_send_bta_sync(dssdev, channel);
- if (r)
- goto err;
+ return 0;
+}
+
+static int dsi_vc_dcs_read_rx_fifo(struct platform_device *dsidev, int channel,
+ u8 *buf, int buflen)
+{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ u32 val;
+ u8 dt;
+ int r;
/* RX_FIFO_NOT_EMPTY */
if (REG_GET(dsidev, DSI_VC_CTRL(channel), 20, 20) == 0) {
@@ -3300,10 +3309,38 @@ int dsi_vc_dcs_read(struct omap_dss_device *dssdev, int
channel, u8 dcs_cmd,
BUG();
err:
- DSSERR(dsi_vc_dcs_read(ch %d, cmd 0x%02x) failed\n,
- channel, dcs_cmd);
+ DSSERR(dsi_vc_dcs_read_rx_fifo(ch %d) failed\n, channel);
+
return r;
+}
+
+int dsi_vc_dcs_read(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
+ u8 *buf, int buflen)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ int r;
+
+ r = dsi_vc_dcs_send_read_request(dssdev, channel, dcs_cmd);
+ if (r)
+ goto err;
+ r = dsi_vc_send_bta_sync(dssdev, channel);
+ if (r)
+ goto err;
+
+ r = dsi_vc_dcs_read_rx_fifo(dsidev, channel, buf, buflen);
+ if (r 0)
+ goto err;
+
+ if (r != buflen) {
+ r = -EIO;
+ goto err;
+ }
+
+ return 0;
+err:
+ DSSERR(dsi_vc_dcs_read(ch %d, cmd 0x%02x) failed\n, channel, dcs_cmd);
+ return r;
}
EXPORT_SYMBOL(dsi_vc_dcs_read);
--
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
[PATCH 07/10] OMAP: DSS2: DSI: Introduce generic read functions
Introduce read functions which use generic Processor-to-Peripheral
transaction types. These are needed by some devices which may not support
corresponding DCS commands.
Add function dsi_vc_generic_send_read_request() which can send
a short packet with 0, 1 or 2 bytes of request data and the corresponding
generic data type.
Rename function dsi_vc_dcs_read_rx_fifo() to dsi_vc_read_rx_fifo() and modify
it to take the enum dss_dsi_content_type as an argument to use either DCS
or GENERIC Peripheral-to-Processor transaction types while parsing data read
from the device.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 146 ++---
include/video/omapdss.h |6 ++
2 files changed, 142 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c26a914..20cad1b 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -3217,8 +3217,44 @@ static int dsi_vc_dcs_send_read_request(struct
omap_dss_device *dssdev,
return 0;
}
-static int dsi_vc_dcs_read_rx_fifo(struct platform_device *dsidev, int channel,
- u8 *buf, int buflen)
+static int dsi_vc_generic_send_read_request(struct omap_dss_device *dssdev,
+ int channel, u8 *reqdata, int reqlen)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ u16 data;
+ u8 data_type;
+ int r;
+
+ if (dsi-debug_read)
+ DSSDBG(dsi_vc_generic_send_read_request(ch %d, reqlen %d)\n,
+ channel, reqlen);
+
+ if (reqlen == 0) {
+ data_type = MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM;
+ data = 0;
+ } else if (reqlen == 1) {
+ data_type = MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM;
+ data = reqdata[0];
+ } else if (reqlen == 2) {
+ data_type = MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM;
+ data = reqdata[0] | (reqdata[1] 8);
+ } else {
+ BUG();
+ }
+
+ r = dsi_vc_send_short(dsidev, channel, data_type, data, 0);
+ if (r) {
+ DSSERR(dsi_vc_generic_send_read_request(ch %d, reqlen %d)
+failed\n, channel, reqlen);
+ return r;
+ }
+
+ return 0;
+}
+
+static int dsi_vc_read_rx_fifo(struct platform_device *dsidev, int channel,
+ u8 *buf, int buflen, enum dss_dsi_content_type type)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
u32 val;
@@ -3242,10 +3278,14 @@ static int dsi_vc_dcs_read_rx_fifo(struct
platform_device *dsidev, int channel,
r = -EIO;
goto err;
- } else if (dt == MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE) {
+ } else if (dt == (type == DSS_DSI_CONTENT_GENERIC ?
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE :
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE)) {
u8 data = FLD_GET(val, 15, 8);
if (dsi-debug_read)
- DSSDBG(\tDCS short response, 1 byte: %02x\n, data);
+ DSSDBG(\t%s short response, 1 byte: %02x\n,
+ type == DSS_DSI_CONTENT_GENERIC ? GENERIC :
+ DCS, data);
if (buflen 1) {
r = -EIO;
@@ -3255,10 +3295,14 @@ static int dsi_vc_dcs_read_rx_fifo(struct
platform_device *dsidev, int channel,
buf[0] = data;
return 1;
- } else if (dt == MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE) {
+ } else if (dt == (type == DSS_DSI_CONTENT_GENERIC ?
+ MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE :
+ MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE)) {
u16 data = FLD_GET(val, 23, 8);
if (dsi-debug_read)
- DSSDBG(\tDCS short response, 2 byte: %04x\n, data);
+ DSSDBG(\t%s short response, 2 byte: %04x\n,
+ type == DSS_DSI_CONTENT_GENERIC ? GENERIC :
+ DCS, data);
if (buflen 2) {
r = -EIO;
@@ -3269,11 +3313,15 @@ static int dsi_vc_dcs_read_rx_fifo(struct
platform_device *dsidev, int channel,
buf[1] = (data 8) 0xff;
return 2;
- } else if (dt == MIPI_DSI_RX_DCS_LONG_READ_RESPONSE) {
+ } else if (dt == (type == DSS_DSI_CONTENT_GENERIC ?
+ MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE :
+ MIPI_DSI_RX_DCS_LONG_READ_RESPONSE)) {
int w;
int len = FLD_GET(val, 23, 8);
if (dsi-debug_read)
- DSSDBG(\tDCS long response, len %d\n, len);
+ DSSDBG(\t%s long response,
[PATCH 08/10] OMAP: DSS2: Clean up stallmode and io pad mode selection
Split the function dispc_set_parallel_interface_mode() into 2 separate
functions called dispc_mgr_set_io_pad_mode() and dispc_mgr_enable_stallmode().
The current function tries to set 2 different modes(io pad mode and stall mode)
based on a parameter omap_parallel_interface_mode which loosely corresponds to
the panel interface type.
This isn't correct because a) these 2 modes are independent to some extent,
b) we are currently configuring gpout0/gpout1 for DSI panels which is
unnecessary, c) a DSI Video mode panel won't get configured correctly.
Splitting the functions allows the interface driver to set these modes
independently and hence allow more flexibility.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 47 +-
drivers/video/omap2/dss/dpi.c |5 ++-
drivers/video/omap2/dss/dsi.c |3 +-
drivers/video/omap2/dss/dss.h | 12 +-
drivers/video/omap2/dss/rfbi.c |4 +-
drivers/video/omap2/dss/sdi.c |4 +-
6 files changed, 35 insertions(+), 40 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d156a52..4107e0b 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2205,46 +2205,41 @@ void dispc_mgr_set_tft_data_lines(enum omap_channel
channel, u8 data_lines)
REG_FLD_MOD(DISPC_CONTROL, code, 9, 8);
}
-void dispc_mgr_set_parallel_interface_mode(enum omap_channel channel,
- enum omap_parallel_interface_mode mode)
+void dispc_mgr_set_io_pad_mode(enum dss_io_pad_mode mode)
{
u32 l;
- int stallmode;
- int gpout0 = 1;
- int gpout1;
+ int gpout0, gpout1;
switch (mode) {
- case OMAP_DSS_PARALLELMODE_BYPASS:
- stallmode = 0;
- gpout1 = 1;
+ case DSS_IO_PAD_MODE_RESET:
+ gpout0 = 0;
+ gpout1 = 0;
break;
-
- case OMAP_DSS_PARALLELMODE_RFBI:
- stallmode = 1;
+ case DSS_IO_PAD_MODE_RFBI:
+ gpout0 = 1;
gpout1 = 0;
break;
-
- case OMAP_DSS_PARALLELMODE_DSI:
- stallmode = 1;
+ case DSS_IO_PAD_MODE_BYPASS:
+ gpout0 = 1;
gpout1 = 1;
break;
-
default:
BUG();
return;
}
- if (channel == OMAP_DSS_CHANNEL_LCD2) {
- l = dispc_read_reg(DISPC_CONTROL2);
- l = FLD_MOD(l, stallmode, 11, 11);
- dispc_write_reg(DISPC_CONTROL2, l);
- } else {
- l = dispc_read_reg(DISPC_CONTROL);
- l = FLD_MOD(l, stallmode, 11, 11);
- l = FLD_MOD(l, gpout0, 15, 15);
- l = FLD_MOD(l, gpout1, 16, 16);
- dispc_write_reg(DISPC_CONTROL, l);
- }
+ l = dispc_read_reg(DISPC_CONTROL);
+ l = FLD_MOD(l, gpout0, 15, 15);
+ l = FLD_MOD(l, gpout1, 16, 16);
+ dispc_write_reg(DISPC_CONTROL, l);
+}
+
+void dispc_mgr_enable_stallmode(enum omap_channel channel, bool enable)
+{
+ if (channel == OMAP_DSS_CHANNEL_LCD2)
+ REG_FLD_MOD(DISPC_CONTROL2, enable, 11, 11);
+ else
+ REG_FLD_MOD(DISPC_CONTROL, enable, 11, 11);
}
static bool _dispc_lcd_timings_ok(int hsw, int hfp, int hbp,
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 1edc832..483888a 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -166,8 +166,9 @@ static void dpi_basic_init(struct omap_dss_device *dssdev)
is_tft = (dssdev-panel.config OMAP_DSS_LCD_TFT) != 0;
- dispc_mgr_set_parallel_interface_mode(dssdev-manager-id,
- OMAP_DSS_PARALLELMODE_BYPASS);
+ dispc_mgr_set_io_pad_mode(DSS_IO_PAD_MODE_BYPASS);
+ dispc_mgr_enable_stallmode(dssdev-manager-id, false);
+
dispc_mgr_set_lcd_display_type(dssdev-manager-id, is_tft ?
OMAP_DSS_LCD_DISPLAY_TFT : OMAP_DSS_LCD_DISPLAY_STN);
dispc_mgr_set_tft_data_lines(dssdev-manager-id,
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 20cad1b..c2c2fa7 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4019,8 +4019,7 @@ static int dsi_display_init_dispc(struct omap_dss_device
*dssdev)
dispc_mgr_set_lcd_display_type(dssdev-manager-id,
OMAP_DSS_LCD_DISPLAY_TFT);
- dispc_mgr_set_parallel_interface_mode(dssdev-manager-id,
- OMAP_DSS_PARALLELMODE_DSI);
+ dispc_mgr_enable_stallmode(dssdev-manager-id, true);
dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 1);
dispc_mgr_set_tft_data_lines(dssdev-manager-id,
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 3ec8dd7..f4196f5 100644
--- a/drivers/video/omap2/dss/dss.h
+++
[PATCH 09/10] OMAP: DSS2: Create an enum for DSI pixel formats
Currently, DSI pixel info is only represented by the pixel size in bits using
the pixel_size parameter in omap_dss_device struct's ctrl member.
This is not sufficient information for DSI video mode usage, as two of the
supported formats(RGB666 loosely packed, and RGB888) have the same pixel
container size, but different data_type values for the video mode packet header.
Create enum omap_dss_dsi_pixel_format which describes the pixel data format
the panel is configured for.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/displays/panel-taal.c |2 +-
drivers/video/omap2/dss/dsi.c | 24
include/video/omapdss.h |8
3 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 7675687..ddc696d 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -976,7 +976,7 @@ static int taal_probe(struct omap_dss_device *dssdev)
dssdev-panel.config = OMAP_DSS_LCD_TFT;
dssdev-panel.timings = panel_config-timings;
- dssdev-ctrl.pixel_size = 24;
+ dssdev-panel.dsi_pix_fmt = OMAP_DSS_DSI_FMT_RGB888;
td = kzalloc(sizeof(*td), GFP_KERNEL);
if (!td) {
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index c2c2fa7..582ae7b 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -422,6 +422,21 @@ static inline int wait_for_bit_change(struct
platform_device *dsidev,
return value;
}
+static inline u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
+{
+ switch (fmt) {
+ case OMAP_DSS_DSI_FMT_RGB888:
+ case OMAP_DSS_DSI_FMT_RGB666:
+ return 24;
+ case OMAP_DSS_DSI_FMT_RGB666_PACKED:
+ return 18;
+ case OMAP_DSS_DSI_FMT_RGB565:
+ return 16;
+ default:
+ BUG();
+ }
+}
+
#ifdef DEBUG
static void dsi_perf_mark_setup(struct platform_device *dsidev)
{
@@ -438,6 +453,7 @@ static void dsi_perf_mark_start(struct platform_device
*dsidev)
static void dsi_perf_show(struct platform_device *dsidev, const char *name)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ struct omap_dss_device *dssdev = dsi-update_region.device;
ktime_t t, setup_time, trans_time;
u32 total_bytes;
u32 setup_us, trans_us, total_us;
@@ -461,7 +477,7 @@ static void dsi_perf_show(struct platform_device *dsidev,
const char *name)
total_bytes = dsi-update_region.w *
dsi-update_region.h *
- dsi-update_region.device-ctrl.pixel_size / 8;
+ dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt) / 8;
printk(KERN_INFO DSI(%s): %u us + %u us = %u us (%uHz),
%u bytes, %u kbytes/sec\n,
@@ -3689,7 +3705,7 @@ static int dsi_proto_config(struct omap_dss_device
*dssdev)
dsi_set_lp_rx_timeout(dsidev, 0x1fff, true, true);
dsi_set_hs_tx_timeout(dsidev, 0x1fff, true, true);
- switch (dssdev-ctrl.pixel_size) {
+ switch (dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt)) {
case 16:
buswidth = 0;
break;
@@ -3814,7 +3830,7 @@ static void dsi_update_screen_dispc(struct
omap_dss_device *dssdev,
dsi_vc_config_source(dsidev, channel, DSI_VC_SOURCE_VP);
- bytespp = dssdev-ctrl.pixel_size / 8;
+ bytespp = dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt) / 8;
bytespl = w * bytespp;
bytespf = bytespl * h;
@@ -4023,7 +4039,7 @@ static int dsi_display_init_dispc(struct omap_dss_device
*dssdev)
dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 1);
dispc_mgr_set_tft_data_lines(dssdev-manager-id,
- dssdev-ctrl.pixel_size);
+ dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt));
{
struct omap_video_timings timings = {
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 8c94d95..1e9a35c 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -129,6 +129,13 @@ enum omap_dss_venc_type {
OMAP_DSS_VENC_TYPE_SVIDEO,
};
+enum omap_dss_dsi_pixel_format {
+ OMAP_DSS_DSI_FMT_RGB888,
+ OMAP_DSS_DSI_FMT_RGB666,
+ OMAP_DSS_DSI_FMT_RGB666_PACKED,
+ OMAP_DSS_DSI_FMT_RGB565,
+};
+
enum omap_dss_dsi_mode {
OMAP_DSS_DSI_CMD_MODE = 0,
OMAP_DSS_DSI_VIDEO_MODE,
@@ -489,6 +496,7 @@ struct omap_dss_device {
enum omap_panel_config config;
+ enum omap_dss_dsi_pixel_format dsi_pix_fmt;
enum omap_dss_dsi_mode dsi_mode;
} panel;
--
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
[PATCH 10/10] OMAP: DSS2: DSI Video mode support
Add initial support for DSI video mode panels:
- Add a new structure omap_dss_dsi_videomode_data in the member panel in
omap_dss_device struct. This allows panel driver to configure dsi video_mode
specific parameters.
- Configure basic DSI video mode timing parameters: HBP, HFP, HSA, VBP, VFP,
VSA,
TL and VACT.
- Configure DSI protocol engine registers for video_mode support.
- Introduce functions dsi_video_mode_enable() and dsi_video_mode_disable() which
enable/disable video mode for a given virtual channel and a given pixel format
type.
Things left for later
- Add functions to check for errors in video mode timings provided by panel.
- Configure timing registers required for command mode interleaving.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 256 -
include/video/omapdss.h | 32 +
2 files changed, 259 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 582ae7b..e3d5c38 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -132,7 +132,7 @@ struct dsi_reg { u16 idx; };
#define DSI_IRQ_TA_TIMEOUT (1 20)
#define DSI_IRQ_ERROR_MASK \
(DSI_IRQ_HS_TX_TIMEOUT | DSI_IRQ_LP_RX_TIMEOUT | DSI_IRQ_SYNC_LOST | \
- DSI_IRQ_TA_TIMEOUT)
+ DSI_IRQ_TA_TIMEOUT | DSI_IRQ_SYNC_LOST)
#define DSI_IRQ_CHANNEL_MASK 0xf
/* Virtual channel interrupts */
@@ -2472,6 +2472,12 @@ static int dsi_cio_init(struct omap_dss_device *dssdev)
dsi_cio_timings(dsidev);
+ if (dssdev-panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ /* DDR_CLK_ALWAYS_ON */
+ REG_FLD_MOD(dsidev, DSI_CLK_CTRL,
+ dssdev-panel.dsi_vm_data.ddr_clk_always_on, 13, 13);
+ }
+
dsi-ulps_enabled = false;
DSSDBG(CIO init done\n);
@@ -2496,6 +2502,9 @@ static void dsi_cio_uninit(struct omap_dss_device *dssdev)
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ /* DDR_CLK_ALWAYS_ON */
+ REG_FLD_MOD(dsidev, DSI_CLK_CTRL, 0, 13, 13);
+
dsi_cio_power(dsidev, DSI_COMPLEXIO_POWER_OFF);
dsi_disable_scp_clk(dsidev);
dsi-disable_pads(dsidev-id, dsi_get_lane_mask(dssdev));
@@ -3683,6 +3692,75 @@ static void dsi_set_hs_tx_timeout(struct platform_device
*dsidev,
ticks, x4 ? x4 : , x16 ? x16 : ,
(total_ticks * 1000) / (fck / 1000 / 1000));
}
+
+static void dsi_config_vp_num_line_buffers(struct omap_dss_device *dssdev)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ int num_line_buffers;
+
+ if (dssdev-panel.dsi_mode == OMAP_DSS_DSI_VIDEO_MODE) {
+ int bpp = dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt);
+ unsigned line_buf_size = dsi_get_line_buf_size(dsidev);
+ struct omap_video_timings *timings = dssdev-panel.timings;
+ /*
+* Don't use line buffers if width is greater than the video
+* port's line buffer size
+*/
+ if (line_buf_size = timings-x_res * bpp / 8)
+ num_line_buffers = 0;
+ else
+ num_line_buffers = 2;
+ } else {
+ /* Use maximum number of line buffers in command mode */
+ num_line_buffers = 2;
+ }
+
+ /* LINE_BUFFER */
+ REG_FLD_MOD(dsidev, DSI_CTRL, num_line_buffers, 13, 12);
+}
+
+static void dsi_config_vp_sync_events(struct omap_dss_device *dssdev)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ int de_pol = dssdev-panel.dsi_vm_data.vp_de_pol;
+ int hsync_pol = dssdev-panel.dsi_vm_data.vp_hsync_pol;
+ int vsync_pol = dssdev-panel.dsi_vm_data.vp_vsync_pol;
+ bool vsync_end = dssdev-panel.dsi_vm_data.vp_vsync_end;
+ bool hsync_end = dssdev-panel.dsi_vm_data.vp_hsync_end;
+ u32 r;
+
+ r = dsi_read_reg(dsidev, DSI_CTRL);
+ r = FLD_MOD(r, de_pol, 9, 9); /* VP_DE_POL */
+ r = FLD_MOD(r, hsync_pol, 10, 10); /* VP_HSYNC_POL */
+ r = FLD_MOD(r, vsync_pol, 11, 11); /* VP_VSYNC_POL */
+ r = FLD_MOD(r, 1, 15, 15); /* VP_VSYNC_START */
+ r = FLD_MOD(r, vsync_end, 16, 16); /* VP_VSYNC_END */
+ r = FLD_MOD(r, 1, 17, 17); /* VP_HSYNC_START */
+ r = FLD_MOD(r, hsync_end, 18, 18); /* VP_HSYNC_END */
+ dsi_write_reg(dsidev, DSI_CTRL, r);
+}
+
+static void dsi_config_blanking_modes(struct omap_dss_device *dssdev)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ int blanking_mode = dssdev-panel.dsi_vm_data.blanking_mode;
+ int hfp_blanking_mode = dssdev-panel.dsi_vm_data.hfp_blanking_mode;
+ int hbp_blanking_mode
[PATCH 1/3] ASoC: tpa6130a2: Model support cleanup
Use the device name and driver_data to identify
the TPA model supported by the driver.
Board files should use either tpa6130a2 or
tpa6140a2 as device name to specify the model
in used on the specific board.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
sound/soc/codecs/tpa6130a2.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 239e0c4..0c0fcb3 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -383,7 +383,7 @@ static int __devinit tpa6130a2_probe(struct i2c_client
*client,
pdata = client-dev.platform_data;
data-power_gpio = pdata-power_gpio;
- data-id = pdata-id;
+ data-id = id-driver_data;
mutex_init(data-mutex);
@@ -405,7 +405,7 @@ static int __devinit tpa6130a2_probe(struct i2c_client
*client,
switch (data-id) {
default:
dev_warn(dev, Unknown TPA model (%d). Assuming 6130A2\n,
-pdata-id);
+data-id);
case TPA6130A2:
regulator = Vdd;
break;
@@ -470,7 +470,8 @@ static int __devexit tpa6130a2_remove(struct i2c_client
*client)
}
static const struct i2c_device_id tpa6130a2_id[] = {
- { tpa6130a2, 0 },
+ { tpa6130a2, TPA6130A2 },
+ { tpa6140a2, TPA6140A2 },
{ }
};
MODULE_DEVICE_TABLE(i2c, tpa6130a2_id);
--
1.7.6.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
[PATCH 0/3] ASoC: tpa6130a2: model handling cleanup
Hello, Small cleanup for the tpa6130a2 driver for model handling: Remove the model_id from platform_data, and use the device name/device_data to distinguish between the supported models of TPA. Regards, Peter --- Peter Ujfalusi (3): ASoC: tpa6130a2: Model support cleanup OMAP: RX51: No need to configure the tpa_model ASoC: tpa6130a2: Remove model_id from platform data arch/arm/mach-omap2/board-rx51-peripherals.c |1 - include/sound/tpa6130a2-plat.h |6 -- sound/soc/codecs/tpa6130a2.c | 12 +--- 3 files changed, 9 insertions(+), 10 deletions(-) -- 1.7.6.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
[PATCH 2/3] OMAP: RX51: No need to configure the tpa_model
The TPA driver now uses the name for model support.
n900 has tpa61030a2 model of TPA.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 5a886cd..ba1aa07 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -900,7 +900,6 @@ static struct twl4030_platform_data rx51_twldata __initdata
= {
};
static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata_or_module
= {
- .id = TPA6130A2,
.power_gpio = 98,
};
--
1.7.6.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
[PATCH 3/3] ASoC: tpa6130a2: Remove model_id from platform data
The model_id is no longer needed within the platform_data
for the TPA driver since the model of TPA specified
with the device name (tpa6130a2/tpa6140a2).
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/sound/tpa6130a2-plat.h |6 --
sound/soc/codecs/tpa6130a2.c |5 +
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/include/sound/tpa6130a2-plat.h b/include/sound/tpa6130a2-plat.h
index 89beccb..4cc1093 100644
--- a/include/sound/tpa6130a2-plat.h
+++ b/include/sound/tpa6130a2-plat.h
@@ -23,13 +23,7 @@
#ifndef TPA6130A2_PLAT_H
#define TPA6130A2_PLAT_H
-enum tpa_model {
- TPA6130A2,
- TPA6140A2,
-};
-
struct tpa6130a2_platform_data {
- enum tpa_model id;
int power_gpio;
};
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 0c0fcb3..f37a02b 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -33,6 +33,11 @@
#include tpa6130a2.h
+enum tpa_model {
+ TPA6130A2,
+ TPA6140A2,
+};
+
static struct i2c_client *tpa6130a2_client;
/* This struct is used to save the context */
--
1.7.6.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
Re: [RFC PATCH 3/3] OMAP: omap_device: Add a method to build an omap_device from a DT node
Kevin,
Some self-review...
On 8/22/2011 8:22 PM, Cousson, Benoit wrote:
Add a notifier called during device_add phase. If a of_node is present,
retrieve the hwmod entry in order to populate propely the omap_device
typo
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver
will not work without that information.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Kevin Hilmankhil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 102 ++
1 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 70361f8..0ae9e7f 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,8 @@
#includelinux/clk.h
#includelinux/clkdev.h
#includelinux/pm_runtime.h
+#includelinux/of_platform.h
This is not the proper include and will break non-DT build.
It should be that one:
+#includelinux/of.h
I'll fix the series and re-send.
Benoit
+#includelinux/notifier.h
#includeplat/omap_device.h
#includeplat/omap_hwmod.h
@@ -94,6 +96,8 @@
#define USE_WAKEUP_LAT0
#define IGNORE_WAKEUP_LAT 1
+#define MAX_HWMOD_NAME_SIZE32
+
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
static struct omap_device *omap_device_alloc(struct platform_device *pdev,
@@ -354,6 +358,100 @@ static int _dt_get_property(const char *prop, int len,
int index, char *output,
return -ENODEV;
}
+static struct dev_pm_domain omap_device_pm_domain;
+
+/**
+ * omap_device_build_from_dt - build an omap_device with multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Function for building an omap_device already registered from device-tree
+ *
+ * Returns 0 or PTR_ERR() on error.
+ */
+static int omap_device_build_from_dt(struct platform_device *pdev)
+{
+ struct omap_hwmod **hwmods;
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ char oh_name[MAX_HWMOD_NAME_SIZE];
+ const char *prop;
+ int oh_cnt, i, prop_len;
+ int ret = 0;
+
+ prop = of_get_property(pdev-dev.of_node, hwmods,prop_len);
+ oh_cnt = _dt_count_property_string(prop, prop_len);
+ if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
+ dev_warn(pdev-dev, No 'hwmods' to build omap_device\n);
+ return -ENODEV;
+ }
+
+ hwmods = kzalloc(sizeof(struct omap_hwmod *) * oh_cnt, GFP_KERNEL);
+ if (!hwmods) {
+ ret = -ENOMEM;
+ goto odbfd_exit;
+ }
+
+ for (i = 0; i oh_cnt; i++) {
+ _dt_get_property(prop, prop_len, i, oh_name,
+MAX_HWMOD_NAME_SIZE);
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ dev_err(pdev-dev, Cannot lookup hwmod '%s'\n,
+ oh_name);
+ ret = -EINVAL;
+ goto odbfd_exit1;
+ }
+ hwmods[i] = oh;
+ }
+
+ od = omap_device_alloc(pdev, hwmods, oh_cnt, NULL, 0);
+ if (!od) {
+ dev_err(pdev-dev, Cannot allocate omap_device for :%s\n,
+ oh_name);
+ ret = PTR_ERR(od);
+ goto odbfd_exit1;
+ }
+
+ if (of_get_property(pdev-dev.of_node, no_idle_on_suspend, NULL))
+ omap_device_disable_idle_on_suspend(pdev);
+
+ pdev-dev.pm_domain =omap_device_pm_domain;
+
+odbfd_exit1:
+ kfree(hwmods);
+odbfd_exit:
+ return ret;
+}
+
+static int _omap_device_notifier_call(struct notifier_block *nb,
+ unsigned long event, void *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ if (pdev-dev.of_node) {
+ dev_dbg(pdev-dev, add_device with DT bindings\n);
+ omap_device_build_from_dt(pdev);
+ }
+ break;
+
+ case BUS_NOTIFY_DEL_DEVICE:
+ dev_dbg(pdev-dev, del_device\n);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
/* Public functions for use by core code */
@@ -1064,8 +1162,12 @@ struct device omap_device_parent = {
.parent =platform_bus,
};
+static
Re: [PATCH 0/3] ASoC: tpa6130a2: model handling cleanup
On 08/30/2011 02:39 PM, Peter Ujfalusi wrote: Hello, Small cleanup for the tpa6130a2 driver for model handling: Remove the model_id from platform_data, and use the device name/device_data to distinguish between the supported models of TPA. Regards, Peter --- Peter Ujfalusi (3): ASoC: tpa6130a2: Model support cleanup OMAP: RX51: No need to configure the tpa_model ASoC: tpa6130a2: Remove model_id from platform data arch/arm/mach-omap2/board-rx51-peripherals.c |1 - include/sound/tpa6130a2-plat.h |6 -- sound/soc/codecs/tpa6130a2.c | 12 +--- 3 files changed, 9 insertions(+), 10 deletions(-) Tested-by: Jarkko Nikula jarkko.nik...@bitmer.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
GPIO chip select support
Thanks for the poke. I've been meaning to send this set out again anyways. This is the patch I am currently using (on top of v3.0). Conceptually it's quite similar to the first patches I sent out but some implementation details were slightly reworked to account for the generalization of the McSPI driver to other silicon. I would say that the patch is close to mergable save the fact that there is currently no clean way to set up GPIO CS pins from a board file. I'll send the horrible hack I currently use shortly. If anyone has any ideas on how this might be done cleanly please let me know. It's sad that the mere lack of a configuration interface is the reason this isn't upstream. Cheers, - Ben -- 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] mcspi: Add support for GPIO chip select lines
Many applications require more chip select lines than the board or
processor allow. Introduce a mechanism to allow use of GPIO pins as
chip select lines with the McSPI controller. To use this
tionality,
one simply provides a table mapping CS line numbers to GPIO numbers
omap2_mcspi_platform_config.cs_gpios.
Signed-off-by: Ben Gamari bgamari.f...@gmail.com
---
arch/arm/plat-omap/include/plat/mcspi.h |1 +
drivers/spi/omap2_mcspi.c | 19 +--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index 3d51b18..c5670f2 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -10,6 +10,7 @@
struct omap2_mcspi_platform_config {
unsigned short num_cs;
unsigned int regs_offset;
+ int *cs_gpios;
};
struct omap2_mcspi_dev_attr {
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index f41c906..20dec5d 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -36,6 +36,7 @@
#include linux/pm_runtime.h
#include linux/spi/spi.h
+#include linux/gpio.h
#include plat/dma.h
#include plat/clock.h
@@ -121,6 +122,7 @@ struct omap2_mcspi {
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
+int *cs_gpios;
};
struct omap2_mcspi_cs {
@@ -227,7 +229,11 @@ static void omap2_mcspi_set_enable(const struct spi_device
*spi, int enable)
static void omap2_mcspi_force_cs(struct spi_device *spi, int cs_active)
{
u32 l;
+ struct omap2_mcspi* mcspi = spi_master_get_devdata(spi-master);
+ if (mcspi-cs_gpios)
+ gpio_set_value(mcspi-cs_gpios[spi-chip_select], cs_active);
+ // TXS times out unless we force the CHCONF reg as well
l = mcspi_cached_chconf0(spi);
MOD_REG_BIT(l, OMAP2_MCSPI_CHCONF_FORCE, cs_active);
mcspi_write_chconf0(spi, l);
@@ -1088,6 +1094,8 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
struct omap2_mcspi *mcspi;
struct resource *r;
int status = 0, i;
+ struct omap2_mcspi_platform_config* pconfig = pdev-dev.platform_data;
+ int num_dma;
master = spi_alloc_master(pdev-dev, sizeof *mcspi);
if (master == NULL) {
@@ -1110,6 +1118,13 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
mcspi = spi_master_get_devdata(master);
mcspi-master = master;
+ if (pconfig pconfig-cs_gpios) {
+ mcspi-cs_gpios = pconfig-cs_gpios;
+ num_dma = 1;
+ } else {
+ mcspi-cs_gpios = NULL;
+ num_dma = master-num_chipselect;
+ }
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
@@ -1139,14 +1154,14 @@ static int __init omap2_mcspi_probe(struct
platform_device *pdev)
INIT_LIST_HEAD(mcspi-msg_queue);
INIT_LIST_HEAD(omap2_mcspi_ctx[master-bus_num - 1].cs);
- mcspi-dma_channels = kcalloc(master-num_chipselect,
+ mcspi-dma_channels = kcalloc(num_dma,
sizeof(struct omap2_mcspi_dma),
GFP_KERNEL);
if (mcspi-dma_channels == NULL)
goto err2;
- for (i = 0; i master-num_chipselect; i++) {
+ for (i = 0; i num_dma; i++) {
char dma_ch_name[14];
struct resource *dma_res;
--
1.7.4.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
[PATCH] beagledaq: Hack in cs_gpios
---
arch/arm/mach-omap2/board-omap3beagle.c |4 ++--
arch/arm/mach-omap2/devices.c | 15 +++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 67999da..481c1a9 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -661,8 +661,8 @@ static struct spi_board_info beagledaq_mcspi_board_info[] =
{
},
};
-static int mcspi3_cs_gpios[4];
-static int mcspi4_cs_gpios[4];
+int mcspi3_cs_gpios[4];
+int mcspi4_cs_gpios[4];
static void __init beagledaq_init(void)
{
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5b8ca68..6808251 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -341,6 +341,9 @@ struct omap_device_pm_latency omap_mcspi_latency[] = {
},
};
+extern int mcspi3_cs_gpios[4];
+extern int mcspi4_cs_gpios[4];
+
static int omap_mcspi_init(struct omap_hwmod *oh, void *unused)
{
struct omap_device *od;
@@ -369,6 +372,18 @@ static int omap_mcspi_init(struct omap_hwmod *oh, void
*unused)
return -EINVAL;
}
+ /* HACK: Not enough time to figure out how to export cs_gpios from
+* board file to driver correctly */
+ if (spi_num == 2) {
+ // Setup McSPI3 cs_gpios
+ pdata-num_cs = 4;
+ pdata-cs_gpios = mcspi3_cs_gpios;
+ } else if (spi_num == 3) {
+ // Setup McSPI4 cs_gpios
+ pdata-num_cs = 4;
+ pdata-cs_gpios = mcspi4_cs_gpios;
+ }
+
spi_num++;
od = omap_device_build(name, spi_num, oh, pdata,
sizeof(*pdata), omap_mcspi_latency,
--
1.7.4.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
[PATCH 1/2] arm: omap: usb: Add mux initialization to ehci and ohci hwmods for omap4
From: Kishon Vijay Abraham kis...@ti.com
For ehci and ohci hwmods, the omap4 mux initializations functions
are included.
Signed-off-by: Kishon Vijay Abraham kis...@ti.com
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 546 +---
1 files changed, 403 insertions(+), 143 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 9c37db9..9ec3d01 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -52,6 +52,355 @@ static struct omap_device_pm_latency omap_uhhtll_latency[]
= {
},
};
+
+static struct omap_device_pad port1_phy_pads[] __initdata = {
+ {
+ .name = usbb1_ulpitll_stp.usbb1_ulpiphy_stp,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_clk.usbb1_ulpiphy_clk,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dir.usbb1_ulpiphy_dir,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+};
+
+static struct omap_device_pad port1_tll_pads[] __initdata = {
+ {
+ .name = usbb1_ulpitll_stp.usbb1_ulpitll_stp,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_clk.usbb1_ulpitll_clk,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dir.usbb1_ulpitll_dir,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_nxt.usbb1_ulpitll_nxt,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat0.usbb1_ulpitll_dat0,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat1.usbb1_ulpitll_dat1,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat2.usbb1_ulpitll_dat2,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat3.usbb1_ulpitll_dat3,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat4.usbb1_ulpitll_dat4,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat5.usbb1_ulpitll_dat5,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat6.usbb1_ulpitll_dat6,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ {
+ .name = usbb1_ulpitll_dat7.usbb1_ulpitll_dat7,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad port2_phy_pads[] __initdata = {
+ {
+ .name = usbb2_ulpitll_stp.usbb2_ulpiphy_stp,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb2_ulpitll_clk.usbb2_ulpiphy_clk,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb2_ulpitll_dir.usbb2_ulpiphy_dir,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE4,
+ },
+ {
+ .name = usbb2_ulpitll_nxt.usbb2_ulpiphy_nxt,
+
[PATCH 0/2] omap: usb: I/O pads initialization to ehci and ohci hwmods
From: Keshava Munegowda keshava_mgo...@ti.com These two patches performs the I/O pad mux initialization to ehci and ohci hwmods for both omap3 and omap4 SOCs. This patch series is based on 1. Runtime PM support of usbhs of omap3 and omap4 These patches are avilable at branch kmg-usbhs-pm code repository : git://gitorious.org/~kmg/mirrors/kmg-usbhs-pm.git 2. Kevin's pm branch Keshava Munegowda (1): arm: omap: usb: Add mux initialization to ehci and ohci hwmods for omap3 Kishon Vijay Abraham (1): arm: omap: usb: Add mux initialization to ehci and ohci hwmods for omap4 arch/arm/mach-omap2/usb-host.c | 1234 ++-- 1 files changed, 933 insertions(+), 301 deletions(-) -- 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 2/2] arm: omap: usb: Add mux initialization to ehci and ohci hwmods for omap3
From: Keshava Munegowda keshava_mgo...@ti.com
For ehci and ohci hwmods, the omap3 mux initializations functions
are included.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 692 ++-
1 files changed, 532 insertions(+), 160 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 9ec3d01..485341f 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -401,151 +401,525 @@ static struct omap_device_pad port2_2pin_pads[]
__initdata = {
},
};
+/*
+ * OMAP3 pad confs
+ */
+static struct omap_device_pad omap3_port1_phy_pads[] __initdata = {
+ {
+ .name = etk_clk.hsusb1_stp,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_ctl.hsusb1_clk,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d8.hsusb1_dir,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d9.hsusb1_nxt,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d0.hsusb1_data0,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d1.hsusb1_data1,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d2.hsusb1_data2,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d7.hsusb1_data3,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d4.hsusb1_data4,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d5.hsusb1_data5,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d6.hsusb1_data6,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d3.hsusb1_data7,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+};
+
+static struct omap_device_pad omap3_port1_tll_pads[] __initdata = {
+ {
+ .name = etk_clk.hsusb1_tll_stp,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_ctl.hsusb1_tll_clk,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d8.hsusb1_tll_dir,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d9.hsusb1_tll_nxt,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d0.hsusb1_tll_data0,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d1.hsusb1_tll_data1,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d2.hsusb1_tll_data2,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d7.hsusb1_tll_data3,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d4.hsusb1_tll_data4,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d5.hsusb1_tll_data5,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d6.hsusb1_tll_data6,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+ {
+ .name = etk_d3.hsusb1_tll_data7,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE6,
+ },
+};
+
+static struct omap_device_pad omap3_port2_phy_pads[] __initdata = {
+ {
+ .name = etk_d11.hsusb2_stp,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d10.hsusb2_clk,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d12.hsusb2_dir,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d13.hsusb2_nxt,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d14.hsusb2_data0,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = etk_d15.hsusb2_data1,
+ .enable = OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE3,
+ },
+ {
+ .name = mcspi1_cs3.hsusb2_data2,
+ .enable = OMAP_PIN_INPUT_PULLDOWN |
Re: [PATCH] usb: ehci: fix update qtd-token in qh_append_tds
Hi Alan, Thanks for your comment. On Tue, Aug 30, 2011 at 12:33 AM, Alan Stern st...@rowland.harvard.edu wrote: Nevertheless, it remains true that you want to add a memory barrier instruction simply in order to speed up a cache writeback, not to force any sort of ordering. This needs to be explained carefully in the code (not just in the patch description!) and it needs to be done in a way that won't affect other architectures. OK, will do it. Also, as you mentioned before, you may want to do the same thing in qh_link_async() just after the head-hw-hw_next = dma; line. Delays in flushing that write would also slow down performance. Will do it too. thanks, -- Ming Lei -- 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] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
From: Ming Lei ming@canonical.com
This patch introduces the helper of ehci_sync_mem to flush
qtd/qh into memory immediately on some ARM, so that HC can
see the up-to-date qtd/qh descriptor asap.
This patch fixs one performance bug on ARM Cortex A9 dual core
platform, which has been reported on quite a few ARM machines
(OMAP4, Tegra 2, snowball...), see details from link of
https://bugs.launchpad.net/bugs/709245.
The patch has been tested ok on OMAP4 panda A1 board, and the
performance of 'dd' over usb mass storage can be increased from
4~5MB/sec to 14~16MB/sec after applying this patch.
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/host/ehci-q.c | 18 ++
drivers/usb/host/ehci.h | 17 +
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 0917e3a..2719879 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -995,6 +995,12 @@ static void qh_link_async (struct ehci_hcd *ehci, struct
ehci_qh *qh)
head-qh_next.qh = qh;
head-hw-hw_next = dma;
+ /*
+* flush qh descriptor into memory immediately,
+* see comments in qh_append_tds.
+* */
+ ehci_sync_mem();
+
qh_get(qh);
qh-xacterrs = 0;
qh-qh_state = QH_STATE_LINKED;
@@ -1082,6 +1088,18 @@ static struct ehci_qh *qh_append_tds (
wmb ();
dummy-hw_token = token;
+ /*
+* Writing to dma coherent buffer on ARM may
+* be delayed to reach memory, so HC may not see
+* hw_token of dummy qtd in time, which can cause
+* the qtd transaction to be executed very late,
+* and degrade performance a lot. ehci_sync_mem
+* is added to flush 'token' immediatelly into
+* memory, so that ehci can execute the transaction
+* ASAP.
+* */
+ ehci_sync_mem();
+
urb-hcpriv = qh_get (qh);
}
}
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index cc7d337..313d9d6 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -738,6 +738,23 @@ static inline u32 hc32_to_cpup (const struct ehci_hcd
*ehci, const __hc32 *x)
#endif
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
/*-*/
#ifndef DEBUG
--
1.7.4.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
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 31 Aug 2011 ming@canonical.com wrote:
From: Ming Lei ming@canonical.com
This patch introduces the helper of ehci_sync_mem to flush
qtd/qh into memory immediately on some ARM, so that HC can
see the up-to-date qtd/qh descriptor asap.
This patch fixs one performance bug on ARM Cortex A9 dual core
platform, which has been reported on quite a few ARM machines
(OMAP4, Tegra 2, snowball...), see details from link of
https://bugs.launchpad.net/bugs/709245.
The patch has been tested ok on OMAP4 panda A1 board, and the
performance of 'dd' over usb mass storage can be increased from
4~5MB/sec to 14~16MB/sec after applying this patch.
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Ming Lei ming@canonical.com
---
drivers/usb/host/ehci-q.c | 18 ++
drivers/usb/host/ehci.h | 17 +
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 0917e3a..2719879 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -995,6 +995,12 @@ static void qh_link_async (struct ehci_hcd *ehci, struct
ehci_qh *qh)
head-qh_next.qh = qh;
head-hw-hw_next = dma;
+ /*
+ * flush qh descriptor into memory immediately,
+ * see comments in qh_append_tds.
+ * */
Comments are supposed to look like this:
/*
* Blah blah blah
* blah blah blah
*/
+ ehci_sync_mem();
+
qh_get(qh);
qh-xacterrs = 0;
qh-qh_state = QH_STATE_LINKED;
@@ -1082,6 +1088,18 @@ static struct ehci_qh *qh_append_tds (
wmb ();
dummy-hw_token = token;
+ /*
+ * Writing to dma coherent buffer on ARM may
+ * be delayed to reach memory, so HC may not see
+ * hw_token of dummy qtd in time, which can cause
+ * the qtd transaction to be executed very late,
+ * and degrade performance a lot. ehci_sync_mem
+ * is added to flush 'token' immediatelly into
+ * memory, so that ehci can execute the transaction
+ * ASAP.
+ * */
Here too.
+ ehci_sync_mem();
+
urb-hcpriv = qh_get (qh);
}
}
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index cc7d337..313d9d6 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -738,6 +738,23 @@ static inline u32 hc32_to_cpup (const struct ehci_hcd
*ehci, const __hc32 *x)
#endif
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
And here.
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
Except for the formatting of the comments, this is fine. When you fix
up the comments, you can add:
Signed-off-by: Alan Stern st...@rowland.harvard.edu
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: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
--Mark
--
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/2 RESEND] OMAP2+: pm: fix typos
Fix typos in comment and error message. Signed-off-by: Johan Hovold jhov...@gmail.com --- arch/arm/mach-omap2/pm.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 3feb359..fd77cf4 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -163,11 +163,11 @@ err: } /* - * This API is to be called during init to put the various voltage + * This API is to be called during init to set the various voltage * domains to the voltage as per the opp table. Typically we boot up * at the nominal voltage. So this function finds out the rate of * the clock associated with the voltage domain, finds out the correct - * opp entry and puts the voltage domain to the voltage specifies + * opp entry and sets the voltage domain to the voltage specified * in the opp entry */ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name, @@ -218,7 +218,7 @@ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name, return 0; exit: - printk(KERN_ERR %s: Unable to put vdd_%s to its init voltage\n\n, + printk(KERN_ERR %s: Unable to set vdd_%s to its init voltage\n\n, __func__, vdd_name); return -EINVAL; } -- 1.7.6 -- 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 2/2 RESEND] OMAP2+: pm: clean up error messages
Replace all printks with pr_err.
Clean up error messages by adding missing whitespace, fixing
capitalisations, removing double newlines, and reducing verbosity.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
arch/arm/mach-omap2/pm.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fd77cf4..3837818 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -137,8 +137,8 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
ret = pwrdm_set_next_pwrst(pwrdm, state);
if (ret) {
- printk(KERN_ERR Unable to set state of powerdomain: %s\n,
- pwrdm-name);
+ pr_err(%s: unable to set state of powerdomain: %s\n,
+ __func__, pwrdm-name);
goto err;
}
@@ -179,21 +179,20 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
unsigned long freq, bootup_volt;
if (!vdd_name || !clk_name || !dev) {
- printk(KERN_ERR %s: Invalid parameters!\n, __func__);
+ pr_err(%s: invalid parameters\n, __func__);
goto exit;
}
voltdm = omap_voltage_domain_lookup(vdd_name);
if (IS_ERR(voltdm)) {
- printk(KERN_ERR %s: Unable to get vdd pointer for vdd_%s\n,
+ pr_err(%s: unable to get vdd pointer for vdd_%s\n,
__func__, vdd_name);
goto exit;
}
clk = clk_get(NULL, clk_name);
if (IS_ERR(clk)) {
- printk(KERN_ERR %s: unable to get clk %s\n,
- __func__, clk_name);
+ pr_err(%s: unable to get clk %s\n, __func__, clk_name);
goto exit;
}
@@ -202,14 +201,14 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
opp = opp_find_freq_ceil(dev, freq);
if (IS_ERR(opp)) {
- printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
+ pr_err(%s: unable to find boot up OPP for vdd_%s\n,
__func__, vdd_name);
goto exit;
}
bootup_volt = opp_get_voltage(opp);
if (!bootup_volt) {
- printk(KERN_ERR %s: unable to find voltage corresponding
+ pr_err(%s: unable to find voltage corresponding
to the bootup OPP for vdd_%s\n, __func__, vdd_name);
goto exit;
}
@@ -218,8 +217,7 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
return 0;
exit:
- printk(KERN_ERR %s: Unable to set vdd_%s to its init voltage\n\n,
- __func__, vdd_name);
+ pr_err(%s: unable to set vdd_%s\n, __func__, vdd_name);
return -EINVAL;
}
--
1.7.6
--
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 3/3] OMAP2+: voltage: clean up error messages
On Mon, Aug 29, 2011 at 02:15:49PM -0700, Kevin Hilman wrote: Hi Johan, Johan Hovold jhov...@gmail.com writes: Clean up error messages by adding missing whitespace, reducing excessive verbosity, and fixing a few language issues. Signed-off-by: Johan Hovold jhov...@gmail.com I've got a major voltage layer cleanup series in progess (and just posted a few series.) Would you care to rebase this on top my pm-wip/voldtm branch[1] where those cleanups are being done? I just resent patches 1 and 2 with proper CC and will try to respin patch 3 against your voltdm branch in a few days. Thanks, Johan -- 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: make HC see up-to-date qh/qtd descriptor ASAP
On Tue, 30 Aug 2011, Mark Salter wrote:
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
This would be a good thing to define centrally. Would you like to
post an RFC on LKML?
Do you know of any other examples of hardware that polls shared DMA
memory?
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: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Tue, Aug 30, 2011 at 05:38:30PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
Right. In this case the buffering is happening at L2 which becomes
noticeable when measuring performance. We also buffer stores at the
CPU (regardless of memory type) but because these tend to become visible
fairly quickly, there isn't a comparable performance problem.
Given that I would expect other architectures to buffer writes at the CPU,
would it not be worth having an API for flushing to L3 (devices)? It seems
like this would be a useful addition to the coherent DMA API on platforms
that handle coherency with non-cacheable memory attributes.
Will
--
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: make HC see up-to-date qh/qtd descriptor ASAP
On Tue, Aug 30, 2011 at 06:26:42PM +0100, Will Deacon wrote:
On Tue, Aug 30, 2011 at 05:38:30PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
Right. In this case the buffering is happening at L2 which becomes
noticeable when measuring performance. We also buffer stores at the
CPU (regardless of memory type) but because these tend to become visible
fairly quickly, there isn't a comparable performance problem.
Given that I would expect other architectures to buffer writes at the CPU,
would it not be worth having an API for flushing to L3 (devices)? It seems
like this would be a useful addition to the coherent DMA API on platforms
that handle coherency with non-cacheable memory attributes.
I agree, this seems to be a new type of barrier that is needed, as the
code comment above seems to go against what the kernel memory barrier
documentation says about what a memory barrier really does on the
hardware.
greg k-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
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Tue, Aug 30, 2011 at 06:48:59PM +0100, Greg KH wrote:
On Tue, Aug 30, 2011 at 06:26:42PM +0100, Will Deacon wrote:
On Tue, Aug 30, 2011 at 05:38:30PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
Right. In this case the buffering is happening at L2 which becomes
noticeable when measuring performance. We also buffer stores at the
CPU (regardless of memory type) but because these tend to become visible
fairly quickly, there isn't a comparable performance problem.
Given that I would expect other architectures to buffer writes at the CPU,
would it not be worth having an API for flushing to L3 (devices)? It seems
like this would be a useful addition to the coherent DMA API on platforms
that handle coherency with non-cacheable memory attributes.
I agree, this seems to be a new type of barrier that is needed, as the
code comment above seems to go against what the kernel memory barrier
documentation says about what a memory barrier really does on the
hardware.
Although this doesn't have anything to do with ordering; it's all to do with
immediacy so I think we should try to avoiding using the term `barrier'. If
this can be made part of the coherent DMA API, that might be the best place
for it (I can't think of any other areas this is needed given that the
streaming DMA API and I/O accessors already deal with it).
Will
--
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: make HC see up-to-date qh/qtd descriptor ASAP
On Tue, 2011-08-30 at 13:15 -0400, Alan Stern wrote:
On Tue, 30 Aug 2011, Mark Salter wrote:
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
This would be a good thing to define centrally. Would you like to
post an RFC on LKML?
Yes, I can take a stab at that.
Do you know of any other examples of hardware that polls shared DMA
memory?
Not offhand nor after a quick search. I don't think it is a common
way of doing things.
--Mark
--
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: [RFC PATCH v2 0/6] TI81XX: Add clock and hwmod data
On Tue, 23 Aug 2011, Hemant Pedanekar wrote: This patch set is the v2 of TI816X clock and hwmods patches sent earlier. The clock data is currently added only for TI816X, while minimal hwmod data common for TI816X and TI814X is added. This patch set depends on following patches: TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM Please note that CHIP_IS_TI816X/CHIP_IS_TI814X are still being used and I will send update once SoC list usage is available. Thanks - am working away on these patches hope to have them out soon. - 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/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
Hi, On Wednesday 10 August 2011 16:03:12 Deepthy Ravi wrote: From: Abhilash K V abhilash...@ti.com While resuming from the suspended to memory state, occasionally CCDC fails to get enabled and thus fails to capture frames any more till the next suspend/resume is issued. This is a race condition which happens only when a CCDC frame-completion ISR is pending even as ISP device's isp_pm_prepare() is getting called and only one buffer is left on the DMA queue. The DMA queue buffers are thus depleted which results in its underrun.So when ISP resumes there are no buffers on the queue (as the application which can issue buffers is yet to resume) to start video capture. This fix addresses this issue by dequeuing and enqueing the last buffer in isp_pm_prepare() after its DMA gets completed. Thus,when ISP resumes it always finds atleast one buffer on the DMA queue - this is true if application uses only 3 buffers. How is that problem specific to the CCDC ? Can't it be reproduce at the preview engine or resizer output as well ? -- Regards, Laurent Pinchart -- 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 RESEND] OMAP2+: pm: fix typos
Johan Hovold jhov...@gmail.com writes: Fix typos in comment and error message. Signed-off-by: Johan Hovold jhov...@gmail.com Thanks, queuing for v3.2 (branch: for_3.2/pm-cleanup) Kevin --- arch/arm/mach-omap2/pm.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 3feb359..fd77cf4 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -163,11 +163,11 @@ err: } /* - * This API is to be called during init to put the various voltage + * This API is to be called during init to set the various voltage * domains to the voltage as per the opp table. Typically we boot up * at the nominal voltage. So this function finds out the rate of * the clock associated with the voltage domain, finds out the correct - * opp entry and puts the voltage domain to the voltage specifies + * opp entry and sets the voltage domain to the voltage specified * in the opp entry */ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name, @@ -218,7 +218,7 @@ static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name, return 0; exit: - printk(KERN_ERR %s: Unable to put vdd_%s to its init voltage\n\n, + printk(KERN_ERR %s: Unable to set vdd_%s to its init voltage\n\n, __func__, vdd_name); return -EINVAL; } -- 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 2/2 RESEND] OMAP2+: pm: clean up error messages
Johan Hovold jhov...@gmail.com writes:
Replace all printks with pr_err.
Clean up error messages by adding missing whitespace, fixing
capitalisations, removing double newlines, and reducing verbosity.
Signed-off-by: Johan Hovold jhov...@gmail.com
Thanks, queuing for v3.2 (branch: for_3.2/pm-cleanup)
Kevin
---
arch/arm/mach-omap2/pm.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index fd77cf4..3837818 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -137,8 +137,8 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
ret = pwrdm_set_next_pwrst(pwrdm, state);
if (ret) {
- printk(KERN_ERR Unable to set state of powerdomain: %s\n,
-pwrdm-name);
+ pr_err(%s: unable to set state of powerdomain: %s\n,
+__func__, pwrdm-name);
goto err;
}
@@ -179,21 +179,20 @@ static int __init omap2_set_init_voltage(char
*vdd_name, char *clk_name,
unsigned long freq, bootup_volt;
if (!vdd_name || !clk_name || !dev) {
- printk(KERN_ERR %s: Invalid parameters!\n, __func__);
+ pr_err(%s: invalid parameters\n, __func__);
goto exit;
}
voltdm = omap_voltage_domain_lookup(vdd_name);
if (IS_ERR(voltdm)) {
- printk(KERN_ERR %s: Unable to get vdd pointer for vdd_%s\n,
+ pr_err(%s: unable to get vdd pointer for vdd_%s\n,
__func__, vdd_name);
goto exit;
}
clk = clk_get(NULL, clk_name);
if (IS_ERR(clk)) {
- printk(KERN_ERR %s: unable to get clk %s\n,
- __func__, clk_name);
+ pr_err(%s: unable to get clk %s\n, __func__, clk_name);
goto exit;
}
@@ -202,14 +201,14 @@ static int __init omap2_set_init_voltage(char
*vdd_name, char *clk_name,
opp = opp_find_freq_ceil(dev, freq);
if (IS_ERR(opp)) {
- printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
+ pr_err(%s: unable to find boot up OPP for vdd_%s\n,
__func__, vdd_name);
goto exit;
}
bootup_volt = opp_get_voltage(opp);
if (!bootup_volt) {
- printk(KERN_ERR %s: unable to find voltage corresponding
+ pr_err(%s: unable to find voltage corresponding
to the bootup OPP for vdd_%s\n, __func__, vdd_name);
goto exit;
}
@@ -218,8 +217,7 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
return 0;
exit:
- printk(KERN_ERR %s: Unable to set vdd_%s to its init voltage\n\n,
- __func__, vdd_name);
+ pr_err(%s: unable to set vdd_%s\n, __func__, vdd_name);
return -EINVAL;
}
--
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/3] AM35x: voltage: Basic initialization
Abhilash K V abhilash...@ti.com writes:
From: Sanjeev Premi pr...@ti.com
This patch adds the basic initialization of voltage layer
for AM35x. Since AM35x doesn't support voltage scaling,
Many functions have been defined to plug into existing
voltage layer.
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
[...]
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index def230f..b45d145 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -67,6 +67,38 @@ static struct omap_vdd_info *omap3_vdd_info[] = {
omap3_vdd2_info,
};
+/*
+ * AM35x VDD structures
+ *
+ * In AM35x there neither scalable voltage domain nor any hook-up with
+ * voltage controller/processor. However, when trying to re-use the hwmod
+ * database for OMAP3, definition of core voltage domain is necessary.
+ * Else, changes in hwmod data structures grow spirally.
+ *
+ * As a workaround, core voltage domain is defined below. The definition
+ * doesn't lead to any side-effects.
Except the side-effect of a bunch of unused data, and nop functions that
just clutter things up in a not-very-maintainable way.
For SoCs without scalable voltage domains, we need to fix the underlying
problems in the core code for how to cleanly re-use hwmods.
Fortunately, this core code cleanup is now in progress, so it shouldn't
be long now where we can do this cleanly.
Kevin
--
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/4] AM3517 : support for suspend/resume
Abhilash K V abhilash...@ti.com writes:
1. Patch to disable dynamic sleep (as it is not supported
on AM35xx).
2. Imported the unique suspend/resume sequence for AM3517,
contained in the new file arch/arm/mach-omap2/sleep3517.S.
3. Added omap3517_ to symbol-names in sleep3517.S which are common
with sleep34xx.S, and added appropriate checks.
There are still 3 caveats:
1. If no_console_suspend is enabled (via boot-args), the device
doesnot resume but simply hangs.
2. Every second and subsequent attempt to suspend/resume prints this slow-path
WARNING (for both uart1 and uart2), while resuming :
[ 70.943939] omap_hwmod: uart1: idle state can only be entered from
enabled state
3. Wakeup using the TSC2004 touch-screen controller is not supported.
Signed-off-by: Ranjith Lohithakshan ranji...@ti.com
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
In addition to Russell's comments about using the latest code from
mainline, I have some comments below.
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/control.c |7 ++-
arch/arm/mach-omap2/control.h |1 +
arch/arm/mach-omap2/pm.h|4 +
arch/arm/mach-omap2/pm34xx.c| 18 -
arch/arm/mach-omap2/sleep3517.S | 144
+++
6 files changed, 170 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/mach-omap2/sleep3517.S
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 46f5fbc..3fdf086 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -61,7 +61,7 @@ endif
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o sleep3517.o \
cpuidle34xx.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index da53ba3..7d2d8a8 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -284,10 +284,13 @@ void omap3_save_scratchpad_contents(void)
* The restore pointer is stored into the scratchpad.
*/
scratchpad_contents.boot_config_ptr = 0x0;
- if (cpu_is_omap3630())
+ if (cpu_is_omap3505() || cpu_is_omap3517()) {
+ scratchpad_contents.public_restore_ptr =
+ virt_to_phys(omap3517_get_restore_pointer());
Based on the contents of the get_restore_pointer() added below, this
value is obviously not being used. Either off-mode was not tested (or not
supported.) Either way, unused code like this should not be
added if it is not tested or supported.
+ } else if (cpu_is_omap3630()) {
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_omap3630_restore_pointer());
- else if (omap_rev() != OMAP3430_REV_ES3_0
+ } else if (omap_rev() != OMAP3430_REV_ES3_0
omap_rev() != OMAP3430_REV_ES3_1)
scratchpad_contents.public_restore_ptr =
virt_to_phys(get_restore_pointer());
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index ad024df..3003940 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -389,6 +389,7 @@ extern void omap4_ctrl_pad_writel(u32 val, u16 offset);
extern void omap3_save_scratchpad_contents(void);
extern void omap3_clear_scratchpad_contents(void);
extern u32 *get_restore_pointer(void);
+extern u32 *omap3517_get_restore_pointer(void);
extern u32 *get_es3_restore_pointer(void);
extern u32 *get_omap3630_restore_pointer(void);
extern u32 omap3_arm_context[128];
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 5c2bd2f..d773e07 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -77,13 +77,17 @@ extern void omap24xx_idle_loop_suspend(void);
extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl,
void __iomem *sdrc_power);
extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
+extern void omap3517_cpu_suspend(u32 *addr, int save_state);
extern int save_secure_ram_context(u32 *addr);
+extern void omap3517_save_secure_ram_context(u32 *addr);
extern void omap3_save_scratchpad_contents(void);
extern unsigned int omap24xx_idle_loop_suspend_sz;
extern unsigned int save_secure_ram_context_sz;
+extern unsigned int omap3517_save_secure_ram_context_sz;
extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap34xx_cpu_suspend_sz;
+extern unsigned int omap3517_cpu_suspend_sz;
#define PM_RTA_ERRATUM_i608 (1 0)
#define
Re: [PATCH 3/4] pm34xx: Warning FIX related to ambiguous else loop
Abhilash K V abhilash...@ti.com writes:
From: Vaibhav Hiremath hvaib...@ti.com
Fixes below warning -
arch/arm/mach-omap2/pm34xx.c:1041: warning:
suggest explicit braces to avoid ambiguous 'else
This warning was introduced in [1/4], so I'd suggest just folding this
fix into the original patch.
Kevin
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Abhilash K V abhilash...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 12af5b9..ab3822b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -856,7 +856,7 @@ void omap_push_sram_idle(void)
else
_omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
omap34xx_cpu_suspend_sz);
- if (omap_type() != OMAP2_DEVICE_TYPE_GP)
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
if (cpu_is_omap3505() || cpu_is_omap3517())
_omap_save_secure_sram = omap_sram_push(
omap3517_save_secure_ram_context,
@@ -865,6 +865,7 @@ void omap_push_sram_idle(void)
_omap_save_secure_sram = omap_sram_push(
save_secure_ram_context,
save_secure_ram_context_sz);
+ }
}
static void __init pm_errata_configure(void)
--
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: make HC see up-to-date qh/qtd descriptor ASAP
On Aug 31, 2011, at 1:54 AM, Will Deacon wrote:
On Tue, Aug 30, 2011 at 06:48:59PM +0100, Greg KH wrote:
On Tue, Aug 30, 2011 at 06:26:42PM +0100, Will Deacon wrote:
On Tue, Aug 30, 2011 at 05:38:30PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 00:03 +0800, ming@canonical.com wrote:
+/*
+ * Writing to dma coherent memory on ARM may be delayed via L2
+ * writing buffer, so introduce the helper which can flush L2 writing
+ * buffer into memory immediately, especially used to flush ehci
+ * descriptor to memory.
+ * */
+#ifdef CONFIG_ARM_DMA_MEM_BUFFERABLE
+static inline void ehci_sync_mem()
+{
+ mb();
+}
+#else
+static inline void ehci_sync_mem()
+{
+}
+#endif
+
I'm wondering if this doesn't really belong in the DMA API for any
future architectures that can't avoid prolonged write buffering to DMA
coherent memory. IIUC, ARM mitigates this for most drivers by including
an implicit write buffer flush in the mmio write routines. This takes
care of the drivers which write to a mmio device register after writing
something to shared DMA memory. IIUC, this doesn't help ehci because the
host controller is polling to see what the cpu writes to the shared
memory. Other hardware which polls shared memory like that will likely
have the same problem and could use buffer drain helpers as well.
Right. In this case the buffering is happening at L2 which becomes
noticeable when measuring performance. We also buffer stores at the
CPU (regardless of memory type) but because these tend to become visible
fairly quickly, there isn't a comparable performance problem.
Given that I would expect other architectures to buffer writes at the CPU,
would it not be worth having an API for flushing to L3 (devices)? It seems
like this would be a useful addition to the coherent DMA API on platforms
that handle coherency with non-cacheable memory attributes.
I agree, this seems to be a new type of barrier that is needed, as the
code comment above seems to go against what the kernel memory barrier
documentation says about what a memory barrier really does on the
hardware.
Although this doesn't have anything to do with ordering; it's all to do with
immediacy so I think we should try to avoiding using the term `barrier'. If
this can be made part of the coherent DMA API, that might be the best place
for it (I can't think of any other areas this is needed given that the
streaming DMA API and I/O accessors already deal with it).
I am agree with you. I met the same issue at both usb device driver (adding
next dTD pointer which
the current one is handling) and usb host driver (performance issue this thread
have discussed) at
Freescale i.MX6Q platform (4 Cores, ARM SMP).
So, now I need to add two barriers at two different drivers.
One question: why this write buffer issue did not happen at UP ARM V7 platform,
whose dma buffer
also uncache, but bufferable?
Will
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Best Regard,
Peter Chen
--
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: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, Aug 31, 2011 at 1:54 AM, Will Deacon will.dea...@arm.com wrote: Although this doesn't have anything to do with ordering; it's all to do with immediacy so I think we should try to avoiding using the term `barrier'. If this can be made part of the coherent DMA API, that might be the best place for it (I can't think of any other areas this is needed given that the streaming DMA API and I/O accessors already deal with it). Agree too. thanks, -- Ming Lei -- 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: Arm device tree wonder
On Tue, 30 Aug 2011, Pierre Beaumon wrote: Also I believe one big arm problem is a lack of common infrastructure that lead to code duplication. Some machine try to do too much things. omap2 (mach-omap2 + plat-omap) is about 80 KSLOC over 400KSLOC (76 mach + plat directories). That 8 times bigger than the average ((80/2)/(400/76))! There are either common stuff that should be shared, or some stuff should be moved in drivers. Here are some additional data points you might consider adding to your analysis: - Consider taking into account what percentage of those lines are for SoC-specific device data files. Where should those files be moved, before a DT (or other data format) conversion? - Consider comparing the number of on-chip devices supported by the core OMAP code to the number of devices supported by the average SoC core code, in mainline. - Consider accounting for the extra code and data needed for fine-grained power management, compared to the average SoC core code, assuming the SoC supports it. - Consider taking into account the number of OMAP variants supported by the core OMAP code (at least thirty, not counting silicon revision differences, which can be significant) compared to the average SoC. - Consider comparing the number of boards supported by the core OMAP code to the number supported by the average SoC code. To what other shared directory or drivers/ subdirectory should these files be moved to, before a DT conversion? To be sure, there's a fair amount of OMAP core code that should be moved out to drivers. My guess is about 10-15% of the current total. Work along those lines is proceeding. If you're offering to help, we could use it. But I don't think that the way to deal with the remaining 85-90% of the core code and data is quite as simple as your rough summary suggests. - 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: How to handle named resources with DT?
On Tue, Aug 30, 2011 at 12:27:24PM +0300, Felipe Balbi wrote: Hi, On Tue, Aug 30, 2011 at 12:29:12PM +1000, David Gibson wrote: So, I actually agree that in the long term getting resource names in the DT would be a generally good thing. But doing so is a *huge* change in one of the very core semantics of all the DT bindings. It's not something that should be done lightly or quickly. It absolutely should not be tied to how this is handled the longer you take to change, the more complex will it be to change. No, not really. The longer we spend discussing the validity of _byname(), more boards/archs/whatnot will be converted to DT without _byname() and after a certain amount of them are converted, noone will be willing to change and validate everything again. I'm not discussing the validity of _byname (Russell King is, but that's not an argument I have a position of). What I'm saying is that the kernel internal use of byname, and named resources in the DT are different things which should be approached independently. -- 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 signature.asc Description: Digital signature
