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>
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>
