Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 31 8月, 2016 3 次提交
  3. 29 8月, 2016 1 次提交
  5. 25 8月, 2016 1 次提交
  7. 29 6月, 2016 2 次提交
  9. 21 6月, 2016 13 次提交
  11. 31 5月, 2016 3 次提交
    • A
      usb: dwc2: fix regression on big-endian PowerPC/ARM systems · 23e34392
      由 Arnd Bergmann 提交于 
      A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
MIPS system unfortunately broke big-endian operation on PowerPC
APM82181 as reported by Christian Lamparter, and likely other
systems.

It actually introduced multiple issues:

- it broke big-endian ARM kernels: any machine that was working
  correctly with a little-endian kernel is no longer using byteswaps
  on big-endian kernels, which clearly breaks them.
- On PowerPC the same thing must be true: if it was working before,
  using big-endian kernels is now broken. Unlike ARM, 32-bit PowerPC
  usually uses big-endian kernels, so they are likely all broken.
- The barrier for dwc2_writel is on the wrong side of the __raw_writel(),
  so the MMIO no longer synchronizes with DMA operations.
- On architectures that require specific CPU instructions for MMIO
  access, using the __raw_ variant may turn this into a pointer
  dereference that does not have the same effect as the readl/writel.

This patch is a simple revert for all architectures other than MIPS,
in the hope that we can more easily backport it to fix the regression
on PowerPC and ARM systems without breaking the Lantiq system again.

We should follow this up with a more elaborate change to add runtime
detection of endianness, to make sure it also works on all other
combinations of architectures and implementations of the usb-dwc2
device. That patch however will be fairly large and not appropriate
for backports to stable kernels.

Felipe suggested a different approach, using an endianness switching
register to always put the device into LE mode, but unfortunately
the dwc2 hardware does not provide a generic way to do that. Also,
I see no practical way of addressing the problem more generally by
patching architecture specific code on MIPS.

Fixes: 95c8bc36 ("usb: dwc2: Use platform endianness when accessing registers")
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      23e34392
    • V
      usb: dwc2: gadget: Do not halt isochronous endpoints · 15186f10
      由 Vahram Aharonyan 提交于 
      Add a check in dwc2_hsotg_ep_sethalt() so that it does not halt
isochronous endpoints.
Signed-off-by: NVahram Aharonyan <vahrama@synopsys.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      15186f10
    • V
      usb: dwc2: gadget: Do not halt endpoint if active · 51da43b5
      由 Vahram Aharonyan 提交于 
      The gadget API function usb_ep_set_halt() expects the gadget to return
-EAGAIN if the ep is active. Add support for this behavior.

Otherwise this may break mass storage protocol if a STALL is attempted
on the endpoint.
Signed-off-by: NVahram Aharonyan <vahrama@synopsys.com>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      51da43b5
  13. 28 4月, 2016 5 次提交
  15. 04 4月, 2016 1 次提交
  17. 04 3月, 2016 11 次提交
    • J
      usb: dwc2: Fix issues in dwc2_complete_non_isoc_xfer_ddma() · 1fc65989
      由 John Youn 提交于 
      Fixes a static analysis issue in dwc2_complete_non_isoc_xfer_ddma(). The
qtd was being passed to a function after being freed. It was not being
used in the function so this doesn't fix any bugs. But it fixes up the
warning and makes the code safer by setting qtd to NULL and not using it
at all.
Reported-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      1fc65989
    • A
      usb: dwc2: Add support for Lantiq ARX and XRX SoCs · 6c0c0951
      由 Antti Seppälä 提交于 
      Add support for Lantiq ARX and XRX SoC families to the dwc2 driver.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NAntti Seppälä <a.seppala@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      6c0c0951
    • J
      usb: dwc2: Move host-specific core functions into hcd.c · b02038fa
      由 John Youn 提交于 
      Move host core initialization and host channel routines into hcd.c. This
allows these functions to only be compiled in host-enabled driver
configurations (DRD or host-only).
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      b02038fa
    • J
      usb: dwc2: Move register save and restore functions · 58e52ff6
      由 John Youn 提交于 
      Move the register save and restore functions into the host and gadget
specific files.
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      58e52ff6
    • A
      usb: dwc2: Use kmem_cache_free() · 9bbe91a1
      由 Amitoj Kaur Chawla 提交于 
      Here, free memory is allocated using kmem_cache_zalloc.  So, use
kmem_cache_free instead of kfree.

This is done using Coccinelle and semantic patch used
is as follows:

//<smpl>
@@
expression x,E,c;
@@
 x =
\(kmem_cache_alloc\|kmem_cache_zalloc\|kmem_cache_alloc_node\)(c,...)
 ... when != x = E
     when != &x
?-kfree(x)
+kmem_cache_free(c,x)
//</smpl>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NAmitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      9bbe91a1
    • D
      usb: dwc2: host: If using uframe scheduler, end splits better · 1479cb69
      由 Douglas Anderson 提交于 
      The microframe scheduler figured out exactly how many transfers we need
for a split transaction.  Let's use this knowledge to know when to end
things.

Without this I found that certain devices would just keep responding
with tons of NYET resonses on their INT_IN endpoint.  These would just
keep going and going and eventually we'd decide to terminate the
transfer (because the whole frame changed), but by that time the
scheduler would decide that we "missed" the start of the next transfer.
I can also imagine that if we blow past the end of our scheduled time we
may mess up other things that were scheduled to happen.

No known test cases are improved by this patch except that the scheduler
code doesn't yell about MISSES constantly anymore.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      1479cb69
    • D
      usb: dwc2: host: Totally redo the microframe scheduler · 9f9f09b0
      由 Douglas Anderson 提交于 
      This totally reimplements the microframe scheduler in dwc2 to attempt to
handle periodic splits properly.  The old code didn't even try, so this
was a significant effort since periodic splits are one of the most
complicated things in USB.

I've attempted to keep the old "don't use the microframe" schduler
around for now, but not sure it's needed.  It has also only been lightly
tested.

I think it's pretty certain that this scheduler isn't perfect and might
have some bugs, but it seems much better than what was there before.
With this change my stressful USB test (USB webcam + USB audio + some
keyboards) crackles less.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      9f9f09b0
    • D
      usb: dwc2: host: Properly set even/odd frame · 9cf1a601
      由 Douglas Anderson 提交于 
      When setting up ISO and INT transfers dwc2 needs to specify whether the
transfer is for an even or an odd frame (or microframe if the controller
is running in high speed mode).

The controller appears to use this as a simple way to figure out if a
transfer should happen right away (in the current microframe) or should
happen at the start of the next microframe.  Said another way:

- If you set "odd" and the current frame number is odd it appears that
  the controller will try to transfer right away.  Same thing if you set
  "even" and the current frame number is even.
- If the oddness you set and the oddness of the frame number are
  _different_, the transfer will be delayed until the frame number
  changes.

As I understand it, the above technique allows you to plan ahead of time
where possible by always working on the next frame.  ...but it still
allows you to properly respond immediately to things that happened in
the previous frame.

The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
It always looked at the frame number and setup the transfer to happen in
the next frame.  In some cases that meant that certain transactions
would be transferred in the wrong frame.

We'll try our best to set the even / odd to do the transfer in the
scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
We'll also modify the scheduler code to handle this and not try to
schedule a second transfer for the same frame.

Note that this change relies on the work to redo the microframe
scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
in scheduler") but it works even better after ("usb: dwc2: host: Totally
redo the microframe scheduler").

With this change my stressful USB test (USB webcam + USB audio +
keyboards) has less audio crackling than before.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      9cf1a601
    • D
      usb: dwc2: host: Add dwc2_hcd_get_future_frame_number() call · fae4e826
      由 Douglas Anderson 提交于 
      As we start getting more exact about our scheduling it's becoming more
and more important to know exactly how far through the current frame we
are.  This lets us make decisions about whether there's still time left
to start a new transaction in the current frame.

We'll add dwc2_hcd_get_future_frame_number() which will tell you what
the frame number will be a certain number of microseconds (us) from
now.  We can use this information to help decide if there's enough time
left in the frame for a transaction that will take a certain duration.

This is expected to be used by a future change ("usb: dwc2: host:
Properly set even/odd frame").
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      fae4e826
    • D
      usb: dwc2: host: Manage frame nums better in scheduler · fb616e3f
      由 Douglas Anderson 提交于 
      The dwc2 scheduler (contained in hcd_queue.c) was a bit confusing in the
way it initted / kept track of which frames a QH was going to be active
in.  Let's clean things up a little bit in preparation for a rewrite of
the microframe scheduler.

Specifically:
* Old code would pick a frame number in dwc2_qh_init() and would try to
  pick it "in a slightly future (micro)frame".  As far as I can tell the
  reason for this was that there was a delay between dwc2_qh_init() and
  when we actually wanted to dwc2_hcd_qh_add().  ...but apparently this
  attempt to be slightly in the future wasn't enough because
  dwc2_hcd_qh_add() then had code to reset things if the frame _wasn't_
  in the future.  There's no reason not to just pick the frame later.
  For non-periodic QH we now pick the frame in dwc2_hcd_qh_add().  For
  periodic QH we pick the frame at dwc2_schedule_periodic() time.
* The old "dwc2_qh_init() actually assigned to "hsotg->frame_number".
  This doesn't seem like a great idea since that variable is supposed to
  be used to keep track of which SOF the interrupt handler has seen.
  Let's be clean: anyone who wants the current frame number (instead of
  the one as of the last interrupt) should ask for it.
* The old code wasn't terribly consistent about trying to use the frame
  that the microframe scheduler assigned to it.  In
  dwc2_sched_periodic_split() when it was scheduling the first frame it
  always "ORed" in 0x7 (!).  Since the frame goes on the wire 1 uFrame
  after next_active_frame it meant that the SSPLIT would always try for
  uFrame 0 and the transaction would happen on the low speed bus during
  uFrame 1.  This is irregardless of what the microframe scheduler
  said.
* The old code assumed it would get called to schedule the next in a
  periodic split very quickly.  That is if next_active_frame was
  0 (transfer on wire in uFrame 1) it assumed it was getting called to
  schedule the next uFrame during uFrame 1 too (so it could queue
  something up for uFrame 2).  It should be possible to actually queue
  something up for uFrame 2 while in uFrame 2 (AKA queue up ASAP).  To
  do this, code needs to look at the previously scheduled frame when
  deciding when to next be active, not look at the current frame number.
* If there was no microframe scheduler, the old code would check for
  whether we should be active using "qh->next_active_frame ==
  frame_number".  This seemed like a race waiting to happen.  ...plus
  there's no way that you wouldn't want to schedule if next_active_frame
  was actually less than frame number.

Note that this change doesn't make 100% sense on its own since it's
expecting some sanity in the frame numbers assigned by the microframe
scheduler and (as per the future patch which rewries it) I think that
the current microframe scheduler is quite insane.  However, it seems
like splitting this up from the microframe scheduler patch makes things
into smaller chunks and hopefully adds to clarity rather than reduces
it.  The two patches could certainly be squashed.  Not that in the very
least, I don't see any obvious bad behavior introduced with just this
patch.

I've attempted to keep the config parameter to disable the microframe
scheduler in tact in this change, though I'm not sure it's worth it.
Obviously the code is touched a lot so it's possible I regressed
something when the microframe scheduler is disabled, though I did some
basic testing and it seemed to work OK.  I'm still not 100% sure why you
wouldn't want the microframe scheduler (presuming it works), so maybe a
future patch (or a future version of this patch?) could remove that
parameter.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      fb616e3f
    • D
      usb: dwc2: host: Add scheduler logging for missed SOFs · 483bb254
      由 Douglas Anderson 提交于 
      We'll use the new "scheduler verbose debugging" macro to log missed
SOFs.  This is fast enough (assuming you configure it to use the ftrace
buffer) that we can do it without worrying about the speed hit.  The
overhead hit if the scheduler tracing is set to "no_printk" should be
near zero.
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      483bb254