fix iommu resource not been released when process mediaserver
crashes unexpectly.
Change-Id: Ia8209f7d0a60f6a86d273e313260b87d5facecc3
Signed-off-by: Zhong Yichong <zyc@rock-chips.com>
The RK817 & RK809 chip is a power management IC for multimedia and handheld
devices. It contains the following components:
- Regulators
- RTC
- Clkout
- Pinctrl
- Powerkey
The RK817 & RK809 core driver is registered as a platform driver and provides
communication through I2C with the host device for the different
components.
The following is the different between the RK817 and the RK809.
1、The dcdc-buck5 is a boost dcdc for RK817 and is a buck for RK809.
2、The RK817 have one switch but The Rk809 have two.
3、The RK817 have a charger and powerpatch function but RK809 not.
Change-Id: I132029c5b28978db7ae06e13c327a1edf70f5b69
Signed-off-by: Tony Xie <tony.xie@rock-chips.com>
to modify bus width error sometime plug out hdmi and switch cvbs output
Change-Id: Iaa7914fbccc99991fbfbc5495ba647f97997c8ba
Signed-off-by: Huicong Xu <xhc@rock-chips.com>
In the following case will lead to wait frame start timeout:
uboot(HDMI output 4K(DCLK: 594HZ))
-> kernel start(unplug HDMI)
->drm driver probe(plug HDMI)enable crtc(set dclk to 27Mhz)
->VOP timing register is frame effect
->VOP working at 4k output but dclk is 27M
-> VOP frame time 16.6ms * 574 / 27 = 354ms
Change-Id: Ic98af0029a15fbeef78e4f3abe4e739e760ab471
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
This change allows the user to read and edit regulator information
in user space through the debugfs file system.
Base on msm work.
Change-Id: I4b40d4fd662e3d3d0856127e8e030fa60e938df9
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
If hdmi is enabled in uboot, hdmi->disabled and bridge_is_on and
phy status need to be updated.
Change-Id: Ib21d894b673bf12b46a271c91d3e08fe7475ea89
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
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>
