Commit graph

9 commits

Author SHA1 Message Date
Greg KH
6fbfddcb52 Merge ../bleed-2.6 2005-10-28 10:13:16 -07:00
Russell King
9480e307cd [PATCH] DRIVER MODEL: Get rid of the obsolete tri-level suspend/resume callbacks
In PM v1, all devices were called at SUSPEND_DISABLE level.  Then
all devices were called at SUSPEND_SAVE_STATE level, and finally
SUSPEND_POWER_DOWN level.  However, with PM v2, to maintain
compatibility for platform devices, I arranged for the PM v2
suspend/resume callbacks to call the old PM v1 suspend/resume
callbacks three times with each level in order so that existing
drivers continued to work.

Since this is obsolete infrastructure which is no longer necessary,
we can remove it.  Here's an (untested) patch to do exactly that.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28 09:52:56 -07:00
Al Viro
55016f10e3 [PATCH] gfp_t: drivers/usb
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-28 08:16:49 -07:00
david-b@pacbell.net
1d7beee3d4 [PATCH] USB: omap_udc tweaks
Minor OMAP updates that somehow got dropped from previous patches.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-12 11:52:56 -07:00
Olav Kongas
5db539e49f [PATCH] USB: Fix kmalloc's flags type in USB
Greg,

This patch fixes the kmalloc() flags argument type in USB
subsystem; hopefully all of its occurences. The patch was
made against patch-2.6.12-git2 from Jun 20.

Cleanup of flags for kmalloc() in USB subsystem.

Signed-off-by: Olav Kongas <ok@artecdesign.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-12 11:52:56 -07:00
David Brownell
65111084c6 [PATCH] USB: more omap_udc updates (dma and omap1710)
More omap_udc updates:

  * OMAP 1710 updates
      - new UDC bit for clearing endpoint toggle, affecting CLEAR_HALT
      - new OTG bits affecting wakeup
  * Fix the bug Vladimir noted, that IN-DMA transfer code path kicks in
    for under 1024 bytes (not "up to 1024 bytes")
  * Handle transceiver setup more intelligently
      - use transceiver whenever one's available; this can be handy
        for GPIO based, loopback, or transceiverless configs
      - cleanup correctly after the "unrecognized HMC" case
  * DMA performance tweaks
      - allow burst/pack for memory access
      - use 16 bit DMA access most of the time on TIPB
  * Add workarounds for some DMA errata (not observed "in the wild"):
      - DMA CSAC/CDAC reads returning zero
      - RX/TX DMA config registers bit 12 always reads as zero (TI patch)
  * More "sparse" warnings removed, notably "changing" the SETUP packet
    to return data in USB byteorder (an API change, null effect on OMAP
    except for these warnings).

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-06-27 14:43:50 -07:00
David Brownell
313980c927 [PATCH] USB: omap_udc updates (mostly cleanups)
Various USB patches, mostly for portability:

  - Fifo mode 1 didn't work previously (oopsed), so now it's fixed and
    (why not) defines even more endpoints for composite devices.

  - OMAP 1710 doesn't have an internal transceiver.

  - Small PM update:  if the USB link is suspended, don't disconnect on
    entry to deep sleep.

  - Be more correct about handling zero length control reads.  OMAP
    seems to mis-handle that protocol peculiarity though; best avoided.

  - Platform device resources (for UDC and OTG controllers) now use
    physical addresses, so /proc/iomem is more consistent.

  - Minor cleanups, notably (by volume) for "sparse" NULL warnings.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
2005-06-27 14:43:41 -07:00
Pavel Machek
ba9d35fb01 [PATCH] USB: fix up remaining pm_message_t usages
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-18 17:39:24 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00