[PATCH 1/1] ARM:OMAP: fix driver MODULE_ALIAS()
Add a correct MODULE_ALIAS() entry for this driver to enable udev module
loading.
Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
---
drivers/input/keyboard/omap-twl4030keypad.c |2 ++
drivers/input/touchscreen/tsc2005.c |2 +-
drivers/mmc/host/omap_hsmmc.c |3 ++-
drivers/rtc/rtc-twl4030.c |2 +-
4 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/input/keyboard/omap-twl4030keypad.c
b/drivers/input/keyboard/omap-twl4030keypad.c
index 0344b4c..fc5d44e 100644
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -350,6 +350,7 @@ static struct platform_driver omap_kp_driver = {
.remove = omap_kp_remove,
.driver = {
.name = omap_twl4030keypad,
+ .owner = THIS_MODULE,
},
};
@@ -371,3 +372,4 @@ module_exit(omap_kp_exit);
MODULE_AUTHOR(Texas Instruments);
MODULE_DESCRIPTION(OMAP TWL4030 Keypad Driver);
MODULE_LICENSE(GPL);
+MODULE_ALIAS(platform:omap_twl4030keypad);
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index fa01799..93dc3c5 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -734,4 +734,4 @@ module_exit(tsc2005_exit);
MODULE_AUTHOR(Lauri Leukkunen [EMAIL PROTECTED]);
MODULE_LICENSE(GPL);
-
+MODULE_ALIAS(platform:tsc2005);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9c18c15..d399dca 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1106,6 +1106,7 @@ static struct platform_driver omap_mmc_driver = {
.resume = omap_mmc_resume,
.driver = {
.name = DRIVER_NAME,
+ .owner = THIS_MODULE,
},
};
@@ -1126,5 +1127,5 @@ module_exit(omap_mmc_cleanup);
MODULE_DESCRIPTION(OMAP High Speed Multimedia Card driver);
MODULE_LICENSE(GPL);
-MODULE_ALIAS(DRIVER_NAME);
+MODULE_ALIAS(platform: DRIVER_NAME);
MODULE_AUTHOR(Texas Instruments Inc);
diff --git a/drivers/rtc/rtc-twl4030.c b/drivers/rtc/rtc-twl4030.c
index ef0e175..7b0a4c5 100644
--- a/drivers/rtc/rtc-twl4030.c
+++ b/drivers/rtc/rtc-twl4030.c
@@ -624,7 +624,7 @@ static int twl4030_rtc_resume(struct platform_device *pdev)
#define twl4030_rtc_resume NULL
#endif
-MODULE_ALIAS(twl4030_rtc);
+MODULE_ALIAS(platform:twl4030_rtc);
static struct platform_driver twl4030rtc_driver = {
.probe = twl4030_rtc_probe,
.remove = __devexit_p(twl4030_rtc_remove),
--
1.5.5.1.357.g1af8b
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Added sleep support to UART
Hi,
A few minor comments based on a quick look.
In terms of the OMAP3 code, is that for retention-idle only,
or does it work with off-idle also?
That patch should basically work in off-mode also, however it requires
correct settings in the padconfig registers which are currently done in
the boot code. Also, currently I have not had any chance to actually
test this in off-mode, I am still trying to get the off-mode work on my
HW.
On Tue, 10 Jun 2008, Tero Kristo wrote:
+const u32 omap2_uart_wk_bit[OMAP_MAX_NR_PORTS] = {
+ OMAP24XX_ST_UART1, OMAP24XX_ST_UART2, OMAP24XX_ST_UART3 };
Looks like that can be static.
True.
+/* UART padconfig registers, these may differ if
non-default padconfig
+ is used */
+#define CONTROL_PADCONF_UART1_RX 0x48002182 #define
+CONTROL_PADCONF_UART2_RX 0x4800217A #define
CONTROL_PADCONF_UART3_RX
+0x4800219E #define PADCONF_WAKEUP_ST 0x8000
Please use omap_ctrl_read{b,w,l}() rather than
omap_read{b,w,l}() for SCM addresses.
Hmm yea, could do.
Also, the above are register addresses + 2. Is it possible to
use the actual register addresses (ideally they should be
defined in include/asm-arm/arch-omap/control.h), do long
reads, and simply shift the register contents for the serial
ports that need it?
These registers are currently not defined anywhere and I did not feel
like wanting to put all the padconfig register definitions somewhere
(all 200+ of them) I don't think it is currently very clear how we
want to handle these registers in general. Also, this fix is more or
less temporary anyway while we are waiting for a real driver that
handles UART clocks properly (the final solution will most likely use
some of the elements of this though.)
Also, the spec says that these registers can be accessed in either 8, 16
or 32 bit modes so why make it unnecessarily complicated and potentially
buggy with shifts (race conditions)?
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Separate out 3430 LCD panel support from 2430 file
From: Iqbal Shareef [EMAIL PROTECTED]
Separate out 3430 LCD panel support from 2430 SDP.
Currently the support for the LCD on 3430SDP is added in the lcd_2430sdp.c
file. This patch separates it out to a new file.
Signed-off-by: Iqbal Shareef [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
drivers/video/omap/Makefile |2 +-
drivers/video/omap/lcd_3430sdp.c| 161 +++
3 files changed, 163 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/omap/lcd_3430sdp.c
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index f6cd08b..7a216cc 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -204,7 +204,7 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
};
static struct platform_device sdp3430_lcd_device = {
- .name = sdp2430_lcd,
+ .name = sdp3430_lcd,
.id = -1,
};
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index fe7ee5d..a72a2d9 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -30,7 +30,7 @@ objs-y$(CONFIG_MACH_SX1) += lcd_sx1.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
-objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
+objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_3430sdp.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_3430sdp.c b/drivers/video/omap/lcd_3430sdp.c
new file mode 100644
index 000..a8e4366
--- /dev/null
+++ b/drivers/video/omap/lcd_3430sdp.c
@@ -0,0 +1,161 @@
+/*
+ * LCD panel support for the TI 3430SDP board
+ *
+ * Copyright (C) 2008 Texas Instruments
+ * Author: Iqbal Shareef [EMAIL PROTECTED]
+ *
+ * Derived from drivers/video/omap/lcd_2430sdp.c
+ * Copyright (C) 2007 MontaVista
+ * Author: Hunyue Yau [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * 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, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+
+#include asm/arch/gpio.h
+#include asm/arch/omapfb.h
+
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+
+#define LCD_PIXCLOCK_MAX 167000
+#define PM_RECEIVERTWL4030_MODULE_PM_RECEIVER
+#define ENABLE_VAUX2_DEDICATED 0x03
+#define ENABLE_VAUX2_DEV_GRP 0x20
+#define ENABLE_VAUX3_DEDICATED 0x05
+#define ENABLE_VAUX3_DEV_GRP 0xE0
+
+static int sdp3430_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
+ backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+ omap_request_gpio(enable_gpio); /* LCD panel */
+ omap_request_gpio(backlight_gpio); /* LCD backlight */
+ omap_set_gpio_direction(enable_gpio, 0);/* output */
+ omap_set_gpio_direction(backlight_gpio, 0); /* output */
+
+ return 0;
+}
+
+static void sdp3430_panel_cleanup(struct lcd_panel *panel)
+{
+ omap_free_gpio(backlight_gpio);
+ omap_free_gpio(enable_gpio);
+}
+
+static int sdp3430_panel_enable(struct lcd_panel *panel)
+{
+ omap_set_gpio_dataout(enable_gpio, 1);
+ omap_set_gpio_dataout(backlight_gpio, 1);
+
+ if (0 != twl4030_i2c_write_u8(PM_RECEIVER, ENABLE_VAUX3_DEDICATED,
+ TWL4030_VAUX3_DEDICATED))
+ return -EIO;
+ if (0 != twl4030_i2c_write_u8(PM_RECEIVER, ENABLE_VAUX3_DEV_GRP,
+ TWL4030_VAUX3_DEV_GRP))
+ return -EIO;
+
+ return 0;
+}
+
+static void sdp3430_panel_disable(struct lcd_panel *panel)
+{
+ omap_set_gpio_dataout(enable_gpio, 0);
+ omap_set_gpio_dataout(backlight_gpio, 0);
+}
+
+static unsigned long sdp3430_panel_get_caps(struct lcd_panel *panel)
+{
+ return 0;
+}
+
+struct lcd_panel sdp3430_panel = {
+ .name
Re: [PATCH] Separate out 3430 LCD panel support from 2430 file
On Thu, 12 Jun 2008 05:24:32 -0500, [EMAIL PROTECTED] wrote:
From: Iqbal Shareef [EMAIL PROTECTED]
Separate out 3430 LCD panel support from 2430 SDP.
Currently the support for the LCD on 3430SDP is added in the
lcd_2430sdp.c
file. This patch separates it out to a new file.
You're at least missing 3430sdp defconfig updates, Kconfig changes
in drivers/media/video/omap and the removal of conditional code in
lcd_2430sdp.c
Some more comments below
Signed-off-by: Iqbal Shareef [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
drivers/video/omap/Makefile |2 +-
drivers/video/omap/lcd_3430sdp.c| 161
+++
3 files changed, 163 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/omap/lcd_3430sdp.c
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index f6cd08b..7a216cc 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -204,7 +204,7 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
};
static struct platform_device sdp3430_lcd_device = {
- .name = sdp2430_lcd,
+ .name = sdp3430_lcd,
.id = -1,
};
diff --git a/drivers/video/omap/Makefile b/drivers/video/omap/Makefile
index fe7ee5d..a72a2d9 100644
--- a/drivers/video/omap/Makefile
+++ b/drivers/video/omap/Makefile
@@ -30,7 +30,7 @@ objs-y$(CONFIG_MACH_SX1) += lcd_sx1.o
objs-y$(CONFIG_MACH_OMAP_APOLLON) += lcd_apollon.o
objs-y$(CONFIG_MACH_OMAP_2430SDP) += lcd_2430sdp.o
-objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_2430sdp.o
+objs-y$(CONFIG_MACH_OMAP_3430SDP) += lcd_3430sdp.o
objs-y$(CONFIG_MACH_OMAP3EVM) += lcd_omap3evm.o
objs-y$(CONFIG_MACH_OMAP3_BEAGLE) += lcd_omap3beagle.o
objs-y$(CONFIG_FB_OMAP_LCD_MIPID) += lcd_mipid.o
diff --git a/drivers/video/omap/lcd_3430sdp.c
b/drivers/video/omap/lcd_3430sdp.c
new file mode 100644
index 000..a8e4366
--- /dev/null
+++ b/drivers/video/omap/lcd_3430sdp.c
@@ -0,0 +1,161 @@
+/*
+ * LCD panel support for the TI 3430SDP board
+ *
+ * Copyright (C) 2008 Texas Instruments
+ * Author: Iqbal Shareef [EMAIL PROTECTED]
+ *
+ * Derived from drivers/video/omap/lcd_2430sdp.c
+ * Copyright (C) 2007 MontaVista
+ * Author: Hunyue Yau [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ * 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, write to the Free Software Foundation,
Inc.,
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+
+#include asm/arch/gpio.h
+#include asm/arch/omapfb.h
+
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+
+#define LCD_PIXCLOCK_MAX 167000
+#define PM_RECEIVER TWL4030_MODULE_PM_RECEIVER
PM_RECEIVER has no prefix. It's better to use TWL4030_MODULE_PM_RECEIVER
to avoid namespace conflicts
+#define ENABLE_VAUX2_DEDICATED 0x03
+#define ENABLE_VAUX2_DEV_GRP 0x20
+#define ENABLE_VAUX3_DEDICATED 0x05
+#define ENABLE_VAUX3_DEV_GRP 0xE0
+
+static int sdp3430_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ enable_gpio= SDP3430_LCD_PANEL_ENABLE_GPIO;
+ backlight_gpio = SDP3430_LCD_PANEL_BACKLIGHT_GPIO;
+
+ omap_request_gpio(enable_gpio); /* LCD panel */
+ omap_request_gpio(backlight_gpio); /* LCD backlight */
+ omap_set_gpio_direction(enable_gpio, 0);/* output */
+ omap_set_gpio_direction(backlight_gpio, 0); /* output */
better using gpiolib
+
+ return 0;
+}
+
+static void sdp3430_panel_cleanup(struct lcd_panel *panel)
+{
+ omap_free_gpio(backlight_gpio);
+ omap_free_gpio(enable_gpio);
gpiolib
+}
+
+static int sdp3430_panel_enable(struct lcd_panel *panel)
+{
+ omap_set_gpio_dataout(enable_gpio, 1);
+ omap_set_gpio_dataout(backlight_gpio, 1);
gpiolib
+
+ if (0 != twl4030_i2c_write_u8(PM_RECEIVER, ENABLE_VAUX3_DEDICATED,
+ TWL4030_VAUX3_DEDICATED))
+ return -EIO;
+ if (0 !=
RE: [PATCH] Separate out 3430 LCD panel support from 2430 file
On Thu, 12 Jun 2008 17:24:49 +0530, Gadiyar, Anand [EMAIL PROTECTED] wrote: Separate out 3430 LCD panel support from 2430 SDP. Currently the support for the LCD on 3430SDP is added in the lcd_2430sdp.c file. This patch separates it out to a new file. You're at least missing 3430sdp defconfig updates, Kconfig changes in drivers/media/video/omap and the removal of conditional code in lcd_2430sdp.c Er... Why Kconfig in drivers/media/video/omap? brainfart :-p It uses CONFIG_MACH_OMAP_XXX :-) forget about the Kconfig :-) -- Best Regards, Felipe Balbi http://felipebalbi.com [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] Updates on mcbsp driver (take #2)
Jarkko, I've been using this patch with good results while developing an alsa soc driver for the 35XX EVM and beagleboard. Do you have plans to to officially submit this patch (or a more recent version of it)? Steve On Tue, May 20, 2008 at 4:21 AM, Jarkko Nikula [EMAIL PROTECTED] wrote: On Mon, 19 May 2008 11:09:43 -0400 ext Eduardo Valentin [EMAIL PROTECTED] wrote: Hi Steve, This series is basically a simple transformation of currect mcbsp code to a platform driver and a separation of machine specific code. It should work for omap1 and omap2 (what is currently supported). But it should add basic support for omap3 mcbps 1 and 2. Chandra will send his patches on top of this series to add more features for omap3. For those who are keen to try ASoC on OMAP3 might want to try attached patch on top of Eduardo's set. I'll prepare better one when there are more ports defined. E.g. there is no need to separe omap34xx_dma_regs table since request numbers are the same between OMAP2 and OMAP3. Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
SDMA, RAM to RAM transfer issue
Hi! All I am new to OMAP3430, I am trying to do DMA transfer from one Memory location to another on RAM. First Scenario is I am Allocating 1024bytes (KMALLOC) for both SRC DEST and after taking physical address (__pa) of allocated addresses I am passing it to DMA tarnsfer. in this case first 64bytes are not reflecting transfer in destination (DST), rest are fine. Second case: I am doing everything else same but allocated size of memory is X=(64+1024) bytes, and passed address to DMA is X+64, in this case eveything is fine, Transfer is complete for 1024bytes. any body can please shed some light, what is wrong in my approach? or why in first case tarnsffer is not reflected in first 64 bytes? is it memory addressing issue or DMA setting issue. I have tried with different channel but result is same. Address returned by Kmalloc is on 32/64 byte boundary. A quick reply will be appreciable! with wishes Somz - end -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: SDMA, RAM to RAM transfer issue
Somz, I'm not sure I quite comprehend the two transfers you mention. Regardless, please send your System DMA parameters for the transfer. Did you perform a cache invalidate of the DEST buffer to ensure you are seeing new data when performing a read by the CPU from DEST to verify the transfer? A cache flush would be probably needed on SRC buffer if you had just initialized SRC with data. This would ensure the contents in SRC are actually out in physical memory. Brandon Azbell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Somnt Sent: Thursday, June 12, 2008 8:35 PM To: linux-omap@vger.kernel.org Subject: SDMA, RAM to RAM transfer issue Hi! All I am new to OMAP3430, I am trying to do DMA transfer from one Memory location to another on RAM. First Scenario is I am Allocating 1024bytes (KMALLOC) for both SRC DEST and after taking physical address (__pa) of allocated addresses I am passing it to DMA tarnsfer. in this case first 64bytes are not reflecting transfer in destination (DST), rest are fine. Second case: I am doing everything else same but allocated size of memory is X=(64+1024) bytes, and passed address to DMA is X+64, in this case eveything is fine, Transfer is complete for 1024bytes. any body can please shed some light, what is wrong in my approach? or why in first case tarnsffer is not reflected in first 64 bytes? is it memory addressing issue or DMA setting issue. I have tried with different channel but result is same. Address returned by Kmalloc is on 32/64 byte boundary. A quick reply will be appreciable! with wishes Somz - end -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge
Viraj, I think in order to read the tags you have to be in secure mode, so this approach might not be possible. Thank you, Best regards, Hari -Original Message- From: Viraj Karandikar [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 11:33 PM To: Kanigeri, Hari; Gupta, Ramesh; linux-omap@vger.kernel.org Cc: Ameet U. Kalagi Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Hari, Yes, performance of other applications will be impacted if we flush entire cache. Can we do something like, scan through cache entries and flush entries belonging to the buffer requested for flush? This can be done only while flushing huge buffers, so that flushing small buffers will not be affected. I am not sure how exactly cache operations are done in linux. But I think this could be done. Regards, Viraj -Original Message- From: Kanigeri, Hari [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 12:38 AM To: Viraj Karandikar; Gupta, Ramesh; linux-omap@vger.kernel.org Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Hi Viraj, I took these changes and built new bridgedriver.ko. I could see 50% reduction in time taken to queue a buffer of size of 3MB. (old time: 28 ms, new time: 13 ms). Nice to hear the optimization worked for you. But actually the L2 cache is only 256Kb. So a small part of the buffer might be in cache ( 256Kb). This will add unnecessary overhead for huge (my buffer size is 3MB) buffers. Is there any way so that I can flush full cache to avoid overhead? I did benchmark the flush part and the number I got is very close to what you observed. We are looking into the issue of reducing the flush time. I will inform once I find any improvements to this. As far as your question regarding flushing the entire cache, I am not sure if this is the best approach as this will have an impact on the performance of other applications running in the system. Thank you, Best regards, Hari -Original Message- From: Viraj Karandikar [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2008 10:51 AM To: Kanigeri, Hari; Gupta, Ramesh; linux-omap@vger.kernel.org Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Thanks Hari, I took these changes and built new bridgedriver.ko. I could see 50% reduction in time taken to queue a buffer of size of 3MB. (old time: 28 ms, new time: 13 ms). If I reserve and map a buffer only once and use the mapped address for future (avoiding map/unmap every time) I get better numbers (9 ms). So only thing which I am doing is flushing the buffer for consistency since this buffer is input to codec on DSP. But 9ms only for flushing seems very high. I am not 100% sure, but it seems like the kernel flush code is scanning through all the virtual addresses of the buffer and flush if any of those are cached. But actually the L2 cache is only 256Kb. So a small part of the buffer might be in cache ( 256Kb). This will add unnecessary overhead for huge (my buffer size is 3MB) buffers. Is there any way so that I can flush full cache to avoid overhead? Regards, Viraj -Original Message- From: Kanigeri, Hari [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2008 10:51 PM To: Viraj Karandikar; Gupta, Ramesh; linux-omap@vger.kernel.org Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Hi Viraj, You can use the attached file to get the DMM optimimzation that Ramesh is referring to. The location of this file is mpu_driver\src\wmd\omap\3430 Thank you, Best regards, Hari -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Viraj Karandikar Sent: Monday, June 09, 2008 10:18 AM To: Gupta, Ramesh; linux-omap@vger.kernel.org Subject: RE: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Thanks Ramesh. I was reserving and mapping buffers every time. This was not required. I modified the code to reserve and map a buffer only once and use the mapped address for future. This modification reduced the overhead. I have one more doubt. Does DSP use virtual-to-physical mapping for all the addresses it accesses (including DSP's local buffers)? Or it uses this mapping only to access shared buffers? Wont it be a big overhead if DSP accesses all the memories through virtual-to-physical mapping? Regards, Viraj -Original Message- From: Ramesh Gupta G [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2008 11:03 AM To: Viraj Karandikar; [EMAIL PROTECTED] Subject: Re: Sharing buffers between ARM-DSP on OMAP3430 over Bridge Hi Vijay, - Original Message - From: Viraj Karandikar [EMAIL PROTECTED]
