Add tve connector port. If uboot logo is enabled,
dac will not be disabled when tve bind.
Change-Id: I5d87f9d1afc05481968dc34b0bd09dd82719a933
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Checked with ic colleague, the name should be same as the datasheet,
so need to change the name, they also change it at trm.
Change-Id: Ie98ba5397cf0e5a2dba4e07fc0ca31a3330f05a6
Signed-off-by: David Wu <david.wu@rock-chips.com>
If vop return error when showing kernel logo, connector atomic flush
will not be call, and mc_clkdis can not be updated.
This patch update mc_clkdis in the dw_hdmi_bind, when phy clock is
locked and HPD is connected.
Change-Id: I1498d787a993961fe75236c309ecc3c898d611a4
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
On rk3288-veyron devices on Chrome OS it was found that plugging in an
Arduino-based USB device could cause the system to lockup, especially
if the CPU Frequency was at one of the slower operating points (like
100 MHz / 200 MHz).
Upon tracing, I found that the following was happening:
* The USB device (full speed) was connected to a high speed hub and
then to the rk3288. Thus, we were dealing with split transactions,
which is all handled in software on dwc2.
* Userspace was initiating a BULK IN transfer
* When we sent the SSPLIT (to start the split transaction), we got an
ACK. Good. Then we issued the CSPLIT.
* When we sent the CSPLIT, we got back a NAK. We immediately (from
the interrupt handler) started to retry and sent another SSPLIT.
* The device kept NAKing our CSPLIT, so we kept ping-ponging between
sending a SSPLIT and a CSPLIT, each time sending from the interrupt
handler.
* The handling of the interrupts was (because of the low CPU speed and
the inefficiency of the dwc2 interrupt handler) was actually taking
_longer_ than it took the other side to send the ACK/NAK. Thus we
were _always_ in the USB interrupt routine.
* The fact that USB interrupts were always going off was preventing
other things from happening in the system. This included preventing
the system from being able to transition to a higher CPU frequency.
As I understand it, there is no requirement to retry super quickly
after a NAK, we just have to retry sometime in the future. Thus one
solution to the above is to just add a delay between getting a NAK and
retrying the transmission. If this delay is sufficiently long to get
out of the interrupt routine then the rest of the system will be able
to make forward progress. Even a 25 us delay would probably be
enough, but we'll be extra conservative and try to delay 1 ms (the
exact amount depends on HZ and the accuracy of the jiffy and how close
the current jiffy is to ticking, but could be as much as 20 ms or as
little as 1 ms).
Presumably adding a delay like this could impact the USB throughput,
so we only add the delay with repeated NAKs.
NOTE: Upon further testing of a pl2303 serial adapter, I found that
this fix may help with problems there. Specifically I found that the
pl2303 serial adapters tend to respond with a NAK when they have
nothing to say and thus we end with this same sequence.
Change-Id: Ie9306eeef2694ceb59a07658905223f698b74e9a
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
commit 38d2b5fb75)
when have two connector, show_loader_logo() must free the
unused connect resources.
Change-Id: Ic0ad98988d7dbae8143087cf00e3c5914281188a
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
warning: Access to field 'dev' results in a dereference of a null
pointer (loaded from variable 'panel')
Change-Id: I0f4224b47b3b7c16a9022e19f8de28df66784a7f
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
This patch can fix the following issue:
The gpio is not invalid when configured as active low.
Change-Id: Idc0618db3c20534ad5c952a4c9b4d4a366599cbf
Signed-off-by: Kaige Li <kevin.li@rock-chips.com>
In current code, the pre-emphasize in eop state and chirp state are
disabled only if we add “rockchip,u2phy-tuning” property in RK3399 dts,
But we find that if we enable the pre-emphasize of sop/eop/chirp state
for rk3399 by default, it will cause usb2 compliance test item - EL_8
and EL_9 failure, so disable the pre-emphasize of sop/eop/chirp state
by default. And this can also help to avoid mis-trigger the disconnect
detection or high-speed handshake failure.
Change-Id: I5ceac9c88de4cdae5af904e973124c194f7718f6
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
This patch fixes the following warnings:
drivers/pinctrl/pinctrl-rockchip.c:1869:9: warning: 1st function call argument is an uninitialized value
ret = regmap_read(extra_regmap, extra_reg, &temp);
^
drivers/pinctrl/pinctrl-rockchip.c:1999:48: warning: The left operand of '+' is a garbage value
data = ((1 << rmask_bits) - 1) << (extra_bit + 16);
^
Change-Id: Ie1bfe825925505314d5d9a4d5491e38768916dbd
Signed-off-by: David Wu <david.wu@rock-chips.com>
avoid out of value range calculate catmdsclk when 4k10bit and set
scdc high tmds clock ratio when mtmdsclock is more than 340000000
Change-Id: I8aed4c99813e43c69526f3918d5e7024879d3288
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
if bootup with hdmi plugin initialize mtmdsclock to modify voicelessness
and set bridge_is_on true to modify green screen when reboot from recovery
Change-Id: I0ed9f956d62ab4087cb42a54dafba6a0fc9e5a7e
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
if get edid error at bootup the input bus format will be set as
rgb and hdmi is no reinit, so hdmi color will be wrong if set yuv
in uboot, now reinit hdmi in this case.
Change-Id: I8d117b6e241079ceab44793f6566adf91e9d84c6
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
voppwm is frame effect, so we need add vop pwm en to
indicate the pwm en state.
Change-Id: I1492322f99b638c8dc6cf03c87035f28dca3de8f
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
