Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 21 9月, 2011 1 次提交
  3. 18 9月, 2011 18 次提交
  5. 10 9月, 2011 16 次提交
    • K
      usb gadget: clean up FSF boilerplate text · 28c9fc68
      由 Klaus Schwarzkopf 提交于 
      remove the following two paragraphs as they are not needed:

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
License for more details.

You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc.,59
Temple Place - Suite 330, Boston, MA  02111-1307, USA.
Signed-off-by: NKlaus Schwarzkopf <schwarzkopf@sensortherm.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      28c9fc68
    • H
      musb_gadget: Fix for spurious interrupts on endpoint zero. · de76cc2b
      由 Hans Petter Selasky 提交于 
      There is a multi-year old bug in the MUSB hardware which is not documented.
It causes spurious interrupts and have various symptoms, like endless
"SetupEnd came in a wrong ep0stage" messages. The fix is taken from the
FreeBSD's musb driver.

How to reproduce:
For example issue clear-stall on a couple of endpoints very fast,
like one request per 125us. After a while the bug triggers and the
musb-chip becomes unusable until next re-enumeration.
Signed-off-by: NHans Petter Selasky <hps@bitfrost.no>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      de76cc2b
    • J
      USB: for usb_autopm_get_interface_async -EINPROGRESS is not an error · c5a48592
      由 Jim Wylder 提交于 
      A return value of -EINPROGRESS from pm_runtime_get indicates that
the device is already resuming due to a previous call.  Internally,
usb_autopm_get_interface_async doesn't treat this as an error and
increments the usage count, but passes the error status along
to the caller.  The logical assumption of the caller is that
any negative return value reflects the device not resuming
and the pm_usage_cnt not being incremented.  Since the usage count
is being incremented and the device is resuming, return success (0)
instead.
Signed-off-by: NJames Wylder <james.wylder@motorola.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c5a48592
    • L
      USB: storage: Use normalized sense when emulating autosense · e16da02f
      由 Luben Tuikov 提交于 
      This patch solves two things:
1) Enables autosense emulation code to correctly
interpret descriptor format sense data, and
2) Fixes a bug whereby the autosense emulation
code would overwrite descriptor format sense data
with SENSE KEY HARDWARE ERROR in fixed format, to
incorrectly look like this:

Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc]  Sense Key : Recovered Error [current] [descriptor]
Oct 21 14:11:07 localhost kernel: Descriptor sense data with sense descriptors (in hex):
Oct 21 14:11:07 localhost kernel:        72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
Oct 21 14:11:07 localhost kernel:        00 4f 00 c2 00 50
Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc]  ASC=0x4 ASCQ=0x1d
Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NMatthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e16da02f
    • S
      xhci: Redundant check in xhci_check_args for xhci->devs · 73ddc247
      由 sifram.rajas@gmail.com 提交于 
      The xhci_hcd->devs is an array of pointers rather than pointer to pointer.
Hence this check is not required.

Signed-off-by: Sifram Rajas <Sifram Rajas sifram.rajas@gmail.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      73ddc247
    • A
      xHCI: refine td allocation · 2ffdea25
      由 Andiry Xu 提交于 
      In xhci_urb_enqueue(), allocate a block of memory for all the TDs instead
of allocating memory for each of them separately. This reduces the number
of kzalloc calling when an isochronous usb is submitted.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2ffdea25
    • S
      xhci: Don't print short isoc packets. · fd984d24
      由 Sarah Sharp 提交于 
      Now that the xHCI driver always return a status value of zero for isochronous
URBs, when the last TD of an isochronous URB is short, the local variable
"status" stays set to -EINPROGRESS.  When xHCI driver debugging is turned on,
this causes the log file to fill with messages like this:

[   38.859282] xhci_hcd 0000:00:14.0: Giveback URB ffff88013ad47800, len = 1408, expected = 580, status = -115

Don't print out the status of an URB for isochronous URBs.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fd984d24
    • S
      xhci: Add software BW checking quirk to Intel PPT xHCI · 86cc558e
      由 Sarah Sharp 提交于 
      The xHCI host controller in the Intel Panther Point chipset needs to have
software check whether new devices will fit in the available bus
bandwidth.  Activate the software bandwidth checking quirk when we find
the right PCI device.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      86cc558e
    • S
      xhci: Implement HS/FS/LS bandwidth checking. · c29eea62
      由 Sarah Sharp 提交于 
      Now that we have a bandwidth interval table per root port or TT that
describes the endpoint bandwidth information, we can finally use it to
check whether the bus bandwidth is oversubscribed for a new device
configuration/alternate interface setting.

The complication for this algorithm is that the bit of hardware logic that
creates the bus schedule is only 12-bit logic.  In order to make sure it
can represent the maximum bus bandwidth in 12 bits, it has to convert the
endpoint max packet size and max esit payload into "blocks" (basically a
less-precise representation).  The block size for each speed of device is
different, aside from low speed and full speed.  In order to make sure we
don't allow a setup where the scheduler might fail, we also have to do the
bandwidth checking in blocks.

After checking that the endpoints fit in the schedule, we store the
bandwidth used for this root port or TT.  If this is a FS/LS device under
an external HS hub, we also update the TT bandwidth and the root port
bandwidth (if this is a newly activated or deactivated TT).

I won't go into the details of the algorithm, as it's pretty well
documented in the comments.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c29eea62
    • S
      xhci: Track interval bandwidth tables per port/TT. · 2e27980e
      由 Sarah Sharp 提交于 
      In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval.  That way we can
easily know the new largest max packet size when we have to remove an
endpoint.

Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size.  Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size.  Only insert endpoints and update the interval table with new
information when those endpoints are periodic.

Make sure to update the number of active TTs when we add or drop periodic
endpoints.  A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus).  If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport.  If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.

We have to be careful when we're checking the bandwidth for a new
configuration/alt setting.  If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table.  We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list.  Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.

We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits.  Besides which, we can't fail a device disconnect.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2e27980e
    • S
      xhci: Store endpoint bandwidth information. · 9af5d71d
      由 Sarah Sharp 提交于 
      In the upcoming patches, we'll use some stored endpoint information to
make software keep track of the worst-case bandwidth schedule.  We need to
store several variables associated with each periodic endpoint:
 - the type of endpoint
 - Max Packet Size
 - Mult
 - Max ESIT payload
 - Max Burst Size (aka number of packets, stored in one-based form)
 - the endpoint interval (normalized to powers of 2 microframes)

All this information is available to the hardware, and stored in its
device output context.  However, we need to ensure that the new
information is stored before the xHCI driver drops the xhci->lock to wait
on the Configure Endpoint command, so that another driver requesting a
configuration or alt setting change will see the update.  The Configure
Endpoint command will never fail on the hardware that needs this software
bandwidth checking (assuming the slot is enabled and the flags are set
properly), so updating the endpoint info before the command completes
should be fine.

Until we add in the bandwidth checking code, just update the endpoint
information after the Configure Endpoint command completes, and after a
Reset Device command completes.  Don't bother to clear the endpoint
bandwidth info when a device is being freed, since the xhci_virt_ep is
just going to be freed anyway.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9af5d71d
    • S
      xhci: Store information about roothubs and TTs. · 839c817c
      由 Sarah Sharp 提交于 
      For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host.  Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.

If the table were in text form, it would look a bit like this:

EP Interval	Sum of Number	Largest Max	Max Packet
		of Packets	Packet Size	Overhead
	0	   N		   mps		  overhead
...
	15	   N		   mps		  overhead

Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval.  Devices with
different speeds have different max packet overhead.  For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead).  Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size.  That's stored in
the interval0_esit_payload variable.  For root ports, we also need to keep
track of the number of active TTs.

For each root port, and each TT under a root port, store some information
about the bandwidth consumption.  Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port.  A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.

When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub.  When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub.  Keep track of which TT entry is associated with a
device under a TT.

LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub.  Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      839c817c
    • S
      xhci: Store the "real" root port number. · 66381755
      由 Sarah Sharp 提交于 
      Since the xHCI driver now has split USB2/USB3 roothubs, devices under each
roothub can have duplicate "fake" port numbers.  For the next set of
patches, we need to keep track of the "real" port number that the xHCI
host uses to index into the port status arrays.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      66381755
    • S
      xhci: Refactor endpoint limit checking. · 750645f8
      由 Sarah Sharp 提交于 
      Move the code to check whether we've reached the host controller's limit
on the number of endpoints out of the two conditional statements, to
remove duplicate code.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      750645f8
    • S
      xhci: Rename virt_dev->port to fake_port. · fe30182c
      由 Sarah Sharp 提交于 
      The "port" field in xhci_virt_dev stores the port number associated with
one of the two xHCI split roothubs, not the unique port number the xHCI
hardware uses.  Since we'll need to store the real hardware port number in
future patches, rename this field to "fake_port".
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fe30182c
    • S
      xhci: If no endpoints changed, don't issue BW command. · 2dc37539
      由 Sarah Sharp 提交于 
      Some alternate interface settings have no endpoints associated with them.
This shows up in some USB webcams, particularly the Logitech HD 1080p,
which uses the uvcvideo driver.  If a driver switches between two alt
settings with no endpoints, there is no need to issue a configure endpoint
command, because there is no endpoint information to update.

The only time a configure endpoint command with just the add slot flag set
makes sense is when the driver is updating hub characteristics in the slot
context.  However, that code never calls xhci_check_bandwidth, so we
should be safe not issuing a command if only the slot context add flag is
set.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2dc37539
  7. 09 9月, 2011 5 次提交
    • A
      usb: musb: Enable DMA mode1 RX for transfers without short packets · 0ae52d54
      由 Anand Gadiyar 提交于 
      This patch enables DMA mode1 for the RX path when we know
there won't be any short packets. We check that by looking
into the short_no_ok flag, if it's true we enable mode1, otherwise
we use mode0 to transfer the data.

This will result in a throughput performance gain of around
40% for USB mass-storage/mtp use cases.

[ balbi@ti.com : updated commit log and code comments slightly ]
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Tested-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      0ae52d54
    • F
      usb: musb: fix build breakage · b3c3dc22
      由 Felipe Balbi 提交于 
      This patch fixes the compilation brekage which
commits 208466dc ("usb: otg:OMAP4430: Powerdown
the internal PHY when USB is disabled") and
fb91cde4 ("usb: musb: OMAP4430: Power down
the PHY during board init") introduced when
building a OMAP2-only kernel.

  LD      .tmp_vmlinux1
arch/arm/mach-omap2/built-in.o:(.data+0x7ce0): undefined reference to
+`omap4430_phy_init'
arch/arm/mach-omap2/built-in.o:(.data+0x7ce4): undefined reference to
+`omap4430_phy_exit'
arch/arm/mach-omap2/built-in.o:(.data+0x7ce8): undefined reference to
+`omap4430_phy_power'
arch/arm/mach-omap2/built-in.o:(.data+0x7cec): undefined reference to
+`omap4430_phy_set_clk'
arch/arm/mach-omap2/built-in.o:(.data+0x7cf0): undefined reference to
+`omap4430_phy_suspend'
make: *** [.tmp_vmlinux1] Error 1
Reported-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      b3c3dc22
    • F
      usb: gadget: audio: queue wLength-sized requests · 7c5881d1
      由 Felipe Balbi 提交于 
      On Audio class, the wLength field of the Setup
packet, contains the data payload size of the
following Data phase. Instead of harcoding values,
use wLength.

This also fixes a bug where Gadget driver had to
receive 3 bytes, but it was queueing a ZLP.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7c5881d1
    • F
      usb: gadget: audio: actually support both speeds · ef7f584c
      由 Felipe Balbi 提交于 
      While testing g_audio with HighSpeed UDC on a
FS Hub, we had no configurations to present to
the host. That's because both speeds where
mutually exclusive.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      ef7f584c
    • P
      usb: gadget: storage: make FSG_NUM_BUFFERS variable size · 6532c7fd
      由 Per Forlin 提交于 
      FSG_NUM_BUFFERS is set to 2 as default.
Usually 2 buffers are enough to establish a good buffering pipeline.
The number may be increased in order to compensate a for bursty VFS
behaviour.

Here follows a description of system that may require more than
2 buffers.
 * CPU ondemand governor active
 * latency cost for wake up and/or frequency change
 * DMA for IO

Use case description.
 * Data transfer from MMC via VFS to USB.
 * DMA shuffles data from MMC and to USB.
 * The CPU wakes up every now and then to pass data in and out from VFS,
   which cause the bursty VFS behaviour.

Test set up
 * Running dd on the host reading from the mass storage device
 * cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100))
 * Caches are dropped on the host and on the device before each run

Measurements on a Snowball board with ondemand_governor active.

FSG_NUM_BUFFERS 2
104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s

FSG_NUM_BUFFERS 4
104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s

There may not be one optimal number for all boards. This is why
the number is added to Kconfig. If selecting USB_GADGET_DEBUG_FILES
this value may be set by a module parameter as well.
Signed-off-by: NPer Forlin <per.forlin@linaro.org>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      6532c7fd