[PATCH v2] OMAP3: PM: Add milliseconds interface to suspend wakeup timer
Millisecond resolution is possible and there are use cases for it
(automatic testing).
Seconds-based interface is preserved for compatibility.
Signed-off-by: Ari Kauppi ext-ari.kau...@nokia.com
---
v2: Keep seconds and milliseconds interfaces strictly separate:
- Consistent interface, setting/getting seconds and milliseconds
is always accurate
- Fixes potential overflow issues in omap2_pm_wakeup_on_timer
- Cleaner patch
---
arch/arm/mach-omap2/pm-debug.c |7 +++
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 17 ++---
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 8aafd71..83acaa2 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -548,6 +548,9 @@ static int option_set(void *data, u64 val)
{
u32 *option = data;
+ if (option == wakeup_timer_milliseconds val = 1000)
+ return -EINVAL;
+
*option = val;
if (option == enable_off_mode)
@@ -605,6 +608,10 @@ static int __init pm_dbg_init(void)
sleep_while_idle, pm_dbg_option_fops);
(void) debugfs_create_file(wakeup_timer_seconds, S_IRUGO | S_IWUGO, d,
wakeup_timer_seconds, pm_dbg_option_fops);
+ (void) debugfs_create_file(wakeup_timer_milliseconds,
+ S_IRUGO | S_IWUGO, d,
+ wakeup_timer_milliseconds,
+ pm_dbg_option_fops);
/* Only enable for = ES2.1 . Going to 0V on anything under
* ES2.1 will eventually cause a crash */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b761be5..b3594a9 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -69,6 +69,7 @@ extern int omap3_pm_get_suspend_state(struct powerdomain
*pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
extern u32 wakeup_timer_seconds;
+extern u32 wakeup_timer_milliseconds;
extern struct omap_dm_timer *gptimer_wakeup;
#ifdef CONFIG_PM_DEBUG
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3868c76..d7922a5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -74,6 +74,7 @@ static inline bool is_suspending(void)
u32 enable_off_mode;
u32 sleep_while_idle;
u32 wakeup_timer_seconds;
+u32 wakeup_timer_milliseconds;
u32 voltage_off_while_idle;
struct power_state {
@@ -640,20 +641,21 @@ out:
}
#ifdef CONFIG_SUSPEND
-static void omap2_pm_wakeup_on_timer(u32 seconds)
+static void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
{
u32 tick_rate, cycles;
- if (!seconds)
+ if (!seconds !milliseconds)
return;
tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
- cycles = tick_rate * seconds;
+ cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
omap_dm_timer_stop(gptimer_wakeup);
omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
- pr_info(PM: Resume timer in %d secs (%d ticks at %d ticks/sec.)\n,
- seconds, cycles, tick_rate);
+ pr_info(PM: Resume timer in %u.%03u secs
+(%d ticks at %d ticks/sec.)\n,
+ seconds, milliseconds, cycles, tick_rate);
}
static int omap3_pm_prepare(void)
@@ -667,8 +669,9 @@ static int omap3_pm_suspend(void)
struct power_state *pwrst;
int state, ret = 0;
- if (wakeup_timer_seconds)
- omap2_pm_wakeup_on_timer(wakeup_timer_seconds);
+ if (wakeup_timer_seconds || wakeup_timer_milliseconds)
+ omap2_pm_wakeup_on_timer(wakeup_timer_seconds,
+wakeup_timer_milliseconds);
/* Read current next_pwrsts */
list_for_each_entry(pwrst, pwrst_list, node)
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP3: PM: Add milliseconds interface to suspend wakeup timer
On 23/03/10 08:04 +0100, Kauppi Ari (EXT-Ixonos/Oulu) wrote:
Millisecond resolution is possible and there are use cases for it
(automatic testing).
Seconds-based interface is preserved for compatibility.
Signed-off-by: Ari Kauppi ext-ari.kau...@nokia.com
---
v2: Keep seconds and milliseconds interfaces strictly separate:
- Consistent interface, setting/getting seconds and milliseconds
is always accurate
- Fixes potential overflow issues in omap2_pm_wakeup_on_timer
- Cleaner patch
Nice one. Just what we need, nothing more, nothing less.
Reviewed-by: Phil Carmody ext-phil.2.carm...@nokia.com
Phil
---
arch/arm/mach-omap2/pm-debug.c |7 +++
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 17 ++---
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 8aafd71..83acaa2 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -548,6 +548,9 @@ static int option_set(void *data, u64 val)
{
u32 *option = data;
+ if (option == wakeup_timer_milliseconds val = 1000)
+ return -EINVAL;
+
*option = val;
if (option == enable_off_mode)
@@ -605,6 +608,10 @@ static int __init pm_dbg_init(void)
sleep_while_idle, pm_dbg_option_fops);
(void) debugfs_create_file(wakeup_timer_seconds, S_IRUGO | S_IWUGO, d,
wakeup_timer_seconds, pm_dbg_option_fops);
+ (void) debugfs_create_file(wakeup_timer_milliseconds,
+S_IRUGO | S_IWUGO, d,
+wakeup_timer_milliseconds,
+pm_dbg_option_fops);
/* Only enable for = ES2.1 . Going to 0V on anything under
* ES2.1 will eventually cause a crash */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b761be5..b3594a9 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -69,6 +69,7 @@ extern int omap3_pm_get_suspend_state(struct powerdomain
*pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
extern u32 wakeup_timer_seconds;
+extern u32 wakeup_timer_milliseconds;
extern struct omap_dm_timer *gptimer_wakeup;
#ifdef CONFIG_PM_DEBUG
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 3868c76..d7922a5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -74,6 +74,7 @@ static inline bool is_suspending(void)
u32 enable_off_mode;
u32 sleep_while_idle;
u32 wakeup_timer_seconds;
+u32 wakeup_timer_milliseconds;
u32 voltage_off_while_idle;
struct power_state {
@@ -640,20 +641,21 @@ out:
}
#ifdef CONFIG_SUSPEND
-static void omap2_pm_wakeup_on_timer(u32 seconds)
+static void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
{
u32 tick_rate, cycles;
- if (!seconds)
+ if (!seconds !milliseconds)
return;
tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
- cycles = tick_rate * seconds;
+ cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
omap_dm_timer_stop(gptimer_wakeup);
omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
- pr_info(PM: Resume timer in %d secs (%d ticks at %d ticks/sec.)\n,
- seconds, cycles, tick_rate);
+ pr_info(PM: Resume timer in %u.%03u secs
+ (%d ticks at %d ticks/sec.)\n,
+ seconds, milliseconds, cycles, tick_rate);
}
static int omap3_pm_prepare(void)
@@ -667,8 +669,9 @@ static int omap3_pm_suspend(void)
struct power_state *pwrst;
int state, ret = 0;
- if (wakeup_timer_seconds)
- omap2_pm_wakeup_on_timer(wakeup_timer_seconds);
+ if (wakeup_timer_seconds || wakeup_timer_milliseconds)
+ omap2_pm_wakeup_on_timer(wakeup_timer_seconds,
+ wakeup_timer_milliseconds);
/* Read current next_pwrsts */
list_for_each_entry(pwrst, pwrst_list, node)
--
1.6.4.2
--
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: [PATCHv2 0/3] OMAP: DSS2: Allow us to use SDI
Hi, Valkeinen Tomi (Nokia-D/Helsinki) wrote: Hi, On Wed, 2010-03-17 at 13:35 +0100, Quadros Roger (Nokia-D/Helsinki) wrote: SDI now makes use of vdds_sdi regulator supply. DPI can now be disabled on systems that don't have it changes since v1: - Incorporated review comments - no more omap3xx checks for regulator enable/disable in SDI - Added Kconfig option to enable/disable DPI Roger Quadros (3): OMAP: DSS2: Add Kconfig option for DPI display type OMAP: DSS2: Remove redundant enable/disable calls from SDI OMAP: DSS2: Use vdds_sdi regulator supply in SDI I think this patch set looks ok. Thanks! Tomi Ps. I took the liberty of removing an extra #include plat/cpu.h Are these patches applied somewhere already. I need to send more patches that get N900 panel working for which I need these patches applied. cheers, -roger -- 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
Merge plans for Staging Synaptics Touchscreen Driver
Hi All, Are there any plans to merge the synaptics touchscreen driver (drivers/staging/dream/synaptics_i2c_rmi.c) to drivers/input/touchscreen. We are interested in the same since OMAP3 based Zoom boards use this touchscreen. Pl add (if required) below tested by for the staging driver. Tested-By: Hemanth V heman...@ti.com Thanks Hemanth -- 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 RFC 1/5] omap3: add platform init code for OHCI driver
Aguirre, Sergio wrote:
+static void setup_ohci_io_mux(enum ohci_omap3_port_mode *port_mode)
+{
+ /* REVISIT: these need to be tailored for each of the modes */
+ switch (port_mode[0]) {
+ case OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0:
+ case OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM:
+ omap_mux_init_signal(mm1_rxdp,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_rxdm,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_txse0,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_rxrcv,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_txdat,
+ OMAP_PIN_INPUT_PULLDOWN);
+ omap_mux_init_signal(mm1_txen_n, OMAP_PIN_OUTPUT);
+ break;
+ case OMAP_OHCI_PORT_MODE_UNUSED:
+ default:
+ /* FALLTHROUGH */
Is this the right place for the fall through comment? I guess you meant
Between 'case OMAP_OHCI_PORT_MODE_UNUSED:' and default: lines...
Ah yes, thanks for catching that.
By the way, I did sort out the 2/3/4/6-pin layout, so in the next version,
I'll be able to cover that cleanly.
- Anand
--
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 5/5] OMAP: RX51: Add LCD Panel and framebuffer console to defconfig
From: Roger Quadros roger.quad...@nokia.com Let's see the flashy Tux and console on N900's LCD screen. Signed-off-by: Roger Quadros roger.quad...@nokia.com --- arch/arm/configs/rx51_defconfig | 37 - 1 files changed, 36 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig index 45135ff..d3bac0e 100644 --- a/arch/arm/configs/rx51_defconfig +++ b/arch/arm/configs/rx51_defconfig @@ -1113,7 +1113,40 @@ CONFIG_RADIO_ADAPTERS=y # # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set -# CONFIG_FB is not set +CONFIG_FB=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y + +# Frame buffer hardware drivers +# +CONFIG_OMAP2_VRAM=y +CONFIG_OMAP2_VRFB=y +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=2 +CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y +# CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set +# CONFIG_OMAP2_DSS_DPI is not set +# CONFIG_OMAP2_DSS_RFBI is not set +# CONFIG_OMAP2_DSS_VENC is not set +CONFIG_OMAP2_DSS_SDI=y +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 +CONFIG_FB_OMAP2=y +CONFIG_FB_OMAP2_DEBUG_SUPPORT=y +CONFIG_FB_OMAP2_NUM_FBS=3 + +# +# OMAP2/3 Display Device Drivers +# +# CONFIG_PANEL_GENERIC is not set +# CONFIG_PANEL_SHARP_LS037V7DW01 is not set +# CONFIG_PANEL_SHARP_LQ043T1DG01 is not set +# CONFIG_PANEL_TOPPOLY_TDO35S is not set +# CONFIG_PANEL_TPO_TD043MTEA1 is not set +CONFIG_PANEL_ACX565AKM=y + # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # @@ -1130,6 +1163,8 @@ CONFIG_DISPLAY_SUPPORT=y # # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_LOGO=y CONFIG_SOUND=y # CONFIG_SOUND_OSS_CORE is not set CONFIG_SND=y -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP: RX51: Add LCD Panel support
From: Roger Quadros roger.quad...@nokia.com
Adds basic support for LCD Panel on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13
arch/arm/mach-omap2/board-rx51-video.c | 95 ++
3 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rx51-video.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..b03cbb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
+ board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..f404537 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,7 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata;
@@ -54,6 +55,11 @@ static struct omap2_mcspi_device_config wl1251_mcspi_config
= {
.single_channel = 1,
};
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -64,6 +70,13 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.controller_data= wl1251_mcspi_config,
.platform_data = wl1251_pdata,
},
+ [RX51_SPI_MIPID] = {
+ .modalias = acx565akm,
+ .bus_num= 1,
+ .chip_select= 2,
+ .max_speed_hz = 600,
+ .controller_data= mipid_mcspi_config,
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
new file mode 100644
index 000..e3e22a8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -0,0 +1,95 @@
+/*
+ * linux/arch/arm/mach-omap2/board-rx51-peripherals.c
+ *
+ * Copyright (C) 2010 Nokia
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/spi/spi.h
+
+#include asm/mach-types.h
+#include plat/mux.h
+#include plat/display.h
+#include plat/mcspi.h
+
+#include mux.h
+
+#define RX51_LCD_RESET_GPIO90
+
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+static int rx51_lcd_enable(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 1);
+ return 0;
+}
+
+static void rx51_lcd_disable(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 0);
+}
+
+static struct omap_dss_device rx51_lcd_device = {
+ .name = lcd,
+ .driver_name= panel-acx565akm,
+ .type = OMAP_DISPLAY_TYPE_SDI,
+ .phy.sdi.datapairs = 2,
+ .reset_gpio = RX51_LCD_RESET_GPIO,
+ .platform_enable= rx51_lcd_enable,
+ .platform_disable = rx51_lcd_disable,
+};
+
+static struct omap_dss_device *rx51_dss_devices[] = {
+ rx51_lcd_device,
+};
+
+static struct omap_dss_board_info rx51_dss_board_info = {
+ .num_devices= ARRAY_SIZE(rx51_dss_devices),
+ .devices= rx51_dss_devices,
+ .default_device = rx51_lcd_device,
+};
+
+struct platform_device rx51_display_device = {
+ .name = omapdss,
+ .id = -1,
+ .dev= {
+ .platform_data = rx51_dss_board_info,
+ },
+};
+
+static struct platform_device *rx51_video_devices[] __initdata = {
+ rx51_display_device,
+};
+
+static int __init rx51_video_init(void)
+{
+ if (!machine_is_nokia_rx51())
+ return 0;
+
+ if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
+ pr_err(%s cannot configure MUX for LCD RESET\n, __func__);
+ return 0;
+ }
+
+ if
[PATCH 4/5] OMAP: DSS2: Add ACX565AKM Panel Driver
From: Roger Quadros roger.quad...@nokia.com
This is the panel used on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
drivers/video/omap2/displays/Kconfig |5 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-acx565akm.c | 551
3 files changed, 557 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-acx565akm.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index dfb57ee..c34e1f5 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -37,4 +37,9 @@ config PANEL_TPO_TD043MTEA1
help
LCD Panel used in OMAP3 Pandora
+config PANEL_ACX565AKM
+ tristate ACX565AKM Panel
+ depends on OMAP2_DSS_SDI
+ help
+ This is the LCD panel used on Nokia N900
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index e2bb321..aa38609 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) +=
panel-sharp-lq043t1dg01.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
+obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
new file mode 100644
index 000..a63447f
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -0,0 +1,551 @@
+/*
+ * Support for ACX565AKM LCD Panel used on Nokia N900
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Author: Roger Quadros roger.quad...@nokia.com
+ *
+ * Based on panel-generic.c by Tomi Valkeinen tomi.valkei...@nokia.com
+ * Borrowed MIPID SPI code from Imre Deak imre.d...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/jiffies.h
+#include linux/sched.h
+#include linux/backlight.h
+
+#include plat/display.h
+
+#define MIPID_CMD_READ_DISP_ID 0x04
+#define MIPID_CMD_READ_RED 0x06
+#define MIPID_CMD_READ_GREEN 0x07
+#define MIPID_CMD_READ_BLUE0x08
+#define MIPID_CMD_READ_DISP_STATUS 0x09
+#define MIPID_CMD_RDDSDR 0x0F
+#define MIPID_CMD_SLEEP_IN 0x10
+#define MIPID_CMD_SLEEP_OUT0x11
+#define MIPID_CMD_DISP_OFF 0x28
+#define MIPID_CMD_DISP_ON 0x29
+#define MIPID_CMD_WRITE_DISP_BRIGHTNESS0x51
+#define MIPID_CMD_READ_DISP_BRIGHTNESS 0x52
+#define MIPID_CMD_WRITE_CTRL_DISP 0x53
+
+#define CTRL_DISP_BRIGHTNESS_CTRL_ON (1 5)
+#define CTRL_DISP_AMBIENT_LIGHT_CTRL_ON(1 4)
+#define CTRL_DISP_BACKLIGHT_ON (1 2)
+#define CTRL_DISP_AUTO_BRIGHTNESS_ON (1 1)
+
+#define MIPID_CMD_READ_CTRL_DISP 0x54
+#define MIPID_CMD_WRITE_CABC 0x55
+#define MIPID_CMD_READ_CABC0x56
+
+#define MIPID_VER_LPH8923 3
+#define MIPID_VER_LS041Y3 4
+#define MIPID_VER_L4F00311 8
+#define MIPID_VER_ACX565AKM9
+
+struct acx565akm_device {
+ char*name;
+ int enabled;
+ int model;
+ int revision;
+ u8 display_id[3];
+ unsignedhas_bc:1;
+ unsignedhas_cabc:1;
+ unsignedcabc_mode;
+ unsigned long hw_guard_end; /* next value of jiffies
+ when we can issue the
+ next sleep in/out command */
+ unsigned long hw_guard_wait; /* max guard time in jiffies */
+
+ struct spi_device *spi;
+ struct mutexmutex;
+
+ struct omap_dss_device *dssdev;
+};
+
+static struct acx565akm_device acx_dev;
+
+/*MIPID interface-*/
+
+static void acx565akm_transfer(struct acx565akm_device *md, int cmd,
+ const u8 *wbuf, int wlen, u8 *rbuf, int rlen)
+{
+ struct spi_message m;
+ struct spi_transfer *x, xfer[5];
+
[PATCH 2/5] OMAP: RX51: Add vdds_sdi supply voltage for SDI
From: Roger Quadros roger.quad...@nokia.com
The SDI Display subsystem needs access to the vdds_sdi supply
regulator. This is TWL4030's VAUX1 supply on RX-51.
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index f404537..3ef805e 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -300,6 +300,19 @@ static struct regulator_consumer_supply rx51_vsim_supply =
{
.dev_name = mmci-omap-hs.1,
};
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+extern struct platform_device rx51_display_device;
+#endif
+
+static struct regulator_consumer_supply rx51_vaux1_consumers[] = {
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+ {
+ .supply = vdds_sdi,
+ .dev= rx51_display_device.dev,
+ },
+#endif
+};
+
static struct regulator_init_data rx51_vaux1 = {
.constraints = {
.name = V28,
@@ -310,6 +323,8 @@ static struct regulator_init_data rx51_vaux1 = {
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vaux1_consumers),
+ .consumer_supplies = rx51_vaux1_consumers,
};
static struct regulator_init_data rx51_vaux2 = {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] OMAP: RX51: Add Touch Controller in SPI board info
From: Roger Quadros roger.quad...@nokia.com
The Touch controller and LCD Panel share the same SPI bus 1.
So, we need to define the touch controller in the SPI board info
else, the SPI bus will be contended due to invalid state of
Touch controller's Chip Select thus preventing the LCD panel
from working.
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3ef805e..020f354 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -46,6 +46,7 @@
enum {
RX51_SPI_WL1251,
RX51_SPI_MIPID, /* LCD panel */
+ RX51_SPI_TSC2005, /* Touch Controller */
};
static struct wl12xx_platform_data wl1251_pdata;
@@ -60,6 +61,11 @@ static struct omap2_mcspi_device_config mipid_mcspi_config =
{
.single_channel = 1,
};
+static struct omap2_mcspi_device_config tsc2005_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -77,6 +83,15 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.max_speed_hz = 600,
.controller_data= mipid_mcspi_config,
},
+ [RX51_SPI_TSC2005] = {
+ .modalias = tsc2005,
+ .bus_num= 1,
+ .chip_select= 0,
+ /* .irq = OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),*/
+ .max_speed_hz = 600,
+ .controller_data= tsc2005_mcspi_config,
+ /* .platform_data = tsc2005_config,*/
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP: RX51: Add LCD Panel Support for N900
These patches get the N900 LCD panel working. Apply's cleanly on 2.6.34-rc2 Pre-requisites: https://patchwork.kernel.org/patch/86318/ https://patchwork.kernel.org/patch/86319/ https://patchwork.kernel.org/patch/86320/ --- Roger Quadros (5): OMAP: RX51: Add LCD Panel support OMAP: RX51: Add vdds_sdi supply voltage for SDI OMAP: RX51: Add Touch Controller in SPI board info OMAP: DSS2: Add ACX565AKM Panel Driver OMAP: RX51: Add LCD Panel and framebuffer console to defconfig arch/arm/configs/rx51_defconfig| 37 ++- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-rx51-peripherals.c | 43 ++ arch/arm/mach-omap2/board-rx51-video.c | 95 drivers/video/omap2/displays/Kconfig |5 + drivers/video/omap2/displays/Makefile |1 + drivers/video/omap2/displays/panel-acx565akm.c | 551 7 files changed, 732 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-rx51-video.c create mode 100644 drivers/video/omap2/displays/panel-acx565akm.c -- 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/5] OMAP: RX51: Add LCD Panel support
On Tue, Mar 23, 2010 at 10:56 AM, Roger Quadros roger.quad...@nokia.com wrote:
From: Roger Quadros roger.quad...@nokia.com
Adds basic support for LCD Panel on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13
arch/arm/mach-omap2/board-rx51-video.c | 95
++
3 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rx51-video.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..b03cbb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) +=
board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
+ board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..f404537 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,7 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata;
@@ -54,6 +55,11 @@ static struct omap2_mcspi_device_config
wl1251_mcspi_config = {
.single_channel = 1,
};
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -64,6 +70,13 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.controller_data = wl1251_mcspi_config,
.platform_data = wl1251_pdata,
},
+ [RX51_SPI_MIPID] = {
+ .modalias = acx565akm,
+ .bus_num = 1,
+ .chip_select = 2,
+ .max_speed_hz = 600,
+ .controller_data = mipid_mcspi_config,
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
new file mode 100644
index 000..e3e22a8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -0,0 +1,95 @@
+/*
+ * linux/arch/arm/mach-omap2/board-rx51-peripherals.c
board-rx51-video.c
+ *
+ * Copyright (C) 2010 Nokia
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/spi/spi.h
+
+#include asm/mach-types.h
+#include plat/mux.h
+#include plat/display.h
+#include plat/mcspi.h
+
+#include mux.h
+
+#define RX51_LCD_RESET_GPIO 90
+
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+static int rx51_lcd_enable(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 1);
+ return 0;
+}
+
+static void rx51_lcd_disable(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(dssdev-reset_gpio, 0);
+}
+
+static struct omap_dss_device rx51_lcd_device = {
+ .name = lcd,
+ .driver_name = panel-acx565akm,
+ .type = OMAP_DISPLAY_TYPE_SDI,
+ .phy.sdi.datapairs = 2,
+ .reset_gpio = RX51_LCD_RESET_GPIO,
+ .platform_enable = rx51_lcd_enable,
+ .platform_disable = rx51_lcd_disable,
+};
+
+static struct omap_dss_device *rx51_dss_devices[] = {
+ rx51_lcd_device,
+};
+
+static struct omap_dss_board_info rx51_dss_board_info = {
+ .num_devices = ARRAY_SIZE(rx51_dss_devices),
+ .devices = rx51_dss_devices,
+ .default_device = rx51_lcd_device,
+};
+
+struct platform_device rx51_display_device = {
+ .name = omapdss,
+ .id = -1,
+ .dev = {
+ .platform_data = rx51_dss_board_info,
+ },
+};
+
+static struct platform_device *rx51_video_devices[] __initdata = {
+ rx51_display_device,
+};
+
+static int __init rx51_video_init(void)
+{
+ if (!machine_is_nokia_rx51())
+
[PATCH] i2c: omap: fix OOPS in omap_i2c_unidle() during probe
Commit d84d3ea317ce0db89ce0903b4037f800c5d4c477 added register shift to allow also 16-bit register access. However, omap_i2c_unidle() is called before these are set which causes the following OOPS: Unhandled fault: alignment exception (0x801) at 0xfa070009 Internal error: : 801 [#1] last sysfs file: Modules linked in: CPU: 0Not tainted (2.6.34-rc2-00052-gae6be51 #3) PC is at omap_i2c_unidle+0x44/0x138 LR is at trace_hardirqs_on_caller+0x158/0x18c pc : [c01cd2c4]lr : [c00743f8]psr: 2013 sp : cfc2bf10 ip : 0009 fp : r10: r9 : r8 : c0378560 r7 : c0378b88 r6 : c0378558 r5 : cfcadc00 r4 : cfcadc00 r3 : 0009 r2 : fa07 r1 : r0 : Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387f Table: 80004019 DAC: 0017 Process swapper (pid: 1, stack limit = 0xcfc2a2e8) Stack: (0xcfc2bf10 to 0xcfc2c000) bf00: c0372cf8 c027225c c0a69678 bf20: cfc3e508 c0500898 c0378560 c0378560 c0500898 cfcac8c0 c04fc280 c017d4f4 bf40: c0378560 c017c63c c0378560 c0378594 c0500898 cfcac8c0 c04fc280 c017c754 bf60: c017c6f4 c0500898 c017beac cfc16a5c cfc3fd94 c0023448 c0500898 bf80: c0500898 c017b7d4 c032dc7f 0093 cfc28d40 c0023448 c0500898 bfa0: c017ca48 c0023448 c001d274 bfc0: c002b344 0031 0192 c0023448 bfe0: c0008578 c002c304 ffdf [c01cd2c4] (omap_i2c_unidle+0x44/0x138) from [c027225c] (omap_i2c_probe+0x1a4/0x398) [c027225c] (omap_i2c_probe+0x1a4/0x398) from [c017d4f4] (platform_drv_probe+0x18/0x1c) [c017d4f4] (platform_drv_probe+0x18/0x1c) from [c017c63c] (driver_probe_device+0xc0/0x178) [c017c63c] (driver_probe_device+0xc0/0x178) from [c017c754] (__driver_attach+0x60/0x84) [c017c754] (__driver_attach+0x60/0x84) from [c017beac] (bus_for_each_dev+0x44/0x74) [c017beac] (bus_for_each_dev+0x44/0x74) from [c017b7d4] (bus_add_driver+0x9c/0x218) [c017b7d4] (bus_add_driver+0x9c/0x218) from [c017ca48] (driver_register+0xa8/0x130) [c017ca48] (driver_register+0xa8/0x130) from [c002b344] (do_one_initcall+0x5c/0x1b8) [c002b344] (do_one_initcall+0x5c/0x1b8) from [c0008578] (kernel_init+0x90/0x144) [c0008578] (kernel_init+0x90/0x144) from [c002c304] (kernel_thread_exit+0x0/0x8) Code: e5942004 e3a0c009 e1a0331c e3a01000 (e18210b3) ---[ end trace 1b75b31a2719ed1c ]--- This patch moves register shift setting before any register accesses are done. Signed-off-by: Mika Westerberg ext-mika.1.westerb...@nokia.com Cc: Cory Maccarrone darkstar6...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index c7c2375..0d5a54a 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -902,6 +902,11 @@ omap_i2c_probe(struct platform_device *pdev) platform_set_drvdata(pdev, dev); + if (cpu_is_omap7xx()) + dev-reg_shift = 1; + else + dev-reg_shift = 2; + if ((r = omap_i2c_get_clocks(dev)) != 0) goto err_iounmap; @@ -925,11 +930,6 @@ omap_i2c_probe(struct platform_device *pdev) dev-b_hw = 1; /* Enable hardware fixes */ } - if (cpu_is_omap7xx()) - dev-reg_shift = 1; - else - dev-reg_shift = 2; - /* reset ASAP, clearing any IRQs */ omap_i2c_init(dev); -- 1.5.6.5 -- 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/5] OMAP: RX51: Add LCD Panel support
ext pHilipp Zabel wrote:
On Tue, Mar 23, 2010 at 10:56 AM, Roger Quadros roger.quad...@nokia.com wrote:
From: Roger Quadros roger.quad...@nokia.com
Adds basic support for LCD Panel on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13
arch/arm/mach-omap2/board-rx51-video.c | 95 ++
3 files changed, 109 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rx51-video.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4b9fc57..b03cbb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
+ board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..f404537 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,7 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata;
@@ -54,6 +55,11 @@ static struct omap2_mcspi_device_config wl1251_mcspi_config
= {
.single_channel = 1,
};
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -64,6 +70,13 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.controller_data= wl1251_mcspi_config,
.platform_data = wl1251_pdata,
},
+ [RX51_SPI_MIPID] = {
+ .modalias = acx565akm,
+ .bus_num= 1,
+ .chip_select= 2,
+ .max_speed_hz = 600,
+ .controller_data= mipid_mcspi_config,
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
new file mode 100644
index 000..e3e22a8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -0,0 +1,95 @@
+/*
+ * linux/arch/arm/mach-omap2/board-rx51-peripherals.c
board-rx51-video.c
yup. thanks :P
-roger
--
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] musb: fix power field to hold all possible values
Hi, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gupta, Ajay Kumar Sent: Friday, February 26, 2010 10:03 AM To: Tony Lindgren; Felipe Balbi Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] musb: fix power field to hold all possible values Hi, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, February 26, 2010 3:50 AM To: Felipe Balbi Cc: Gupta, Ajay Kumar; linux-omap@vger.kernel.org Subject: Re: [PATCH] musb: fix power field to hold all possible values * Felipe Balbi m...@felipebalbi.com [100223 12:30]: Hi, On Tue, Feb 23, 2010 at 08:01:50PM +0530, Gupta, Ajay Kumar wrote: Board files are providing the actual mA and it is getting divided in Arch/arm/mach-omap2/usb-musb.c. See the code snippet below, musb_plat.clock = ick; musb_plat.board_data = board_data; -- musb_plat.power = board_data-power 1; musb_plat.mode = board_data-mode; So we need to either take this patch or fix this logic of dividing the mA supplied from all omap board files. that's true, had missed that. Sorry. Hmm, I believe this value is also divided somewhere else but I forgot where. In any case, when making changes like this please run the standard USB tests for gadgets and OTG. Otherwise things are guaranteed to break for USB certs :) Tony, Currently the flow is, 1. Actual mA provided in all omap board files. 2. mA gets divided in usb-musb.c 3. mA multiplied by two in driver/usb/musb/musb_core.c to pass it to hcd-power_budget. So the current patch fixes the logic in step [1] above to fill mA value Above 255. Felipe/Tony, Any update on this patch ? Regards, Ajay -Ajay Tony -- 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 -- 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] arm: omap1/2/3/4: convert clocksource to a platform_driver
Convert the omap32k clocksource driver into a platform_driver
and while at that, also remove the ifdeferry around the code.
Tested on N900.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
this patch depends on Aaro's offset_32k patch:
http://marc.info/?l=linux-omapm=126927727024322w=2
arch/arm/mach-omap1/devices.c| 24
arch/arm/mach-omap2/devices.c| 38 ++
arch/arm/plat-omap/Makefile |4 +-
arch/arm/plat-omap/clocksource.c | 247 ++
arch/arm/plat-omap/common.c | 158
5 files changed, 311 insertions(+), 160 deletions(-)
create mode 100644 arch/arm/plat-omap/clocksource.c
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 379100c..1265cad 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -28,6 +28,29 @@
/*-*/
+#define OMAP16XX_TIMER_32K_BASE0xfffbc400
+
+static struct resources omap_32k_resources[] = {
+ {
+ .start = OMAP16XX_TIMER_32K_BASE,
+ .end= SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-clksrc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap16xx())
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
#defineOMAP_RTC_BASE 0xfffb4800
@@ -295,6 +318,7 @@ static int __init omap1_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
+ omap_init_32k;
omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 23e4d77..8f8eb4f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,43 @@
#include mux.h
+static struct resource omap_32k_resources[] = {
+ {
+ .start = -EINVAL, /* gets changed later */
+ .end= -EINVAL, /* gets changed later */
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-clksrc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap2420()) {
+ omap_32k_resources[0].start = OMAP2420_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP2420_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap2430()) {
+ omap_32k_resources[0].start = OMAP2430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP2430_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap34xx()) {
+ omap_32k_resources[0].start = OMAP3430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP3430_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap44xx()) {
+ omap_32k_resources[0].start = OMAP4430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP4430_32KSYNCT_BASE + SZ_4K;
+ } else {/* not supported */
+ return;
+ }
+
+
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
static struct resource cam_resources[] = {
@@ -794,6 +831,7 @@ static int __init omap2_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
omap_hsmmc_reset();
+ omap_init_32k();
omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 98f0191..4630be3 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o gpio.o \
-usb.o fb.o io.o
+usb.o fb.o io.o clocksource.o
obj-m :=
obj-n :=
obj- :=
@@ -30,4 +30,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
\ No newline at end of file
+obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/clocksource.c b/arch/arm/plat-omap/clocksource.c
new file mode 100644
index 000..e5381e5
--- /dev/null
+++ b/arch/arm/plat-omap/clocksource.c
@@ -0,0 +1,247 @@
+/*
+ * omap.c -- OMAP Clocksource Driver
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Copyright
Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 MD5 driver
On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.
This driver implements async and sync crypto API.
It still contains pr_debug() for debugging purpose.
Will be remove for integration.
Dmitry Kasatkin (2):
sec: omap sha1 md5 driver
sec: Makefile/Kconfig update for omap sha1 md5 driver
It looks good to me as far as the Crypto API is concerned.
My only question is what's your plan with respect to HMAC? If
you're going to do it in hardware then it's fine as it is.
Otherwise you need to implement export/import and we also need
to add ahash support to hmac.c.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] arm: omap1/2/3/4: convert clocksource to a platform_driver
Convert the omap32k clocksource driver into a platform_driver
and while at that, also remove the ifdeferry around the code.
Tested on N900. Compile tested with omap_h2_1610_defconfig.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
this patch depends on Aaro's offset_32k patch:
http://marc.info/?l=linux-omapm=126927727024322w=2
Changes since v1:
. Aaro noted a few typos which I didn't catch before. Now fixed.
arch/arm/mach-omap1/devices.c| 24
arch/arm/mach-omap2/devices.c| 38 ++
arch/arm/plat-omap/Makefile |4 +-
arch/arm/plat-omap/clocksource.c | 247 ++
arch/arm/plat-omap/common.c | 158
5 files changed, 311 insertions(+), 160 deletions(-)
create mode 100644 arch/arm/plat-omap/clocksource.c
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 379100c..acbf475 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -28,6 +28,29 @@
/*-*/
+#define OMAP16XX_TIMER_32K_BASE0xfffbc400
+
+static struct resource omap_32k_resources[] = {
+ {
+ .start = OMAP16XX_TIMER_32K_BASE,
+ .end= SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-clksrc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap16xx())
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
#defineOMAP_RTC_BASE 0xfffb4800
@@ -295,6 +318,7 @@ static int __init omap1_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
+ omap_init_32k();
omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 23e4d77..8f8eb4f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,43 @@
#include mux.h
+static struct resource omap_32k_resources[] = {
+ {
+ .start = -EINVAL, /* gets changed later */
+ .end= -EINVAL, /* gets changed later */
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-clksrc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap2420()) {
+ omap_32k_resources[0].start = OMAP2420_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP2420_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap2430()) {
+ omap_32k_resources[0].start = OMAP2430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP2430_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap34xx()) {
+ omap_32k_resources[0].start = OMAP3430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP3430_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap44xx()) {
+ omap_32k_resources[0].start = OMAP4430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP4430_32KSYNCT_BASE + SZ_4K;
+ } else {/* not supported */
+ return;
+ }
+
+
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
static struct resource cam_resources[] = {
@@ -794,6 +831,7 @@ static int __init omap2_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
omap_hsmmc_reset();
+ omap_init_32k();
omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 98f0191..4630be3 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o gpio.o \
-usb.o fb.o io.o
+usb.o fb.o io.o clocksource.o
obj-m :=
obj-n :=
obj- :=
@@ -30,4 +30,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
\ No newline at end of file
+obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/clocksource.c b/arch/arm/plat-omap/clocksource.c
new file mode 100644
index 000..e5381e5
--- /dev/null
+++
Re: [PATCH RFC 2/5] usb: ohci: introduce omap3 ohci-hcd driver
On Mon, Mar 22, 2010 at 07:53:32AM +0100, ext Gadiyar, Anand wrote:
+ void __iomem*uhh_base;
+ void __iomem*tll_base;
+ void __iomem*ohci_base;
this is something we need to think carefully, right ? I believe ehci is
already ioremap()ing uhh_base and tll_base ??
Correct. In it's current form, ehci and ohci will be mutually exclusive.
We'll need to fix this later, but I was hoping to get this driver
in so people can actually use it and test.
Nobody can use EHCI and OHCI together on OMAP3 today anyway - the only
problem we'll have right now is that we cannot build-in both drivers in
the kernel at the same time.
I'll work on getting this in place. I was thinking of moving uhh_* and tll_*
configuration out of these two drivers and into mach-omap2/usb-ehci.c.
Along with this, we have the board files specify one set of port-modes for
each port, instead of one set each for EHCI and OHCI. Then, based on this,
we can ioremap and configure the UHH and TLL blocks once during init.
What do you think?
I was thinking more on the direction of having a core platform_driver
instantiate ehci and ohci platform_drivers and pass the ioremaped uhh
and tll bases down as, e.g. platform_data. But I don't know still.
Having the board code ioremap() that area doesn't sound good. Maybe
someone else on linux-omap or linux-usb would have good tips ??
+ .shutdown = ohci_hcd_omap_shutdown,
+ .driver = {
+ .name = ohci-omap3,
+ },
no suspend/resume yet ?? :-(
I made this as similar to the current ehci-omap driver as possible.
I wanted to get the functionality in, while I work on adding the
power-management support.
ok makes sense :-)
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] musb: fix power field to hold all possible values
On Tue, Mar 23, 2010 at 12:41:16PM +0100, ext Gupta, Ajay Kumar wrote: Felipe/Tony, Any update on this patch ? It's fine by me but I was expecting Tony to pick it up since it's on the arch code. Tony, do you want me to queue it for Greg or you take it forward ? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] musb: Add extvbus in musb_board_data
Hi,
-Original Message-
From: Gupta, Ajay Kumar
Sent: Wednesday, February 24, 2010 10:01 AM
To: linux-omap@vger.kernel.org
Cc: felipe.ba...@nokia.com; Gupta, Ajay Kumar
Subject: [PATCH] musb: Add extvbus in musb_board_data
EXTVBUS programming is required by OMAP3EVM REV =E to supply 500mA
power so adding a flag which can be used by musb driver to program
EXTVBUS.
Felipe,
Any comment on this one ?
Regards,
ajay
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Created against l-o master branch and on top of below patch.
[PATCH] musb: fix power field to hold all possible values
arch/arm/mach-omap2/board-omap3evm.c |3 +++
arch/arm/mach-omap2/usb-musb.c|1 +
arch/arm/plat-omap/include/plat/usb.h |1 +
3 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index d6bc88c..b7ea9b7 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -702,6 +702,9 @@ static void __init omap3_evm_init(void)
omap_mux_init_gpio(21, OMAP_PIN_INPUT_PULLUP);
ehci_pdata.reset_gpio_port[1] = 21;
+ /* EVM REV = E can supply 500mA with EXTVBUS programming */
+ musb_board_data.power = 500;
+ musb_board_data.extvbus = 1;
} else {
/* setup EHCI phy reset on MDC */
omap_mux_init_gpio(135, OMAP_PIN_OUTPUT);
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-
musb.c
index 53a9638..17726ac 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -106,6 +106,7 @@ void __init usb_musb_init(struct omap_musb_board_data
*board_data)
musb_plat.board_data = board_data;
musb_plat.power = board_data-power 1;
musb_plat.mode = board_data-mode;
+ musb_plat.extvbus = board_data-extvbus;
if (platform_device_register(musb_device) 0)
printk(KERN_ERR Unable to register HS-USB (MUSB) device\n);
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-
omap/include/plat/usb.h
index b181297..d82bf77 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -47,6 +47,7 @@ struct omap_musb_board_data {
u8 interface_type;
u8 mode;
u16 power;
+ unsigned extvbus:1;
};
enum musb_interface{MUSB_INTERFACE_ULPI, MUSB_INTERFACE_UTMI};
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP-OPP][PATCH 3/4] omap: pm: opp: add ability to store data per opp
Gopinath, Thara had written, on 03/23/2010 12:06 AM, the following:
[...] [I am not about to repeat everything I stated in previous
threads.. so snipping the discussion down.]
Otherwise the primary idea to remove OPP ID is good, and the way to go.
good. So lets NAK that SR series and see how else we can implement it
without OPP ID. I am open to any clean mechanisms you may propose
without using OPP ID referencing :).
Ok guys.. In the current V2 series , I have linked N targets with voltage..
Only it does not come from voltage layer but from smartreflex devices
layer.
The smartreflex driver does not use opp ids at all.. Also whether you
call
it by opp ids or by any other name, we need to know the number of
different
voltages supported by VDD1 and VDD2 and form the table.. That is exactly
what I am doing in smartreflex device layer. I am just creating a
table with
different voltages and N target values associated with those voltages.
To create this table I need to know there should be 5 voltages for VDD1
and 3 voltages for VDD2 which unfortunately coincides with the number of
different OPP's defined in OMAP3430 today..
SR patches should ideally be discussed in SR patch series context
anyways, since we are looking at the fundamentals of OPP:
3430: VDD1: 5 voltages+frequencies, VDD2: 3 voltages and frequencies
3630: VDD1: 4 voltages+frequencies, VDD2: 2 voltages and frequencies
are there cases where the number of discrete voltage != number of
supported frequencies?
Agreed that for a voltage the characteristic data is unique. but since a
voltage is tied to a frequency, does'nt it make sense to tie it to an
OPP (my initial point in the first place)?
look at the amount of redundant data:
static void __init omap34xx_sr_volt_details(struct omap_smartreflex_data
*sr_data, int srid)
{
if (srid == SR1) {
sr_data-no_opp = opp_get_opp_count(OPP_MPU);
sr_data-sr_volt_data =
kzalloc(sizeof(sr_data-sr_volt_data) *
sr_data-no_opp , GFP_KERNEL);
WARN_ON(!sr_data-sr_volt_data);
sr_data-sr_volt_data[0].voltage = 975000;
sr_data-sr_volt_data[1].voltage = 1075000;
sr_data-sr_volt_data[2].voltage = 120;
sr_data-sr_volt_data[3].voltage = 127;
sr_data-sr_volt_data[4].voltage = 135;
} else if (srid == SR2) {
sr_data-no_opp = 3;
sr_data-sr_volt_data =
kzalloc(sizeof(sr_data-sr_volt_data) *
sr_data-no_opp , GFP_KERNEL);
WARN_ON(!sr_data-sr_volt_data);
sr_data-sr_volt_data[0].voltage = 975000;
sr_data-sr_volt_data[1].voltage = 105;
sr_data-sr_volt_data[2].voltage = 115;
}
}
If you link sr_volt_data with OPP, you have a simple scalable soln
without having to manage voltage in multiple places etc.
the implementation is definitely based on number of OPPs :). and it is
not exactly the most scalable implementation currently present.
I also think it is an excellent idea to NAK a series of 19 patches for
which everybody has been shouting for, for this reason.
NAK was for SRID usage and voltage indexing which makes scaling across
silicon variants troublesome.
--
Regards,
Nishanth Menon
--
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 v3] arm: omap1/2/3/4: convert clocksource to a platform_driver
Convert the omap32k clocksource driver into a platform_driver
and while at that, also remove the ifdeferry around the code.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
this patch depends on Aaro's offset_32k patch:
http://marc.info/?l=linux-omapm=126927727024322w=2
Changes since v2:
. the clock name was wrong.
The device was still working, probably because bootloader
enables the clock.
arch/arm/mach-omap1/devices.c| 24
arch/arm/mach-omap2/devices.c| 38 ++
arch/arm/plat-omap/Makefile |4 +-
arch/arm/plat-omap/clocksource.c | 247 ++
arch/arm/plat-omap/common.c | 158
5 files changed, 311 insertions(+), 160 deletions(-)
create mode 100644 arch/arm/plat-omap/clocksource.c
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 379100c..acbf475 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -28,6 +28,29 @@
/*-*/
+#define OMAP16XX_TIMER_32K_BASE0xfffbc400
+
+static struct resource omap_32k_resources[] = {
+ {
+ .start = OMAP16XX_TIMER_32K_BASE,
+ .end= SZ_4K,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-clksrc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap16xx())
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
#defineOMAP_RTC_BASE 0xfffb4800
@@ -295,6 +318,7 @@ static int __init omap1_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
+ omap_init_32k();
omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 23e4d77..8f8eb4f 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -29,6 +29,43 @@
#include mux.h
+static struct resource omap_32k_resources[] = {
+ {
+ .start = -EINVAL, /* gets changed later */
+ .end= -EINVAL, /* gets changed later */
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap_32k_device = {
+ .name = omap-clksrc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(omap_32k_resources),
+ .resource = omap_32k_resources,
+};
+
+static void omap_init_32k(void)
+{
+ if (cpu_is_omap2420()) {
+ omap_32k_resources[0].start = OMAP2420_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP2420_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap2430()) {
+ omap_32k_resources[0].start = OMAP2430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP2430_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap34xx()) {
+ omap_32k_resources[0].start = OMAP3430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP3430_32KSYNCT_BASE + SZ_4K;
+ } else if (cpu_is_omap44xx()) {
+ omap_32k_resources[0].start = OMAP4430_32KSYNCT_BASE;
+ omap_32k_resources[0].end = OMAP4430_32KSYNCT_BASE + SZ_4K;
+ } else {/* not supported */
+ return;
+ }
+
+
+ (void) platform_device_register(omap_32k_device);
+};
+
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
static struct resource cam_resources[] = {
@@ -794,6 +831,7 @@ static int __init omap2_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
omap_hsmmc_reset();
+ omap_init_32k();
omap_init_camera();
omap_init_mbox();
omap_init_mcspi();
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 98f0191..4630be3 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o gpio.o \
-usb.o fb.o io.o
+usb.o fb.o io.o clocksource.o
obj-m :=
obj-n :=
obj- :=
@@ -30,4 +30,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y)
# OMAP mailbox framework
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o
-obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
\ No newline at end of file
+obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o
diff --git a/arch/arm/plat-omap/clocksource.c b/arch/arm/plat-omap/clocksource.c
new file mode 100644
index 000..9a43b0c
--- /dev/null
+++ b/arch/arm/plat-omap/clocksource.c
@@ -0,0
Regulator message while booting recent kernel
This is from a recent git kernel. Any ideas how I can make it go away? [ 16.512817] [ cut here ] [ 16.517517] WARNING: at drivers/regulator/core.c:1375 _regulator_disable+0x58 /0x170() [ 16.525451] unbalanced disables for dummy [ 16.529479] Modules linked in: [ 16.532623] [c0039628] (unwind_backtrace+0x0/0xdc) from [c005c864] (warn_ slowpath_common+0x4c/0x80) [ 16.542114] [c005c864] (warn_slowpath_common+0x4c/0x80) from [c005c8d4] ( warn_slowpath_fmt+0x28/0x38) [ 16.551788] [c005c8d4] (warn_slowpath_fmt+0x28/0x38) from [c020575c] (_re gulator_disable+0x58/0x170) [ 16.561370] [c020575c] (_regulator_disable+0x58/0x170) from [c0205968] (r egulator_disable+0x20/0x38) [ 16.570953] [c0205968] (regulator_disable+0x20/0x38) from [c02b2314] (oma p_hsmmc_23_set_power+0xb8/0xf4) [ 16.580902] [c02b2314] (omap_hsmmc_23_set_power+0xb8/0xf4) from [c02b1400 ] (omap_hsmmc_set_ios+0x74/0x40c) [ 16.591003] [c02b1400] (omap_hsmmc_set_ios+0x74/0x40c) from [c02a74a8] (m mc_power_off+0x4c/0x54) [ 16.600219] [c02a74a8] (mmc_power_off+0x4c/0x54) from [c02a86a8] (mmc_res can+0x23c/0x268) [ 16.608856] [c02a86a8] (mmc_rescan+0x23c/0x268) from [c006c064] (worker_t hread+0x150/0x1c4) [ 16.617645] [c006c064] (worker_thread+0x150/0x1c4) from [c006f198] (kthre ad+0x78/0x80) [ 16.626007] [c006f198] (kthread+0x78/0x80) from [c00358c0] (kernel_thread _exit+0x0/0x8) [ 16.634429] ---[ end trace 72e9bbcb61162c84 ]--- -- 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] arm: omap1/2/3/4: change sync_32k_ick to ick
Use clkdev and forget about clock names.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
and now make all the clocks with same name
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/plat-omap/clocksource.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d932b14..0115853 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1806,7 +1806,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gpios_fck,gpios_fck, CK_242X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_242X),
CLK(omap_wdt, fck, mpu_wdt_fck, CK_242X),
- CLK(NULL, sync_32k_ick, sync_32k_ick, CK_242X),
+ CLK(omap-clksrc, ick, sync_32k_ick, CK_242X),
CLK(NULL, wdt1_ick, wdt1_ick, CK_242X),
CLK(NULL, omapctrl_ick, omapctrl_ick, CK_242X),
CLK(omap24xxcam, fck, cam_fck, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 0438b6e..d2e1041 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1900,7 +1900,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, gpios_fck,gpios_fck, CK_243X),
CLK(omap_wdt, ick, mpu_wdt_ick, CK_243X),
CLK(omap_wdt, fck, mpu_wdt_fck, CK_243X),
- CLK(NULL, sync_32k_ick, sync_32k_ick, CK_243X),
+ CLK(omap-clksrc, ick, sync_32k_ick, CK_243X),
CLK(NULL, wdt1_ick, wdt1_ick, CK_243X),
CLK(NULL, omapctrl_ick, omapctrl_ick, CK_243X),
CLK(NULL, icr_ick, icr_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d5153b6..6bf0f96 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3414,7 +3414,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_wdt, ick, wdt2_ick, CK_3XXX),
CLK(NULL, wdt1_ick, wdt1_ick, CK_3XXX),
CLK(NULL, gpio1_ick,gpio1_ick, CK_3XXX),
- CLK(NULL, omap_32ksync_ick, omap_32ksync_ick, CK_3XXX),
+ CLK(omap-clksrc, ick, omap_32ksync_ick, CK_3XXX),
CLK(NULL, gpt12_ick,gpt12_ick, CK_3XXX),
CLK(NULL, gpt1_ick, gpt1_ick, CK_3XXX),
CLK(NULL, per_96m_fck, per_96m_fck, CK_3XXX),
diff --git a/arch/arm/plat-omap/clocksource.c b/arch/arm/plat-omap/clocksource.c
index 9a43b0c..13ae8da 100644
--- a/arch/arm/plat-omap/clocksource.c
+++ b/arch/arm/plat-omap/clocksource.c
@@ -139,7 +139,7 @@ static int __init omap_clksrc_probe(struct platform_device
*pdev)
goto err2;
}
- ick = clk_get(pdev-dev, sync_32k_ick);
+ ick = clk_get(pdev-dev, ick);
if (IS_ERR(ick)) {
dev_dbg(pdev-dev, couldn't get clock\n);
ret = PTR_ERR(ick);
--
1.7.0.rc0.33.g7c3932
--
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/5] OMAP: RX51: Add LCD Panel support
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Roger Quadros
Sent: Tuesday, March 23, 2010 3:26 PM
To: t...@atomide.com
Cc: tomi.valkei...@nokia.com; linux-omap@vger.kernel.org;
linux-fb...@vger.kernel.org
Subject: [PATCH 1/5] OMAP: RX51: Add LCD Panel support
From: Roger Quadros roger.quad...@nokia.com
Adds basic support for LCD Panel on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13
arch/arm/mach-omap2/board-rx51-video.c | 95
++
3 files changed, 109 insertions(+), 0 deletions(-) create
mode 100644 arch/arm/mach-omap2/board-rx51-video.c
diff --git a/arch/arm/mach-omap2/Makefile
b/arch/arm/mach-omap2/Makefile index 4b9fc57..b03cbb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_MACH_NOKIA_N8X0)
+= board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
+board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2)+= board-zoom2.o \
board-zoom-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..f404537 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,7 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata; @@ -54,6
+55,11 @@ static struct omap2_mcspi_device_config
wl1251_mcspi_config = {
.single_channel = 1,
};
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
Any specific reason for not enabling turbo mode?
It will increase throughput if it is configured in single channel mode.
+ .single_channel = 1,
+};
+
static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
@@ -64,6 +70,13 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.controller_data= wl1251_mcspi_config,
.platform_data = wl1251_pdata,
},
+ [RX51_SPI_MIPID] = {
+ .modalias = acx565akm,
+ .bus_num= 1,
+ .chip_select= 2,
+ .max_speed_hz = 600,
+ .controller_data= mipid_mcspi_config,
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) ||
defined(CONFIG_KEYBOARD_GPIO_MODULE)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
new file mode 100644
index 000..e3e22a8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -0,0 +1,95 @@
+/*
+ * linux/arch/arm/mach-omap2/board-rx51-peripherals.c
+ *
+ * Copyright (C) 2010 Nokia
+ *
+ * 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.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/spi/spi.h
+
+#include asm/mach-types.h
+#include plat/mux.h
+#include plat/display.h
+#include plat/mcspi.h
+
+#include mux.h
+
+#define RX51_LCD_RESET_GPIO 90
+
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+
+static int rx51_lcd_enable(struct omap_dss_device *dssdev) {
+ gpio_set_value(dssdev-reset_gpio, 1);
+ return 0;
+}
+
+static void rx51_lcd_disable(struct omap_dss_device *dssdev) {
+ gpio_set_value(dssdev-reset_gpio, 0); }
+
+static struct omap_dss_device rx51_lcd_device = {
+ .name = lcd,
+ .driver_name= panel-acx565akm,
+ .type = OMAP_DISPLAY_TYPE_SDI,
+ .phy.sdi.datapairs = 2,
+ .reset_gpio = RX51_LCD_RESET_GPIO,
+ .platform_enable= rx51_lcd_enable,
+ .platform_disable = rx51_lcd_disable,
+};
+
+static struct omap_dss_device *rx51_dss_devices[] = {
+ rx51_lcd_device,
+};
+
+static struct omap_dss_board_info rx51_dss_board_info = {
+ .num_devices= ARRAY_SIZE(rx51_dss_devices),
+ .devices= rx51_dss_devices,
+ .default_device = rx51_lcd_device,
+};
+
+struct platform_device rx51_display_device = {
+ .name =
Re: [PATCH 1/5] OMAP: RX51: Add LCD Panel support
Hi,
ext G, Manjunath Kondaiah wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Roger Quadros
Sent: Tuesday, March 23, 2010 3:26 PM
To: t...@atomide.com
Cc: tomi.valkei...@nokia.com; linux-omap@vger.kernel.org;
linux-fb...@vger.kernel.org
Subject: [PATCH 1/5] OMAP: RX51: Add LCD Panel support
From: Roger Quadros roger.quad...@nokia.com
Adds basic support for LCD Panel on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13
arch/arm/mach-omap2/board-rx51-video.c | 95
++
3 files changed, 109 insertions(+), 0 deletions(-) create
mode 100644 arch/arm/mach-omap2/board-rx51-video.c
diff --git a/arch/arm/mach-omap2/Makefile
b/arch/arm/mach-omap2/Makefile index 4b9fc57..b03cbb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_MACH_NOKIA_N8X0)
+= board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
+ board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..f404537 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,7 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata; @@ -54,6
+55,11 @@ static struct omap2_mcspi_device_config
wl1251_mcspi_config = {
.single_channel = 1,
};
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
Any specific reason for not enabling turbo mode?
It will increase throughput if it is configured in single channel mode.
No specific reason. That was the original configuration, in previous versions of
the code. It shouldn't make much difference as mipid is only used for panel
detection, enable/disable, and backlight control. Need to test if it works with
turbo mode.
+ .single_channel = 1,
+};
+
static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
+static int __init rx51_video_init(void) {
+ if (!machine_is_nokia_rx51())
+ return 0;
+
+ if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
+ pr_err(%s cannot configure MUX for LCD
RESET\n, __func__);
+ return 0;
+ }
+
+ if (gpio_request(RX51_LCD_RESET_GPIO, LCD ACX565AKM reset)) {
+ pr_err(%s failed to get LCD Reset GPIO\n, __func__);
+ return 0;
+ }
+
+ gpio_direction_output(RX51_LCD_RESET_GPIO, 1);
+
+ platform_add_devices(rx51_video_devices,
+ ARRAY_SIZE(rx51_video_devices));
+ return 0;
+}
Since this functional always returns 0, you can make return value of this
function as void.
I guess it is better to return non zero on failure paths then.
thanks.
-roger
--
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/5] OMAP: RX51: Add LCD Panel support
Hi,
ext G, Manjunath Kondaiah wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Roger Quadros
Sent: Tuesday, March 23, 2010 3:26 PM
To: t...@atomide.com
Cc: tomi.valkei...@nokia.com; linux-omap@vger.kernel.org;
linux-fb...@vger.kernel.org
Subject: [PATCH 1/5] OMAP: RX51: Add LCD Panel support
From: Roger Quadros roger.quad...@nokia.com
Adds basic support for LCD Panel on Nokia N900
Signed-off-by: Roger Quadros roger.quad...@nokia.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 13
arch/arm/mach-omap2/board-rx51-video.c | 95
++
3 files changed, 109 insertions(+), 0 deletions(-) create
mode 100644 arch/arm/mach-omap2/board-rx51-video.c
diff --git a/arch/arm/mach-omap2/Makefile
b/arch/arm/mach-omap2/Makefile index 4b9fc57..b03cbb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_MACH_NOKIA_N8X0)
+= board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
board-rx51-peripherals.o \
+ board-rx51-video.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..f404537 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -45,6 +45,7 @@
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_MIPID, /* LCD panel */
};
static struct wl12xx_platform_data wl1251_pdata; @@ -54,6
+55,11 @@ static struct omap2_mcspi_device_config
wl1251_mcspi_config = {
.single_channel = 1,
};
+static struct omap2_mcspi_device_config mipid_mcspi_config = {
+ .turbo_mode = 0,
Any specific reason for not enabling turbo mode?
It will increase throughput if it is configured in single channel mode.
No specific reason. That was the original configuration, in previous versions of
the code. It shouldn't make much difference as mipid is only used for panel
detection, enable/disable, and backlight control. Need to test if it works with
turbo mode.
+ .single_channel = 1,
+};
+
static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = wl1251,
+static int __init rx51_video_init(void) {
+ if (!machine_is_nokia_rx51())
+ return 0;
+
+ if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
+ pr_err(%s cannot configure MUX for LCD
RESET\n, __func__);
+ return 0;
+ }
+
+ if (gpio_request(RX51_LCD_RESET_GPIO, LCD ACX565AKM reset)) {
+ pr_err(%s failed to get LCD Reset GPIO\n, __func__);
+ return 0;
+ }
+
+ gpio_direction_output(RX51_LCD_RESET_GPIO, 1);
+
+ platform_add_devices(rx51_video_devices,
+ ARRAY_SIZE(rx51_video_devices));
+ return 0;
+}
Since this functional always returns 0, you can make return value of this
function as void.
I guess it is better to return non zero on failure paths then.
thanks.
-roger
--
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: Merge plans for Staging Synaptics Touchscreen Driver
Hi Hemanth, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of V, Hemanth Sent: Tuesday, March 23, 2010 4:29 AM To: pa...@ucw.cz; linux-in...@vger.kernel.org Cc: linux-omap@vger.kernel.org Subject: Merge plans for Staging Synaptics Touchscreen Driver Hi All, Are there any plans to merge the synaptics touchscreen driver (drivers/staging/dream/synaptics_i2c_rmi.c) to drivers/input/touchscreen. We are interested in the same since OMAP3 based Zoom boards use this touchscreen. Can you please elaborate on the specific Synaptics touchscreen chip you're attempting to drive? Unless there's only one synaptic chip that exists... Regards, Sergio Pl add (if required) below tested by for the staging driver. Tested-By: Hemanth V heman...@ti.com Thanks Hemanth -- 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 -- 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: Merge plans for Staging Synaptics Touchscreen Driver
Hi Hemanth, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of V, Hemanth Sent: Tuesday, March 23, 2010 4:29 AM To: pa...@ucw.cz; linux-in...@vger.kernel.org Cc: linux-omap@vger.kernel.org Subject: Merge plans for Staging Synaptics Touchscreen Driver Hi All, Are there any plans to merge the synaptics touchscreen driver (drivers/staging/dream/synaptics_i2c_rmi.c) to drivers/input/touchscreen. We are interested in the same since OMAP3 based Zoom boards use this touchscreen. Can you please elaborate on the specific Synaptics touchscreen chip you're attempting to drive? Sergio, The current driver available in staging directory is for Synaptics RMI3 chip 511-99-01F Thanks Hemanth -- 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
[PATCHv3 0/3] Add support for TCA6416 based Keypad driver.
AM3517 EVM with APPS board includes keys interfaced to TCA6416 IO expander User keys are connected as GPIO lines to TCA6416 IO expander. Unlike the case with generic gpio-keypad driver individual keys do not generate an interrupt event. Hence we implement a simple keypad driver, that registers as direct I2C client. The implementation has been tested on AM3517 EVM with the driver tested in polling mode. Version3 is refreshed against the tip of linux-omap and file mode issues from the previous version is fixed. Sriramakrishnan (3): TCA6416 keypad : Implement keypad driver for keys interfaced to TCA6416 AM3517: Board hookup for TCA6416 keypad driver. AM3517 EVM : Enable TCA6416 keypad. arch/arm/configs/am3517_evm_defconfig | 16 ++- arch/arm/mach-omap2/board-am3517evm.c | 47 - drivers/input/keyboard/Kconfig | 16 ++ drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/tca6416-keypad.c | 354 +++ include/linux/tca6416_keypad.h | 34 +++ 6 files changed, 462 insertions(+), 6 deletions(-) create mode 100644 drivers/input/keyboard/tca6416-keypad.c create mode 100644 include/linux/tca6416_keypad.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
[PATCHv3 2/3] AM3517: Board hookup for TCA6416 keypad driver.
Add board specific hookup for TCA6416 keypad driver.
Signed-off-by: Sriramakrishnan s...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 47 +---
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 6ae8805..d50e505 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,7 +20,10 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/gpio.h
+#include linux/i2c.h
#include linux/i2c/pca953x.h
+#include linux/input.h
+#include linux/tca6416_keypad.h
#include mach/hardware.h
#include mach/am35xx.h
@@ -88,16 +91,50 @@ static struct i2c_board_info __initdata
am3517evm_tca6416_info_0[] = {
};
/* Mounted on UI Card */
-static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_1 = {
+/* IO expander at address 0x20 on UI card will be managed by Keypad driver */
+
+static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_2 = {
.gpio_base = OMAP_MAX_GPIO_LINES + 16,
};
-static struct pca953x_platform_data am3517evm_ui_gpio_expander_info_2 = {
- .gpio_base = OMAP_MAX_GPIO_LINES + 32,
+
+/*Keypad Initialization */
+#define KEYPAD_PIN_MASK0xFFC0
+
+#define KEYPAD_BUTTON(ev_type, ev_code, act_low) \
+{ \
+ .type = ev_type, \
+ .code = ev_code, \
+ .active_low = act_low, \
+}
+
+#define KEYPAD_BUTTON_LOW(event_code) \
+ KEYPAD_BUTTON(EV_KEY, event_code, 1)
+
+static struct tca6416_button am3517_gpio_keys[] = {
+ KEYPAD_BUTTON_LOW(KEY_DOWN),
+ KEYPAD_BUTTON_LOW(KEY_UP),
+ KEYPAD_BUTTON_LOW(KEY_MENU),
+ KEYPAD_BUTTON_LOW(KEY_MODE),
+ KEYPAD_BUTTON_LOW(KEY_LEFTSHIFT),
+ KEYPAD_BUTTON_LOW(KEY_REWIND),
+ KEYPAD_BUTTON_LOW(KEY_FORWARD),
+ KEYPAD_BUTTON_LOW(KEY_STOP),
+ KEYPAD_BUTTON_LOW(KEY_PLAY),
+ KEYPAD_BUTTON_LOW(KEY_RECORD),
};
+
+static struct tca6416_keys_platform_data am3517evm_tca6416_keys_info = {
+ .buttons= am3517_gpio_keys,
+ .nbuttons = ARRAY_SIZE(am3517_gpio_keys),
+ .rep= 1,
+ .use_polling= 1,
+ .pinmask= KEYPAD_PIN_MASK,
+};
+
static struct i2c_board_info __initdata am3517evm_ui_tca6416_info[] = {
{
- I2C_BOARD_INFO(tca6416, 0x20),
- .platform_data = am3517evm_ui_gpio_expander_info_1,
+ I2C_BOARD_INFO(tca6416-keys, 0x20),
+ .platform_data = am3517evm_tca6416_keys_info,
},
{
I2C_BOARD_INFO(tca6416, 0x21),
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/3] TCA6416 keypad : Implement keypad driver for keys interfaced to TCA6416
This patch implements a simple Keypad driver that functions
as an I2C client. It handles key press events for keys
connected to TCA6416 I2C based IO expander.
Signed-off-by: Sriramakrishnan s...@ti.com
---
drivers/input/keyboard/Kconfig | 16 ++
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/tca6416-keypad.c | 354 +++
include/linux/tca6416_keypad.h | 34 +++
4 files changed, 405 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/keyboard/tca6416-keypad.c
create mode 100644 include/linux/tca6416_keypad.h
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 64c1023..cf7fca9 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -192,6 +192,22 @@ config KEYBOARD_GPIO
To compile this driver as a module, choose M here: the
module will be called gpio_keys.
+config KEYBOARD_TCA6416
+ tristate TCA6416 Keypad Support
+ depends on I2C
+ help
+ This driver implements basic keypad functionality
+ for keys connected through TCA6416 IO expander
+
+ Say Y here if your device has keys connected to
+ TCA6416 IO expander. Your board-specific setup logic
+ must also provide pin-mask details(of which TCA6416 pins
+ are used for keypad).
+
+ If enabled the complete TCA6416 device will be managed through
+ this driver.
+
+
config KEYBOARD_MATRIX
tristate GPIO driven matrix keypad support
depends on GENERIC_GPIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 706c6b5..47e267c 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_KEYBOARD_CORGI) += corgikbd.o
obj-$(CONFIG_KEYBOARD_DAVINCI) += davinci_keyscan.o
obj-$(CONFIG_KEYBOARD_EP93XX) += ep93xx_keypad.o
obj-$(CONFIG_KEYBOARD_GPIO)+= gpio_keys.o
+obj-$(CONFIG_KEYBOARD_TCA6416) += tca6416-keypad.o
obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
diff --git a/drivers/input/keyboard/tca6416-keypad.c
b/drivers/input/keyboard/tca6416-keypad.c
new file mode 100644
index 000..17df832
--- /dev/null
+++ b/drivers/input/keyboard/tca6416-keypad.c
@@ -0,0 +1,354 @@
+/*
+ * Driver for keys on TCA6416 I2C IO expander
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * Author : Sriramakrishnan.A.G. s...@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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/input.h
+#include linux/tca6416_keypad.h
+#include linux/workqueue.h
+#include linux/types.h
+#include linux/interrupt.h
+#include linux/delay.h
+
+#define TCA6416_INPUT 0
+#define TCA6416_OUTPUT 1
+#define TCA6416_INVERT 2
+#define TCA6416_DIRECTION 3
+
+static const struct i2c_device_id tca6416_id[] = {
+ { tca6416-keys, 16, },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, tca6416_id);
+
+struct tca6416_drv_data {
+ struct input_dev *input;
+ struct tca6416_button data[0];
+};
+
+struct tca6416_keypad_chip {
+ uint16_t reg_output;
+ uint16_t reg_direction;
+ uint16_t reg_input;
+
+ struct i2c_client *client;
+ struct tca6416_drv_data *drv_data;
+ struct delayed_work dwork;
+ uint16_t pinmask;
+ int irqnum;
+ int use_polling;
+};
+
+static int tca6416_write_reg(struct tca6416_keypad_chip *chip, int reg,
+ uint16_t val)
+{
+ int ret;
+
+ ret = i2c_smbus_write_word_data(chip-client, reg 1, val);
+
+ if (ret 0) {
+ dev_err(chip-client-dev, failed writing register\n);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int tca6416_read_reg(struct tca6416_keypad_chip *chip, int reg,
+ uint16_t *val)
+{
+ int ret;
+
+ ret = i2c_smbus_read_word_data(chip-client, reg 1);
+
+ if (ret 0) {
+ dev_err(chip-client-dev, failed reading register\n);
+ return ret;
+ }
+
+ *val = (uint16_t)ret;
+ return 0;
+}
+
+static irqreturn_t tca6416_keys_isr(int irq, void *dev_id)
+{
+ struct tca6416_keypad_chip *chip =
+ (struct tca6416_keypad_chip *) dev_id;
+
+ disable_irq(irq);
+ schedule_delayed_work(chip-dwork, 0);
+ return IRQ_HANDLED;
+
+}
+
+static void tca6416_keys_work_func(struct work_struct *workstruct)
+{
+ struct delayed_work *delay_work =
+ container_of(workstruct, struct delayed_work, work);
+ struct tca6416_keypad_chip *chip
Regarding OMAP3630 Zoom3 Board Clock Speed
Hi, How can read DPLL1 (MPU_CLK) speed related registers in ported TI linux kernel. i am facing in figuting out the values. After going through TRM and given formula (SYS_CLK*2*M)/(N+1)*M2 value is coming as 1200 Mhz having a SYS_CLK of 26 Mhz. but while reading through cat /proc/cpuinfo it is giving 600Mhz. and this is not same and it is giving some wrong oitput as ARM7 core as a processor name althjough it is a ARM11 coretex 8 processor. Did my registers reading code is wrong as 1200Mhz is not possible. Is there any proper way to read the corresponding CPRM MPU registers. Please help us as we are in critical stage. Thanks and regards Abhay Kumar -- 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: Regulator message while booting recent kernel
On Tue, Mar 23, 2010 at 09:34:46AM -0400, Philip Balister wrote: This is from a recent git kernel. Any ideas how I can make it go away? [ 16.525451] unbalanced disables for dummy Turn off REGULATOR_USE_DUMMY - it substitutes in a dummy regulator as a band aid for systems which don't have regulators fully set up, but can lead to confusion with drivers that have non-trivial regulator usage. The MMC driver needs enough control over the regulator to mean that I'm not 100% confused that the dummy driver confuses it, thoguh it may be worth investigating and seeing if it can be improved. -- 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
[ANNOUNCE] dspbridge rebased to 2.6.33
Hi, The rebased branch of dspbridge 2.6.33 kernel was pushed to d-o.z. Please use it for your development. Regards, Omar -- 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] DSPBRIDGE: Remove autoconf.h dependency from host_os header
On 3/18/2010 4:57 PM, Ramirez Luna, Omar wrote: There shouldn't be any dependency on the definitions generated by autoconf.h, besides it is automatically included by the build system. This solves the following warning: In file included from arch/arm/plat-omap/include/dspbridge/host_os.h:20, from arch/arm/mach-omap2/io.c:51: include/linux/autoconf.h:165:1: warning: CONFIG_DEFAULT_IOSCHED redefined In file included fromcommand-line:0: ./include/generated/autoconf.h:172:1: warning: this is the location of the previous definition Signed-off-by: Omar Ramirez Lunaomar.rami...@hotmail.com --- arch/arm/plat-omap/include/dspbridge/host_os.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Pushed to dspbridge. - omar -- 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] DSPBRIDGE: Fix header locations mach to plat
On 3/18/2010 4:57 PM, Ramirez Luna, Omar wrote: Fix header locations, replaced mach to plat Signed-off-by: Omar Ramirez Lunaomar.rami...@ti.com Acked-by: Ameya Palandeameya.pala...@nokia.com --- arch/arm/mach-omap2/dspbridge.c|2 +- arch/arm/plat-omap/include/dspbridge/host_os.h |2 +- drivers/dsp/bridge/wmd/tiomap3430.c|2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Pushed to dspbridge. - omar -- 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] DSPBRIDGE: Change dspbridge for open source mailbox implementation
On 2/12/2010 8:03 PM, Guzman Lugo, Fernando wrote: From 627fb103cb73202128b8c5d2a51c879c52ebf076 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugox0095...@ti.com Date: Fri, 12 Feb 2010 02:26:58 -0600 Subject: [PATCH] DSPBRIDGE: Change dspbridge for open source mailbox implementation This patch removes our dspbridge for opensource mailbox implementation. Signed-off-by: Fernando Guzman Lugox0095...@ti.com --- arch/arm/plat-omap/include/dspbridge/cfgdefs.h |1 - arch/arm/plat-omap/include/dspbridge/clk.h |3 +- arch/arm/plat-omap/include/dspbridge/drv.h |3 - arch/arm/plat-omap/include/dspbridge/host_os.h |2 +- arch/arm/plat-omap/include/dspbridge/io_sm.h |7 +- drivers/dsp/bridge/Makefile|2 +- drivers/dsp/bridge/rmgr/drv.c |9 - drivers/dsp/bridge/services/clk.c |1 - drivers/dsp/bridge/wmd/_tiomap.h |4 +- drivers/dsp/bridge/wmd/chnl_sm.c | 26 +++- drivers/dsp/bridge/wmd/io_sm.c | 196 --- drivers/dsp/bridge/wmd/tiomap3430.c| 49 --- drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 13 +- drivers/dsp/bridge/wmd/tiomap_sm.c | 109 + drivers/dsp/bridge/wmd/ue_deh.c|4 +- 15 files changed, 143 insertions(+), 286 deletions(-) Rebased and pushed to dspbridge. - omar -- 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/3] DSPBRIDGE: Remove hw_mbox.c and hw_mbox.h not needed anymore
On 2/12/2010 8:03 PM, Guzman Lugo, Fernando wrote: From 5451312f78b6631c9cfacfde10928f481e60b65c Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugox0095...@ti.com Date: Wed, 27 Jan 2010 20:12:38 -0600 Subject: [PATCH] DSPBRIDGE: Remove hw_mbox.c and hw_mbox.h not needed anymore Because of mailbox migration now the files hw_mbox.c and hw_mbox.h are not needed anymore. Signed-off-by: Fernando Guzman Lugox0095...@ti.com --- drivers/dsp/bridge/hw/hw_mbox.c | 248 - drivers/dsp/bridge/hw/hw_mbox.h | 326 --- 2 files changed, 0 insertions(+), 574 deletions(-) delete mode 100644 drivers/dsp/bridge/hw/hw_mbox.c delete mode 100644 drivers/dsp/bridge/hw/hw_mbox.h Rebased and pushed, deleted MLBAccInt.h and MLBRegAcM.h too. - omar -- 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] DSPBRIDGE: Remove chnl_sm.h and tiomap_sm.c
On 2/12/2010 8:04 PM, Guzman Lugo, Fernando wrote: From d287e11cdb126f2c9b4be8d6d6f958ffdf7ff716 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugox0095...@ti.com Date: Fri, 22 Jan 2010 21:46:42 -0600 Subject: [PATCH] DSPBRIDGE: Remove chnl_sm.h and tiomap_sm.c Because of mailbox migration all the functions in tiomap_sm.c except one and their prototypes in chnl_sm.h are not needed anymore, so that function was changed to tiomap_io.c and changed the name to remove camelcasing Signed-off-by: Fernando Guzman Lugox0095...@ti.com --- arch/arm/plat-omap/include/dspbridge/chnl_sm.h | 154 drivers/dsp/bridge/Makefile|2 +- drivers/dsp/bridge/wmd/_tiomap.h | 18 +++ drivers/dsp/bridge/wmd/io_sm.c | 13 +- drivers/dsp/bridge/wmd/tiomap3430.c|3 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 13 +- drivers/dsp/bridge/wmd/tiomap_io.c | 71 +++ drivers/dsp/bridge/wmd/tiomap_sm.c | 101 8 files changed, 103 insertions(+), 272 deletions(-) delete mode 100644 arch/arm/plat-omap/include/dspbridge/chnl_sm.h delete mode 100644 drivers/dsp/bridge/wmd/tiomap_sm.c Rebased and pushed to dspbridge. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Mailbox: Fix some issues in mailbox module
On 2/18/2010 1:06 AM, Guzman Lugo, Fernando wrote: From 79f2b477b19c49b36c51e8589c0a3d52ecd9ec99 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugox0095...@ti.com Date: Thu, 18 Feb 2010 01:06:34 -0600 Subject: [PATCH] Mailbox: Fix some issues in mailbox module This set of patches fix some issue I found when I was working with mailbox module. Fernando Guzman Lugo (4): Mailbox: free mailbox interrupt before freeing blk queue Mailbox: flush pending deferred works before freeing blk queue Mailbox: Check valid registered callback before calling Mailbox: disable mailbox interrupt when request queue Hiroshi DOYU (1): Mailbox: new mutext lock for h/w mailbox configuration arch/arm/plat-omap/mailbox.c | 29 - 1 files changed, 20 insertions(+), 9 deletions(-) Cherry-picked until 2.6.34 rebase is available. Pushed to dspbridge. - omar -- 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: Save/Restore (PM) support in DSS2
Hiremath, Vaibhav hvaib...@ti.com writes:
Hi Tomi and others,
As part of our internal release I found that save and restore support doesn't
work as expected (I have fixed it for our release and full PM support works
fine for me), and below is my analysis/observation and fix for the same -
Observation -
---
The save and restore of DSS registers happen inside function dss_clk_enable
and dss_clk_disable. The save context gets executed as per expectation when
actually required, i.e. when clock usage count goes to 0.
The issue is with restore functionality, the restore is blocked by various
conditions -
void dss_clk_enable(enum dss_clock clks)
{
bool check_ctx = core.num_clks_enabled == 0;
dss_clk_enable_no_ctx(clks);
if (check_ctx cpu_is_omap34xx() dss_need_ctx_restore())
restore_all_ctx();
}
The check for clock usage count is mandatory here (which was missing earlier)
but I am more concerned about other of two, cpu_is_omap34xx()
dss_need_ctx_restore().
Why this is tied only to omap34xx? And
Frankly I am quite not sure whether I understood use of
dss_need_ctx_restore()? What are we trying to do here with function
dss_need_ctx_restore()? It internally calls dss_get_ctx_id() which internally
calls pdata-get_last_off_on_transaction_id().
Are we providing control to platform file when to restore? If yes, then what
could be the trigger for that decision?
Currently none of OMAP board files defines this function, so it is always
going to return 0. That means, without this function (and returns true)
restore won't happen at all.
If I understand correctly, irrespective of which platform you are running on
and whether you are hitting off/idle/retention state or not, you must save
and restore states when your module interface clock usage count goes to zero.
I may be missing something here.
You only need restore if the powerdomain has gone to off mode (or
OSWR, which is not yet in l-o.) For retention or inactive, no context
save/restore is needed.
That pdata pointer was intended to hook up to the OMAP PM layer
funciton of the same name, which uses the has the smarts to determine
if context was actually lost.
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
[dspbridge] news: omap mailbox implementation
Hi All, When updating the custom dspbridge mailbox functions with the ones avaliable through omap mailbox (by pulling latest dspbridge), PLEASE remember to enable omap mailbox through menuconfig: make menuconfig System Type --- TI OMAP Implementations --- * Mailbox framework support otherwise, compilation will break like: Building modules, stage 2. MODPOST 7 modules ERROR: omap_mbox_msg_send [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_put [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_get [drivers/dsp/bridge/bridgedriver.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [modules] Error 2 Regards, Omar -- 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: [dspbridge] news: omap mailbox implementation
Hi Omar, On Tue, 2010-03-23 at 19:08 +0100, ext Omar Ramirez Luna wrote: Hi All, When updating the custom dspbridge mailbox functions with the ones avaliable through omap mailbox (by pulling latest dspbridge), PLEASE remember to enable omap mailbox through menuconfig: make menuconfig System Type --- TI OMAP Implementations --- * Mailbox framework support otherwise, compilation will break like: Building modules, stage 2. MODPOST 7 modules ERROR: omap_mbox_msg_send [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_put [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_get [drivers/dsp/bridge/bridgedriver.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [modules] Error 2 Can't we make DSP Bridge driver depend on mailbox then? Cheers, Ameya. -- 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 v3] arm: omap1/2/3/4: convert clocksource to a platform_driver
Felipe Balbi felipe.ba...@nokia.com writes: Convert the omap32k clocksource driver into a platform_driver and while at that, also remove the ifdeferry around the code. Signed-off-by: Felipe Balbi felipe.ba...@nokia.com Looks like a good direction, but it still is rather tied to the 32k sync timer. We also have the ability to use a GPtimer as a clocksource (see the clocksource register in timer-gp.c.) By default, we are always using the 32k timer for PM reasons, but we need the ability to register any timer as clocksource. This problably means just splitting a little more the driver part and the device part. Also, the new clocksource.c file should reference from whence it came. A lot of that was copy/pasted from the older code so copyrights/author credits should follow. 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: [dspbridge] news: omap mailbox implementation
On 3/23/2010 12:54 PM, Ameya Palande wrote: Hi Omar, On Tue, 2010-03-23 at 19:08 +0100, ext Omar Ramirez Luna wrote: Hi All, When updating the custom dspbridge mailbox functions with the ones avaliable through omap mailbox (by pulling latest dspbridge), PLEASE remember to enable omap mailbox through menuconfig: make menuconfig System Type --- TI OMAP Implementations --- * Mailbox framework support otherwise, compilation will break like: Building modules, stage 2. MODPOST 7 modules ERROR: omap_mbox_msg_send [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_put [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_get [drivers/dsp/bridge/bridgedriver.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [modules] Error 2 Can't we make DSP Bridge driver depend on mailbox then? Yes we can, but I thought that new-to-bridge people who want to compile a kernel and are impatient enough to read a wiki (updating as we speak), would freak out if DSP Bridge is not shown in menuconfig because it is dependent on mailbox ;). Also thought that a note in Bridge defconfig option might be enough This driver depends on OMAP Mailbox (OMAP_MBOX_FWK)., rather than a hard dependency. The other option was to update the defconfig. I'm fine with any of those or if anyone has a better suggestion. Regards, Omar -- 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: [dspbridge] news: omap mailbox implementation
On 3/23/2010 1:29 PM, Omar Ramirez Luna wrote: On 3/23/2010 12:54 PM, Ameya Palande wrote: Hi Omar, On Tue, 2010-03-23 at 19:08 +0100, ext Omar Ramirez Luna wrote: Hi All, When updating the custom dspbridge mailbox functions with the ones avaliable through omap mailbox (by pulling latest dspbridge), PLEASE remember to enable omap mailbox through menuconfig: make menuconfig System Type --- TI OMAP Implementations --- * Mailbox framework support otherwise, compilation will break like: Building modules, stage 2. MODPOST 7 modules ERROR: omap_mbox_msg_send [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_put [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_get [drivers/dsp/bridge/bridgedriver.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [modules] Error 2 Can't we make DSP Bridge driver depend on mailbox then? Yes we can, but I thought that new-to-bridge people who want to compile a kernel and are impatient enough to read a wiki (updating as we speak), would freak out if DSP Bridge is not shown in menuconfig because it is dependent on mailbox ;). Also thought that a note in Bridge defconfig option might be enough This driver depends on OMAP Mailbox (OMAP_MBOX_FWK)., rather than a hard dependency. The other option was to update the defconfig. I'm fine with any of those or if anyone has a better suggestion. By the way a third one would be to auto select mailbox when selecting bridgedriver, but if module is selected this means that a second module hast to be installed prior to bridgedriver. - omar -- 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: [dspbridge] news: omap mailbox implementation
On Tue, 2010-03-23 at 19:29 +0100, ext Omar Ramirez Luna wrote: On 3/23/2010 12:54 PM, Ameya Palande wrote: Hi Omar, On Tue, 2010-03-23 at 19:08 +0100, ext Omar Ramirez Luna wrote: Hi All, When updating the custom dspbridge mailbox functions with the ones avaliable through omap mailbox (by pulling latest dspbridge), PLEASE remember to enable omap mailbox through menuconfig: make menuconfig System Type --- TI OMAP Implementations --- * Mailbox framework support otherwise, compilation will break like: Building modules, stage 2. MODPOST 7 modules ERROR: omap_mbox_msg_send [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_put [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_get [drivers/dsp/bridge/bridgedriver.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [modules] Error 2 Can't we make DSP Bridge driver depend on mailbox then? Yes we can, but I thought that new-to-bridge people who want to compile a kernel and are impatient enough to read a wiki (updating as we speak), would freak out if DSP Bridge is not shown in menuconfig because it is dependent on mailbox ;). Also thought that a note in Bridge defconfig option might be enough This driver depends on OMAP Mailbox (OMAP_MBOX_FWK)., rather than a hard dependency. I would go for hard dependency since otherwise we can't compile dspbridge module :( IMO selecting dspbridge module should automatically select mailbox module as well and same should apply for modprobe also :) Cheers, Ameya. -- 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: [dspbridge] news: omap mailbox implementation
On 3/23/2010 1:31 PM, Ameya Palande wrote: On Tue, 2010-03-23 at 19:29 +0100, ext Omar Ramirez Luna wrote: On 3/23/2010 12:54 PM, Ameya Palande wrote: Hi Omar, On Tue, 2010-03-23 at 19:08 +0100, ext Omar Ramirez Luna wrote: Hi All, When updating the custom dspbridge mailbox functions with the ones avaliable through omap mailbox (by pulling latest dspbridge), PLEASE remember to enable omap mailbox through menuconfig: make menuconfig System Type --- TI OMAP Implementations --- * Mailbox framework support otherwise, compilation will break like: Building modules, stage 2. MODPOST 7 modules ERROR: omap_mbox_msg_send [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_put [drivers/dsp/bridge/bridgedriver.ko] undefined! ERROR: omap_mbox_get [drivers/dsp/bridge/bridgedriver.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [modules] Error 2 Can't we make DSP Bridge driver depend on mailbox then? Yes we can, but I thought that new-to-bridge people who want to compile a kernel and are impatient enough to read a wiki (updating as we speak), would freak out if DSP Bridge is not shown in menuconfig because it is dependent on mailbox ;). Also thought that a note in Bridge defconfig option might be enough This driver depends on OMAP Mailbox (OMAP_MBOX_FWK)., rather than a hard dependency. I would go for hard dependency since otherwise we can't compile dspbridge module :( IMO selecting dspbridge module should automatically select mailbox module as well and same should apply for modprobe also :) Agree to auto select then, will send a patch to modify Kconfig. - omar -- 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] DSPBRIDGE: DSP recovery feature
I have tested just using an application (base on bridged code) which is registered for fatal events and once it receives an event it prints the received event: status = DSPManager_WaitForEvents(notifier, EVENTS, index, DSP_FOREVER); printf(Event received %s\n, evt_name[index]); print event received try_err_out(Catch notification signal, status); And this is what I get: #Load baseimage with absolute path, so that kernel thread can load #baseimage # ./cexec.out /dspbridge_reco/ddspbase_tiomap3430.dof64P #Run listener.out # ./listener.out # DspManager_Open succeeded DSPProcessor_Attach succeeded DSP node register notify DSP_MMUFAULT succeeded DSP node register notify DSP_SYSERROR succeeded DSP node register notify DSP_PWRERROR succeeded DSP node register notify DSP_StateChange succeeded # #Cause MMUFault. # ./faultapp.out ddspbase_tiomap3430.dof64P test DSP device detected !! DSPProcessor_Attach succeeded. DSPNode_Allocate succeeded. DSPNode_Create succeeded. DSPNod* DSPMMU FAULT * IRQStatus 0x2 MMUFault caused e_Run succeeded. DSPProcessor_R* DSPMMU FAULT * fault_addr 0x8000 eserveMemory succeeded. dspAddrSbridge_deh_notify: ** DEVICE EXCEPTION * * end= 0x203f DSPProcessor_Rbridge_deh_notify: DSP_MMUFAULT,err_info = 0x0 eserveMemory succeeded. dspAddrdbridge_deh_notify: DSP_MMUFAULT, High Address = 0x8000 Recv= 0x2040a000 DSPProcessor_bridge_deh_notify: DSP_MMUFAULT, Low Address = 0x0 Map succeeded. DSPProcessor_Mapbridge_deh_notify: DSP_MMUFAULT, fault address = 0x8000 succeeded. Sending DMM BUFs toprint_dsp_trace_buffer: DSP MMU FAULT currtask:0x20061114 DSP cmd=SETUP, DspRecvBuf=0x2b2DSPTrace: DSP MMU FAULT currtask:0x20061114 f0, DspSendBuf=0x122e8 Read 102400 bytes from input file. Event received MMU_FAULTMMUFault detected by the application (notification was really received) Catch notification signal succeeded ^Ckill faultapp.out it is stuck by doing Ctrl + C # proc_load: Processor Loaded /dspbridge_reco/ddspbase_tiomap3430.dof64P baseimage was reloaded successfully proc_start: dsp in running state DspManager_Open succeeded DSPProcessor_Attach succeeded DSP node register notify DSP_MMUFAULT succeeded DSP node register notify DSP_SYSERROR succeeded DSP node register notify DSP_PWRERROR succeeded DSP node register notify DSP_StateChange succeeded # #Run dmmcopy.out sample to make sure DSP was recovered successfully # ./dmmcopy.out ddspbase_tiomap3430.dof64P test DSP device detected !! DSPProcessor_Attach succeeded. DSPNode_Allocate succeeded. DSPNode_Create succeeded. DSPNode_Run succeeded. DSPProcessor_ReserveMemory succeeded. dspAddrSend= 0x203f DSPProcessor_ReserveMemory succeeded. dspAddrdRecv= 0x2040a000 DSPProcessor_Map succeeded. DSPProcessor_Map succeeded. Sending DMM BUFs to DSP cmd=SETUP, DspRecvBuf=0x203f02e8, DspSendBuf=0x2040a2f0 Read 102400 bytes from input file. Writing 102400 bytes to output file. Read 33684 bytes from input file. Writing 33684 bytes to output file. DSPProcessor_UnMap succeeded. DSPProcessor_UnMap succeeded. DSPProcessor_UnReserveMemory succeeded. DSPProcessor_UnReserveMemory succeeded. RunTask succeeded. DSPNode_Terminate succeeded.procwrap_detach: deprecated dspbridge ioctl DSPNode_Delete succeeded. DSPProcessor_Detach succeeded. # You can use the application attached to see if you are able to receive notifications, if you still don't receives the notifications can you share the code you are using? Regards, Fernando. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Guzman Lugo, Fernando Sent: Friday, March 19, 2010 4:31 PM To: Felipe Contreras Cc: Hebbar, Shivananda; linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; felipe.contre...@nokia.com Subject: RE: [PATCH 2/2] DSPBRIDGE: DSP recovery feature -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Friday, March 19, 2010 4:11 PM To: Guzman Lugo, Fernando Cc: Hebbar, Shivananda; linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; felipe.contre...@nokia.com Subject: Re: [PATCH 2/2] DSPBRIDGE: DSP recovery feature On Fri, Mar 19, 2010 at 11:49 PM, Guzman Lugo, Fernando x0095...@ti.com wrote: Do you mean applying DSP recovery process you are no able to receive MMUFault notifications? I am going to check that case. Is there any possibility that the process is stuck waiting other event? I think mgr_wait_for_bridge_events is constantly failing, so no MMUFAULT notifications come through. Ok, I am going to see if the patch is changing something related to that function and debug the problem. Regards, Fernando. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [PM-WIP-OPP][PATCH 3/4] omap: pm: opp: add ability to store data per opp
Cousson, Benoit had written, on 03/23/2010 11:12 AM, the following:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Tuesday, March 23, 2010 2:00 PM
Gopinath, Thara had written, on 03/23/2010 12:06 AM, the following:
[...] [I am not about to repeat everything I stated in previous
threads.. so snipping the discussion down.]
Otherwise the primary idea to remove OPP ID is good, and the way to go.
good. So lets NAK that SR series and see how else we can implement it
without OPP ID. I am open to any clean mechanisms you may propose
without using OPP ID referencing :).
Ok guys.. In the current V2 series , I have linked N targets with
voltage..
Only it does not come from voltage layer but from smartreflex devices
layer.
The smartreflex driver does not use opp ids at all.. Also whether you
call
it by opp ids or by any other name, we need to know the number of
different
voltages supported by VDD1 and VDD2 and form the table.. That is exactly
what I am doing in smartreflex device layer. I am just creating a
table with
different voltages and N target values associated with those voltages.
To create this table I need to know there should be 5 voltages for VDD1
and 3 voltages for VDD2 which unfortunately coincides with the number of
different OPP's defined in OMAP3430 today..
SR patches should ideally be discussed in SR patch series context
anyways, since we are looking at the fundamentals of OPP:
3430: VDD1: 5 voltages+frequencies, VDD2: 3 voltages and frequencies
3630: VDD1: 4 voltages+frequencies, VDD2: 2 voltages and frequencies
are there cases where the number of discrete voltage != number of
supported frequencies?
If you'd like to support DPLL bypass or several frequencies for thermal
management purpose it can happen. And believe me; it will happen soon, at least
on OMAP4.
Agreed that for a voltage the characteristic data is unique. but since a
voltage is tied to a frequency, does'nt it make sense to tie it to an
OPP (my initial point in the first place)?
Frequency is an IP characteristic, not a voltage one, hence the need to
separate them.
[..]
Sigh.. quickly becoming an SR thread, but what the heck..
Trying to brainstorm here: Can we consider an inverse relationship? As
in: For a given voltage to a voltage rail, there exists a supported
range of frequencies for specific IP modules? does'nt this make sense? I
mean for a given voltage to the module, there is only so much range of
frequencies you can do on the module that sinks that voltage?
In the case of OMAP3, then we will have a 1-1 relation ship, on OMAP4,
you'd potentially have 1-many relationship..
If this is the representation, then storing that information will still
make sense.
The v2 patches implement a logic as follows:
sr_device.c: arch_initcall:
omap34xx_sr_volt_details
this currently stores voltages (essentially replicates OPP layer
information from cpufreq34xx.c other than using OPP indices). The NAK
for this approach is still valid from maintainence and redundancy
perspective.
What other alternatives do we have?
Here is what I can imagine from the few mins I spend thinking about it
(just my 2 cents):
int omap_voltage_notify(omap_device *volt_dev, struct omap_voltage_data
*new, struct omap_voltage_data *old, enum voltage_notify_type);
enum voltage_notify_type {
VOLTAGE_PRE
VOLTAGE_ACTIVATE
VOLTAGE_POST
VOLTAGE_PAUSE
VOLTAGE_RESUME
}
or split them up into 4/5 functions..
I will not need to store SRID or any similar stuff inside various files
NOR will i have to replicate another OPP layer in SR/vc codebase.
volt_device will contain platform_data similar to what
omap_smartreflex_data has today + additional register baseaddress and
offset information. it will not contain sr_nvalue, nor sr_volt_data
struct omap_sr_volt_data will be omap_voltage_data be similar to what we
provide today.
The caller has the responsibility of providing the correct voltage_data
to the voltage subsystem.
So for today (resource34xx.c or pm34xx.c which ever is triggering the
chage) the caller will provide the trigger to the voltage layer- for
OMAP3, store the voltage_data against each OPP. For OMAP4 and elsewhere
the data could be somewhere else (hwmod itself perhaps if it triggers
the transitions eventually?). It seems to scale to me + all those hacks
such as get_curr_vdd[12]_voltage() in the current voltage.c can be avoided.
--
Regards,
Nishanth Menon
--
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 00/10] dsp-bridge: deh: general cleanups
Hi, While trying to fix the recovery feature I stumbled many areas of improvments in 'deh' (whatever that means). I quickly tested tesed these changes in Nokia hw, there should be essentially no functional changes. Cheers. Felipe Contreras (10): dsp-bridge: deh: remove obvious comments dsp-bridge: deh: trivial cleanups dsp-bridge: deh: remove unnecessary casts dsp-bridge: deh: improve logging stuff dsp-bridge: deh: report mmu faults as errors dsp-bridge: deh: decrease nesting levels dsp-bridge: deh: fix obvious return codes dsp-bridge: deh: reorganize create() dsp-bridge: deh: fix hdeh_mgr silliness dsp-bridge: deh: fix dummy_va_addr arch/arm/plat-omap/include/dspbridge/wmddeh.h | 24 +- drivers/dsp/bridge/wmd/ue_deh.c | 392 +++-- 2 files changed, 191 insertions(+), 225 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] dsp-bridge: deh: remove obvious comments
They are weirdly formatted and don't provide any useful information.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/wmd/ue_deh.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 5edcce9..8d44180 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -60,10 +60,7 @@ static struct hw_mmu_map_attrs_t map_attrs = {
HW_LITTLE_ENDIAN,
#define VIRT_TO_PHYS(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
static u32 dummy_va_addr;
-/*
- * bridge_deh_create
- * Creates DEH manager object.
- */
+
dsp_status bridge_deh_create(OUT struct deh_mgr **phDehMgr,
struct dev_object *hdev_obj)
{
@@ -126,10 +123,6 @@ dsp_status bridge_deh_create(OUT struct deh_mgr **phDehMgr,
return status;
}
-/*
- * bridge_deh_destroy
- * Destroys DEH manager object.
- */
dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr)
{
dsp_status status = DSP_SOK;
@@ -154,10 +147,6 @@ dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr)
return status;
}
-/*
- * bridge_deh_register_notify
- * Registers for DEH notifications.
- */
dsp_status bridge_deh_register_notify(struct deh_mgr *hdeh_mgr, u32 event_mask,
u32 notify_type,
struct dsp_notification *hnotification)
@@ -173,10 +162,6 @@ dsp_status bridge_deh_register_notify(struct deh_mgr
*hdeh_mgr, u32 event_mask,
return status;
}
-/*
- * bridge_deh_notify
- * DEH error notification function. Informs user about the error.
- */
void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32 ulEventMask, u32
dwErrInfo)
{
struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)hdeh_mgr;
@@ -290,10 +275,6 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32
ulEventMask, u32 dwErrInfo)
}
}
-/*
- * bridge_deh_get_info
- * Retrieves error information.
- */
dsp_status bridge_deh_get_info(struct deh_mgr *hdeh_mgr,
struct dsp_errorinfo *pErrInfo)
{
@@ -317,10 +298,6 @@ dsp_status bridge_deh_get_info(struct deh_mgr *hdeh_mgr,
return status;
}
-/*
- * bridge_deh_release_dummy_mem
- * Releases memory allocated for dummy page
- */
void bridge_deh_release_dummy_mem(void)
{
kfree((void *)dummy_va_addr);
--
1.7.0.3
--
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 02/10] dsp-bridge: deh: trivial cleanups
Mostly white-space formatting.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/wmddeh.h | 16 ++--
drivers/dsp/bridge/wmd/ue_deh.c | 111 +---
2 files changed, 68 insertions(+), 59 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
index 0152c43..e193029 100644
--- a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
+++ b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
@@ -27,22 +27,22 @@
#include dspbridge/dehdefs.h
-extern dsp_status bridge_deh_create(OUT struct deh_mgr **phDehMgr,
- struct dev_object *hdev_obj);
+extern dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
+ struct dev_object *hdev_obj);
extern dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr);
extern dsp_status bridge_deh_get_info(struct deh_mgr *hdeh_mgr,
- struct dsp_errorinfo *pErrInfo);
+ struct dsp_errorinfo *pErrInfo);
extern dsp_status bridge_deh_register_notify(struct deh_mgr *hdeh_mgr,
- u32 event_mask,
- u32 notify_type,
- struct dsp_notification
- *hnotification);
+ u32 event_mask,
+ u32 notify_type,
+ struct dsp_notification *hnotification);
extern void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
- u32 ulEventMask, u32 dwErrInfo);
+ u32 ulEventMask, u32 dwErrInfo);
extern void bridge_deh_release_dummy_mem(void);
+
#endif /* WMDDEH_ */
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 8d44180..284f378 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -52,7 +52,8 @@
#include _tiomap_pwr.h
#include dspbridge/io_sm.h
-static struct hw_mmu_map_attrs_t map_attrs = { HW_LITTLE_ENDIAN,
+static struct hw_mmu_map_attrs_t map_attrs = {
+ HW_LITTLE_ENDIAN,
HW_ELEM_SIZE16BIT,
HW_MMU_CPUES
};
@@ -61,8 +62,8 @@ static struct hw_mmu_map_attrs_t map_attrs = {
HW_LITTLE_ENDIAN,
static u32 dummy_va_addr;
-dsp_status bridge_deh_create(OUT struct deh_mgr **phDehMgr,
-struct dev_object *hdev_obj)
+dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
+ struct dev_object *hdev_obj)
{
dsp_status status = DSP_SOK;
struct deh_mgr *deh_mgr_obj = NULL;
@@ -70,9 +71,12 @@ dsp_status bridge_deh_create(OUT struct deh_mgr **phDehMgr,
struct cfg_devnode *dev_node_obj;
struct wmd_dev_context *hwmd_context = NULL;
- /* Message manager will be created when a file is loaded, since
-* size of message buffer in shared memory is configurable in
-* the base image. */
+ /*
+* Message manager will be created when a file is loaded, since size
+* of message buffer in shared memory is configurable in the base
+* image.
+*/
+
/* Get WMD context info. */
dev_get_wmd_context(hdev_obj, hwmd_context);
DBC_ASSERT(hwmd_context);
@@ -87,14 +91,14 @@ dsp_status bridge_deh_create(OUT struct deh_mgr **phDehMgr,
/* Create a MMUfault DPC */
tasklet_init(deh_mgr_obj-dpc_tasklet, mmu_fault_dpc,
-(u32) deh_mgr_obj);
+ (u32) deh_mgr_obj);
if (DSP_SUCCEEDED(status))
status = dev_get_dev_node(hdev_obj, dev_node_obj);
if (DSP_SUCCEEDED(status))
status =
- cfg_get_host_resources(dev_node_obj, cfg_host_res);
+ cfg_get_host_resources(dev_node_obj,
cfg_host_res);
if (DSP_SUCCEEDED(status)) {
/* Fill in context structure */
@@ -105,8 +109,8 @@ dsp_status bridge_deh_create(OUT struct deh_mgr **phDehMgr,
deh_mgr_obj-err_info.dw_val3 = 0L;
/* Install ISR function for DSP MMU fault */
if ((request_irq(INT_DSP_MMU_IRQ, mmu_fault_isr, 0,
-DspBridge\tiommu fault,
-(void *)deh_mgr_obj)) == 0)
+ DspBridge\tiommu
fault,
+ (void *)deh_mgr_obj))
== 0)
status = DSP_SOK;
else
status = DSP_EFAIL;
@@ -148,15 +152,15 @@ dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr)
}
dsp_status bridge_deh_register_notify(struct deh_mgr *hdeh_mgr, u32 event_mask,
- u32 notify_type,
-
[PATCH 03/10] dsp-bridge: deh: remove unnecessary casts
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/dsp/bridge/wmd/ue_deh.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c index 284f378..fae036f 100644 --- a/drivers/dsp/bridge/wmd/ue_deh.c +++ b/drivers/dsp/bridge/wmd/ue_deh.c @@ -137,7 +137,7 @@ dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr) bridge_deh_release_dummy_mem(); /* If notification object exists, delete it */ if (deh_mgr_obj-ntfy_obj) - (void)ntfy_delete(deh_mgr_obj-ntfy_obj); + ntfy_delete(deh_mgr_obj-ntfy_obj); /* Disable DSP MMU fault */ free_irq(INT_DSP_MMU_IRQ, deh_mgr_obj); @@ -275,7 +275,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32 ulEventMask, u32 dwErrInfo) /* Set the Board state as ERROR */ dev_context-dw_brd_state = BRD_ERROR; /* Disable all the clocks that were enabled by DSP */ - (void)dsp_peripheral_clocks_disable(dev_context, NULL); + dsp_peripheral_clocks_disable(dev_context, NULL); /* Call DSP Trace Buffer */ print_dsp_trace_buffer(hdeh_mgr-hwmd_context); -- 1.7.0.3 -- 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] dsp-bridge: deh: improve logging stuff
Get rid of printk, use dev_foo, and prettify the output.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/wmd/ue_deh.c | 33 -
1 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index fae036f..0c29442 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -182,9 +182,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32
ulEventMask, u32 dwErrInfo)
resources);
if (MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) {
- printk(KERN_INFO
- bridge_deh_notify: ** DEVICE EXCEPTION
- **\n);
+ dev_info(bridge, %s: device exception\n, __func__);
dev_context =
(struct wmd_dev_context *)deh_mgr_obj-hwmd_context;
@@ -196,9 +194,8 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32
ulEventMask, u32 dwErrInfo)
deh_mgr_obj-err_info.dw_val2 = 0L;
deh_mgr_obj-err_info.dw_val3 = 0L;
deh_mgr_obj-err_info.dw_val1 = dwErrInfo;
- printk(KERN_ERR
- bridge_deh_notify: DSP_SYSERROR,
err_info
- = 0x%x\n, dwErrInfo);
+ dev_err(bridge, %s: %s, err_info = 0x%x\n,
+ __func__, DSP_SYSERROR, dwErrInfo);
break;
case DSP_MMUFAULT:
/*
@@ -206,18 +203,13 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32
ulEventMask, u32 dwErrInfo)
* structure.
*/
deh_mgr_obj-err_info.dw_err_mask = DSP_MMUFAULT;
- printk(KERN_INFO bridge_deh_notify: DSP_MMUFAULT,
- err_info = 0x%x\n, dwErrInfo);
- printk(KERN_INFO
- bridge_deh_notify: DSP_MMUFAULT, High
- Address = 0x%x\n,
- (unsigned
int)deh_mgr_obj-err_info.dw_val1);
- printk(KERN_INFO bridge_deh_notify: DSP_MMUFAULT, Low
- Address = 0x%x\n,
- (unsigned
int)deh_mgr_obj-err_info.dw_val2);
- printk(KERN_INFO
- bridge_deh_notify: DSP_MMUFAULT, fault
- address = 0x%x\n, (unsigned
int)fault_addr);
+ dev_info(bridge, %s: %s, err_info = 0x%x\n,
+ __func__, DSP_MMUFAULT, dwErrInfo);
+ dev_info(bridge, %s: %s, high=0x%x, low=0x%x,
fault=0x%x\n,
+ __func__, DSP_MMUFAULT,
+ (unsigned int)
deh_mgr-err_info.dw_val1,
+ (unsigned int)
deh_mgr-err_info.dw_val2,
+ (unsigned int) fault_addr);
dummy_va_addr =
(u32) mem_calloc(sizeof(char) * 0x1000,
MEM_PAGED);
mem_physical =
@@ -257,9 +249,8 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32
ulEventMask, u32 dwErrInfo)
deh_mgr_obj-err_info.dw_val2 = 0L;
deh_mgr_obj-err_info.dw_val3 = 0L;
deh_mgr_obj-err_info.dw_val1 = dwErrInfo;
- printk(KERN_ERR
- bridge_deh_notify: DSP_PWRERROR,
err_info
- = 0x%x\n, dwErrInfo);
+ dev_err(bridge, %s: %s, err_info = 0x%x\n,
+ __func__, DSP_PWRERROR, dwErrInfo);
break;
#endif /* CONFIG_BRIDGE_NTFY_PWRERR */
default:
--
1.7.0.3
--
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 05/10] dsp-bridge: deh: report mmu faults as errors
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/dsp/bridge/wmd/ue_deh.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c index 0c29442..4708c10 100644 --- a/drivers/dsp/bridge/wmd/ue_deh.c +++ b/drivers/dsp/bridge/wmd/ue_deh.c @@ -203,7 +203,7 @@ void bridge_deh_notify(struct deh_mgr *hdeh_mgr, u32 ulEventMask, u32 dwErrInfo) * structure. */ deh_mgr_obj-err_info.dw_err_mask = DSP_MMUFAULT; - dev_info(bridge, %s: %s, err_info = 0x%x\n, + dev_err(bridge, %s: %s, err_info = 0x%x\n, __func__, DSP_MMUFAULT, dwErrInfo); dev_info(bridge, %s: %s, high=0x%x, low=0x%x, fault=0x%x\n, __func__, DSP_MMUFAULT, -- 1.7.0.3 -- 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] dsp-bridge: deh: decrease nesting levels
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/wmd/ue_deh.c | 293 +++
1 files changed, 145 insertions(+), 148 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 4708c10..0a03e09 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -85,37 +85,44 @@ dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
MEM_ALLOC_OBJECT(deh_mgr_obj, struct deh_mgr, SIGNATURE);
if (deh_mgr_obj == NULL) {
status = DSP_EMEMORY;
- } else {
- /* Create an NTFY object to manage notifications */
- status = ntfy_create(deh_mgr_obj-ntfy_obj);
+ goto leave;
+ }
- /* Create a MMUfault DPC */
- tasklet_init(deh_mgr_obj-dpc_tasklet, mmu_fault_dpc,
- (u32) deh_mgr_obj);
+ /* Create an NTFY object to manage notifications */
+ status = ntfy_create(deh_mgr_obj-ntfy_obj);
- if (DSP_SUCCEEDED(status))
- status = dev_get_dev_node(hdev_obj, dev_node_obj);
+ /* Create a MMUfault DPC */
+ tasklet_init(deh_mgr_obj-dpc_tasklet, mmu_fault_dpc,
+ (u32) deh_mgr_obj);
- if (DSP_SUCCEEDED(status))
- status =
- cfg_get_host_resources(dev_node_obj,
cfg_host_res);
+ if (DSP_FAILED(status))
+ goto leave;
- if (DSP_SUCCEEDED(status)) {
- /* Fill in context structure */
- deh_mgr_obj-hwmd_context = hwmd_context;
- deh_mgr_obj-err_info.dw_err_mask = 0L;
- deh_mgr_obj-err_info.dw_val1 = 0L;
- deh_mgr_obj-err_info.dw_val2 = 0L;
- deh_mgr_obj-err_info.dw_val3 = 0L;
- /* Install ISR function for DSP MMU fault */
- if ((request_irq(INT_DSP_MMU_IRQ, mmu_fault_isr, 0,
- DspBridge\tiommu
fault,
- (void *)deh_mgr_obj))
== 0)
- status = DSP_SOK;
- else
- status = DSP_EFAIL;
- }
- }
+ status = dev_get_dev_node(hdev_obj, dev_node_obj);
+
+ if (DSP_FAILED(status))
+ goto leave;
+
+ status = cfg_get_host_resources(dev_node_obj, cfg_host_res);
+
+ if (DSP_FAILED(status))
+ goto leave;
+
+ /* Fill in context structure */
+ deh_mgr_obj-hwmd_context = hwmd_context;
+ deh_mgr_obj-err_info.dw_err_mask = 0L;
+ deh_mgr_obj-err_info.dw_val1 = 0L;
+ deh_mgr_obj-err_info.dw_val2 = 0L;
+ deh_mgr_obj-err_info.dw_val3 = 0L;
+ /* Install ISR function for DSP MMU fault */
+ if ((request_irq(INT_DSP_MMU_IRQ, mmu_fault_isr, 0,
+ DspBridge\tiommu fault,
+ (void *)deh_mgr_obj)) == 0)
+ status = DSP_SOK;
+ else
+ status = DSP_EFAIL;
+
+leave:
if (DSP_FAILED(status)) {
/* If create failed, cleanup */
bridge_deh_destroy((struct deh_mgr *)deh_mgr_obj);
@@ -129,41 +136,39 @@ dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr)
{
- dsp_status status = DSP_SOK;
struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)hdeh_mgr;
- if (MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) {
- /* Release dummy VA buffer */
- bridge_deh_release_dummy_mem();
- /* If notification object exists, delete it */
- if (deh_mgr_obj-ntfy_obj)
- ntfy_delete(deh_mgr_obj-ntfy_obj);
- /* Disable DSP MMU fault */
- free_irq(INT_DSP_MMU_IRQ, deh_mgr_obj);
+ if (!MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE))
+ return DSP_SOK;
- /* Free DPC object */
- tasklet_kill(deh_mgr_obj-dpc_tasklet);
+ /* Release dummy VA buffer */
+ bridge_deh_release_dummy_mem();
+ /* If notification object exists, delete it */
+ if (deh_mgr_obj-ntfy_obj)
+ ntfy_delete(deh_mgr_obj-ntfy_obj);
+ /* Disable DSP MMU fault */
+ free_irq(INT_DSP_MMU_IRQ, deh_mgr_obj);
- /* Deallocate the DEH manager object */
- MEM_FREE_OBJECT(deh_mgr_obj);
- }
+ /* Free DPC object */
+ tasklet_kill(deh_mgr_obj-dpc_tasklet);
- return status;
+ /* Deallocate the DEH manager object */
+ MEM_FREE_OBJECT(deh_mgr_obj);
+
+ return DSP_SOK;
}
dsp_status bridge_deh_register_notify(struct deh_mgr
[PATCH 07/10] dsp-bridge: deh: fix obvious return codes
Now that the code is cleaner is easy to spot them. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/dsp/bridge/wmd/ue_deh.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c index 0a03e09..1add675 100644 --- a/drivers/dsp/bridge/wmd/ue_deh.c +++ b/drivers/dsp/bridge/wmd/ue_deh.c @@ -139,7 +139,7 @@ dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr) struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)hdeh_mgr; if (!MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) - return DSP_SOK; + return DSP_EHANDLE; /* Release dummy VA buffer */ bridge_deh_release_dummy_mem(); @@ -165,7 +165,7 @@ dsp_status bridge_deh_register_notify(struct deh_mgr *hdeh_mgr, u32 event_mask, struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)hdeh_mgr; if (!MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE)) - return DSP_SOK; + return DSP_EHANDLE; return ntfy_register(deh_mgr_obj-ntfy_obj, hnotification, event_mask, notify_type); -- 1.7.0.3 -- 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 08/10] dsp-bridge: deh: reorganize create()
No functional changes.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/wmddeh.h |2 +-
drivers/dsp/bridge/wmd/ue_deh.c | 22 --
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
index e193029..d7b7ee9 100644
--- a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
+++ b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
@@ -27,7 +27,7 @@
#include dspbridge/dehdefs.h
-extern dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
+extern dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
struct dev_object *hdev_obj);
extern dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr);
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 1add675..104ab33 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -62,11 +62,11 @@ static struct hw_mmu_map_attrs_t map_attrs = {
static u32 dummy_va_addr;
-dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
+dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
struct dev_object *hdev_obj)
{
dsp_status status = DSP_SOK;
- struct deh_mgr *deh_mgr_obj = NULL;
+ struct deh_mgr *deh_mgr_obj;
struct cfg_hostres cfg_host_res;
struct cfg_devnode *dev_node_obj;
struct wmd_dev_context *hwmd_context = NULL;
@@ -83,7 +83,7 @@ dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
dummy_va_addr = 0;
/* Allocate IO manager object: */
MEM_ALLOC_OBJECT(deh_mgr_obj, struct deh_mgr, SIGNATURE);
- if (deh_mgr_obj == NULL) {
+ if (!deh_mgr_obj) {
status = DSP_EMEMORY;
goto leave;
}
@@ -96,17 +96,17 @@ dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
(u32) deh_mgr_obj);
if (DSP_FAILED(status))
- goto leave;
+ goto err;
status = dev_get_dev_node(hdev_obj, dev_node_obj);
if (DSP_FAILED(status))
- goto leave;
+ goto err;
status = cfg_get_host_resources(dev_node_obj, cfg_host_res);
if (DSP_FAILED(status))
- goto leave;
+ goto err;
/* Fill in context structure */
deh_mgr_obj-hwmd_context = hwmd_context;
@@ -114,6 +114,7 @@ dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
deh_mgr_obj-err_info.dw_val1 = 0L;
deh_mgr_obj-err_info.dw_val2 = 0L;
deh_mgr_obj-err_info.dw_val3 = 0L;
+
/* Install ISR function for DSP MMU fault */
if ((request_irq(INT_DSP_MMU_IRQ, mmu_fault_isr, 0,
DspBridge\tiommu fault,
@@ -122,15 +123,16 @@ dsp_status bridge_deh_create(struct deh_mgr **phDehMgr,
else
status = DSP_EFAIL;
-leave:
+err:
if (DSP_FAILED(status)) {
/* If create failed, cleanup */
bridge_deh_destroy((struct deh_mgr *)deh_mgr_obj);
- *phDehMgr = NULL;
- } else {
- *phDehMgr = (struct deh_mgr *)deh_mgr_obj;
+ deh_mgr_obj = NULL;
}
+leave:
+ *ret_deh_mgr = deh_mgr_obj;
+
return status;
}
--
1.7.0.3
--
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 09/10] dsp-bridge: deh: fix hdeh_mgr silliness
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
arch/arm/plat-omap/include/dspbridge/wmddeh.h |8 +-
drivers/dsp/bridge/wmd/ue_deh.c | 104 +++-
2 files changed, 52 insertions(+), 60 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
index d7b7ee9..67beb08 100644
--- a/arch/arm/plat-omap/include/dspbridge/wmddeh.h
+++ b/arch/arm/plat-omap/include/dspbridge/wmddeh.h
@@ -30,17 +30,17 @@
extern dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
struct dev_object *hdev_obj);
-extern dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr);
+extern dsp_status bridge_deh_destroy(struct deh_mgr *deh_mgr);
-extern dsp_status bridge_deh_get_info(struct deh_mgr *hdeh_mgr,
+extern dsp_status bridge_deh_get_info(struct deh_mgr *deh_mgr,
struct dsp_errorinfo *pErrInfo);
-extern dsp_status bridge_deh_register_notify(struct deh_mgr *hdeh_mgr,
+extern dsp_status bridge_deh_register_notify(struct deh_mgr *deh_mgr,
u32 event_mask,
u32 notify_type,
struct dsp_notification *hnotification);
-extern void bridge_deh_notify(struct deh_mgr *hdeh_mgr,
+extern void bridge_deh_notify(struct deh_mgr *deh_mgr,
u32 ulEventMask, u32 dwErrInfo);
extern void bridge_deh_release_dummy_mem(void);
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index 104ab33..b1c3189 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -66,7 +66,7 @@ dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
struct dev_object *hdev_obj)
{
dsp_status status = DSP_SOK;
- struct deh_mgr *deh_mgr_obj;
+ struct deh_mgr *deh_mgr;
struct cfg_hostres cfg_host_res;
struct cfg_devnode *dev_node_obj;
struct wmd_dev_context *hwmd_context = NULL;
@@ -82,18 +82,17 @@ dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
DBC_ASSERT(hwmd_context);
dummy_va_addr = 0;
/* Allocate IO manager object: */
- MEM_ALLOC_OBJECT(deh_mgr_obj, struct deh_mgr, SIGNATURE);
- if (!deh_mgr_obj) {
+ MEM_ALLOC_OBJECT(deh_mgr, struct deh_mgr, SIGNATURE);
+ if (!deh_mgr) {
status = DSP_EMEMORY;
goto leave;
}
/* Create an NTFY object to manage notifications */
- status = ntfy_create(deh_mgr_obj-ntfy_obj);
+ status = ntfy_create(deh_mgr-ntfy_obj);
/* Create a MMUfault DPC */
- tasklet_init(deh_mgr_obj-dpc_tasklet, mmu_fault_dpc,
- (u32) deh_mgr_obj);
+ tasklet_init(deh_mgr-dpc_tasklet, mmu_fault_dpc, (u32) deh_mgr);
if (DSP_FAILED(status))
goto err;
@@ -109,16 +108,16 @@ dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
goto err;
/* Fill in context structure */
- deh_mgr_obj-hwmd_context = hwmd_context;
- deh_mgr_obj-err_info.dw_err_mask = 0L;
- deh_mgr_obj-err_info.dw_val1 = 0L;
- deh_mgr_obj-err_info.dw_val2 = 0L;
- deh_mgr_obj-err_info.dw_val3 = 0L;
+ deh_mgr-hwmd_context = hwmd_context;
+ deh_mgr-err_info.dw_err_mask = 0L;
+ deh_mgr-err_info.dw_val1 = 0L;
+ deh_mgr-err_info.dw_val2 = 0L;
+ deh_mgr-err_info.dw_val3 = 0L;
/* Install ISR function for DSP MMU fault */
if ((request_irq(INT_DSP_MMU_IRQ, mmu_fault_isr, 0,
DspBridge\tiommu fault,
- (void *)deh_mgr_obj)) == 0)
+ (void *)deh_mgr)) == 0)
status = DSP_SOK;
else
status = DSP_EFAIL;
@@ -126,56 +125,51 @@ dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
err:
if (DSP_FAILED(status)) {
/* If create failed, cleanup */
- bridge_deh_destroy((struct deh_mgr *)deh_mgr_obj);
- deh_mgr_obj = NULL;
+ bridge_deh_destroy(deh_mgr);
+ deh_mgr = NULL;
}
leave:
- *ret_deh_mgr = deh_mgr_obj;
+ *ret_deh_mgr = deh_mgr;
return status;
}
-dsp_status bridge_deh_destroy(struct deh_mgr *hdeh_mgr)
+dsp_status bridge_deh_destroy(struct deh_mgr *deh_mgr)
{
- struct deh_mgr *deh_mgr_obj = (struct deh_mgr *)hdeh_mgr;
-
- if (!MEM_IS_VALID_HANDLE(deh_mgr_obj, SIGNATURE))
+ if (!MEM_IS_VALID_HANDLE(deh_mgr, SIGNATURE))
return DSP_EHANDLE;
/* Release dummy VA buffer */
bridge_deh_release_dummy_mem();
/* If notification object exists, delete it */
- if (deh_mgr_obj-ntfy_obj)
- ntfy_delete(deh_mgr_obj-ntfy_obj);
+ if (deh_mgr-ntfy_obj)
+ ntfy_delete(deh_mgr-ntfy_obj);
/* Disable DSP MMU fault */
- free_irq(INT_DSP_MMU_IRQ,
[PATCH 10/10] dsp-bridge: deh: fix dummy_va_addr
It's supposed to be virtual, so u32 doesn't make sense.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
drivers/dsp/bridge/wmd/ue_deh.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/ue_deh.c b/drivers/dsp/bridge/wmd/ue_deh.c
index b1c3189..018905e 100644
--- a/drivers/dsp/bridge/wmd/ue_deh.c
+++ b/drivers/dsp/bridge/wmd/ue_deh.c
@@ -52,15 +52,15 @@
#include _tiomap_pwr.h
#include dspbridge/io_sm.h
+#define ALIGN_DOWN(x,a) ((x)(~((a)-1)))
+
static struct hw_mmu_map_attrs_t map_attrs = {
HW_LITTLE_ENDIAN,
HW_ELEM_SIZE16BIT,
HW_MMU_CPUES
};
-#define VIRT_TO_PHYS(x) ((x) - PAGE_OFFSET + PHYS_OFFSET)
-
-static u32 dummy_va_addr;
+static void *dummy_va_addr;
dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
struct dev_object *hdev_obj)
@@ -80,7 +80,7 @@ dsp_status bridge_deh_create(struct deh_mgr **ret_deh_mgr,
/* Get WMD context info. */
dev_get_wmd_context(hdev_obj, hwmd_context);
DBC_ASSERT(hwmd_context);
- dummy_va_addr = 0;
+ dummy_va_addr = NULL;
/* Allocate IO manager object: */
MEM_ALLOC_OBJECT(deh_mgr, struct deh_mgr, SIGNATURE);
if (!deh_mgr) {
@@ -210,13 +210,11 @@ void bridge_deh_notify(struct deh_mgr *deh_mgr, u32
ulEventMask, u32 dwErrInfo)
(unsigned int) deh_mgr-err_info.dw_val1,
(unsigned int) deh_mgr-err_info.dw_val2,
(unsigned int) fault_addr);
- dummy_va_addr =
- (u32) mem_calloc(sizeof(char) * 0x1000, MEM_PAGED);
- mem_physical =
- VIRT_TO_PHYS(PG_ALIGN_LOW
- ((u32) dummy_va_addr, PG_SIZE4K));
+ dummy_va_addr = mem_calloc(0x1000, MEM_PAGED);
+ mem_physical = ALIGN_DOWN(virt_to_phys(dummy_va_addr),
PAGE_SIZE);
dev_context = (struct wmd_dev_context *)
deh_mgr-hwmd_context;
+
/*
* Reset the dynamic mmu index to fixed count if it exceeds
* 31. So that the dynmmuindex is always between the range of
@@ -291,6 +289,6 @@ dsp_status bridge_deh_get_info(struct deh_mgr *deh_mgr,
void bridge_deh_release_dummy_mem(void)
{
- kfree((void *)dummy_va_addr);
- dummy_va_addr = 0;
+ kfree(dummy_va_addr);
+ dummy_va_addr = NULL;
}
--
1.7.0.3
--
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] DSPBRIDGE: Fix obvious wrong comment formats in mbox migration
Fix obvious wrong comment formats in mbox migration.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/wmd/_tiomap.h|2 +-
drivers/dsp/bridge/wmd/tiomap3430.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/_tiomap.h b/drivers/dsp/bridge/wmd/_tiomap.h
index e853777..71ef731 100644
--- a/drivers/dsp/bridge/wmd/_tiomap.h
+++ b/drivers/dsp/bridge/wmd/_tiomap.h
@@ -326,7 +326,7 @@ struct wmd_dev_context {
u32 dw_dsp_start_add; /* API Boot vector */
u32 dw_internal_size; /* Internal memory size */
- struct omap_mbox *mbox; /* Mail box handle*/
+ struct omap_mbox *mbox; /* Mail box handle */
/*
* Processor specific info is set when prog loaded and read from DCD.
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index d90518a..a972ea2 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -663,7 +663,7 @@ static dsp_status bridge_brd_start(struct wmd_dev_context
*hDevContext,
ul_dsp_clk_addr, sizeof(u32), 0);
}
/*
-*Enable Mailbox events and also drain any pending
+* Enable Mailbox events and also drain any pending
* stale messages.
*/
dev_context-mbox = omap_mbox_get(dsp);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] DSPBRIDGE: auto select mailbox when compiling bridge
Auto select mailbox when compiling bridgedriver. If selected as module, first install: arch/arm/plat-omap/mailbox.ko arch/arm/mach-omap2/mailbox_mach.ko Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/dsp/bridge/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dsp/bridge/Kconfig b/drivers/dsp/bridge/Kconfig index c721f40..a3251c3 100644 --- a/drivers/dsp/bridge/Kconfig +++ b/drivers/dsp/bridge/Kconfig @@ -5,6 +5,7 @@ menuconfig MPU_BRIDGE tristate DSP Bridge driver default n + select OMAP_MBOX_FWK help DSP/BIOS Bridge is designed for platforms that contain a GPP and one or more attached DSPs. The GPP is considered the master or -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] dspbridge: minor mbox cleanups
Fix obvious coding style issues not seen during review. And now bridge driver will auto select mailbox driver. Omar Ramirez Luna (3): DSPBRIDGE: fix checkpatch error introduced with mailbox patches DSPBRIDGE: Fix obvious wrong comment formats in mbox migration DSPBRIDGE: auto select mailbox when compiling bridge drivers/dsp/bridge/Kconfig |1 + drivers/dsp/bridge/wmd/_tiomap.h|4 ++-- drivers/dsp/bridge/wmd/tiomap3430.c |2 +- 3 files changed, 4 insertions(+), 3 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 1/3] DSPBRIDGE: fix checkpatch error introduced with mailbox patches
This fixes: ERROR: foo* bar should be foo *bar 218: FILE: drivers/dsp/bridge/wmd/_tiomap.h:374: +dsp_status sm_interrupt_dsp(struct wmd_dev_context* dev_context, u16 mb_val); Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com --- drivers/dsp/bridge/wmd/_tiomap.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/wmd/_tiomap.h b/drivers/dsp/bridge/wmd/_tiomap.h index 7a884f4..e853777 100644 --- a/drivers/dsp/bridge/wmd/_tiomap.h +++ b/drivers/dsp/bridge/wmd/_tiomap.h @@ -371,6 +371,6 @@ extern dsp_status wmd_tlb_dsp_va_to_mpu_pa(struct wmd_dev_context *dev_context, * Requires: * Ensures: */ -dsp_status sm_interrupt_dsp(struct wmd_dev_context* dev_context, u16 mb_val); +dsp_status sm_interrupt_dsp(struct wmd_dev_context *dev_context, u16 mb_val); #endif /* _TIOMAP_ */ -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3)
Tony Lindgren had written, on 03/23/2010 10:27 AM, the following: [...] Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... I have seen this on few platforms and seem to be related to eMMC usage. Any ideas if that's fixed somewhere also? Madhu, any comments? -- Regards, Nishanth Menon -- 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 02/10] dsp-bridge: deh: trivial cleanups
On 3/23/2010 4:25 PM, Felipe Contreras wrote: Mostly white-space formatting. Most of this white space changes were made because of rules defined when executing Lindent, if there is an agreement that this Lindent changes are bringing more trouble I think we should roll them back instead of manually fixing all of them. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] DSPBRIDGE: Simplify and optimize sync module
From 16f7a1a33d7f76ea3e2962421fea8d5b5f15e4e1 Mon Sep 17 00:00:00 2001 From: Fernando Guzman Lugo x0095...@ti.com Date: Tue, 23 Mar 2010 20:04:33 -0600 Subject: [PATCH] DSPBRIDGE: Simplify and optimize sync module This set of patches simplifies and optimizes the sync module. Fernando Guzman Lugo (4): DSPBRIDGE: replace sync_enter/leave_cs with mutexts or spinlocks DSPBRIDGE: replace sync_enter/leave_cs for tasklets with spin_lock_bh DSPBRIDGE: modify sync event functions to use completions instead of sems DSPBRIDGE: cleanup to sync module arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |4 +- arch/arm/plat-omap/include/dspbridge/chnlpriv.h |4 - arch/arm/plat-omap/include/dspbridge/sync.h | 327 - drivers/dsp/bridge/pmgr/cmm.c | 30 +- drivers/dsp/bridge/pmgr/dmm.c | 47 +-- drivers/dsp/bridge/rmgr/node.c | 281 ++ drivers/dsp/bridge/rmgr/proc.c | 16 +- drivers/dsp/bridge/rmgr/strm.c | 14 +- drivers/dsp/bridge/services/ntfy.c | 50 ++-- drivers/dsp/bridge/services/services.c |9 +- drivers/dsp/bridge/services/sync.c | 465 +++ drivers/dsp/bridge/wmd/_msg_sm.h|2 +- drivers/dsp/bridge/wmd/chnl_sm.c| 42 +- drivers/dsp/bridge/wmd/io_sm.c |4 - drivers/dsp/bridge/wmd/msg_sm.c | 88 +++-- drivers/dsp/bridge/wmd/tiomap3430.c | 22 +- 16 files changed, 398 insertions(+), 1007 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 1/4] DSPBRIDGE: replace sync_enter/leave_cs with mutexts or spinlocks
From 0691223bb8e78186a1651c810f0e5c4e966c38bf Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Fri, 19 Mar 2010 13:42:19 -0600
Subject: [PATCH] DSPBRIDGE: replace sync_enter/leave_cs with mutexts or
spinlocks
This patch replaces sync_enter/leave_cs functions used before as
mutext with mutex_lock/unlock functions or with spin_lock/unlock in case of
small CS or removes them in case of they are not needed.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/pmgr/cmm.c | 30 ++--
drivers/dsp/bridge/pmgr/dmm.c | 47 +++
drivers/dsp/bridge/rmgr/node.c | 269 +++
drivers/dsp/bridge/rmgr/proc.c | 16 +--
drivers/dsp/bridge/rmgr/strm.c | 10 +--
drivers/dsp/bridge/wmd/io_sm.c |4 -
drivers/dsp/bridge/wmd/tiomap3430.c | 22 +--
7 files changed, 160 insertions(+), 238 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/cmm.c b/drivers/dsp/bridge/pmgr/cmm.c
index 798f601..7523361 100644
--- a/drivers/dsp/bridge/pmgr/cmm.c
+++ b/drivers/dsp/bridge/pmgr/cmm.c
@@ -108,7 +108,7 @@ struct cmm_object {
/*
* Cmm Lock is used to serialize access mem manager for multi-threads.
*/
- struct sync_csobject *cmm_lock; /* Lock to access cmm mgr */
+ struct mutex cmm_lock; /* Lock to access cmm mgr */
struct lst_list *node_free_list_head; /* Free list of memory nodes */
u32 ul_min_block_size; /* Min SM block; default 16 bytes */
u32 dw_page_size; /* Memory Page size (1k/4k) */
@@ -202,7 +202,7 @@ void *cmm_calloc_buf(struct cmm_object *hcmm_mgr, u32 usize,
((usize - 1) ~(cmm_mgr_obj-ul_min_block_size -
1))
+ cmm_mgr_obj-ul_min_block_size;
- sync_enter_cs(cmm_mgr_obj-cmm_lock);
+ mutex_lock(cmm_mgr_obj-cmm_lock);
pnode = get_free_block(allocator, usize);
}
if (pnode) {
@@ -240,7 +240,7 @@ void *cmm_calloc_buf(struct cmm_object *hcmm_mgr, u32 usize,
*pp_buf_va = (void *)pnode-dw_va;
}
}
- sync_leave_cs(cmm_mgr_obj-cmm_lock);
+ mutex_unlock(cmm_mgr_obj-cmm_lock);
}
return buf_pa;
}
@@ -296,7 +296,7 @@ dsp_status cmm_create(OUT struct cmm_object **ph_cmm_mgr,
node_free_list_head-head);
}
if (DSP_SUCCEEDED(status))
- status = sync_initialize_cs(cmm_obj-cmm_lock);
+ mutex_init(cmm_obj-cmm_lock);
if (DSP_SUCCEEDED(status))
*ph_cmm_mgr = cmm_obj;
@@ -327,7 +327,7 @@ dsp_status cmm_destroy(struct cmm_object *hcmm_mgr, bool
bForce)
status = DSP_EHANDLE;
return status;
}
- sync_enter_cs(cmm_mgr_obj-cmm_lock);
+ mutex_lock(cmm_mgr_obj-cmm_lock);
/* If not force then fail if outstanding allocations exist */
if (!bForce) {
/* Check for outstanding memory allocations */
@@ -360,10 +360,10 @@ dsp_status cmm_destroy(struct cmm_object *hcmm_mgr, bool
bForce)
/* delete NodeFreeList list */
kfree(cmm_mgr_obj-node_free_list_head);
}
- sync_leave_cs(cmm_mgr_obj-cmm_lock);
+ mutex_unlock(cmm_mgr_obj-cmm_lock);
if (DSP_SUCCEEDED(status)) {
/* delete CS cmm mgr object */
- sync_delete_cs(cmm_mgr_obj-cmm_lock);
+ mutex_destroy(cmm_mgr_obj-cmm_lock);
MEM_FREE_OBJECT(cmm_mgr_obj);
}
return status;
@@ -411,7 +411,7 @@ dsp_status cmm_free_buf(struct cmm_object *hcmm_mgr, void
*buf_pa,
/* get the allocator for this segment id */
allocator = get_allocator(cmm_mgr_obj, ul_seg_id);
if (allocator != NULL) {
- sync_enter_cs(cmm_mgr_obj-cmm_lock);
+ mutex_lock(cmm_mgr_obj-cmm_lock);
mnode_obj =
(struct cmm_mnode *)lst_first(allocator-in_use_list_head);
while (mnode_obj) {
@@ -429,7 +429,7 @@ dsp_status cmm_free_buf(struct cmm_object *hcmm_mgr, void
*buf_pa,
lst_next(allocator-in_use_list_head,
(struct list_head *)mnode_obj);
}
- sync_leave_cs(cmm_mgr_obj-cmm_lock);
+ mutex_unlock(cmm_mgr_obj-cmm_lock);
}
return status;
}
@@ -478,7 +478,7 @@ dsp_status cmm_get_info(struct cmm_object *hcmm_mgr,
status = DSP_EHANDLE;
return status;
}
- sync_enter_cs(cmm_mgr_obj-cmm_lock);
+ mutex_lock(cmm_mgr_obj-cmm_lock);
cmm_info_obj-ul_num_gppsm_segs = 0;/* # of SM segments */
/* Total # of
[PATCH 2/4] DSPBRIDGE: replace sync_enter/leave_cs for tasklets with spin_lock_bh
From cae4f92de97038b442e06d4d33ba4d36d0754c7b Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Fri, 19 Mar 2010 14:04:28 -0600
Subject: [PATCH] DSPBRIDGE: replace sync_enter/leave_cs for tasklets with
spin_lock_bh
This patch replaces sync_enter/leave_cs function calls used in
tasklets with spin_lock/unlock_bh functions.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |2 +-
drivers/dsp/bridge/services/ntfy.c | 34 +---
drivers/dsp/bridge/wmd/_msg_sm.h|2 +-
drivers/dsp/bridge/wmd/chnl_sm.c| 25 ++
drivers/dsp/bridge/wmd/msg_sm.c | 39 ++-
5 files changed, 45 insertions(+), 57 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
index 3c6f891..d961578 100644
--- a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
@@ -116,7 +116,7 @@ struct chnl_mgr {
u32 dw_output_mask; /* Host output channels w/ full buffers */
u32 dw_last_output; /* Last output channel fired from DPC */
/* Critical section object handle */
- struct sync_csobject *hcs_obj;
+ spinlock_t chnl_mgr_lock;
u32 word_size; /* Size in bytes of DSP word */
u32 max_channels; /* Total number of channels */
u32 open_channels; /* Total number of open channels */
diff --git a/drivers/dsp/bridge/services/ntfy.c
b/drivers/dsp/bridge/services/ntfy.c
index 6eb222f..de7ee0c 100644
--- a/drivers/dsp/bridge/services/ntfy.c
+++ b/drivers/dsp/bridge/services/ntfy.c
@@ -44,7 +44,7 @@
struct ntfy_object {
u32 dw_signature; /* For object validation */
struct lst_list *notify_list; /* List of notifier objects */
- struct sync_csobject *sync_obj; /* For critical sections */
+ spinlock_t ntfy_lock; /* For critical sections */
};
/*
@@ -84,20 +84,18 @@ dsp_status ntfy_create(struct ntfy_object **phNtfy)
MEM_ALLOC_OBJECT(notify_obj, struct ntfy_object, NTFY_SIGNATURE);
if (notify_obj) {
+ spin_lock_init(notify_obj-ntfy_lock);
- status = sync_initialize_dpccs(notify_obj-sync_obj);
- if (DSP_SUCCEEDED(status)) {
- notify_obj-notify_list =
- mem_calloc(sizeof(struct lst_list), MEM_NONPAGED);
- if (notify_obj-notify_list == NULL) {
- (void)sync_delete_cs(notify_obj-sync_obj);
- MEM_FREE_OBJECT(notify_obj);
- status = DSP_EMEMORY;
- } else {
- INIT_LIST_HEAD(notify_obj-notify_list-head);
- *phNtfy = notify_obj;
- }
+ notify_obj-notify_list = mem_calloc(sizeof(struct lst_list),
+ MEM_NONPAGED);
+ if (!notify_obj-notify_list) {
+ MEM_FREE_OBJECT(notify_obj);
+ status = DSP_EMEMORY;
+ } else {
+ INIT_LIST_HEAD(notify_obj-notify_list-head);
+ *phNtfy = notify_obj;
}
+
} else {
status = DSP_EMEMORY;
}
@@ -129,8 +127,6 @@ void ntfy_delete(struct ntfy_object *ntfy_obj)
DBC_ASSERT(LST_IS_EMPTY(ntfy_obj-notify_list));
kfree(ntfy_obj-notify_list);
}
- if (ntfy_obj-sync_obj)
- (void)sync_delete_cs(ntfy_obj-sync_obj);
MEM_FREE_OBJECT(ntfy_obj);
}
@@ -173,7 +169,7 @@ void ntfy_notify(struct ntfy_object *ntfy_obj, u32
event_mask)
* event_mask events.
*/
- (void)sync_enter_cs(ntfy_obj-sync_obj);
+ spin_lock_bh(ntfy_obj-ntfy_lock);
notifier_obj = (struct notifier *)lst_first(ntfy_obj-notify_list);
while (notifier_obj != NULL) {
@@ -189,7 +185,7 @@ void ntfy_notify(struct ntfy_object *ntfy_obj, u32
event_mask)
notifier_obj);
}
- (void)sync_leave_cs(ntfy_obj-sync_obj);
+ spin_unlock_bh(ntfy_obj-ntfy_lock);
}
/*
@@ -223,7 +219,7 @@ dsp_status ntfy_register(struct ntfy_object *ntfy_obj,
if (DSP_FAILED(status))
return status;
- (void)sync_enter_cs(ntfy_obj-sync_obj);
+ spin_lock_bh(ntfy_obj-ntfy_lock);
notifier_obj = (struct notifier *)lst_first(ntfy_obj-notify_list);
while (notifier_obj != NULL) {
@@ -281,7 +277,7 @@ dsp_status ntfy_register(struct ntfy_object *ntfy_obj,
notifier_obj-event_mask = event_mask;
}
}
- (void)sync_leave_cs(ntfy_obj-sync_obj);
+
[PATCH 3/4] DSPBRIDGE: modify sync event functions to use completions instead of sems
From fe3614b420203e22e4e30125ccdef05c8786f595 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Tue, 23 Mar 2010 19:59:38 -0600
Subject: [PATCH] DSPBRIDGE: modify sync event functions to use completions
instead of sems
This functions modifies sync event functions to use completions
instead of semaphores and also simplifies the code.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/sync.h | 201 +++--
drivers/dsp/bridge/rmgr/node.c | 12 +-
drivers/dsp/bridge/rmgr/strm.c |4 +-
drivers/dsp/bridge/services/ntfy.c | 16 +-
drivers/dsp/bridge/services/sync.c | 259 +++
drivers/dsp/bridge/wmd/chnl_sm.c| 17 +-
drivers/dsp/bridge/wmd/msg_sm.c | 51 --
7 files changed, 195 insertions(+), 365 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/sync.h
b/arch/arm/plat-omap/include/dspbridge/sync.h
index 6b46e2f..c3c68e1 100644
--- a/arch/arm/plat-omap/include/dspbridge/sync.h
+++ b/arch/arm/plat-omap/include/dspbridge/sync.h
@@ -19,6 +19,7 @@
#ifndef _SYNC_H
#define _SYNC_H
+#include dspbridge/errbase.h
#define SIGNATURECS 0x53435953 /* SYCS (in reverse) */
#define SIGNATUREDPCCS 0x53445953 /* SYDS (in reverse) */
@@ -28,8 +29,16 @@
/* Maximum string length of a named event */
#define SYNC_MAXNAMELENGTH 32
-/* Generic SYNC object: */
-struct sync_object;
+/**
+ * struct sync_object - the basic sync_object structure
+ * @comp: use to signal events
+ * @multi_comp:use to signal multiple events.
+ *
+ */
+struct sync_object{
+ struct completion comp;
+ struct completion *multi_comp;
+};
/* Generic SYNC CS object: */
struct sync_csobject {
@@ -46,25 +55,6 @@ struct sync_attrs {
};
/*
- * sync_close_event
- * Purpose:
- * Close this event handle, freeing resources allocated in sync_open_event
- * if necessary.
- * Parameters:
- * event_obj: Handle to a synchronization event, created/opened in
- * sync_open_event.
- * Returns:
- * DSP_SOK:Success;
- * DSP_EFAIL: Failed to close event handle.
- * DSP_EHANDLE:Invalid handle.
- * Requires:
- * SYNC initialized.
- * Ensures:
- * Any subsequent usage of event_obj would be invalid.
- */
-extern dsp_status sync_close_event(IN struct sync_object *event_obj);
-
-/*
* sync_delete_cs
* Purpose:
* Delete a critical section.
@@ -162,39 +152,18 @@ extern dsp_status sync_initialize_dpccs(OUT struct
sync_csobject
*/
extern dsp_status sync_leave_cs(IN struct sync_csobject *hcs_obj);
-/*
- * sync_open_event
- * Purpose:
- * Create/open and initialize an event object for thread synchronization,
- * which is initially in the non-signalled state.
- * Parameters:
- * ph_event:Pointer to location to receive the event object handle.
- * pattrs: Pointer to sync_attrs object containing initial SYNC
- * sync_object attributes. If this pointer is NULL, then
- * sync_open_event will create and manage an OS specific
- * syncronization object.
- * pattrs-user_event: Platform's User Mode synchronization object.
- *
- * The behaviour of the SYNC methods depend on the value of
- * the user_event attr:
+/**
+ * sync_init_event() - set initial state for a sync_event element
+ * @event: event to be initialized.
*
- * 1. (user_event == NULL):
- * A user mode event is created.
- * 2. (user_event != NULL):
- * A user mode event is supplied by the caller of sync_open_event().
- * Returns:
- * DSP_SOK:Success.
- * DSP_EFAIL: Unable to create user mode event.
- * DSP_EMEMORY:Insufficient memory.
- * DSP_EINVALIDARG sync_attrs values are invalid.
- * Requires:
- * - SYNC initialized.
- * - ph_event != NULL.
- * Ensures:
- * If function succeeded, event-event_obj must be a valid event handle.
+ * Set the initial state for a sync_event element.
*/
-extern dsp_status sync_open_event(OUT struct sync_object **ph_event,
- IN OPTIONAL struct sync_attrs *pattrs);
+
+static inline void sync_init_event(struct sync_object *event)
+{
+ init_completion(event-comp);
+ event-multi_comp = NULL;
+}
/*
* = sync_post_message
@@ -213,91 +182,61 @@ extern dsp_status sync_open_event(OUT struct sync_object
**ph_event,
*/
extern dsp_status sync_post_message(IN bhandle hWindow, IN u32 uMsg);
-/*
- * sync_reset_event
- * Purpose:
- * Reset a syncronization event object state to non-signalled.
- * Parameters:
- * event_obj: Handle to a sync event.
- * Returns:
- * DSP_SOK:Success;
- * DSP_EFAIL: Failed to reset
[PATCH 4/4] DSPBRIDGE: cleanup to sync module
From 16f7a1a33d7f76ea3e2962421fea8d5b5f15e4e1 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Tue, 23 Mar 2010 19:54:24 -0600
Subject: [PATCH] DSPBRIDGE: cleanup to sync module
This patch cleanup sync module removing everything is not needed
anymore.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |2 -
arch/arm/plat-omap/include/dspbridge/chnlpriv.h |4 -
arch/arm/plat-omap/include/dspbridge/sync.h | 136 +--
drivers/dsp/bridge/services/services.c |9 +-
drivers/dsp/bridge/services/sync.c | 212 +--
5 files changed, 7 insertions(+), 356 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
index d961578..f394ba6 100644
--- a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
@@ -141,8 +141,6 @@ struct chnl_object {
bhandle user_event;
/* Abstract syncronization object */
struct sync_object *sync_event;
- /* Name of Sync event */
- char sz_event_name[SYNC_MAXNAMELENGTH + 1];
u32 process;/* Process which created this channel */
u32 pcb_arg;/* Argument to use with callback */
struct lst_list *pio_requests; /* List of IOR's to driver */
diff --git a/arch/arm/plat-omap/include/dspbridge/chnlpriv.h
b/arch/arm/plat-omap/include/dspbridge/chnlpriv.h
index 0793e0d..9fe7a74 100644
--- a/arch/arm/plat-omap/include/dspbridge/chnlpriv.h
+++ b/arch/arm/plat-omap/include/dspbridge/chnlpriv.h
@@ -83,10 +83,6 @@ struct chnl_info {
u32 cio_cs; /* Number of IOCs in queue. */
u32 cio_reqs; /* Number of IO Requests in queue. */
u32 process;/* Process owning this channel. */
- /*
-* Name of channel I/O completion event. Not required in Linux
-*/
- char sz_event_name[CHNL_MAXEVTNAMELEN + 1];
};
/* Channel manager info: */
diff --git a/arch/arm/plat-omap/include/dspbridge/sync.h
b/arch/arm/plat-omap/include/dspbridge/sync.h
index c3c68e1..9f8786e 100644
--- a/arch/arm/plat-omap/include/dspbridge/sync.h
+++ b/arch/arm/plat-omap/include/dspbridge/sync.h
@@ -20,15 +20,12 @@
#define _SYNC_H
#include dspbridge/errbase.h
-#define SIGNATURECS 0x53435953 /* SYCS (in reverse) */
-#define SIGNATUREDPCCS 0x53445953 /* SYDS (in reverse) */
+#include dspbridge/dbdefs.h
+
/* Special timeout value indicating an infinite wait: */
#define SYNC_INFINITE 0x
-/* Maximum string length of a named event */
-#define SYNC_MAXNAMELENGTH 32
-
/**
* struct sync_object - the basic sync_object structure
* @comp: use to signal events
@@ -40,118 +37,6 @@ struct sync_object{
struct completion *multi_comp;
};
-/* Generic SYNC CS object: */
-struct sync_csobject {
- u32 dw_signature; /* used for object validation */
- struct semaphore sem;
-};
-
-/* SYNC object attributes: */
-struct sync_attrs {
- bhandle user_event; /* Platform's User Mode synch. object. */
- bhandle kernel_event; /* Platform's Kernel Mode sync. object. */
- u32 dw_reserved1; /* For future expansion. */
- u32 dw_reserved2; /* For future expansion. */
-};
-
-/*
- * sync_delete_cs
- * Purpose:
- * Delete a critical section.
- * Parameters:
- * hcs_obj: critical section handle.
- * Returns:
- * DSP_SOK:Success.
- * DSP_EHANDLE:Invalid handle.
- * Requires:
- * Ensures:
- */
-extern dsp_status sync_delete_cs(IN struct sync_csobject *hcs_obj);
-
-/*
- * sync_enter_cs
- * Purpose:
- * Enter the critical section.
- * Parameters:
- * hcs_obj: critical section handle.
- * Returns:
- * DSP_SOK:Success.
- * DSP_EHANDLE:Invalid handle.
- * Requires:
- * Ensures:
- */
-extern dsp_status sync_enter_cs(IN struct sync_csobject *hcs_obj);
-
-/*
- * sync_exit
- * Purpose:
- * Discontinue usage of module; free resources when reference count
- * reaches 0.
- * Parameters:
- * Returns:
- * Requires:
- * SYNC initialized.
- * Ensures:
- * Resources used by module are freed when cRef reaches zero.
- */
-extern void sync_exit(void);
-
-/*
- * sync_init
- * Purpose:
- * Initializes private state of SYNC module.
- * Parameters:
- * Returns:
- * TRUE if initialized; FALSE if error occured.
- * Requires:
- * Ensures:
- * SYNC initialized.
- */
-extern bool sync_init(void);
-
-/*
- * sync_initialize_cs
- * Purpose:
- * Initialize the critical section.
- * Parameters:
- * hcs_obj: critical section handle.
- * Returns:
- * DSP_SOK:Success.
- * DSP_EMEMORY:Out of memory.
- * Requires:
- * Ensures:
- */
-extern
