rk3288 cif can work with mipi channel and switch work mode
Change-Id: Ie8a49cf787617ff5d98ef84cdac761c3ece761c9
Signed-off-by: Allon Huang <allon.huang@rock-chips.com>
txrx can be linked with isp or csi-host, so separate it
Change-Id: I41d81770c53008bdf9703f92834cc41d9724a563
Signed-off-by: Allon Huang <allon.huang@rock-chips.com>
Link mipi with cif to work.
Meanwhile,replace isp node with rkisp1 node to use
rkisp driver and remove edp-panel enable pin due to
it conflicts with dvp pwdn pin on rk3288-evb-v11.
Change-Id: If8125d2173c7340d7d702294ab55ee2f0c433663
Signed-off-by: Allon Huang <allon.huang@rock-chips.com>
drm_dp_cec_register_connector() is called when registering each DP
connector in DRM, while sounds a good idea register CEC adapters as
earlier as possible, it causes some driver initialization delay
trying to do DPCD transactions in disconnected connectors.
This change will cause no regressions as drm_dp_cec_set_edid() will
still be called in further detection of connected connectors with a
valid edid parameter.
This change reduced the module load of i915 by average 0.5sec in a
machine with just one DP port disconnected while reducing more than
3sec in a machine with 4 DP ports disconnected.
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181011004439.4482-1-jose.souza@intel.com
(cherry picked from commit 7323001549)
Change-Id: I815948f733719705bbc576fc1ca723fb5a59fe6b
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
If aux->transfer == NULL, then just return without doing
anything. In that case the function is likely called for
a non-(e)DP connector.
This never happened for the i915 driver, but the nouveau and amdgpu
drivers need this check.
The alternative would be to add this check in those drivers before
every drm_dp_cec call, but it makes sense to check it in the
drm_dp_cec functions to prevent a kernel oops.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180827075820.41109-2-hverkuil@xs4all.nl
(cherry picked from commit 5ce70c799a)
Change-Id: I8a56122cc777e17c2b303120372f7087a94c5083
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180711132909.25409-2-hverkuil@xs4all.nl
(cherry picked from commit 2c6d1fffa1)
Conflicts:
drivers/gpu/drm/Makefile
drivers/gpu/drm/drm_dp_helper.c
include/drm/drm_dp_helper.h
Change-Id: I63df93f87cc521c148b6a999de9459577680a4f6
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
The CEC_CAP_LOG_ADDRS, CEC_CAP_TRANSMIT, CEC_CAP_PASSTHROUGH and
CEC_CAP_RC capabilities are normally always present.
Add a CEC_CAP_DEFAULTS define that ORs these four caps to simplify
drivers.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit ee0c503eac)
Change-Id: Ic3221f5c676f2159dbe65115e38dfae5a8b6712e
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
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>
