Add a binding that describes the Rockchip PCIe controller found on Rockchip
SoCs PCIe interface.
Change-Id: Ifb84320315c06759612f2b3d9b2b6ff3e1e5cb1e
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
This patch adds a binding that describes the Rockchip PCIe PHY found
on Rockchip SoCs PCIe interface.
Change-Id: I18940e940e0c951d3e2d6bb3b2131a37727a430d
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
If pwm polarity was configured with different values at uboot,
the enable_conf would not be configured correctly.
Change-Id: I55b9ccc262382951a8a82810f1be74ce9460f266
Signed-off-by: Zhou weixin <zwx@rock-chips.com>
1. modify clock-names, according to Heiko's suggestion, clock names
should always be in the scope of the device block (named after what
it supplies), and clock-names are always meant from the perspective
of the individual ip-block.
2. remove unnecessary clocks, refer to rk3399 TRM, aclk_usb3 is the
parent of aclk_usb3otg0/1 and aclk_usb3_grf, and we will enable
aclk_usb3otg0/1 and aclk_usb3_grf, so don't need to enable aclk_usb3
again. In addition, the aclk_usb3_rksoc_axi_perf clk is used for usb3
performance monitor module which we don't use now, so don't need to
enable it.
Change-Id: I1d50a72d1523b8b70f1e5f388dc357807131dd7c
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
When do Rx compliance test, PHY is in loopback mode, we
observed that Rx test failed with long cable, and it was
found that equalizer adaptation is not happening properly.
With rx_eq_training forced from PMA, the equalizer adaptation
working fine and Rx test can pass. The root cause is that
the Rx REE component will be turned off when control data
is being received by default PHY configuration. So we need
to unmask REE control data by setting REE control data mask
register, and with this patch, equalizer training will happen
based on the signal coming from controller only.
Change-Id: Ic4fca1045d92381470588c4afccff0cc7318ab4c
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
userspace will set several frame after vop suspend, so the kernel back
buffer will be freed and after resume vop will read a freed buffer and lead
to post empty, so we close all win before suspend, after resume vop will
display black until userspace set a new frame.
Change-Id: I6648861d2162f221e7fbf85d2361ad245e7b88aa
Signed-off-by: Huang Jiachai <hjc@rock-chips.com>
Since edp screen couple with another type of touchscreen,
so disable gt9xx to reduce i2c errors.
Change-Id: I829ae12039ecaea44c4e0734c18a5ebcd41845f8
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
This patch remove emmc node for rk3288-miniarm board.
because the new version of the hardware does not use emmc.
Change-Id: I72914a4e570342e5b0b559b3400e0a9db8aea7eb
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
regmap_write
->_regmap_raw_write
-->regcache_write first and than use map->bus->write to write i2c or spi
But if the i2c or spi transfer failed, But the cache is updated, So if I use
regmap_read will get the cache data which is not the real register value.
Change-Id: Iae06edf8a2a50d2561d351a8398bd3140904630c
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
commit 815806e39b)
there define two devfreq_event_get_drvdata() function in devfreq-event.h
when disable CONFIG_PM_DEVFREQ_EVENT, it will lead to build fail. So
remove devfreq_event_get_drvdata() function.
Change-Id: I273e91d4aac48ae25af5ef6de2feb37944cf6e39
Signed-off-by: Lin Huang <hl@rock-chips.com>
add clock flag parameter so we can pass specific clock flag
(like CLK_GET_RATE_NOCACHE etc..)to pll driver.
Change-Id: I1e076b3efa6b5da082b6e68e2e2a4c9dfd93e3d4
Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Lin Huang <hl@rock-chips.com>
According to the databook, the core soft reset should be done before
checking for AHBIDLE. The gadget version of core reset had it correct
but the hcd version did not. This fixes the hcd version.
Change-Id: I49540085036982e6c496a3b911805f0b67fa79e1
Signed-off-by: John Youn <johnyoun@synopsys.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(cherry picked from commit b8ccc593ee)
Calls to dwc2_core_reset() are currently very slow, taking at least
150ms (possibly more). It behooves us to take as many of these calls
out as possible.
It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init()
should (as documented in the code) only be needed if we need to do a PHY
SELECT. That means that if we see that we can avoid the PHY SELECT then
we can avoid the reset.
This patch appears to successfully bypass two resets (one per USB
device) on rk3288-based ARM Chromebooks.
Change-Id: If9f7275d61af6fd8558124ff9ebc7c3622c1f4a3
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(cherry picked from commit 7d56cc2620)
I found that the probe function of dwc2 driver takes much time
when kernel boot up. There are many long delays in the probe
function these take almost 1 second.
This patch trying to reduce unnecessary delay time.
In dwc2_core_reset() I see it use two at least 20ms delays to
wait AHB idle and core soft reset, but dwc2 data book said that
dwc2 core soft reset and AHB idle just need a few clocks (I think
it refers to AHB clock, and AHB clock run at 150MHz in my RK3288
board), so 20ms is too long, delay 1us for wait AHB idle and soft
reset is enough.
And in dwc2_get_hwparams() it takes 150ms to wait ForceHostMode
and ForceDeviceMode valid but in data book it said software must
wait at least 25ms before the change to take effect, so I reduce
this time to 25ms~50ms. By the way, is there any state bit show
that the force mode take effect ? Could we poll curmod bit for
figuring out if the change take effect ?
It seems that usleep_range() at boot time will pick the longest
value in the range. In dwc2_core_reset() there is a very long
delay takes 200ms, and this function run twice when probe, could
any one tell me is this delay time resonable ?
I have tried this patch in my RK3288-evb board. It works well.
Change-Id: I1f42ab6b6851f0721bf93d516bee895ebcdd994f
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(cherry picked from commit 20bde64343)
On some host-only DWC2 ports (like the one in rk3288) when we set
GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the
bit set. Presumably that's because the port is always forced to HOST
mode so there's no reason to implement these status bits.
Since we know dwc2_core_reset() is always called before
dwc2_get_hwparams() and we know dwc2_core_reset() should have set
GUSBCFG_FORCEHOSTMODE whenever hsotg->dr_mode == USB_DR_MODE_HOST, we
can just check hsotg->dr_mode to decide that we can skip the delays in
dwc2_get_hwparams().
Change-Id: I912ac2dd5e0ff3f8c12b8263ce268296bbed315f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(cherry picked from commit f619473140)
In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an
extra reset to the probe path for the dwc2 USB controllers. This
allowed proper detection of parameters even if the firmware had already
used the USB part.
Unfortunately, this extra reset is quite slow and is affecting boot
speed. We can avoid the double-reset by skipping the extra reset that
would happen just after the one we added. Logic that explains why this
is safe:
* As of the CL mentioned above, we now always call dwc2_core_reset() in
dwc2_driver_probe() before dwc2_hcd_init().
* The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're
guaranteed that dwc2_core_reset() was called before dwc2_hdc_init().
* dwc2_hdc_init() is the only caller that passes an irq other than -1 to
dwc2_core_init(). Thus if dwc2_core_init() is called with an irq
other than -1 we're guaranteed that dwc2_core_reset was called before
dwc2_core_init().
...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if
irq is not < 0.
Note that since "irq" wasn't used in the function dwc2_core_init()
anyway and since select_phy was always set at exactly the same times we
could avoid the reset, we remove "irq" and rename "select_phy" to
"initial_setup" and adjust the callers accordingly.
Change-Id: Id3b085ddc9d35baca140fc8a502fca74dcfd01b5
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(cherry picked from commit 0fe239bc19)
We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.
This patch could avoid warnning massage like in rk3288 platform:
[ 2.074764] dwc2 ff580000.usb: 256 invalid for
host_perio_tx_fifo_size. Check HW configuration.
Change-Id: Iab346c005c9f3ea940f4070f3e433e0c7ea89087
Signed-off-by: Yunzhi Li <lyz@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(cherry picked from commit cebfdbf329)
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it
back the way it was (specifically it set and cleared FORCEHOSTMODE).
Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we
should make sure dwc2_get_hwparams() isn't messing with things in a
permanent way.
Since we're now looking at GUSBCFG, it's obvious that we shouldn't need
all the extra delays if FORCEHOSTMODE was already set. This will avoid
some delays for any ports that have forced host mode.
Change-Id: I514aaaf77a7ee3f0871efb15e659b93b9717c5f1
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
(cherry picked from commit 991824677f)
This configure file is created for Linux Opensource project, and this
file is based on:
- arch/arm/configs/rockchip_linux_defconfig
Only have some light changes:
+ CONFIG_ARMV8_DEPRECATED=y
+ CONFIG_COMPAT=y
+ CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
+ CONFIG_CPU_IDLE=y
+ CONFIG_ARM_CPUIDLE=y
+ CONFIG_REGULATOR=y
+ CONFIG_REGULATOR_DEBUG=y
+ CONFIG_MMC_BLOCK_MINORS=32
+ CONFIG_MMC_SDHCI_OF_ARASAN=y
+ CONFIG_PHY_ROCKCHIP_EMMC=y
+ CONFIG_FIQ_DEBUGGER=y
+ CONFIG_FIQ_DEBUGGER_NO_SLEEP=y
+ CONFIG_FIQ_DEBUGGER_CONSOLE=y
+ CONFIG_FIQ_DEBUGGER_CONSOLE_DEFAULT_ENABLE=y
- CONFIG_RT2X00=y
- CONFIG_RT2800USB=y
- CONFIG_VIDEO_ROCKCHIP_VPU=y
- CONFIG_MALI400=y
- CONFIG_MALI_SHARED_INTERRUPTS=y
- CONFIG_MALI_DT=y
Change-Id: I4557ca060647c88fd2de2d1e736f9cb0048e3c9a
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Add Excavator board dts file for Linux Opensource project
Change-Id: I5e5375814d2a4cfa8ae613115b2cbced47cd56ab
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
The dw-hdmi-audio driver could only work on FB dw-hdmi driver, we can't
use it on DRM display sub-system. So I think it's better to disable the
dw-hdmi-audio by default for Sapphire board, but enable this device node
for excavator-edp and excavator-box boards.
Change-Id: I8c2639d535510f1092a3da02e008986394608998
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Backlight is the common device node, this would help to reduce
dumplicate code.
Change-Id: If0ee83f0bf929c242ec6dde3808a680f28e408ed
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
We observed the failure of initializing card after resume
accidentally. It's hard to reproduce but we did get report from
the suspend/resume test of our RK3399 mp test farm . Unfortunately,
we still fail to figure out what was going wrong at that time.
Also we can't achieve it by retrying the host->f_init without falling
back it. But this patch will solve the problem as we could add some log
there and see that we resume the mmc card successfully after falling
back the host->f_init. There is no obvious side effect found, so it seems
this patch will improve the stability.
[ 93.405085] mmc1: unexpected status 0x800900 after switch
[ 93.408474] mmc1: switch to bus width 1 failed
[ 93.408482] mmc1: mmc_select_hs200 failed, error -110
[ 93.408492] mmc1: error -110 during resume (card was removed?)
[ 93.408705] PM: resume of devices complete after 213.453 msecs
Change-Id: I5b24cb84a223394392450a1f10d8bbacb9e1006e
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
We will reuse it outside the core.c file, so let's
move it to the header file.
Change-Id: Ibc40268d104d503603d59911d71157fcee0e5196
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
wait_event_interruptible_timeout() will return early if the blocked
process receives a signal, causing the driver to abort the tuning
procedure and possibly leaving the controller in a bad state. Since the
tuning command is expected to complete quickly (<50ms) and we've set a
timeout, use wait_event_timeout() instead.
Change-Id: Ibd1c5e8076c5fde4b4e9c4ebb0a2733c8d2d4eda
Signed-off-by: Christopher Freeman <cfreeman@nvidia.com>
Tested-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
