Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 25 1月, 2013 5 次提交
  3. 24 1月, 2013 1 次提交
    • F
      usb: dwc3: gadget: change HIRD threshold to 12 · 1a947746
      由 Felipe Balbi 提交于 
      First of all, that 28 value makes no sense as
HIRD threshold is a 4-bit value, second of all
it's causing issues for OMAP5.

Using 12 because commit cbc725b3 (usb: dwc3:
keep default hird threshold value as 4b1100)
had the intention of setting the maximum allowed
value of 0xc.

Also, original code has been wrong forever, so
this should be backported as far back as
possible.

Cc: <stable@vger.kernel.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1a947746
  5. 18 1月, 2013 13 次提交
    • V
      usb: dwc3: remove dwc3 dependency on host AND gadget. · 388e5c51
      由 Vivek Gautam 提交于 
      DWC3 controller curretly depends on USB && USB_GADGET.
Some hardware may like to use only host feature on dwc3,
or only gadget feature.

So, removing this dependency of USB_DWC3 on USB and USB_GADGET.
Adding the mode of operaiton of DWC3 also here
HOST/GADGET/DUAL_ROLE based on which features are enabled.

[ balbi@ti.com :
	. make sure we have default modes for all possible Kernel
		configurations.
	. Remove the config -> menuconfig change as it's unnecessary
	. switch over to IS_ENABLED() ]

CC: Doug Anderson <dianders@chromium.org>
Signed-off-by: NVivek Gautam <gautam.vivek@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      388e5c51
    • P
      usb: dwc3: gadget: req->queued must be forced to false in cleanup · c9fda7d6
      由 Pratyush Anand 提交于 
      I am not sure, why I found it during SG debugging. But, I noticed that
even when req_queued list was empty, there were some request in
request_list having queued flag true. If I run test second time, it
first removes all request from request_list and hence busy_slot was
wrongly incremented.

Cc: <stable@vger.kernel.org>
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c9fda7d6
    • P
      usb: dwc3: gadget: fix scatter gather implementation · e5ba5ec8
      由 Pratyush Anand 提交于 
      To work with scatter gather properly, fixes have been done in number of
functions. I will explain requirement of each fixes one by one.

start_slot: used to retrieve all request of SG during cleanup

dwc3_gadget_giveback: We need to skip link TRB if it was one of the
intermediate TRB of SG.

dwc3_prepare_one_trb: We need to track all submitted TRBs during
cleanup. Since, all TRBs would be serially allocated, so we can just
keep starting slot info and we can always find rest of them. We need to
pass sg node number, so that we cab appropriately program ISOC_FIRST/ISOC,
Chain etc.

dwc3_prepare_trbs: last_one should be set when it is last node
of SG as well as last node of request_list.

__dwc3_cleanup_done_trbs: It has been prepared after re-factorization of
dwc3_cleanup_done_reqs. It is called for each TRB of SG.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      e5ba5ec8
    • P
      usb: dwc3: gadget: no need to pass params in case of UPDATE_TRANSFER · 1877d6c9
      由 Pratyush Anand 提交于 
      UPDATE_TRANSFER does not need any parameters. So, no need to prepare it.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      1877d6c9
    • P
      usb: dwc3: gadget: fix skip LINK_TRB on ISOC · 915e202a
      由 Pratyush Anand 提交于 
      When we reach to link trb, we just need to increase free_slot and then
calculate TRB. Return is not correct, as it will cause wrong TRB DMA
address to fetch in case of update transfer.

Cc: <stable@vger.kernel.org>
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      915e202a
    • P
      usb: dwc3: gadget: fix isoc END TRANSFER Condition · cdc359dd
      由 Pratyush Anand 提交于 
      There were still some corner cases where isoc transfer was not able to
restart, specially when missed isoc does not happen , and in fact gadget does
not queue any new request during giveback.

Cleanup function calls giveback first, which provides a way to queue
another request to gadget. But gadget did not had any data. So , it did
not call ep_queue. To twist it further, gadget did not queue till
cleanup for last queued TRB is called. If we ever reach this scenario,
we must call END TRANSFER, so that we receive a new  xfernotready with
information about current microframe number.

Also insure that there is no request submitted to core when issuing END
TRANSFER.

Cc: <stable@vger.kernel.org> # v3.8
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      cdc359dd
    • P
      usb: dwc3: gadget: correct return from ep_queue · 15f86bde
      由 Pratyush Anand 提交于 
      Its better to return from each if condition as they are mutually
exclusive.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      15f86bde
    • P
      usb: dwc3: gadget: fix missed isoc · 7efea86c
      由 Pratyush Anand 提交于 
      There are two reasons to generate missed isoc.

1. when the host does not poll for all the data.
2. because of application-side delays that prevent all the data from
being transferred in programmed microframe.

Current code was able to handle first case only.  This patch handles
scenario 2 as well.Scenario 2 sometime may occur with complex gadget
application, however it can be easily reproduced for testing purpose as
follows:

a. use isoc binterval as 1 in f_sourcesink.
b. use pattern=0
c. introduce a delay of 150us deliberately in source_sink_complete, so
that after few frames it lands into scenario 2.
d. now run testusb 16 (isoc in  test). You will notice that if this
patch is not applied then isoc transfer is not able to recover after
first missed.

Current patch's approach is as under:

If missed isoc occurs and there is no request queued then issue END
TRANSFER, so that core generates next xfernotready and we will issue a
fresh START TRANSFER.
If there are still queued request then wait, do not issue either END or
UPDATE TRANSFER, just attach next request in request_list during giveback.
If any future queued request is successfully transferred then we will issue
UPDATE TRANSFER for all request in the request_list.

Cc: <stable@vger.kernel.org> # v3.6 v3.7 v3.8
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7efea86c
    • P
      usb: dwc3: Enable usb2 LPM only when connected as usb2.0 · 2b758350
      由 Pratyush Anand 提交于 
      Synopsys says:
The HIRD Threshold field must be set to ‘0’ when the device core is
operating in super speed mode.

This patch implements above statement.

Cc: <stable@vger.kernel.org> # v3.6 v3.7 v3.8
Acked-by: NPaul Zimmerman <paulz@synopsys.com>
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2b758350
    • F
      usb: dwc3: debugfs: convert our regdump to use regsets · d7668024
      由 Felipe Balbi 提交于 
      regset is a generic implementation of regdump
utility through debugfs.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      d7668024
    • F
      usb: dwc3: gadget: don't redefine 'ret' · 7dbdf4e4
      由 Felipe Balbi 提交于 
      we have an extra 'ret' variable shadowing a previous
definition. Remove it.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7dbdf4e4
    • J
      usb: dwc3: exynos: use devm_ functions · 20b97dc1
      由 Jingoo Han 提交于 
      The devm_ functions allocate memory that is released when a driver
detaches. This makes the code smaller and a bit simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      20b97dc1
    • F
      usb: dwc3: decrease event buffer size · 5da93478
      由 Felipe Balbi 提交于 
      Currently we're allocating an entire page to
serve as our event buffer. Provided our events
are 4 bytes long, it's very unlikely we will
even trigger 1k events at once.

Even in the worst case scenario where every
endpoint triggers one event and we still have
a couple of error events, that would still
be less than 40 events.

In order to cope with future versions of the
IP which could (or could not) increase the
amount of possible events to trigger
simultaneously, we're using an arbitrary size
of 64 events for our event buffer.

We're saving 3840 bytes by doing so.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
      5da93478
  7. 14 1月, 2013 1 次提交
  9. 12 1月, 2013 13 次提交
  11. 08 1月, 2013 2 次提交
  13. 04 1月, 2013 5 次提交
    • G
      Drivers: usb: host: ehci-orion.c: remove __devinitdata marking · 59a609a9
      由 Greg Kroah-Hartman 提交于 
      This snuck in from a different tree during the merge and needs to be
removed.

Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      59a609a9
    • S
      xhci: Avoid "dead ports", add roothub port polling. · c52804a4
      由 Sarah Sharp 提交于 
      The USB core hub thread (khubd) is designed with external USB hubs in
mind.  It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.

The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits.  When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event.  If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.

This means that the hub code may lose port status changes because of
race conditions between clearing change bits.  The user sees this as a
"dead port" that doesn't react to device connects.

The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.

We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's.  Instead, stop the port polling timer, and
unconditionally restart it when the host resumes.  If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.

This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a7930 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
      c52804a4
    • S
      USB: Handle warm reset failure on empty port. · 65bdac5e
      由 Sarah Sharp 提交于 
      An empty port can transition to either Inactive or Compliance Mode if a
newly connected USB 3.0 device fails to link train.  In that case, we
issue a warm reset.  Some devices, such as John's Roseweil eusb3
enclosure, slip back into Compliance Mode after the warm reset.

The current warm reset code does not check for device connect status on
warm reset completion, and it incorrectly reports the warm reset
succeeded.  This causes the USB core to attempt to send a Set Address
control transfer to a port in Compliance Mode, which will always fail.

Make hub_port_wait_reset check the current connect status and link state
after the warm reset completes.  Return a failure status if the device
is disconnected or the link state is Compliance Mode or SS.Inactive.

Make hub_events disable the port if warm reset fails.  This will disable
the port, and then bring it back into the RxDetect state.  Make the USB
core ignore the connect change until the device reconnects.

Note that this patch does NOT handle connected devices slipping into the
Inactive state very well.  This is a concern, because devices can go
into the Inactive state on U1/U2 exit failure.  However, the fix for
that case is too large for stable, so it will be submitted in a separate
patch.

This patch should be backported to kernels as old as 3.2, contain the
commit ID 75d7cf72 "usbcore: refine warm
reset logic"
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NJohn Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
      65bdac5e
    • S
      USB: Ignore port state until reset completes. · 4f43447e
      由 Sarah Sharp 提交于 
      The port reset code bails out early if the current connect status is
cleared (device disconnected).  If we're issuing a hot reset, it may
also look at the link state before the reset is finished.

Section 10.14.2.6 of the USB 3.0 spec says that when a port enters the
Error state or Resetting state, the port connection bit retains the
value from the previous state.  Therefore we can't trust it until the
reset finishes.  Also, the xHCI spec section 4.19.1.2.5 says software
shall ignore the link state while the port is resetting, as it can be in
an unknown state.

The port state during reset is also unknown for USB 2.0 hubs.  The hub
sends a reset signal by driving the bus into an SE0 state.  This
overwhelms the "connect" signal from the device, so the port can't tell
whether anything is connected or not.

Fix the port reset code to ignore the port link state and current
connect bit until the reset finishes, and USB_PORT_STAT_RESET is
cleared.

Remove the check for USB_PORT_STAT_C_BH_RESET in the warm reset case,
because it's redundant.  When the warm reset finishes, the port reset
bit will be cleared at the same time USB_PORT_STAT_C_BH_RESET is set.
Remove the now-redundant check for a cleared USB_PORT_STAT_RESET bit
in the code to deal with the finished reset.

This patch should be backported to all stable kernels.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
      4f43447e
    • S
      USB: Increase reset timeout. · 77c7f072
      由 Sarah Sharp 提交于 
      John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete.  The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72 "usbcore: refine
warm reset logic".
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NJohn Covici <covici@ccs.covici.com>
Cc: stable@vger.kernel.org
      77c7f072