There are some operations that need to be ignored if there is a soft
disconnect in progress. This is to avoid having a pending EP0 transfer in
progress while attempting to stop active transfers and halting the
controller.
There were several instances seen where a soft disconnect was able to occur
during early link negotiation, i.e. bus reset/conndone, which leads to the
conndone handler re-configuring EPs while attempting to halt the
controller, as DEP flags are cleared as part of the soft disconnect path.
ep0out: cmd 'Start New Configuration'
ep0out: cmd 'Set Endpoint Transfer Resource'
ep0in: cmd 'Set Endpoint Transfer Resource'
ep1out: cmd 'Set Endpoint Transfer Resource'
...
event (00030601): Suspend [U3]
event (00000101): Reset [U0]
ep0out: req ffffff87e5c9e100 length 0/0 zsI ==> 0
event (00000201): Connection Done [U0]
ep0out: cmd 'Start New Configuration'
ep0out: cmd 'Set Endpoint Transfer Resource'
In addition, if a soft disconnect occurs, EP0 events are still allowed to
process, however, it will stall/restart during the SETUP phase. The
host is still able to query for the DATA phase, leading to a
xfernotready(DATA) event. Since none of the SETUP transfer parameters are
populated, the xfernotready is treated as a "wrong direction" error,
leading to a duplicate stall/restart routine.
Add the proper softconnect/connected checks in sequences that are
potentially involved during soft disconnect processing.
Change-Id: Iaeae73684d91391ab51a02db59e7d04d3a196301
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220817182359.13550-2-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 359d5a85a7)
Relocate the pullups_connected check until after it is ensured that there
are no runtime PM transitions. If another context triggered the DWC3
core's runtime resume, it may have already enabled the Run/Stop. Do not
re-run the entire pullup sequence again, as it may issue a core soft
reset while Run/Stop is already set.
This patch depends on
commit 69e131d1ac ("usb: dwc3: gadget: Prevent repeat pullup()")
Change-Id: Ic4fa942b4c5f39da71741146fb50b6785ba026ba
Fixes: 77adb8bdf4 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@kernel.org>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220728020647.9377-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 040f2dbd20)
The functions stop_active_transfers and ep_disable are both calling
remove_requests. This functions in both cases will giveback the requests
with status ESHUTDOWN, which also represents an physical disconnection.
For ep_disable this is not true. This patch adds the status parameter to
remove_requests and sets the status to ECONNRESET on ep_disable.
Change-Id: I7bb9dead0d4f4a50bc5600abb2a64d1d63257355
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220720213523.1055897-1-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit b44c0e7fef)
During a 3 stage SETUP transfer, if the host sends another SETUP token
before completing the status phase, it signifies that the host has aborted
the current control transfer. Currently, if a setup_packet_pending is
received, there are no subsequent calls to dwc3_ep0_out_start() to fetch
the new SETUP packet. This leads to a stall on EP0, as host does not
expect another STATUS phase as it has aborted the current transfer.
Fix this issue by explicitly stalling and restarting EP0, as well as
resetting the trb_enqueue indexes. (without this, there is a chance the
SETUP TRB is set up on trb_endqueue == 1)
Change-Id: Ib4502a1e5d70b46b6314b4061788d3883e2bdf42
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220712014403.2977-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 5e76ee96be)
According to the databook ep0 should be in setup phase during reset.
If host issues reset between control transfers, ep0 will be in an
invalid state. Fix this by issuing stall and restart on ep0 if it
is not in setup phase.
Also SW needs to complete pending control transfer and setup core for
next setup stage as per data book. Hence check ep0 state during reset
interrupt handling and make sure active transfers on ep0 out/in
endpoint are stopped by queuing ENDXFER command for that endpoint and
restart ep0 out again to receive next setup packet.
Change-Id: I4127a1d80d3f555ef606e22b49b309f24b7413bc
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
Link: https://lore.kernel.org/r/1651693001-29891-1-git-send-email-quic_mrana@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 9d778f0c5f)
If the controller hasn't DMA'ed the Setup data from its fifo, it won't
process the End Transfer command. Polling for the command completion may
block the driver from servicing the Setup phase and cause a timeout.
Previously we only check and delay issuing End Transfer in the case of
endpoint dequeue. Let's do that for all End Transfer scenarios.
Change-Id: I38ca19735337ca3e09d0d27d6623ea7acae37b16
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/2fcf3b5d90068d549589a57a27a79f76c6769b04.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f66eef8fb8)
The driver shouldn't be able to issue End Transfer to the control
endpoint at anytime. Typically we should only do so in error cases such
as invalid/unexpected direction of Data Phase as described in the
control transfer flow of the programming guide. It _may_ end started
data phase during controller deinitialization from soft disconnect or
driver removal. However, that should not happen because the driver
should be maintained in EP0_SETUP_PHASE during driver tear-down. On
soft-connect, the controller should be reset from a soft-reset and there
should be no issue starting the control endpoint.
Change-Id: I1dabd91d5078be2af8ff65e1fadd3cf16e76db7f
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/3c6643678863a26702e4115e9e19d7d94a30d49c.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit ace17b6ee4)
Since we can't guarantee that the host won't send new Setup packet
before going through the device-initiated disconnect, don't prepare
beyond the Setup stage and keep the device in EP0_SETUP_PHASE. This
ensures that the device-initated disconnect sequence can go through
gracefully. Note that the controller won't service the End Transfer
command if it can't DMA out the Setup packet.
Change-Id: I797d9cc93f775929acdead9762e79e073ac61239
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/6bacec56ecabb2c6e49a09cedfcac281fdc97de0.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c96683798e)
Don't do soft-disconnect if it's previously done. Likewise, don't do
soft-connect if the device is currently connected and running. It would
break normal operation.
Currently the caller of pullup() (udc's sysfs soft_connect) only checks
if it had initiated disconnect to prevent repeating soft-disconnect. It
doesn't check for soft-connect. To be safe, let's keep the check here
regardless whether the udc core is fixed.
Change-Id: I07eaeb0ed388ef967eeb9c7513a9c1b260f8d9c5
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1c1345bd66c97a9d32f77d63aaadd04b7b037143.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 69e131d1ac)
The usb_ep_clear_halt() API can be called from the function driver, and
translates to dwc3_gadget_ep_set_halt(). This routine is shared with when
the host issues a clear feature ENDPOINT_HALT, and is differentiated by the
protocol argument. If the following sequence occurs, there can be a
situation where the delayed_status flag is improperly cleared for the wrong
SETUP transaction:
1. Vendor specific control transfer returns USB_GADGET_DELAYED_STATUS.
2. DWC3 gadget sets dwc->delayed_status to '1'.
3. Another function driver issues a usb_ep_clear_halt() call.
4. DWC3 gadget issues dwc3_stop_active_transfer() and sets
DWC3_EP_PENDING_CLEAR_STALL.
5. EP command complete interrupt triggers for the end transfer, and
dwc3_ep0_send_delayed_status() is allowed to run, as delayed_status
is '1' due to step#1.
6. STATUS phase is sent, and delayed_status is cleared.
7. Vendor specific control transfer is finished being handled, and issues
usb_composite_setup_continue(). This results in queuing of a data
phase.
Cache the protocol flag so that DWC3 gadget is aware of when the clear halt
is due to a SETUP request from the host versus when it is sourced from a
function driver. This allows for the EP command complete interrupt to know
if it needs to issue a delayed status phase.
Change-Id: If19e1628c151a109820a60e7b4c4c6f6128a2242
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220414073902.21960-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 2840d6dfcf)
Rockchip VOP3 is new VOP architecture base on VOP2, compared to the
VOP2, the biggest change is VOP overlay and post process module.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I19ee4e91aa430ec8b80095702c697d08a696d52b
On some sensors, the exposure configuration for the first frame
will be lost if the MCLK was ever turned off before stream on.
(Such as GC2093.)
Signed-off-by: Lin Jinhan <troy.lin@rock-chips.com>
Change-Id: I06f7eb24fa4f13afaca32f66701956e216b552ec
For hdmirx controllers, audio interface always act as master And
will make system wait a long time for audio data, Here report a
audio off event to audio stream, Then applications can exit immediately
Signed-off-by: Shunhua Lan <lsh@rock-chips.com>
Change-Id: Ia8b458d5a45f8c84f17dfd10cf8bdae8d6a6016d
Move i2c0 node ahead before i2c1, make the i2c0 to be probed first.
Change-Id: I822622fc1f1ed41729851294858246cf6da8c202
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
sometimes, cause buffer state error in thunderboot mode
Signed-off-by: Zefa Chen <zefa.chen@rock-chips.com>
Change-Id: I1b750cbad21e29b112d8e7670029c6f1d0d53fc3
Remove the duplicated power key node, which has existed in
rk3288-evb.dtsi file.
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: I798fe8fc1096dc07243fa9573bb19ffc6636a358
Fixes: 78f9ac0daa ("treewide: Migrate rockchip dts file to use new host type tags")
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: I4f5a4d676a450a706770f8ad0bface40a95f5d5e
The reboot and fb notifiers are also need for some platfroms when enable
dmcfreq.
Change-Id: I7a02e43ebfff6f8cdccd050a30a9e6c270fc5b5e
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
In RK3588C, 24M clock noise is carried into the PHY ROPLL loop filter.
Due to the low noise frequency, it can pass through the low-pass loop
filter of ROPLL, resulting in hdmi clk jitter test fail.
The loop bandwidth of LCPLL is low, so LCPLL can be used to circumvent
this problem. RK3588 is also suitable for this scheme.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: I1eafbc3db3daca6b86c97a6682d120f88b71dfa0
The default bus-format should be MEDIA_BUS_FMT_UYVY8_2X8
according to sii902x datasheet.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Change-Id: Ie22ae04fc0a0d339ea211c76891d40c5942e2a86
To avoid the conflict of GKI, the drm_connector_oob_hotplug_event() is be
completed in rockchip drm driver, not the drm framework.
So add depends on DRM_ROCKCHIP, otherwise get following warning:
aarch64-none-linux-gnu-ld: drivers/usb/typec/altmodes/displayport.o: in function `dp_altmode_status_update':
drivers/usb/typec/altmodes/displayport.c:156: undefined reference to `drm_connector_oob_hotplug_event'
Fixes: 594af86e81 ("FORMLIST: usb: typec: altmodes/displayport: Notify drm subsys of hotplug events")
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: Id31efd89e5af47811138890ce9fbcb79da187b91
According to upstream commit 39b7b42be4 ("tty: stop using alloc_tty_driver").
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I1f60a2066a2649c736e333a11161bfb49bef8ccb
drivers/power/supply/rk818_battery.c: In function 'rk818_bat_calc_zero_linek':
drivers/power/supply/rk818_battery.c:1741:25: warning: this 'else' clause does not guard... [-Wmisleading-indentation]
1741 | else
| ^~~~
drivers/power/supply/rk818_battery.c:45:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'else'
45 | do { \
| ^~
drivers/power/supply/rk818_battery.c:1743:33: note: in expansion of macro 'DBG'
1743 | DBG("ZERO-new: zero_linek adjust step6...\n");
| ^~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: Iefecf6fe6b44ba84850a89a6e8cc12637f801ac0
drivers/input/touchscreen/gslx680_pad.c:1045:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
1045 | if(ret)
| ^~
In file included from ./include/linux/device.h:15,
from drivers/input/touchscreen/gslx680_pad.c:15:
./include/linux/dev_printk.h:118:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
118 | _dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~
drivers/input/touchscreen/gslx680_pad.c:1048:8: note: in expansion of macro 'dev_info'
1048 | dev_info(&ts->client->dev, "[tp-gsl] gsl_chip_id =[%d] \n",gsl_chip_id);
| ^~~~~~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: If4366c867ab6985e37708a4f89ed6d5460c74795
