Re: Patch [2/2] DaVinci CPPI TX DMA tasklet
On Thu, Aug 21, 2008 at 08:24:11PM -0700, David Brownell wrote: > They'll need to be in nicely reviewable chunks ... I remember seeing > some DaVinci patches in late 2006 which broke on TUSB6010 silicon, > for example. > > DMA in particular could really stand some cleanup. Having four > different chunks of DMA code -- RX/TX vs Host/Peripheral -- with > ifdeffery for multiple DMA engines is ... chaotic. Yeah, after the debugfs changes I plan to clean up those. Might take a while due to internal tasks > > I discussed with Kevin on the DaVinci Git tree and Filipe here and they > > recommended that > > I take the changes to linux-usb, linux-omap tree (w.r.t musb changes) to > > get a wider > > audience for review and acceptance. > > > > Kevin would then pull in the changes as part of his regular synch ups. > > I think the plan should be to have various SOC-specific trees (DaVinci, > OMAP, Blackfin, etc) stop hosting MUSB-specific patches. They should > be pushed up to mainline ASAP ... the linux-omap tree should stop being > the place where the latest MUSB code sits. It's not anymore, we Cc that list so interested people might also take a look on the patches, since we pushed musb code via Greg's queue, linux-usb is the place for musb discussion. -- balbi -- 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 [2/2] DaVinci CPPI TX DMA tasklet
On Fri, Aug 22, 2008 at 07:01:26AM +0530, ext Subbrathnam, Swaminathan wrote: > When in DMA mode (mode 1) Endpoint interrupt does not get > generated (only DMA completion interrupt) and hence cannot rely on that. afaict, endpoint interrupt is generated case we get a short packet. Then dma engine won't send that last short packet and an enpoint interrupt will be generated, from that point you decide if you wanna use PIO or reprogram the dma for mode 0. -- balbi -- 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] OMAP:MUSB: Corrects urb unlink function path
On Fri, Aug 22, 2008 at 12:00:56PM +0530, ext [EMAIL PROTECTED] wrote: > From: Ajay Kumar Gupta <[EMAIL PROTECTED]> > > Fixes kernel panic while ISO IN transfer is aborted.Replaced > usb_hcd_unlink_urb_from_ep() from musb_giveback() to __musb_giveback() > to make sure urb is unlinked before giveback when __musb_giveback() is > called from musb_urb_dequeue(). looks right as well note: please break your patch header after 72 caracters > Signed-off-by: Ajay Kumar Gupta <[EMAIL PROTECTED]> > --- > drivers/usb/musb/musb_host.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > index 93b0678..a889ac4 100644 > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -292,6 +292,7 @@ __acquires(musb->lock) > ); > > spin_unlock(&musb->lock); > + usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb); > usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status); > spin_lock(&musb->lock); > } > @@ -353,8 +354,6 @@ musb_giveback(struct musb_qh *qh, struct urb *urb, int > status) > break; > } > > - usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb); > - > qh->is_ready = 0; > __musb_giveback(musb, urb, status); > qh->is_ready = ready; > -- > 1.5.6 > > -- > 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 -- balbi -- 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: [RFC 0/2] McBSP and ASoC OMAP update patches for 2430 and 34xx
On Thu, 21 Aug 2008 14:51:04 -0700 "ext Steve Sakoman" <[EMAIL PROTECTED]> wrote: > I will submit the TWL4030 + Beagle, EVM, and Overo ASoC driver patches > as soon as I can track down a recurring crashing bug -- a null > substream pointer that seems to show up in certain circumstances. Not > quite sure my driver is causing the error, but I would like to get to > the bottom of it. It may be a compatibility issue with the version of > alsa lib I am using with the linux-omap kernel since the lib is > passing in the null pointer. Have you seen anything like this on the > N810? > Thus far I've seen only these two fixed 66c23551b1b774e2be3c7bdf91c0ebf2c7a3519e and 55502f74b56f609a84d8919b9b29390b2e0147ff OMAP DMA related dump_stacks but probably I haven't stressed enough :-) For testing I use Debian/testing and alsa-utils and various players like mpg321, madplay, etc from there. ii libasound2 1.0.16-2 ALSA library cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.17. Can you share the error log and steps when this typically occurs in order to see can I reproduce it? 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
Re: [RFC][DRAFT] TODO list for TI DSP BRIDGE
Hi Richard, From: "ext Woodruff, Richard" <[EMAIL PROTECTED]> Subject: RE: [RFC][DRAFT] TODO list for TI DSP BRIDGE Date: Thu, 21 Aug 2008 14:43:34 -0500 > Hi Hiroshi, > > > -Original Message- > > From: Hiroshi DOYU [mailto:[EMAIL PROTECTED] > > > > > I think that, in this virtual clock, frequency changing will be done > > in the totally different path(just in a normal clock tree). This > > virtual clock resides in an independent clock tree and supposed to be > > used aggressively just to turn on/off clocks(enable/disable), which > > drivers use, for saving power consumption. So the relationship between > > "clk" and "vclk" may be similar to "struct device" and "struct class" > > in the linux driver-model, which means that, the former is based on > > H/W connection and the latter is based on functionality. Of course > > there is a possibility that other clk methods can be overwritten, but > > it's has to be used for different purpose than a normal clock does, > > not to break the H/W clock tree consistency. > > Ok. I 'think' I better understand your idea. Thanks for the description. > > To me it seems like it could be slightly confusing to maintain 2 > clock structures. One for v and one for p. In the end it is > probably not very hard to lean. > > It would reduce some amount of code in the more complex > subsystems/drivers resulting in a cleaner driver. > > The interface used in drivers with the clock frame work is pretty > simple so it might seem more about clean up then reducing complexity > in the driver. > > Do you feel a lot of drivers will benefit or it will expand to auto > handle resources better? If it is just 1 or 2 drivers then it might > be the new code in clock framework and platform will add some > complexity which is higher than what was removed from the driver. > If lots of drivers use it then it would be positive. I have no idea right now about how much drivers and the feature evolution. But basically I feel positive because for now this won't affect the existing clock tree(or framework) at all and this is just a helper function for driver's clock initialization and can be considered as a kind of independent add-on feature from the clock framework perspective. I agree that there is a possibility that some smart guy can extend this to handle all device driver related resources(platform dependent?) together. Hiroshi DOYU -- 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 [2/2] DaVinci CPPI TX DMA tasklet
Felipe, < afaict, endpoint interrupt is generated case we get a short packet. Then < dma engine won't send that last short packet and an enpoint interrupt < will be generated, from that point you decide if you wanna use PIO or < reprogram the dma for mode 0. DaVinci CPPI TX DMA requires operating in Mode 1 and only DMA interrupts are raised and endpoint interrupts are not raised (excepting under error conditions). Regards Swami (Type "pspproducts" in you web browser for PSP info) http://dbdwss01.india.ti.com/pspproducts/ PSP downloads at : http://software.ti.com/swcoe/intranet/reports/pds/PSP_releases.php Office : +91-80-25048629 -Original Message- From: Felipe Balbi [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2008 12:53 PM To: Subbrathnam, Swaminathan Cc: Dmitry Krivoschekov; linux-omap@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Patch [2/2] DaVinci CPPI TX DMA tasklet On Fri, Aug 22, 2008 at 07:01:26AM +0530, ext Subbrathnam, Swaminathan wrote: > When in DMA mode (mode 1) Endpoint interrupt does not get > generated (only DMA completion interrupt) and hence cannot rely on that. afaict, endpoint interrupt is generated case we get a short packet. Then dma engine won't send that last short packet and an enpoint interrupt will be generated, from that point you decide if you wanna use PIO or reprogram the dma for mode 0. -- balbi -- 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: [RFC][PATCH 1/1] serial: OMAP driver
Tony,
> Hi,
>
> Some comments below.
>
> * Girish. S. G. <[EMAIL PROTECTED]> [080731 14:26]:
>> Serial driver for OMAP Uart controllers
>>
>> Signed-off-by: Girish S G <[EMAIL PROTECTED]>
>> ---
>> arch/arm/configs/omap_3430sdp_defconfig | 12
>> arch/arm/mach-omap2/serial.c| 166 ++---
>> drivers/serial/Kconfig | 23
>> drivers/serial/Makefile |1
>> drivers/serial/omap-serial.c| 887
>>
>> include/linux/serial_core.h |3
>> 6 files changed, 974 insertions(+), 118 deletions(-)
>>
>> Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
>> }
>> -}
>> -
>> -static struct platform_device serial_device = {
>> -.name = "serial8250",
>> -.id = PLAT8250_DEV_PLATFORM,
>> -.dev= {
>> -.platform_data = serial_platform_data,
>> -},
>> -};
>
> What about powering UART on/off? I suggest you provide set_power()
> function in platform_data. That way the UART power function can be
> generic on later omaps, or external like the FPGA on omap1510.
There isn't any specific power on/off for UART as such(or any on omap1510?).
But yes we can have all the clk and pm related functions to be grouped under
uart_ops->pm().
>> +static struct console serial_omap_console = {
>> +.name = "ttyS",
>> +.write = serial_omap_console_write,
>> +.device = uart_console_device,
>> +.setup = serial_omap_console_setup,
>> +.flags = CON_PRINTBUFFER,
>> +.index = -1,
>> +.data = &serial_omap_reg,
>> +};
>> +
>
> AFAIK using ttyS name will break hot-plug 8250 ports, such as CF ports.
> How about using ttyO or something similar? I guess the minor number also
> needs to be different then.
>
> In general, will this driver also work on DaVinci? Maybe use name like
> serial_ti or similar?
I don't think the name would conflict as only our uart instance would be up and
working. Right now this driver is supported and tested only on OMAP2/OMAP3. But
yes, once it's in it can be easily ported on other TI platforms.
I will resend the patch with only OMAP2/OMAP3 support as of now.
Regards,
Girish
--
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
[RFC][Resending: PATCH 1/1] serial: OMAP driver
Serial driver for OMAP Uart controllers for OMAP2/OMAP3. Tested only on
OMAP3430ES2.0
Signed-off-by: Girish S G <[EMAIL PROTECTED]>
---
arch/arm/configs/omap_3430sdp_defconfig | 12
arch/arm/mach-omap2/serial.c| 164 ++---
drivers/serial/Kconfig | 23
drivers/serial/Makefile |1
drivers/serial/omap-serial.c| 886
include/linux/serial_core.h |3
6 files changed, 972 insertions(+), 117 deletions(-)
Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
===
--- linux-omap-2.6.orig/arch/arm/configs/omap_3430sdp_defconfig 2008-08-21
09:56:48.0 +0530
+++ linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig 2008-08-21
10:00:15.0 +0530
@@ -683,19 +683,13 @@
#
# Serial drivers
#
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=32
-CONFIG_SERIAL_8250_RUNTIME_UARTS=4
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_8250_DETECT_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
+# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_OMAP=y
+CONFIG_SERIAL_OMAP_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
Index: linux-omap-2.6/arch/arm/mach-omap2/serial.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/serial.c2008-08-21
09:56:52.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/serial.c 2008-08-22 15:42:17.0
+0530
@@ -14,8 +14,9 @@
*/
#include
#include
-#include
#include
+#include
+#include
#include
#include
@@ -23,85 +24,66 @@
#include
#include
-static struct clk *uart_ick[OMAP_MAX_NR_PORTS];
-static struct clk *uart_fck[OMAP_MAX_NR_PORTS];
-static struct plat_serial8250_port serial_platform_data[] = {
+static struct resource omap2_uart1_resources[] = {
{
- .membase= (__force void __iomem
*)IO_ADDRESS(OMAP_UART1_BASE),
- .mapbase= (unsigned long)OMAP_UART1_BASE,
- .irq= 72,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
+ .start = OMAP_UART1_BASE,
+ .end= OMAP_UART1_BASE + 0x3ff,
+ .flags = IORESOURCE_MEM,
}, {
- .membase= (__force void __iomem
*)IO_ADDRESS(OMAP_UART2_BASE),
- .mapbase= (unsigned long)OMAP_UART2_BASE,
- .irq= 73,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .membase= (__force void __iomem
*)IO_ADDRESS(OMAP_UART3_BASE),
- .mapbase= (unsigned long)OMAP_UART3_BASE,
- .irq= 74,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
+ .start = 72,
+ .flags = IORESOURCE_IRQ,
}
};
-static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
- int offset)
-{
- offset <<= up->regshift;
- return (unsigned int)__raw_readb(up->membase + offset);
-}
-
-static inline void serial_write_reg(struct plat_serial8250_port *p, int offset,
- int value)
-{
- offset <<= p->regshift;
- __raw_writeb(value, p->membase + offset);
-}
-
-/*
- * Internal UARTs need to be initialized for the 8250 autoconfig to work
- * properly. Note that the TX watermark initialization may not be needed
- * once the 8250.c watermark handling code is merged.
- */
-static inline void __init omap_serial_reset(struct plat_serial8250_port *p)
-{
- serial_write_reg(p, UART_OMAP_MDR1, 0x07);
- serial_write_reg(p, UART_OMAP_SCR, 0x08);
- serial_write_reg(p, UART_OMAP_MDR1, 0x00);
- serial_write_reg(p, UART_OMAP_SYSC, (0x02 << 3) | (1 << 2) | (1 << 0));
-}
+static struct resource omap2_uart2_resources[] = {
+ {
+ .start = OMAP_UART2_BASE,
+ .end= OMAP_UART2_BASE + 0x3ff,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = 73,
+ .flags = IORESOURCE_IRQ,
+ }
+};
-void omap_serial_enable_clocks(int enable)
-{
- int i;
- for (i = 0; i < OMAP_MAX_NR_PORTS; i++) {
- if (uart_ick[i]
[PATCH] Fix the broken functionalit
From: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
TWL4030-RTC: Fix the broken functionality.
rtc_irq_set_freq() function takes only powers of 2 as a valid
argument. This stipulates that an ioctl call on /dev/rtc0
can accept values of 1,2,4 and 8 only. But the function
twl4030_rtc_irq_set_freq() takes only values 0-3. RTC_INTERRUPTS_REG
of TWL4030 also requires value in the range 0-3 for the interrupt
period. Hence it is required to map the argument from the powers of 2,
to the corresponding numbers 0-3, via a call to ilog2.
Signed-off-by: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
Index: my-local-git-dir/drivers/rtc/rtc-twl4030.c
===
--- my-local-git-dir.orig/drivers/rtc/rtc-twl4030.c 2008-08-22
17:37:33.0 +0530
+++ my-local-git-dir/drivers/rtc/rtc-twl4030.c 2008-08-22 19:25:41.616786397
+0530
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -363,14 +364,26 @@ out:
static int twl4030_rtc_irq_set_freq(struct device *dev, int freq)
{
struct rtc_device *rtc = dev_get_drvdata(dev);
+ u8 value;
- if (freq < 0 || freq > 3)
+ /* RTC_INTERRUPTS_REG takes the value of 0 for interrupts every
+* second, 1 for every minute, 2 every hour and 3 every day.
+* But freq is in 2^N format, which needs to be converted back.
+*/
+ value = ilog2(freq);
+ if (value < 0 || value > 3)
return -EINVAL;
- rtc->irq_freq = freq;
+ rtc->irq_freq = value;
+
+ /* Clear the current periodicity of irq*/
+ mask_rtc_irq_bit(0x3);
- /* set rtc irq freq to user defined value */
- set_rtc_irq_bit(freq);
+ /* If the new value is non-zero, set the new periodicity */
+ if (value) {
+ /* set rtc irq freq to user defined value */
+ set_rtc_irq_bit(freq);
+ }
return 0;
}
--
With Regards,
Jagadeesh Bhaskar P
Some men see things as they are and say why - I dream things that never were
and say why not.
- George Bernard Shaw
---
--
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 resend] TWL4030-RTC: Fix the broken functionality
From: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
rtc_irq_set_freq() function takes only powers of 2 as a valid
argument. This stipulates that an ioctl call on /dev/rtc0
can accept values of 1,2,4 and 8 only. But the function
twl4030_rtc_irq_set_freq() takes only values 0-3. RTC_INTERRUPTS_REG
of TWL4030 also requires value in the range 0-3 for the interrupt
period. Hence it is required to map the argument from the powers of 2,
to the corresponding numbers 0-3, via a call to ilog2.
Signed-off-by: Jagadeesh Bhaskar Pakaravoor <[EMAIL PROTECTED]>
---
Index: my-local-git-dir/drivers/rtc/rtc-twl4030.c
===
--- my-local-git-dir.orig/drivers/rtc/rtc-twl4030.c 2008-08-22
17:37:33.0 +0530
+++ my-local-git-dir/drivers/rtc/rtc-twl4030.c 2008-08-22 19:25:41.616786397
+0530
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -363,14 +364,26 @@ out:
static int twl4030_rtc_irq_set_freq(struct device *dev, int freq)
{
struct rtc_device *rtc = dev_get_drvdata(dev);
+ u8 value;
- if (freq < 0 || freq > 3)
+ /* RTC_INTERRUPTS_REG takes the value of 0 for interrupts every
+* second, 1 for every minute, 2 every hour and 3 every day.
+* But freq is in 2^N format, which needs to be converted back.
+*/
+ value = ilog2(freq);
+ if (value < 0 || value > 3)
return -EINVAL;
- rtc->irq_freq = freq;
+ rtc->irq_freq = value;
+
+ /* Clear the current periodicity of irq*/
+ mask_rtc_irq_bit(0x3);
- /* set rtc irq freq to user defined value */
- set_rtc_irq_bit(freq);
+ /* If the new value is non-zero, set the new periodicity */
+ if (value) {
+ /* set rtc irq freq to user defined value */
+ set_rtc_irq_bit(freq);
+ }
return 0;
}
--
With Regards,
Jagadeesh Bhaskar P
Some men see things as they are and say why - I dream things that never were
and say why not.
- George Bernard Shaw
---
--
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] OMAP:MUSB: Corrects urb unlink function path
On Fri, 22 Aug 2008 [EMAIL PROTECTED] wrote: > From: Ajay Kumar Gupta <[EMAIL PROTECTED]> > > Fixes kernel panic while ISO IN transfer is aborted.Replaced > usb_hcd_unlink_urb_from_ep() from musb_giveback() to __musb_giveback() to > make sure urb is unlinked before giveback when __musb_giveback() is called > from musb_urb_dequeue(). > > Signed-off-by: Ajay Kumar Gupta <[EMAIL PROTECTED]> > --- > drivers/usb/musb/musb_host.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > index 93b0678..a889ac4 100644 > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -292,6 +292,7 @@ __acquires(musb->lock) > ); > > spin_unlock(&musb->lock); > + usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb); > usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status); > spin_lock(&musb->lock); This is wrong. You must call usb_hcd_unlink_urb_from_ep() while holding musb->lock. Alan Stern -- 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
cool gadget
http://www.linuxdevices.com/news/NS8246055816.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: [PATCH] OMAP:MUSB: Corrects urb unlink function path
On Fri, 22 Aug 2008 [EMAIL PROTECTED] wrote: > From: Ajay Kumar Gupta <[EMAIL PROTECTED]> > > Fixes kernel panic while ISO IN transfer is aborted.Replaced > usb_hcd_unlink_urb_from_ep() from musb_giveback() to __musb_giveback() to > make sure urb is unlinked before giveback when __musb_giveback() is called > from musb_urb_dequeue(). > > Signed-off-by: Ajay Kumar Gupta <[EMAIL PROTECTED]> > --- > drivers/usb/musb/musb_host.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > index 93b0678..a889ac4 100644 > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -292,6 +292,7 @@ __acquires(musb->lock) > ); > > spin_unlock(&musb->lock); > + usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb); > usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status); > spin_lock(&musb->lock); This is wrong. You must call usb_hcd_unlink_urb_from_ep() while holding musb->lock. You are correct. the unlink function should be moved above spin_unlock(). as, + usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb); spin_unlock(&musb->lock); usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status); spin_lock(&musb->lock); Simiar locking issue is also in enqueue path where unlink is being done without holding musb->lock. Alan Stern-- 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] OMAP:MUSB: Corrects urb unlink function path
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Gupta, Ajay Kumar [EMAIL PROTECTED] Sent: Friday, August 22, 2008 8:44 PM To: Alan Stern Cc: linux-omap@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PATCH] OMAP:MUSB: Corrects urb unlink function path On Fri, 22 Aug 2008 [EMAIL PROTECTED] wrote: > From: Ajay Kumar Gupta <[EMAIL PROTECTED]> > > Fixes kernel panic while ISO IN transfer is aborted.Replaced > usb_hcd_unlink_urb_from_ep() from musb_giveback() to __musb_giveback() to > make sure urb is unlinked before giveback when __musb_giveback() is called > from musb_urb_dequeue(). > > Signed-off-by: Ajay Kumar Gupta <[EMAIL PROTECTED]> > --- > drivers/usb/musb/musb_host.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > index 93b0678..a889ac4 100644 > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -292,6 +292,7 @@ __acquires(musb->lock) > ); > > spin_unlock(&musb->lock); > + usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb); > usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status); > spin_lock(&musb->lock); >This is wrong. You must call usb_hcd_unlink_urb_from_ep() while >holding musb->lock. > >You are correct. the unlink function should be moved above spin_unlock(). as, > >+ usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb); > spin_unlock(&musb->lock); > usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status); > spin_lock(&musb->lock); >Simiar locking issue is also in enqueue path where unlink is being done >without holding musb->lock. I will resend the patch with other lock fixes. Ajay >Alan Stern-- >To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
[PATCH v2] OMAP:MUSB: Corrects urb unlink function path
From: Ajay Kumar Gupta <[EMAIL PROTECTED]>
Fixes kernel panic while ISO IN transfer is aborted.Replaced
usb_hcd_unlink_urb_from_ep() from musb_giveback() to __musb_giveback()
to make sure urb is unlinked before giveback when __musb_giveback() is
called from musb_urb_dequeue().
Moved usb_hcd_unlink_urb_from_ep() within musb->lock() in enqueue path.
Signed-off-by: Ajay Kumar Gupta <[EMAIL PROTECTED]>
---
drivers/usb/musb/musb_host.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 08e421f..2bdedf2 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -291,6 +291,7 @@ __acquires(musb->lock)
urb->actual_length, urb->transfer_buffer_length
);
+ usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb);
spin_unlock(&musb->lock);
usb_hcd_giveback_urb(musb_to_hcd(musb), urb, status);
spin_lock(&musb->lock);
@@ -353,8 +354,6 @@ musb_giveback(struct musb_qh *qh, struct urb *urb, int
status)
break;
}
- usb_hcd_unlink_urb_from_ep(musb_to_hcd(musb), urb);
-
qh->is_ready = 0;
__musb_giveback(musb, urb, status);
qh->is_ready = ready;
@@ -1785,9 +1784,11 @@ static int musb_urb_enqueue(
* REVISIT consider a dedicated qh kmem_cache, so it's harder
* for bugs in other kernel code to break this driver...
*/
+ spin_lock_irqsave(&musb->lock, flags);
qh = kzalloc(sizeof *qh, mem_flags);
if (!qh) {
usb_hcd_unlink_urb_from_ep(hcd, urb);
+ spin_unlock_irqrestore(&musb->lock, flags);
return -ENOMEM;
}
@@ -1878,7 +1879,6 @@ static int musb_urb_enqueue(
* until we get real dma queues (with an entry for each urb/buffer),
* we only have work to do in the former case.
*/
- spin_lock_irqsave(&musb->lock, flags);
if (hep->hcpriv) {
/* some concurrent activity submitted another urb to hep...
* odd, rare, error prone, but legal.
@@ -1895,13 +1895,13 @@ static int musb_urb_enqueue(
* musb_start_urb(), but otherwise only konicawc cares ...
*/
}
- spin_unlock_irqrestore(&musb->lock, flags);
done:
if (ret != 0) {
usb_hcd_unlink_urb_from_ep(hcd, urb);
kfree(qh);
}
+ spin_unlock_irqrestore(&musb->lock, flags);
return ret;
}
--
1.5.6
--
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 v2] OMAP:MUSB: Corrects urb unlink function path
On Fri, 22 Aug 2008 [EMAIL PROTECTED] wrote:
> @@ -1785,9 +1784,11 @@ static int musb_urb_enqueue(
>* REVISIT consider a dedicated qh kmem_cache, so it's harder
>* for bugs in other kernel code to break this driver...
>*/
> + spin_lock_irqsave(&musb->lock, flags);
> qh = kzalloc(sizeof *qh, mem_flags);
> if (!qh) {
> usb_hcd_unlink_urb_from_ep(hcd, urb);
> + spin_unlock_irqrestore(&musb->lock, flags);
> return -ENOMEM;
> }
This doesn't look right. After calling spin_lock_irqsave you are in an
atomic context, so you can't pass mem_flags to kzalloc.
Either move the spin_lock_irqsave after the call to kzalloc or else
change mem_flags to GFP_ATOMIC.
Alan Stern
--
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 2/4] PM: Workaround for taking care of gpio clocks
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [080821 14:08]: > > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of ext > >Tony Lindgren > >Sent: 20 August, 2008 14:37 > >To: Hogander Jouni (Nokia-D/Tampere) > >Cc: linux-omap@vger.kernel.org > >Subject: Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks > > > >* Jouni Hogander <[EMAIL PROTECTED]> [080815 10:47]: > >> In omap3 gpios 2-6 are in per domain. Functional clocks for these > >> should be disabled. This patch is needed until gpio driver disables > >> gpio clocks. > >> > >> GPIO modules in PER domain are not able to act as a wake up > >source if > >> PER domain is in retention. PER domain sleep transition > >before MPU is > >> prevented by leaving icks active. PER domain still enters retention > >> together with MPU. When this happens IOPAD wake up mechanism is used > >> for gpios. > > > >As we talked offline.. Should we pass the GPIO wake-up > >configuration from board-*.c files? Or can we always > >automatically do this safely on 34xx? > > After some investigation it seems that we can configure wake-up events > for almost every GPIO from the padconfigs. There are only 2 pins that do > not seem to have this functionality, however I am not sure if this is a > documentation bug or what because it is strange that only 2 pins lack > this capability. GPIOs 32 and 187 are missing wake-up capability from > padconfig. > > Because of this, our proposal would be to make GPIO clock switching > global, but this would be enabled from a sysfs entry pretty much like > how it is in the patches now. However, this would be separated from UART > clock switching. So, we would introduce two new sysfs files: > uart_clocks_off_while_idle and gpio_clocks_off_while_idle. This would > avoid introducing new complexity in to the idle loop. > > How does this sound like? Sounds good to me. Then we may be able to remove both sysfs files eventually. Regards, Tony -- 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 1/4] 34XX: PM: Workaround to check wether any fck is active before entering sleep
* Högander Jouni <[EMAIL PROTECTED]> [080822 08:45]:
> "ext Tony Lindgren" <[EMAIL PROTECTED]> writes:
>
> > * Jouni Hogander <[EMAIL PROTECTED]> [080815 10:47]:
> >> This workaround shouldn't be needed when all drivers are configuring
> >> their sysconfig registers properly and using their clocks properly.
> >
> > How about the cosmetically prettified version below? This could
> > still be kept around as CONFIG_PM_DEBUG functionality even after
> > the drivers are fixed.
>
> Sounds ok to me. I don't get how PM_DEBUG option is related to this,
> but anyway ok to me.
OK will push then. PM_DEBUG option comment was just to be able to
maybe warn about debug broken drivers if idle fails or something
like that.
Tony
> >
> > Tony
> >
> >>From e37e8acd7685df9cb39f2fbc7887ba36639d5820 Mon Sep 17 00:00:00 2001
> > From: Jouni Hogander <[EMAIL PROTECTED]>
> > Date: Wed, 20 Aug 2008 14:32:46 +0300
> > Subject: [PATCH] ARM: OMAP: 34xx specific check wether any fck is active
> > before entering sleep
> >
> > We cannot enter sleep_while_idle if some functional clocks are
> > active. Add a check for enabled functional clocks for 34xx.
> >
> > Note that this workaround could be behind CONFIG_PM_DEBUG
> > option when all drivers are configuring their sysconfig
> > registers properly and using their clocks properly.
> >
> > Signed-off-by: Jouni Hogander <[EMAIL PROTECTED]>
> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> >
> > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> > index a57cf41..a145f80 100644
> > --- a/arch/arm/mach-omap2/pm34xx.c
> > +++ b/arch/arm/mach-omap2/pm34xx.c
> > @@ -174,10 +174,47 @@ static void omap_sram_idle(void)
> > omap2_gpio_resume_after_retention();
> > }
> >
> > +/*
> > + * Check if functional clocks are enabled before entering
> > + * sleep. This function could be behind CONFIG_PM_DEBUG
> > + * when all drivers are configuring their sysconfig registers
> > + * properly and using their clocks properly.
> > + */
> > +static int omap3_fclks_active(void)
> > +{
> > + u32 fck_core1 = 0, fck_core3 = 0, fck_sgx = 0, fck_dss = 0,
> > + fck_cam = 0, fck_per = 0, fck_usbhost = 0;
> > +
> > + fck_core1 = cm_read_mod_reg(CORE_MOD,
> > + CM_FCLKEN1);
> > + if (is_sil_rev_greater_than(OMAP3430_REV_ES1_0)) {
> > + fck_core3 = cm_read_mod_reg(CORE_MOD,
> > + OMAP3430ES2_CM_FCLKEN3);
> > + fck_sgx = cm_read_mod_reg(OMAP3430ES2_SGX_MOD,
> > + CM_FCLKEN);
> > + fck_usbhost = cm_read_mod_reg(OMAP3430ES2_USBHOST_MOD,
> > + CM_FCLKEN);
> > + } else
> > + fck_sgx = cm_read_mod_reg(GFX_MOD,
> > + OMAP3430ES2_CM_FCLKEN3);
> > + fck_dss = cm_read_mod_reg(OMAP3430_DSS_MOD,
> > + CM_FCLKEN);
> > + fck_cam = cm_read_mod_reg(OMAP3430_CAM_MOD,
> > + CM_FCLKEN);
> > + fck_per = cm_read_mod_reg(OMAP3430_PER_MOD,
> > + CM_FCLKEN);
> > + if (fck_core1 | fck_core3 | fck_sgx | fck_dss |
> > + fck_cam | fck_per | fck_usbhost)
> > + return 1;
> > + return 0;
> > +}
> > +
> > static int omap3_can_sleep(void)
> > {
> > if (!enable_dyn_sleep)
> > return 0;
> > + if (omap3_fclks_active())
> > + return 0;
> > if (atomic_read(&sleep_block) > 0)
> > return 0;
> > return 1;
>
> --
> Jouni Högander
>
--
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 v2] OMAP:MUSB: Corrects urb unlink function path
On Fri, Aug 22, 2008 at 01:32:12PM -0400, Alan Stern wrote:
> On Fri, 22 Aug 2008 [EMAIL PROTECTED] wrote:
>
> > @@ -1785,9 +1784,11 @@ static int musb_urb_enqueue(
> > * REVISIT consider a dedicated qh kmem_cache, so it's harder
> > * for bugs in other kernel code to break this driver...
> > */
>
> This doesn't look right. After calling spin_lock_irqsave you are in an
> atomic context, so you can't pass mem_flags to kzalloc.
>
> Either move the spin_lock_irqsave after the call to kzalloc or else
> change mem_flags to GFP_ATOMIC.
first one, please.
should be like:
qh = kzalloc(sizeof *qh, mem_flags);
if (!qh) {
+ spin_lock_irqsave(&musb->lock, flags);
usb_hcd_unlink_urb_from_ep(hcd, urb);
+ spin_unlock_irqrestore(&musb->lock, flags);
return -ENOMEM;
}
--
balbi
pgpYPZiULaFFp.pgp
Description: PGP signature
Re: [RFC][PATCH 1/1] serial: OMAP driver
* Girish. S. G. <[EMAIL PROTECTED]> [080822 15:42]:
> Tony,
>
> > Hi,
> >
> > Some comments below.
> >
> > * Girish. S. G. <[EMAIL PROTECTED]> [080731 14:26]:
> >> Serial driver for OMAP Uart controllers
> >>
> >> Signed-off-by: Girish S G <[EMAIL PROTECTED]>
> >> ---
> >> arch/arm/configs/omap_3430sdp_defconfig | 12
> >> arch/arm/mach-omap2/serial.c| 166 ++---
> >> drivers/serial/Kconfig | 23
> >> drivers/serial/Makefile |1
> >> drivers/serial/omap-serial.c| 887
> >>
> >> include/linux/serial_core.h |3
> >> 6 files changed, 974 insertions(+), 118 deletions(-)
> >>
> >> Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
>
> >>}
> >> -}
> >> -
> >> -static struct platform_device serial_device = {
> >> - .name = "serial8250",
> >> - .id = PLAT8250_DEV_PLATFORM,
> >> - .dev= {
> >> - .platform_data = serial_platform_data,
> >> - },
> >> -};
> >
> > What about powering UART on/off? I suggest you provide set_power()
> > function in platform_data. That way the UART power function can be
> > generic on later omaps, or external like the FPGA on omap1510.
>
> There isn't any specific power on/off for UART as such(or any on omap1510?).
> But yes we can have all the clk and pm related functions to be grouped under
> uart_ops->pm().
Yeah I believe it's an external power for early omaps. So some board
specific function pointer should be available for that.
>
> >> +static struct console serial_omap_console = {
> >> + .name = "ttyS",
> >> + .write = serial_omap_console_write,
> >> + .device = uart_console_device,
> >> + .setup = serial_omap_console_setup,
> >> + .flags = CON_PRINTBUFFER,
> >> + .index = -1,
> >> + .data = &serial_omap_reg,
> >> +};
> >> +
> >
> > AFAIK using ttyS name will break hot-plug 8250 ports, such as CF ports.
> > How about using ttyO or something similar? I guess the minor number also
> > needs to be different then.
> >
> > In general, will this driver also work on DaVinci? Maybe use name like
> > serial_ti or similar?
>
> I don't think the name would conflict as only our uart instance would be up
> and
> working. Right now this driver is supported and tested only on OMAP2/OMAP3.
> But
> yes, once it's in it can be easily ported on other TI platforms.
The thing is this driver won't be accepted upstream if it conflicts
with hot-pluggable 8250 ports. AFAIK, you need to get a new id for it,
and call it something like ttyO instead.
> I will resend the patch with only OMAP2/OMAP3 support as of now.
Yeah that's fine as long as the functions can be added for ther omaps
later on as needed.
Tony
--
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: cool gadget
On Fri, 2008-08-22 at 09:48 -0500, ext Woodruff, Richard wrote: > http://www.linuxdevices.com/news/NS8246055816.html Yes, cool, but this one http://www.speaknspell.co.uk/speaknspell.html wins hands down :-D -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- 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: cool gadget
On Fri, Aug 22, 2008 at 11:32:49PM +0300, Igor Stoppa wrote: > http://www.speaknspell.co.uk/speaknspell.html > > wins hands down :-D ehehe, great. My new time killer application :-) -- balbi -- 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][OMAP 3/4] dspbridge latest patches
Hi all, The following patches were submitted to the Omap 3/4 Linux Kernel tree, please find them at the following link: http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseView&release_id=119 Patch order: 1. 0020-BRIDGE-use-likely-unlikely-for-status-checking.patch (Hiroshi.DOYU) 2. 0021-BRIDGE-add-table-end-wcd.patch (Omar Ramirez) 3. 0022-BRIDGE-headers-to-plat-omap.patch (Omar Ramirez) 4. 0023-BRIDGE-wcd-sparse-user-space-warnings.patch (Fernando Guzman) - omar -- 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
[omapzoom] Dspbridge binaries
Hi, You can find dspbridge binaries uploaded into omapzoom site: http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseView&release_id=132 Base images (.dof64P) are statically linked DSP executables loaded on the DSP when system boots up, dynamic libraries (.dll64P) are DSP object files that can be loaded into virtually any address on the DSPloading examples. For more information please refer to the Readme file (in the previous link) or db_linux_rguide.pdf found at: http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 - omar -- 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: [omapzoom] Dspbridge binaries
Hi Omar, > You can find dspbridge binaries uploaded into omapzoom site: > > http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseView&release_id=132 > Thanks. Are these binaries compatible with the Bridge driver on 3/4+ tree ? > Base images (.dof64P) are statically linked DSP executables loaded on the DSP > when system boots up, dynamic libraries (.dll64P) are DSP object files that > can be loaded into virtually any address on the DSPloading examples. For more > information please refer to the Readme file (in the previous link) or > db_linux_rguide.pdf found at: > I think you mean db_linux_pguide.pdf and not db_linux_rguide.pdf BR, Stalin On Fri, Aug 22, 2008 at 8:51 PM, Ramirez Luna, Omar <[EMAIL PROTECTED]> wrote: > Hi, > > You can find dspbridge binaries uploaded into omapzoom site: > > http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseView&release_id=132 > > Base images (.dof64P) are statically linked DSP executables loaded on the DSP > when system boots up, dynamic libraries (.dll64P) are DSP object files that > can be loaded into virtually any address on the DSPloading examples. For more > information please refer to the Readme file (in the previous link) or > db_linux_rguide.pdf found at: > > http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 > > - omar > -- > 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: [omapzoom] Dspbridge binaries
Hi Omar, > You can find dspbridge binaries uploaded into omapzoom site: > > http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseView&release_id=132 > Thanks. Are these binaries compatible with the Bridge driver on 3/4+ tree ? - Yes, they're > Base images (.dof64P) are statically linked DSP executables loaded on the DSP > when system boots up, dynamic libraries (.dll64P) are DSP object files that > can be loaded into virtually any address on the DSPloading examples. For more > information please refer to the Readme file (in the previous link) or > db_linux_rguide.pdf found at: > I think you mean db_linux_pguide.pdf and not db_linux_rguide.pdf - Tricked you to download the other one :), yes I mean db_linux_pguide.pdf BR, Stalin On Fri, Aug 22, 2008 at 8:51 PM, Ramirez Luna, Omar <[EMAIL PROTECTED]> wrote: > Hi, > > You can find dspbridge binaries uploaded into omapzoom site: > > http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseView&release_id=132 > > Base images (.dof64P) are statically linked DSP executables loaded on the DSP > when system boots up, dynamic libraries (.dll64P) are DSP object files that > can be loaded into virtually any address on the DSPloading examples. For more > information please refer to the Readme file (in the previous link) or > db_linux_rguide.pdf found at: > > http://omapzoom.org/gf/project/omapbridge/docman/?subdir=3 > > - omar > -- > 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: [PATCH v2] OMAP:MUSB: Corrects urb unlink function path
On Fri, Aug 22, 2008 at 01:32:12PM -0400, Alan Stern wrote:
> On Fri, 22 Aug 2008 [EMAIL PROTECTED] wrote:
>
> > @@ -1785,9 +1784,11 @@ static int musb_urb_enqueue(
> > * REVISIT consider a dedicated qh kmem_cache, so it's harder
> > * for bugs in other kernel code to break this driver...
> > */
>
> This doesn't look right. After calling spin_lock_irqsave you are in an
> atomic context, so you can't pass mem_flags to kzalloc.
>
> Either move the spin_lock_irqsave after the call to kzalloc or else
> change mem_flags to GFP_ATOMIC.
first one, please.
should be like:
qh = kzalloc(sizeof *qh, mem_flags);
if (!qh) {
+ spin_lock_irqsave(&musb->lock, flags);
usb_hcd_unlink_urb_from_ep(hcd, urb);
+ spin_unlock_irqrestore(&musb->lock, flags);
return -ENOMEM;
}
Similarly at the end of enqueue(),
if (ret != 0) {
+ spin_lock_irqsave(&musb->lock, flags);
usb_hcd_unlink_urb_from_ep(hcd, urb);
+ spin_unlock_irqrestore(&musb->lock, flags);
kfree(qh);
}
So hold the musb->lock at the two places in enqueue path and no
other change. If this is fine then I will resubmit with this modification.
--Ajay
--
balbi--
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
