Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix
* Shilimkar, Santosh santosh.shilim...@ti.com [090109 15:22]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 6:27 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 14:52]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 4:58 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 12:51]: Tony, Regarding your proposal of doing the no. of channel reservation during runtime has one problem. The whole idea was not to restrict users from using all 32 channels and hence the config option. For OMAP secure chips, few security drivers which will execute in secure contex needs dedicated DMA channels and kernel dma library can't be used in that case. So in such cases, required DMA channels can be reserved using this config option. For GP devices all 32 channels can be used currently. If it can done in better way, please suggest. Well how about passing the configuration for the DMA channels from board-*.c file then? This is certainly a good option if the setting is fixed for a particular board type. With this how do we ensure user configurability. Lets say on a particular board, two users/customers wants to use separate configurations for DMA channels because of the needs what mentioned earlier. Then again we need some kind of comfit option. Another clean way to achieve this is through 'bootargs'. But this might be too much of a design for this requirement. Hmm, well how about starting with all of them, and allow limiting the active DMA number via /sys? I guess we could just set some of the DMA channels inactive that way. Or maybe allow setting indvidual DMA channels inactive via /sys? This won't be a good option because of few limitations. - dma library init will configure the entire register set for all the channels. So through /sys disable , you have to mask all of this registers with appropriate mask depending on the no of channels deactivated. This is almost like doing another DMA init. - Secondly the security driver is active even before the dma library is initialed and hence it won't get the required reservation of channels which is bottleneck. - If both, dma library and security driver configure the DMA channels then, you end up in a problem because the way OMAP DMA hardware is. Just a brief - In contrast to the SDMA.DMA4_CSRi registers, the SDMA.DMA4_IRQSTATUS_Lj registers are updated regardless of the corresponding bits in the SDMA.DMA4_IRQENABLE_Lj registers. For more details, you can refer the DMA section in TRM. Because of above, this is not seems to be an option. How about set up a cmdline option for omap dma for masking the available channels? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, January 12, 2009 6:11 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 15:22]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 6:27 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 14:52]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 4:58 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 12:51]: Tony, Regarding your proposal of doing the no. of channel reservation during runtime has one problem. The whole idea was not to restrict users from using all 32 channels and hence the config option. For OMAP secure chips, few security drivers which will execute in secure contex needs dedicated DMA channels and kernel dma library can't be used in that case. So in such cases, required DMA channels can be reserved using this config option. For GP devices all 32 channels can be used currently. If it can done in better way, please suggest. Well how about passing the configuration for the DMA channels from board-*.c file then? This is certainly a good option if the setting is fixed for a particular board type. With this how do we ensure user configurability. Lets say on a particular board, two users/customers wants to use separate configurations for DMA channels because of the needs what mentioned earlier. Then again we need some kind of comfit option. Another clean way to achieve this is through 'bootargs'. But this might be too much of a design for this requirement. Hmm, well how about starting with all of them, and allow limiting the active DMA number via /sys? I guess we could just set some of the DMA channels inactive that way. Or maybe allow setting indvidual DMA channels inactive via /sys? This won't be a good option because of few limitations. - dma library init will configure the entire register set for all the channels. So through /sys disable , you have to mask all of this registers with appropriate mask depending on the no of channels deactivated. This is almost like doing another DMA init. - Secondly the security driver is active even before the dma library is initialed and hence it won't get the required reservation of channels which is bottleneck. - If both, dma library and security driver configure the DMA channels then, you end up in a problem because the way OMAP DMA hardware is. Just a brief - In contrast to the SDMA.DMA4_CSRi registers, the SDMA.DMA4_IRQSTATUS_Lj registers are updated regardless of the corresponding bits in the SDMA.DMA4_IRQENABLE_Lj registers. For more details, you can refer the DMA section in TRM. Because of above, this is not seems to be an option. How about set up a cmdline option for omap dma for masking the available channels? Do you mean through bootargs ? If yes then I already wrote about it.Indeed it is nice method to do this. So if your answer is yes, I will make a patch along with spurious interrupt patch. -- 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] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix
* Shilimkar, Santosh santosh.shilim...@ti.com [090112 15:00]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, January 12, 2009 6:11 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 15:22]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 6:27 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 14:52]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 4:58 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 12:51]: Tony, Regarding your proposal of doing the no. of channel reservation during runtime has one problem. The whole idea was not to restrict users from using all 32 channels and hence the config option. For OMAP secure chips, few security drivers which will execute in secure contex needs dedicated DMA channels and kernel dma library can't be used in that case. So in such cases, required DMA channels can be reserved using this config option. For GP devices all 32 channels can be used currently. If it can done in better way, please suggest. Well how about passing the configuration for the DMA channels from board-*.c file then? This is certainly a good option if the setting is fixed for a particular board type. With this how do we ensure user configurability. Lets say on a particular board, two users/customers wants to use separate configurations for DMA channels because of the needs what mentioned earlier. Then again we need some kind of comfit option. Another clean way to achieve this is through 'bootargs'. But this might be too much of a design for this requirement. Hmm, well how about starting with all of them, and allow limiting the active DMA number via /sys? I guess we could just set some of the DMA channels inactive that way. Or maybe allow setting indvidual DMA channels inactive via /sys? This won't be a good option because of few limitations. - dma library init will configure the entire register set for all the channels. So through /sys disable , you have to mask all of this registers with appropriate mask depending on the no of channels deactivated. This is almost like doing another DMA init. - Secondly the security driver is active even before the dma library is initialed and hence it won't get the required reservation of channels which is bottleneck. - If both, dma library and security driver configure the DMA channels then, you end up in a problem because the way OMAP DMA hardware is. Just a brief - In contrast to the SDMA.DMA4_CSRi registers, the SDMA.DMA4_IRQSTATUS_Lj registers are updated regardless of the corresponding bits in the SDMA.DMA4_IRQENABLE_Lj registers. For more details, you can refer the DMA section in TRM. Because of above, this is not seems to be an option. How about set up a cmdline option for omap dma for masking the available channels? Do you mean through bootargs ? If yes then I already wrote about it.Indeed it is nice method to do this. So if your answer is yes, I will make a patch along with spurious interrupt patch. Yes, sorry if I missed that earlier. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix
* Shilimkar, Santosh santosh.shilim...@ti.com [090109 14:52]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 4:58 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 12:51]: Tony, Regarding your proposal of doing the no. of channel reservation during runtime has one problem. The whole idea was not to restrict users from using all 32 channels and hence the config option. For OMAP secure chips, few security drivers which will execute in secure contex needs dedicated DMA channels and kernel dma library can't be used in that case. So in such cases, required DMA channels can be reserved using this config option. For GP devices all 32 channels can be used currently. If it can done in better way, please suggest. Well how about passing the configuration for the DMA channels from board-*.c file then? This is certainly a good option if the setting is fixed for a particular board type. With this how do we ensure user configurability. Lets say on a particular board, two users/customers wants to use separate configurations for DMA channels because of the needs what mentioned earlier. Then again we need some kind of comfit option. Another clean way to achieve this is through 'bootargs'. But this might be too much of a design for this requirement. Hmm, well how about starting with all of them, and allow limiting the active DMA number via /sys? I guess we could just set some of the DMA channels inactive that way. Or maybe allow setting indvidual DMA channels inactive via /sys? Time being if needed what best I can do is, to split this patch into two parts as mentioned earlier. This will avoid confusion of spurious interrupt issue and dam channel reservation OK I will do this once I get some time for sure. Great! Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 6:27 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 14:52]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, January 09, 2009 4:58 PM To: Shilimkar, Santosh Cc: Pandita, Vikram; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix * Shilimkar, Santosh santosh.shilim...@ti.com [090109 12:51]: Tony, Regarding your proposal of doing the no. of channel reservation during runtime has one problem. The whole idea was not to restrict users from using all 32 channels and hence the config option. For OMAP secure chips, few security drivers which will execute in secure contex needs dedicated DMA channels and kernel dma library can't be used in that case. So in such cases, required DMA channels can be reserved using this config option. For GP devices all 32 channels can be used currently. If it can done in better way, please suggest. Well how about passing the configuration for the DMA channels from board-*.c file then? This is certainly a good option if the setting is fixed for a particular board type. With this how do we ensure user configurability. Lets say on a particular board, two users/customers wants to use separate configurations for DMA channels because of the needs what mentioned earlier. Then again we need some kind of comfit option. Another clean way to achieve this is through 'bootargs'. But this might be too much of a design for this requirement. Hmm, well how about starting with all of them, and allow limiting the active DMA number via /sys? I guess we could just set some of the DMA channels inactive that way. Or maybe allow setting indvidual DMA channels inactive via /sys? This won't be a good option because of few limitations. - dma library init will configure the entire register set for all the channels. So through /sys disable , you have to mask all of this registers with appropriate mask depending on the no of channels deactivated. This is almost like doing another DMA init. - Secondly the security driver is active even before the dma library is initialed and hence it won't get the required reservation of channels which is bottleneck. - If both, dma library and security driver configure the DMA channels then, you end up in a problem because the way OMAP DMA hardware is. Just a brief - In contrast to the SDMA.DMA4_CSRi registers, the SDMA.DMA4_IRQSTATUS_Lj registers are updated regardless of the corresponding bits in the SDMA.DMA4_IRQENABLE_Lj registers. For more details, you can refer the DMA section in TRM. Because of above, this is not seems to be an option. Time being if needed what best I can do is, to split this patch into two parts as mentioned earlier. This will avoid confusion of spurious interrupt issue and dam channel reservation OK I will do this once I get some time for sure. Great! Tony Regards, Santosh -- 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] [OMAPZOOM] OMAP : DMA: Spurious interrupt fix
From: Santosh Shilimkar [EMAIL PROTECTED]
This fixes the spurious interrupt issue on a DMA channel.
Signed-off-by: Santosh Shilimkar [EMAIL PROTECTED]
Acked By: Nishant Kamat [EMAIL PROTECTED]
Acked By: Gopinath Thara [EMAIL PROTECTED]
---
--- omapkernel.orig/arch/arm/plat-omap/include/mach/dma.h 2008-12-04
10:29:08.949018434 +0530
+++ omapkernel/arch/arm/plat-omap/include/mach/dma.h2008-12-04
11:14:25.359087775 +0530
@@ -67,7 +67,11 @@
#define OMAP_DMA4_CAPS_4 0x74
#define OMAP1_LOGICAL_DMA_CH_COUNT 17
+#ifdef CONFIG_OMAP_DMA_LIBRARY_CHANNELS
+#define OMAP_DMA4_LOGICAL_DMA_CH_COUNT CONFIG_OMAP_DMA_LIBRARY_CHANNELS
+#else
#define OMAP_DMA4_LOGICAL_DMA_CH_COUNT 32 /* REVISIT: Is this 32 + 2? */
+#endif
/* Common channel specific registers for omap1 */
#define OMAP1_DMA_CH_BASE(n) (0x40 * (n) + 0x00)
Index: omapkernel/arch/arm/plat-omap/Kconfig
===
--- omapkernel.orig/arch/arm/plat-omap/Kconfig 2008-12-04 10:29:08.949018434
+0530
+++ omapkernel/arch/arm/plat-omap/Kconfig 2008-12-04 10:38:21.883850512
+0530
@@ -256,6 +256,18 @@ config OMAP_SERIAL_WAKE
to data on the serial RX line. This allows you to wake the
system from serial console.
+
+config OMAP_DMA_LIBRARY_CHANNELS
+int DMA channels controlled by the kernel DMA library
+range 24 32
+depends on ARCH_OMAP3
+default 32
+help
+ Some of the OMAP System DMA channels may need to be
+ reserved for software that don't use the DMA library, such as
+ security drivers. Use this option to limit the number of channels
+ controlled by the kernel DMA library.
+
endmenu
endif
Index: omapkernel/arch/arm/configs/omap_3430sdp_defconfig
===
--- omapkernel.orig/arch/arm/configs/omap_3430sdp_defconfig 2008-12-04
10:29:08.949018434 +0530
+++ omapkernel/arch/arm/configs/omap_3430sdp_defconfig 2008-12-04
10:38:21.884850481 +0530
@@ -177,7 +177,7 @@ CONFIG_ARCH_OMAP_OTG=y
# CONFIG_ARCH_OMAP1 is not set
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y
-
+CONFIG_OMAP_DMA_LIBRARY_CHANNELS=24
#
# OMAP Feature Selections
#
Index: omapkernel/arch/arm/plat-omap/dma.c
===
--- omapkernel.orig/arch/arm/plat-omap/dma.c2008-12-04 10:38:16.732010840
+0530
+++ omapkernel/arch/arm/plat-omap/dma.c 2008-12-04 11:11:07.671274902 +0530
@@ -1946,7 +1946,7 @@ static int omap2_dma_handle_ch(int ch)
/* STATUS register count is from 1-32 while our is 0-31 */
static irqreturn_t omap2_dma_irq_handler(int irq, void *dev_id)
{
- u32 val;
+ u32 val, enable_reg;
int i;
val = dma_read(IRQSTATUS_L0);
@@ -1955,6 +1955,8 @@ static irqreturn_t omap2_dma_irq_handler
printk(KERN_WARNING Spurious DMA IRQ\n);
return IRQ_HANDLED;
}
+ enable_reg = dma_read(IRQENABLE_L0);
+ val = enable_reg; /* Dispatch only relevant interrupts */
for (i = 0; i dma_lch_count val != 0; i++) {
if (val 1)
omap2_dma_handle_ch(i);
Index: omapkernel/arch/arm/configs/omap_ldp_defconfig
===
--- omapkernel.orig/arch/arm/configs/omap_ldp_defconfig 2008-12-04
11:18:54.0 +0530
+++ omapkernel/arch/arm/configs/omap_ldp_defconfig 2008-12-04
11:19:33.507466484 +0530
@@ -177,6 +177,7 @@ CONFIG_ARCH_OMAP_OTG=y
# CONFIG_ARCH_OMAP1 is not set
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y
+CONFIG_OMAP_DMA_LIBRARY_CHANNELS=32
#
# OMAP Feature Selections
#
--
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
