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>
This patch remove nau8825 sound card node for rk3288-miniarm board,
because the change of hardware.
Change-Id: I2bc447bb247cbc5da9452591ee13dd3ae101c299
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
This reverts commit 2a1f2d1e89.
Refer to DWC3 databook, Table 7-7 Device Endpoint-n Events(DEPEVT),
XferNotReady is generated when the core responds NRDY to the host
on the USB. It is useful in the beginning of a transfer when
software wants to wait for the host to start polling the endpoint
before setting up TRBs. And also refer to 8.2.4 Transfer Setup
Recommendations, when using on-demand transfers, the XferNotRead
event must be enabled.
TEST=Set usb gadget work as RNDIS, connect to win7/win10, check
the RNDIS function
Change-Id: I091cd3ff4a3c93e6cc02fcc6714511c8989786bf
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
Both 3.3v and 1.8v are available on rk3288-miniarm board, so add sd
io-domain support in case need to deploy UHS speed mode.
Change-Id: I44a7c775620e32105c8c1b91219aac8b9d8b9e92
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
New user encoder will send larger register size to kernel with extra
info right after the register file. The extra information will specify
the offset patch for address registers. This behavior will cause a lot
of noisy log. So we need to disable it.
Change-Id: I32609be325482b445ee6e97f7f4a245d6d0dc9c2
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
H546dlb01 is a 5.46 inch OLED screen with resolution 1080x1920.
Change-Id: I977f355c53c58f6dba46c4581fc8190bfce04cf2
Signed-off-by: bivvy <bivvy.bi@rock-chips.com>
The cpu class need independent governor tunables for big/little system.
Change-Id: I0c31f694b6790c05c18b0c3d5522fa75143f293e
Signed-off-by: Chen Liang <cl@rock-chips.com>
set port->cap_lanes to 0 when dp connected error last time, and allow
dp go on probing if there is only one fusb302.
Change-Id: I90169f77ac02a94f42da96f20aacfd51b898de09
Signed-off-by: wenping.zhang <wenping.zhang@rock-chips.com>
