Re: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap
Hi Fernando, From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 04:27:36 +0200 Omap platform is omap_iounmap function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..5489ca9 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, Woundn't the above be enough? Eventually this iounmap() calls __arch_iounmap() - omap_iounmap(). I don't see any special reason to call omap_iounmap() here for now. + sgt = unmap_vm_area(obj, da, (func_t)omap_iounmap, IOVMF_LINEAR | IOVMF_MMIO); if (!sgt) dev_dbg(obj-dev, %s: No sgt\n, __func__); -- 1.6.3.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
RE: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap
From: Hiroshi DOYU [hiroshi.d...@nokia.com] Sent: Thursday, October 14, 2010 1:45 AM To: Guzman Lugo, Fernando Cc: felipe.contre...@nokia.com; t...@atomide.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Hi Fernando, From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 04:27:36 +0200 Omap platform is omap_iounmap function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..5489ca9 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, Woundn't the above be enough? Eventually this iounmap() calls __arch_iounmap() - omap_iounmap(). I don't see any special reason to call omap_iounmap() here for now. iounmap and __arch_iounmap are macros they cannot not be used there. If so, it gives a undeclared compile error. Regards, Fernando. + sgt = unmap_vm_area(obj, da, (func_t)omap_iounmap, IOVMF_LINEAR | IOVMF_MMIO); if (!sgt) dev_dbg(obj-dev, %s: No sgt\n, __func__); -- 1.6.3.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
External SD card on nokia n810.
Hi, I try to boot n810 using root on external SD card with few recent linux-omap kernels. For example, with commit 151c7a7f it is ok, but with recent kernels it does not. Can I use recent kernel with root on external SD? Thanks. -- Best regards, Maksim A. Boyko -- 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: DSP fails to Initialise due to memory map
Hi, On Thu, 2010-10-14 at 15:49 +1100, John Garland wrote: Hi, using both dspbridge (5b4ec5f459a64b70a01d00a2dae9d79dc2a93c0c) and pm (e0bcaca00bb6cc2d79c8c3b765f969e00a3d313b) branches, I get a memory map failure when trying to load the dspbridge module (I've attached the traceback). It's a memory allocation failure for the SHM area which is very large (6 MB of continuous memory). You have to reserve some memory outside of the kernel control for that (use the mem parameter in your bootargs). Has anyone else experienced this? Is there a series of patches I need to apply? Try this patch: http://www.spinics.net/lists/linux-omap/msg38350.html However, even with this patch, don't expect everything to work just yet. I got the kernel module to load, but when I try to run some tests (e.g. load an image with the cexec tool from userspace-dspbridge), I get a node allocation failure. I didn't have time to debug it further ... We're probably missing some patches that were not applied yet to the staging tree ... Cheers, Ionut. -- 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/4] iovmm: replace __iounmap with omap_iounmap
From: ext Guzman Lugo, Fernando fernando.l...@ti.com Subject: RE: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 10:18:30 +0200 From: Hiroshi DOYU [hiroshi.d...@nokia.com] Sent: Thursday, October 14, 2010 1:45 AM To: Guzman Lugo, Fernando Cc: felipe.contre...@nokia.com; t...@atomide.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Hi Fernando, From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 04:27:36 +0200 Omap platform is omap_iounmap function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..5489ca9 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, Woundn't the above be enough? Eventually this iounmap() calls __arch_iounmap() - omap_iounmap(). I don't see any special reason to call omap_iounmap() here for now. iounmap and __arch_iounmap are macros they cannot not be used there. If so, it gives a undeclared compile error. Ok. I'll add this explanation as a note on this commit. -- 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] ADS7846: Changing chip detection channel due to improper detection
On Wed, Oct 13, 2010 at 5:47 PM, GERBER Patrick patrick.ger...@heig-vd.ch wrote: Hello, I am using the TSC2046 (newer ADS7846 silicon) on a custom design where the AUX input is not used and so pulled to GND. The ADS7846 driver is using the value of the AUX input to detect if a chip is connected or not. If the AUX value is 0x000 or 0xFFF the driver think that there is no chip. In my case due to the fact that the AUX input is pulled to GND the 0x000 value is normal. Therefore I suggest to use the temp1 channel instead of the AUX channel. The temperature will probably never be 0x000. What kernel is this against? Mainline doesn't seem to have this code. -- 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/1] OMAP: DSS2: Add NEC NL8048HL11-01B display panel
From: Erik Gilling konk...@android.com
NEC WVGA LCD NL8048HL11-01B panel support has been added.
This panel is being used in zoom2/zoom3/3630 sdp boards.
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
CC: Subbu Venkatesh subramani.venkat...@windriver.com
CC: Erik Gilling konk...@android.com
---
This panel driver has orginated from panel-zoom2 from the L25.x
releases.Refer Commit:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=75fc121865125d9e3ca3b36f1f19f86b394e1f6b
drivers/video/omap2/displays/Kconfig |7 +
drivers/video/omap2/displays/Makefile |1 +
.../omap2/displays/panel-nec-nl8048hl11-01b.c | 381
3 files changed, 389 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 12327bb..f8152cf 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -20,6 +20,13 @@ config PANEL_SHARP_LQ043T1DG01
help
LCD Panel used in TI's OMAP3517 EVM boards
+config PANEL_NEC_NL8048HL11_01B
+ tristate NEC NL8048HL11-01B Panel
+ depends on OMAP2_DSS
+ help
+ This NEC NL8048HL11-01B panel is TFT LCD
+ used in the Zoom2/3/3630 sdp boards.
+
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index aa38609..8ece91c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_PANEL_GENERIC) += panel-generic.o
obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_SHARP_LQ043T1DG01) += panel-sharp-lq043t1dg01.o
+obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-nl8048hl11-01b.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
obj-$(CONFIG_PANEL_TOPPOLY_TDO35S) += panel-toppoly-tdo35s.o
diff --git a/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
new file mode 100644
index 000..cdc0d8f
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec-nl8048hl11-01b.c
@@ -0,0 +1,381 @@
+/*
+ * Support for NEC-nl8048hl11-01b panel driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc.
+ * Author: Erik Gilling konk...@android.com
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include plat/display.h
+#include linux/backlight.h
+#include linux/fb.h
+
+#define LCD_XRES 800
+#define LCD_YRES 480
+/*
+ * NEC PIX Clock Ratings
+ * MIN:21.8MHz TYP:23.8MHz MAX:25.7MHz
+ */
+#define LCD_PIXEL_CLOCK23800
+
+struct nec_8048_data {
+ struct backlight_device *bl;
+};
+
+/*
+ * NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_8048_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_8048_bl_update_status(struct backlight_device *bl)
+{
+ struct omap_dss_device *dssdev = dev_get_drvdata(bl-dev);
+ int level;
+
+ if (!dssdev-set_backlight)
+ return -EINVAL;
+
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ level = bl-props.brightness;
+ else
+ level = 0;
+
+ return dssdev-set_backlight(dssdev, level);
+}
+
+static int nec_8048_bl_get_brightness(struct backlight_device *bl)
+{
+ if (bl-props.fb_blank == FB_BLANK_UNBLANK
+ bl-props.power == FB_BLANK_UNBLANK)
+ return bl-props.brightness;
+
+ return 0;
+}
+
+static const struct backlight_ops nec_8048_bl_ops = {
+ .get_brightness = nec_8048_bl_get_brightness,
+ .update_status = nec_8048_bl_update_status,
+};
+
+static int
[PATCH 0/2] OMAP3: Display Support
This patch series adds the Display Support for OMAP3 platforms and the corresponding changes in the board files. Kishore Y (2): OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3 OMAP3: Enable display on ZOOM2/3/3630SDP arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom-display.c | 165 + arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++- arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + arch/arm/mach-omap2/include/mach/board-zoom.h |2 + 7 files changed, 220 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-display.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3: ZOOM2/3/3630SDP: Add display board file for OMAP3
From: Kishore Y kishor...@ti.com
Board-zoom-display.c added as a common file for display functionality
on boards zoom2, zoom3 and 3630sdp
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
Signed-off-by: Rajkumar N rajkumar.nagara...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/board-zoom-display.c | 165 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 49 +++-
arch/arm/mach-omap2/include/mach/board-zoom.h |2 +
4 files changed, 217 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 88d3a1e..95e0ecf 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -132,16 +132,19 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
board-zoom-peripherals.o \
+ board-zoom-display.o \
board-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
new file mode 100644
index 000..1e0b3da
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -0,0 +1,165 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-zoom-peripherals.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/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/gpio.h
+#include linux/i2c/twl.h
+#include linux/spi/spi.h
+#include plat/mcspi.h
+#include plat/display.h
+
+#define LCD_PANEL_ENABLE_GPIO (7 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_RESET_GPIO_PROD 96
+#define LCD_PANEL_RESET_GPIO_PILOT 55
+#define LCD_PANEL_QVGA_GPIO56
+
+static void zoom_lcd_panel_init(void)
+{
+ int ret;
+ unsigned char lcd_panel_reset_gpio;
+
+ lcd_panel_reset_gpio = (omap_rev() OMAP3430_REV_ES3_0) ?
+ LCD_PANEL_RESET_GPIO_PROD :
+ LCD_PANEL_RESET_GPIO_PILOT;
+
+ ret = gpio_request(lcd_panel_reset_gpio, lcd reset);
+ if (ret) {
+ pr_err(Failed to get LCD reset GPIO (gpio%d).\n,
+ lcd_panel_reset_gpio);
+ return;
+ }
+ gpio_direction_output(lcd_panel_reset_gpio, 1);
+
+ ret = gpio_request(LCD_PANEL_QVGA_GPIO, lcd qvga);
+ if (ret) {
+ pr_err(Failed to get LCD_PANEL_QVGA_GPIO (gpio%d).\n,
+ LCD_PANEL_QVGA_GPIO);
+ goto err0;
+ }
+ gpio_direction_output(LCD_PANEL_QVGA_GPIO, 1);
+
+ return;
+err0:
+ gpio_free(lcd_panel_reset_gpio);
+}
+
+static int zoom_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ return 0;
+}
+
+static void zoom_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+}
+
+/*
+ * PWMA/B register offsets (TWL4030_MODULE_PWMA)
+ */
+#define TWL_INTBR_PMBR10xD
+#define TWL_INTBR_GPBR10xC
+#define TWL_LED_PWMON 0x0
+#define TWL_LED_PWMOFF 0x1
+
+static int zoom_set_bl_intensity(struct omap_dss_device *dssdev, int level)
+{
+ unsigned char c;
+ u8 mux_pwm, enb_pwm;
+
+ if (level 100)
+ return -1;
+
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, mux_pwm, TWL_INTBR_PMBR1);
+ twl_i2c_read_u8(TWL4030_MODULE_INTBR, enb_pwm, TWL_INTBR_GPBR1);
+
+ if (level == 0) {
+ /* disable pwm1 output and clock */
+ enb_pwm = enb_pwm 0xF5;
+ /* change pwm1 pin to gpio pin */
+ mux_pwm = mux_pwm 0xCF;
+ twl_i2c_write_u8(TWL4030_MODULE_INTBR,
+ enb_pwm, TWL_INTBR_GPBR1);
+
[PATCH 2/2] OMAP3: Enable display on ZOOM2/3/3630SDP
From: Kishore Y kishor...@ti.com Enable Display on zoom2, zoom3 and 3630sdp boards. Signed-off-by: Mukund Mittal mmit...@ti.com Signed-off-by: Kishore Y kishor...@ti.com Signed-off-by: Samreen samr...@ti.com --- arch/arm/mach-omap2/board-3630sdp.c |1 + arch/arm/mach-omap2/board-zoom2.c |1 + arch/arm/mach-omap2/board-zoom3.c |1 + 3 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c index b359c3f..d6ba94a 100644 --- a/arch/arm/mach-omap2/board-3630sdp.c +++ b/arch/arm/mach-omap2/board-3630sdp.c @@ -210,6 +210,7 @@ static void __init omap_sdp_init(void) omap3_mux_init(board_mux, OMAP_PACKAGE_CBP); omap_serial_init(); zoom_peripherals_init(); + zoom_display_init(); board_smc91x_init(); board_flash_init(sdp_flash_partitions, chip_sel_sdp); enable_board_wakeup_source(); diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-omap2/board-zoom2.c index 3ad9ecf..1db4d95 100644 --- a/arch/arm/mach-omap2/board-zoom2.c +++ b/arch/arm/mach-omap2/board-zoom2.c @@ -138,6 +138,7 @@ static void __init omap_zoom2_init(void) board_nand_init(zoom_nand_partitions, ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS); zoom_debugboard_init(); + zoom_display_init(); } MACHINE_START(OMAP_ZOOM2, OMAP Zoom2 board) diff --git a/arch/arm/mach-omap2/board-zoom3.c b/arch/arm/mach-omap2/board-zoom3.c index 6ca0b83..6e012f6 100644 --- a/arch/arm/mach-omap2/board-zoom3.c +++ b/arch/arm/mach-omap2/board-zoom3.c @@ -117,6 +117,7 @@ static void __init omap_zoom_init(void) board_nand_init(zoom_nand_partitions, ARRAY_SIZE(zoom_nand_partitions), ZOOM_NAND_CS); zoom_debugboard_init(); + zoom_display_init(); omap_mux_init_gpio(64, OMAP_PIN_OUTPUT); usb_ehci_init(ehci_pdata); -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
The defconfig options for display are taken in the respective Kconfig to enable display by default on OMAP3 platforms Signed-off-by: Samreen samr...@ti.com --- drivers/video/omap2/displays/Kconfig |3 +++ drivers/video/omap2/dss/Kconfig |6 -- drivers/video/omap2/omapfb/Kconfig |4 +++- 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/video/omap2/displays/Kconfig b/drivers/video/omap2/displays/Kconfig index f8152cf..d7d3edb 100644 --- a/drivers/video/omap2/displays/Kconfig +++ b/drivers/video/omap2/displays/Kconfig @@ -3,6 +3,7 @@ menu OMAP2/3 Display Device Drivers config PANEL_GENERIC tristate Generic Panel + default y help Generic panel driver. Used for DVI output for Beagle and OMAP3 SDP. @@ -10,6 +11,7 @@ config PANEL_GENERIC config PANEL_SHARP_LS037V7DW01 tristate Sharp LS037V7DW01 LCD Panel depends on OMAP2_DSS + default y select BACKLIGHT_CLASS_DEVICE help LCD Panel used in TI's SDP3430 and EVM boards @@ -17,6 +19,7 @@ config PANEL_SHARP_LS037V7DW01 config PANEL_SHARP_LQ043T1DG01 tristate Sharp LQ043T1DG01 LCD Panel depends on OMAP2_DSS + default y help LCD Panel used in TI's OMAP3517 EVM boards diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index 43b6440..f3244a2 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -1,6 +1,7 @@ menuconfig OMAP2_DSS tristate OMAP2/3 Display Subsystem support (EXPERIMENTAL) depends on ARCH_OMAP2 || ARCH_OMAP3 + default y help OMAP2/3 Display Subsystem support. @@ -9,7 +10,7 @@ if OMAP2_DSS config OMAP2_VRAM_SIZE int VRAM size (MB) range 0 32 - default 0 + default 4 help The amount of SDRAM to reserve at boot time for video RAM use. This VRAM will be used by omapfb and other drivers that need @@ -102,7 +103,8 @@ config OMAP2_DSS_FAKE_VSYNC config OMAP2_DSS_MIN_FCK_PER_PCK int Minimum FCK/PCK ratio (for scaling) range 0 32 - default 0 + default 4 if ARCH_OMAP2 || ARCH_OMAP3 + default 0 if ARCH_OMAP4 help This can be used to adjust the minimum FCK/PCK ratio. diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig index 65149b2..41aec6f 100644 --- a/drivers/video/omap2/omapfb/Kconfig +++ b/drivers/video/omap2/omapfb/Kconfig @@ -1,6 +1,7 @@ menuconfig FB_OMAP2 tristate OMAP2/3 frame buffer support (EXPERIMENTAL) depends on FB OMAP2_DSS + default y select OMAP2_VRAM select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 @@ -21,7 +22,8 @@ config FB_OMAP2_DEBUG_SUPPORT config FB_OMAP2_NUM_FBS int Number of framebuffers range 1 10 - default 3 + default 1 if ARCH_OMAP2 || ARCH_OMAP3 + default 3 if ARCH_OMAP4 depends on FB_OMAP2 help Select the number of framebuffers created. OMAP2/3 has 3 overlays -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] OMAP3: V4L2: Kconfig changes to enable V4L2 options on OMAP3
The defconfig options for V4L2 are taken in the respective Kconfig to enable V4L2 by default on OMAP3 platforms Signed-off-by: Samreen samr...@ti.com --- drivers/media/Kconfig|2 ++ drivers/media/video/omap/Kconfig |2 +- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index a28541b..2592d88 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -5,6 +5,7 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM + default y if ARCH_OMAP2 || ARCH_OMAP3 help If you want to use Video for Linux, DVB for Linux, or DAB adapters, enable this option and other options below. @@ -19,6 +20,7 @@ comment Multimedia core support config VIDEO_DEV tristate Video For Linux + default y if ARCH_OMAP2 || ARCH_OMAP3 ---help--- V4L core support for video capture and overlay devices, webcams and AM/FM radio cards. diff --git a/drivers/media/video/omap/Kconfig b/drivers/media/video/omap/Kconfig index e63233f..f3e33c3 100644 --- a/drivers/media/video/omap/Kconfig +++ b/drivers/media/video/omap/Kconfig @@ -6,6 +6,6 @@ config VIDEO_OMAP2_VOUT select OMAP2_DSS select OMAP2_VRAM select OMAP2_VRFB - default n + default y ---help--- V4L2 Display driver support for OMAP2/3 based boards. -- 1.5.6.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
Re: External SD card on nokia n810.
On Thu, 14 Oct 2010 13:24:03 +0400 Maksim A. Boyko maksim.a.bo...@gmail.com wrote: Hi, I try to boot n810 using root on external SD card with few recent linux-omap kernels. For example, with commit 151c7a7f it is ok, but with recent kernels it does not. Can I use recent kernel with root on external SD? How recent? I was able to use uSD root on N810 about 1-2 weeks ago with linux-omap head. The 2nd slot was broken between ~mid 2009 and Aug 2010. -- 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
Re: External SD card on nokia n810.
How recent? I was able to use uSD root on N810 about 1-2 weeks ago with linux-omap head. The 2nd slot was broken between ~mid 2009 and Aug 2010. Аpproximately 2-3 weeks ago. Is uSD internal mmc (/dev/mmcblk1) ? How hard to fix 2nd slot? -- Best regards, Maksim A. Boyko -- 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] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n
Paul, Benoit,
Please provide your input on this.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, October 12, 2010 11:57 PM
To: Cousson, Benoit
Cc: Varadarajan, Charulatha; Paul Walmsley; linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap2plus: wdt: Fix boot warn when
CONFIG_PM_RUNTIME=n
Cousson, Benoit b-cous...@ti.com writes:
Adding more folks to the discussion.
On 10/12/2010 9:30 AM, Varadarajan, Charulatha wrote:
From: Cousson, Benoit
Sent: Tuesday, October 12, 2010 12:45 PM
To: Varadarajan, Charulatha
Hi Charu,
On 10/11/2010 2:02 PM, Varadarajan, Charulatha wrote:
Fix the below warning during boot
[0.00] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185
_omap_hwmod_enable+0x34/0x150()
[0.00] omap_hwmod: wd_timer2: enabled state can
only be entered
from initialized, idle, or disabled state
[0.00] Modules linked in:
[0.00] [c0050460] (unwind_backtrace+0x0/0xe4) from
[c0083954] (warn_slowpath_common+0x4c/0x64)
[0.00] [c0083954] (warn_slowpath_common+0x4c/0x64) from
[c00839ec] (warn_slowpath_fmt+0x2c/0x3c)
[0.00] [c00839ec] (warn_slowpath_fmt+0x2c/0x3c) from
[c0059be4] (_omap_hwmod_enable+0x34/0x150)
[0.00] [c0059be4] (_omap_hwmod_enable+0x34/0x150) from
[c0059d28] (omap_hwmod_enable+0x28/0x3c)
[0.00] [c0059d28] (omap_hwmod_enable+0x28/0x3c) from
[c005580c] (omap2_disable_wdt+0x48/0xdc)
[0.00] [c005580c] (omap2_disable_wdt+0x48/0xdc) from
[c0058898] (omap_hwmod_for_each_by_class+0x60/0xa4)
[0.00] [c0058898]
(omap_hwmod_for_each_by_class+0x60/0xa4)
from [c000f6d0] (omap2_init_devices+0x44/0x330)
[0.00] [c000f6d0] (omap2_init_devices+0x44/0x330) from
[c0049578] (do_one_initcall+0xcc/0x1a4)
[0.00] [c0049578] (do_one_initcall+0xcc/0x1a4) from
[c0008780] (kernel_init+0x148/0x210)
[0.00] [c0008780] (kernel_init+0x148/0x210)
from [c004acb8]
(kernel_thread_exit+0x0/0x8)
[0.00] ---[ end trace 1b75b31a2719ed1f ]---
[0.00] wd_timer2: Could not enable clocks for
omap2_disable_wdt
When CONFIG_PM_RUNTIME is not defined, watchdog timer
clocks are not
disabled after a watchdog reset. Hence in
omap2_disable_wdt(), it is
not required to enable clocks before accessing the watchdog timer
registers if CONFIG_PM_RUNTIME is not defined.
I'm not a big fan of adding some dependencies with
CONFIG_PM_RUNTIME
inside this code.
The real root cause is not CONFIG_PM_RUNTIME, but mostly the
skip_setup_idle variable added in
arch/arm/mach-omap2/io.c by Paul.
Yes.
So I'd rather use that parameter as an input for the
omap2_disable_wdt.
I also thought about this, but we need to
1. call omap2_disable_wdt() in omap2_init_common_hw() rather than
omap2_init_devices(). That would involve movement of
omap2_disable_wdt() from devices.c to io.c.
(or)
2. make skip_setup_idle global
(or)
3. make omap2_disable_wdt() global and call it from
omap2_init_common_hw() and pass skip_setup_idle as parameter.
I felt that the usage of CONFIG_PM_RUNTIME is better than
the above.
But still we may consider any of the above options or any other
option. Please suggest.
It is maybe easier, but I don't think it is better...
As I said, CONFIG_PM_RUNTIME is not the root cause of your
issue, just
an indirect cause. OK, maybe strictly speaking, it is the
root cause,
since it started for that... but that not the cause that we should
consider in your case.
If we decide to remove that CONFIG_PM_RUNTIME dependency in the io /
hwmod code, nobody will be able to find the relation with
your code in
WDT.
That's why you should not do that, for my point of view.
Paul, Kevin,
Any thoughts on that point?
I agree that this is not strictly a dependency on PM_RUNTIME.
What's really needed is a way for low-level hwmod users like
this to be
able to check whether the hwmod is already enabled.
Something like this
(completely untested):
bool omap_hwmod_is_enabled(struct omap_hwmod *oh)
{
return (oh-_state == _HWMOD_STATE_ENABLED);
}
Kevin,
Thanks. This is similar to what we were discussing internally and
I would prefer this. But is it a good idea to allow drivers to
know the state of oh and then enable/idle the device?
Or should it be used only in exceptional situations like the scenario
addressed in this patch?
Alternatively, maybe calling omap_hwmod_enable() when the state is
already enabled should not be so verbose, and it should just return
success, but that option needs a little more thought...
Kevin
Regards,
Benoit
Tested on OMAP3430 SDP and OMAP4430 SDP.
Signed-off-by: Charulatha Vch...@ti.com
---
arch/arm/mach-omap2/devices.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git
Re: [PATCHv3 00/11] staging tidspbridge: iommu migration
On Tue, Oct 12, 2010 at 5:39 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Oct 11, 2010 at 6:03 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo x0095...@ti.com wrote: This set of patches remove the dspbridge custom mmu implementation and use iommu module instead. I have tried this, it works for simple tests, but not real use-cases. I applied all your iommu patches. How did you test this? Have you applied: - scatterlist: define SG chain for arm architecture - iovmm: replace __iounmap with omap_iounmap - iovmm: add superpages support to fixed da address - iovmm: IVA2 MMU range is from 0x1100 to 0x - iovmm: no gap checking for fixed address Yes. Also make sure your baseline have this patch: - omap:iommu-load cam register before flushing the entry Huh? That's not even in v2.6.36-rc7, in which baseline is this supposed to be in? Anyway, I'll try adding that. That's is in latest Hiroshi's tree and it is really needed, Otherwise You will have wrong traslations which can cause unexpected behavior. Now I applied that, still fails. What kind of error are you getting? Node allocation failing IIRC. Is it falling to map the Heap?? I mean you see this trace? if (status) pr_err(%s: Failed to map memory for Heap: 0x%x\n, __func__, status); Otherwise, I don't see how that fail is related with iommu changes. Nope. I don't have a complete framework to test MM testcases at this moment See: http://felipec.wordpress.com/2010/10/08/my-arm-development-notes/ I even prepared a tarball so you just need to extract it on your device. It's not difficult to test this with GStreamer, and I don't see how you can be confident that they indeed work without testing some real use-cases. Anyway, I'll try that missing patch. Most of time real use-cases are not so stressing like testcases We can make to test under real stress in order to find out corner cases. However when I test it was pretty stable and just few erros because staging Does not have latest mailbox patches. Also I test in a .35 version of staging. So now I am using a branch with all new patches and I will recheck and test Again any possible issue. Also I will look at your gstreamer fail too. Well, in my experience it's the other way around, the stress test-cases don't catch the errors that happen on real use-case scenarios, no matter how extensive they are. This is a good example. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: perf: Fix build break due to a typo
armpmu is a pointer to a structure - We need to use the
structure pointer operator to access num_events, and not
the structure member operator.
This fixes the following build break when building for OMAP4.
CC arch/arm/kernel/perf_event.o
arch/arm/kernel/perf_event.c: In function 'armpmu_event_init':
arch/arm/kernel/perf_event.c:543: error: request for member 'num_events' in
something not a structure or union
make[1]: *** [arch/arm/kernel/perf_event.o] Error 1
make: *** [arch/arm/kernel] Error 2
Signed-off-by: Anand Gadiyar gadi...@ti.com
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: paulus pau...@samba.org
Cc: Ingo Molnar mi...@elte.hu
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
---
This break is reproducible on linux-next as of 20101014.
This was introduced in commit 15ac9a395a75 in linux-next
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=15ac9a395a753cb28c674e7ea80386ffdff21785
Strangely, I did not catch it with a standard omap2plus_defconfig
build, but it showed up when I build a custom OMAP4-only config.
I've saved the defconfig for later analysis.
arch/arm/kernel/perf_event.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: mainline/arch/arm/kernel/perf_event.c
===
--- mainline.orig/arch/arm/kernel/perf_event.c
+++ mainline/arch/arm/kernel/perf_event.c
@@ -540,7 +540,7 @@ static int armpmu_event_init(struct perf
event-destroy = hw_perf_event_destroy;
if (!atomic_inc_not_zero(active_events)) {
- if (atomic_read(active_events) armpmu.num_events) {
+ if (atomic_read(active_events) armpmu-num_events) {
atomic_dec(active_events);
return -ENOSPC;
}
--
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/4] iovmm: replace __iounmap with omap_iounmap
-Original Message- From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] Sent: Thursday, October 14, 2010 4:47 AM To: Guzman Lugo, Fernando Cc: felipe.contre...@nokia.com; t...@atomide.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap From: ext Guzman Lugo, Fernando fernando.l...@ti.com Subject: RE: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 10:18:30 +0200 From: Hiroshi DOYU [hiroshi.d...@nokia.com] Sent: Thursday, October 14, 2010 1:45 AM To: Guzman Lugo, Fernando Cc: felipe.contre...@nokia.com; t...@atomide.com; linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Hi Fernando, From: ext Fernando Guzman Lugo x0095...@ti.com Subject: [PATCH 3/4] iovmm: replace __iounmap with omap_iounmap Date: Thu, 14 Oct 2010 04:27:36 +0200 Omap platform is omap_iounmap function. Signed-off-by: Fernando Guzman Lugo x0095...@ti.com --- arch/arm/plat-omap/iovmm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 93a34d9..5489ca9 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -821,7 +821,7 @@ void iommu_kunmap(struct iommu *obj, u32 da) struct sg_table *sgt; typedef void (*func_t)(const void *); - sgt = unmap_vm_area(obj, da, (func_t)__iounmap, + sgt = unmap_vm_area(obj, da, (func_t)iounmap, Woundn't the above be enough? Eventually this iounmap() calls __arch_iounmap() - omap_iounmap(). I don't see any special reason to call omap_iounmap() here for now. iounmap and __arch_iounmap are macros they cannot not be used there. If so, it gives a undeclared compile error. Ok. I'll add this explanation as a note on this commit. Sure, Thanks. Regards, Fernando. -- 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] arm: perf: Fix build break due to a typo
* Anand Gadiyar gadi...@ti.com wrote: armpmu is a pointer to a structure - We need to use the structure pointer operator to access num_events, and not the structure member operator. This fixes the following build break when building for OMAP4. Yeah - i already fixed it earlier today and pushed it out. Thanks, Ingo -- 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/7] omap:mailbox-enhancments and fixes
* Hari Kanigeri h-kanige...@ti.com [101013 18:24]: This patch set includes following mailbox enhancments and fixes. Please repost one more time with linux-arm-kernel list Cc'd so Hiroshi does not need to repost these. For any arch/arm/*omap*/ patches we need to have them also reviewed on the linux-arm-kernel list. 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
[PATCH] OMAP: hmwod: Update the sysc_cache in case module context is lost
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index cb911d7..e57fe21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -115,7 +115,10 @@ static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
/* XXX ensure module interface clock is up */
- if (oh-_sysc_cache != v) {
+ if ((oh-_sysc_cache != v) ||
+ /* Did the module go to off and loose context? */
+ (oh-_sysc_cache !=
+omap_hwmod_readl(oh, oh-class-sysc-sysc_offs))) {
oh-_sysc_cache = v;
omap_hwmod_writel(v, oh, oh-class-sysc-sysc_offs);
}
--
1.7.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
RE: [PATCH] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n
Hello Charu, Kevin, Benoît, On Thu, 14 Oct 2010, Varadarajan, Charulatha wrote: Please provide your input on this. Thinking about this problem -- and the earlier problem of how to determine what state to leave the watchdog in -- what occurs to me is that we should probably: 1. add a function pointer in the struct omap_hwmod_class for a custom pre-shutdown function, called before clocks are disabled, etc.; that can do the appropriate register writes needed during an omap_hwmod_shutdown() while the device is still considered to be enabled; 2. add a function to allow OMAP core code or board-*.c code to tell the hwmod code to leave a hwmod disabled at the end of _setup(), rather than idled or left enabled -- something like omap_hwmod_set_postsetup_state(HWMOD_STATE_DISABLED); 3. look to see if we can detect if the watchdog is enabled before the hwmod code starts -- perhaps by reading WSPR? -- and if it is not enabled, calling omap_hwmod_set_postsetup_state(HWMOD_STATE_DISABLED) prior to calling omap_hwmod_late_init(); 4. disable the MPU watchdog by default if #3 is not possible, and then allow specific board files to indicate that it should be enabled if they want full kernel boot watchdog coverage with something like omap_hwmod_set_postsetup_state(HWMOD_STATE_IDLE); and possibly also add a kernel command line parameter like enable_omapwdt_boot that can specify that the watchdog should be left enabled upon boot. This arrangement is a little more complicated, but it ensures that omap_hwmod_shutdown() really will shut down the watchdog. It also makes it possible for individual board files or bootloader configurations to ensure full watchdog coverage of the kernel initialization process. If I were designing a commercial OMAP-based device, I'd probably want full watchdog coverage of the entire boot process from the bootloader onwards. But simultaneously we don't want to change the existing kernel behavior too much -- most of our developer users would probably be shocked if, upon upgrading to a new kernel, suddenly the watchdog started rebooting their machines -- so it makes sense to me to disable the watchdog unless instructed otherwise. Enclosed below is a work-in-progress patch to illustrate the proposal. It clearly needs some more work and should be split into at least two patches, but it might help clarify what I am proposing. We also should, IMHO, move the struct omap_hwmod_class definitions out of the main hwmod data files, since they may contain function pointers. (We will probably also need a .reset function pointer there also to deal with complicated IPs like the IVA2, as we discussed a few months ago.) We should try to restrict the main omap_hwmod data files to be relatively OS-independent data structures. Regarding the omap_hwmod_is_enabled() proposal: it seems racy to me. In theory the system state can change after the result of omap_hwmod_is_enabled() is tested, but before the consequence of the conditional statement runs. There used to be a similar problem in the clock framework with a clk_is_enabled() function (a similar race still exists with the clk_get_rate() function). If possible, I think we should try to avoid creating APIs that are explicitly racy. Charu, I think that functions like omap2_disable_wdt() and any related watchdog device manipulation functions should go into their own file -- something like arch/arm/mach-omap2/wd_timer.c ? -- and not live in devices.c. One last thing: Benoît, in the hwmod data, I think we should separate watchdog IPs that are automatically enabled upon reset (like the MPU watchdog), from watchdogs that are disabled after reset (like the IVA2 watchdog). It doesn't matter to me whether we create a second class, or whether we just use a dev_attr flag. If we separate these, then code can use omap_hwmod_for_each_class() to ensure that all watchdogs of this type are disabled upon boot, rather than hardcoding a specific hwmod. Thoughts? ... As an aside, we seem to again be skirting issues of what it means for a hwmod to be enabled and idle. If we read enabled as fully functional and registers accessible, that seems to make sense; but if we consider idle as meaning configured but nonfunctional, that does not match up to the state that modules like WDT and GPIO are left in. The issue with WDT is that it probably does not IdleAck when enabled and its clocks are turned off, as Benoît mentioned; and the issue with GPIO is that it can generate asynchronous interrupts, even when all its clocks are off. It would be good if we could clarify the semantics for these states in some formal way. Perhaps more states are needed at the hwmod level? Or perhaps we just need to clarify what idle really means... - Paul From 2e05f1c33b2c5b081146079a2908fe5bbb4350d6 Mon Sep 17 00:00:00 2001 From: Paul Walmsley p...@pwsan.com Date: Thu, 14 Oct 2010 11:47:46 -0600 Subject: [RFC PATCH] OMAP2+: hwmod: add
Re: [RFC][PATCH 2/2] OMAP4: PRCM: Fix usage of prm/cm accessor api's for OMAP4
Hello Rajendra, On Tue, 10 Aug 2010, Rajendra Nayak wrote: OMAP's have always had PRCM split into PRM for power and reset management and CM for clock management. In OMAP4 the split (physically) is not very straight forward and there are instances of clock management control registers in PRM and vice versa. However it still makes sense, even on OMAP4 to logically split PRCM into PRM and CM for better understanding and to avoid adding additonal complexity in higher level frameworks which rely on the accessor api;s to do the low level register accesses. Hence this patch makes sure that any clock management code can use the cm_read/write* accessor apis (without knowing the physical split) and power and reset management code can use prm_read/write* accessor api;s. To do this the submodule offsets within PRM/CM1 and CM2 have additonal info embedded in them specifying what base address to use while trying to access registers in the given submodule. The 16 bit signed submodule offset is defined for OMAP4 as Bit 15 | Bit 14:13 | Bit 12:0 Sign bit| base identifier | submodule offset from base The concern that I have with embedding multiple parameters into a single parameter is that it seems like a hack. Why not add an extra parameter for the base identifier, rather than packing it into an existing parameter? I am not necessarily opposed to your patch as it exists. But I would like to hear your opinions first on separating out the base identifier parameter as a separate function parameter, and then adding an extra field for it into any data structure that would need it. Could you write briefly if you see any significant advantages/disadvantages to that approach? For older OMAP's the base identifier is always set to 0. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com --- arch/arm/mach-omap2/cm.h |4 +- arch/arm/mach-omap2/prcm-common.h | 58 --- arch/arm/mach-omap2/prcm.c| 68 ++-- arch/arm/mach-omap2/prm.h |4 +- 4 files changed, 105 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index a02ca30..7b7ef09 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -23,9 +23,9 @@ #define OMAP34XX_CM_REGADDR(module, reg) \ OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE + (module) + (reg)) #define OMAP44XX_CM1_REGADDR(module, reg)\ - OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + (module) + (reg)) + OMAP2_L4_IO_ADDRESS(OMAP4430_CM1_BASE + ((module) (MOD_MASK)) + (reg)) #define OMAP44XX_CM2_REGADDR(module, reg)\ - OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + (module) + (reg)) + OMAP2_L4_IO_ADDRESS(OMAP4430_CM2_BASE + ((module) (MOD_MASK)) + (reg)) #include cm44xx.h diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 995b7ed..b93d33e 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -57,10 +57,26 @@ #define BITFIELD(l_bit, u_bit) \ (BITS(u_bit) ~((BITS(l_bit)) 1)) -/* OMAP44XX specific module offsets */ +/* + * OMAP44XX specific module offsets + * The 16 bit submodule offset is defined for OMAP4 as + * Bit 15 | Bit 14:13 | Bit 12:0 + * Sign bit| base identifier | submodule offset from base + */ -/* CM1 instances */ +#define DEFAULT_BASE 0x0 +#define PRM_BASE 0x1 +#define PRCM_MPU_BASE0x2 +#define CM2_BASE 0x3 +#define BASE_ID_SHIFT13 +#define MOD_MASK ((1 BASE_ID_SHIFT)-1) + +#define PRM_BASE_ID (PRM_BASE BASE_ID_SHIFT) +#define PRCM_MPU_BASE_ID (PRCM_MPU_BASE BASE_ID_SHIFT) +#define CM2_BASE_ID (CM2_BASE BASE_ID_SHIFT) + +/* CM1 instances */ #define OMAP4430_CM1_OCP_SOCKET_MOD 0x #define OMAP4430_CM1_CKGEN_MOD 0x0100 #define OMAP4430_CM1_MPU_MOD 0x0300 @@ -71,19 +87,19 @@ /* CM2 instances */ -#define OMAP4430_CM2_OCP_SOCKET_MOD 0x -#define OMAP4430_CM2_CKGEN_MOD 0x0100 -#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 -#define OMAP4430_CM2_CORE_MOD0x0700 -#define OMAP4430_CM2_IVAHD_MOD 0x0f00 -#define OMAP4430_CM2_CAM_MOD 0x1000 -#define OMAP4430_CM2_DSS_MOD 0x1100 -#define OMAP4430_CM2_GFX_MOD 0x1200 -#define OMAP4430_CM2_L3INIT_MOD 0x1300 -#define OMAP4430_CM2_L4PER_MOD 0x1400 -#define OMAP4430_CM2_CEFUSE_MOD 0x1600 -#define OMAP4430_CM2_RESTORE_MOD 0x1e00 -#define OMAP4430_CM2_INSTR_MOD 0x1f00 +#define
RE: [PATCH] omap2plus: wdt: Fix boot warn when CONFIG_PM_RUNTIME=n
On Thu, 14 Oct 2010, Paul Walmsley wrote:
Enclosed below is a work-in-progress patch to illustrate the proposal.
It clearly needs some more work and should be split into at least two
patches, but it might help clarify what I am proposing.
Here's one important missing piece of the patch that I wanted to
illustrate...
- Paul
From de3b800f9a6db027846f68de3aa4202eb713b391 Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Thu, 14 Oct 2010 12:48:00 -0600
Subject: [RFC PATCH] OMAP2+ hwmod: illustrate pre-shutdown hook
implementation
---
arch/arm/mach-omap2/omap_hwmod.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 618e135..92dd369 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1261,6 +1261,9 @@ int _omap_hwmod_idle(struct omap_hwmod *oh)
*/
static int _shutdown(struct omap_hwmod *oh)
{
+ int ret;
+ u8 prev_state;
+
if (oh-_state != _HWMOD_STATE_IDLE
oh-_state != _HWMOD_STATE_ENABLED) {
WARN(1, omap_hwmod: %s: disabled state can only be entered
@@ -1270,6 +1273,18 @@ static int _shutdown(struct omap_hwmod *oh)
pr_debug(omap_hwmod: %s: disabling\n, oh-name);
+ if (oh-class-pre_shutdown) {
+ prev_state = oh-_state;
+ if (oh-_state == _HWMOD_STATE_IDLE)
+ _omap_hwmod_enable(oh);
+ ret = oh-class-pre_shutdown(oh);
+ if (ret) {
+ if (prev_state == _HWMOD_STATE_IDLE)
+ _omap_hwmod_idle(oh);
+ return ret;
+ }
+ }
+
if (oh-class-sysc)
_shutdown_sysc(oh);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions
On Thu, Oct 14, 2010 at 5:14 AM, Jason Wang jason77.w...@gmail.com wrote: Grazvydas Ignotas wrote: Working here on pandora too, applied on top of linux-next (did not test suspend though). Not caused by this patch, but the old problem where lower measurement bits get lost is back - when I draw diagonal line it looks like stairs. I think it's caused by OMAP SPI driver, CCing linux-omap. Yes, it is OMAP spi driver issues, I have met the same problem before, please refer to: http://www.spinics.net/lists/arm-kernel/msg91538.html you can apply this patch and test again. It solves my issue, thanks Tested-by: Grazvydas Ignotas nota...@gmail.com BTW I have done similar patch almost 2 years ago for exactly the same problem: http://marc.info/?l=linux-omapm=122565580616920w=2 but then problem went away after random kernel update (from what I remember), and my patch was no longer needed. From 393f445ab899abaf5d60a55a54f242c430507047 Mon Sep 17 00:00:00 2001 From: Jason Wang jason77.w...@gmail.com Date: Thu, 14 Oct 2010 10:08:07 +0800 Subject: [PATCH] spi/omap2_mcspi: disable channel after TX_ONLY transfer in PIO mode In TX_ONLY transfer, the SPI controller can also receive data simultaneously and saves them in rx register. After the TX_ONLY transfer, the rx register will hold random data received during last tx transaction. If the next transfer is RX_ONLY, this random data has the possibility to affect this transfer like this: If the spi controller is changed from TX_ONLY to RX_ONLY mode, The random data makes the rx register full imediately and triggers a dummy write (in SPI RX_ONLY transfer, we need a dummy write to trigger the first transaction). So the first data received in RX_ONLY transfer will be that random data instead of something meaningfug. We can avoid this by a Disable/reenable toggle of the spi channel after the TX_ONLY transfer, since it purges the rx register. Signed-off-by: Jason Wang jason77.w...@gmail.com --- drivers/spi/omap2_mcspi.c | 6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c index b3a94ca..43fab41 100644 --- a/drivers/spi/omap2_mcspi.c +++ b/drivers/spi/omap2_mcspi.c @@ -644,6 +644,12 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct spi_transfer *xfer) } else if (mcspi_wait_for_reg_bit(chstat_reg, OMAP2_MCSPI_CHSTAT_EOT) 0) dev_err(spi-dev, EOT timed out\n); + + /* disable chan to purge rx datas received in TX_ONLY transfer, + * otherwise these rx datas will affect the direct following + * RX_ONLY transfer. + */ + omap2_mcspi_set_enable(spi, 0); } out: omap2_mcspi_set_enable(spi, 1); -- 1.5.6.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Difference between twl4030_hsmmc_info and omap_mmc_platform_data
Hi,
I'm trying to bring up a TI WL1271 wlan module connected to MMC2
controller of a TI OMAP 3530 processor.
I am unclear about the difference between the use of twl4030_hsmmc_info and
omap_mmc_platform_data, to set the attributes and constraints for the MMC1
(connected to microSD card) and MMC2 (connected to WLAN module).
The beagleboard uses twl4030_mmc_init, which has a wrapper for
omap_mmc_platform_data defined in mmc-twl4030.h.
The board-sholes-hsmmc.c doesn't use twl4030, but directly uses the
omap_mmc_platform_data structure.
Example:
board-omap3beagle.c uses twl4030_mmc_init, which internally uses the following
structure to define mmc properties.
static struct twl4030_hsmmc_info mmc[] = {
{
.mmc= 1,
.wires = 8,
.gpio_wp= -ENOSYS,
.gpio_cd= -ENOSYS,
.name = MMC1 controller slot
},
{
.mmc= 2,
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
// .transceiver= true,
.name = MMC2 controller slot,
.ocr_mask = 0x0080,
},
{} /* Terminator */
};
For board-sholes-hsmmc.c, it uses a omap_mmc_platform_data
static struct omap_mmc_platform_data mmc1_data = {
.nr_slots = 1,
.init = hsmmc_late_init,
.cleanup= hsmmc_cleanup,
#ifdef CONFIG_PM
.suspend= hsmmc_suspend,
.resume = hsmmc_resume,
#endif
.dma_mask = 0x,
.slots[0] = {
.wires = 8,
.set_power = hsmmc_set_power,
.ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34 |
MMC_VDD_165_195,
.name = first slot,
/* we get car_detect_irq later */
.card_detect_irq= 0,
.card_detect= hsmmc_card_detect,
},
};
#if defined(CONFIG_OMAP_HS_MMC2)
#ifdef CONFIG_MMC_EMBEDDED_SDIO
static struct sdio_embedded_func wifi_func_array[] = {
{
.f_class= SDIO_CLASS_NONE,
.f_maxblksize = 0,
},
{
.f_class= SDIO_CLASS_WLAN,
.f_maxblksize = 512,
},
};
static struct embedded_sdio_data sholes_wifi_emb_data = {
.cis= {
.vendor = 0x104c,
.device = 0x9066,
.blksize= 512,
.max_dtr= 2400,
},
.cccr = {
.multi_block= 1,
.low_speed = 0,
.wide_bus = 1,
.high_power = 0,
.high_speed = 0,
},
.funcs = wifi_func_array,
.num_funcs = 2,
};
#endif
static struct omap_mmc_platform_data mmc2_data = {
.nr_slots = 1,
.init = hsmmc2_late_init,
.cleanup= hsmmc2_cleanup,
#ifdef CONFIG_PM
.suspend= hsmmc2_suspend,
.resume = hsmmc2_resume,
#endif
.dma_mask = 0x,
#ifndef CONFIG_MMC_EMBEDDED_SDIO
.name = TIWLAN_SDIO,
#endif
.slots[0] = {
.wires = 4,
.set_power = hsmmc2_set_power,
.ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34 |
MMC_VDD_165_195,
.name = first slot,
.internal_clock = 1,
.card_detect_irq= 0,
.card_detect= hsmmc2_card_detect,
#ifdef CONFIG_MMC_EMBEDDED_SDIO
.embedded_sdio = sholes_wifi_emb_data,
.register_status_notify = sholes_wifi_status_register,
#endif
},
};
#endif
Best regards,
Elvis Dowson
--
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 02/11] OMAP3: PM: Adding voltage driver support for OMAP3
On Wed, 2010-09-22 at 20:15 +0530, Thara Gopinath wrote:
This patch adds voltage driver support for OMAP3. The driver
allows configuring the voltage controller and voltage
processors during init and exports APIs to enable/disable
voltage processors, scale voltage and reset voltage.
The driver also maintains the global voltage table on a per
VDD basis which contains the various voltages supported by the
VDD along with per voltage dependent data like smartreflex
n-target value, errminlimit and voltage processor errorgain.
The driver allows scaling of VDD voltages either through
vc bypass method or through vp forceupdate method the
choice being configurable through the board file.
This patch contains code originally in linux omap pm branch
smartreflex driver. Major contributors to this driver are
Lesly A M, Rajendra Nayak, Kalle Jokiniemi, Paul Walmsley,
Nishant Menon, Kevin Hilman.
Signed-off-by: Thara Gopinath th...@ti.com
[...]
+/*
+ * Omap3630 specific VP register values. Maybe these need to come from
+ * board file or PMIC data structure
+ */
+#define OMAP3630_VP1_VLIMITTO_VDDMIN 0x18
+#define OMAP3630_VP1_VLIMITTO_VDDMAX 0x3C
+#define OMAP3630_VP2_VLIMITTO_VDDMIN 0x18
+#define OMAP3630_VP2_VLIMITTO_VDDMAX 0x30
+
+/* TODO OMAP4 VP register values if the same file is used for OMAP4*/
+
+/**
+ * voltagedomain - omap voltage domain global structure
+ * @name : Name of the voltage domain which can be used as a unique
+ * identifier.
+ */
+struct voltagedomain {
+ char *name;
+};
Minor: to keep the voltagedomain stuff somewhat separate from the rest
of the voltage layer API, I suggest putting the voltage domain APIs
here:
struct voltagedomain *omap_voltage_domain_get(char *name);
However, I think this function shoul be called _lookup instead of _get
to continue the naming conventions of the powerdomain and clockdomain
code.
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 v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
On Wed, 2010-09-22 at 20:15 +0530, Thara Gopinath wrote: --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -558,8 +558,13 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long volt) return -ENODATA; } - /* errminlimit is opp dependent and hence linked to voltage */ - sr-err_minlimit = volt_data-sr_errminlimit; + /* +* errminlimit is opp dependent and hence linked to voltage +* if the debug option is enabled, the user might have over ridden +* this parameter so do not get it from voltage table +*/ this comment needs better punctuation to be clearer + if (!enable_sr_vp_debug) + sr-err_minlimit = volt_data-sr_errminlimit; Rather than checking if debug is enabled, you should create a flag specific to whether this value was overwritten by the user, and use that flag instead. 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 v3 04/11] OMAP3: PM: Adding smartreflex device file.
On Wed, 2010-09-22 at 20:15 +0530, Thara Gopinath wrote:
This patch adds support for device registration of various
smartreflex module present in the system. This patch introduces
the platform data for smartreflex devices which include
the efused and test n-target vaules, module enable/disable
pointers and a parameter to indicate whether smartreflex
autocompensation needs to be enabled on init or not.
Currently auocompensation is enabled on init by default
for OMAP3430 ES3.1 chip.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/Makefile|2 +-
arch/arm/mach-omap2/sr_device.c | 174
+++
2 files changed, 175 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/sr_device.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8dd32a7..abc377a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -56,7 +56,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= pm34xx.o sleep34xx.o
voltage.o \
cpuidle34xx.o pm_bus.o
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
-obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
+obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
new file mode 100644
index 000..606da59
--- /dev/null
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -0,0 +1,174 @@
+/*
+ * OMAP3/OMAP4 smartreflex device file
+ *
+ * Author: Thara Gopinathth...@ti.com
+ *
+ * Based originally on code from smartreflex.c
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Lesly A M x0080...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/slab.h
+
+#include plat/control.h
+#include plat/omap_device.h
+#include plat/smartreflex.h
+#include plat/voltage.h
+
+static struct omap_device_pm_latency omap_sr_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST
+ },
+};
+
+#ifdef OMAP_SMARTREFLEX_TESTING
+/*
+ * Hard coded nvalues for testing purposes for OMAP3430,
+ * may cause device to hang!
+ */
+static void __init sr_set_nvalues(struct omap_sr_dev_data *dev_data,
+ struct omap_sr_data *sr_data)
+{
+ int i;
+
+ if (!dev_data || !dev_data-volts_supported ||
+ !dev_data-volt_data || !dev_data-test_nvalues) {
+ pr_warning(%s: Bad parameters! dev_data = %x,
+ dev_data-volts_supported = %x,
+ dev_data-volt_data = %x,
+ dev_data-test_nvalues = %x\n, __func__,
+ (unsigned int)dev_data, dev_data-volts_supported,
+ (unsigned int)dev_data-volt_data,
+ (unsigned int)dev_data-test_nvalues);
+ return;
+ }
+
+ sr_data-senn_mod = dev_data-test_sennenable;
+ sr_data-senp_mod = dev_data-test_senpenable;
+ for (i = 0; i dev_data-volts_supported; i++)
+ dev_data-volt_data[i].sr_nvalue = dev_data-test_nvalues[i];
+}
+#else
+/* Read EFUSE values from control registers for OMAP3430 */
+static void __init sr_set_nvalues(struct omap_sr_dev_data *dev_data,
+ struct omap_sr_data *sr_data)
+{
+ int i;
+
+ if (!dev_data || !dev_data-volts_supported || !dev_data-volt_data ||
+ !dev_data-efuse_nvalues_offs) {
+ pr_warning(%s: Bad parameters! dev_data = %x,
+ dev_data-volts_supported = %x,
+ dev_data-volt_data = %x,
+ dev_data-efuse_nvalues_offs = %x\n, __func__,
+ (unsigned int)dev_data, dev_data-volts_supported,
+ (unsigned int)dev_data-volt_data,
+ (unsigned int)dev_data-efuse_nvalues_offs);
+ return;
+ }
+
+ /*
+ * From OMAP3630 onwards there are no efuse registers for senn_mod
+ * and senp_mod. They have to be 0x1 by default.
+ */
+ if (!dev_data-efuse_sr_control) {
+ sr_data-senn_mod = 0x1;
+ sr_data-senp_mod = 0x1;
+ } else {
+ sr_data-senn_mod =
+
Re: [PATCH] OMAP: hmwod: Update the sysc_cache in case module context is lost
Rajendra Nayak rna...@ti.com writes:
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Shouldn't the driver for each IP be responsible for restoring it's
register contents after context loss, including it's SYSC?
Seems to me that if SYSC is lost, it means the driver's save/restore
is buggy.
Kevin
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index cb911d7..e57fe21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -115,7 +115,10 @@ static void _write_sysconfig(u32 v, struct omap_hwmod
*oh)
/* XXX ensure module interface clock is up */
- if (oh-_sysc_cache != v) {
+ if ((oh-_sysc_cache != v) ||
+ /* Did the module go to off and loose context? */
+ (oh-_sysc_cache !=
+ omap_hwmod_readl(oh, oh-class-sysc-sysc_offs))) {
oh-_sysc_cache = v;
omap_hwmod_writel(v, oh, oh-class-sysc-sysc_offs);
}
--
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
Integrating TI WL1271 module with MMC2 controller of TI OMAP 3530
Hi, I'm trying to integrate a LSR TiWi WL1271 wlan module with a custom TI OMAP 3530 beagleboard-based platform. I'm having some trouble with sending commands from the MMC2 controller to the TI WLAN module. I've built the wl1271 kernel and driver from the android-rowboard-froyo-2.2 kernel repo. The tiwlan_loader was created from a separate TI wlan repository. The interface has been registered, but there are some issues with sending commands to it. # insmod tiwlan_drv.ko [ 59.891113] TIWLAN: driver init [ 59.894287] TIWLAN SDIO init [ 59.912658] hPlatform_Wlan_Hardware_Init [ 59.917297] dashboard20_wifi_power: 0 [ 59.935668] drv-irq = 215, 2 r...@beagleboard:/wlan# ./tiwlan_loader r...@beagleboard:/wlan# ls firmware.bin sdio.ko tiwlan.ini tiwlan_drv.ko tiwlan_loader wlan_cu r...@beagleboard:/wlan# ifconfig -a loLink encap:Local Loopback LOOPBACK MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) tiwlan0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) r...@beagleboard:/wlan# ifconfig tiwlan0 up [ 155.564697] wlanDrvIf_Open [ 155.567504] wlanDrvIf_Start [ 155.703765] TIWLAN: 2399.885440: pInitParams-RoamingScanning_2_4G_enable 0 [ 155.711181] dashboard20_wifi_power: 1 [ 155.729522] dashboard20_wifi_power: 0 [ 155.734222] dashboard20_wifi_power: 1 [ 155.806274] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b4130 [ 155.814025] Internal error: : 1028 [#1] [ 155.817871] last sysfs file: /sys/devices/virtual/net/tiwlan0/flags [ 155.824188] Modules linked in: tiwlan_drv [ 155.828247] CPU: 0Not tainted (2.6.32 #19) [ 155.833923] PC is at sdioDrv_ExecuteCmd+0x74/0xec [tiwlan_drv] [ 155.839782] LR is at 0x480b4000 [ 155.842956] pc : [bf005758]lr : [480b4000]psr: a013 [ 155.842956] sp : c524dd48 ip : c350 fp : c73e2b0c [ 155.854522] r10: 0001 r9 : c73e2b04 r8 : c524dd7f [ 155.859771] r7 : r6 : r5 : r4 : [ 155.866333] r3 : r2 : fa0b4108 r1 : fa0b410c r0 : fa0b4130 [ 155.872894] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 155.880065] Control: 10c5387d Table: 87308019 DAC: 0015 [ 155.885864] [ 155.885864] SP: 0xc524dcc8: [ 155.890136] dcc8 c0043a04 c703f510 c524dcf4 c524dd04 c0043a04 c0043a90 c524dd28 6013 [ 155.898437] dce8 c524dd34 c524dd7f c003faec fa0b4130 fa0b410c [ 155.906738] dd08 fa0b4108 c524dd7f c73e2b04 [ 155.915039] dd28 0001 c73e2b0c c350 c524dd48 480b4000 bf005758 a013 [ 155.923339] dd48 00fb 0200 0001 bf07ded0 c524dd7f 00fb [ 155.931640] dd68 0200 bf0062a8 0001 c524dd80 c00729ac c0068b64 c729b9e0 c729b814 [ 155.939941] dd88 0001 c73e2b04 0002 c73e2b04 c729ba00 bf07e08c c729b9d4 c729b9d8 [ 155.948211] dda8 c729b9dc c729b9e0 c716cb14 bf07d6d4 bf07c6ac c73e2b0c [ 155.956512] [ 155.956512] FP: 0xc73e2a8c: [ 155.960815] 2a8c c7168e14 c7168414 c7316b54 c7b6e3d4 c711e014 c7174014 c716c754 c73c6414 [ 155.969116] 2aac c5200d94 c716cb14 0002 0002 0001 0001 [ 155.977416] 2acc bf007158 c73e2a14 [ 155.985717] 2aec 0006 0001 c7289454 0009 00fb [ 155.994018] 2b0c 6d656d65 [ 156.002288] 2b2c [ 156.010589] 2b4c [ 156.018890] 2b6c [ 156.027191] [ 156.027191] R0: 0xfa0b40b0: [ 156.031494] 40b0 [ 156.039794] 40d0 [ 156.048095] 40f0 [ 156.056396] 4110 [ 156.064697] 4130 [ 156.072998] 4150 [ 156.081298] 4170 [ 156.089599] 4190
Re: [PATCH v3 06/11] OMAP3: PM: Adding smartreflex class3 driver
Thara Gopinath th...@ti.com writes:
Smartreflex Class3 implementation continuously monitors
silicon performance and instructs the Voltage Processors
to increase or decrease the voltage.
This patch adds smartreflex class 3 driver. This driver hooks
up with the generic smartreflex driver smartreflex.c to abstract
out class specific implementations out of the generic driver.
Signed-off-by: Thara Gopinath th...@ti.com
Some minor comments below...
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/smartreflex-class3.c | 61
++
arch/arm/mach-omap2/smartreflex-class3.h | 23 +++
arch/arm/plat-omap/Kconfig |9
4 files changed, 94 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/smartreflex-class3.c
create mode 100644 arch/arm/mach-omap2/smartreflex-class3.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index abc377a..4f6139c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= pm34xx.o sleep34xx.o
voltage.o \
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o pm_bus.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
+obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
new file mode 100644
index 000..f1ade08
--- /dev/null
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -0,0 +1,61 @@
+/*
+ * Smart reflex Class 3 specific implementations
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include plat/smartreflex.h
+
+#include smartreflex-class3.h
+
+static int sr_class3_enable(struct voltagedomain *voltdm)
+{
+ unsigned long volt = 0;
minor: '= 0' assignment not needed as it's immediately assigned in the
next line.
+ volt = omap_voltage_get_nom_volt(voltdm);
+ if (!volt) {
+ pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
+ __func__, voltdm-name);
+ return -ENODATA;
+ }
+
+ omap_vp_enable(voltdm);
+ return sr_enable(voltdm, volt);
+}
+
+static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
+{
+ omap_vp_disable(voltdm);
+ sr_disable(voltdm);
+ if (is_volt_reset)
+ omap_voltage_reset(voltdm);
+
+ return 0;
+}
+
+static int sr_class3_configure(struct voltagedomain *voltdm)
+{
+ return sr_configure_errgen(voltdm);
+}
+
+/* SR class3 structure */
+static struct omap_smartreflex_class_data class3_data = {
+ .enable = sr_class3_enable,
+ .disable = sr_class3_disable,
+ .configure = sr_class3_configure,
+ .class_type = SR_CLASS3,
+};
+
+/* Smartreflex CLASS3 init API to be called from board file */
s/CLASS3/Class 3/
+int __init sr_class3_init(void)
+{
+ pr_info(SmartReflex CLASS3 initialized\n);
ditto
+ return sr_register_class(class3_data);
+}
diff --git a/arch/arm/mach-omap2/smartreflex-class3.h
b/arch/arm/mach-omap2/smartreflex-class3.h
new file mode 100644
index 000..4d86037
--- /dev/null
+++ b/arch/arm/mach-omap2/smartreflex-class3.h
@@ -0,0 +1,23 @@
+/*
+ * Smartreflex Class 3 Routines
+ *
+ * Author: Thara Gopinath th...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Thara Gopinath th...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_SMARTREFLEXCLASS3_H
+#define __ARCH_ARM_MACH_OMAP2_SMARTREFLEXCLASS3_H
+
+#ifdef CONFIG_OMAP_SMARTREFLEX_CLASS3
+int sr_class3_init(void);
+#else
+static int sr_class3_init(void) { return 0; }
+#endif
+
+#endif
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 8056349..af7acc9 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -67,6 +67,15 @@ config OMAP_SMARTREFLEX_TESTING
WARNING: Enabling this option may cause your device to hang!
+config OMAP_SMARTREFLEX_CLASS3
+ bool Class 3 mode of Smartreflex Implementation
+ depends on OMAP_SMARTREFLEX TWL4030_CORE
+ help
+ Say Y to enable Class 3 implementation of Smartreflex
+
+ Class 3 implementation of Smartreflex employs
Re: Difference between twl4030_hsmmc_info and omap_mmc_platform_data
Hi Nishanth, On Oct 15, 2010, at 2:56 AM, Nishanth Menon wrote: Dont have a board-sholes-hsmm.c in l-o[1]... :( so not sure which kernel you are talking about here. This is in the omapzoom, p-android-omap-2.6.32 branch http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=arch/arm/mach-omap2;h=c64c82c9c28c33f925ce59f1c5c471f7fa8ac0c3;hb=refs/heads/p-android-omap-2.6.32 mainline does it this way: board files report using omap2_hsmmc_info[2] to hsmmc.c using omap2_hsmmc_init[3] - hsmmc.c converts them to required datastructures that omap_hsmmc.c uses.. Which structure should I fill and use? I tried with omap_mmc_platform_data alone without the twl4030 and it didn't boot from the microSD card. Is it because the twl4030 regulator is required as indicated in the TRM for MMC1? Best regards, Elvis -- 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: Difference between twl4030_hsmmc_info and omap_mmc_platform_data
Elvis Dowson had written, on 10/14/2010 06:08 PM, the following: Hi Nishanth, On Oct 15, 2010, at 2:56 AM, Nishanth Menon wrote: Dont have a board-sholes-hsmm.c in l-o[1]... :( so not sure which kernel you are talking about here. This is in the omapzoom, p-android-omap-2.6.32 branch http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=arch/arm/mach-omap2;h=c64c82c9c28c33f925ce59f1c5c471f7fa8ac0c3;hb=refs/heads/p-android-omap-2.6.32 Cant really help you with this kernel as I am not familiar with that code. I recommend [1] instead. Ref: [1] https://gforge.ti.com/gf/project/omapandroid/mailman/?action=ListThreadsmailman_id=22 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Difference between twl4030_hsmmc_info and omap_mmc_platform_data
Elvis Dowson had written, on 10/14/2010 06:18 PM, the following: Hi, On Oct 15, 2010, at 2:56 AM, Nishanth Menon wrote: mainline does it this way: board files report using omap2_hsmmc_info[2] to hsmmc.c using omap2_hsmmc_init[3] - hsmmc.c converts them to required datastructures that omap_hsmmc.c uses.. What is the relationship between twl4030 and hsmmc controller in this chain, especially with respect to MMC2? As far as I know, card detection and power supply. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 08/11] OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
Thara Gopinath th...@ti.com writes:
This patch adds debug support to the voltage and smartreflex drivers.
This means a whole bunch of voltage processor and smartreflex
parameters are now visible through the pm debugfs. By default
only a read of these parameters are permitted. If you need to
write into them then
echo 1 /pm_debug/enable_sr_vp_debug
Why a read-only interface by default? As a debug interface it seems
redundant to have to enable it.
The voltage parameters can be viewed at
/pm_debug/voltage/vdd_x/parameter
and the smartreflex parameters can be viewed at
/pm_debug/smartreflex/sr_x/parameter
where x is mpu or core for OMAP3.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm-debug.c| 15 ++
arch/arm/mach-omap2/smartreflex.c | 40 +-
arch/arm/mach-omap2/voltage.c | 210
-
arch/arm/plat-omap/include/plat/smartreflex.h |1 -
arch/arm/plat-omap/include/plat/voltage.h |5 +
5 files changed, 264 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 390f1c6..879efb2 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -32,6 +32,7 @@
#include plat/powerdomain.h
#include plat/clockdomain.h
#include plat/dmtimer.h
+#include plat/voltage.h
#include prm.h
#include cm.h
@@ -586,6 +587,18 @@ static int option_set(void *data, u64 val)
omap3_pm_off_mode_enable(val);
}
+ if (option == enable_sr_vp_debug val)
+ pr_notice(Beware that enabling this option will allow user
+ to override the system defined vp and sr parameters
+ All the updated parameters will take effect next
+ time smartreflex is enabled. Also this option
+ disables the automatic vp errorgain and sr errormin
+ limit changes as per the voltage. Users will have
+ to explicitly write values into the debug fs
+ entries corresponding to these if they want to see
+ them changing according to the VDD voltage\n);
+
+
return 0;
}
@@ -642,6 +655,8 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(wakeup_timer_milliseconds,
S_IRUGO | S_IWUGO, d, wakeup_timer_milliseconds,
pm_dbg_option_fops);
+ (void) debugfs_create_file(enable_sr_vp_debug, S_IRUGO | S_IWUGO, d,
+ enable_sr_vp_debug, pm_dbg_option_fops);
pm_dbg_main_dir = d;
pm_dbg_init_done = 1;
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7fc3138..b5a7878 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -558,8 +558,13 @@ int sr_enable(struct voltagedomain *voltdm, unsigned
long volt)
return -ENODATA;
}
- /* errminlimit is opp dependent and hence linked to voltage */
- sr-err_minlimit = volt_data-sr_errminlimit;
+ /*
+ * errminlimit is opp dependent and hence linked to voltage
+ * if the debug option is enabled, the user might have over ridden
+ * this parameter so do not get it from voltage table
+ */
+ if (!enable_sr_vp_debug)
+ sr-err_minlimit = volt_data-sr_errminlimit;
/* Enable the clocks */
if (!sr-sr_enable) {
@@ -811,9 +816,34 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return 0;
}
+static int omap_sr_params_show(void *data, u64 *val)
+{
+ u32 *param = data;
+
+ *val = *param;
+ return 0;
+}
+
+static int omap_sr_params_store(void *data, u64 val)
+{
+ if (enable_sr_vp_debug) {
+ u32 *option = data;
insert blank line
+ *option = val;
+ } else {
+ pr_notice(%s: DEBUG option not enabled!\n \
you don't need a '\' to continue strings onto new lines. Just end the
string, and start another on the next line, as you've done elsewhere in
the patch.
+ echo 1 pm_debug/enable_sr_vp_debug - to enable\n,
+ __func__);
+ }
+
+ return 0;
+}
+
DEFINE_SIMPLE_ATTRIBUTE(pm_sr_fops, omap_sr_autocomp_show,
omap_sr_autocomp_store, %llu\n);
+DEFINE_SIMPLE_ATTRIBUTE(sr_params_fops, omap_sr_params_show,
+ omap_sr_params_store, %llu\n);
+
static int __init omap_smartreflex_probe(struct platform_device *pdev)
{
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
@@ -907,6 +937,12 @@ static int __init omap_smartreflex_probe(struct
platform_device *pdev)
(void) debugfs_create_file(autocomp, S_IRUGO | S_IWUGO, dbg_dir,
(void *)sr_info, pm_sr_fops);
+
Re: [PATCH v3 10/11] OMAP3: PM: Program correct init voltages for VDD1 and VDD2
Thara Gopinath th...@ti.com writes:
By default the system boots up at nominal voltage for every
voltage domain in the system. This patch puts VDD1 and VDD2
to the correct boot up voltage as per the opp tables specified.
This patch implements this by matching the rate of the main clock
of the voltage domain with the opp table and picking up the correct
voltage.
Signed-off-by: Thara Gopinath th...@ti.com
For de-coupling the init from OPP, I like this approach better. Thanks.
Minor comment below...
---
arch/arm/mach-omap2/pm.c | 67
+-
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 71c5a77..86c7bf1 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -13,6 +13,7 @@
#include linux/init.h
#include linux/io.h
#include linux/err.h
+#include linux/clk.h
#include plat/omap-pm.h
#include plat/omap_device.h
@@ -20,6 +21,7 @@
#include plat/powerdomain.h
#include plat/clockdomain.h
+#include plat/voltage.h
#include pm.h
@@ -138,12 +140,75 @@ err:
return ret;
}
+/*
+ * This is to be called during init to put the various voltage
+ * domains to the voltage as per the opp table. Typically we boot up
+ * at the nominal voltage. So this function finds out the rate of
+ * the clock associated with the voltage domain, finds out the correct
+ * opp entry and puts the voltage domain to the voltage specifies
+ * in the opp entry
+ */
+static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
+ struct device *dev)
+{
+ struct voltagedomain *voltdm;
+ struct clk *_clk;
s/_clk/clk/
+ struct omap_opp *opp;
+ unsigned long freq, bootup_volt;
+
+ if (!vdd_name || !clk_name || !dev) {
+ printk(KERN_ERR %s: Invalid parameters!\n, __func__);
+ goto exit;
+ }
+
+ voltdm = omap_voltage_domain_get(vdd_name);
+ if (IS_ERR(voltdm)) {
+ printk(KERN_ERR %s: Unable to get vdd pointer for vdd_%s\n,
+ __func__, vdd_name);
+ goto exit;
+ }
+
+ _clk = clk_get(NULL, clk_name);
+ if (IS_ERR(_clk)) {
+ printk(KERN_ERR %s: unable to get clk %s\n,
+ __func__, clk_name);
+ goto exit;
+ }
+
+ freq = _clk-rate;
+ opp = opp_find_freq_ceil(dev, freq);
+ if (IS_ERR(opp)) {
+ printk(KERN_ERR %s: unable to find boot up OPP for vdd_%s\n,
+ __func__, vdd_name);
+ goto exit;
+ }
+
+ bootup_volt = opp_get_voltage(opp);
+ if (!bootup_volt) {
+ printk(KERN_ERR %s: unable to find voltage corresponding
+ to the bootup OPP for vdd_%s\n, __func__, vdd_name);
+ goto exit;
+ }
+
+ omap_voltage_scale_vdd(voltdm, bootup_volt);
+
+ return 0;
+
+exit:
+ printk(KERN_ERR %s: Unable to put vdd_%s to its init voltage\n\n,
+ __func__, vdd_name);
+ return -EINVAL;
+}
+
static int __init omap2_common_pm_init(void)
{
omap2_init_processor_devices();
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx()) {
omap3_pm_init_opp_table();
+ omap2_set_init_voltage(mpu, dpll1_ck, mpu_dev);
+ omap2_set_init_voltage(core, l3_ick, l3_dev);
+ }
omap_pm_if_init();
--
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: [Omapandroid-discussion] Difference between twl4030_hsmmc_infoand omap_mmc_platform_data
-Original Message- From: omapandroid-discussion-boun...@gforge.ti.com [mailto:omapandroid- discussion-boun...@gforge.ti.com] On Behalf Of Elvis Dowson Sent: Thursday, October 14, 2010 6:19 PM To: Nishanth Menon Cc: Linux OMAP Mailing List; omapandroid-discuss...@omapzoom.org Subject: Re: [Omapandroid-discussion] Difference between twl4030_hsmmc_infoand omap_mmc_platform_data Hi, On Oct 15, 2010, at 2:56 AM, Nishanth Menon wrote: mainline does it this way: board files report using omap2_hsmmc_info[2] to hsmmc.c using omap2_hsmmc_init[3] - hsmmc.c converts them to required datastructures that omap_hsmmc.c uses.. What is the relationship between twl4030 and hsmmc controller in this chain, especially with respect to MMC2? Twl4030 is the power chip. Its LDOs are modeled through the regulator framework used by MMC1 and MMC2. On OMAP3 the card detect is from the GPIO module of twl4030. Regards, Madhu Best regards, Elvis ___ Omapandroid-discussion mailing list omapandroid-discuss...@gforge.ti.com https://gforge.ti.com/mailman/listinfo/omapandroid-discussion -- 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/7] omap:mailbox-fix checkpatch warnings
Fix the checkpatch warnings observed in mailbox module Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/plat-omap/mailbox.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 9ce3570..ed960c1 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -279,11 +279,11 @@ static int omap_mbox_startup(struct omap_mbox *mbox) return 0; - fail_alloc_rxq: +fail_alloc_rxq: mbox_queue_free(mbox-txq); - fail_alloc_txq: +fail_alloc_txq: free_irq(mbox-irq, mbox); - fail_request_irq: +fail_request_irq: if (mbox-ops-shutdown) mbox-ops-shutdown(mbox); @@ -394,7 +394,8 @@ static int __init omap_mbox_init(void) /* kfifo size sanity check: alignment and minimal size */ mbox_kfifo_size = ALIGN(mbox_kfifo_size, sizeof(mbox_msg_t)); - mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, sizeof(mbox_msg_t)); + mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, + sizeof(mbox_msg_t)); return 0; } -- 1.7.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 0/7] omap:mailbox-enhancements and fixes
Resending the patch set copying linux arm mailing list. please ignore the previous patchset. [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37214.html] This patch set includes following mailbox enhancements and fixes. - Fix in RX interrupt disable mechanism for OMAP4 - Fix checkpatch warnings - Resolve multiple receiver problem in OMAP4 where there is only one interrupt line shared between Ducati and Tesla. - Protect the Mailbox's internal callback function pointer from being set directly by Users. Added option for multiple listeners on a mailbox instance. - Send Mailbox message in Process context to avoid the latency involved in scheduling Tasklet for every Mailbox message. Schedule Tasklet only when the mailbox fifo is full - There is no explicit mailbox configuration register to enable mailbox clocks. Define a dummy clock for mailbox to avoid addign cpu check for omap4 in mailbox driver. - The patch from Fernando was sent to LO, but looks like it didn't get merged, resending the patch after revising and rebasing. https://patchwork.kernel.org/patch/105650/ Fernando Guzman Lugo (1): mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (6): omap:mailbox: fix rx interrupt disable in omap4 omap:mailbox-fix checkpatch warnings omap:mailbox-send message in process context omap:mailbox-resolve multiple receiver problem omap:mailbox-add notification support for multiple readers omap:clocks44x-add dummy clock for mailbox arch/arm/mach-omap2/clock44xx_data.c |1 + arch/arm/mach-omap2/mailbox.c |5 +- arch/arm/plat-omap/include/plat/mailbox.h | 10 ++- arch/arm/plat-omap/mailbox.c | 148 + 4 files changed, 98 insertions(+), 66 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] mailbox: change full flag per mailbox queue instead of global
From: Fernando Guzman Lugo x0095...@ti.com
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to the latest.
Version 3:
- Remove spin_lock protection. When the full flag is
true the interrupt for that mailbox is disabled. So there
is no race condition if full flag is modified before
calling omap_mbox_enable_irq.
Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..13f2ef3 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..9ce3570 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -148,6 +147,10 @@ static void mbox_rx_work(struct work_struct *work)
if (mq-callback)
mq-callback((void *)msg);
+ if (mq-full) {
+ mq-full = false;
+ omap_mbox_enable_irq(mq-mbox, IRQ_RX);
+ }
}
}
@@ -170,7 +173,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq-full = true;
goto nomem;
}
--
1.7.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 4/7] omap:mailbox-send message in process context
Schedule the Tasklet to send only when mailbox fifo is full, else
send the message in the Process context. This would avoid
needless scheduling of Tasklet for every message transfer
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/mailbox.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index ed960c1..a4170c7 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -92,20 +92,25 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t
msg)
struct omap_mbox_queue *mq = mbox-txq;
int ret = 0, len;
- spin_lock(mq-lock);
+ spin_lock_bh(mq-lock);
if (kfifo_avail(mq-fifo) sizeof(msg)) {
ret = -ENOMEM;
goto out;
}
+ if (!__mbox_poll_for_space(mbox)) {
+ mbox_fifo_write(mbox, msg);
+ goto out;
+ }
+
len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
tasklet_schedule(mbox-txq-tasklet);
out:
- spin_unlock(mq-lock);
+ spin_unlock_bh(mq-lock);
return ret;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
--
1.7.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/7] omap:mailbox: fix rx interrupt disable in omap4
disabling rx interrupt on omap4 is different than its pre-decessors. The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the interrupts instead of clearing the bit. Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..82b5ced 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -195,7 +195,10 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv; u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; l = mbox_read_reg(p-irqdisable); - l = ~bit; + if (cpu_is_omap44xx()) + l |= bit; + else + l = ~bit; mbox_write_reg(l, p-irqdisable); } -- 1.7.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 5/7] omap:mailbox-resolve multiple receiver problem
OMAP4 shares one interrupt line for all the mailbox instances.
The ISR is handling only the mailbox instance that was registered last.
So if both mailbox instances are running at the same time, the first mailbox
that registered wouldn't get the mailbox message. The same issue is present
in Transmit Interrupt case too. Only the last registered mailbox is handled.
The fix is to iterate through the list of mailboxes that were registered
checking for the mailbox TX and RX interrupt source.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ramesh Gupta grgu...@ti.com
Signed-off-by: Subramaniam C.A subramaniam...@ti.com
---
arch/arm/plat-omap/mailbox.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index a4170c7..1727548 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -174,6 +174,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
struct omap_mbox_queue *mq = mbox-rxq;
mbox_msg_t msg;
int len;
+ bool msg_rx = false;
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
@@ -181,7 +182,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
mq-full = true;
goto nomem;
}
-
+ msg_rx = true;
msg = mbox_fifo_read(mbox);
len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
@@ -192,21 +193,25 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
}
/* no more messages in the fifo. clear IRQ source. */
- ack_mbox_irq(mbox, IRQ_RX);
+ if (msg_rx)
+ ack_mbox_irq(mbox, IRQ_RX);
nomem:
- queue_work(mboxd, mbox-rxq-work);
+ if (msg_rx)
+ queue_work(mboxd, mbox-rxq-work);
}
static irqreturn_t mbox_interrupt(int irq, void *p)
{
struct omap_mbox *mbox = p;
- if (is_mbox_irq(mbox, IRQ_TX))
- __mbox_tx_interrupt(mbox);
-
- if (is_mbox_irq(mbox, IRQ_RX))
- __mbox_rx_interrupt(mbox);
+ for (i = 0; mboxes[i]; i++) {
+ struct omap_mbox *mbox = mboxes[i];
+ if (is_mbox_irq(mbox, IRQ_TX))
+ __mbox_tx_interrupt(mbox);
+ if (is_mbox_irq(mbox, IRQ_RX))
+ __mbox_rx_interrupt(mbox);
+ }
return IRQ_HANDLED;
}
--
1.7.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 6/7] omap:mailbox-add notification support for multiple readers
In the current mailbox driver, the mailbox internal pointer for
callback can be directly manipulated by the Users, so a second
User can easily corrupt the first user's callback pointer.
The initial effort to correct this issue can be referred here:
https://patchwork.kernel.org/patch/107520/
Along with fixing the above stated issue, this patch adds the
flexibility option to register notifications from
multiple readers to the events received on a mailbox instance.
The discussion regarding this can be referred here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |9 ++-
arch/arm/plat-omap/mailbox.c | 102 -
2 files changed, 62 insertions(+), 49 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 13f2ef3..4c35654 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -8,6 +8,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/kfifo.h
+#include linux/notifier.h
typedef u32 mbox_msg_t;
struct omap_mbox;
@@ -46,7 +47,6 @@ struct omap_mbox_queue {
struct kfifofifo;
struct work_struct work;
struct tasklet_struct tasklet;
- int (*callback)(void *);
struct omap_mbox*mbox;
bool full;
};
@@ -58,13 +58,16 @@ struct omap_mbox {
struct omap_mbox_ops*ops;
struct device *dev;
void*priv;
+
+ int use_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
int omap_mbox_unregister(void);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 1727548..35956f5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -28,6 +28,7 @@
#include linux/slab.h
#include linux/kfifo.h
#include linux/err.h
+#include linux/notifier.h
#include plat/mailbox.h
@@ -150,8 +151,8 @@ static void mbox_rx_work(struct work_struct *work)
len = kfifo_out(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
- if (mq-callback)
- mq-callback((void *)msg);
+ blocking_notifier_call_chain(mq-mbox-notifier, len,
+ (void *)msg);
if (mq-full) {
mq-full = false;
omap_mbox_enable_irq(mq-mbox, IRQ_RX);
@@ -202,7 +203,7 @@ nomem:
static irqreturn_t mbox_interrupt(int irq, void *p)
{
- struct omap_mbox *mbox = p;
+ int i;
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
@@ -252,41 +253,39 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
int ret = 0;
struct omap_mbox_queue *mq;
- if (mbox-ops-startup) {
- mutex_lock(mbox_configured_lock);
- if (!mbox_configured)
+ mutex_lock(mbox_configured_lock);
+ if (!mbox_configured++) {
+ if (likely(mbox-ops-startup)) {
ret = mbox-ops-startup(mbox);
-
- if (ret) {
- mutex_unlock(mbox_configured_lock);
- return ret;
+ if (unlikely(ret))
+ goto fail_startup;
}
- mbox_configured++;
- mutex_unlock(mbox_configured_lock);
}
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (ret) {
- printk(KERN_ERR
- failed to register mailbox interrupt:%d\n, ret);
- goto fail_request_irq;
- }
-
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox-txq = mq;
+ if (!mbox-use_count++) {
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ pr_err(failed to register mailbox interrupt:%d\n,
+ ret);
+ goto fail_request_irq;
+ }
+
[PATCH 2/7] omap:mailbox: fix rx interrupt disable in omap4
disabling rx interrupt on omap4 is different than its pre-decessors. The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the interrupts instead of clearing the bit. Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..82b5ced 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -195,7 +195,10 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv; u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; l = mbox_read_reg(p-irqdisable); - l = ~bit; + if (cpu_is_omap44xx()) + l |= bit; + else + l = ~bit; mbox_write_reg(l, p-irqdisable); } -- 1.7.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 7/7] omap:clocks44x-add dummy clock for mailbox
In omap4, there is no explicit configuration register to enable mailbox clocks.
Defining dummy clock for mailbox clock module to keep the mailbox driver
backward compatible with previous omaps.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..421ae7f 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2687,6 +2687,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_ick,dummy_ck,
CK_443X),
CLK(NULL, uart4_ick,dummy_ck,
CK_443X),
CLK(omap_wdt, ick, dummy_ck,
CK_443X),
+ CLK(NULL, mailboxes_ick,dummy_ck,
CK_443X),
};
int __init omap4xxx_clk_init(void)
--
1.7.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 3/7] omap:mailbox-fix checkpatch warnings
Fix the checkpatch warnings observed in mailbox module Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/plat-omap/mailbox.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 9ce3570..ed960c1 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -279,11 +279,11 @@ static int omap_mbox_startup(struct omap_mbox *mbox) return 0; - fail_alloc_rxq: +fail_alloc_rxq: mbox_queue_free(mbox-txq); - fail_alloc_txq: +fail_alloc_txq: free_irq(mbox-irq, mbox); - fail_request_irq: +fail_request_irq: if (mbox-ops-shutdown) mbox-ops-shutdown(mbox); @@ -394,7 +394,8 @@ static int __init omap_mbox_init(void) /* kfifo size sanity check: alignment and minimal size */ mbox_kfifo_size = ALIGN(mbox_kfifo_size, sizeof(mbox_msg_t)); - mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, sizeof(mbox_msg_t)); + mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, + sizeof(mbox_msg_t)); return 0; } -- 1.7.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 0/7] omap:mailbox-enhancements and fixes
My apologies for spamming linux omap. Resending again with the patch set copying correct linux arm mailing list. please ignore the previous patchsets. [http://www.spinics.net/lists/linux-omap/msg38782.html] [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37214.html] This patch set includes following mailbox enhancements and fixes. - Fix in RX interrupt disable mechanism for OMAP4 - Fix checkpatch warnings - Resolve multiple receiver problem in OMAP4 where there is only one interrupt line shared between Ducati and Tesla. - Protect the Mailbox's internal callback function pointer from being set directly by Users. Added option for multiple listeners on a mailbox instance. - Send Mailbox message in Process context to avoid the latency involved in scheduling Tasklet for every Mailbox message. Schedule Tasklet only when the mailbox fifo is full - There is no explicit mailbox configuration register to enable mailbox clocks. Define a dummy clock for mailbox to avoid addign cpu check for omap4 in mailbox driver. - The patch from Fernando was sent to LO, but looks like it didn't get merged, resending the patch after revising and rebasing. https://patchwork.kernel.org/patch/105650/ Fernando Guzman Lugo (1): mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (6): omap:mailbox: fix rx interrupt disable in omap4 omap:mailbox-fix checkpatch warnings omap:mailbox-send message in process context omap:mailbox-resolve multiple receiver problem omap:mailbox-add notification support for multiple readers omap:clocks44x-add dummy clock for mailbox arch/arm/mach-omap2/clock44xx_data.c |1 + arch/arm/mach-omap2/mailbox.c |5 +- arch/arm/plat-omap/include/plat/mailbox.h | 10 ++- arch/arm/plat-omap/mailbox.c | 148 + 4 files changed, 98 insertions(+), 66 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] omap:mailbox-send message in process context
Schedule the Tasklet to send only when mailbox fifo is full, else
send the message in the Process context. This would avoid
needless scheduling of Tasklet for every message transfer
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/mailbox.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index ed960c1..a4170c7 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -92,20 +92,25 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t
msg)
struct omap_mbox_queue *mq = mbox-txq;
int ret = 0, len;
- spin_lock(mq-lock);
+ spin_lock_bh(mq-lock);
if (kfifo_avail(mq-fifo) sizeof(msg)) {
ret = -ENOMEM;
goto out;
}
+ if (!__mbox_poll_for_space(mbox)) {
+ mbox_fifo_write(mbox, msg);
+ goto out;
+ }
+
len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
tasklet_schedule(mbox-txq-tasklet);
out:
- spin_unlock(mq-lock);
+ spin_unlock_bh(mq-lock);
return ret;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
--
1.7.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 1/7] mailbox: change full flag per mailbox queue instead of global
From: Fernando Guzman Lugo x0095...@ti.com
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to the latest.
Version 3:
- Remove spin_lock protection. When the full flag is
true the interrupt for that mailbox is disabled. So there
is no race condition if full flag is modified before
calling omap_mbox_enable_irq.
Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..13f2ef3 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..9ce3570 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -148,6 +147,10 @@ static void mbox_rx_work(struct work_struct *work)
if (mq-callback)
mq-callback((void *)msg);
+ if (mq-full) {
+ mq-full = false;
+ omap_mbox_enable_irq(mq-mbox, IRQ_RX);
+ }
}
}
@@ -170,7 +173,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq-full = true;
goto nomem;
}
--
1.7.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 6/7] omap:mailbox-add notification support for multiple readers
In the current mailbox driver, the mailbox internal pointer for
callback can be directly manipulated by the Users, so a second
User can easily corrupt the first user's callback pointer.
The initial effort to correct this issue can be referred here:
https://patchwork.kernel.org/patch/107520/
Along with fixing the above stated issue, this patch adds the
flexibility option to register notifications from
multiple readers to the events received on a mailbox instance.
The discussion regarding this can be referred here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |9 ++-
arch/arm/plat-omap/mailbox.c | 102 -
2 files changed, 62 insertions(+), 49 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 13f2ef3..4c35654 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -8,6 +8,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/kfifo.h
+#include linux/notifier.h
typedef u32 mbox_msg_t;
struct omap_mbox;
@@ -46,7 +47,6 @@ struct omap_mbox_queue {
struct kfifofifo;
struct work_struct work;
struct tasklet_struct tasklet;
- int (*callback)(void *);
struct omap_mbox*mbox;
bool full;
};
@@ -58,13 +58,16 @@ struct omap_mbox {
struct omap_mbox_ops*ops;
struct device *dev;
void*priv;
+
+ int use_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
int omap_mbox_unregister(void);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 1727548..35956f5 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -28,6 +28,7 @@
#include linux/slab.h
#include linux/kfifo.h
#include linux/err.h
+#include linux/notifier.h
#include plat/mailbox.h
@@ -150,8 +151,8 @@ static void mbox_rx_work(struct work_struct *work)
len = kfifo_out(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
- if (mq-callback)
- mq-callback((void *)msg);
+ blocking_notifier_call_chain(mq-mbox-notifier, len,
+ (void *)msg);
if (mq-full) {
mq-full = false;
omap_mbox_enable_irq(mq-mbox, IRQ_RX);
@@ -202,7 +203,7 @@ nomem:
static irqreturn_t mbox_interrupt(int irq, void *p)
{
- struct omap_mbox *mbox = p;
+ int i;
for (i = 0; mboxes[i]; i++) {
struct omap_mbox *mbox = mboxes[i];
@@ -252,41 +253,39 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
int ret = 0;
struct omap_mbox_queue *mq;
- if (mbox-ops-startup) {
- mutex_lock(mbox_configured_lock);
- if (!mbox_configured)
+ mutex_lock(mbox_configured_lock);
+ if (!mbox_configured++) {
+ if (likely(mbox-ops-startup)) {
ret = mbox-ops-startup(mbox);
-
- if (ret) {
- mutex_unlock(mbox_configured_lock);
- return ret;
+ if (unlikely(ret))
+ goto fail_startup;
}
- mbox_configured++;
- mutex_unlock(mbox_configured_lock);
}
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (ret) {
- printk(KERN_ERR
- failed to register mailbox interrupt:%d\n, ret);
- goto fail_request_irq;
- }
-
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox-txq = mq;
+ if (!mbox-use_count++) {
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ pr_err(failed to register mailbox interrupt:%d\n,
+ ret);
+ goto fail_request_irq;
+ }
+
[PATCH 5/7] omap:mailbox-resolve multiple receiver problem
OMAP4 shares one interrupt line for all the mailbox instances.
The ISR is handling only the mailbox instance that was registered last.
So if both mailbox instances are running at the same time, the first mailbox
that registered wouldn't get the mailbox message. The same issue is present
in Transmit Interrupt case too. Only the last registered mailbox is handled.
The fix is to iterate through the list of mailboxes that were registered
checking for the mailbox TX and RX interrupt source.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ramesh Gupta grgu...@ti.com
Signed-off-by: Subramaniam C.A subramaniam...@ti.com
---
arch/arm/plat-omap/mailbox.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index a4170c7..1727548 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -174,6 +174,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
struct omap_mbox_queue *mq = mbox-rxq;
mbox_msg_t msg;
int len;
+ bool msg_rx = false;
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
@@ -181,7 +182,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
mq-full = true;
goto nomem;
}
-
+ msg_rx = true;
msg = mbox_fifo_read(mbox);
len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
@@ -192,21 +193,25 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
}
/* no more messages in the fifo. clear IRQ source. */
- ack_mbox_irq(mbox, IRQ_RX);
+ if (msg_rx)
+ ack_mbox_irq(mbox, IRQ_RX);
nomem:
- queue_work(mboxd, mbox-rxq-work);
+ if (msg_rx)
+ queue_work(mboxd, mbox-rxq-work);
}
static irqreturn_t mbox_interrupt(int irq, void *p)
{
struct omap_mbox *mbox = p;
- if (is_mbox_irq(mbox, IRQ_TX))
- __mbox_tx_interrupt(mbox);
-
- if (is_mbox_irq(mbox, IRQ_RX))
- __mbox_rx_interrupt(mbox);
+ for (i = 0; mboxes[i]; i++) {
+ struct omap_mbox *mbox = mboxes[i];
+ if (is_mbox_irq(mbox, IRQ_TX))
+ __mbox_tx_interrupt(mbox);
+ if (is_mbox_irq(mbox, IRQ_RX))
+ __mbox_rx_interrupt(mbox);
+ }
return IRQ_HANDLED;
}
--
1.7.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
Re: [Omapandroid-discussion] Difference between twl4030_hsmmc_infoand omap_mmc_platform_data
Hi Madhusudhan, On Oct 15, 2010, at 4:35 AM, Madhusudhan wrote: Twl4030 is the power chip. Its LDOs are modeled through the regulator framework used by MMC1 and MMC2. On OMAP3 the card detect is from the GPIO module of twl4030. Could you suggest an example of a board that uses TWL4030 for MMC power and card detect control, but the HSMMC MMC2 controller for enabling control of the TI WL1271 wlan module? The examples I have seen use either pure HSMMC only, or pure TWL4030 only, and I just need an example where I use the TWL4030 to supply power and detect MMC card events, for MMC1 controller, but HSMMC2 for MMC2 controller with DMA access. Best regards, Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: hmwod: Update the sysc_cache in case module context is lost
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, October 15, 2010 3:44 AM
To: Nayak, Rajendra
Cc: linux-omap@vger.kernel.org; Paul Walmsley; Cousson, Benoit; Shilimkar,
Santosh
Subject: Re: [PATCH] OMAP: hmwod: Update the sysc_cache in case module
context is lost
Rajendra Nayak rna...@ti.com writes:
Do not skip the sysc programming in the hmwod framework based
on the cached value alone, since at times the module might have lost
context (due to the Powerdomain in which the module belongs
transitions to either Open Switch RET or OFF).
Shouldn't the driver for each IP be responsible for restoring it's
register contents after context loss, including it's SYSC?
Seems to me that if SYSC is lost, it means the driver's save/restore
is buggy.
I am glad you asked this question. I had a same argument with Benoit
that driver anyway does context save restore for other registers and
it can do SYSC as well.
But Benoit's point was that sysconfig is a part of the PRCM located
in the IP, but this is purely TI implementation specific. The same
IP in another platform will not have this sysconfig entry. That's why
its important to hide them from the driver
This make sense too.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
omap2/omap_hwmod.c
index cb911d7..e57fe21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -115,7 +115,10 @@ static void _write_sysconfig(u32 v, struct
omap_hwmod *oh)
/* XXX ensure module interface clock is up */
- if (oh-_sysc_cache != v) {
+ if ((oh-_sysc_cache != v) ||
+ /* Did the module go to off and loose context? */
+ (oh-_sysc_cache !=
+omap_hwmod_readl(oh, oh-class-sysc-sysc_offs))) {
oh-_sysc_cache = v;
omap_hwmod_writel(v, oh, oh-class-sysc-sysc_offs);
}
--
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
