Yes, unfortunately. I'm focusing on the isochronous support right now.
I'm using the ISP1761, which doesn't support OTG.
You'll notice in the archives that every so often another poor soul
asks for help with the isp176x, but more than one has chosen to ditch
their hardware rather than fight it ou
On Fri, May 19, 2006 at 08:50:50PM -0400, Paul Giblock wrote:
> >
> >If it's not an interrupt or a bulk, what is it?
> >
>
> It _is_ an interrupt endpoint.
>
> >
> >usb_bulk_msg() should work just fine for interrupt endpoints and bulk
> >endpoints. What are you trying to connect to here?
> >
>
If it's not an interrupt or a bulk, what is it?
It _is_ an interrupt endpoint.
usb_bulk_msg() should work just fine for interrupt endpoints and bulk
endpoints. What are you trying to connect to here?
It should, but it doesn't. On one system (VIA EDEN with Gentoo
2.6.15) it works fine.
On Fri, May 19, 2006 at 07:58:00PM -0400, Paul Giblock wrote:
> Sorry Greg, but your patch does not work, I tried using usb_bulk_msg()
> in the first place but it returns -22 (-EINVAL) this is because the
> pipe is not an interrupt pipe.
If it's not an interrupt or a bulk, what is it?
> Using usb
Sorry Greg, but your patch does not work, I tried using usb_bulk_msg()
in the first place but it returns -22 (-EINVAL) this is because the
pipe is not an interrupt pipe. Using usb_bulk_msg() does work on
another one of my machines, however.
A properly written solution would be a modified version
On Fri, May 19, 2006 at 03:23:24PM -0700, Greg KH wrote:
> On Fri, May 19, 2006 at 01:21:52AM -0400, Paul Giblock wrote:
> > Hello, sorry about the last message. I figured it out on my own. I
> > was always sort of surprised that usb_bulk_msg would work fine with
> > interrupt endpoints, so it was
On Fri, May 19, 2006 at 01:21:52AM -0400, Paul Giblock wrote:
> Hello, sorry about the last message. I figured it out on my own. I
> was always sort of surprised that usb_bulk_msg would work fine with
> interrupt endpoints, so it was just a matter of time until it would
> not. Anyways, I solved t
On Fri, May 19, 2006 at 12:20:25PM -0400, Mike Panetta wrote:
> Please CC me on all replies since I seem to be having issues
> subscribing to the list...
>
> I am working on writing a USB Serial driver roughly based on the
> Keyspan_pda driver, and I am running into real strange issues. As
> this
On Fri, May 19, 2006 at 10:35:28PM +0200, Bart Verstraete wrote:
> Hi,
> got this code for a dacal dc300, its a cd library,more info on
> http://www.dacal.com.tw. But now I want to convert it to a kernel
> module, but the first thing I don't know how I would use the function
> usb_control_msg().
Greg:
This patch (as690) does the same thing for ISO TDs as as680 did for
non-ISO TDs: free them as they are used rather than all at once when an
URB is complete. At the same time it fixes a minor buglet (I'm not aware
of it ever affecting anyone): An ISO TD should be retired when its frame
i
On Fri, 19 May 2006, David Brownell wrote:
> On Friday 19 May 2006 10:34 am, Alan Stern wrote:
> > Dave:
> >
> > While trying to test some changes to the ISO handling in uhci-hcd, I ran
> > across a whole mess of bugs.
> >
> > Easy one first: The ISO tests in usbtest don't report
> > e
Greg:
This patch (as689) stores the period for periodic transfers (interrupt and
ISO) in the queue header. This is necessary for proper bandwidth
tracking (not yet implemented). It also makes the scheduling of ISO
transfers a bit more rigorous, with checks for out-of-bounds frame
numbers.
A
Greg:
This patch (as688) fixes a small race in uhci-hcd. Because ISO queues
aren't controlled by queue headers, they can't be unlinked. Only
individual URBs can. So whenever multiple ISO URBs are dequeued, it's
necessary to make sure the hardware is done with each one. We can't
assume that deq
Hi,
got this code for a dacal dc300, its a cd library,more info on
http://www.dacal.com.tw. But now I want to convert it to a kernel
module, but the first thing I don't know how I would use the function
usb_control_msg(). I need it to fill with the data I retrieve from
usbsnoop.log that is in
Greg:
This patch (as687) changes uhci-hcd to keep track of frame numbers as
full-sized integers rather than 11-bit values. This makes them a lot
easier to handle and makes it possible to schedule beyond a 2-second
window, should anyone ever want to do so.
Alan Stern
Signed-off-by: Alan Ste
This patch increases an arbitrary limit on the size of
individual isochronous packets submitted via usbfs. The
limit is still arbitrary, but it's now large enough to
support the maximum packet size used by high-bandwidth
isochronous transfers.
Signed-off-by: Micah Dowty <[EMAIL PROTECTED]>
Index
On Thursday 18 May 2006 4:08 pm, Greg KH wrote:
> > > After looking through the logs again it appears this may be an Arm related
> > > problem. The dmabounce message is saying there is a device on the pci
> > > bus and
> > > then the drivers attach. When it fails the dmabounce message is coming
On Friday 19 May 2006 10:34 am, Alan Stern wrote:
> Dave:
>
> While trying to test some changes to the ISO handling in uhci-hcd, I ran
> across a whole mess of bugs.
>
> Easy one first: The ISO tests in usbtest don't report
> errors! test_iso_queue() will return 0 even if all the
>
This patch removes the artificial 4088-byte limit that usbfs
currently places on Control transfers. The USB spec does not
specify a strict limit on the size of an entire control transfer.
It does, however, state that the data stage "follows the same
protocol rules as bulk transfers." (USB 2, 8.5.3
Dave:
While trying to test some changes to the ISO handling in uhci-hcd, I ran
across a whole mess of bugs.
Easy one first: The ISO tests in usbtest don't report
errors! test_iso_queue() will return 0 even if all the
URBs fail. Not so good for testing purposes.
Oliver Neukum wrote:
If you allow exactly 32768 the management information for kmalloc will
need additional space pushing the allocation to 64K.
How is this the case for allocations >= PAGE_SIZE? From my understanding
of the slab allocator, the size you give kmalloc() will be immediately
rounde
Please CC me on all replies since I seem to be having issues subscribing to the
list...
I am working on writing a USB Serial driver roughly based on the Keyspan_pda
driver, and I am running into real strange issues. As this is my first serial
driver (and my first serial firmware) I am not quit
On Fri, May 19, 2006 at 03:47:58PM +0530, [EMAIL PROTECTED] wrote:
>
> We need to re-build linux kernel 2.4.25 to support USB Bluetooth Dongle
> for the embedded platform MPC 5200 Lite.
Ick, you will not get much support for 2.4 kernels here, as it is in
maintenance mode only now.
> We are facin
Hi Rakesh,
> Hi Subash,
>
> I am using ARC HS-OTG Core with ULPI Interface. Hope the ARC PHY u are
> referring to is this ULPI interface.
That means you do have ULPI tranceiver chip, that actually provides USB
PHY interface. BTW, it's not ARC PHY here.
> My kernel is 2.6.16-11, the thing is that
Greetings,
The USB_OTG config variable is defined in two places, drivers/usb/core/Kconfig
and drivers/usb/gadget/Kconfig. The former defines it as a simple boolean,
while the later defines it as a choice. This causes `make oldconfig` to
loop infinitely on the USB_OTG choice selection if CONFIG_
We need to re-build linux kernel 2.4.25 to support USB Bluetooth Dongle
for the embedded platform MPC 5200 Lite.
We are facing problem with connecting USB Bluetooth Dongle to icecube
(MPC5200 Lite EVM) running embedded Linux from Denx (Debian flavor). We
would appreciate any kind of help towards
26 matches
Mail list logo
