This is an updated version of a patch submitted to me from
Michal Sojka <sojkam1@fel.cvut.cz>, basically providing a
much-needed rewrite of the highspeed ISO support.  I updated
the scheduling and made it a closer match to how OHCI works;
and also tested it a bunch.

So far it seems most of the requests for highspeed ISO support
have been for realtime data collection -- custom apps, nothing
a mainstream kernel would ship with.   The USB Video class is
now defined; highspeed video will also need these updates.

Key changes:

   - Define an "iso_stream" head for iso endpoints.  This acts
     enough like a QH that endpoint_disable() works.  It holds the
     queue of ITDs, and the endpoint's current schedule state.
     And it's easy to find (spinlocked array access), no search.

   - Uses a temporary "itd_sched" while submitting each URB, with
     not-yet-linked ITDs and request-specific metadata.  There's
     a per-stream cache of ITDs, so resubmitting ISO urbs (to
     achieve a "ring" of transfers) is typically cheap.

   - Scheduling for most URBs is almost a NOP:  just a sanity
     check to make sure there's no need to reschedule, and then
     just link into the schedule at the current schedule slot.
     (The previous code was a gross hack that didn't even work
     reasonably with more than two URBs queued.)

   - Is a reasonable model to use with full speed ISO transfers.
     (They need additional TT scheduling hooks, most of which
     are already written but not merged.)

   - Handles several cases the previous code didn't, including
     high bandwidth transfers (loads up to 24 MByte/sec)

   - Has had more testing than the old code, including 20+ hour
     successful IN+OUT runs, more varied transfer intervals and
     maxpacket sizes.  (Using net2280 and a gadgetfs driver.)

So it's worth replacing the existing code with this; there
aren't too many rough edges, and it's much more fixable than
the previous version.


p.s. Many thanks, Michal!

This patch is needed to make high bandwidth ISO streams behave,
but could resolve some other scanning glitches.  Current users
of periodic transfers (interrupt transfer modes for hubs, mice,
and keyboards) shouldn't even notice this change.

It makes the periodic schedule scan handle cases where a given
frame's schedule slot reports completions in several different
microframes.  So far that's been uncommon, but it's typical
for high bandwidth iso (or even with busier interrupt trees than
this driver has supported yet).

It also starts to remove the assumption that each ITD only uses
one microframe; but most of those changes are in the next patch.
And it fixes a bug where some status bits were mis-interpreted as
significant bits in the ITD transfer length.

This is minor "obvious" fixes plus two tweaks to help later
patches:

    - Interrupt QH has a link to the device, needed to implement
      schedule trees (like OHCI does today) that are TT-aware
      (essential for most keyboards and mice).

    - Export the macros that do high bandwidth packetsize stuff.
      They're also needed for high bandwidth ISO transfers.

It also morphs some existing "too much debug info" urb tracing
so it's kicked in by a manual #define EHCI_URB_TRACE.  If some
generic version of that gets added to usbcore, this sort
of debug code can vanish (from all hcds).

Someone sent this around mixed with an EHCI patch which should not
be applied (there's a different patch on the way).  I lost their
name, sorry.  It lets 1024 byte ISO packets be used.

 From Darwin Rambo, <drambo@broadcom.com>

   These get rid of 8 and 16 byte PCI access, which don't work
   on some MIPS platforms.

On Tue, 2003-12-23 at 22:49, David Brownell wrote:
> > This patch should take care of it.  Additionally, I had to fold one of
> > my patches that's in the queue for 2.6.1 (ethtool link check fix) into
> > this as the other would not apply due to changes.
>
> It looks fine, though it didn't apply against Greg's usb-devel-2.6
> tree ... which has a few more methods added.
>
> I guess I'll just add this one to my tree, and let you merge this
> with those additional ax8817x changes.
>
> - Dave
>

Re-diffed against the usb-2.6-devel tree.

There's a couple of old patches floating around still that you might want
to apply.  I have reproduced them below.

as129 handles the situation where a command error causes us to do a device
reset, but the SCSI layer times out and aborts the command during the
reset delay.  It clears a flag that otherwise will prevent us from sending
the clear-halt messages following the reset.

as141 is the DMA buffer alignment patch.  You asked me to remind you about
it eventually.  There shouldn't be any harm at all in applying it without
waiting for the corresponding SCSI part of the patch to be applied.
Without that other part, this will essentially do nothing.

Alan Stern

this patch which applies against Linux-2.6.0 (and also 2.6.1)
adds support for the Emagic A6-2 USB-Audio-Interface.

Note that the selection of either MIDI or SPDIF is actually done
by ifdefs in the driver, this behaviour should clearly be changed
to MODULE_PARAM in the future.

See <http://adi.thur.de/?show=emi62> for details.

On Sat, 2004-01-10 at 05:07, Greg KH wrote:
> On Thu, Dec 18, 2003 at 10:28:24PM +0100, Rasmus Rohde wrote:
> > I wrote to you earlier about a missing patch to ftdi_sio.c that appeared
> > in
> >
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.5/usb-ftdi_sio-2.5.68.patch
> >
> > It has to do with the introduction tiocmset and tiocmget.
> > This patch was dropped in
> >
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.5/usb-ftdi_sio-2.5.75.patch
> >
> > which unfortunately breaks the driver.
>
> Hm, sorry about that.  Care to send me a patch to fix it up?

This patch adds a new product ID to the list of devices using the FTDI232BM
chip. It applies cleanly against vanilla 2.6.0.

On Wed, 14 Jan 2004, Marcin Juszkiewicz wrote:

> After running "MS Import" on my Sony Clie SJ30 palmtop I got:
>
> hub 3-0:1.0: new USB device on port 2, assigned address 6
> usb-storage: This device (054c,006d,0100 S 05 P 00) has unneeded SubClass and Protocol entries in unusual_devs.h
>    Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>

Thanks for sending this.  The updated information will appear in an
upcoming kernel.

On Fri, 2 Jan 2004, Eric Lussard wrote:

> <5>usb-storage: This device (05e3,0701,0002 S 02 P 50) has an unneeded
> Protocol entry
> in unusual_devs.h
> <4>   Please send a copy of this message to
> <linux-usb-devel@lists.sourceforge.net>

Yet another unusual_devs change!  I really should stick to a policy of
reading through all the new email before sending any replies...

On Fri, 2 Jan 2004, Oliver Neukum wrote:

> Hi Alan,
>
> you seem to like them. Here it is:
>
> usb-storage 3-1:1.0: usb_probe_interface
> usb-storage 3-1:1.0: usb_probe_interface - got id
> usb-storage: This device (0686,4014,0001 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h
>    Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>
> scsi1 : SCSI emulation for USB Mass Storage devices
>   Vendor: MINOLTA   Model: DIMAGE  CAMERA    Rev: 1.00
>   Type:   Direct-Access                      ANSI SCSI revision: 02

Thanks Oliver.  Interestingly, it looks as though the unneeded SubClass
and Protocol values were the only reason for keeping this entry, so now it
can be deleted in both 2.4 and 2.6.

On Tue, 23 Dec 2003, sledgedog wrote:

> USB Mass Storage support registered.
> hub 3-0:1.0: new USB device on port 2, assigned address 2
> usb-storage: This device (090c,1132,0100 S 06 P 50) has unneeded SubClass and Protocol entries in unusual_devs.h
>    Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>

Thank you for sending this in.

Greg, here is the patch for unusual_devs.h, both 2.4 and 2.6.

I was unable to get my Pentax Optio 330GSrecognised
by the 2.6.0 kernel until I applied the patch below that I found
posted some months ago on the German Debian mailing list.

I have attributred it to the original poster.

Thanks to BOUCNIAUX Benjamin <borax@neron.info> for the information.

Also cleaned up the string files.
Thanks to Mark Smith for pointing this out.

>>	if (dev->bulk_in_buffer != NULL)
>>		kfree (dev->bulk_in_buffer);
>
>
> Yes that one check can go away.  Care to send me a patch?

Actually all those checks should go away ...

This patch implements the "USB Gadget" API using the
"Goku-S" (TC86C001) full speed usb device controller.

It's passed testing with Gadget Zero, g_ether (full
CDC Ethernet support), gadgetfs, and most interestingly
Alan Stern's "File Storage Gadget" (FSG, talking to
Linux or Windows as a usb-storage device) to give the
halt processing a good workout.  Control-OUT works.
Tested mostly on x86, with reported success on MIPS.

As well as being directly useful with that hardware,
I think this is small and simple enough to be useful
as an example of how to write a USB controller driver.
(There will be many more controller drivers than gadget
drivers, I suspect ...)

Please merge this to the next 2.6 release that takes
new drivers.  Corresponding updates for kbuild and the
various gadget drivers will be coming (not in a flood).

Thanks to Stefan Verkoyen <stefan.verkoyen@quesd.com> for the information.

Fix for oops on rmmod caused by *_remove() function marked as __devinit
(and thus discarded after module initialization - if CONFIG_MODULES=y
and CONFIG_HOTPLUG is not set).
This patch changes __devinit to __devexit and adds __devexit_p() where
pointer to such function is used.

The only exception is au1000, where au1000_remove() is called from
cleanup_au1000() function - __devinit is jest removed there.

It was also removed in 2.4.23.

Use rq->cmd[0] instead of rq->flags for storing special request flags.

Per Jens' suggestion.  Tested by Stef van der Made <svdmade@planet.nl>.

Revert wrong changes introduced in 2.4.21.

From: Stefan Talpalaru <stefantalpalaru@yahoo.com>,
      Ingo Kilian <ikilian@web.de>.

The MSI port to x86-64 added an interrupt routing bug that makes the
kernel not boot anymore on some machines.

Fix that.

From Pavel Machek

sometimes nanoseconds are used, sometimes microseconds, sometimes even something else.