Rk3036 vop default is blank, so init vop with unblank.
Change-Id: I10c21af70cec95b7073f8c999e655031ee154747
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Depending on a number of factors including:
- Which exact Rockchip SoC we're working with
- How deep we suspend
- Which i2c port we're on
We might lose the state of the i2c registers at suspend time.
Specifically we've found that on rk3399 the i2c ports that are not in
the PMU power domain lose their state with the current suspend depth
configured by ARM Tursted Firmware.
Note that there are very few actual i2c registers that aren't configured
per transfer anyway so all we actually need to re-configure are the
clock config registers. We'll just add a call to rk3x_i2c_adapt_div()
at resume time and be done with it.
NOTE: On rk3399 on ports whose power was lost, I put printouts in at
resume time. I saw things like:
before: con=0x00010300, div=0x00060006
after: con=0x00010200, div=0x00180025
Change-Id: I9799a77b9f332ef6b72ca2a8c1ee348b470a4d53
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: David Wu <david.wu@rock-chips.com>
Tested-by: David Wu <david.wu@rock-chips.com>
[wsa: removed duplicate const]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Because chg_work is used for charge detection, so if OTG works in
Host mode, we don't need to initialize chg_work, and aslo we don't
need to cancel it when phy exit.
Change-Id: I19cbede5aeb4c1f7f8faa32f195fffb0fc71eca9
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
On upstream uboot, we use ums mode to update firmware.
Add this flag to help enter USB Mass Storage mode.
Change-Id: I0e515bfd8703bd48d950b72787b365226af11ce9
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Rockchip platform use a SYSCON mapped register store
the reboot mode magic value for bootloader to use when
system reboot. So add syscon-reboot-mode driver DT node
for rk3xxx/rk3036/rk3288 based platform
Change-Id: I625613021621bd07a531d29cdb4b7c31a8bfc364
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
drm enable/disable_vblank callback maybe call when vop is disabled,
it would cause system hang, we need reject it.
Change-Id: I3825fc9074203579bba0f71b1135f77075af85bb
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
move inline function "copy_from_user" and "copy_to_user" from
rk_ftl_arm_v8.S to rk_nand_base.c
Change-Id: Ibac121c2ef04357d1abb35c4dd225bd424503e02
Signed-off-by: Zhaoyifeng <zyf@rock-chips.com>
Some phys would not enter low power mode by writing 'power down'
bit into phy common register0 such as RTL8211E. And pulling down
reset gpio is also a common way to make phy get low consumption,
if the supplied regulator of phy could not be disabled at suspend.
Change-Id: Ib01f48ec8c0bdec633868bb79e4155561ca6c471
Signed-off-by: David Wu <david.wu@rock-chips.com>
With this patch, we can support host only mode for otg port
(e.g. rk3399 Type-C1 USB). We use of_usb_get_dr_mode_by_phy()
to get the string from property 'dr_mode' of the controller
device node.
Right now, we only support host only mode for phys which do
not have phy-cells, and don't support #phy-cells >= 1.
Change-Id: Ic15b4afdfd954d91e38dbce3c996176bf2d6f101
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
There is an USB3 Standard-A receptacle on the rk3399 box platform
with Type-C1 phy, this patch enalbe Type-C1 phy for the USB3 port.
Change-Id: I77074823e713b8a4c5e4ff693746d1bd2c3c139c
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
There is a Standard-A receptacle on the rk3399 box platform with
Type-C phy, which does not have an extern Type-C controller
(e.g. FUSB302), this result in failure when typec probe, this patch
add support without extcon for usb3.0, support of dp is not included
in this patch.
Change-Id: I1af87d311707a5d385017e10478f992d940000b8
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
We used dwc->connected flag for rockchip platform before, but this
flag can be modified both in dwc3_gadget_disconnect_interrupt() and
dwc3_rockchip_otg_extcon_evt_work(), this result in race condition
may casue USB hot plug failed.
A typical error case is:
Set DWC3 works as peripheral device, connect to PC, after
PC identifies the USB device, and then disconnet USB cable,
if dwc3_gadget_disconnect_interrupt() is called prior to
dwc3_rockchip_otg_extcon_evt_work(), it will cause extcon
work unable to do disconnect operation, and let DWC3 core
device stay in runtime active status. Then if we plug in
USB cable again, we'll fail to do runtime resume DWC3 core
and reinit it.
Change-Id: I1c06fa55c10b3dfb749b689a116ab939a6e13f97
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Some SoCs have a single phy-hw-block with multiple phys, this is
modelled by a single phy dts node, so we end up with multiple
controller nodes with a phys property pointing to the phy-node
of the otg-phy.
Only one of these controllers typically is an otg controller, yet we
were checking the first controller who uses a phy from the block and
then end up looking for a dr_mode property in e.g. the ehci controller.
This commit fixes this by adding an arg0 parameter to
of_usb_get_dr_mode_by_phy and make of_usb_get_dr_mode_by_phy
check that this matches the phandle args[0] value when looking for
the otg controller.
Conflicts:
drivers/usb/phy/phy-am335x.c
Change-Id: I0b999a7445399cb2c86060bdf662db8aab96d1cc
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit ce15ed4c5d)
If OF is disabled, we will try to define a stub for
of_usb_get_dr_mode_by_phy(), however that missed a
static inline annotation which made us redefine the
stub over and over again. Fix that.
Change-Id: I0e3594d2beb29273343dacf0af73f159ad30a35d
Fixes: 98bfb39466 ("usb: of: add an api to get
dr_mode by the phy node")
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
(cherry picked from commit be99c84300)
Some USB phy drivers have different handling for the controller in each
dr_mode. But the phy driver does not have visibility to the dr_mode of
the controller.
This adds an api to return the dr_mode of the controller which
associates the given phy node.
Change-Id: I2bdf7ba8fbff03e8dd33a2f4642b4455bcdabd29
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
(cherry picked from commit 98bfb39466)
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
error log:
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by DRM_ROCKCHIP
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/rockchip/Kconfig:1: symbol DRM_ROCKCHIP depends on IOMMU_DMA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/iommu/Kconfig:52: symbol IOMMU_DMA is selected by ARM_DMA_USE_IOMMU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/arm/Kconfig:105: symbol ARM_DMA_USE_IOMMU is selected by VIDEO_OMAP3
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/media/platform/Kconfig:86: symbol VIDEO_OMAP3 depends on VIDEO_V4L2
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/media/v4l2-core/Kconfig:6: symbol VIDEO_V4L2 depends on I2C
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:374: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:362: symbol FB_CYBER2000 depends on FB
Change-Id: Ia65757ad3a220a601a0d1ef0fa34d9381c405dfe
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
According to the DesignWare state machine description, after we get a
"response error" or "response CRC error" we move into data transfer
mode. That means that we don't necessarily need to special case
trying to deal with the failure right away. We can wait until we are
notified that the data transfer is complete (with or without errors)
and then we can deal with the failure.
It may sound strange to defer dealing with a command that we know will
fail anyway, but this appears to fix a bug. During tuning (CMD19) on
a specific card on an rk3288-based system, we found that we could get
a "response CRC error". Sending the stop command after the "response
CRC error" would then throw the system into a confused state causing
all future tuning phases to report failure.
When in the confused state, the controller would show these (hex codes
are interrupt status register):
CMD ERR: 0x00000046 (cmd=19)
CMD ERR: 0x0000004e (cmd=12)
DATA ERR: 0x00000208
DATA ERR: 0x0000020c
CMD ERR: 0x00000104 (cmd=19)
CMD ERR: 0x00000104 (cmd=12)
DATA ERR: 0x00000208
DATA ERR: 0x0000020c
...
...
It is inherently difficult to deal with the complexity of trying to
correctly send a stop command while a data transfer is taking place
since you need to deal with different corner cases caused by the fact
that the data transfer could complete (with errors or without errors)
during various places in sending the stop command (dw_mci_stop_dma,
send_stop_abort, etc)
Instead of adding a bunch of extra complexity to deal with this, it
seems much simpler to just use the more straightforward (and less
error-prone) path of letting the data transfer finish. There
shouldn't be any huge benefit to sending the stop command slightly
earlier, anyway.
BUG=redmine:102457
(cherry picked from commit 46d179525a)
Change-Id: I1356df95ea7851b2143ba48dc66310e203341721
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
fix build error:
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:
In function 'rockchip_drm_fb_destroy':
drivers/gpu/drm/rockchip/rockchip_drm_fb.c:74:21:
error: 'struct rockchip_drm_fb' has no member named 'sgt'
Change-Id: I413391291be21ebf452bde340a788dcf2d1c76d4
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Add a efuse0 node in the device tree for the ARM64 rk3399 SoC.
Change-Id: I603e02177138f699b8b5f9d5609573547076e058
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
1) the efuse timing of rk3399 is different from earlier SoCs.
2) rk3399-efuse is organized as 32bits by 32 one-time programmable
electrical fuses, the efuse of earlier SoCs is organized as 32bits
by 8 one-time programmable electrical fuses with random access interface.
This patch adds a new read function for rk3399-efuse.
Change-Id: I04c70a18f7f7e77eded6ffde132baac47b3aff73
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 02baff3254)
Rk3399-efuse is organized as 32bits by 32 one-time programmable electrical
fuses. The efuse of earlier SoCs are organized as 32bits by 8 one-time
programmable electrical fuses with random access interface.
Add different device tree compatible string for different SoCs to be able
to differentiate between the two. The old binding is of course preserved,
though deprecated.
Change-Id: Id8e0e95dd1c7897235afd47d5576d15cfcb577cc
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b3149f4e33)
DEFAULT_MODE: default mode
ONE_VOP_DUAL_MIPI_HOR_SCAN: one vop to dual mipi screen hor scan
ONE_VOP_DUAL_MIPI_VER_SCAN: one vop to dual mipi screen ver scan
TWO_VOP_DUAL_MIPI: two vop to dual mipi screen
Change-Id: I48a96369059afd5615ebf41b4b6178d7206c4f72
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>
We found that the system on rk3366 SoC was crashed due to 480m
output clock of usb-phy was unstable after clock had been enabled by
gpu module.
Theoretically, 1 millisecond is a critical value for 480 output clock
stable time, so we try changing the delay time to 1.2 millisecond to
avoid this issue.
Change-Id: I8790eb3d7fccc9fbaa7b49f8d4386df147a95b75
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
