In platform arm32, iommu is shared in different device,
it must attach to ensure hardware working in current device.
Change-Id: I854a362adf6145dcfd796885922683f8a6b7e131
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
Calling ioctl PCIE_DMA_GET_FLASH_INFO to get spi nor id.
Change-Id: I1ecfdd527f18c0c323fba9673546c167032d1726
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
These two interrupts are managed by data routine and not need to
enable it via runtime_resume each time.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: I9ef2ae0acabefeba4a69ff6b4c7edc3c0318fdeb
If kick transfer command fail and the return value isn't
EAGAIN, the current code will issue end transfer command
to stop the active transfer, and only set dep->flags with
DWC3_EP_END_TRANSFER_PENDING if the end transfer command
is done successfully. If the DWC3_EP_END_TRANSFER_PENDING
isn't set, it cleanup the cancelled requests and give the
request back to the gadget layer immediately.
For uvc gadget, the uvc gadget driver hold spinlock and
then call usb_ep_queue() to submit uvc usb request to dwc3
controller. The dwc3 controller may kick transfer for the
request sequentially, if the kick transfer command and
the end transfer command all failed, the dwc3 will give
the request back to the uvc gadget driver via the request
complete function uvc_video_complete(), in this function,
it try to get the spinlock again that lead to deadlock.
This case always happens with the following warning log:
WARNING: CPU: 0 PID: 14450 at drivers/usb/dwc3/gadget.c:1839 __dwc3_gadget_kick_transfer+0x3a0/0x3b0
...
Workqueue: events uvcg_video_pump
...
Call trace:
__dwc3_gadget_kick_transfer+0x3a0/0x3b0
__dwc3_gadget_ep_queue+0x128/0x1f0
dwc3_gadget_ep_queue+0x40/0x6c
usb_ep_queue+0x44/0x100
uvcg_video_pump+0xd0/0x1d4
process_one_work+0x1f4/0x490
worker_thread+0x278/0x4dc
kthread+0x13c/0x344
ret_from_fork+0x10/0x30
Fixes: 0ec00e864a ("UPSTREAM: usb: dwc3: gadget: move cmd_endtransfer to extra function")
Change-Id: I43d455a45d542efcaa9234de60e37277611b3c47
Signed-off-by: William Wu <william.wu@rock-chips.com>
drivers/pci/controller/dwc/pcie-dw-ep-rockchip.c:533:70: error: too few arguments to function call, expected 6, have 5
ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr, as_type);
Change-Id: Iaa3083f6cfe4edbba422fff5a245515f40c70db4
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
Validate vmf_insert_pfn return value with VM_FAULT_NOPAGE
Signed-off-by: Jacob Chen <cc@rock-chips.com>
Change-Id: I53b1eabd20ab76f08f5edf571ead1ffaccd19ec1
Fix the error from pinctrl
[ 5.112827] rockchip-pinctrl pinctrl: could not request pin 235 (gpio7-19) from group i2c5-xfer on device rockchip-pinctrl
[ 5.123951] rk3x-i2c ff170000.i2c: Error applying setting, reverse things back
[ 5.131207] rk3x-i2c: probe of ff170000.i2c failed with error -22
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: I7bdf76832fb2805ced05f0a5bb52612f528d8ebf
when uvc calls uvcg_video_enable() to disable the video
stream, it dequeues all requests from the usb endpoint,
and it expects the usb controller to giveback the requests
immediately, and then it can free the requests safely.
But for usb dwc3 controller, it doesn't giveback the
started requests in dequeue ops. Instead, it issues the
end transfer command and wait for the command completion
IRQ, then giveback the requests to uvc. If the uvc driver
free req before the command completion IRQ, it will led
to null pointer dereference problem. So need to wait
for the req complete before free it.
Example call stack on RK3588 platform:
Thread#1:
uvcg_video_enable()
-> usb_ep_dequeue()
-> dwc3_gadget_ep_dequeue()
-> dwc3_stop_active_transfer()
issue end transfer command
-> dwc3_gadget_move_cancelled_request()
...
-> uvc_video_free_requests()
-> Thread#2 executes
Thread#2:
dwc3 end transfer command completion IRQ occurs
dwc3_gadget_endpoint_command_complete()
-> dwc3_gadget_ep_cleanup_cancelled_requests()
-> dwc3_gadget_giveback()
-> usb_gadget_giveback_request()
-> uvc_video_complete()
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I0bcb8d18e851448fc973f901d74afa19ab1e2406
Due to the particularity of the px30 iommu, it is necessary to configure
the grf to switch iommu.
So need to configure rockchip,shootdown-entire to prevent a case from
happening: when one device is running, the task of another device
operates iommu when doing map.
This commit relies on the following commit:
commit 3b67ff56d6 ("video: rockchip: mpp: add iommu flush tlb before hw run for px30")
Signed-off-by: Yandong Lin <yandong.lin@rock-chips.com>
Change-Id: Ifd94ab4b5d7f53f711320b608ff105539fd9b38d
The rk3568 usb dwc3 controller has phy management at its
own driver to cover both device and host mode. And for
usb otg0, it enable device wakeup that make the usb hcd
core to keep the phy initialized so the device can wake
up the system. However, most of rk3568 platforms power
off the logic and cause phy grf lost power, thus we need
to add quirk-skip-phy-init to reinit phy grf upon system
resume.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I14061e3b8bad05818e8496d4710695ef31deed9f
PLL_CPLL is for VOP only, which does not need to be
initialized in CRU.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Change-Id: Ic51b4e2ef377ee6f796e807131f1fe02d0db39cc
When there is no acquire_fence, the allocated release_fence_fd must be
closed when the job submission fails, and it is unreasonable to require
user-space to close.
Update driver version to 1.2.22
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: Ie7c3006968dbb1ba22e21d6de65037183386112e
The gadget driver may wait on the request completion when it sets the
USB_GADGET_DELAYED_STATUS. Make sure that the End Transfer command can
go through if the dwc->delayed_status is set so that the request can
complete. When the delayed_status is set, the Setup packet is already
processed, and the next phase should be either Data or Status. It's
unlikely that the host would cancel the control transfer and send a new
Setup packet during End Transfer command. But if that's the case, we can
try again when ep0state returns to EP0_SETUP_PHASE.
Change-Id: Ie99f8e9306e1212dd602a8d9345dd5fabb640b0d
Fixes: e1ee843488 ("usb: dwc3: gadget: Force sending delayed status during soft disconnect")
Cc: stable@vger.kernel.org
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/3f9f59e5d74efcbaee444cf4b30ef639cc7b124e.1666146954.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 4db0fbb601)
DWC3_EP_DELAYED_STOP is utilized to defer issuing the end transfer command
until the subsequent SETUP stage, in order to avoid end transfer timeouts.
During cable disconnect scenarios, __dwc3_gadget_ep_disable() is
responsible for ensuring endpoints have no active transfers pending. Since
dwc3_remove_request() can now exit early if the EP delayed stop is set,
avoid clearing all DEP flags, otherwise the transition back into the SETUP
stage won't issue an endxfer command.
Change-Id: Ifaaf6405e24868b1b52f23aa492ed8ed783d1e14
Fixes: 2b2da6574e ("usb: dwc3: Avoid unmapping USB requests if endxfer is not complete")
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220919231213.21364-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 76bff31c7f)
If DWC3_EP_DELAYED_STOP is set during stop active transfers, then do not
continue attempting to unmap request buffers during dwc3_remove_requests().
This can lead to SMMU faults, as the controller has not stopped the
processing of the TRB. Defer this sequence to the EP0 out start, which
ensures that there are no pending SETUP transactions before issuing the
endxfer.
Change-Id: I576922c1a9566507f8ac268a4fc2c4bfb4129aee
Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220901193625.8727-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 2b2da6574e)
During soft disconnect, EP0 events are expected to be handled in order to
allow the controller to successfully move into the halted state. Since
__dwc3_gadget_stop() is executed before polling, EP0 has been disabled, and
events are being blocked. Allow xfercomplete events to be handled, so that
cached SETUP packets can be read out from the internal controller memory.
Without doing so, it will lead to endxfer timeouts, which results to
controller halt failures.
Change-Id: Ie58a709ee48f8f8e869285414ee2fd93d4d56326
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-5-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 dff981842a)
If any function drivers request for a delayed status phase, this leads to a
SETUP transfer timeout error, since the function may take longer to process
the DATA stage. This eventually results in end transfer timeouts, as there
is a pending SETUP transaction.
In addition, allow the DWC3_EP_DELAY_STOP to be set for if there is a
delayed status requested. Ocasionally, a host may abort the current SETUP
transaction, by issuing a subsequent SETUP token. In those situations, it
would result in an endxfer timeout as well.
Change-Id: I7decd682cf7f5714779364465383827efa22f2a1
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-3-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 e1ee843488)
