Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 4月, 2016 1 次提交
  3. 29 3月, 2016 2 次提交
  5. 04 3月, 2016 3 次提交
  7. 17 2月, 2016 1 次提交
    • J
      usb: dwc3: Fix assignment of EP transfer resources · c4509601
      由 John Youn 提交于 
      The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda618 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fixed one aspect of this
where resources may be exhausted with multiple calls to SET_INTERFACE.
However, it introduced an issue where composite devices with multiple
interfaces can be assigned the same transfer resources for different
endpoints. This patch solves both issues.

The assignment of transfer resources cannot perfectly follow the data
book due to the fact that the controller driver does not have all
knowledge of the configuration in advance. It is given this information
piecemeal by the composite gadget framework after every
SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
programming model in this scenario can cause errors. For two reasons:

1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
interfaces.

2) The databook does not mention doing more DEPXFERCFG for new endpoint
on alt setting (8.1.6).

The following simplified method is used instead:

All hardware endpoints can be assigned a transfer resource and this
setting will stay persistent until either a core reset or hibernation.
So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
every hardware endpoint as well. We are guaranteed that there are as
many transfer resources as endpoints.

This patch triggers off of the calling dwc3_gadget_start_config() for
EP0-out, which always happens first, and which should only happen in one
of the above conditions.

Fixes: aebda618 ("usb: dwc3: Reset the transfer resource index on SET_INTERFACE")
Cc: <stable@vger.kernel.org> # v3.2+
Reported-by: NRavi Babu <ravibabu@ti.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      c4509601
  9. 04 2月, 2016 1 次提交
  11. 23 12月, 2015 1 次提交
  13. 17 12月, 2015 1 次提交
  15. 15 12月, 2015 5 次提交
    • F
      usb: dwc3: gadget: handle request->zero · 04c03d10
      由 Felipe Balbi 提交于 
      So far, dwc3 has always missed request->zero
handling for every endpoint. Let's implement
that so we can handle cases where transfer must
be finished with a ZLP.

Note that dwc3 is a little special. Even though
we're dealing with a ZLP, we still need a buffer
of wMaxPacketSize bytes; to hide that detail from
every gadget driver, we have a preallocated buffer
of 1024 bytes (biggest bulk size) to use (and
share) among all endpoints.
Reported-by: NRavi B <ravibabu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      04c03d10
    • F
      usb: dwc3: ep0: fix setup_packet_pending initialization · b5d335e5
      由 Felipe Balbi 提交于 
      It just ocurred to me that dwc3 already gives a
really hint of when a setup packet is pending and
that's the SETUP_PENDING TRB Status for EP0 IRQs.

Fix setup_packet_pending initialization based on
that. While at that, also make sure the comment in
gadget.c matches what code is doing.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      b5d335e5
    • F
      usb: dwc3: gadget: simplify next_request() return check · ac7bdcc1
      由 Felipe Balbi 提交于 
      In dwc3_cleanup_done_reqs() we expect that all
iterations of our while (1) loop will find a valid
struct dwc3_request *. In case we don't, we're
dumping a WARN_ON_ONCE() splat so that people report
the failure.

This patch is a simple cleanup converting:

	if (!req) {
		WARN_ON_ONCE(1);
		return 1;
	}

to:

	if (WARN_ON_ONCE(!req))
		return 1;

which is a little easier to read.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      ac7bdcc1
    • F
      usb: dwc3: gadget: purge dev_dbg() calls · ec5e795c
      由 Felipe Balbi 提交于 
      The last few dev_dbg() messages are converted to
tracepoints and we can finally ignore dev_dbg()
messages during debug sessions.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      ec5e795c
    • F
      usb: dwc3: gadget: simplify dwc3_gadget_ep_queue() · bb423984
      由 Felipe Balbi 提交于 
      By moving our sanity checks our internal function
__dwc3_gadget_ep_queue() we can simplify the
externally visible API while also making sure that
callers of __dwc3_gadget_ep_queue() also make use of
the same checks.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      bb423984
  17. 01 12月, 2015 1 次提交
    • F
      usb: dwc3: gadget: don't prestart interrupt endpoints · 62e345ae
      由 Felipe Balbi 提交于 
      Because interrupt endpoints usually transmit such
small amounts of data, it seems pointless to prestart
transfers and try to get speed improvements. This
patch also sorts out a problem with CDC ECM function
where its notification endpoint gets stuck in busy
state and we continuously issue Update Transfer
commands.

Fixes: 8a1a9c9e ("usb: dwc3: gadget: start transfer on XFER_COMPLETE")
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      62e345ae
  19. 18 11月, 2015 1 次提交
    • B
      usb: dwc3: gadget: let us set lower max_speed · b9e51b2b
      由 Ben McCauley 提交于 
      In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.

Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.

At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.

[ balbi@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]

Cc: <stable@vger.kernel.org>
Signed-off-by: NBen McCauley <ben.mccauley@garmin.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      b9e51b2b
  21. 13 10月, 2015 2 次提交
  23. 29 9月, 2015 4 次提交
  25. 27 9月, 2015 4 次提交
  27. 22 9月, 2015 1 次提交
  29. 05 8月, 2015 1 次提交
  31. 31 7月, 2015 1 次提交
  33. 29 7月, 2015 2 次提交
  35. 29 5月, 2015 1 次提交
  37. 26 5月, 2015 2 次提交
  39. 09 3月, 2015 1 次提交
  41. 30 1月, 2015 2 次提交
  43. 28 1月, 2015 2 次提交