add rk3288/rk3368/rk3399 vop area plane
Change-Id: Ia6f77353363e25423ac29129372bc510565682f8
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
The series vop of VOP_FULL framework support area plane, such as
RK3288 and RK3399, one group of area planes share same hardware,
reuse the hardware on different scanout time, this design is
useful to support mulit planes with low hardware consume.
Change-Id: Ie53211ce9ed22d03f7668637efbb7c95d9a8eb5b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
The plane hardware is used when the display scanout run into plane active
scanout, that means we can reuse the plane hardware resources on plane
non-active scanout.
Because resource share, There are some limit on share plane: one group
of share planes need use same zpos, can't not overlap, etc.
We assume share plane is a universal plane with some limit flags.
people who use the share plane need know the limit, should call the ioctl
DRM_CLIENT_CAP_SHARE_PLANES, and judge the planes limit before use it.
Change-Id: Iecc3d8e7f1ce29d567cdbad689ba4dbad3d594e1
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
DTS hdmi phy name have to be the same with dt-binding document and
hdmi driver code.
Change-Id: Ib2142607e0792f430f05a972206e608f79a46132
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
DTS hdmi phy name have to be the same with dt-binding document and
hdmi driver code.
Change-Id: I00edde5b5745832f123b98f41a2fdb52434ce386
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
When cherry-pick from develop-4.4, inno hdmi phy config entry
was lost (commit-id: 0b56e9a7e8).
So we must add inno hdmi phy config entry again.
Change-Id: I8a17c75359869896f5f110cf268c3c2469781537
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
This change allows the user to read and edit regulator information
in user space through the debugfs file system.
Base on msm work.
Change-Id: I4b40d4fd662e3d3d0856127e8e030fa60e938df9
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Under some circumstances the Frame Composer arithmetic unit can miss
an FC register write due to being busy processing the previous one.
The issue can be worked around by issuing a TMDS software reset and
then write one of the FC registers several times. After tested, the
number of iterations of RK3399/RK3328(v2.11a), RK3368(v2.01a),
RK3288(v2.00a) is one.
Change-Id: Iba209e25d56aff84a8cc90b4d8dcb87369c9ae52
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
The macro name DWC3_DCTL_LPM_ERRATA is uninformative and does not do
masking. Remove DWC3_DCTL_LPM_ERRATA_MASK and rename
DWC3_DCTL_LPM_ERRATA to DWC3_DCTL_NYET_THRES with proper masking.
Change-Id: I74a86306c10a5d03e8d772a86f04ffe9048ad990
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 2e487d2805)
DWC3 is missing the printing of control request GET_STATUS(device)
tracepoint. This patch prints that.
Change-Id: I22b523a236a7afe913f7d7f52791f26a8a007847
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit dd24f9b604)
The setting of the dr_mode may need to check the controller's revision.
The revision is set in the dwc3_core_is_valid(), which comes after
dr_mode setting. Let's move it closer to the start of the dwc3_probe()
function and before calling dwc3_get_dr_mode().
Change-Id: I400f22c66cd03abebfed2c8791c88baafb581b39
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit b873e2d0ea)
All DWC3 controllers are LPM capable. Report that in the
usb_gadget.lpm_capable for the gadget driver to properly output the
bcdUSB value in the descriptor.
Change-Id: Ib40247fb4145a683ce84a0358eddfeb69b5a868c
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit c729969b2b)
dwc3_gadget_suspend() is called under dwc->lock spinlock. In such context
calling synchronize_irq() is not allowed. Move the problematic call out
of the protected block to fix the following kernel BUG during system
suspend:
BUG: sleeping function called from invalid context at kernel/irq/manage.c:112
in_atomic(): 1, irqs_disabled(): 128, pid: 1601, name: rtcwake
6 locks held by rtcwake/1601:
#0: f70ac2a2 (sb_writers#7){.+.+}, at: vfs_write+0x130/0x16c
#1: b5fe1270 (&of->mutex){+.+.}, at: kernfs_fop_write+0xc0/0x1e4
#2: 7e597705 (kn->count#60){.+.+}, at: kernfs_fop_write+0xc8/0x1e4
#3: 8b3527d0 (system_transition_mutex){+.+.}, at: pm_suspend+0xc4/0xc04
#4: fc7f1c42 (&dev->mutex){....}, at: __device_suspend+0xd8/0x74c
#5: 4b36507e (&(&dwc->lock)->rlock){....}, at: dwc3_gadget_suspend+0x24/0x3c
irq event stamp: 11252
hardirqs last enabled at (11251): [<c09c54a4>] _raw_spin_unlock_irqrestore+0x6c/0x74
hardirqs last disabled at (11252): [<c09c4d44>] _raw_spin_lock_irqsave+0x1c/0x5c
softirqs last enabled at (9744): [<c0102564>] __do_softirq+0x3a4/0x66c
softirqs last disabled at (9737): [<c0128528>] irq_exit+0x140/0x168
Preemption disabled at:
[<00000000>] (null)
CPU: 7 PID: 1601 Comm: rtcwake Not tainted
5.0.0-rc3-next-20190122-00039-ga3f4ee4f8a52 #5252
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c01110f0>] (unwind_backtrace) from [<c010d120>] (show_stack+0x10/0x14)
[<c010d120>] (show_stack) from [<c09a4d04>] (dump_stack+0x90/0xc8)
[<c09a4d04>] (dump_stack) from [<c014c700>] (___might_sleep+0x22c/0x2c8)
[<c014c700>] (___might_sleep) from [<c0189d68>] (synchronize_irq+0x28/0x84)
[<c0189d68>] (synchronize_irq) from [<c05cbbf8>] (dwc3_gadget_suspend+0x34/0x3c)
[<c05cbbf8>] (dwc3_gadget_suspend) from [<c05bd020>] (dwc3_suspend_common+0x154/0x410)
[<c05bd020>] (dwc3_suspend_common) from [<c05bd34c>] (dwc3_suspend+0x14/0x2c)
[<c05bd34c>] (dwc3_suspend) from [<c051c730>] (platform_pm_suspend+0x2c/0x54)
[<c051c730>] (platform_pm_suspend) from [<c05285d4>] (dpm_run_callback+0xa4/0x3dc)
[<c05285d4>] (dpm_run_callback) from [<c0528a40>] (__device_suspend+0x134/0x74c)
[<c0528a40>] (__device_suspend) from [<c052c508>] (dpm_suspend+0x174/0x588)
[<c052c508>] (dpm_suspend) from [<c0182134>] (suspend_devices_and_enter+0xc0/0xe74)
[<c0182134>] (suspend_devices_and_enter) from [<c0183658>] (pm_suspend+0x770/0xc04)
[<c0183658>] (pm_suspend) from [<c0180ddc>] (state_store+0x6c/0xcc)
[<c0180ddc>] (state_store) from [<c09a9a70>] (kobj_attr_store+0x14/0x20)
[<c09a9a70>] (kobj_attr_store) from [<c02d6800>] (sysfs_kf_write+0x4c/0x50)
[<c02d6800>] (sysfs_kf_write) from [<c02d594c>] (kernfs_fop_write+0xfc/0x1e4)
[<c02d594c>] (kernfs_fop_write) from [<c02593d8>] (__vfs_write+0x2c/0x160)
[<c02593d8>] (__vfs_write) from [<c0259694>] (vfs_write+0xa4/0x16c)
[<c0259694>] (vfs_write) from [<c0259870>] (ksys_write+0x40/0x8c)
[<c0259870>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
Exception stack(0xed55ffa8 to 0xed55fff0)
...
Change-Id: I90fa927b1b5d428a7114d2a7a40915cf04837fbb
Fixes: 01c10880d2 ("usb: dwc3: gadget: synchronize_irq dwc irq in suspend")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 41a91c606e)
When we read an array of integers from device properties,
the temporary buffer is allocated.
However, in case of dwc3_set_incr_burst_type() it's not freed.
Free allocated buffer immediately after use.
Change-Id: I19353b4b74fb09543a91b2927f5166cecaa9d94b
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 75ecb9dd56)
Currently req->num_trbs is not reset after the TRBs are skipped and
processed from the cancelled list. The gadget driver may reuse the
request with an invalid req->num_trbs, and DWC3 will incorrectly skip
trbs. To fix this, simply reset req->num_trbs to 0 after skipping
through all of them.
Change-Id: I3baf95ab4513f54f65ed2c79ff6bf1e0655006fc
Fixes: c3acd59014 ("usb: dwc3: gadget: use num_trbs when skipping TRBs on ->dequeue()")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit c7152763f0)
Since we're disabling the endpoint anyway, we don't worry about
getting endpoint command completion interrupt.
Change-Id: Ibd8b9f362b88da6bc7e60e19156dcf0a816ae42a
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit c5353b225d)
i.MX6QP and i.MX7D platform use a PCIe controller with the same VID and
PID as this USB controller. The system may incorrectly match this driver
to that PCIe controller. To workaround this, specifically use class type
USB with PCI device ID to prevent incorrect driver matching.
Change-Id: Ie0b9d6ebe4eaa2209af0c098b9ae120b576a94da
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 9c7ebc99b3)
Now that buffer size is always passed around, we don't need to rely on
strcat anymore.
Change-Id: If24ef7da4630e04f5fd75ae4621ae11785bce15f
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 1381a5113c)
Instead of assuming that our buffer is big enough, let's pass the
buffer size around so printing functions can make sure they won't
overflow the buffer.
Change-Id: I8d2bbbdabf6247f69ac7a3132b199938486c7193
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 7790b3556f)
Now that we modified the code to fix a race condition, it's clear that
DWC3_EP_END_TRANSFER_PENDING is unnecessary, considering that
DWC3_EP_TRANSFER_STARTED will remain set until End Transfer completes.
Change-Id: Ifbbd5c961a2e757cc3e39f8ba0d0a27bb3d18897
Tested-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 3aec99154d)
There is a rare race condition that may happen during a Disconnect
Interrupt if we have a started request that happens to be
dequeued *after* completion of End Transfer command. If that happens,
that request will be left waiting for completion of an End Transfer
command that will never happen.
If End Transfer command has already completed before, we are safe to
giveback the request straight away.
Change-Id: I98d4f8a42459d752be969cf3aabc9b01d5bcd212
Tested-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 9f45581f5e)
We have a proper flag for testing that we have a valid transfer in
flight, let's use that instead.
This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Change-Id: I475cd17ef21acd268b326c4896e973d9f4437b5b
Tested-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 974a1368c3)
We must wait until End Transfer completes in order to clear
DWC3_EP_TRANSFER_STARTED, otherwise we may confuse the driver.
This patch is in preparation to fix a rare race condition that happens
upon Disconnect Interrupt.
Change-Id: I2f36f240dc0917715d0eeacde14b22043e19eee7
Tested-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit acbfa6c26f)
For OUT endpoints, zero-length transfers require MaxPacketSize buffer as
per the DWC_usb3 programming guide 3.30a section 4.2.3.3.
This patch fixes this by explicitly checking zero length
transfer to correctly pad up to MaxPacketSize.
Change-Id: I9dff2dabdbe1c5cd86ef213356bcbefe90d0e1be
Fixes: c6267a5163 ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
Cc: stable@vger.kernel.org
Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 1e19cdc806)
Now that we have req->status, we don't need this extra flag
anymore. It's safe to remove it.
Change-Id: I95a9b2a7c7f3e8aeff224e30886e51a8786bb99b
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 7c3d7dc89e)
Queueing the same request twice can introduce hard-to-debug
problems. At least one function driver - Android's f_mtp.c - is known
to cause this problem.
While that function is out-of-tree, this is a problem that's easy
enough to avoid.
Change-Id: Ia1535b7f8b9a1899f585e2539c3326ae6e260df6
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit b2b6d60136)
This patch starts tracking dwc3_request status. A following patch will
build on top of this to prevent a request from being queued twice.
Change-Id: Ifd85d753e508bc31694fc76d6ac1fd0675430553
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit a3af5e3ad3)
On v3.10a in dual-role mode, if port is in device mode
and gadget driver isn't loaded, the OTG event interrupts don't
come through.
It seems that if the core is configured to be OTG2.0 only,
then we can't leave the DCFG.DEVSPD at Super-speed (default)
if we expect OTG to work properly. It must be set to High-speed.
Fix this issue by configuring DCFG.DEVSPD to the supported
maximum speed at gadget init. Device tree still needs to provide
correct supported maximum speed for this to work.
This issue wasn't present on v2.40a but is seen on v3.10a.
It doesn't cause any side effects on v2.40a.
Change-Id: If3c14d2e49d75f674a271fe6e5d40120c3d4da72
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 169e3b68ca)
There are a few remaining drivers/usb/ files that do not have SPDX
identifiers in them, all of these are either Kconfig or Makefiles. Add
the correct GPL-2.0 identifier to them to make scanning tools happy.
Conflicts:
drivers/usb/typec/tcpm/Kconfig
Change-Id: I71f213ce249e506e0a3cf21cc33ed890e953cca4
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit cae8dc3b68)
Currently the link_state is uninitialized and the default value is 0(U0)
before the first time we start the udc, and after we start the udc then
stop the udc, the link_state will be undefined.
We may have the following warnings if we start the udc again with
an undefined link_state:
WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308
dwc3 100e0000.hidwc3_0: wakeup failed --> -22
[...]
Call Trace:
[<c010f270>] (unwind_backtrace) from [<c010b3d8>] (show_stack+0x10/0x14)
[<c010b3d8>] (show_stack) from [<c034a4dc>] (dump_stack+0x84/0x98)
[<c034a4dc>] (dump_stack) from [<c0118000>] (__warn+0xe8/0x100)
[<c0118000>] (__warn) from [<c0118050>](warn_slowpath_fmt+0x38/0x48)
[<c0118050>] (warn_slowpath_fmt) from [<c0442ec0>](dwc3_send_gadget_ep_cmd+0x304/0x308)
[<c0442ec0>] (dwc3_send_gadget_ep_cmd) from [<c0445e68>](dwc3_ep0_start_trans+0x48/0xf4)
[<c0445e68>] (dwc3_ep0_start_trans) from [<c0446750>](dwc3_ep0_out_start+0x64/0x80)
[<c0446750>] (dwc3_ep0_out_start) from [<c04451c0>](__dwc3_gadget_start+0x1e0/0x278)
[<c04451c0>] (__dwc3_gadget_start) from [<c04452e0>](dwc3_gadget_start+0x88/0x10c)
[<c04452e0>] (dwc3_gadget_start) from [<c045ee54>](udc_bind_to_driver+0x88/0xbc)
[<c045ee54>] (udc_bind_to_driver) from [<c045f29c>](usb_gadget_probe_driver+0xf8/0x140)
[<c045f29c>] (usb_gadget_probe_driver) from [<bf005424>](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite])
[<bf005424>] (gadget_dev_desc_UDC_store [libcomposite]) from[<c023d8e0>] (configfs_write_file+0xd4/0x160)
[<c023d8e0>] (configfs_write_file) from [<c01d51e8>] (__vfs_write+0x1c/0x114)
[<c01d51e8>] (__vfs_write) from [<c01d5ff4>] (vfs_write+0xa4/0x168)
[<c01d5ff4>] (vfs_write) from [<c01d6d40>] (SyS_write+0x3c/0x90)
[<c01d6d40>] (SyS_write) from [<c0107400>] (ret_fast_syscall+0x0/0x3c)
Change-Id: I0624247cc507043d7f6d20f48d08a914e2efda2e
Signed-off-by: Zeng Tao <prime.zeng@hisilicon.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 88b1bb1f3b)
We see dwc3 endpoint stopped by unwanted irq during
suspend resume test, which is caused dwc3 ep can't be started
with error "No Resource".
Here, add synchronize_irq before suspend to sync the
pending IRQ handlers complete.
Change-Id: I84b64e9fc760552fe831497a5889db0537e72667
Signed-off-by: Bo He <bo.he@intel.com>
Signed-off-by: Yu Wang <yu.y.wang@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 01c10880d2)
Move Synopsys HAPS platform device IDs to pci_ids.h so that both
drivers/pci/quirks.c and dwc3-haps driver can reference these IDs.
Change-Id: Id07de9d2a298cc6ffb872a6f3ba9b621e03b36a0
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit b6061b1e56)
In stream mode, when fast-forwarding TRBs, the stream number
is not cleared causing the new stream to not get assigned. So
we don't want controller to carry on transfers when short packet
is received. So disable the CSP for stream capable endpoint.
This is based on the 3.30a Programming guide, where table 3-1
device descriptor structure field definitions says for CSP bit
If this bit is 0, the controller generates an XferComplete event
and remove the stream. So if we keep CSP as 1 then switching between
streams would not happen as in stream mode, when fast-forwarding
TRBs, the stream number is not cleared causing the new stream to not get
assigned.
Change-Id: Ifd97bcedd72e18213cba830db900c261164a08f5
Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 244add8ebf)
The missed break statement in the outer switch makes the code fall through
always and thus always same value will be printed.
Besides that, compiler warns about missed fall through marker:
drivers/usb/dwc3/./trace.h: In function ‘trace_raw_output_dwc3_log_trb’:
drivers/usb/dwc3/./trace.h:246:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
switch (pcm) {
^~~~~~
Add the missing break statement to work correctly without compilation
warnings.
Change-Id: I189588587ec7a89d5c1ae2f0a5c06f11b26b08d6
Fixes: fa8d965d73 ("usb: dwc3: trace: pretty print high-bandwidth transfers too")
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 54d48183d2)
Implement the new frame_number API to report the isochronous interval
frame number. This patch checks and reports the interval in which the
isoc transfer was transmitted or received via the Isoc-First TRB SOF
number field.
Change-Id: I7ac010bd196b029c3da8707fd120f16756763191
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 6abfa0f5bb)
Add a field frame_number to the usb_request to report the interval
number in (micro)frames in which the isochronous transfer was
transmitted or received. The gadget driver can use this knowledge to
synchronize with the host. Also, this option is useful for debugging
purposes.
Change-Id: I94d9186bd31e277f385ba886e3c7e45dff100ab6
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 6b69753fa0)
Availability of TRB's is calculated using dwc3_calc_trbs_left(), which
determines total available TRB's based on the HWO bit set in a TRB.
In the present code, __dwc3_prepare_one_trb() is called with a TRB which
needs to be prepared for transfer. This __dwc3_prepare_one_trb() calls
dwc3_calc_trbs_left() to determine total available TRBs and set IOC bit
if the total available TRBs are zero. Since the present working TRB (which
is passed as an argument to __dwc3_prepare_one_trb() ) doesn't yet have
the HWO bit set before calling dwc3_calc_trbs_left(), there are chances
that dwc3_calc_trbs_left() wrongly calculates this present working TRB
as free(since the HWO bit is not yet set) and returns the total available
TRBs as greater than zero (including the present working TRB). This could
be a problem.
This patch corrects the above mentioned problem in __dwc3_prepare_one_trb()
by increementing the dep->trb_enqueue at the last (after preparing the TRB)
instead of increementing at the start and setting the IOC bit only if the
total available TRBs returned by dwc3_calc_trbs_left() is 1 . Since we are
increementing the dep->trb_enqueue at the last, the present working TRB is
also considered as available by dwc3_calc_trbs_left() and non zero value is
returned . So, according to the modified logic, when the total available
TRBs is equal to 1 that means the total available TRBs in the pool are 0.
Change-Id: I9fbded627019c756520f943acd60e80dafe881bb
Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Reviewed-by: Thinh Nguyen <thinhn@synopsys.com>
Tested-by: Tejas Joglekar <tejas.joglekar@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit b7a4fbe230)
The stream capable endpoints require stream id to be given
when issuing START TRANSFER. While issuing no-op trb the
stream id is not yet known, so don't issue no-op trb's on
stream capable endpoints.
Change-Id: I0e4f3759f4ca9d2b9d06542a498fa3b01002e7c6
Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 26d62b4d10)
For stream capable endpoints, stream id related information
needs to be updated into DEPCMD while issuing START TRANSFER.
This patch does the same.
Change-Id: I2f1b8714cd819c2c5ca723514b43ff24a6b920c5
Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit a7351807bd)
