RE: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields
Sergio,
-Original Message-
From: Aguirre, Sergio
Sent: Friday, November 20, 2009 9:28 PM
To: Sripathy, Vishwanath; linux-omap@vger.kernel.org
Subject: RE: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields
Vishwa,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Sripathy, Vishwanath
Sent: Friday, November 20, 2009 9:29 AM
To: linux-omap@vger.kernel.org; Sripathy, Vishwanath
Subject: [PATCHV2 3/4] OMAP3: Correct width for CLKSEL Fields
DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in
3630.This patch has changes to accommodate this in CM
dynamically based on
chip version.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 18 --
arch/arm/mach-omap2/clock34xx.h | 53
--
arch/arm/mach-omap2/cm-regbits-34xx.h |7 +++-
arch/arm/plat-omap/include/plat/clock.h |4 +-
4 files changed, 71 insertions(+), 11 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/clock34xx.c
No file mode changes, please.
Ack
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index 167f075..1e35f9a
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -43,6 +43,7 @@
#include prm-regbits-34xx.h
#include cm.h
#include cm-regbits-34xx.h
+#include plat/cpu.h
static const struct clkops clkops_noncore_dpll_ops;
@@ -97,6 +98,7 @@ struct omap_clk {
#define CK_3XXX(1 0)
#define CK_3430ES1 (1 1)
#define CK_3430ES2 (1 2)
+#define CK_363X(1 3)
static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_32k_fck, omap_32k_fck, CK_3XXX),
@@ -134,13 +136,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_12m_fck, omap_12m_fck, CK_3XXX),
CLK(NULL, dpll4_m2_ck, dpll4_m2_ck, CK_3XXX),
CLK(NULL, dpll4_m2x2_ck, dpll4_m2x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_3XXX),
+ CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_3XXX
| CK_363X),
Shouldn't CK_363X replace CK_3XXX?
CK_363X is always inside the CK_3XXX scope, but not the other way around.
Not really. If you see the intention of adding CK_363X, it is to indicate that
this particular clock node has some changes specific to 3630 and it needs
special handling. So we cannot replace CK_363X with CK_3XXX
CLK(NULL, dpll4_m3x2_ck, dpll4_m3x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_3XXX),
+ CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_3XXX
| CK_363X),
CLK(NULL, dpll4_m4x2_ck, dpll4_m4x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_3XXX),
+ CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_3XXX
| CK_363X),
CLK(NULL, dpll4_m5x2_ck, dpll4_m5x2_ck, CK_3XXX),
- CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_3XXX),
+ CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_3XXX
| CK_363X),
CLK(NULL, dpll4_m6x2_ck, dpll4_m6x2_ck, CK_3XXX),
CLK(NULL, emu_per_alwon_ck, emu_per_alwon_ck, CK_3XXX),
CLK(NULL, dpll5_ck, dpll5_ck, CK_3430ES2),
@@ -1222,6 +1224,8 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_DCO_SEL_MASK;
dpll4_ck.dpll_data-sd_div_mask =
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
+ dpll4_dd.mult_mask =
OMAP3630_PERIPH_DPLL_MULT_MASK;
+ cpu_mask |= RATE_IN_363X;
}
}
@@ -1232,6 +1236,12 @@ int __init omap2_clk_init(void)
for (c = omap34xx_clks; c omap34xx_clks +
ARRAY_SIZE(omap34xx_clks); c++)
if (c-cpu cpu_clkflg) {
+ /* for 3630, change the mask value for
clocks which are
+ marked as CK_363X*/
+ if (cpu_is_omap3630() (c-cpu CK_363X)) {
+ c-lk.clk-clksel_mask =
+
c-lk.clk-clksel_mask_3630;
+ }
clkdev_add(c-lk);
clk_register(c-lk.clk);
omap2_init_clk_clkdm(c-lk.clk);
diff --git a/arch/arm/mach-omap2/clock34xx.h
b/arch/arm/mach-omap2/clock34xx.h
index 813a83e..93c92e5 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -243,6 +243,42 @@ static const struct clksel_rate
div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_3XXX | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 3, .val = 3, .flags = RATE_IN_3XXX },
+ { .div = 4, .val = 4, .flags = RATE_IN_3XXX },
+ { .div = 5, .val = 5, .flags = RATE_IN_3XXX
RE: [PATCHV2 4/4] OMAP3: add support for 192Mhz sgx clock
-Original Message-
From: Menon, Nishanth
Sent: Friday, November 20, 2009 9:49 PM
To: Sripathy, Vishwanath
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHV2 4/4] OMAP3: add support for 192Mhz sgx clock
unrelated to this patch comment: we might want to consider thinking in
terms of optimizing the memory as OMAP4 also kicks in.. some sort of
dynamic clock tree traversal and __initdata method perhaps??
Hi Vishwa,
Thanks for the patch, few minor comments follow:
Sripathy, Vishwanath had written, on 11/20/2009 09:28 AM, the following:
SGX can run at 192MHz on 3630 and this patch has changes to support this
feature. Basically DPLL4 M2 will be 192Mhz which will be used as SGX
Clock. 192Mhz clock is divided by 2 (using CM_CLKSEL_CORE) to generate
96Mh clock
- you probably intended 96Mhz
Yes, is should be 96Mhz.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 16 +++-
arch/arm/mach-omap2/clock34xx.h | 33
+
arch/arm/mach-omap2/cm-regbits-34xx.h |2 ++
arch/arm/mach-omap2/id.c |7 +--
arch/arm/plat-omap/include/plat/cpu.h |3 +++
5 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-
omap2/clock34xx.c
index 1e35f9a..bce7e46 100755
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -128,6 +128,7 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, emu_core_alwon_ck, emu_core_alwon_ck, CK_3XXX),
CLK(NULL, dpll4_ck, dpll4_ck, CK_3XXX),
CLK(NULL, dpll4_x2_ck, dpll4_x2_ck, CK_3XXX),
+ CLK(NULL, omap_192m_alwon_ck, omap_192m_alwon_ck,
CK_363X),
CLK(NULL, omap_96m_alwon_fck, omap_96m_alwon_fck, CK_3XXX),
CLK(NULL, omap_96m_fck, omap_96m_fck, CK_3XXX),
CLK(NULL, cm_96m_fck, cm_96m_fck,CK_3XXX),
@@ -1226,7 +1227,20 @@ int __init omap2_clk_init(void)
OMAP3630_PERIPH_DPLL_SD_DIV_MASK;
dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
cpu_mask |= RATE_IN_363X;
- }
+ cpu_clkflg |= CK_363X;
I think introduce CK_36XX should be done seperately.
Ack. It should have been part of patch3.
+ }
+
+ if (omap3_has_192mhz_clk()) {
+ omap_96m_alwon_fck.parent = omap_192m_alwon_ck;
+ omap_96m_alwon_fck.init = omap2_init_clksel_parent;
+ omap_96m_alwon_fck.clksel_reg =
+ OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
+ omap_96m_alwon_fck.clksel_mask =
+ OMAP3630_CLKSEL_96M_MASK;
+ omap_96m_alwon_fck.clksel = omap_96m_alwon_fck_clksel;
+ omap_96m_alwon_fck.recalc = omap2_clksel_recalc;
+ }
+
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-
omap2/clock34xx.h
index 93c92e5..6fe89df 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -654,12 +654,31 @@ static struct clk dpll4_m2x2_ck = {
.recalc = omap3_clkoutx2_recalc,
};
+/* Adding 192MHz Clock node needed by SGX */
+static struct clk omap_192m_alwon_ck = {
+ .name = omap_192m_alwon_ck,
+ .ops= clkops_null,
+ .parent = dpll4_m2x2_ck,
+ .recalc = followparent_recalc,
+};
+
/*
* DPLL4 generates DPLL4_M2X2_CLK which is then routed into the PRM as
* PRM_96M_ALWON_(F)CLK. Two clocks then emerge from the PRM:
* 96M_ALWON_FCLK (called omap_96m_alwon_fck below) and
* CM_96K_(F)CLK.
*/
+static const struct clksel_rate omap_96m_alwon_fck_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_363X },
+ { .div = 2, .val = 2, .flags = RATE_IN_363X | DEFAULT_RATE },
+ { .div = 0 }
+};
+
+static const struct clksel omap_96m_alwon_fck_clksel[] = {
+ { .parent = omap_192m_alwon_ck, .rates = omap_96m_alwon_fck_rates },
+ { .parent = NULL }
+};
+
static struct clk omap_96m_alwon_fck = {
.name = omap_96m_alwon_fck,
.ops= clkops_null,
@@ -1223,6 +1242,18 @@ static const struct clksel_rate sgx_core_rates[] = {
{ .div = 3, .val = 0, .flags = RATE_IN_3XXX | DEFAULT_RATE },
{ .div = 4, .val = 1, .flags = RATE_IN_3XXX },
{ .div = 6, .val = 2, .flags = RATE_IN_3XXX },
+ { .div = 2, .val = 5, .flags = RATE_IN_363X },
dont we have more options here? thinking: does this mean that all 3XXX
and 36XX defines are valid ones for SGX?
From PRCM point of view all 3XXX configurations are valid for 3430. All 3XXX
and 363X are valid for 3630. May be SGX driver not use all these
RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Y, Kishore
Sent: Friday, November 20, 2009 7:58 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00
2001
From: Mukund Mittal mmit...@ti.com
Date: Fri, 20 Nov 2009 18:35:26 +0530
Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display
Nec panel has been added which is used on both
zoom2 and zoom3 boards
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/video/omap2/displays/panel-nec.c | 291
++
1 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-nec.c
diff --git a/drivers/video/omap2/displays/panel-nec.c
b/drivers/video/omap2/displays/panel-nec.c
new file mode 100644
index 000..c18f3ba
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec.c
@@ -0,0 +1,291 @@
+/*
+ * NEC panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
[Hiremath, Vaibhav] Can you please verify/cross-check this?
Thanks,
Vaibhav
+ * 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/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+#include linux/spi/spi.h
+
+#include mach/gpio.h
+#include mach/gpio.h
+#include plat/mux.h
+#include asm/mach-types.h
+#include plat/control.h
+
+#include plat/display.h
+
+#define LCD_XRES 800
+#define LCD_YRES 480
+
+#define LCD_PIXCLOCK_MIN 21800 /* NEC MIN PIX Clock is
21.8MHz */
+#define LCD_PIXCLOCK_TYP 23800 /* Typical PIX clock is
23.8MHz */
+#define LCD_PIXCLOCK_MAX 25700 /* Maximum is 25.7MHz */
+
+/* Current Pixel clock */
+#define LCD_PIXEL_CLOCK LCD_PIXCLOCK_MIN
+
+
+/*NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_panel_timings = {
+ /* 800 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = LCD_XRES,
+ .y_res = LCD_YRES,
+ .pixel_clock= LCD_PIXEL_CLOCK,
+ .hfp= 6,
+ .hsw= 1,
+ .hbp= 4,
+ .vfp= 3,
+ .vsw= 1,
+ .vbp= 4,
+};
+
+static int nec_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF
|
+OMAP_DSS_LCD_ONOFF;
+ dssdev-panel.timings = nec_panel_timings;
+ dssdev-panel.recommended_bpp = 16;
+
+ return 0;
+}
+
+static void nec_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int nec_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ mdelay(4);
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void nec_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+ mdelay(4);
+}
+
+static int nec_panel_suspend(struct omap_dss_device *dssdev)
+{
+ nec_panel_disable(dssdev);
+ return 0;
+}
+
+static int nec_panel_resume(struct omap_dss_device *dssdev)
+{
+ return nec_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver nec_driver = {
+ .probe = nec_panel_probe,
+ .remove = nec_panel_remove,
+
+ .enable = nec_panel_enable,
+ .disable= nec_panel_disable,
+ .suspend= nec_panel_suspend,
+ .resume = nec_panel_resume,
+
+ .driver = {
+ .name = NEC_panel,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int
+spi_send(struct spi_device *spi, unsigned char reg_addr, unsigned
char reg_data)
+{
+ int ret = 0;
+ unsigned int cmd = 0;
+ unsigned int data = 0;
+
+ cmd = 0x | reg_addr; /* register address write */
+ data = 0x0100 | reg_data ; /* register data write */
+ data = (cmd 16) | data;
+ if (spi_write(spi, (unsigned char *)data, 4))
+
RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, November 23, 2009 3:06 PM
To: Y, Kishore; linux-omap@vger.kernel.org
Subject: RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Y, Kishore
Sent: Friday, November 20, 2009 7:58 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00
2001
From: Mukund Mittal mmit...@ti.com
Date: Fri, 20 Nov 2009 18:35:26 +0530
Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display
Nec panel has been added which is used on both
zoom2 and zoom3 boards
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/video/omap2/displays/panel-nec.c | 291
++
1 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-nec.c
diff --git a/drivers/video/omap2/displays/panel-nec.c
b/drivers/video/omap2/displays/panel-nec.c
new file mode 100644
index 000..c18f3ba
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec.c
@@ -0,0 +1,291 @@
+/*
+ * NEC panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
[Hiremath, Vaibhav] Can you please verify/cross-check this?
Thanks,
Vaibhav
Mistake from my side. I will check it out and update the patch.
Regards,
Kishore Y
+ * 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/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+#include linux/spi/spi.h
+
+#include mach/gpio.h
+#include mach/gpio.h
+#include plat/mux.h
+#include asm/mach-types.h
+#include plat/control.h
+
+#include plat/display.h
+
+#define LCD_XRES 800
+#define LCD_YRES 480
+
+#define LCD_PIXCLOCK_MIN 21800 /* NEC MIN PIX Clock is
21.8MHz */
+#define LCD_PIXCLOCK_TYP 23800 /* Typical PIX clock is
23.8MHz */
+#define LCD_PIXCLOCK_MAX 25700 /* Maximum is 25.7MHz */
+
+/* Current Pixel clock */
+#define LCD_PIXEL_CLOCKLCD_PIXCLOCK_MIN
+
+
+/*NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_panel_timings = {
+ /* 800 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = LCD_XRES,
+ .y_res = LCD_YRES,
+ .pixel_clock= LCD_PIXEL_CLOCK,
+ .hfp= 6,
+ .hsw= 1,
+ .hbp= 4,
+ .vfp= 3,
+ .vsw= 1,
+ .vbp= 4,
+};
+
+static int nec_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF
|
+OMAP_DSS_LCD_ONOFF;
+ dssdev-panel.timings = nec_panel_timings;
+ dssdev-panel.recommended_bpp = 16;
+
+ return 0;
+}
+
+static void nec_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int nec_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ mdelay(4);
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void nec_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+ mdelay(4);
+}
+
+static int nec_panel_suspend(struct omap_dss_device *dssdev)
+{
+ nec_panel_disable(dssdev);
+ return 0;
+}
+
+static int nec_panel_resume(struct omap_dss_device *dssdev)
+{
+ return nec_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver nec_driver = {
+ .probe = nec_panel_probe,
+ .remove = nec_panel_remove,
+
+ .enable = nec_panel_enable,
+ .disable= nec_panel_disable,
+ .suspend= nec_panel_suspend,
+ .resume = nec_panel_resume,
+
+ .driver = {
+ .name = NEC_panel,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int
+spi_send(struct
RE: [PATCH 2/3] Input:TouchScreen: Introduce TSC2004 driver support
-Original Message- From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] Sent: Friday, November 20, 2009 10:32 PM To: Hiremath, Vaibhav Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/3] Input:TouchScreen: Introduce TSC2004 driver support Hi Vaibhav, On Thu, Nov 19, 2009 at 08:16:40PM +0530, hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com If I do: sed 's/2004/2007/g' drivers/input/touchscreen/tsc2004.c | diff -u drivers/input/touchscreen/tsc2007.c - the diff is miniscule so why can't TSC2004 support be simply added to TSC2007 driver? [Hiremath, Vaibhav] The driver which I submitted is the basic version, there is lot which required to be added here for complete support of TSC2004 features. I tried to summarize it (in short) here - - TSC2004 supports register based control, whereas TSC2007 is command based control. - TSC2004 supports 2 different modes of operation, whereas there is nothing like this in TSc2007 - There are lots of configuration options TSC2004 provides. Again there are differences like command/address formats TSC2004 - -- BIT NAMEDESCRIPTION D7 Control Byte ID 1 D6-D3 C3-C0 Converter function select D2 M 1: 12 Bit 0: 10 bit D1 SWRSTSoftware Reset. D0 STS Stop bit for all converter functions. TSC2007 - - BIT NAMEDESCRIPTION D7-D4 C3-C0 All Converter Function Select bits D3-D2 PD1-PD0 Power down bit control D1 M 1: 8-bit 0: 12 bit D0 X Don't care. So in my opinion we must not try to merge drivers for these two devices. I hope this information clears all the confusion. Thanks, Vaibhav Thanks. -- Dmitry -- 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: DSS2 panel question
On Sat, 2009-11-21 at 16:16 +0100, ext Grazvydas Ignotas wrote: Hello, I've been updating Pandora's panel for upstream-going DSS2, which now uses device/device_driver model for panels. The thing is that the panel we use is SPI controlled, so it needs to be set up as spi_driver. From SPI probe function I can do omap_dss_register_driver(), but how do I pass SPI data to omap_dss_device cleanly? Surely some globals would help, but this is not a clean way I guess. There used to be panel-n800.c with similar requirements, but it's not yet converted, right? Do you have any ideas how this can be done? I don't have any good answer for this. For N900's panel there was a static global variable, if I remember right. Not very clean, as you said. Tomi -- 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: [alsa-devel] [PATCH 6/8] AI TB: Audio driver of Always Innovating OMAP3-based Touch Book
On Wed, Nov 18, 2009 at 06:57:59PM -0800, Gregoire Gentil wrote: Signed-off-by: Gregoire Gentil grego...@gentil.com --- sound/soc/omap/Kconfig |8 ++ sound/soc/omap/Makefile |2 + sound/soc/omap/omap3touchbook.c | 211 +++ Your MUA has word wrapped this patch so it can't be applied. It's also removed all the indentation so I skipped reviewing it due to the resulting legibility issues. -- 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] [OMAP1] use gen_nand
Since omapnand driver never find its way into mainline, switch to gen_nand
instead.
Following patch is compile tested only, but it is based on code I wrote for
NetStar board and runtime tested it there.
Signed-off-by: Ladislav Michl la...@linux-mips.org
Cc: Imre Deak imre.d...@nokia.com
Cc: Brian Swetland swetl...@google.com
Cc: Kevin Hilman k...@hilman.org
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..8da8c64 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -30,7 +30,6 @@
#include mach/gpio.h
#include plat/mux.h
#include plat/fpga.h
-#include plat/nand.h
#include plat/keypad.h
#include plat/common.h
#include plat/board.h
@@ -167,8 +166,40 @@ static struct platform_device nor_device = {
.resource = nor_resource,
};
-static struct omap_nand_platform_data nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
+static void nand_cmd_ctl(struct mtd_info *mtd, int cmd,unsigned int
ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this-IO_ADDR_W | mask);
+}
+
+#define FSAMPLE_NAND_RB_GPIO_PIN 62
+
+static int nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(FSAMPLE_NAND_RB_GPIO_PIN);
+}
+
+static const char *part_probes[] = { cmdlinepart, NULL };
+
+static struct platform_nand_data nand_data = {
+ .chip = {
+ .nr_chips = 1,
+ .chip_offset= 0,
+ .options= NAND_SAMSUNG_LP_OPTIONS,
+ .part_probe_types = part_probes,
+ },
+ .ctrl = {
+ .cmd_ctrl = nand_cmd_ctl,
+ .dev_ready = nand_dev_ready,
+ },
};
static struct resource nand_resource = {
@@ -178,7 +209,7 @@ static struct resource nand_resource = {
};
static struct platform_device nand_device = {
- .name = omapnand,
+ .name = gen_nand,
.id = 0,
.dev= {
.platform_data = nand_data,
@@ -233,13 +264,6 @@ static struct platform_device *devices[] __initdata = {
lcd_device,
};
-#define P2_NAND_RB_GPIO_PIN62
-
-static int nand_dev_ready(struct omap_nand_platform_data *data)
-{
- return gpio_get_value(P2_NAND_RB_GPIO_PIN);
-}
-
static struct omap_lcd_config fsample_lcd_config __initdata = {
.ctrl_name = internal,
};
@@ -250,9 +274,9 @@ static struct omap_board_config_kernel fsample_config[] = {
static void __init omap_fsample_init(void)
{
- if (gpio_request(P2_NAND_RB_GPIO_PIN, NAND ready) 0)
+ if (gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, NAND ready) 0)
BUG();
- nand_data.dev_ready = nand_dev_ready;
+ gpio_direction_input(FSAMPLE_NAND_RB_GPIO_PIN);
omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..283a6f2 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -40,7 +40,6 @@
#include plat/mux.h
#include plat/dma.h
#include plat/tc.h
-#include plat/nand.h
#include plat/irda.h
#include plat/usb.h
#include plat/keypad.h
@@ -179,11 +178,43 @@ static struct mtd_partition h2_nand_partitions[] = {
},
};
-/* dip switches control NAND chip access: 8 bit, 16 bit, or neither */
-static struct omap_nand_platform_data h2_nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
- .parts = h2_nand_partitions,
- .nr_parts = ARRAY_SIZE(h2_nand_partitions),
+static void h2_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this-IO_ADDR_W | mask);
+}
+
+#define H2_NAND_RB_GPIO_PIN62
+
+static int h2_nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(H2_NAND_RB_GPIO_PIN);
+}
+
+static const char *h2_part_probes[] = { cmdlinepart, NULL };
+
+struct platform_nand_data h2_nand_platdata = {
+ .chip = {
+ .nr_chips = 1,
+ .chip_offset= 0,
+ .nr_partitions = ARRAY_SIZE(h2_nand_partitions),
+ .partitions = h2_nand_partitions,
+ .options= NAND_SAMSUNG_LP_OPTIONS,
+ .part_probe_types = h2_part_probes,
+ },
+ .ctrl = {
+ .cmd_ctrl = h2_nand_cmd_ctl,
+
Re: [PATCH v3] mmc-omap: Add support for 16-bit and 32-bit registers
On Sun, Nov 22, 2009 at 01:16:25PM -0800, Cory Maccarrone wrote:
The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
a modification of the register addresses in the mmc-omap driver. To resolve
this, a bit shift is performed on base register addresses, either by 1 or 2
bits depending on the CPU in use. This yields the correct registers for
each CPU.
[...]
@@ -167,6 +168,8 @@ struct mmc_omap_host {
spinlock_t clk_lock; /* for changing enabled state */
unsigned intfclk_enabled:1;
+ unsignedreg_shift:1;
+
[...]
Here you made reg_shift one bit wide variable...
@@ -1490,6 +1493,8 @@ static int __init mmc_omap_probe(struct platform_device
*pdev)
}
}
+ host-reg_shift = (cpu_is_omap7xx() ? 1 : 2);
+
...and here you are possibly trying to set second bit of that variable. It does
not work.
And sorry to ask again. This very driver works reliable and there are no
timeouts like this
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
while detecting MMC card on OMAP730? (because I can see them on 5910). This
question
is unrelated to your patch.
ladis
--
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
missing keypad interrupts
Hi, I use 2.6.29 kernel (omap zoom kernel) and am facing a strange problem. When i go to suspend, I am unable to wakeup using the keypad. Sometimes this works. I find that when the system is alive keypad works fine. The sysnirq mux is okay. I am not sure, why i am unable to wakeup when the system is suspended. I am missing keypad interrupts. I set an led on and off every time i press the keypad in the isr. After sometime, it does not glow, when i press the keypad. However, i am able to wakeup on serial input. Please advise. Regards, sriram -- 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: VDD1 voltage after resume from idle
-Original Message- From: Premi, Sanjeev Sent: Saturday, November 21, 2009 1:04 AM To: Premi, Sanjeev; Maxime Petazzoni Cc: linux-omap@vger.kernel.org Subject: RE: VDD1 voltage after resume from idle -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev Sent: Friday, November 20, 2009 11:46 PM To: Maxime Petazzoni Cc: linux-omap@vger.kernel.org Subject: RE: VDD1 voltage after resume from idle -Original Message- From: Maxime Petazzoni [mailto:mpetazz...@mvista.com] Sent: Friday, November 20, 2009 10:00 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: VDD1 voltage after resume from idle [snip]--[snip]--[snip] I guess the root cause could be same. I have not been able to ascertain the reason for the voltage changing during the idle/wakeup sequence. Also tried to eliminate the enable_smartreflex() calls on wakeup path. Sill I see voltage ramp-up. I am trying to find the cause of voltage ramping to 1.2V in hope that the reason for ramp down will be just inverted reflection. With smartreflex disabled, there is no change in the voltage during suspend; so the problem area seems to be smartreflex. Best regards, Sanjeev Found the problem! In sr_configure_vp() the vsel is picked up from the OPP table and used, setting the voltage as expected (1.35V in my case). A printk confirms PRM_VC_CMD_VAL_0 is 0x3C201E00. By the time, kernel boots up, the value has changed to 0x30201E00. (0x30 corresponds to 1.2V) [r...@omap3evm /]# devmem 0x4830722c 32 0x30201E00 Now, when I update the init voltage back to 3C (via devmem) the voltage after resume/idle-wakeup is right (as expected). [r...@omap3evm /]# devmem 0x4830722c 32 0x3c201e00 [r...@omap3evm /]# So, I just need to find exact location where the configuration is being overwritten. Correction. Though I expected/assumed VSEL to be written to this Location. It wasn't the case. VSEL is used to update the ON voltage Field in PRM_VP1_CONFIG; but not the PRM_VC_CMD_VAL_0. Haven't tried (too hard) to find initiator programming this reg in kernel - so, it might be retaining values from u-boot. After ensuring that PRM_VC_CMD_VAL_0,1 are updated based on the VSEL values in current opp tables, the problem seems to be fixed. Patch from my working tree following soon for review. Will refresh it against /pm, if needed, there are no comments. Best regards, Sanjeev It is well past midnight now. So the patch will have to wait until tomorrow. Best regards, Sanjeev [snip]--[snip]--[snip] -- 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] omap3: sr: Update ON voltage levels based on VSEL
The settings for ON voltage level in the registers PRM_VC_CMD_VAL_0,1 was not updated based on OPP table. Once the MPU resumes from OFF mode (during idle OR suspend) the VDD1 voltage always returns to 1.2V. This patch programs the value based on current OPP. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/mach-omap2/smartreflex.c | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index be3a1da..4cbbd6f 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -313,6 +313,15 @@ static void sr_configure_vp(int srid) PRM_VP1_CONFIG_TIMEOUTEN | vsel OMAP3430_INITVOLTAGE_SHIFT; + /* +* Update the 'ON' voltage levels based on the VSEL. +* (See spruf8c.pdf sec 1.5.3.1) +*/ + prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK, + (vsel OMAP3430_VC_CMD_ON_SHIFT), + OMAP3430_GR_MOD, + OMAP3_PRM_VC_CMD_VAL_0_OFFSET); + prm_write_mod_reg(vpconfig, OMAP3430_GR_MOD, OMAP3_PRM_VP1_CONFIG_OFFSET); prm_write_mod_reg(PRM_VP1_VSTEPMIN_SMPSWAITTIMEMIN | @@ -354,6 +363,15 @@ static void sr_configure_vp(int srid) else vsel = l3_opps[target_opp_no].vsel; + /* +* Update the 'ON' voltage levels based on the VSEL. +* (See spruf8c.pdf sec 1.5.3.1) +*/ + prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK, + (vsel OMAP3430_VC_CMD_ON_SHIFT), + OMAP3430_GR_MOD, + OMAP3_PRM_VC_CMD_VAL_1_OFFSET); + vpconfig = PRM_VP2_CONFIG_ERROROFFSET | PRM_VP2_CONFIG_ERRORGAIN | PRM_VP2_CONFIG_TIMEOUTEN | @@ -391,7 +409,6 @@ static void sr_configure_vp(int srid) /* Clear force bit */ prm_clear_mod_reg_bits(OMAP3430_FORCEUPDATE, OMAP3430_GR_MOD, OMAP3_PRM_VP2_CONFIG_OFFSET); - } } -- 1.6.2.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 v3] mmc-omap: Add support for 16-bit and 32-bit registers
2009/11/23 Ladislav Michl ladislav.mi...@seznam.cz: And sorry to ask again. This very driver works reliable and there are no timeouts like this mmci-omap mmci-omap.0: command timeout (CMD8) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD5) mmci-omap mmci-omap.0: command timeout (CMD55) mmci-omap mmci-omap.0: command timeout (CMD55) mmci-omap mmci-omap.0: command timeout (CMD55) mmci-omap mmci-omap.0: command timeout (CMD55) while detecting MMC card on OMAP730? (because I can see them on 5910). This question is unrelated to your patch. Yes, this driver (after patching) works reliably on OMAP7XX. The CMD5/8 timeouts seem normal and non-fatal. CMD55 is the init command that has to work. We had an old problem causing output just like what you report - it turned out we missed a GPIO to power up the MMC card. -- Alistair Buxton a.j.bux...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2] OMAP3: PM: Fix for MPU power domain MEM BANK position
Hello Thara,
On Fri, 16 Oct 2009, Gopinath, Thara wrote:
Yes sounds definitely reasonable :-). I agree,we should try to do away with
the strcmp if possible.
I will implement the same and repost this fix.
Had a chance to work on this yet? It would be good to get this fix in at
some point.
.
- Paul
Regards
Thara
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Friday, October 16, 2009 1:51 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com
Subject: RE: [PATCH V2] OMAP3: PM: Fix for MPU power domain MEM BANK
position
Hi Thara,
On Thu, 15 Oct 2009, Gopinath, Thara wrote:
Thanks Paul. The bit positions are goofed up only in PWRSTS and
PREPWRSTS not in PWSTCTRL register. As per the approach you have
suggested below, if we change the mem bank number from 0 to 1 , we will
have to change the logic for read/write into PWSTCTRL for mpu pwr
domain.
Okay. Here's what I'd propose: rather than testing for the
powerdomain name in the function, or testing for the MPU PRCM module
offset, let's add a new powerdomain flag into powerdomain.h,
#define PWRDM_OMAP3_MPU_QUIRK(1 1) /* MPU bit pos quirk */
or something similar. Then let's set that for the mpu_pwrdm in
powerdomains34xx.h and test for that flag in powerdomain.c.
I prefer this since RMK has previously NAK'ed strcmp()s for this sort of
thing, for good reason, and testing the PRCM internal module offset has
many of the same problems.
Sound reasonable?
- Paul
Regards
Thara
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, October 15, 2009 4:51 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com
Subject: Re: [PATCH V2] OMAP3: PM: Fix for MPU power domain MEM BANK
position
Hi Thara,
I regret the delay. A comment:
On Fri, 28 Aug 2009, Thara Gopinath wrote:
MPU power domain bank 0 bits are displayed in position of bank 1
in PWRSTS and PREPWRSTS registers. So read them from correct
position
Indeed. What do you think about a slightly different approach: changing
powerdomains34xx.h to be correct? In other words, instead of
.pwrsts_mem_ret = {
[0] = PWRSTS_OFF_RET,
},
.pwrsts_mem_on= {
[0] = PWRSTS_OFF_ON,
},
we would use:
.pwrsts_mem_ret = {
[1] = PWRSTS_OFF_RET,
},
.pwrsts_mem_on= {
[1] = PWRSTS_OFF_ON,
},
We have to deal with the bank count field in struct powerdomain - we
could
just convert it into a bitmap representing available banks. So instead
of:
.banks = 1,
use maybe:
.banks = PWRDM_BANK_1, /* | PWRDM_BANK_0, etc */
Can you foresee any problems with the above approach?
- Paul
Patch refresh issue.
arch/arm/mach-omap2/powerdomain.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 2594cbf..6c5fee9 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -971,6 +971,16 @@ int pwrdm_read_mem_pwrst(struct powerdomain
*pwrdm, u8 bank)
return -EEXIST;
/*
+ * In 3430, for MPU domain bank 0 status bits
+ * are displayed in the position of bank1 status bits
+ * in PWST . So the hack. Think of a cleaner
+ * way of doing this
+ */
+ if (cpu_is_omap34xx())
+ if (!strcmp(mpu_pwrdm, pwrdm-name))
+ bank = 1;
+
+ /*
* The register bit names below may not correspond to the
* actual names of the bits in each powerdomain's register,
* but the type of value returned is the same for each
@@ -1018,6 +1028,15 @@ int pwrdm_read_prev_mem_pwrst(struct
powerdomain *pwrdm, u8 bank)
return -EEXIST;
/*
+ * In 3430, for MPU domain bank 0 status bits
+ * are displayed in the position of bank1 status bits
+ * in PREPWST . So the hack. Think of a cleaner
+ * way of doing this
+ */
+ if (cpu_is_omap34xx())
+ if (!strcmp(mpu_pwrdm, pwrdm-name))
+ bank = 1;
+ /*
* The register bit names below may not correspond to the
* actual names of the bits in each powerdomain's register,
* but the type of value returned is the same for each
--
1.5.4.7
--
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
- Paul
- Paul
- Paul
--
To unsubscribe
Re: [PATCH v3] mmc-omap: Add support for 16-bit and 32-bit registers
On Mon, Nov 23, 2009 at 5:25 AM, Ladislav Michl
ladislav.mi...@seznam.cz wrote:
[...]
@@ -167,6 +168,8 @@ struct mmc_omap_host {
spinlock_t clk_lock; /* for changing enabled state */
unsigned int fclk_enabled:1;
+ unsigned reg_shift:1;
+
[...]
Here you made reg_shift one bit wide variable...
@@ -1490,6 +1493,8 @@ static int __init mmc_omap_probe(struct
platform_device *pdev)
}
}
+ host-reg_shift = (cpu_is_omap7xx() ? 1 : 2);
+
...and here you are possibly trying to set second bit of that variable. It
does
not work.
Ah, clumsy mistake, I'll fix it and resubmit.
And sorry to ask again. This very driver works reliable and there are no
timeouts like this
mmci-omap mmci-omap.0: command timeout (CMD8)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD5)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
mmci-omap mmci-omap.0: command timeout (CMD55)
while detecting MMC card on OMAP730? (because I can see them on 5910). This
question
is unrelated to your patch.
When booting up, I see the first set of timeouts (CMD8 and CMD5), but
I don't get any timeouts on 55, and it starts up correctly for me,
detecting my SD card and mounting it. I've got an Angstrom
installation on my SD card and can boot all the way into it with this
patch.
Not sure if it matters, but this is against the linux-omap for-next branch.
- Cory
--
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: [alsa-devel] [PATCH 6/8] Audio driver of Always Innovating OMAP3-based Touch Book
On Thu, Nov 19, 2009 at 09:18:09AM -0800, Gregoire Gentil wrote:
Signed-off-by: Gregoire Gentil grego...@gentil.com
Please remember to CC the maintainers for the subsystem you're
submitting to on patches.
+static irqreturn_t touchbook_headphone_event(int irq, void *snd)
+{
+ int status = gpio_get_value(TB_HEADPHONE_GPIO);
+ struct snd_soc_device *socdev = platform_get_drvdata(
+ omap3touchbook_snd_device);
+ struct snd_soc_codec *codec = socdev-card-codec;
+
+ if (status) {
+ snd_soc_dapm_disable_pin(codec, HFL);
+ snd_soc_dapm_disable_pin(codec, HFR);
+ } else {
+ snd_soc_dapm_enable_pin(codec, HFL);
+ snd_soc_dapm_enable_pin(codec, HFR);
+ }
+
+ schedule_work(jack_work);
+ return IRQ_HANDLED;
+}
All this jack handling should be using the standard GPIO based jack
abstraction provided by sound/soc/soc-jack.c. That will also give
userspace visiblity of the status of the jack, allowing better
application integration. sdp3430 and ams-delta provide examples of
using the API.
--
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 V4 3/3] OMAP: I2C: Add mpu wake up latency constraint in i2c
-Original Message-
From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com]
Sent: Tuesday, October 27, 2009 7:02 AM
To: Sonasath, Moiz
Cc: khil...@deeprootsystems.com; linux-omap@vger.kernel.org; Jarkko
Nikula; Paul Walmsley; Menon, Nishanth; Pandita, Vikram; jouni.hogander
Subject: RE: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency constraint
in i2c
On Fri, 2009-10-23 at 18:53 +0300, Sonasath, Moiz wrote:
Hello Jokiniemi!
-Original Message-
From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com]
Sent: Wednesday, October 21, 2009 6:51 AM
To: khil...@deeprootsystems.com
Cc: linux-omap@vger.kernel.org; Kalle Jokiniemi; Sonasath, Moiz;
Jarkko
Nikula; Paul Walmsley; Menon, Nishanth
Subject: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up latency
constraint in
i2c
While waiting for completion of the i2c transfer, the
MPU could hit OFF mode and cause several msecs of
delay that made i2c transfers fail more often. The
extra delays and subsequent re-trys cause i2c clocks
to be active more often. This has also an negative
effect on power consumption.
Created a mechanism for passing and using the
constraint setting function in driver code. The used
mpu wake up latency constraints are now set individually
per bus, and they are calculated based on clock rate
and fifo size.
Thanks to Jarkko Nikula, Moiz Sonasath, Paul Walmsley,
and Nishanth Menon for tuning out the details of
this patch.
Cc: Moiz Sonasath m-sonas...@ti.com
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Kalle Jokiniemi kalle.jokini...@digia.com
---
dev-speed = speed;
dev-idle = 1;
@@ -911,6 +923,11 @@ omap_i2c_probe(struct platform_device *pdev)
*/
dev-fifo_size = (dev-fifo_size / 2);
dev-b_hw = 1; /* Enable hardware fixes */
+
+ /* calculate wakeup latency constraint for MPU */
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-latency = (100 * dev-fifo_size) /
+(1000 * speed / 8);
}
IMHO, here instead of using 'dev-fifo_size' for calculating the
'dev-latency', we need to use:
1. For RX case, to avoid Reciver overrun:
if (msg-flags I2C_M_RD)
Use [(FIFO Depth)bytes - (FIFO THRSH)bytes] in calculating
dev-latency
Because conceptually, RDR/RRDY interrupts are generated when RTRSH is
reached, so we want the MPU to be wake up within the time it takes to
fill the FIFO from RTRSH to FIFO Depth (FIFO full).
2. For TX case, to avoid Transmitter Underflow:
if (!(msg-flags I2C_M_RD))
Use (FIFO THRSH)bytes in calculating dev-latency
Because conceptually, XDR/XRDY interrupts are generated when XTRSH is
reached, so we want the MPU to be wake up within the time it takes to
drain the FIFO from XTRSH to Zero (FIFO empty).
Using, dev-fifo_size instead, works in the present code because we
have a RTRSH/XTRSH = dev-fifo_size/2 = 4 bytes
And therefore,
(FIFO Depth)bytes - (FIFO THRSH)bytes
= 8 - 4 = 4 bytes
But, to make it more generic in future and to make it independent of
any changes in the RTRSH/XTRSH values or FIFO depths in future, we
should use a generic code here.
Well, I don't completely agree with the necessity of preparing for
different rx/tx thresholds. For this to make sense, the i2c-omap driver
should first separate in it's code the use of rx and tx thresholds. If
someone is planning to do that, he/she should anyway update the usage of
fifo_size throughout the code, including the wake up latency setting.
Anyways, attached a patch that separates the mpu wake up latencies for
rx and tx. In case that is needed. Though I'm not for it, since it adds
unneeded complexity.
Yes Kalle, you are right! Not having different RX/TX wake-up latencies will
absolutely work fine with the in-place code as we have both the RX/TX
thresholds same. But, I think in future we might have to play around with
different RX/TX thresholds and so from a conceptually right and generic point
of view it makes sense to incur the cost of the added complexity.
The patch V4 looks perfect to me :)
- Moiz
- Kalle
/* reset ASAP, clearing any IRQs */
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
new file mode 100644
index 000..1362fba
--- /dev/null
+++ b/include/linux/i2c-omap.h
@@ -0,0 +1,9 @@
+#ifndef __I2C_OMAP_H__
+#define __I2C_OMAP_H__
+
+struct omap_i2c_bus_platform_data {
+ u32 clkrate;
+ void(*set_mpu_wkup_lat)(struct device *dev, int set);
+};
+
+#endif
--
1.5.4.3
Regards
Moiz Sonasath
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[PATCH] OMAP3: id code detection 3525 vs 3515
From: Sergey Lapin sla...@ossfans.org
The runtime detection of OMAP3515 and OMAP3525
was reversed.
Signed-off-by: Sergey Lapin sla...@ossfans.org
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index f48a4b2..4fad192 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -277,10 +277,10 @@ void __init omap3_cpuinfo(void)
} else if (omap3_has_iva() omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, OMAP3430/3530);
- } else if (omap3_has_sgx()) {
+ } else if (omap3_has_iva()) {
omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, OMAP3525);
- } else if (omap3_has_iva()) {
+ } else if (omap3_has_sgx()) {
omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, OMAP3515);
} else {
--
1.6.2.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
[PATCH v4] mmc-omap: Add support for 16-bit and 32-bit registers
The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
a modification of the register addresses in the mmc-omap driver. To resolve
this, a bit shift is performed on base register addresses, either by 1 or 2
bits depending on the CPU in use. This yields the correct registers for
each CPU.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
drivers/mmc/host/omap.c | 63 +-
1 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5f970e2..ca63e94 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -38,30 +38,30 @@
#include plat/fpga.h
#defineOMAP_MMC_REG_CMD0x00
-#defineOMAP_MMC_REG_ARGL 0x04
-#defineOMAP_MMC_REG_ARGH 0x08
-#defineOMAP_MMC_REG_CON0x0c
-#defineOMAP_MMC_REG_STAT 0x10
-#defineOMAP_MMC_REG_IE 0x14
-#defineOMAP_MMC_REG_CTO0x18
-#defineOMAP_MMC_REG_DTO0x1c
-#defineOMAP_MMC_REG_DATA 0x20
-#defineOMAP_MMC_REG_BLEN 0x24
-#defineOMAP_MMC_REG_NBLK 0x28
-#defineOMAP_MMC_REG_BUF0x2c
-#define OMAP_MMC_REG_SDIO 0x34
-#defineOMAP_MMC_REG_REV0x3c
-#defineOMAP_MMC_REG_RSP0 0x40
-#defineOMAP_MMC_REG_RSP1 0x44
-#defineOMAP_MMC_REG_RSP2 0x48
-#defineOMAP_MMC_REG_RSP3 0x4c
-#defineOMAP_MMC_REG_RSP4 0x50
-#defineOMAP_MMC_REG_RSP5 0x54
-#defineOMAP_MMC_REG_RSP6 0x58
-#defineOMAP_MMC_REG_RSP7 0x5c
-#defineOMAP_MMC_REG_IOSR 0x60
-#defineOMAP_MMC_REG_SYSC 0x64
-#defineOMAP_MMC_REG_SYSS 0x68
+#defineOMAP_MMC_REG_ARGL 0x01
+#defineOMAP_MMC_REG_ARGH 0x02
+#defineOMAP_MMC_REG_CON0x03
+#defineOMAP_MMC_REG_STAT 0x04
+#defineOMAP_MMC_REG_IE 0x05
+#defineOMAP_MMC_REG_CTO0x06
+#defineOMAP_MMC_REG_DTO0x07
+#defineOMAP_MMC_REG_DATA 0x08
+#defineOMAP_MMC_REG_BLEN 0x09
+#defineOMAP_MMC_REG_NBLK 0x0a
+#defineOMAP_MMC_REG_BUF0x0b
+#defineOMAP_MMC_REG_SDIO 0x0d
+#defineOMAP_MMC_REG_REV0x0f
+#defineOMAP_MMC_REG_RSP0 0x10
+#defineOMAP_MMC_REG_RSP1 0x11
+#defineOMAP_MMC_REG_RSP2 0x12
+#defineOMAP_MMC_REG_RSP3 0x13
+#defineOMAP_MMC_REG_RSP4 0x14
+#defineOMAP_MMC_REG_RSP5 0x15
+#defineOMAP_MMC_REG_RSP6 0x16
+#defineOMAP_MMC_REG_RSP7 0x17
+#defineOMAP_MMC_REG_IOSR 0x18
+#defineOMAP_MMC_REG_SYSC 0x19
+#defineOMAP_MMC_REG_SYSS 0x1a
#defineOMAP_MMC_STAT_CARD_ERR (1 14)
#defineOMAP_MMC_STAT_CARD_IRQ (1 13)
@@ -77,8 +77,9 @@
#defineOMAP_MMC_STAT_CARD_BUSY (1 2)
#defineOMAP_MMC_STAT_END_OF_CMD(1 0)
-#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG_##reg)
-#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val), (host)-virt_base +
OMAP_MMC_REG_##reg)
+#define OMAP_MMC_REG(host, reg)(OMAP_MMC_REG_##reg
(host)-reg_shift)
+#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG(host, reg))
+#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val), (host)-virt_base +
OMAP_MMC_REG(host, reg))
/*
* Command types
@@ -167,6 +168,8 @@ struct mmc_omap_host {
spinlock_t clk_lock; /* for changing enabled state */
unsigned intfclk_enabled:1;
+ unsignedreg_shift:2;
+
struct omap_mmc_platform_data *pdata;
};
@@ -679,9 +682,9 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
host-data-bytes_xfered += n;
if (write) {
- __raw_writesw(host-virt_base + OMAP_MMC_REG_DATA,
host-buffer, n);
+ __raw_writesw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
} else {
- __raw_readsw(host-virt_base + OMAP_MMC_REG_DATA, host-buffer,
n);
+ __raw_readsw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
}
}
@@ -899,7 +902,7 @@ mmc_omap_prepare_dma(struct mmc_omap_host *host, struct
mmc_data *data)
int dst_port = 0;
int sync_dev = 0;
- data_addr = host-phys_base + OMAP_MMC_REG_DATA;
+ data_addr = host-phys_base + OMAP_MMC_REG(host, DATA);
frame = data-blksz;
count = sg_dma_len(sg);
@@ -1490,6 +1493,8 @@ static int __init mmc_omap_probe(struct platform_device
*pdev)
}
}
+ host-reg_shift = (cpu_is_omap7xx() ? 1 : 2);
+
[PATCH] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
From: Rajendra Nayak rna...@ti.com
Because of OMAP off-mode, powerdomain can go off when I2C is idle.
Save enough state, and do a re-init for each transfer.
Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
(SYSC_REG) and Aaro Koskinen (wakeup sources.)
Also, The OMAP3430 TRM states:
During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers. Changes may
result in unpredictable behavior.
Hence, the I2C_EN bit should be clearer when modifying these
registers. Please note that clearing the entire I2C_CON register to
disable the I2C module is safe, because the I2C_CON register is
re-configured for each transfer.
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Hu Tao ta...@motorola.com
Cc: Xiaolong Chen a21...@motorola.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Originally posted on 21-july-2009 for the 2.6.32 merge window:
http://marc.info/?l=linux-i2cm=124821776627177w=2
Please queue for 2.6.32-rc if still possible, or at least for 2.6.33.
drivers/i2c/busses/i2c-omap.c | 64 ++--
1 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 827da08..75bf3ad 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -178,6 +178,12 @@ struct omap_i2c_dev {
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
+ u16 pscstate;
+ u16 scllstate;
+ u16 sclhstate;
+ u16 bufstate;
+ u16 syscstate;
+ u16 westate;
};
static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
@@ -230,9 +236,18 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
clk_enable(dev-iclk);
clk_enable(dev-fclk);
+ if (cpu_is_omap34xx()) {
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev-syscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ }
dev-idle = 0;
- if (dev-iestate)
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
}
static void omap_i2c_idle(struct omap_i2c_dev *dev)
@@ -258,7 +273,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
+ u16 psc = 0, scll = 0, sclh = 0, buf = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -287,24 +302,22 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
SYSC_AUTOIDLE_MASK);
} else if (dev-rev = OMAP_I2C_REV_ON_3430) {
- u32 v;
-
- v = SYSC_AUTOIDLE_MASK;
- v |= SYSC_ENAWAKEUP_MASK;
- v |= (SYSC_IDLEMODE_SMART
+ dev-syscstate = SYSC_AUTOIDLE_MASK;
+ dev-syscstate |= SYSC_ENAWAKEUP_MASK;
+ dev-syscstate |= (SYSC_IDLEMODE_SMART
__ffs(SYSC_SIDLEMODE_MASK));
- v |= (SYSC_CLOCKACTIVITY_FCLK
+ dev-syscstate |= (SYSC_CLOCKACTIVITY_FCLK
__ffs(SYSC_CLOCKACTIVITY_MASK));
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ dev-syscstate);
/*
* Enabling all wakup sources to stop I2C freezing on
* WFI instruction.
* REVISIT: Some wkup sources might not be needed.
*/
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- OMAP_I2C_WE_ALL);
-
+ dev-westate = OMAP_I2C_WE_ALL;
+ omap_i2c_write_reg(dev,
Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote: I have not seen any comments on this patch series yet. Tony, Is there something I need to modify? Or it can be unstreamed now? Oh, and by the way, serial drivers are preferrably merged through Greg K-H (gre...@suse.de). So Cc him on the next revision of the patch. -Olof -- 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: [PATCHv3 1/3] OMAP UART: Add omap-serial driver support.
On Fri, 2009-11-13 at 12:23 +0530, Govindraj.R wrote: From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001 From: Govindraj R govindraj.r...@ti.com Date: Fri, 13 Nov 2009 12:01:54 +0530 Subject: [PATCH] OMAP UART: Add omap-serial driver support. This patch adds support for OMAP3430-HIGH SPEED UART Controller. It adds support for the following features: 1. It supports Interrupt mode and DMA mode of operation. 2. Supports Hardware flow control and sofware flow control. 3. Debug Console support on all UARTs. Signed-off-by: Govindraj R govindraj.r...@ti.com --- arch/arm/plat-omap/include/plat/omap-serial.h | 115 +++ drivers/serial/Kconfig| 23 + drivers/serial/Makefile |1 + drivers/serial/omap-serial.c | 1330 + include/linux/serial_core.h |3 + 5 files changed, 1472 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h create mode 100644 drivers/serial/omap-serial.c Did you address the irq storm problems pointed by Mika Westerberg? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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 v4] mmc-omap: Add support for 16-bit and 32-bit registers
* Cory Maccarrone darkstar6...@gmail.com [091123 08:23]:
The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
a modification of the register addresses in the mmc-omap driver. To resolve
this, a bit shift is performed on base register addresses, either by 1 or 2
bits depending on the CPU in use. This yields the correct registers for
each CPU.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
Looks good to me.
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/mmc/host/omap.c | 63 +-
1 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5f970e2..ca63e94 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -38,30 +38,30 @@
#include plat/fpga.h
#define OMAP_MMC_REG_CMD0x00
-#define OMAP_MMC_REG_ARGL 0x04
-#define OMAP_MMC_REG_ARGH 0x08
-#define OMAP_MMC_REG_CON0x0c
-#define OMAP_MMC_REG_STAT 0x10
-#define OMAP_MMC_REG_IE 0x14
-#define OMAP_MMC_REG_CTO0x18
-#define OMAP_MMC_REG_DTO0x1c
-#define OMAP_MMC_REG_DATA 0x20
-#define OMAP_MMC_REG_BLEN 0x24
-#define OMAP_MMC_REG_NBLK 0x28
-#define OMAP_MMC_REG_BUF0x2c
-#define OMAP_MMC_REG_SDIO0x34
-#define OMAP_MMC_REG_REV0x3c
-#define OMAP_MMC_REG_RSP0 0x40
-#define OMAP_MMC_REG_RSP1 0x44
-#define OMAP_MMC_REG_RSP2 0x48
-#define OMAP_MMC_REG_RSP3 0x4c
-#define OMAP_MMC_REG_RSP4 0x50
-#define OMAP_MMC_REG_RSP5 0x54
-#define OMAP_MMC_REG_RSP6 0x58
-#define OMAP_MMC_REG_RSP7 0x5c
-#define OMAP_MMC_REG_IOSR 0x60
-#define OMAP_MMC_REG_SYSC 0x64
-#define OMAP_MMC_REG_SYSS 0x68
+#define OMAP_MMC_REG_ARGL 0x01
+#define OMAP_MMC_REG_ARGH 0x02
+#define OMAP_MMC_REG_CON0x03
+#define OMAP_MMC_REG_STAT 0x04
+#define OMAP_MMC_REG_IE 0x05
+#define OMAP_MMC_REG_CTO0x06
+#define OMAP_MMC_REG_DTO0x07
+#define OMAP_MMC_REG_DATA 0x08
+#define OMAP_MMC_REG_BLEN 0x09
+#define OMAP_MMC_REG_NBLK 0x0a
+#define OMAP_MMC_REG_BUF0x0b
+#define OMAP_MMC_REG_SDIO 0x0d
+#define OMAP_MMC_REG_REV0x0f
+#define OMAP_MMC_REG_RSP0 0x10
+#define OMAP_MMC_REG_RSP1 0x11
+#define OMAP_MMC_REG_RSP2 0x12
+#define OMAP_MMC_REG_RSP3 0x13
+#define OMAP_MMC_REG_RSP4 0x14
+#define OMAP_MMC_REG_RSP5 0x15
+#define OMAP_MMC_REG_RSP6 0x16
+#define OMAP_MMC_REG_RSP7 0x17
+#define OMAP_MMC_REG_IOSR 0x18
+#define OMAP_MMC_REG_SYSC 0x19
+#define OMAP_MMC_REG_SYSS 0x1a
#define OMAP_MMC_STAT_CARD_ERR (1 14)
#define OMAP_MMC_STAT_CARD_IRQ (1 13)
@@ -77,8 +77,9 @@
#define OMAP_MMC_STAT_CARD_BUSY (1 2)
#define OMAP_MMC_STAT_END_OF_CMD(1 0)
-#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG_##reg)
-#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
(host)-virt_base + OMAP_MMC_REG_##reg)
+#define OMAP_MMC_REG(host, reg) (OMAP_MMC_REG_##reg
(host)-reg_shift)
+#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG(host, reg))
+#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
(host)-virt_base + OMAP_MMC_REG(host, reg))
/*
* Command types
@@ -167,6 +168,8 @@ struct mmc_omap_host {
spinlock_t clk_lock; /* for changing enabled state */
unsigned intfclk_enabled:1;
+ unsignedreg_shift:2;
+
struct omap_mmc_platform_data *pdata;
};
@@ -679,9 +682,9 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
host-data-bytes_xfered += n;
if (write) {
- __raw_writesw(host-virt_base + OMAP_MMC_REG_DATA,
host-buffer, n);
+ __raw_writesw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
} else {
- __raw_readsw(host-virt_base + OMAP_MMC_REG_DATA, host-buffer,
n);
+ __raw_readsw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
}
}
@@ -899,7 +902,7 @@ mmc_omap_prepare_dma(struct mmc_omap_host *host, struct
mmc_data *data)
int dst_port = 0;
int sync_dev = 0;
- data_addr = host-phys_base + OMAP_MMC_REG_DATA;
+ data_addr = host-phys_base + OMAP_MMC_REG(host, DATA);
frame = data-blksz;
count = sg_dma_len(sg);
@@ -1490,6 +1493,8 @@ static int __init mmc_omap_probe(struct
Re: [PATCH] [OMAP1] use gen_nand
* Ladislav Michl ladislav.mi...@seznam.cz [091123 03:45]:
Since omapnand driver never find its way into mainline, switch to gen_nand
instead.
Following patch is compile tested only, but it is based on code I wrote for
NetStar board and runtime tested it there.
Nice patch, and totally the way to go!
Regards,
Tony
Signed-off-by: Ladislav Michl la...@linux-mips.org
Cc: Imre Deak imre.d...@nokia.com
Cc: Brian Swetland swetl...@google.com
Cc: Kevin Hilman k...@hilman.org
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c
index f4b72c1..8da8c64 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -30,7 +30,6 @@
#include mach/gpio.h
#include plat/mux.h
#include plat/fpga.h
-#include plat/nand.h
#include plat/keypad.h
#include plat/common.h
#include plat/board.h
@@ -167,8 +166,40 @@ static struct platform_device nor_device = {
.resource = nor_resource,
};
-static struct omap_nand_platform_data nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
+static void nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this-IO_ADDR_W | mask);
+}
+
+#define FSAMPLE_NAND_RB_GPIO_PIN 62
+
+static int nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(FSAMPLE_NAND_RB_GPIO_PIN);
+}
+
+static const char *part_probes[] = { cmdlinepart, NULL };
+
+static struct platform_nand_data nand_data = {
+ .chip = {
+ .nr_chips = 1,
+ .chip_offset= 0,
+ .options= NAND_SAMSUNG_LP_OPTIONS,
+ .part_probe_types = part_probes,
+ },
+ .ctrl = {
+ .cmd_ctrl = nand_cmd_ctl,
+ .dev_ready = nand_dev_ready,
+ },
};
static struct resource nand_resource = {
@@ -178,7 +209,7 @@ static struct resource nand_resource = {
};
static struct platform_device nand_device = {
- .name = omapnand,
+ .name = gen_nand,
.id = 0,
.dev= {
.platform_data = nand_data,
@@ -233,13 +264,6 @@ static struct platform_device *devices[] __initdata = {
lcd_device,
};
-#define P2_NAND_RB_GPIO_PIN 62
-
-static int nand_dev_ready(struct omap_nand_platform_data *data)
-{
- return gpio_get_value(P2_NAND_RB_GPIO_PIN);
-}
-
static struct omap_lcd_config fsample_lcd_config __initdata = {
.ctrl_name = internal,
};
@@ -250,9 +274,9 @@ static struct omap_board_config_kernel fsample_config[] =
{
static void __init omap_fsample_init(void)
{
- if (gpio_request(P2_NAND_RB_GPIO_PIN, NAND ready) 0)
+ if (gpio_request(FSAMPLE_NAND_RB_GPIO_PIN, NAND ready) 0)
BUG();
- nand_data.dev_ready = nand_dev_ready;
+ gpio_direction_input(FSAMPLE_NAND_RB_GPIO_PIN);
omap_cfg_reg(L3_1610_FLASH_CS2B_OE);
omap_cfg_reg(M8_1610_FLASH_CS2B_WE);
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 89ba8ec..283a6f2 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -40,7 +40,6 @@
#include plat/mux.h
#include plat/dma.h
#include plat/tc.h
-#include plat/nand.h
#include plat/irda.h
#include plat/usb.h
#include plat/keypad.h
@@ -179,11 +178,43 @@ static struct mtd_partition h2_nand_partitions[] = {
},
};
-/* dip switches control NAND chip access: 8 bit, 16 bit, or neither */
-static struct omap_nand_platform_data h2_nand_data = {
- .options= NAND_SAMSUNG_LP_OPTIONS,
- .parts = h2_nand_partitions,
- .nr_parts = ARRAY_SIZE(h2_nand_partitions),
+static void h2_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
+{
+ struct nand_chip *this = mtd-priv;
+ unsigned long mask;
+
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ mask = (ctrl NAND_CLE) ? 0x02 : 0;
+ if (ctrl NAND_ALE)
+ mask |= 0x04;
+ writeb(cmd, (unsigned long)this-IO_ADDR_W | mask);
+}
+
+#define H2_NAND_RB_GPIO_PIN 62
+
+static int h2_nand_dev_ready(struct mtd_info *mtd)
+{
+ return gpio_get_value(H2_NAND_RB_GPIO_PIN);
+}
+
+static const char *h2_part_probes[] = { cmdlinepart, NULL };
+
+struct platform_nand_data h2_nand_platdata = {
+ .chip = {
+ .nr_chips = 1,
+ .chip_offset= 0,
+ .nr_partitions = ARRAY_SIZE(h2_nand_partitions),
+ .partitions = h2_nand_partitions,
+ .options= NAND_SAMSUNG_LP_OPTIONS,
+
[PATCH 1/3] OMAP: omap_device: fix nsec/usec conversion in latency calculations
Use usecs = nsecs / NSEC_PER_USEC; instead of usecs = nsecs * NSEC_PER_USEC; Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/omap_device.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 288fd12..722f2c8 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -142,7 +142,7 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat) read_persistent_clock(b); c = timespec_sub(b, a); - act_lat = timespec_to_ns(c) * NSEC_PER_USEC; + act_lat = timespec_to_ns(c) / NSEC_PER_USEC; pr_debug(omap_device: %s: pm_lat %d: activate: elapsed time %llu usec\n, od-pdev.name, od-pm_lat_level, @@ -198,7 +198,7 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) read_persistent_clock(b); c = timespec_sub(b, a); - deact_lat = timespec_to_ns(c) * NSEC_PER_USEC; + deact_lat = timespec_to_ns(c) / NSEC_PER_USEC; pr_debug(omap_device: %s: pm_lat %d: deactivate: elapsed time %llu usec\n, od-pdev.name, od-pm_lat_level, -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] OMAP: omap_device: track latency in nanoseconds
Rather than having to do a usecs = nsecs / NSECS_PER_USEC to track latency in usecs, just track it in nanoseconds. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/plat/omap_device.h |4 ++-- arch/arm/plat-omap/omap_device.c |8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h index c504780..3b2f3a6 100644 --- a/arch/arm/plat-omap/include/plat/omap_device.h +++ b/arch/arm/plat-omap/include/plat/omap_device.h @@ -50,8 +50,8 @@ * @pm_lats: ptr to an omap_device_pm_latency table * @pm_lats_cnt: ARRAY_SIZE() of what is passed to @pm_lats * @pm_lat_level: array index of the last odpl entry executed - -1 if never - * @dev_wakeup_lat: dev wakeup latency in microseconds - * @_dev_wakeup_lat_limit: dev wakeup latency limit in usec - set by OMAP PM + * @dev_wakeup_lat: dev wakeup latency in nanoseconds + * @_dev_wakeup_lat_limit: dev wakeup latency limit in nsec - set by OMAP PM * @_state: one of OMAP_DEVICE_STATE_* (see above) * @flags: device flags * diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 722f2c8..7bf665c 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -142,10 +142,10 @@ static int _omap_device_activate(struct omap_device *od, u8 ignore_lat) read_persistent_clock(b); c = timespec_sub(b, a); - act_lat = timespec_to_ns(c) / NSEC_PER_USEC; + act_lat = timespec_to_ns(c); pr_debug(omap_device: %s: pm_lat %d: activate: elapsed time -%llu usec\n, od-pdev.name, od-pm_lat_level, +%llu nsec\n, od-pdev.name, od-pm_lat_level, act_lat); WARN(act_lat odpl-activate_lat, omap_device: %s.%d: @@ -198,10 +198,10 @@ static int _omap_device_deactivate(struct omap_device *od, u8 ignore_lat) read_persistent_clock(b); c = timespec_sub(b, a); - deact_lat = timespec_to_ns(c) / NSEC_PER_USEC; + deact_lat = timespec_to_ns(c); pr_debug(omap_device: %s: pm_lat %d: deactivate: elapsed time -%llu usec\n, od-pdev.name, od-pm_lat_level, +%llu nsec\n, od-pdev.name, od-pm_lat_level, deact_lat); WARN(deact_lat odpl-deactivate_lat, omap_device: %s.%d: -- 1.6.5.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies
First, this patch adds new worst-case latency values to the
omap_device_pm_latency struct. Here the worst-case measured latencies
for the activate and deactivate hooks are stored.
In addition, add an option to auto-adjust the latency values used for
device activate/deactivate.
By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the
omap_device_pm_latency struct, the omap_device layer automatically
adjusts the activate/deactivate latencies to the worst-case measured
values.
Anytime a new worst-case value is found, it is printed to the console.
Here is an example log during boot using UART2 s an example. After
boot, the OPP is manually changed to the 125MHz OPP:
[...]
Freeing init memory: 128K
omap_device: serial8250.2: new worst case deactivate latency 0: 30517
omap_device: serial8250.2: new worst case activate latency 0: 30517
omap_device: serial8250.2: new worst case activate latency 0: 218139648
omap_device: serial8250.2: new worst case deactivate latency 0: 61035
omap_device: serial8250.2: new worst case activate latency 0: 278076171
omap_device: serial8250.2: new worst case activate latency 0: 298614501
omap_device: serial8250.2: new worst case activate latency 0: 327331542
/ # echo 125000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
omap_device: serial8250.2: new worst case deactivate latency 0: 91552
Motivation: this can be used as a technique to automatically determine
the worst case latency values. The current method of printing a
warning on every violation is too noisy to actually interact the
console in order to set low OPP to discover latencies.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/omap_device.h |4 ++
arch/arm/plat-omap/omap_device.c | 41 -
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 3b2f3a6..e0634fe 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -132,11 +132,15 @@ int omap_device_enable_clocks(struct omap_device *od);
*/
struct omap_device_pm_latency {
u32 deactivate_lat;
+ u32 deactivate_lat_worst;
int (*deactivate_func)(struct omap_device *od);
u32 activate_lat;
+ u32 activate_lat_worst;
int (*activate_func)(struct omap_device *od);
+ u32 flags;
};
+#define OMAP_DEVICE_LATENCY_AUTO_ADJUST BIT(1)
/* Get omap_device pointer from platform_device pointer */
#define to_omap_device(x) container_of((x), struct omap_device, pdev)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7bf665c..8ba12a6 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -148,10 +148,22 @@ static int _omap_device_activate(struct omap_device *od,
u8 ignore_lat)
%llu nsec\n, od-pdev.name, od-pm_lat_level,
act_lat);
- WARN(act_lat odpl-activate_lat, omap_device: %s.%d:
-activate step %d took longer than expected (%llu %d)\n,
-od-pdev.name, od-pdev.id, od-pm_lat_level,
-act_lat, odpl-activate_lat);
+ if (act_lat odpl-activate_lat) {
+ odpl-activate_lat_worst = act_lat;
+ if (odpl-flags OMAP_DEVICE_LATENCY_AUTO_ADJUST) {
+ odpl-activate_lat = act_lat;
+ pr_warning(omap_device: %s.%d: new worst case
+ activate latency %d: %llu\n,
+ od-pdev.name, od-pdev.id,
+ od-pm_lat_level, act_lat);
+ } else
+ pr_warning(omap_device: %s.%d: activate
+ latency %d higher than exptected.
+ (%llu %d)\n,
+ od-pdev.name, od-pdev.id,
+ od-pm_lat_level, act_lat,
+ odpl-activate_lat);
+ }
od-dev_wakeup_lat -= odpl-activate_lat;
}
@@ -204,10 +216,23 @@ static int _omap_device_deactivate(struct omap_device
*od, u8 ignore_lat)
%llu nsec\n, od-pdev.name, od-pm_lat_level,
deact_lat);
- WARN(deact_lat odpl-deactivate_lat, omap_device: %s.%d:
-deactivate step %d took longer than expected
-(%llu %d)\n, od-pdev.name, od-pdev.id,
-od-pm_lat_level, deact_lat, odpl-deactivate_lat);
+ if (deact_lat odpl-deactivate_lat) {
+ odpl-deactivate_lat_worst = deact_lat;
+ if
Re: [PATCH 1/2] ARM: Implemented support for VFP PM context saving
* Tero Kristo tero.kri...@nokia.com [091119 07:12]:
From: Tero Kristo tero.kri...@nokia.com
In some ARM architectures, like OMAP3, the VFP context can be lost during
dynamic sleep cycle. For this purpose, there is now a function
vfp_pm_save_context() that should be called before the VFP is assumed to
lose context. Next VFP trap will then restore context automatically.
We need to have the last_VFP_context[cpu] cleared after the save in idle,
else the restore would fail to restore when it sees that the last_VFP_context
is same as the current threads vfp_state. This happens when the same
process/thread traps an exception post idle.
Main work for this patch was done by Peter and Rajendra. Some cleanup and
optimization by Tero.
This should go via the linux-arm-ker...@lists.infradead.org list.
We should probably merge them both via LAKML as they logically belong
toghether. Can you please resend, and also Cc linux-omap list?
For both, you can add Acked-by: Tony Lindgren t...@atomide.com
if you want to.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/vfp/vfpmodule.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2d7423a..80a08bd 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -329,6 +329,31 @@ static void vfp_enable(void *unused)
#ifdef CONFIG_PM
#include linux/sysdev.h
+void vfp_pm_save_context(void)
+{
+ struct thread_info *thread = current_thread_info();
+ u32 fpexc = fmrx(FPEXC);
+ __u32 cpu = thread-cpu;
+
+ if (last_VFP_context[cpu]) {
+ if (!(fpexc FPEXC_EN)) {
+ /* enable vfp now to save context */
+ vfp_enable(NULL);
+ fmxr(FPEXC, fmrx(FPEXC) | FPEXC_EN);
+ }
+ vfp_save_state(last_VFP_context[cpu], fpexc);
+
+ /* Disable vfp. The next inst traps an exception and restores*/
+ fmxr(FPEXC, fmrx(FPEXC) ~FPEXC_EN);
+
+ /*
+ * This is needed else the restore might fail if it sees
+ * last_VFP_context if same as the current threads vfp_state.
+ */
+ last_VFP_context[cpu] = NULL;
+ }
+}
+
static int vfp_pm_suspend(struct sys_device *dev, pm_message_t state)
{
struct thread_info *ti = current_thread_info();
--
1.5.4.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
--
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: DSS2 panel question
Hi,
One idea as below
struct spi_dss_device {
struct omap_dss_device dss_dev;
struct spi_dss_dev_priv * spi_data;
} spi_dss_dev;
spi_dss_probe.c
spi_probe(spi_device * spi)
{
spi_dss_dev. spi_data = spi;
omap_dss_register_device((spi_ device *) spi_dss_dev);
}
spi_dss_drv.c
spi_dss_drv_probe(omap_dss_device * dev)
{
my_spi_dss_dev = container_of(dev, struct spi_dss_device, dss_dev);
spi_data = my_spi_dss_dev;
}
- Hu Tao
On Mon, Nov 23, 2009 at 7:04 PM, Tomi Valkeinen
tomi.valkei...@nokia.com wrote:
On Sat, 2009-11-21 at 16:16 +0100, ext Grazvydas Ignotas wrote:
Hello,
I've been updating Pandora's panel for upstream-going DSS2, which now
uses device/device_driver model for panels. The thing is that the
panel we use is SPI controlled, so it needs to be set up as
spi_driver. From SPI probe function I can do
omap_dss_register_driver(), but how do I pass SPI data to
omap_dss_device cleanly? Surely some globals would help, but this is
not a clean way I guess. There used to be panel-n800.c with similar
requirements, but it's not yet converted, right? Do you have any ideas
how this can be done?
I don't have any good answer for this. For N900's panel there was a
static global variable, if I remember right. Not very clean, as you
said.
Tomi
--
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: [PATCH-v5 2/4] OMAP3: Add support for NAND on ZOOM2/LDP boards
* Vimal Singh vimal.neww...@gmail.com [091119 00:52]:
On Wed, Nov 18, 2009 at 10:37 PM, Tony Lindgren t...@atomide.com wrote:
* Vimal Singh vimal.neww...@gmail.com [091118 06:38]:
Tony,
On Fri, Nov 13, 2009 at 2:14 AM, Tony Lindgren t...@atomide.com wrote:
* Vimal Singh vimal.neww...@gmail.com [091110 02:08]:
From 6f535d7128ca392458dd0cb31d138cda84747c06 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 10 Nov 2009 11:42:45 +0530
Subject: [PATCH] OMAP3: Add support for NAND on ZOOM2/LDP boards
[...]
+static int omap_ldp_nand_unlock(struct mtd_info *mtd, loff_t ofs,
uint64_t len)
+{
+ int ret = 0;
+ int chipnr;
+ int status;
+ unsigned long page;
+ struct nand_chip *this = mtd-priv;
+ printk(KERN_INFO nand_unlock: start: %08x, length: %d!\n,
+ (int)ofs, (int)len);
+
+ /* select the NAND device */
+ chipnr = (int)(ofs this-chip_shift);
+ this-select_chip(mtd, chipnr);
+ /* check the WP bit */
+ this-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+ if ((this-read_byte(mtd) 0x80) == 0) {
+ printk(KERN_ERR nand_unlock: Device is write
protected!\n);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if ((ofs (mtd-writesize - 1)) != 0) {
+ printk(KERN_ERR nand_unlock: Start address must be
+ beginning of nand page!\n);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (len == 0 || (len (mtd-writesize - 1)) != 0) {
+ printk(KERN_ERR nand_unlock: Length must be a multiple
of
+ nand page size!\n);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /* submit address of first page to unlock */
+ page = (unsigned long)(ofs this-page_shift);
+ this-cmdfunc(mtd, NAND_CMD_UNLOCK1, -1, page this-pagemask);
+
+ /* submit ADDRESS of LAST page to unlock */
+ page += (unsigned long)((ofs + len) this-page_shift) ;
+ this-cmdfunc(mtd, NAND_CMD_UNLOCK2, -1, page this-pagemask);
+
+ /* call wait ready function */
+ status = this-waitfunc(mtd, this);
+ udelay(1000);
+ /* see if device thinks it succeeded */
+ if (status 0x01) {
+ /* there was an error */
+ printk(KERN_ERR nand_unlock: error status =0x%08x ,
status);
+ ret = -EIO;
+ goto out;
+ }
+
+ out:
+ /* de-select the NAND device */
+ this-select_chip(mtd, -1);
+ return ret;
+}
Isn't the unlocking generic to the NAND device driver? Or is it somehow
board
specific?
Yes, zoom2 boards come up with whole NAND locked, whereas it is not
case for SDP boards.
But the procedure should be done under drivers/mtd I believe using some
standard tools.
OK, I'll take this discussion to mtd mailing list. For now I'll remove
this from here.
OK, I'd assume there's some standard way to handle this for all NOR
drivers.
+static struct mtd_partition ldp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size
*/
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8
*/
+ .mask_flags = MTD_WRITEABLE, /* force
read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset =
0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB,
0x14 */
+ .mask_flags = MTD_WRITEABLE, /* force
read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset =
0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4
*/
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset =
0x020*/
+ .size = 240 * (64 * 2048), /* 30M, 0x1E0
*/
+ },
+#ifdef CONFIG_MACH_OMAP_ZOOM2
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset =
0x200 */
+ .size = 1280 * (64 * 2048), /* 160M,
0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset =
0xC00 */
+ .size = 256 * (64 * 2048), /* 32M, 0x200
*/
+ },
+ {
+ .name = cache,
+ .offset =
Re: [PATCH 1/3] Mux configuration for AM3517 TouchScreen support
* hvaib...@ti.com hvaib...@ti.com [091119 06:45]:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/mux.c |3 +++
arch/arm/plat-omap/include/plat/mux.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c18a94e..f64ce14 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -566,6 +566,9 @@ MUX_CFG_34XX(AF9_34XX_GPIO22, 0x5ec,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(U3_34XX_GPIO61, 0x0c8,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
+ /*Touch-screen*/
+ MUX_CFG_34XX(U1_34XX_GPIO65, 0x0d2,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/plat/mux.h
b/arch/arm/plat-omap/include/plat/mux.h
index ba77de6..244afee 100644
--- a/arch/arm/plat-omap/include/plat/mux.h
+++ b/arch/arm/plat-omap/include/plat/mux.h
@@ -854,6 +854,7 @@ enum omap34xx_index {
AH14_34XX_GPIO21,
AF9_34XX_GPIO22,
U3_34XX_GPIO61,
+ U1_34XX_GPIO65,
};
struct omap_mux_cfg {
Let's put this on hold until we have the new mux framework
up and running. This should not stop getting in the driver
patch integrated.
Regards,
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
Re: [PATCH 3/3] AM3517: Add support for TSC2004 driver
Hi,
* hvaib...@ti.com hvaib...@ti.com [091119 06:46]:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 415a13d..ae47b51 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,8 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/gpio.h
+#include linux/irq.h
+#include linux/i2c/tsc2004.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -27,10 +29,64 @@
#include asm/mach/map.h
#include plat/board.h
+#include plat/mux.h
#include plat/common.h
#include plat/usb.h
/*
+ * TSC 2004 Support
+ */
+#define GPIO_TSC2004_IRQ65
+
+static int tsc2004_init_irq(void)
+{
+ int ret = 0;
+
+ ret = gpio_request(GPIO_TSC2004_IRQ, tsc2004-irq);
+ if (ret 0) {
+ printk(KERN_WARNING failed to request GPIO#%d: %d\n,
+ GPIO_TSC2004_IRQ, ret);
+ return ret;
+ }
+
+ if (gpio_direction_input(GPIO_TSC2004_IRQ)) {
+ printk(KERN_WARNING GPIO#%d cannot be configured as
+ input\n, GPIO_TSC2004_IRQ);
+ return -ENXIO;
+ }
+
+ omap_set_gpio_debounce(GPIO_TSC2004_IRQ, 1);
+ omap_set_gpio_debounce_time(GPIO_TSC2004_IRQ, 0xa);
+ return ret;
+}
+
+static void tsc2004_exit_irq(void)
+{
+ gpio_free(GPIO_TSC2004_IRQ);
+}
+
+static int tsc2004_get_irq_level(void)
+{
+ return gpio_get_value(GPIO_TSC2004_IRQ) ? 0 : 1;
+}
+
+struct tsc2004_platform_data am3517evm_tsc2004data = {
+ .model = 2004,
+ .x_plate_ohms = 180,
+ .get_pendown_state = tsc2004_get_irq_level,
+ .init_platform_hw = tsc2004_init_irq,
+ .exit_platform_hw = tsc2004_exit_irq,
+};
+
+static struct i2c_board_info __initdata am3517evm_tsc_i2c_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(tsc2004, 0x4B),
+ .type = tsc2004,
+ .platform_data = am3517evm_tsc2004data,
+ },
+};
+
+/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[] __initdata = {
@@ -67,6 +123,12 @@ static void __init am3517_evm_init(void)
omap_serial_init();
usb_ehci_init(ehci_pdata);
+
+ /* TSC 2004 */
+ omap_cfg_reg(U1_34XX_GPIO65);
+ am3517evm_tsc_i2c_boardinfo[0].irq = gpio_to_irq(GPIO_TSC2004_IRQ);
+ i2c_register_board_info(1, am3517evm_tsc_i2c_boardinfo,
+ ARRAY_SIZE(am3517evm_tsc_i2c_boardinfo));
}
static void __init am3517_evm_map_io(void)
Can you please leave out the omap_cfg_reg call for new mux registers
from this patch? This way it will still compile and we can patch
in the muxing later on.
Regards,
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
Re: [PATCH] USB: twl4030: Enable USB regulators before enabling USB charging
* Aguilar Pena, Leed leed.agui...@ti.com [091119 10:34]: For TWL family of power management ICs, USB charging works only when USB regulators are in enabled state: 3v1, 1v5, 1v8 On a USB cable attach, twl4030_phy_resume(twl) function enables the regulators. Enable USB charging, only after all regulators are enabled. Its observed that enabling USB charging before regulators are enabled, causes USB charging to fail. Tested on: Zoom2: omap3430: ES3.1 + TWL5030 Needs T2-MADC and T2-BCI drivers which are still not upstreamed. This should go to linux-usb list with linux-omap list Cc'd. Regards, Tony Signed-off-by: Moiz Sonasath m-sonas...@ti.com Signed-off-by: Leed Aguilar leed.agui...@ti.com Acked-by: Vikram Pandita vikram.pand...@ti.com Acked-by: Anand Gadiyar gadi...@ti.com Acked-by: Nishanth Menon n...@ti.com --- drivers/usb/otg/twl4030-usb.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c index 9e3e7a5..bd9883f 100644 --- a/drivers/usb/otg/twl4030-usb.c +++ b/drivers/usb/otg/twl4030-usb.c @@ -598,12 +598,12 @@ static irqreturn_t twl4030_usb_irq(int irq, void *_twl) * USB_LINK_VBUS state. musb_hdrc won't care until it * starts to handle softconnect right. */ - twl4030charger_usb_en(status == USB_LINK_VBUS); - if (status == USB_LINK_NONE) twl4030_phy_suspend(twl, 0); else twl4030_phy_resume(twl); + + twl4030charger_usb_en(status == USB_LINK_VBUS); } sysfs_notify(twl-dev-kobj, NULL, vbus); -- 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/2] [RESEND] Amstrad Delta: add support for LCD contrast
Initialy submitted on 2009-11-16 (http://www.spinics.net/lists/linux-omap/msg20629.html). Resendig due to fbdev mailing list address changed. The series consists of 2 patches: [PATCH 1/2] omapfb: lcd_ams_delta: add support for contrast control [PATCH 2/2] OMAP: ams_delta_defconfig: enable LCD class device support It is intended for 2.6.33, if it's not too late. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omapfb: lcd_ams_delta: add support for contrast control
The patch extends the Amstrad Delta LCD panel driver with optional support for
changing contrast using standard LCD class device API instead of setting it
silently to a default value at panel enable. It also allows for lowering power
consumption by turning off OMAP_PWL_CLK_ENABLE via lcd_ops.set_power callback.
Created and tested against linux-omap for-next,
commit 155a75d9725e66e5ec8a383822957dee52427057.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
--- a/drivers/video/omap/lcd_ams_delta.c2009-11-14 23:49:16.0
+0100
+++ b/drivers/video/omap/lcd_ams_delta.c2009-11-16 01:32:19.0
+0100
@@ -24,6 +24,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/delay.h
+#include linux/lcd.h
#include plat/board-ams-delta.h
#include mach/hardware.h
@@ -31,6 +32,71 @@
#define AMS_DELTA_DEFAULT_CONTRAST 112
+#define AMS_DELTA_MAX_CONTRAST 0x00FF
+#define AMS_DELTA_LCD_POWER0x0100
+
+
+/* LCD class device section */
+
+static int ams_delta_lcd;
+
+static int ams_delta_lcd_set_power(struct lcd_device *dev, int power)
+{
+ if (power == FB_BLANK_UNBLANK) {
+ if (!(ams_delta_lcd AMS_DELTA_LCD_POWER)) {
+ omap_writeb(ams_delta_lcd AMS_DELTA_MAX_CONTRAST,
+ OMAP_PWL_ENABLE);
+ omap_writeb(1, OMAP_PWL_CLK_ENABLE);
+ ams_delta_lcd |= AMS_DELTA_LCD_POWER;
+ }
+ } else {
+ if (ams_delta_lcd AMS_DELTA_LCD_POWER) {
+ omap_writeb(0, OMAP_PWL_ENABLE);
+ omap_writeb(0, OMAP_PWL_CLK_ENABLE);
+ ams_delta_lcd = ~AMS_DELTA_LCD_POWER;
+ }
+ }
+ return 0;
+}
+
+static int ams_delta_lcd_set_contrast(struct lcd_device *dev, int value)
+{
+ if ((value = 0) (value = AMS_DELTA_MAX_CONTRAST)) {
+ omap_writeb(value, OMAP_PWL_ENABLE);
+ ams_delta_lcd = ~AMS_DELTA_MAX_CONTRAST;
+ ams_delta_lcd |= value;
+ }
+ return 0;
+}
+
+#ifdef CONFIG_LCD_CLASS_DEVICE
+static int ams_delta_lcd_get_power(struct lcd_device *dev)
+{
+ if (ams_delta_lcd AMS_DELTA_LCD_POWER)
+ return FB_BLANK_UNBLANK;
+ else
+ return FB_BLANK_POWERDOWN;
+}
+
+static int ams_delta_lcd_get_contrast(struct lcd_device *dev)
+{
+ if (!(ams_delta_lcd AMS_DELTA_LCD_POWER))
+ return 0;
+
+ return ams_delta_lcd AMS_DELTA_MAX_CONTRAST;
+}
+
+static struct lcd_ops ams_delta_lcd_ops = {
+ .get_power = ams_delta_lcd_get_power,
+ .set_power = ams_delta_lcd_set_power,
+ .get_contrast = ams_delta_lcd_get_contrast,
+ .set_contrast = ams_delta_lcd_set_contrast,
+};
+#endif
+
+
+/* omapfb panel section */
+
static int ams_delta_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
{
@@ -47,10 +113,6 @@ static int ams_delta_panel_enable(struct
AMS_DELTA_LATCH2_LCD_NDISP);
ams_delta_latch2_write(AMS_DELTA_LATCH2_LCD_VBLEN,
AMS_DELTA_LATCH2_LCD_VBLEN);
-
- omap_writeb(1, OMAP_PWL_CLK_ENABLE);
- omap_writeb(AMS_DELTA_DEFAULT_CONTRAST, OMAP_PWL_ENABLE);
-
return 0;
}
@@ -90,8 +152,31 @@ static struct lcd_panel ams_delta_panel
.get_caps = ams_delta_panel_get_caps,
};
+
+/* platform driver section */
+
static int ams_delta_panel_probe(struct platform_device *pdev)
{
+ struct lcd_device *lcd_device = NULL;
+#ifdef CONFIG_LCD_CLASS_DEVICE
+ int ret;
+
+ lcd_device = lcd_device_register(omapfb, pdev-dev, NULL,
+ ams_delta_lcd_ops);
+
+ if (IS_ERR(lcd_device)) {
+ ret = PTR_ERR(lcd_device);
+ dev_err(pdev-dev, failed to register device\n);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, lcd_device);
+ lcd_device-props.max_contrast = AMS_DELTA_MAX_CONTRAST;
+#endif
+
+ ams_delta_lcd_set_contrast(lcd_device, AMS_DELTA_DEFAULT_CONTRAST);
+ ams_delta_lcd_set_power(lcd_device, FB_BLANK_UNBLANK);
+
omapfb_register_panel(ams_delta_panel);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP: ams_delta_defconfig: enable LCD class device support
The patch enables LCD class device support in ams_delta_defconfig in order to get optional contrast control functional. Created and tested against linux-omap for-next, commit 155a75d9725e66e5ec8a383822957dee52427057. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- --- a/arch/arm/configs/ams_delta_defconfig 2009-11-14 23:48:40.0 +0100 +++ b/arch/arm/configs/ams_delta_defconfig 2009-11-16 01:06:12.0 +0100 @@ -836,7 +836,8 @@ # # Graphics support # -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y # # Display device support -- 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 v4] mmc-omap: Add support for 16-bit and 32-bit registers
On Mon, Nov 23, 2009 at 08:23:59AM -0800, Cory Maccarrone wrote:
The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
a modification of the register addresses in the mmc-omap driver. To resolve
this, a bit shift is performed on base register addresses, either by 1 or 2
bits depending on the CPU in use. This yields the correct registers for
each CPU.
[...]
@@ -167,6 +168,8 @@ struct mmc_omap_host {
spinlock_t clk_lock; /* for changing enabled state */
unsigned intfclk_enabled:1;
+ unsignedreg_shift:2;
Ah, there is no valid reason to make it bitfield, right? Whole struct is
not well layed wtr alignment, but please do not make it any worse. That is
my last complain, I swear ;-). Thank you for your patience.
Other than that, tested on OMAP5910 and it works now (though it needs
additional patch, see here:
http://thread.gmane.org/gmane.linux.kernel.mmc/649).
Tested-by: Ladislav Michl la...@linux-mips.org
Best regards,
ladis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] USB: twl4030: Enable USB regulators before enabling USB charging
Tony Lindgren wrote: * Aguilar Pena, Leed leed.agui...@ti.com [091119 10:34]: For TWL family of power management ICs, USB charging works only when USB regulators are in enabled state: 3v1, 1v5, 1v8 On a USB cable attach, twl4030_phy_resume(twl) function enables the regulators. Enable USB charging, only after all regulators are enabled. Its observed that enabling USB charging before regulators are enabled, causes USB charging to fail. Tested on: Zoom2: omap3430: ES3.1 + TWL5030 Needs T2-MADC and T2-BCI drivers which are still not upstreamed. This should go to linux-usb list with linux-omap list Cc'd. It's already in greg's queue. - 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 0/4] AM3517: MMC: Add support for HSMMC
This patch series adds support for HSMMC for AM3517 platform. It also enables the HSMMC driver in the AM3517 defconfig. Anuj Aggarwal (4): AM3517: MMC: Add low-level init code for HSMMC controller AM3517: MMC: Modifying board-evm file to add mmc_init AM3517: MMC: Modifying Makefile to enable MMC init AM3517: MMC: Make HSMMC driver built-in arch/arm/configs/am3517_evm_defconfig | 21 +++- arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/board-am3517evm.c | 22 +++ arch/arm/mach-omap2/mmc-am3517evm.c | 267 + arch/arm/mach-omap2/mmc-am3517evm.h | 22 +++ 5 files changed, 333 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.c create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] AM3517: MMC: Modifying Makefile to enable MMC init
Modifying Makefile to build mmc-am3517.c for AM3517 platform, this file has the mmc_init function for 3517 EVM. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/mach-omap2/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 59b0ccc..77ec48b 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -93,7 +93,8 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \ obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o -obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o +obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o \ + mmc-am3517evm.o # Platform specific device init code obj-y += usb-musb.o -- 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 2/4] AM3517: MMC: Modifying board-evm file to add mmc_init
Modifying the board-evm file for AM3517 and adding the mmc_init
function in it.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 415a13d..30f8b00 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,6 +30,7 @@
#include plat/common.h
#include plat/usb.h
+#include mmc-am3517evm.h
/*
* Board initialization
*/
@@ -60,6 +61,24 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initdata = {
.reset_gpio_port[2] = -EINVAL
};
+static struct am3517_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ .wires = 4,
+ /* TODO: Need to change */
+ .gpio_cd= 127,
+ .gpio_wp= 126,
+ },
+ {
+ .mmc= 2,
+ .wires = 4,
+ /* TODO: Need to change */
+ .gpio_cd= 128,
+ .gpio_wp= 129,
+ },
+ {} /* Terminator */
+};
+
static void __init am3517_evm_init(void)
{
platform_add_devices(am3517_evm_devices,
@@ -67,6 +86,9 @@ static void __init am3517_evm_init(void)
omap_serial_init();
usb_ehci_init(ehci_pdata);
+
+ /* MMC init function */
+ am3517_mmc_init(mmc);
}
static void __init am3517_evm_map_io(void)
--
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 4/4] AM3517: MMC: Make HSMMC driver built-in
Make HSMMC driver as a built-in module for AM3517 platform. Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com --- arch/arm/configs/am3517_evm_defconfig | 21 - 1 files changed, 20 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index ad54e92..601f1f5 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -818,7 +818,26 @@ CONFIG_USB_STORAGE=y # # CONFIG_USB_GPIO_VBUS is not set # CONFIG_NOP_USB_XCEIV is not set -# CONFIG_MMC is not set +CONFIG_MMC=y +# CONFIG_MMC_DEBUG is not set +# CONFIG_MMC_UNSAFE_RESUME is not set + +# +# MMC/SD/SDIO Card Drivers +# +CONFIG_MMC_BLOCK=y +CONFIG_MMC_BLOCK_BOUNCE=y +# CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set + +# +# MMC/SD/SDIO Host Controller Drivers +# +# CONFIG_MMC_SDHCI is not set +# CONFIG_MMC_OMAP is not set +CONFIG_MMC_OMAP_HS=y +# CONFIG_MMC_AT91 is not set +# CONFIG_MMC_ATMELMCI is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set -- 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 1/4] AM3517: MMC: Add low-level init code for HSMMC controller
Add init code for HSMMC controller for AM3517 platform.
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
arch/arm/mach-omap2/mmc-am3517evm.c | 267 +++
arch/arm/mach-omap2/mmc-am3517evm.h | 22 +++
2 files changed, 289 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.c
create mode 100644 arch/arm/mach-omap2/mmc-am3517evm.h
diff --git a/arch/arm/mach-omap2/mmc-am3517evm.c
b/arch/arm/mach-omap2/mmc-am3517evm.c
new file mode 100644
index 000..7995239
--- /dev/null
+++ b/arch/arm/mach-omap2/mmc-am3517evm.c
@@ -0,0 +1,267 @@
+/*
+ * linux/arch/arm/mach-omap2/mmc-am3517evm.c
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ * Author: Anuj Aggarwal anuj.aggar...@ti.com
+ *
+ * Based on mach-omap2/mmc-twl4030.c
+ *
+ * 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/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/gpio.h
+
+#include mach/hardware.h
+#include plat/control.h
+#include plat/mmc.h
+#include plat/board.h
+#include mmc-am3517evm.h
+
+#define LDO_CLR0x00
+#define VSEL_S2_CLR0x40
+
+#define VMMC1_DEV_GRP 0x27
+#define VMMC1_CLR 0x00
+#define VMMC1_315V 0x03
+#define VMMC1_300V 0x02
+#define VMMC1_285V 0x01
+#define VMMC1_185V 0x00
+#define VMMC1_DEDICATED0x2A
+
+#define VMMC2_DEV_GRP 0x2B
+#define VMMC2_CLR 0x40
+#define VMMC2_315V 0x0c
+#define VMMC2_300V 0x0b
+#define VMMC2_285V 0x0a
+#define VMMC2_260V 0x08
+#define VMMC2_185V 0x06
+#define VMMC2_DEDICATED0x2E
+
+#define VMMC_DEV_GRP_P10x20
+
+#define HSMMC_NAME_LEN 9
+
+#if defined(CONFIG_REGULATOR) || \
+ (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
+defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
+
+/*
+ * MMC definitions
+ *
+ */
+static struct mmc_controller {
+ struct omap_mmc_platform_data *mmc;
+ u8 vmmc_dev_grp;
+ u8 vmmc_dedicated;
+ charname[HSMMC_NAME_LEN];
+} hsmmc[] = {
+ {
+ .vmmc_dev_grp = VMMC1_DEV_GRP,
+ .vmmc_dedicated = VMMC1_DEDICATED,
+ },
+ {
+ .vmmc_dev_grp = VMMC2_DEV_GRP,
+ .vmmc_dedicated = VMMC2_DEDICATED,
+ },
+};
+
+static int mmc_card_detect(int irq)
+{
+ unsigned i;
+
+ for (i = 0; i ARRAY_SIZE(hsmmc); i++) {
+ struct omap_mmc_platform_data *mmc;
+
+ mmc = hsmmc[i].mmc;
+ if (!mmc)
+ continue;
+ if (irq != mmc-slots[0].card_detect_irq)
+ continue;
+
+ /* NOTE: assumes card detect signal is active-low */
+ return !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
+ }
+ return -ENOSYS;
+}
+
+static int mmc_get_ro(struct device *dev, int slot)
+{
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+
+ /* NOTE: assumes write protect signal is active-high */
+ return gpio_get_value_cansleep(mmc-slots[0].gpio_wp);
+}
+
+/*
+ * MMC Slot Initialization.
+ */
+static int mmc_late_init(struct device *dev)
+{
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+ int ret = 0;
+ int i;
+
+ ret = gpio_request(mmc-slots[0].switch_pin, mmc_cd);
+ if (ret)
+ goto done;
+ ret = gpio_direction_input(mmc-slots[0].switch_pin);
+ if (ret)
+ goto err;
+
+ for (i = 0; i ARRAY_SIZE(hsmmc); i++) {
+ if (hsmmc[i].name == mmc-slots[0].name) {
+ hsmmc[i].mmc = mmc;
+ break;
+ }
+ }
+
+ return 0;
+
+err:
+ gpio_free(mmc-slots[0].switch_pin);
+done:
+ mmc-slots[0].card_detect_irq = 0;
+ mmc-slots[0].card_detect = NULL;
+
+ dev_err(dev, err %d configuring card detect\n, ret);
+ return ret;
+}
+
+static void mmc_cleanup(struct device *dev)
+{
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+
+ gpio_free(mmc-slots[0].switch_pin);
+}
+
+#ifdef CONFIG_PM
+
+static int mmc_suspend(struct device *dev, int slot)
+{
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+
+ disable_irq(mmc-slots[0].card_detect_irq);
+ return 0;
+}
+
+static int mmc_resume(struct device *dev, int slot)
+{
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+
+ enable_irq(mmc-slots[0].card_detect_irq);
+ return 0;
+}
+
+#else
Re: [PATCH 3/3] OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies
Kevin Hilman wrote: First, this patch adds new worst-case latency values to the omap_device_pm_latency struct. Here the worst-case measured latencies for the activate and deactivate hooks are stored. In addition, add an option to auto-adjust the latency values used for device activate/deactivate. By setting a new 'OMAP_DEVICE_LATENCY_AUTO_ADJUST' flag in the omap_device_pm_latency struct, the omap_device layer automatically adjusts the activate/deactivate latencies to the worst-case measured values. Anytime a new worst-case value is found, it is printed to the console. Here is an example log during boot using UART2 s an example. After boot, the OPP is manually changed to the 125MHz OPP: [...] Freeing init memory: 128K omap_device: serial8250.2: new worst case deactivate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 30517 omap_device: serial8250.2: new worst case activate latency 0: 218139648 omap_device: serial8250.2: new worst case deactivate latency 0: 61035 omap_device: serial8250.2: new worst case activate latency 0: 278076171 omap_device: serial8250.2: new worst case activate latency 0: 298614501 omap_device: serial8250.2: new worst case activate latency 0: 327331542 / # echo 125000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed omap_device: serial8250.2: new worst case deactivate latency 0: 91552 Motivation: this can be used as a technique to automatically determine the worst case latency values. The current method of printing a warning on every violation is too noisy to actually interact the console in order to set low OPP to discover latencies. Another motivation for this patch is that the activate/deactivate latenices can vary depending on the idlemode of the device. While working on the UART I noticed that when using no-idle, the activate latencies were as high as several hundred msecs as shown above. When the UARTs are in smart-idle, the max latency is well under 100 usecs. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mmc-omap: Add support for 16-bit and 32-bit registers
On Mon, Nov 23, 2009 at 11:12 AM, Ladislav Michl ladislav.mi...@seznam.cz wrote: Ah, there is no valid reason to make it bitfield, right? Whole struct is not well layed wtr alignment, but please do not make it any worse. That is my last complain, I swear ;-). Thank you for your patience. Other than that, tested on OMAP5910 and it works now (though it needs additional patch, see here: http://thread.gmane.org/gmane.linux.kernel.mmc/649). Tested-by: Ladislav Michl la...@linux-mips.org Heh, fair enough :) Thanks for your patience too -- I'll convert it to an unsigned int and resubmit. Hopefully 5th time's the charm. :) Glad to hear it's working with that patch too, that adds some confidence to my changes. Thanks - Cory -- 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 v5] mmc-omap: Add support for 16-bit and 32-bit registers
The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
a modification of the register addresses in the mmc-omap driver. To resolve
this, a bit shift is performed on base register addresses, either by 1 or 2
bits depending on the CPU in use. This yields the correct registers for
each CPU.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
drivers/mmc/host/omap.c | 62 +--
1 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5f970e2..f10339a 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -38,30 +38,30 @@
#include plat/fpga.h
#defineOMAP_MMC_REG_CMD0x00
-#defineOMAP_MMC_REG_ARGL 0x04
-#defineOMAP_MMC_REG_ARGH 0x08
-#defineOMAP_MMC_REG_CON0x0c
-#defineOMAP_MMC_REG_STAT 0x10
-#defineOMAP_MMC_REG_IE 0x14
-#defineOMAP_MMC_REG_CTO0x18
-#defineOMAP_MMC_REG_DTO0x1c
-#defineOMAP_MMC_REG_DATA 0x20
-#defineOMAP_MMC_REG_BLEN 0x24
-#defineOMAP_MMC_REG_NBLK 0x28
-#defineOMAP_MMC_REG_BUF0x2c
-#define OMAP_MMC_REG_SDIO 0x34
-#defineOMAP_MMC_REG_REV0x3c
-#defineOMAP_MMC_REG_RSP0 0x40
-#defineOMAP_MMC_REG_RSP1 0x44
-#defineOMAP_MMC_REG_RSP2 0x48
-#defineOMAP_MMC_REG_RSP3 0x4c
-#defineOMAP_MMC_REG_RSP4 0x50
-#defineOMAP_MMC_REG_RSP5 0x54
-#defineOMAP_MMC_REG_RSP6 0x58
-#defineOMAP_MMC_REG_RSP7 0x5c
-#defineOMAP_MMC_REG_IOSR 0x60
-#defineOMAP_MMC_REG_SYSC 0x64
-#defineOMAP_MMC_REG_SYSS 0x68
+#defineOMAP_MMC_REG_ARGL 0x01
+#defineOMAP_MMC_REG_ARGH 0x02
+#defineOMAP_MMC_REG_CON0x03
+#defineOMAP_MMC_REG_STAT 0x04
+#defineOMAP_MMC_REG_IE 0x05
+#defineOMAP_MMC_REG_CTO0x06
+#defineOMAP_MMC_REG_DTO0x07
+#defineOMAP_MMC_REG_DATA 0x08
+#defineOMAP_MMC_REG_BLEN 0x09
+#defineOMAP_MMC_REG_NBLK 0x0a
+#defineOMAP_MMC_REG_BUF0x0b
+#defineOMAP_MMC_REG_SDIO 0x0d
+#defineOMAP_MMC_REG_REV0x0f
+#defineOMAP_MMC_REG_RSP0 0x10
+#defineOMAP_MMC_REG_RSP1 0x11
+#defineOMAP_MMC_REG_RSP2 0x12
+#defineOMAP_MMC_REG_RSP3 0x13
+#defineOMAP_MMC_REG_RSP4 0x14
+#defineOMAP_MMC_REG_RSP5 0x15
+#defineOMAP_MMC_REG_RSP6 0x16
+#defineOMAP_MMC_REG_RSP7 0x17
+#defineOMAP_MMC_REG_IOSR 0x18
+#defineOMAP_MMC_REG_SYSC 0x19
+#defineOMAP_MMC_REG_SYSS 0x1a
#defineOMAP_MMC_STAT_CARD_ERR (1 14)
#defineOMAP_MMC_STAT_CARD_IRQ (1 13)
@@ -77,8 +77,9 @@
#defineOMAP_MMC_STAT_CARD_BUSY (1 2)
#defineOMAP_MMC_STAT_END_OF_CMD(1 0)
-#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG_##reg)
-#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val), (host)-virt_base +
OMAP_MMC_REG_##reg)
+#define OMAP_MMC_REG(host, reg)(OMAP_MMC_REG_##reg
(host)-reg_shift)
+#define OMAP_MMC_READ(host, reg) __raw_readw((host)-virt_base +
OMAP_MMC_REG(host, reg))
+#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val), (host)-virt_base +
OMAP_MMC_REG(host, reg))
/*
* Command types
@@ -132,6 +133,7 @@ struct mmc_omap_host {
int irq;
unsigned char bus_mode;
unsigned char hw_bus_mode;
+ unsigned intreg_shift;
struct work_struct cmd_abort_work;
unsignedabort:1;
@@ -679,9 +681,9 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
host-data-bytes_xfered += n;
if (write) {
- __raw_writesw(host-virt_base + OMAP_MMC_REG_DATA,
host-buffer, n);
+ __raw_writesw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
} else {
- __raw_readsw(host-virt_base + OMAP_MMC_REG_DATA, host-buffer,
n);
+ __raw_readsw(host-virt_base + OMAP_MMC_REG(host, DATA),
host-buffer, n);
}
}
@@ -899,7 +901,7 @@ mmc_omap_prepare_dma(struct mmc_omap_host *host, struct
mmc_data *data)
int dst_port = 0;
int sync_dev = 0;
- data_addr = host-phys_base + OMAP_MMC_REG_DATA;
+ data_addr = host-phys_base + OMAP_MMC_REG(host, DATA);
frame = data-blksz;
count = sg_dma_len(sg);
@@ -1490,6 +1492,8 @@ static int __init mmc_omap_probe(struct platform_device
*pdev)
}
}
+ host-reg_shift =
Re: NULL pointer dereference with 2.6.31 on OMAP243
Thank you very much for the assistance, that seemed to fix the problem. ~Chris On Sun, Nov 22, 2009 at 9:55 AM, Tony Lindgren t...@atomide.com wrote: Hi, Added linux-omap list and Paul to Cc. * Chris Banker cban...@gmail.com [091119 12:34]: I'm having trouble with the 2.6.31 kernel running on an OMAP2430 board. I was able to get the board to boot using 2.6.31rc1, but am having some issue with 2.6.31. With low-level debugging enabled, I get the output below. It appears to be an issue with the new hwmod system, which didn't exist in 2.6.31rc1. It seems to die during the initialization of mpu_hwmod. Anyone have any suggestions as to how to fix this or what to try? Good to hear somebody is playing with a 2430 :) What's the board you're using? I guess it is not an SDP based on the crystal rate at 19.2MHz? We had a similar issue with 2420, that got fixed by a7f20b2695eb6a00a5464089bacf75b8ed64725e. Maybe give it a try and see if it helps? I've attached Paul's patch too for reference. Regards, Tony Thanks, Chris -- Starting kernel ... Uncompressing Linux. done, booting the kernel. 5Linux version 2.6.31-omap1 (cban...@vcaeng05) (gcc version 4.3.3 (GCC) ) #27 Wed Nov 18 17:23:18 PST 2009 CPU: ARMv6-compatible processor [4107b366] revision 6 (ARMv6TEJ), cr=00c5387f CPU: VIPT aliasing data cache, VIPT aliasing instruction cache Machine: BFT Digital Modem Memory policy: ECC disabled, Data cache writeback 7On node 0 totalpages: 32768 7free_area_init_node: node 0, pgdat c0f10848, node_mem_map c0f35000 7 Normal zone: 256 pages used for memmap 7 Normal zone: 0 pages reserved 7 Normal zone: 32512 pages, LIFO batch:7 6OMAP24306 6SRAM: Mapped pa 0x4020 to va 0xe300 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 5Kernel command line: root=/dev/ram0 rw console=ttys2,115200n8 PID hash table entries: 512 (order: 9, 2048 bytes) 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) 6Memory: 128MB = 128MB total 5Memory: 114232KB available (3084K code, 327K data, 12124K init, 0K highmem) 6NR_IRQS:384 6Clocking rate (Crystal/DPLL/MPU): 19.2/660/330 MHz 1Unable to handle kernel NULL pointer dereference at virtual address 0004 1pgd = c0004000 1[0004] *pgd= Internal error: Oops: 5 [#1] dModules linked in: CPU: 0 Not tainted (2.6.31-omap1 #27) PC is at _enable+0x78/0x208 LR is at release_console_sem+0x1a8/0x204 pc : [c0be9098] lr : [c0bff998] psr: a1d3 sp : c0ee3f38 ip : c0ee3e80 fp : c0ee3f4c r10: 80022140 r9 : 4107b366 r8 : 80022174 r7 : c0ee86b4 r6 : c0be95cc r5 : c0ee6154 r4 : c0ee6154 r3 : r2 : r1 : 05b2 r0 : 001f Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 80004000 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc0ee2260) Stack: (0xc0ee3f38 to 0xc0ee4000) 3f20: c0ee6634 c0ee6154 3f40: c0ee3f68 c0ee3f50 c0be9648 c0be902c c0ee6154 c0be95cc c0ee3f88 3f60: c0ee3f6c c0be8a6c c0be95d8 c0eece48 c0eece48 c0bdbe08 c0ee5b34 c0ee3f98 3f80: c0ee3f8c c0be98f4 c0be8a44 c0ee3fb0 c0ee3f9c c000dfc4 c0be98a0 c0f11190 3fa0: c0f11184 c0ee3fc0 c0ee3fb4 c000ef0c c000df50 c0ee3fd0 c0ee3fc4 c000b878 3fc0: c000eee8 c0ee3ff4 c0ee3fd4 c0008a2c c000b84c c0008658 c0bdbe08 00c5387d 3fe0: c0f11440 c0bdc20c c0ee3ff8 80008034 c00088fc Backtrace: [c0be9020] (_enable+0x0/0x208) from [c0be9648] (_setup+0x7c/0xb0) r4:c0ee6154 [c0be95cc] (_setup+0x0/0xb0) from [c0be8a6c] (omap_hwmod_for_each+0x34/0x78) r6:c0be95cc r5:c0ee6154 r4: [c0be8a38] (omap_hwmod_for_each+0x0/0x78) from [c0be98f4] (omap_hwmod_late_init+0x60/0x8c) r7:c0ee5b34 r6:c0bdbe08 r5:c0eece48 r4:c0eece48 [c0be9894] (omap_hwmod_late_init+0x0/0x8c) from [c000dfc4] (omap2_init_common_hw+0x80/0xbc) [c000df44] (omap2_init_common_hw+0x0/0xbc) from [c000ef0c] (omap2430bft_init_irq+0x30/0x1c4) r5:c0f11184 r4:c0f11190 [c000eedc] (omap2430bft_init_irq+0x0/0x1c4) from [c000b878] (init_IRQ+0x38/0x44) [c000b840] (init_IRQ+0x0/0x44) from [c0008a2c] (start_kernel+0x13c/0x2ac) [c00088f0] (start_kernel+0x0/0x2ac) from [80008034] (0x80008034)
[PATCH] DSPBRIDGE: Interface tightening to check for invalid
From f28ec22e48a9b61ac00b7711e035e117bdc71aeb Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Mon, 23 Nov 2009 12:16:45 -0600
Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid inputs.
Move the error checking to kernel to address usecases
accessing kernel API directly.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
arch/arm/plat-omap/include/dspbridge/dbdefs.h |3 +-
drivers/dsp/bridge/pmgr/wcd.c | 263 +++--
drivers/dsp/bridge/rmgr/proc.c| 42
3 files changed, 249 insertions(+), 59 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dbdefs.h
b/arch/arm/plat-omap/include/dspbridge/dbdefs.h
index 3570171..2de5ab6 100644
--- a/arch/arm/plat-omap/include/dspbridge/dbdefs.h
+++ b/arch/arm/plat-omap/include/dspbridge/dbdefs.h
@@ -217,7 +217,8 @@
DSP_DCDLIBRARYTYPE,
DSP_DCDCREATELIBTYPE,
DSP_DCDEXECUTELIBTYPE,
- DSP_DCDDELETELIBTYPE
+ DSP_DCDDELETELIBTYPE,
+ DSP_MAXOBJTYPE = DSP_DCDDELETELIBTYPE
} ;
/* Processor states */
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 306164f..30cae21 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -268,6 +268,41 @@ static inline void __cp_to_usr(void __user *to, const void
*from,
}
}
+/* Check if the given area blongs to process virtul memory address space */
+static int memory_check_vma(void *start_addr, u32 len)
+{
+ int err = 0;
+ u32 end;
+ u32 start = (u32)start_addr;
+ struct vm_area_struct *vma;
+
+ end = start + len;
+ if (end = start)
+ return -EINVAL;
+
+ down_read(current-mm-mmap_sem);
+
+ while ((vma = find_vma(current-mm, start)) != NULL) {
+
+ if (vma-vm_start start) {
+ err = -EINVAL;
+ break;
+ }
+
+ if (end = vma-vm_end)
+ break;
+
+ start = vma-vm_end;
+ }
+
+ if (!vma)
+ err = -EINVAL;
+
+ up_read(current-mm-mmap_sem);
+
+ return err;
+}
+
/*
* WCD_CallDevIOCtl
* Purpose:
@@ -470,7 +505,7 @@ u32 MGRWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
u8 *pNDBProps;
u32 uNumNodes;
DSP_STATUS status = DSP_SOK;
- u32 size = args-ARGS_MGR_ENUMNODE_INFO.uNDBPropsSize;
+ u32 size;
GT_4trace(WCD_debugMask, GT_ENTER,
MGR_EnumNodeInfo: entered args:\n0x%x
@@ -479,6 +514,20 @@ u32 MGRWRAP_EnumNode_Info(union Trapped_Args *args, void
*pr_ctxt)
args-ARGS_MGR_ENUMNODE_INFO.pNDBProps,
args-ARGS_MGR_ENUMNODE_INFO.uNDBPropsSize,
args-ARGS_MGR_ENUMNODE_INFO.puNumNodes);
+
+ if (memory_check_vma(args-ARGS_MGR_ENUMNODE_INFO.pNDBProps,
+ sizeof(struct DSP_NDBPROPS)))
+ return DSP_EPOINTER;
+
+ if (memory_check_vma(args-ARGS_MGR_ENUMNODE_INFO.puNumNodes,
+ sizeof(u32)))
+ return DSP_EPOINTER;
+
+ size = args-ARGS_MGR_ENUMNODE_INFO.uNDBPropsSize;
+
+ if (size sizeof(struct DSP_NDBPROPS))
+ return DSP_ESIZE;
+
pNDBProps = MEM_Alloc(size, MEM_NONPAGED);
if (pNDBProps == NULL)
status = DSP_EMEMORY;
@@ -506,7 +555,7 @@ u32 MGRWRAP_EnumProc_Info(union Trapped_Args *args, void
*pr_ctxt)
u8 *pProcessorInfo;
u32 uNumProcs;
DSP_STATUS status = DSP_SOK;
- u32 size = args-ARGS_MGR_ENUMPROC_INFO.uProcessorInfoSize;
+ u32 size;
GT_4trace(WCD_debugMask, GT_ENTER,
MGRWRAP_EnumProc_Info: entered args:\n
@@ -516,6 +565,20 @@ u32 MGRWRAP_EnumProc_Info(union Trapped_Args *args, void
*pr_ctxt)
args-ARGS_MGR_ENUMPROC_INFO.pProcessorInfo,
args-ARGS_MGR_ENUMPROC_INFO.uProcessorInfoSize,
args-ARGS_MGR_ENUMPROC_INFO.puNumProcs);
+
+ if (memory_check_vma(args-ARGS_MGR_ENUMPROC_INFO.pProcessorInfo,
+ sizeof(struct DSP_PROCESSORINFO)))
+ return DSP_EPOINTER;
+
+ if (memory_check_vma(args-ARGS_MGR_ENUMPROC_INFO.puNumProcs,
+ sizeof(u32)))
+ return DSP_EPOINTER;
+
+ size = args-ARGS_MGR_ENUMPROC_INFO.uProcessorInfoSize;
+
+ if (size sizeof(struct DSP_PROCESSORINFO))
+ return DSP_ESIZE;
+
pProcessorInfo = MEM_Alloc(size, MEM_NONPAGED);
if (pProcessorInfo == NULL)
status = DSP_EMEMORY;
@@ -548,6 +611,11 @@ u32 MGRWRAP_RegisterObject(union Trapped_Args *args, void
*pr_ctxt)
char *pszPathName = NULL;
DSP_STATUS status = DSP_SOK;
+
+ GT_1trace(WCD_debugMask, GT_ENTER,
+MGRWRAP_RegisterObject: entered
+0x%x\n,
Re: [RFC][PATCH] ARM: OMAP: McBSP: Use register cache
(drop all except Tony, Jarkko and linux-omap)
Saturday 14 November 2009 03:06:39 Janusz Krzysztofik napisał(a):
Hi,
This patch got outdated and does not apply any more, but the idea still
hangs in my queue. I am not sure why the patch has never been acknowledged
nor rejected. Maybe it just got missed?
Tony,
I have just found this patch, initially submitted on 2009-08-12, archived in
linux-omap patchwork with State: Awaiting Upstream. What does it mean? Am I
supposed to do something about it? After that many weeks of no negative
comments nor requests for changes, and taking into account what Jarkko said
lately in a different thread[*] about the McBSP register cache concept, can I
assume that it has been generally accepted? Is it worth of refreshing against
current linux-omap?
Thanks,
Janusz
Could you please take a position on this idea?
Thanks,
Janusz
http://www.spinics.net/lists/linux-omap/msg16720.html
[*] http://www.spinics.net/lists/linux-omap/msg20597.html
Wednesday 12 August 2009 12:39:25 Janusz Krzysztofik wrote:
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta (buggy?)
hardware. Before that, I could suspect that values read back from McBSP
registers before updating them happened to be errornous.
I think there is one important point that makes this patch worth of
applying, apart from my hardware quality. With the current code, if it
ever happens to any machine, no matter if OMAP1510 or newer, to read
incorrect value from a McBSP register, this wrong value will get written
back without any checking. That can lead to hardware damage if, for
example, an input pin is turned into output as a result.
Created against linux-2.6.31-rc5
Tested on Amstrad Delta
Signed-off-by: Janusz Krzysztofik
---
---
linux-2.6.31-rc5/arch/arm/plat-omap/include/mach/mcbsp.h.orig
2009-08-11
23:43:25.0 +0200 +++
linux-2.6.31-rc5/arch/arm/plat-omap/include/mach/mcbsp.h2009-08-11
23:45:46.0 +0200 @@ -377,6 +377,8 @@ struct omap_mcbsp {
struct omap_mcbsp_platform_data *pdata;
struct clk *iclk;
struct clk *fclk;
+
+ struct omap_mcbsp_reg_cfg reg_cache;
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
--- linux-2.6.31-rc5/arch/arm/plat-omap/mcbsp.c.orig2009-08-11
23:43:25.0 +0200 +++
linux-2.6.31-rc5/arch/arm/plat-omap/mcbsp.c 2009-08-11 23:45:35.0
+0200 @@ -91,6 +91,7 @@ static void omap_mcbsp_dump_reg(u8 id)
static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_tx = dev_id;
+ struct omap_mcbsp_reg_cfg *reg_cache = mcbsp_tx-reg_cache;
u16 irqst_spcr2;
irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx-io_base, SPCR2);
@@ -101,7 +102,7 @@ static irqreturn_t omap_mcbsp_tx_irq_han
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
OMAP_MCBSP_WRITE(mcbsp_tx-io_base, SPCR2,
- irqst_spcr2 ~(XSYNC_ERR));
+ reg_cache-spcr2 = ~(XSYNC_ERR));
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -112,6 +113,7 @@ static irqreturn_t omap_mcbsp_tx_irq_han
static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_rx = dev_id;
+ struct omap_mcbsp_reg_cfg *reg_cache = mcbsp_rx-reg_cache;
u16 irqst_spcr1;
irqst_spcr1 = OMAP_MCBSP_READ(mcbsp_rx-io_base, SPCR1);
@@ -122,7 +124,7 @@ static irqreturn_t omap_mcbsp_rx_irq_han
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
OMAP_MCBSP_WRITE(mcbsp_rx-io_base, SPCR1,
- irqst_spcr1 ~(RSYNC_ERR));
+ reg_cache-spcr1 = ~(RSYNC_ERR));
} else {
complete(mcbsp_rx-tx_irq_completion);
}
@@ -167,6 +169,7 @@ static void omap_mcbsp_rx_dma_callback(i
void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg
*config) {
struct omap_mcbsp *mcbsp;
+ struct omap_mcbsp_reg_cfg *reg_cache;
void __iomem *io_base;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -174,26 +177,27 @@ void omap_mcbsp_config(unsigned int id,
return;
}
mcbsp = id_to_mcbsp_ptr(id);
+ reg_cache = mcbsp-reg_cache;
io_base = mcbsp-io_base;
dev_dbg(mcbsp-dev, Configuring McBSP%d phys_base: 0x%08lx\n,
mcbsp-id, mcbsp-phys_base);
/* We write the given config */
- OMAP_MCBSP_WRITE(io_base, SPCR2, config-spcr2);
- OMAP_MCBSP_WRITE(io_base, SPCR1, config-spcr1);
- OMAP_MCBSP_WRITE(io_base, RCR2, config-rcr2);
- OMAP_MCBSP_WRITE(io_base, RCR1, config-rcr1);
-
PATCH] DSPBRIDGE: NULL Pointer Dereference fix
From f51da1af78be289c9b101154c16e615d135c62c2 Mon Sep 17 00:00:00 2001
From: Ernesto Ramos erne...@ti.com
Date: Wed, 18 Nov 2009 16:03:42 -0600
Subject: [PATCH] DSPBRIDGE: NULL Pointer Dereference fix
This patch takes care of the possible null pointers dereferenced within dsp
bridge driver.
Signed-off-by: Ernesto Ramos erne...@ti.com
---
drivers/dsp/bridge/rmgr/nldr.c |3 ++-
drivers/dsp/bridge/rmgr/node.c |6 +++---
drivers/dsp/bridge/rmgr/proc.c |9 -
drivers/dsp/bridge/wmd/chnl_sm.c |2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/nldr.c b/drivers/dsp/bridge/rmgr/nldr.c
index 24eb9c6..e977a94 100644
--- a/drivers/dsp/bridge/rmgr/nldr.c
+++ b/drivers/dsp/bridge/rmgr/nldr.c
@@ -1007,7 +1007,8 @@ DSP_STATUS NLDR_Unload(struct NLDR_NODEOBJECT *hNldrNode,
enum NLDR_PHASE phase)
/* Unload main library */
pRootLib = hNldrNode-root;
}
- UnloadLib(hNldrNode, pRootLib);
+ if (pRootLib)
+ UnloadLib(hNldrNode, pRootLib);
} else {
if (hNldrNode-fOverlay)
UnloadOvly(hNldrNode, phase);
diff --git a/drivers/dsp/bridge/rmgr/node.c b/drivers/dsp/bridge/rmgr/node.c
index 9127751..3f3934c 100644
--- a/drivers/dsp/bridge/rmgr/node.c
+++ b/drivers/dsp/bridge/rmgr/node.c
@@ -906,7 +906,7 @@ DSP_STATUS NODE_ChangePriority(struct NODE_OBJECT *hNode,
s32 nPriority)
GT_2trace(NODE_debugMask, GT_ENTER, NODE_ChangePriority:
hNode: 0x%x\tnPriority: %d\n, hNode, nPriority);
- if (!MEM_IsValidHandle(hNode, NODE_SIGNATURE)) {
+ if (!MEM_IsValidHandle(hNode, NODE_SIGNATURE) || !hNode-hNodeMgr) {
GT_1trace(NODE_debugMask, GT_7CLASS,
Invalid NODE Handle: 0x%x\n, hNode);
status = DSP_EHANDLE;
@@ -2612,7 +2612,7 @@ DSP_STATUS NODE_Terminate(struct NODE_OBJECT *hNode, OUT
DSP_STATUS *pStatus)
GT_1trace(NODE_debugMask, GT_ENTER,
NODE_Terminate: hNode: 0x%x\n, hNode);
- if (!MEM_IsValidHandle(hNode, NODE_SIGNATURE)) {
+ if (!MEM_IsValidHandle(hNode, NODE_SIGNATURE) || !hNode-hNodeMgr) {
status = DSP_EHANDLE;
goto func_end;
}
@@ -3329,7 +3329,7 @@ DSP_STATUS NODE_GetUUIDProps(DSP_HPROCESSOR hProcessor,
pNodeId, pNodeProps);
status = PROC_GetDevObject(hProcessor, hDevObject);
- if (DSP_SUCCEEDED(status) hDevObject != NULL) {
+ if (hDevObject != NULL) {
status = DEV_GetNodeManager(hDevObject, hNodeMgr);
if (hNodeMgr == NULL) {
status = DSP_EHANDLE;
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index bf89ad0..7b3317f 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -580,12 +580,11 @@ DSP_STATUS PROC_Detach(struct PROCESS_CONTEXT *pr_ctxt)
DSP_STATUS status = DSP_SOK;
struct PROC_OBJECT *pProcObject = NULL;
- if (pr_ctxt pr_ctxt-hProcessor)
- pProcObject = (struct PROC_OBJECT *)pr_ctxt-hProcessor;
-
DBC_Require(cRefs 0);
- GT_1trace(PROC_DebugMask, GT_ENTER, Entered PROC_Detach, args:\n\t
- pr_ctxt-phProcessor: 0x%x\n, *pProcObject);
+ GT_0trace(PROC_DebugMask, GT_ENTER, Entered PROC_Detach\n);
+
+ if (pr_ctxt)
+ pProcObject = (struct PROC_OBJECT *)pr_ctxt-hProcessor;
if (MEM_IsValidHandle(pProcObject, PROC_SIGNATURE)) {
/* Notify the Client */
diff --git a/drivers/dsp/bridge/wmd/chnl_sm.c b/drivers/dsp/bridge/wmd/chnl_sm.c
index f0bd986..7c1d7f7 100644
--- a/drivers/dsp/bridge/wmd/chnl_sm.c
+++ b/drivers/dsp/bridge/wmd/chnl_sm.c
@@ -326,7 +326,7 @@ DSP_STATUS WMD_CHNL_CancelIO(struct CHNL_OBJECT *hChnl)
struct CHNL_MGR *pChnlMgr = NULL;
/* Check args: */
- if (MEM_IsValidHandle(pChnl, CHNL_SIGNATURE)) {
+ if (MEM_IsValidHandle(pChnl, CHNL_SIGNATURE) pChnl-pChnlMgr) {
iChnl = pChnl-uId;
uMode = pChnl-uMode;
pChnlMgr = pChnl-pChnlMgr;
--
1.5.4.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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
Olof Johansson o...@lixom.net writes: On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote: I have not seen any comments on this patch series yet. Tony, Is there something I need to modify? Or it can be unstreamed now? Oh, and by the way, serial drivers are preferrably merged through Greg K-H (gre...@suse.de). So Cc him on the next revision of the patch. FWIW, I had asked Govindraj to not post more broadly until we get some sort of better consensus/design around this driver. I don't think we're quite there yet. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
VFP save context is called before MPU/NEON off. Restore is not needed as
the next VFP trap will restore context automatically. Uses the support
routine implemented in arch/arm/vfp/vfpmodule.c.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Looks good. I'll queue in PM branch when patch 1/2 is reviewed/accepted on
LAKML.
Kevin
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 21 -
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4f22107..dd5bbaf 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -18,6 +18,7 @@ extern u32 sleep_while_idle;
extern u32 voltage_off_while_idle;
extern void *omap3_secure_ram_storage;
+extern void vfp_pm_save_context(void);
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b26ae5b..4b01303 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -321,6 +321,18 @@ static void restore_control_register(u32 val)
__asm__ __volatile__ (mcr p15, 0, %0, c1, c0, 0 : : r (val));
}
+static inline void omap3_save_neon_context(void)
+{
+#ifdef CONFIG_VFP
+ vfp_pm_save_context();
+#endif
+}
+
+static inline void omap3_restore_neon_context(void)
+{
+ return;
+}
+
/* Function to restore the table entry that was modified for enabling MMU */
static void restore_table_entry(void)
{
@@ -365,6 +377,7 @@ void omap_sram_idle(void)
/* save_state = 3 = L1, L2 and logic lost */
int save_state = 0;
int mpu_next_state = PWRDM_POWER_ON;
+ int neon_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
@@ -398,8 +411,12 @@ void omap_sram_idle(void)
pwrdm_pre_transition();
/* NEON control */
- if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
+ if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON) {
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ neon_next_state = mpu_next_state;
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_save_neon_context();
+ }
/* PER */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
@@ -537,6 +554,8 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_restore_neon_context();
pwrdm_post_transition();
}
--
1.5.4.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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] ARM: OMAP: McBSP: Use register cache
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091123 12:42]:
(drop all except Tony, Jarkko and linux-omap)
Saturday 14 November 2009 03:06:39 Janusz Krzysztofik napisał(a):
Hi,
This patch got outdated and does not apply any more, but the idea still
hangs in my queue. I am not sure why the patch has never been acknowledged
nor rejected. Maybe it just got missed?
Tony,
I have just found this patch, initially submitted on 2009-08-12, archived in
linux-omap patchwork with State: Awaiting Upstream. What does it mean? Am I
supposed to do something about it? After that many weeks of no negative
comments nor requests for changes, and taking into account what Jarkko said
lately in a different thread[*] about the McBSP register cache concept, can I
assume that it has been generally accepted? Is it worth of refreshing against
current linux-omap?
I'll just mark patches Awaiting upstream if I feel like somebody else
should ack or merge it. If there are obvious changes needed, I'll mark
it Changes requested.
So for the patch, please refresh. Then let's apply it assuming Jarkko
acks it.
Regards,
Tony
Thanks,
Janusz
Could you please take a position on this idea?
Thanks,
Janusz
http://www.spinics.net/lists/linux-omap/msg16720.html
[*] http://www.spinics.net/lists/linux-omap/msg20597.html
Wednesday 12 August 2009 12:39:25 Janusz Krzysztofik wrote:
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta (buggy?)
hardware. Before that, I could suspect that values read back from McBSP
registers before updating them happened to be errornous.
I think there is one important point that makes this patch worth of
applying, apart from my hardware quality. With the current code, if it
ever happens to any machine, no matter if OMAP1510 or newer, to read
incorrect value from a McBSP register, this wrong value will get written
back without any checking. That can lead to hardware damage if, for
example, an input pin is turned into output as a result.
Created against linux-2.6.31-rc5
Tested on Amstrad Delta
Signed-off-by: Janusz Krzysztofik
---
---
linux-2.6.31-rc5/arch/arm/plat-omap/include/mach/mcbsp.h.orig
2009-08-11
23:43:25.0 +0200 +++
linux-2.6.31-rc5/arch/arm/plat-omap/include/mach/mcbsp.h 2009-08-11
23:45:46.0 +0200 @@ -377,6 +377,8 @@ struct omap_mcbsp {
struct omap_mcbsp_platform_data *pdata;
struct clk *iclk;
struct clk *fclk;
+
+ struct omap_mcbsp_reg_cfg reg_cache;
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
--- linux-2.6.31-rc5/arch/arm/plat-omap/mcbsp.c.orig 2009-08-11
23:43:25.0 +0200 +++
linux-2.6.31-rc5/arch/arm/plat-omap/mcbsp.c 2009-08-11
23:45:35.0
+0200 @@ -91,6 +91,7 @@ static void omap_mcbsp_dump_reg(u8 id)
static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_tx = dev_id;
+ struct omap_mcbsp_reg_cfg *reg_cache = mcbsp_tx-reg_cache;
u16 irqst_spcr2;
irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx-io_base, SPCR2);
@@ -101,7 +102,7 @@ static irqreturn_t omap_mcbsp_tx_irq_han
irqst_spcr2);
/* Writing zero to XSYNC_ERR clears the IRQ */
OMAP_MCBSP_WRITE(mcbsp_tx-io_base, SPCR2,
- irqst_spcr2 ~(XSYNC_ERR));
+ reg_cache-spcr2 = ~(XSYNC_ERR));
} else {
complete(mcbsp_tx-tx_irq_completion);
}
@@ -112,6 +113,7 @@ static irqreturn_t omap_mcbsp_tx_irq_han
static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_rx = dev_id;
+ struct omap_mcbsp_reg_cfg *reg_cache = mcbsp_rx-reg_cache;
u16 irqst_spcr1;
irqst_spcr1 = OMAP_MCBSP_READ(mcbsp_rx-io_base, SPCR1);
@@ -122,7 +124,7 @@ static irqreturn_t omap_mcbsp_rx_irq_han
irqst_spcr1);
/* Writing zero to RSYNC_ERR clears the IRQ */
OMAP_MCBSP_WRITE(mcbsp_rx-io_base, SPCR1,
- irqst_spcr1 ~(RSYNC_ERR));
+ reg_cache-spcr1 = ~(RSYNC_ERR));
} else {
complete(mcbsp_rx-tx_irq_completion);
}
@@ -167,6 +169,7 @@ static void omap_mcbsp_rx_dma_callback(i
void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg
*config) {
struct omap_mcbsp *mcbsp;
+ struct omap_mcbsp_reg_cfg *reg_cache;
void __iomem *io_base;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -174,26 +177,27 @@ void omap_mcbsp_config(unsigned int id,
return;
}
mcbsp = id_to_mcbsp_ptr(id);
+ reg_cache = mcbsp-reg_cache;
io_base = mcbsp-io_base;
[PATCH 8/9] DSPBRIDGE: Remove DPC module from SERVICES layer
This patch removes init and exit functions for DPC module.
It also deletes dpc source file and takes out the module from
Makefile.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/dpc.h | 26 ---
drivers/dsp/bridge/Makefile|3 +-
drivers/dsp/bridge/services/dpc.c | 68
drivers/dsp/bridge/services/services.c |9 +---
4 files changed, 3 insertions(+), 103 deletions(-)
delete mode 100644 drivers/dsp/bridge/services/dpc.c
diff --git a/arch/arm/plat-omap/include/dspbridge/dpc.h
b/arch/arm/plat-omap/include/dspbridge/dpc.h
index b22140f..aee910d 100644
--- a/arch/arm/plat-omap/include/dspbridge/dpc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dpc.h
@@ -35,30 +35,4 @@ struct DPC_OBJECT {
spinlock_t dpc_lock;
};
-/*
- * DPC_Exit
- * Purpose:
- * Discontinue usage of the DPC module.
- * Parameters:
- * Returns:
- * Requires:
- * DPC_Init(void) was previously called.
- * Ensures:
- * Resources acquired in DPC_Init(void) are freed.
- */
- extern void DPC_Exit(void);
-
-/*
- * DPC_Init
- * Purpose:
- * Initialize the DPC module's private state.
- * Parameters:
- * Returns:
- * TRUE if initialized; FALSE if error occured.
- * Requires:
- * Ensures:
- * A requirement for each of the other public DPC functions.
- */
- extern bool DPC_Init(void);
-
#endif /* DPC_ */
diff --git a/drivers/dsp/bridge/Makefile b/drivers/dsp/bridge/Makefile
index cb6d1ce..df870c9 100644
--- a/drivers/dsp/bridge/Makefile
+++ b/drivers/dsp/bridge/Makefile
@@ -1,8 +1,7 @@
obj-$(CONFIG_MPU_BRIDGE) += bridgedriver.o
libgen = gen/gb.o gen/gt.o gen/gs.o gen/gh.o gen/_gt_para.o gen/uuidutil.o
-libservices = services/mem.o services/list.o services/dpc.o \
- services/sync.o \
+libservices = services/mem.o services/list.o services/sync.o \
services/clk.o services/cfg.o services/reg.o \
services/regsup.o services/ntfy.o \
services/dbg.o services/services.o
diff --git a/drivers/dsp/bridge/services/dpc.c
b/drivers/dsp/bridge/services/dpc.c
deleted file mode 100644
index bbb2d47..000
--- a/drivers/dsp/bridge/services/dpc.c
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * dpc.c
- *
- * DSP-BIOS Bridge driver support functions for TI OMAP processors.
- *
- * Deferred Procedure Call(DPC) Services.
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- *
- * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- */
-
-/* --- Host OS */
-#include dspbridge/host_os.h
-
-/* --- DSP/BIOS Bridge */
-#include dspbridge/std.h
-#include dspbridge/dbdefs.h
-#include dspbridge/errbase.h
-
-/* --- Trace Debug */
-#include dspbridge/dbc.h
-#include dspbridge/gt.h
-
-/* --- OS Adaptation Layer */
-#include dspbridge/mem.h
-
-/* --- This */
-#include dspbridge/dpc.h
-
-/* --- Defines, Data Structures, Typedefs */
-#define SIGNATURE 0x5f435044 /* DPC_ (in reverse). */
-
-/* --- Globals */
-#if GT_TRACE
-static struct GT_Mask DPC_DebugMask = { NULL, NULL }; /* DPC Debug Mask */
-#endif
-
-/*
- * DPC_Exit
- * Purpose:
- * Discontinue usage of the DPC module.
- */
-void DPC_Exit(void)
-{
- GT_0trace(DPC_DebugMask, GT_5CLASS, Entered DPC_Exit\n);
-}
-
-/*
- * DPC_Init
- * Purpose:
- * Initialize the DPC module's private state.
- */
-bool DPC_Init(void)
-{
- GT_create(DPC_DebugMask, DP);
-
- GT_0trace(DPC_DebugMask, GT_5CLASS, Entered DPC_Init\n);
-
- return true;
-}
-
diff --git a/drivers/dsp/bridge/services/services.c
b/drivers/dsp/bridge/services/services.c
index dc9bfad..0b7d623 100644
--- a/drivers/dsp/bridge/services/services.c
+++ b/drivers/dsp/bridge/services/services.c
@@ -68,7 +68,6 @@ void SERVICES_Exit(void)
CLK_Exit();
REG_Exit();
LST_Exit();
- DPC_Exit();
DBG_Exit();
CFG_Exit();
MEM_Exit();
@@ -87,7 +86,7 @@ void SERVICES_Exit(void)
bool SERVICES_Init(void)
{
bool fInit = true;
- bool fCFG, fDBG, fDPC, fLST, fMEM;
+ bool fCFG, fDBG, fLST, fMEM;
bool fREG, fSYNC, fCLK, fNTFY;
DBC_Require(cRefs = 0);
@@ -106,12 +105,11 @@ bool SERVICES_Init(void)
[PATCH 4/9] DSPBRIDGE: Use _IOxx macro to define ioctls
Use standard convention to define ioctls.
Currently 'DB' is used as identifier for dspbridge.
*** NOTE: An update in api ioctl definitions is required. ***
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/wcdioctl.h | 142 ++-
drivers/dsp/bridge/pmgr/wcd.c | 116 +--
2 files changed, 117 insertions(+), 141 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
index 397361c..8aaa1ec 100644
--- a/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
+++ b/arch/arm/plat-omap/include/dspbridge/wcdioctl.h
@@ -391,83 +391,67 @@ union Trapped_Args {
} ARGS_UTIL_TESTDLL;
} ;
-#define CMD_BASE 101
-
-/* MGR module offsets */
-#define CMD_MGR_BASE_OFFSET CMD_BASE
-#define CMD_MGR_ENUMNODE_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 0)
-#define CMD_MGR_ENUMPROC_INFO_OFFSET(CMD_MGR_BASE_OFFSET + 1)
-#define CMD_MGR_REGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 2)
-#define CMD_MGR_UNREGISTEROBJECT_OFFSET (CMD_MGR_BASE_OFFSET + 3)
-#define CMD_MGR_WAIT_OFFSET (CMD_MGR_BASE_OFFSET + 4)
-
-#ifndef RES_CLEANUP_DISABLE
-#define CMD_MGR_RESOUCES_OFFSET (CMD_MGR_BASE_OFFSET + 5)
-#define CMD_MGR_END_OFFSET CMD_MGR_RESOUCES_OFFSET
-#else
-#define CMD_MGR_END_OFFSET CMD_MGR_WAIT_OFFSET
-#endif
-
-#define CMD_PROC_BASE_OFFSET (CMD_MGR_END_OFFSET + 1)
-#define CMD_PROC_ATTACH_OFFSET (CMD_PROC_BASE_OFFSET + 0)
-#define CMD_PROC_CTRL_OFFSET (CMD_PROC_BASE_OFFSET + 1)
-#define CMD_PROC_DETACH_OFFSET (CMD_PROC_BASE_OFFSET + 2)
-#define CMD_PROC_ENUMNODE_OFFSET (CMD_PROC_BASE_OFFSET + 3)
-#define CMD_PROC_ENUMRESOURCES_OFFSET (CMD_PROC_BASE_OFFSET + 4)
-#define CMD_PROC_GETSTATE_OFFSET (CMD_PROC_BASE_OFFSET + 5)
-#define CMD_PROC_GETTRACE_OFFSET (CMD_PROC_BASE_OFFSET + 6)
-#define CMD_PROC_LOAD_OFFSET (CMD_PROC_BASE_OFFSET + 7)
-#define CMD_PROC_REGISTERNOTIFY_OFFSET (CMD_PROC_BASE_OFFSET + 8)
-#define CMD_PROC_START_OFFSET (CMD_PROC_BASE_OFFSET + 9)
-#define CMD_PROC_RSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 10)
-#define CMD_PROC_UNRSVMEM_OFFSET (CMD_PROC_BASE_OFFSET + 11)
-#define CMD_PROC_MAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 12)
-#define CMD_PROC_UNMAPMEM_OFFSET (CMD_PROC_BASE_OFFSET + 13)
-#define CMD_PROC_FLUSHMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 14)
-#define CMD_PROC_STOP_OFFSET (CMD_PROC_BASE_OFFSET + 15)
-#define CMD_PROC_INVALIDATEMEMORY_OFFSET (CMD_PROC_BASE_OFFSET + 16)
-#define CMD_PROC_END_OFFSET CMD_PROC_INVALIDATEMEMORY_OFFSET
-
-
-#define CMD_NODE_BASE_OFFSET (CMD_PROC_END_OFFSET + 1)
-#define CMD_NODE_ALLOCATE_OFFSET (CMD_NODE_BASE_OFFSET + 0)
-#define CMD_NODE_ALLOCMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 1)
-#define CMD_NODE_CHANGEPRIORITY_OFFSET (CMD_NODE_BASE_OFFSET + 2)
-#define CMD_NODE_CONNECT_OFFSET (CMD_NODE_BASE_OFFSET + 3)
-#define CMD_NODE_CREATE_OFFSET (CMD_NODE_BASE_OFFSET + 4)
-#define CMD_NODE_DELETE_OFFSET (CMD_NODE_BASE_OFFSET + 5)
-#define CMD_NODE_FREEMSGBUF_OFFSET (CMD_NODE_BASE_OFFSET + 6)
-#define CMD_NODE_GETATTR_OFFSET (CMD_NODE_BASE_OFFSET + 7)
-#define CMD_NODE_GETMESSAGE_OFFSET (CMD_NODE_BASE_OFFSET + 8)
-#define CMD_NODE_PAUSE_OFFSET (CMD_NODE_BASE_OFFSET + 9)
-#define CMD_NODE_PUTMESSAGE_OFFSET (CMD_NODE_BASE_OFFSET + 10)
-#define CMD_NODE_REGISTERNOTIFY_OFFSET (CMD_NODE_BASE_OFFSET + 11)
-#define CMD_NODE_RUN_OFFSET (CMD_NODE_BASE_OFFSET + 12)
-#define CMD_NODE_TERMINATE_OFFSET (CMD_NODE_BASE_OFFSET + 13)
-#define CMD_NODE_GETUUIDPROPS_OFFSET(CMD_NODE_BASE_OFFSET + 14)
-#define CMD_NODE_END_OFFSET CMD_NODE_GETUUIDPROPS_OFFSET
-
-#define CMD_STRM_BASE_OFFSET (CMD_NODE_END_OFFSET + 1)
-#define CMD_STRM_ALLOCATEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 0)
-#define CMD_STRM_CLOSE_OFFSET (CMD_STRM_BASE_OFFSET + 1)
-#define CMD_STRM_FREEBUFFER_OFFSET (CMD_STRM_BASE_OFFSET + 2)
-#define CMD_STRM_GETEVENTHANDLE_OFFSET (CMD_STRM_BASE_OFFSET + 3)
-#define CMD_STRM_GETINFO_OFFSET (CMD_STRM_BASE_OFFSET + 4)
-#define CMD_STRM_IDLE_OFFSET (CMD_STRM_BASE_OFFSET + 5)
-#define CMD_STRM_ISSUE_OFFSET (CMD_STRM_BASE_OFFSET + 6)
-#define CMD_STRM_OPEN_OFFSET (CMD_STRM_BASE_OFFSET + 7)
-#define CMD_STRM_RECLAIM_OFFSET (CMD_STRM_BASE_OFFSET + 8)
-#define CMD_STRM_REGISTERNOTIFY_OFFSET (CMD_STRM_BASE_OFFSET + 9)
-#define CMD_STRM_SELECT_OFFSET (CMD_STRM_BASE_OFFSET + 10)
-#define CMD_STRM_END_OFFSET CMD_STRM_SELECT_OFFSET
-
-/* Communication Memory Manager (UCMM) */
-#define CMD_CMM_BASE_OFFSET (CMD_STRM_END_OFFSET + 1)
-#define CMD_CMM_ALLOCBUF_OFFSET (CMD_CMM_BASE_OFFSET + 0)
-#define CMD_CMM_FREEBUF_OFFSET (CMD_CMM_BASE_OFFSET + 1)
-#define CMD_CMM_GETHANDLE_OFFSET (CMD_CMM_BASE_OFFSET + 2)
-#define CMD_CMM_GETINFO_OFFSET
[PATCH 9/9] DSPBRIDGE: Remove DPC object structure
Remove DPC object structure and declare required members
for each tasklet inside their correspondent modules.
Remove dpc header file.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/_chnl_sm.h |1 -
arch/arm/plat-omap/include/dspbridge/dpc.h | 38 ---
drivers/dsp/bridge/pmgr/chnl.c |1 -
drivers/dsp/bridge/services/services.c |1 -
drivers/dsp/bridge/wmd/_deh.h |5 +-
drivers/dsp/bridge/wmd/io_sm.c | 80 ---
drivers/dsp/bridge/wmd/mmu_fault.c | 24 +--
drivers/dsp/bridge/wmd/ue_deh.c | 25 +--
8 files changed, 35 insertions(+), 140 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/dspbridge/dpc.h
diff --git a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
index f22b2cb..eb5adc2 100644
--- a/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/_chnl_sm.h
@@ -25,7 +25,6 @@
#include dspbridge/wcd.h
#include dspbridge/wmd.h
-#include dspbridge/dpc.h
#include dspbridge/list.h
#include dspbridge/ntfy.h
diff --git a/arch/arm/plat-omap/include/dspbridge/dpc.h
b/arch/arm/plat-omap/include/dspbridge/dpc.h
deleted file mode 100644
index aee910d..000
--- a/arch/arm/plat-omap/include/dspbridge/dpc.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * dpc.h
- *
- * DSP-BIOS Bridge driver support functions for TI OMAP processors.
- *
- * Deferred Procedure Call(DPC) Services.
- *
- * Copyright (C) 2005-2006 Texas Instruments, Inc.
- *
- * This package 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
- * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
- * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
- */
-
-#ifndef DPC_
-#define DPC_
-
-/* The DPC object, passed to our priority event callback routine: */
-struct DPC_OBJECT {
- u32 dwSignature;/* Used for object validation. */
- void *pRefData; /* Argument for client's DPC.*/
- u32 numRequested; /* Number of requested DPC's. */
- u32 numScheduled; /* Number of executed DPC's. */
- struct tasklet_struct dpc_tasklet;
-
-#ifdef DEBUG
- u32 cEntryCount;/* Number of times DPC reentered. */
- u32 numRequestedMax;/* Keep track of max pending DPC's. */
-#endif
-
- spinlock_t dpc_lock;
-};
-
-#endif /* DPC_ */
diff --git a/drivers/dsp/bridge/pmgr/chnl.c b/drivers/dsp/bridge/pmgr/chnl.c
index f4d0fc1..fd487f0 100644
--- a/drivers/dsp/bridge/pmgr/chnl.c
+++ b/drivers/dsp/bridge/pmgr/chnl.c
@@ -31,7 +31,6 @@
/* --- OS Adaptation Layer */
#include dspbridge/cfg.h
-#include dspbridge/dpc.h
#include dspbridge/list.h
#include dspbridge/mem.h
#include dspbridge/sync.h
diff --git a/drivers/dsp/bridge/services/services.c
b/drivers/dsp/bridge/services/services.c
index 0b7d623..5590634 100644
--- a/drivers/dsp/bridge/services/services.c
+++ b/drivers/dsp/bridge/services/services.c
@@ -29,7 +29,6 @@
/* --- OS Adaptation Layer */
#include dspbridge/cfg.h
#include dspbridge/dbg.h
-#include dspbridge/dpc.h
#include dspbridge/list.h
#include dspbridge/mem.h
#include dspbridge/ntfy.h
diff --git a/drivers/dsp/bridge/wmd/_deh.h b/drivers/dsp/bridge/wmd/_deh.h
index 2b364b5..aadb9fa 100644
--- a/drivers/dsp/bridge/wmd/_deh.h
+++ b/drivers/dsp/bridge/wmd/_deh.h
@@ -19,7 +19,6 @@
#ifndef _DEH_
#define _DEH_
-#include dspbridge/dpc.h
#include dspbridge/ntfy.h
#include dspbridge/wmd.h
@@ -30,8 +29,10 @@ struct DEH_MGR {
u32 dwSignature;/* Used for object validation. */
struct WMD_DEV_CONTEXT *hWmdContext;/* WMD device context. */
struct NTFY_OBJECT *hNtfy; /* NTFY object */
- struct DPC_OBJECT *hMmuFaultDpc;/* DPC object handle. */
struct DSP_ERRORINFO errInfo; /* DSP exception info. */
+
+ /* MMU Fault DPC */
+ struct tasklet_struct dpc_tasklet;
} ;
#endif /* _DEH_ */
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 1e855ce..a15e077 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -43,7 +43,6 @@
/* --- OS Adaptation Layer */
#include dspbridge/cfg.h
-#include dspbridge/dpc.h
#include dspbridge/mem.h
#include dspbridge/ntfy.h
#include dspbridge/sync.h
@@ -108,7 +107,6 @@ struct IO_MGR {
u8 *pMsgOutput; /* Address of output messages */
u32 uSMBufSize; /* Size of a shared memory I/O channel */
[PATCH 0/9] dspbridge cleanup patches
Following patches are cleanups, removing history of files, tab spacing and also remove DPC layer. Omar Ramirez Luna (8): DSPBRIDGE: trivial checkpatch fixes DSPBRIDGE: Fix multiline macros to use do while DSPBRIDGE: Use _IOxx macro to define ioctls DSPBRIDGE: trivial cleanup and indentation for io_sm DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers DSPBRIDGE: Remove main DPC wrapper for IO and MMUfault DSPBRIDGE: Remove DPC module from SERVICES layer DSPBRIDGE: Remove DPC object structure DSPBRIDGE: trivial file history cleanup arch/arm/plat-omap/include/dspbridge/_chnl_sm.h| 47 +- arch/arm/plat-omap/include/dspbridge/_dcd.h| 40 +- arch/arm/plat-omap/include/dspbridge/brddefs.h | 20 +- arch/arm/plat-omap/include/dspbridge/cfg.h | 50 +- arch/arm/plat-omap/include/dspbridge/cfgdefs.h | 27 +- arch/arm/plat-omap/include/dspbridge/chnl.h| 45 +- arch/arm/plat-omap/include/dspbridge/chnl_sm.h | 30 +- arch/arm/plat-omap/include/dspbridge/chnldefs.h| 26 +- arch/arm/plat-omap/include/dspbridge/chnlpriv.h| 33 +- arch/arm/plat-omap/include/dspbridge/clk.h | 11 +- arch/arm/plat-omap/include/dspbridge/cmm.h | 66 +- arch/arm/plat-omap/include/dspbridge/cmmdefs.h | 20 +- arch/arm/plat-omap/include/dspbridge/cod.h | 58 +- arch/arm/plat-omap/include/dspbridge/dbc.h | 40 +- arch/arm/plat-omap/include/dspbridge/dbdcd.h | 26 +- arch/arm/plat-omap/include/dspbridge/dbdcddef.h| 27 +- arch/arm/plat-omap/include/dspbridge/dbdefs.h | 61 +- arch/arm/plat-omap/include/dspbridge/dbg.h | 25 +- arch/arm/plat-omap/include/dspbridge/dbl.h | 14 - arch/arm/plat-omap/include/dspbridge/dbldefs.h | 12 - arch/arm/plat-omap/include/dspbridge/dbll.h| 15 +- arch/arm/plat-omap/include/dspbridge/dblldefs.h| 11 - arch/arm/plat-omap/include/dspbridge/dbtype.h | 21 +- arch/arm/plat-omap/include/dspbridge/dehdefs.h | 14 +- arch/arm/plat-omap/include/dspbridge/dev.h | 64 +- arch/arm/plat-omap/include/dspbridge/devdefs.h | 15 +- arch/arm/plat-omap/include/dspbridge/disp.h| 31 +- arch/arm/plat-omap/include/dspbridge/dispdefs.h| 14 +- arch/arm/plat-omap/include/dspbridge/dmm.h | 18 +- arch/arm/plat-omap/include/dspbridge/dpc.h | 167 --- arch/arm/plat-omap/include/dspbridge/drv.h | 48 +- arch/arm/plat-omap/include/dspbridge/drvdefs.h | 13 +- arch/arm/plat-omap/include/dspbridge/dspdrv.h | 33 +- .../plat-omap/include/dspbridge/dynamic_loader.h |2 - arch/arm/plat-omap/include/dspbridge/errbase.h | 37 +- arch/arm/plat-omap/include/dspbridge/gb.h | 10 +- arch/arm/plat-omap/include/dspbridge/getsection.h | 21 +- arch/arm/plat-omap/include/dspbridge/gh.h |8 - arch/arm/plat-omap/include/dspbridge/gs.h | 15 +- arch/arm/plat-omap/include/dspbridge/gt.h | 30 +- arch/arm/plat-omap/include/dspbridge/host_os.h | 10 - arch/arm/plat-omap/include/dspbridge/io.h | 21 +- arch/arm/plat-omap/include/dspbridge/io_sm.h | 46 +- arch/arm/plat-omap/include/dspbridge/iodefs.h | 13 +- arch/arm/plat-omap/include/dspbridge/ldr.h | 34 +- arch/arm/plat-omap/include/dspbridge/list.h| 36 +- arch/arm/plat-omap/include/dspbridge/mbx_sh.h | 25 +- arch/arm/plat-omap/include/dspbridge/mem.h | 78 +- arch/arm/plat-omap/include/dspbridge/memdefs.h | 16 +- arch/arm/plat-omap/include/dspbridge/mgr.h | 32 +- arch/arm/plat-omap/include/dspbridge/mgrpriv.h | 14 +- arch/arm/plat-omap/include/dspbridge/msg.h | 24 +- arch/arm/plat-omap/include/dspbridge/msgdefs.h | 15 +- arch/arm/plat-omap/include/dspbridge/nldr.h| 29 +- arch/arm/plat-omap/include/dspbridge/nldrdefs.h| 14 +- arch/arm/plat-omap/include/dspbridge/node.h| 48 +- arch/arm/plat-omap/include/dspbridge/nodedefs.h| 16 +- arch/arm/plat-omap/include/dspbridge/nodepriv.h| 23 +- arch/arm/plat-omap/include/dspbridge/ntfy.h| 22 +- arch/arm/plat-omap/include/dspbridge/proc.h| 47 +- arch/arm/plat-omap/include/dspbridge/procpriv.h| 13 +- arch/arm/plat-omap/include/dspbridge/pwr.h | 19 - arch/arm/plat-omap/include/dspbridge/pwr_sh.h | 12 +- arch/arm/plat-omap/include/dspbridge/reg.h | 35 +- arch/arm/plat-omap/include/dspbridge/rmm.h | 26 +- arch/arm/plat-omap/include/dspbridge/rms_sh.h | 34 +- arch/arm/plat-omap/include/dspbridge/rmstypes.h| 15 +- arch/arm/plat-omap/include/dspbridge/services.h| 17 +- arch/arm/plat-omap/include/dspbridge/std.h | 48 - arch/arm/plat-omap/include/dspbridge/strm.h| 41 +- arch/arm/plat-omap/include/dspbridge/strmdefs.h| 14 +-
[PATCH 5/9] DSPBRIDGE: trivial cleanup and indentation for io_sm
Remove duplicate set of braces from if statement and reduce
indentation.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/wmd/io_sm.c | 96 +---
1 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index af31831..96a5aa6 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -115,7 +115,7 @@ struct IO_MGR {
/* private extnd proc info; mmu setup */
struct MGR_PROCESSOREXTINFO extProcInfo;
struct CMM_OBJECT *hCmmMgr; /* Shared Mem Mngr*/
- struct work_struct io_workq; /*workqueue */
+ struct work_struct io_workq; /*workqueue */
u32 dQuePowerMbxVal[MAX_PM_REQS];
u32 iQuePowerHead;
u32 iQuePowerTail;
@@ -185,7 +185,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
struct CFG_HOSTRES hostRes;
struct CFG_DEVNODE *hDevNode;
struct CHNL_MGR *hChnlMgr;
- static int ref_count;
+ static int ref_count;
u32 devType;
/* Check requirements: */
if (!phIOMgr || !pMgrAttrs || pMgrAttrs-uWordSize == 0) {
@@ -197,9 +197,10 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
status = DSP_EHANDLE;
goto func_end;
}
-/* Message manager will be created when a file is loaded, since
+ /* Message manager will be created when a file is loaded, since
* size of message buffer in shared memory is configurable in
-* the base image. */
+* the base image.
+*/
DEV_GetWMDContext(hDevObject, hWmdContext);
if (!hWmdContext) {
status = DSP_EHANDLE;
@@ -209,7 +210,8 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
/* DSP shared memory area will get set properly when
* a program is loaded. They are unknown until a COFF file is
* loaded. I chose the value -1 because it was less likely to be
-* a valid address than 0. */
+* a valid address than 0.
+*/
pSharedMem = (struct SHM *) -1;
if (DSP_FAILED(status))
goto func_cont;
@@ -230,7 +232,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
status = DSP_EMEMORY;
goto func_cont;
}
- /*Intializing Work Element*/
+ /* Intializing Work Element */
if (ref_count == 0) {
INIT_WORK(pIOMgr-io_workq, (void *)IO_DispatchPM);
ref_count = 1;
@@ -319,7 +321,7 @@ DSP_STATUS WMD_IO_Destroy(struct IO_MGR *hIOMgr)
SYNC_DeleteCS(hIOMgr-hCSObj); /* Leak Fix. */
/* Free this IO manager object: */
MEM_FreeObject(hIOMgr);
- } else
+ } else
status = DSP_EHANDLE;
return status;
@@ -445,19 +447,16 @@ func_cont1:
#endif
if (DSP_FAILED(status))
status = CHNL_E_NOMEMMAP;
-
}
if (DSP_SUCCEEDED(status)) {
status = COD_GetSymValue(hCodMan, DYNEXTBASE, ulDynExtBase);
if (DSP_FAILED(status))
status = CHNL_E_NOMEMMAP;
-
}
if (DSP_SUCCEEDED(status)) {
status = COD_GetSymValue(hCodMan, EXTEND, ulExtEnd);
if (DSP_FAILED(status))
status = CHNL_E_NOMEMMAP;
-
}
if (DSP_SUCCEEDED(status)) {
/* Get memory reserved in host resources */
@@ -609,7 +608,7 @@ func_cont1:
}
}
-/* Copy remaining entries from CDB. All entries are 1 MB and should not
+ /* Copy remaining entries from CDB. All entries are 1 MB and should not
* conflict with SHM entries on MPU or DSP side */
for (i = 3; i 7 ndx WMDIOCTL_NUMOFMMUTLB
DSP_SUCCEEDED(status); i++) {
@@ -726,9 +725,9 @@ func_cont:
}
DBC_Assert(ulShmBase != 0);
if (DSP_SUCCEEDED(status)) {
+ /* Register SM */
status = registerSHMSegs(hIOMgr, hCodMan,
aEProc[0].ulGppPa);
- /* Register SM */
}
}
}
@@ -780,7 +779,6 @@ func_cont:
hIOMgr-ulTraceBufferBegin);
if (DSP_FAILED(status))
status = CHNL_E_NOMEMMAP;
-
}
hIOMgr-ulGPPReadPointer = hIOMgr-ulTraceBufferBegin =
(ulGppVa + ulSeg1Size + ulPadSize) +
@@ -791,7 +789,6 @@ func_cont:
hIOMgr-ulTraceBufferEnd);
if (DSP_FAILED(status))
status = CHNL_E_NOMEMMAP;
-
}
[PATCH 6/9] DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers
Remove DPC wrappers and replace with direct Linux calls.
These changes apply to IO DPC and MMUfault DPC
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/dpc.h | 90 +++--
drivers/dsp/bridge/services/dpc.c | 144 +---
drivers/dsp/bridge/wmd/io_sm.c | 73 +-
drivers/dsp/bridge/wmd/mmu_fault.c | 24 -
drivers/dsp/bridge/wmd/ue_deh.c| 31 ++-
5 files changed, 132 insertions(+), 230 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dpc.h
b/arch/arm/plat-omap/include/dspbridge/dpc.h
index 870a1b2..0c60342 100644
--- a/arch/arm/plat-omap/include/dspbridge/dpc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dpc.h
@@ -19,8 +19,6 @@
#ifndef DPC_
#define DPC_
- struct DPC_OBJECT;
-
/*
* DPC_PROC
* Purpose:
@@ -40,64 +38,22 @@
*/
typedef void(*DPC_PROC) (void *pRefData);
-/*
- * DPC_Cancel
- * Purpose:
- * Cancel a DPC previously scheduled by DPC_Schedule.
- * Parameters:
- * hDPC: A DPC object handle created in DPC_Create().
- * Returns:
- * DSP_SOK:Scheduled DPC, if any, is cancelled.
- * DSP_SFALSE: No DPC is currently scheduled for execution.
- * DSP_EHANDLE:Invalid hDPC.
- * Requires:
- * Ensures:
- * If the DPC has already executed, is executing, or was not yet
- * scheduled, this function will have no effect.
- */
- extern DSP_STATUS DPC_Cancel(IN struct DPC_OBJECT *hDPC);
+/* The DPC object, passed to our priority event callback routine: */
+struct DPC_OBJECT {
+ u32 dwSignature;/* Used for object validation. */
+ void *pRefData; /* Argument for client's DPC.*/
+ DPC_PROC pfnDPC;/* Client's DPC. */
+ u32 numRequested; /* Number of requested DPC's. */
+ u32 numScheduled; /* Number of executed DPC's. */
+ struct tasklet_struct dpc_tasklet;
-/*
- * DPC_Create
- * Purpose:
- * Create a DPC object, allowing a client's own DPC procedure to be
- * scheduled for a call with client reference data.
- * Parameters:
- * phDPC: Pointer to location to store DPC object.
- * pfnDPC: Client's DPC procedure.
- * pRefData: Pointer to user-defined reference data.
- * Returns:
- * DSP_SOK:DPC object created.
- * DSP_EPOINTER: phDPC == NULL or pfnDPC == NULL.
- * DSP_EMEMORY:Insufficient memory.
- * Requires:
- * Must not be called at interrupt time.
- * Ensures:
- * DSP_SOK: DPC object is created;
- * else: *phDPC is set to NULL.
- */
- extern DSP_STATUS DPC_Create(OUT struct DPC_OBJECT **phDPC,
- IN DPC_PROC pfnDPC,
- IN void *pRefData);
+#ifdef DEBUG
+ u32 cEntryCount;/* Number of times DPC reentered. */
+ u32 numRequestedMax;/* Keep track of max pending DPC's. */
+#endif
-/*
- * DPC_Destroy
- * Purpose:
- * Cancel the last scheduled DPC, and deallocate a DPC object previously
- * allocated with DPC_Create().Frees the Object only if the thread and
- * the events are terminated successfuly.
- * Parameters:
- * hDPC: A DPC object handle created in DPC_Create().
- * Returns:
- * DSP_SOK:Success.
- * DSP_EHANDLE:Invalid hDPC.
- * Requires:
- * All DPC's scheduled for the DPC object must have completed their
- * processing.
- * Ensures:
- * (SUCCESS hDPC is NULL) or DSP_EFAILED status
- */
- extern DSP_STATUS DPC_Destroy(IN struct DPC_OBJECT *hDPC);
+ spinlock_t dpc_lock;
+};
/*
* DPC_Exit
@@ -125,21 +81,7 @@
*/
extern bool DPC_Init(void);
-/*
- * DPC_Schedule
- * Purpose:
- * Schedule a deferred procedure call to be executed at a later time.
- * Latency and order of DPC execution is platform specific.
- * Parameters:
- * hDPC: A DPC object handle created in DPC_Create().
- * Returns:
- * DSP_SOK:An event is scheduled for deferred processing.
- * DSP_EHANDLE:Invalid hDPC.
- * Requires:
- * See requirements for DPC_PROC.
- * Ensures:
- * DSP_SOK:The DPC will not be called before this function
returns.
- */
- extern DSP_STATUS DPC_Schedule(IN struct DPC_OBJECT *hDPC);
+/* --- Function Prototypes */
+ void DPC_DeferredProcedure(IN unsigned long pDeferredContext);
#endif /* DPC_ */
diff --git a/drivers/dsp/bridge/services/dpc.c
b/drivers/dsp/bridge/services/dpc.c
index a6d453c..10bd792 100644
--- a/drivers/dsp/bridge/services/dpc.c
+++ b/drivers/dsp/bridge/services/dpc.c
@@ -37,111 +37,11 @@
/*
[PATCH 7/9] DSPBRIDGE: Remove main DPC wrapper for IO and MMUfault
Remove DeferredProcedure which is used as a wrapper to call
either IO or MMUfault DPCs. This also removes a custom typedef.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
arch/arm/plat-omap/include/dspbridge/dpc.h | 23
arch/arm/plat-omap/include/dspbridge/io_sm.h |2 +-
drivers/dsp/bridge/services/dpc.c| 36 --
drivers/dsp/bridge/wmd/io_sm.c | 50 -
drivers/dsp/bridge/wmd/mmu_fault.c |2 +-
drivers/dsp/bridge/wmd/mmu_fault.h |2 +-
drivers/dsp/bridge/wmd/ue_deh.c |5 +--
7 files changed, 36 insertions(+), 84 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/dpc.h
b/arch/arm/plat-omap/include/dspbridge/dpc.h
index 0c60342..b22140f 100644
--- a/arch/arm/plat-omap/include/dspbridge/dpc.h
+++ b/arch/arm/plat-omap/include/dspbridge/dpc.h
@@ -19,30 +19,10 @@
#ifndef DPC_
#define DPC_
-/*
- * DPC_PROC
- * Purpose:
- * Deferred processing routine. Typically scheduled from an ISR to
- * complete I/O processing.
- * Parameters:
- * pRefData: Ptr to user data: passed in via ISR_ScheduleDPC.
- * Returns:
- * Requires:
- * The DPC should not block, or otherwise acquire resources.
- * Interrupts to the processor are enabled.
- * DPC_PROC executes in a critical section.
- * Ensures:
- * This DPC will not be reenterred on the same thread.
- * However, the DPC may take hardware interrupts during execution.
- * Interrupts to the processor are enabled.
- */
- typedef void(*DPC_PROC) (void *pRefData);
-
/* The DPC object, passed to our priority event callback routine: */
struct DPC_OBJECT {
u32 dwSignature;/* Used for object validation. */
void *pRefData; /* Argument for client's DPC.*/
- DPC_PROC pfnDPC;/* Client's DPC. */
u32 numRequested; /* Number of requested DPC's. */
u32 numScheduled; /* Number of executed DPC's. */
struct tasklet_struct dpc_tasklet;
@@ -81,7 +61,4 @@ struct DPC_OBJECT {
*/
extern bool DPC_Init(void);
-/* --- Function Prototypes */
- void DPC_DeferredProcedure(IN unsigned long pDeferredContext);
-
#endif /* DPC_ */
diff --git a/arch/arm/plat-omap/include/dspbridge/io_sm.h
b/arch/arm/plat-omap/include/dspbridge/io_sm.h
index 77f9e25..67e3834 100644
--- a/arch/arm/plat-omap/include/dspbridge/io_sm.h
+++ b/arch/arm/plat-omap/include/dspbridge/io_sm.h
@@ -77,7 +77,7 @@
* Ensures:
* Non-preemptible (but interruptible).
*/
- extern void IO_DPC(IN OUT void *pRefData);
+ extern void IO_DPC(IN OUT unsigned long pRefData);
/*
* IO_ISR
diff --git a/drivers/dsp/bridge/services/dpc.c
b/drivers/dsp/bridge/services/dpc.c
index 10bd792..bbb2d47 100644
--- a/drivers/dsp/bridge/services/dpc.c
+++ b/drivers/dsp/bridge/services/dpc.c
@@ -66,39 +66,3 @@ bool DPC_Init(void)
return true;
}
-/*
- * DeferredProcedure
- * Purpose:
- * Main DPC routine. This is called by host OS DPC callback
- * mechanism with interrupts enabled.
- */
-void DPC_DeferredProcedure(IN unsigned long pDeferredContext)
-{
- struct DPC_OBJECT *pDPCObject = (struct DPC_OBJECT *)pDeferredContext;
- /* read numRequested in local variable */
- u32 requested;
- u32 serviced;
-
- DBC_Require(pDPCObject != NULL);
- requested = pDPCObject-numRequested;
- serviced = pDPCObject-numScheduled;
-
- GT_1trace(DPC_DebugMask, GT_ENTER, DPC_DeferredProcedure
- pDeferredContext=%x\n, pDeferredContext);
- /* Rollover taken care of using != instead of */
- if (serviced != requested) {
- if (pDPCObject-pfnDPC != NULL) {
- /* Process pending DPC's: */
- do {
- /* Call client's DPC: */
- (*(pDPCObject-pfnDPC))(pDPCObject-pRefData);
- serviced++;
- } while (serviced != requested);
- }
- pDPCObject-numScheduled = requested;
- }
- GT_2trace(DPC_DebugMask, GT_ENTER,
- DPC_DeferredProcedure requested %d
- serviced %d\n, requested, serviced);
-}
-
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 60dbc62..1e855ce 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -255,10 +255,8 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
IO_MGRSIGNATURE);
if (pIOMgr-hDPC) {
tasklet_init(pIOMgr-hDPC-dpc_tasklet,
- DPC_DeferredProcedure, (u32)pIOMgr-hDPC);
+
Re: [PATCH] omap3: sr: Update ON voltage levels based on VSEL
Premi, Sanjeev had written, on 11/23/2009 07:38 AM, the following: The settings for ON voltage level in the registers PRM_VC_CMD_VAL_0,1 was not updated based on OPP table. Once the MPU resumes from OFF mode (during idle OR suspend) the VDD1 voltage always returns to 1.2V. This patch programs the value based on current OPP. thanks for flagging this. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/mach-omap2/smartreflex.c | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index be3a1da..4cbbd6f 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -313,6 +313,15 @@ static void sr_configure_vp(int srid) PRM_VP1_CONFIG_TIMEOUTEN | vsel OMAP3430_INITVOLTAGE_SHIFT; + /* +* Update the 'ON' voltage levels based on the VSEL. +* (See spruf8c.pdf sec 1.5.3.1) +*/ + prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK, + (vsel OMAP3430_VC_CMD_ON_SHIFT), + OMAP3430_GR_MOD, + OMAP3_PRM_VC_CMD_VAL_0_OFFSET); + prm_write_mod_reg(vpconfig, OMAP3430_GR_MOD, OMAP3_PRM_VP1_CONFIG_OFFSET); prm_write_mod_reg(PRM_VP1_VSTEPMIN_SMPSWAITTIMEMIN | @@ -354,6 +363,15 @@ static void sr_configure_vp(int srid) else vsel = l3_opps[target_opp_no].vsel; + /* +* Update the 'ON' voltage levels based on the VSEL. +* (See spruf8c.pdf sec 1.5.3.1) +*/ + prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK, + (vsel OMAP3430_VC_CMD_ON_SHIFT), + OMAP3430_GR_MOD, + OMAP3_PRM_VC_CMD_VAL_1_OFFSET); + vpconfig = PRM_VP2_CONFIG_ERROROFFSET | PRM_VP2_CONFIG_ERRORGAIN | PRM_VP2_CONFIG_TIMEOUTEN | @@ -391,7 +409,6 @@ static void sr_configure_vp(int srid) /* Clear force bit */ prm_clear_mod_reg_bits(OMAP3430_FORCEUPDATE, OMAP3430_GR_MOD, OMAP3_PRM_VP2_CONFIG_OFFSET); - } } CMD_VAL_[01] contains: OFF, RET, ONLowPower, ON voltages. for VDD1 and VDD2 ON voltage: Here is what I see: sr_voltagescale_vcbypass sets the voltage for ON mode. BUT, this is called as part of voltage scale logic (from resource34xx.c::program_opp) == invoked only as part of DVFS transitions. The trouble we have is this: IF OFF mode is hit without DVFS transition, we call disable_smartreflex, which in turn calls sr_reset_voltage(). Unfortunately, this function is a wannabe sr_voltagescale_bypass, but does not do what sr_voltagebypass in it's entirety - critical one being: setting ON voltage based on state it is going into. (ideally, it should set the RET/ON voltage based on the state it is going into - but that'd be an optimization thing).. Now, without your patch, the OPP voltage is based on nominal OPP at which the system boots up on and CMD_VAL_0::ON voltage is not set when disable_smartreflex::reset_voltage is called. ON voltage is some value someone has set in the reg. For this, we come to the interesting part, we should now also look at arch/arm/mach-omap2/pm34xx.c::configure_vc function - which is another function who hits the ON ret and OFF voltage values based on prm_setup - this is where your bug comes from: defaults: 92 .vdd0_on = 0x30,/* 1.2v */ But voila, this can be updated by omap3_pm_init_vc - e.g. see arch/arm/mach-omap2/board-3430sdp.c You have few options here to proceed: a) Modify the board file to update the ON/OFF/RET voltages you'd like for your board. b) Fix configure_vc to take boot-up OPP voltage. c) Given the current state of code, but I think we dont handle disable_smartreflex correctly @ various OPPs and states. I do agree that we badly need to clean this path up. While I work on that, could I request this logic be moved across to sr_resetvoltage instead as a temporary standin for the immediate bug and others not using pm_init_vc function from hitting this bug? I think (a) might be a quicker solution for you. Do let me know if I missed something. -- 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
Do we have the benchmark about MUSB host of OMAP3530
Hi Ajay and Guys, Do we have the benchmark about MUSB host of OMAP3530, both in PIO mode and HSDMA mode. I want to know what is the performance and the gap in the two modes. -- K T Jung -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] dspbridge cleanup patches
On Mon, 2009-11-23 at 18:50 -0600, Omar Ramirez Luna wrote: Following patches are cleanups, removing history of files, tab spacing and also remove DPC layer. Omar Ramirez Luna (8): DSPBRIDGE: trivial checkpatch fixes DSPBRIDGE: Fix multiline macros to use do while DSPBRIDGE: Use _IOxx macro to define ioctls DSPBRIDGE: trivial cleanup and indentation for io_sm DSPBRIDGE: Remove DPC, create, destroy and schedule wrappers DSPBRIDGE: Remove main DPC wrapper for IO and MMUfault DSPBRIDGE: Remove DPC module from SERVICES layer DSPBRIDGE: Remove DPC object structure DSPBRIDGE: trivial file history cleanup Look like good clean-ups to me! Although I did not look at the patches very carefully, just briefly walked through. I think if you keep doing this, we could add dspbrige to -staging even! -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] ARM: OMAP: McBSP: Use register cache
On Mon, 23 Nov 2009 15:53:55 -0800 Tony Lindgren t...@atomide.com wrote: I have just found this patch, initially submitted on 2009-08-12, archived in linux-omap patchwork with State: Awaiting Upstream. What does it mean? Am I supposed to do something about it? After that many weeks of no negative comments nor requests for changes, and taking into account what Jarkko said lately in a different thread[*] about the McBSP register cache concept, can I assume that it has been generally accepted? Is it worth of refreshing against current linux-omap? I'll just mark patches Awaiting upstream if I feel like somebody else should ack or merge it. If there are obvious changes needed, I'll mark it Changes requested. So for the patch, please refresh. Then let's apply it assuming Jarkko acks it. Yep, I was aware of this Janusz's patch and was thinking that it could help also for developing the McBSP context save/restore features. + OMAP_MCBSP_WRITE(io_base, SPCR2, reg_cache-spcr2 = config-spcr2); + OMAP_MCBSP_WRITE(io_base, SPCR1, reg_cache-spcr1 = config-spcr1); ... - mcbsp-rx_word_length = (OMAP_MCBSP_READ(io_base, RCR1) 5) 0x7; - mcbsp-tx_word_length = (OMAP_MCBSP_READ(io_base, XCR1) 5) 0x7; + mcbsp-rx_word_length = (reg_cache-rcr1 5) 0x7; + mcbsp-tx_word_length = (reg_cache-xcr1 5) 0x7; IMO these would be cleaner if you embed cache handling into read and write functions only. Probably reading could have explicit _read and read_cache functions when code is dealing with the status bits and when just updating some cached bits. -- Jarkko -- 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
