| Paul Mundt |
| Jul 4, 11:39 am 2009 |
| Steve Henke | Moving from Centos 5.2 to 5.3 Breaks USB HUB Use
Hello All,
I help develop an Asterisk channel driver that uses USB audio devices to
link amateur radio stations via the Internet.
All worked well under Centos 5.2 but I recently upgraded to Centos 5.3.
I now get either "cannot submit datapipe for urb 0, error -28: not
enough bandwidth" followed by a kernel panic or choppy audio depending
on the use of either single or multi-TT hubs. For at least 4 devices,
things do work under Centos 5.3 if I have a PC with 4 USB ports and do
not use a hub. Of c...
| Jul 3, 9:36 pm 2009 |
| Greg KH |
| Jul 3, 11:54 pm 2009 |
| Yang Fei-AFY095 | RE: using cacheable buffer for descriptor
unmap_urb_for_dma?
unmap_urb_for_dma -> dma_unmap_single
dma_unmap_single is defined in arch/arm/include/asm/dma-mapping.h as
following
------ snip ------
#ifndef CONFIG_DMABOUNCE
static inline void
dma_unmap_single(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir)
{
/* nothing to do */
}
#else
extern void dma_unmap_single(struct device *, dma_addr_t, size_t, enum
dma_data_direction);
#endif
------ snip ------
And CONFIG_DMABOUNCE is not defined...
| Jul 3, 11:43 pm 2009 |
| Ming Lei | Re: using cacheable buffer for descriptor
On Fri, 3 Jul 2009 23:43:51 -0400
Since the ARM core of TI-OMAP is not cache coherent, it seems
dma_unmap_*() should do something(such as invalidate cache)
instead of nothing.
--
Lei Ming
--
| Jul 4, 5:11 am 2009 |
| Ming Lei | Re: using cacheable buffer for descriptor
dma_map_*() can invalidate cache lines, so dma_unmap_*() may do nothing.
But if someone accesses the dma buffer during dma transfer, you may
get the inconsistent result.
--
Lei Ming
--
| Jul 4, 11:41 am 2009 |
| Russell King - ARM Linux | Re: using cacheable buffer for descriptor
You missed an important statement: accessing the dma buffer during a dma
transfer is not permitted without an intervening call to the dma_sync_*
functions.
DMA buffers have the idea of "ownership" - they initially start off being
owned by the CPU. Upon dma_map_*(), ownership transfers to the DMA agent,
and remains there until either a dma_unmap_*() or dma_sync_single_for_cpu().
In the case of dma_sync_single_for_cpu(), it can only be given back to the
DMA agent using dma_sync_single_for_device()...
| Jul 4, 2:07 pm 2009 |
| Yang Fei-AFY095 | RE: using cacheable buffer for descriptor
That is right, I don't think in our case the buffer is being accessed
during DMA transfer.
In drivers/usb/core/config.c, function usb_get_descriptor calls
usb_control_msg to submit URB, and that is a blocking call, it wouldn't
return until DMA to RAM is finished.
As Alan pointed out, if dma_map_single() invalidates cache lines for IN
URB, nothing special needs to be done on URB completion.
But the fact that a call to dma_cache_maint before CPU accessing the
buffer makes the inconsistency problem...
| Jul 4, 5:01 pm 2009 |
| Alan Stern | Re: using cacheable buffer for descriptor
I don't know what dma_cache_maint does. If it causes the cache line to
be written back to memory, that's sufficient for OUT transfers. If it
invalidates the cache line, that's sufficient for IN transfers.
Nothing special is needed when the URB completes; when the CPU wants to
access the buffer it will be forced to read the data from RAM.
Correct. In this case, nothing should be accessing the dma buffer
during the transfer.
Alan Stern
--
| Jul 4, 11:51 am 2009 |
| Alexey Klimov | Re: autosuspend for radio-mr800 driver
Hello,
I wanna say thank you for spending time for mr800 driver.
I'm in timeline when i'm preparing 6 or 7 patches for this driver(not
posted yet to maillist). And my patches will conflict with your patch.
Generally because of removing usb_amradio_open/close functions and
radio->users counter. The main reason of removing is needless in them.
And suspend/resume will be realized in other way..
So because you are experienced developer i should i ask you what is
the better option here. Is you p...
| Jul 3, 8:23 pm 2009 |
| Oliver Neukum | Re: autosuspend for radio-mr800 driver
Hi,
no problem. Send me your patches when you will have finished them
and I'll redo mine. Would it be hard for you to leave open/close in the
driver? They are very useful for implementing autosuspend.
Regards
Oliver
--
| Jul 4, 2:48 am 2009 |
| Steve Calfee | Re: possible memleak in devio.c::processcompl
Oops, never mind. The leak is in usb urbs, not usbdevfs urbs, so you
cannot fix the leak without changing a kernel driver (devio.c) to
reuse urbs. But it does explain why cheese/uvcvideo does not leak
until the system crashes - just when it starts up. Changing devio.c to
reuse urbs is probably more effort than fixing the real cause and
patching ehci as described in the earlier link.
Regards, Steve
--
| Jul 4, 1:07 pm 2009 |
| Paul Mundt |
| Jul 4, 11:37 am 2009 |
| Rafael J. Wysocki |
| Jul 4, 7:45 pm 2009 |
