dma_status bit flag is set but never really used
so get rid of it.
Change-Id: If11b9522e8592dbeebf1e5d8e9a1eaad43d65f7d
Reported-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit af566a0be6)
It makes no sense to interrupt in the middle of
chained transfer. This patch just makes sure we
don't do that.
Change-Id: Ic90f7482b1f4367532199155c51fb790c3566cdc
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 8e7046b71d)
trace already adds a newline character for us, we
don't need to do it ourselves.
Change-Id: I1cf87e312e9f7f89916911f347fe1b4b93681c19
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 052ba52efa)
instead of limiting link TRB only to Isoc endpoints,
let's use it for all endpoint types, this way we are
more likely to transfer more data before a
XferComplete event.
Change-Id: Id0e34e43bd1cecf59addcfcfca8e58f727a4a8fa
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 36b68aae8e)
By moving our % DWC3_NUM_TRB operation to the
increment helpers, the rest of the driver can be
simplified.
It's also a good practice to make sure we will have
a single place dealing with details about how to
increment our enqueue and dequeue pointers.
Change-Id: I4a218a52f6d7c8c2797c64772e25dc734fc6c861
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 4faf75504a)
Add three little helpers which will aid in making
the code slightly easier to read. One helper
increments enqueue pointer, another increments
dequeue pointer and the last one tests if we're
dealing with the last TRB.
Change-Id: I98da6b44c0a348978f5e03a374af5b951bb2adc5
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit ef966b9d33)
instead of using a bitwise and, let's rely on the %
operator since that's a lot more clear. Also, GCC
will optimize % 256 to nothing anyway.
Change-Id: I7c12be2d080f3c70b1028def9736d73084100de7
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 70fdb273db)
We *know* that we have 1 PAGE (4096 bytes) for our
TRB poll. We also know the size of each TRB and know
that we can fit 256 of them in one PAGE. By using a
u8 type we can make sure that:
enqueue++ % 256;
gets optimized to an increment only.
Change-Id: I80e868bff1c431d8b9efbe1a107bfc127da70038
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit c28f82595d)
This makes it clear that we're dealing with a queue
of TRBs. No functional changes. While at that, also
rename start_slot to first_trb_index for similar
reasons.
Change-Id: Id3efc327981472fff229182552787035de1b6fb7
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 53fd88189e)
The DWC3 OMAP driver supports DT-boot only, as result dma_mask will be
always configured properly from DT -
of_platform_device_create_pdata()->of_dma_configure(). More over,
dwc3-omap.c can be built as module and in this case it's unsafe to
assign local variable as dma_mask.
Hence, remove dma_mask configuration code.
Change-Id: I48f756ccc2d84b0e5eb4afc7b3789261d735600c
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 495dd5f781)
Some freescale QorIQ platforms require to disable receiver detection
in P3 for correct detection of USB devices. If GUSB3PIPECTL(DISRXDETINP3)
is set, Core will change PHY power state to P2 and then perform receiver
detection. After receiver detection, Core will change PHY power state to
P3. Same quirk would be added in dts file in future patches.
Change-Id: Idf29b70a5c9815a87c96e2b7d8d724157f35d8da
Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit e58dd35774)
Synopsys Databook says we should move link to U0
before issuing a Start Transfer command. We could
require the gadget driver to call
usb_gadget_wakeup() however I feel that changing all
gadget drivers to keep track of Link State and
conditionally call usb_gadget_wakeup() would be far
too much work. For now we will handle this at the
UDC level, but at some point composite.c should be
one handling this.
Change-Id: I3a124898f642d909c3b705f12dcb95c6af1a7825
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit c36d8e947a)
we will need this from StartTransfer to make sure
link is in U0 before starting a transfer.
Change-Id: Id6c9497969e2a65b4fae725a0ecf6ff6c369815b
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 218ef7b647)
Synopsys Databook 2.60a has a note that if we're
sending an endpoint command we _must_ make sure that
DWC3_GUSB2PHY(n).SUSPHY bit is cleared.
This patch implements that particular detail.
Change-Id: Iee711b2a1035af1e82201eacf1ac236e87614819
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 2b0f11df84)
dwc3_send_gadget_ep_cmd() had three return
points. That becomes a pain to track when we need to
debug something or if we need to add more code
before returning.
Let's combine all three return points into a single
one just by introducing a local 'ret' variable.
Change-Id: I7faecdab1a78c973e59570fc6a32462ac4ddf6fb
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit c0ca324d09)
we don't plan on using multiple event buffers, but
if we find a good use case for it, this little trick
will help us avoid a loop in hardirq handler looping
for each and every event buffer.
Change-Id: I841862a0b825e50137f6237750c963651b1fdeb7
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit dea520a4a2)
Gadget controller might not be always active during system
suspend/resume as gadget driver might not have yet been loaded or
might have been unloaded prior to system suspend.
Check if we're active and only then perform
necessary actions during suspend/resume.
Change-Id: I1efb16ec3b2d1c32904c7bcc8cc947d266786e20
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 9772b47a4c)
dwc->regset is allocated on dwc3_debugfs_init, and should
be released on init failure or dwc3_debugfs_exit. Btw,
The line "dwc->root = NULL" is unnecessary, so remove it.
Change-Id: I57f72554e8fc6eab95bd9103c0a44f4328613d15
Signed-off-by: Du, Changbin <changbin.du@intel.com>
[ felipe.balbi@linux.intel.com : add another err label for the new
error condition ]
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit e6bdf8195b)
we need to power off the PHY during suspend and
power it back on during resume.
Change-Id: Ied8a2927e522ce1a94e5bb06ce13af678e47ca18
Signed-off-by: Felipe Balbi <balbi@kernel.org>
[nsekhar@ti.com: fix call to usb_phy_set_suspend() in dwc3_suspend()]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 5c4ad318de)
Even if pm_runtime_get*() fails, we *MUST* call
pm_runtime_put_sync() before disabling PM.
While at it, remove superfluous dwc3_omap_disable_irqs()
in error path.
Change-Id: I9dfb77af15b831f0e0e2578536d64f0a36d2fc74
Signed-off-by: Felipe Balbi <balbi@kernel.org>
[nsekhar@ti.com: patch description updates]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 45d49cb706)
we will be using a single event buffer and that
renders ev_buffs array unnecessary. Let's remove it
in favor of a single pointer to a single event
buffer.
Change-Id: I3c7b2e306be660baaa570cf63abaa532f4b87eee
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 696c8b1282)
We never, ever route any of the other event buffers
so we might as well drop support for them.
Until someone has a real, proper benefit for
multiple event buffers, we will rely on a single
one. This also helps reduce memory footprint of
dwc3.ko which won't allocate memory for the extra
event buffers.
Change-Id: I70bf36abecc422e59e90a89bb3438be6de0f8ef1
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 660e9bde74)
request_list and req_queued were, well, weird naming
choices.
Let's give those better names and call them,
respectively, pending_list and started_list. These
new names better reflect what these lists are
supposed to do.
While at that also rename req->queued to req->started.
Change-Id: I0055847591aa22310fd4e142729596c54010eefe
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit aa3342c8bb)
previously we were using a maximum of 32 TRBs per
endpoint. With each TRB being 16 bytes long, we were
using 512 bytes of memory for each endpoint.
However, SLAB/SLUB will always allocate PAGE_SIZE
chunks. In order to better utilize the memory we
allocate and to allow deeper queues for gadgets
which would benefit from it (g_ether comes to mind),
let's increase the maximum to 256 TRBs which rounds
up to 4096 bytes for each endpoint.
Change-Id: I2591378bfa8e9c98804d52a1862509c91c4b00f5
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit 8495036e98)
CSP bit of TRB Control is useful for protocols such
CDC EEM/ECM/NCM where we're transferring in blocks
of MTU-sized requests (usually MTU is 1500 bytes).
We know we will always have a short packet after two
(for HS) wMaxPacketSize packets and, usually, we
will have a long(-ish) queue of requests (for our
g_ether gadget, we have at least 10
requests).
Instead of always stopping the queue processing to
interrupt, giveback and restart, let's tell dwc3 to
interrupt but continue processing following request
if we have anything already pending in the queue.
This gave me a considerable improvement of 40% on my
test setup.
Change-Id: I02ba152fff9cacad4ffabb3c03a70b06774c09ee
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit ca4d44ea2a)
That FIFO resizing logic was added to support OMAP5
ES1.0 which had a bogus default FIFO size. I can't
remember the exact size of default FIFO, but it was
less than one bulk superspeed packet (<1024) which
would prevent USB3 from ever working on OMAP5 ES1.0.
However, OMAP5 ES1.0 support has been dropped by
commit aa2f4b16f8 ("ARM: OMAP5: id: Remove ES1.0
support") which renders FIFO resizing unnecessary.
Change-Id: I0c5843d4da7ab9ed975a723075b4b31b6c2fcc54
Tested-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit bc5081617f)
The Keystone 2 supports DT-boot only, as result dma_mask will be
always configured properly from DT -
of_platform_device_create_pdata()->of_dma_configure(). More over,
dwc3-keystone.c can be built as module and in this case it's unsafe to
assign local variable as dma_mask.
Hence, remove dma_mask configuration code.
Change-Id: I10ec6c75bf6deb68d27430bf52e1dc3a56ab151c
Cc: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit adf9a3ab90)
We were exitting the function before actually
renaming anything. While at that, also always leave
control endpoint un-renamed.
Change-Id: Ia0c8f3d5451e0f5c2e1a6bf61d5b769736bf606d
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit e901aa159d)
It's a requirement that we release controller's lock
while calling gadget API function pointers. This
patch just fixes that long standing bug.
Change-Id: I19c2cd36fa48a6c27d59305ef2d6cb4c35512433
Signed-off-by: Jiebing Li <jiebing.li@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit ad14d4e030)
Add a convenience function to check if the controller is DWC_usb31.
Change-Id: I2018d882b389a8499d4c88171650ac22059139be
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit c4137a9c84)
The check for < 0 is impossible now that
of_clk_get_parent_count() returns an unsigned int. Simplify the
code and update the types.
Change-Id: Iadb562ddbb14a61e7e7c65ec947bab12047b100b
Acked-by: Felipe Balbi <balbi@kernel.org>
Cc: <linux-usb@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
(cherry picked from commit 3d755dcc20)
Reorganize hdmi_unmute_interrupts() to put all the HPD-related config
together. This also eliminates an extra clearning of the HPD
interrupt.
BUG=chrome-os-partner:44922
TEST=HDMI still works fine.
Change-Id: I9d3cd847a00f9c887e2d054ff2b5671b0eeb8a42
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/299777
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
This is a no-op change that eliminates the dw_hdmi_fb_registered()
function and just folds the code into the one caller of the function:
hdmi_unmute_interrupts().
Eliminated because:
* The name and comment of the function implied that it was to be called
after the frame buffer was registered. ...but it wasn't called when
that happened, at least not directly.
* The function does some parts of enabling the HPD interrupt but not all
parts. Other parts are done by the calling function, and the calling
function also duplicates some bits (like clearing existing HPD). The
split doesn't make sense.
A future change will reorganize hdmi_unmute_interrupts() a little.
BUG=chrome-os-partner:44922
TEST=HDMI still works fine.
Change-Id: Ib77c03dd8f4791bc7276ccab184ff5b766de5ddd
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299776
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
We should really do the reset of i2c before we set the speed. There are
no actual known problems fixed by this, but it seems like a good idea
and the latest upstream patch does this.
BUG=chrome-os-partner:34741
TEST=HDMI vs. suspend/resume, broken monitor, HDCP, etc.
Change-Id: I5207f39e074b7ab0d56d945bd1ae74d06f89c74b
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302629
Commit-Ready: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
DDC have two modes: fast mode, standard mode. The previous ddc support
patch(https://chromium-review.googlesource.com/#/c/292012/) configure
the ddc to fast mode.
It works rightly in most HDTV case, but I found that ddc would always
failed if I used the VGA->HDMI adapter. And after I switch ddc to
standard mode, no failed anymore. I believe the standard mode could
provide better compatibility.
BUG=chrome-os-partner:34741
TEST=My VGA->HDMI adapter can read edid now
Change-Id: Ia33ade0a4fda998483baf454b9ccb9f31802f6bc
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/298270
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
In (3b9ba9a FROMLIST: drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter
support) we added a new i2c bus adapter but no of_node was provided to
the adapter. This made it difficult to assign a bus number to the
adapter in the device tree.
Because of the fact that dynamic bus numbering of i2c starts at 0 and
the fact that i2c busses are no longer allowed to be loaded extra-early
at boot (because deferred probe solves the boot order problem), it's
possible that this could cause the DDC i2c bus to get ID 0 and could
cause later SoC i2c busses to fail to probe because they're expecting to
get ID 0.
Note that probe ordering of mickey is slightly different than probe
ordering of other veyron devices, which is why this only shows up on
mickey.
BUG=chrome-os-partner:44802
TEST=With dts patch can now boot mickey again
Change-Id: I8f971a967f398ab58a6713a2b6471a4a2fe61dc6
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/297040
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
The change adds support of internal HDMI I2C master controller, this
subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.
The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks,
EDID reading operation won't succeed, in my practice all tested HDMI
monitors have at maximum one extension block.
(am from https://patchwork.kernel.org/patch/7098101)
Change-Id: Ic3abe878a02f89bda15f39676164803b467c62a1
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/292012
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
