Since ddr initalize codes have some update, so ddr dmc driver
needs to update.
Disable the dmc currently for evb to boot success.
Change-Id: Ica259a81f5412da31d41b68c841dfda7d8c2e3b2
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
This adds support usb2.0 phy-phandle for ohci controller on rk3366.
Change-Id: I9b5e27636e7574669ba01e4302c741d8895c68ff
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
We found that the system on rk3366-sdk will crash at the first time
after updating the whole firmware, the root cause is the 480m clock
from usb-phy has some issues.
Since the new usb-phy driver have taken over the 480m clock's
maintenance, the clock tree have a bit changes, so related
reference clock for usb-controler also need to correct.
Change-Id: I54dcc6f416adf61c34df2b9b897e5b58f3b6fed8
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
- Add the corresponding to samplerate for bitstream
- Add the audio type judgement when open the mode
Change-Id: Ic5bbd2ee214e707fd3695f1a1f359cd43fed9618
Signed-off-by: smj <smj@rock-chips.com>
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch makes es8323 work well on the RK3288-Fennec boards.
Change-Id: Ia71101363c5cc4a9650c21c5dbebcad4d785ebf8
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
This patch update the es8323 codec drivers as follows:
o Remove snd_soc_control_type:
Now that upstream remove definition of snd_soc_control_type.
o Replace SOC_DAPM_VALUE_ENUM:
SOC_DAPM_VALUE_ENUM is replaced by SOC_DAPM_ENUM.
o Remove codec->dapm.bias_level = level:
The line at the end of the set_bias_level callback to update the bias_level state. Now that upstream move this update into snd_soc_dapm_force_bias_level().
o Remove .owner = THIS_MODULE:
No need to set .owner here.The i2c_driver core will do.
o module_i2c_driver:
Convert to use module_i2c_driver is simple.
o Add match table:
Add a device tree match table for es8323 codec driver.
o Add mclk:
The I2S block provide the output clock as the mclk,so add it.
o Adjust code format:
Adjust some problems of code format.
Change-Id: I8e0647310eb11325c39ebb408f75cc9ed28df71d
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
It will cause conflict if we are using other vendor driver.
Change-Id: Ia5f6ccc22c1f733abc1569486d5a864e41d4f4a5
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
It will cause conflict if we are using other vendor driver.
Change-Id: I269c253fae874acf1b0290f5f16ca1433cf33b15
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
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>
