Modify the wait delay utilize the high resolution timer API to allow for
more precisely scheduled callbacks.
A previous commit added a 1ms retry delay after multiple consecutive
NAKed transactions using jiffies. On systems with a low timer interrupt
frequency, this delay may be significantly longer than specified,
resulting in misbehavior with some USB devices.
This scenario was reached on a Raspberry Pi 3B with a Macally FDD-USB
floppy drive (identified as 0424:0fdc Standard Microsystems Corp.
Floppy, based on the USB97CFDC USB FDC). With the relay delay, the drive
would be unable to mount a disk, replying with NAKs until the device was
reset.
Using ktime, the delta between starting the timer (in dwc2_hcd_qh_add)
and the callback function can be determined. With the original delay
implementation, this value was consistently approximately 12ms. (output
in us).
<idle>-0 [000] ..s. 1600.559974: dwc2_wait_timer_fn: wait_timer delta: 11976
<idle>-0 [000] ..s. 1600.571974: dwc2_wait_timer_fn: wait_timer delta: 11977
<idle>-0 [000] ..s. 1600.583974: dwc2_wait_timer_fn: wait_timer delta: 11976
<idle>-0 [000] ..s. 1600.595974: dwc2_wait_timer_fn: wait_timer delta: 11977
After converting the relay delay to using a higher resolution timer, the
delay was much closer to 1ms.
<idle>-0 [000] d.h. 1956.553017: dwc2_wait_timer_fn: wait_timer delta: 1002
<idle>-0 [000] d.h. 1956.554114: dwc2_wait_timer_fn: wait_timer delta: 1002
<idle>-0 [000] d.h. 1957.542660: dwc2_wait_timer_fn: wait_timer delta: 1004
<idle>-0 [000] d.h. 1957.543701: dwc2_wait_timer_fn: wait_timer delta: 1002
The floppy drive operates properly with delays up to approximately 5ms,
and sends NAKs for any delays that are longer.
Change-Id: I54987bfcab6d874b017bdcc8641e886ea4b626f7
Fixes: 38d2b5fb75 ("usb: dwc2: host: Don't retry NAKed transactions right away")
Cc: <stable@vger.kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Terin Stock <terin@terinstock.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 6ed30a7d8e)
When handling split transactions we will try to delay retry after
getting a NAK from the device. This works well for BULK transfers that
can be polled for essentially forever. Unfortunately, on slower systems
at boot time, when the kernel is busy enumerating all the devices (USB
or not), we issue a bunch of control requests (reading device
descriptors, etc). If we get a NAK for the IN part of the control
request and delay retry for too long (because the system is busy), we
may confuse the device when we finally get to reissue SSPLIT/CSPLIT IN
and the device will respond with STALL. As a result we end up with
failure to get device descriptor and will fail to enumerate the device:
[ 3.428801] usb 2-1.2.1: new full-speed USB device number 9 using dwc2
[ 3.508576] usb 2-1.2.1: device descriptor read/8, error -32
[ 3.699150] usb 2-1.2.1: device descriptor read/8, error -32
[ 3.891653] usb 2-1.2.1: new full-speed USB device number 10 using dwc2
[ 3.968859] usb 2-1.2.1: device descriptor read/8, error -32
...
Let's not delay retries of split CONTROL IN transfers, as this allows us
to reliably enumerate devices at boot time.
Change-Id: If24ce2df467cd07e11d28baa01cdbe334fd7b592
Fixes: 38d2b5fb75 ("usb: dwc2: host: Don't retry NAKed transactions right away")
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.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 b3eb981be7)
Most users used 4K monitors with HDMI on RK3399/RK3399PRO platform, but no
more than 2K monitors on EDP/DSI panels.
So the reasonable that HDMI connected to VOPB control, and EDP/DSI shound
be connected to VOPL.
Change-Id: Id97efc5d6d534c302aa52ad00e705c093457f41e
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
afbdc should be closed before vop disable, otherwise will
abfdc will access AXI with error address, this will lead to
appear vop post empty or iommu pagefault error.
Change-Id: Ia811d629d12aa7fff8bb26ead4c97cc84b35e9b6
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
When we use /sys/class/udc/<udc>/soft_connect to do
a logical disconnection from the USB Host, the func
usb_udc_softconn_store（） anusb_gadget_remove_driver（
both call dwc3_gadget_stop(). This results in a
'Trying to free already-free IRQ' warning and stack
trace. To solve the problem, don't call free_irq()
in dwc3_gadget_stop() if dwc->gadget_driver is NULL.
Change-Id: I9d5b5b354612c3ce3677b3d15cf6af1fcbf3f399
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch fix the issue that users fail to do a logical
disconnection from the USB Host via the kernel node:
/sys/class/udc/<udc>/soft_connect
Fixes: 3099e13bdb ("usb: gadget: f_uvc: support uvc and adb use independently")
Change-Id: I2a19f72dc0a5dc34e430d384f5b475b488731311
Signed-off-by: William Wu <william.wu@rock-chips.com>
The original order of sound cards registration were really messy......
The hdmi is the first sound card by default.
for linux:
[ 1.870252] ALSA device list:
[ 1.871548] #0: rockchip,hdmi
[ 1.871863] #1: realtek,rt5651-codec
[ 1.872248] #2: ROCKCHIP,SPDIF
Then after adding this patch, the sound cards as below:
[ 1.863328] ALSA device list:
[ 1.863601] #0: realtek,rt5651-codec
[ 1.863942] #1: rockchip,hdmi
[ 1.864236] #2: ROCKCHIP,SPDIF
Change-Id: I884df2752e84d95dbddba9b23c7dbd778ffb9357
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
This patch adds bulk endpoint for uvc to be used as
video streaming transfer. By default, the uvc gadget
still uses isoc endpoint for video streaming.
The important difference between the bulk and isoc
method is that, alt-settings in a video streaming
interface are supported only for isoc endpoints as
there are different alt-settings for zero-bandwidth
and full-bandwidth use-cases, but the same is not
true for bulk endpoints, as they support only a single
alt-setting.
How to use:
1. Enable the bulk transfer:
echo 1 > /config/usb-gadget/g1/functions/uvc.name/streaming_bulk
2. Disable the bulk transfer:
echo 0 > /config/usb-gadget/g1/functions/uvc.name/streaming_bulk
3. Testing the uvc bulk function transfer:
device: run the uvc-gadget program
# uvc-gadget -b -u /dev/video<uvc video node #> -v /dev/video<vivid video node #>
where uvc-gadget is this program:
http://git.ideasonboard.org/uvc-gadget.git
with these patches:
http://www.spinics.net/lists/linux-usb/msg99220.html
Change-Id: Ifedfe3f5c4354dd2bdf07382290107e9bcc89f59
Signed-off-by: William Wu <william.wu@rock-chips.com>
Also add unpack_bootimg and update mkbootimg
AOSP 96fd8874ef8e ("Check DTB image size for boot image header version 2 and above")
Change-Id: I4582913b21f711c84d62bed0ffd024b583a094f7
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
8bit logo convert to 24bit enlarge triple buffer size which
some chips can't reserve.
Change-Id: I769602f9d04e46a039d7a9158e25c1bb2067df32
Signed-off-by: Shixiang Zheng <shixiang.zheng@rock-chips.com>
support yuyv output by setting the input mode to raw8
Change-Id: Ie33fa1e5d5cee532ebcfb23d57cac3700ee25042
Signed-off-by: Xu Hongfei <xuhf@rock-chips.com>
The dwc2 programming guide section 3.5 'Halting a Channel'
says that the application can disable any channel by
programming the HCCHARn register with the HCCHARn.ChDis
and HCCHARn.ChEna bits set to 1'b1. This enables the
dwc_otg host to flush the posted requests (if any) and
generates a Channel Halted interrupt.
But it also requires that channel disable must not be
programmed for non-split periodic channels. At the end
of the next uframe/frame (in the worst case), the core
generates a channel halted and disables the channel
automatically.
If we disable non-spilt periodic channels to halt the
channels, it will easily to cause data transfer fail.
A typical case is take photo with usb camera or close
usb camera, Specifically, the observed order is:
1. uvc driver calls usb_kill_urb
2. usb_kill_urb calls urb_dequeue to cancel urb
3. urb_dequeue call dwc_otg_hc_halt to disable
non-spilt periodic channels
4. usb core doesn't halt the non-spilt periodic
channels immediately, and the application
reallocates the channels for other transactions
without waiting for the HCINTn.ChHltd interrupt.
5. uvc driver calls usb_set_interface to start
control transfer, and gets a channel which used
for non-spilt periodic transfer before. The core
generates a channel halted and disables the channel
automatically. This cause control transfer fail.
Change-Id: I95424a99b77b552396a9fb95a5058258270ed4c2
Signed-off-by: William Wu <william.wu@rock-chips.com>
Because rk3308 vop win empty isn't reliable, so we delete it.
Change-Id: If033eb02c4d7174db8dde7984581e39c98ee4998
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
__sync_icache_dcache unconditionally skips the cache maintenance for
anonymous pages, under the assumption that flushing is only required in
the presence of D-side aliases [see 7249b79f6b ("arm64: Do not flush
the D-cache for anonymous pages")].
Unfortunately, this breaks migration of anonymous pages holding
self-modifying code, where userspace cannot be reasonably expected to
reissue maintenance instructions in response to a migration.
This patch fixes the problem by removing the broken page_mapping(page)
check from the cache syncing code, otherwise we may end up fetching and
executing stale instructions from the PoU.
Change-Id: Ie304b57c7a8597beff653e9a2a13b7cf3725a365
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Cliff Chen <cliff.chen@rock-chips.com>
(cherry picked from commit 20c27a4270)
1. use the same mutex to serialize the calls from user application.
2. keep iommu attached state when last video is closed,
because the user application may still access the buffer allocated
by v4l2 driver.
Change-Id: I667a42a07672e5d30cc4383e9f54388fe1b91f1c
Signed-off-by: Hu Kejun <william.hu@rock-chips.com>
