If there is no codec instance or headphone jack, we
should not request headphone jack from machine driver.
Change-Id: If05ac2f4bbfd3fc495a75c0701a44a325e5010cd
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Some of the RK3399 sapphire excavator boards have a
suspend/resume issue with the following error log:
dpm_run_callback(): usb_dev_suspend+0x0/0x30 returns -16
PM: Device usb6 failed to suspend async: error -16
PM: Some devices failed to suspend, or early wake event detected
If this error happens, the USB port can't recognize
any USB device with the failed log:
usb usb5-port1: connect-debounce failed
It's because that the Type-A USB3 port which belongs
to fe900000.dwc3 is in abnormal state. We can check
the link state easily via the debug node:
cat /sys/kernel/debug/fe900000.dwc3/link_state
The normal link state is Rx.Detect if no USB device plug
in. But after resume, the link state will change to Polling.
According to the USB 3.1 Spec, the link state can change
from Rx.Detect to Polling state if the USB3 PHY detect
the far end receiver termination. From that we infer that
the USB3 PHY affects the USB3 controller link state since
the USB3 PHY is in power on state when enter suspend.
Actually, it's a common problem if the DWC3 work as Host
mode in the following cases, and it only happens if system
enter suspend/resume without any USB device conneted.
Case1. Type-A USB 3.0 interface with dr_mode = "host";
Case2. Type-A USB 3.0 interface with dr_mode = "otg",
and set DWC3 to host mode via "dwc3_mode";
Case3. Type-C USB 3.0 interface with dr_mode = "host";
Case4. Type-C USB 3.0 interface with dr_mode = "otg",
and plug in Type-C to Host cable;
Case5. Type-C USB 3.0 interface with dr_mode = "otg",
and set DWC3 to host mode via "dwc3_mode";
This patch power off the USB3 PHY if no USB device connect
with the DWC3 Host port before enter suspend, and power on
the USB3 PHY again upon resum.
Fixes: 323ccc3640 ("usb: dwc3: rockchip: fix rk3399 dwc3 host power on fail")
Change-Id: Ifd7805e1f4accb281dd047445d97f4cc954eb5ac
Signed-off-by: William Wu <william.wu@rock-chips.com>
Some i2s bus GPIOs maybe designed multiplex, the default
is input, we need to configure IN/OUT dynamically.
Change-Id: I2e0f0f972d6f9fa3fc8e8fc9f5dfd5d4e6deaee1
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
If the number of buffers in Import exceeds the original set of 30,
it will result in each import buffer kicking out the original stored
buffers, and all subsequent buffers need attachments.
Change-Id: I6e547e1f8943d54995077827ae0d1019e659d797
Signed-off-by: Rimon Xu <rimon.xu@rock-chips.com>
By default fsync option, if fsync is called frequently, and suddenly
lost power, the POR will consume too much memory at mounting, this
process may be very slow due to a large number of swapping.
Change-Id: I8235098cca062d7ab58af4ebed414aed9aba6c75
Signed-off-by: Cliff Chen <cliff.chen@rock-chips.com>
Test on RK3399
Fixes: f324dff252 ("drm/rockchip: dsi: Send turnaround request after a read request for dsi1")
Change-Id: Id1fad1e8c7c742291bdbd77082dd872093ad549e
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The RNDIS gadget function has USB class of 2 and subclass
of 2, which matches "USB\Class_02&SubClass_02" in the
usbser.inf file in the Windows system, so the device is
initially detected as a COM port instead of RNDIS. This
is why we need to install RNDIS manually.
Refer to Defined Class Codes [1] and rndis_host of Linux [2],
this patch sets the RNDIS gadget with base class of 0xE0h
(Wireless Controller) and subclass of 0x01h and protocol
of 0x03h.
[1] https://www.usb.org/defined-class-codes
[2] http://www.embedded-os.de/en/proto-rndis_host.shtml
Change-Id: Ida366749f378a0ce770d707b4ba56b87f9e188cf
Signed-off-by: William Wu <william.wu@rock-chips.com>
We need to export Headphone Jack snd ctl to userspace
on linux platform via multicodec machine driver.
Change-Id: I5664a0b29dfda2ed8cc450a5f0fd388d32dfdd48
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
We need to export Headphone Jack snd ctl to userspace
on linux platform via multicodec machine driver.
Change-Id: I1d042b080ab45f303f7c1a4100a2dd8014d923bc
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
We need to specify a pin description to create a
new soc jack kctl and report to userspace.
Change-Id: I46f665bd4009c0779a5c9cc3f6b9d43123b54883
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
For the legacy issues, we still need to call rk_headset
on some linux platform.
Change-Id: I395de2b8c1300b1cd7cb429dce852ef12bfe2f4c
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Some legacy hardware reference designs are based on the
driver configuration of rk_headset, we need to open it
by default.
Change-Id: I15758e15da3a6c76f8cc021749ce9fee1905f72a
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
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)
