fix the pinctrl default state is repeatedly defined
between rk3229-at-gva.dts and rk3229-at-som.dtsi
Change-Id: I117b3d97d446899ad7f35234df7c8dc0da60634e
Signed-off-by: Yankun Zheng <zyk@rock-chips.com>
Bind / unbind stress testing of the USB controller on rk3399 found
that we'd often end up with lots of failures that looked like this:
phy phy-ff800000.phy.9: phy poweron failed --> -110
dwc3 fe900000.dwc3: failed to initialize core
dwc3: probe of fe900000.dwc3 failed with error -110
Those errors were sometimes seen at bootup too, in which case USB
peripherals wouldn't work until unplugged and re-plugged in.
I spent some time trying to figure out why the PHY was failing to
power on but I wasn't able to. Possibly this has to do with the fact
that the PHY docs say that the USB controller "needs to be held in
reset to hold pipe power state in P2 before initializing the Type C
PHY" but that doesn't appear to be easy to do with the dwc3 driver
today. Messing around with the ordering of the reset vs. the PHY
initialization in the dwc3 driver didn't seem to fix things.
I did, however, find that if I simply retry the power on it seems to
have a good chance of working. So let's add some retries. I ran a
pretty tight bind/unbind loop overnight. When I did so, I found that
I need to retry between 1% and 2% of the time. Overnight I found only
a small handful of times where I needed 2 retries. I never found a
case where I needed 3 retries.
I'm completely aware of the fact that this is quite an ugly hack and I
wish I didn't have to resort to it, but I have no other real idea how
to make this hardware reliable. If Rockchip in the future can come up
with a solution we can always revert this hack. Until then, let's at
least have something that works.
This patch is tested atop Enric's latest dwc3 patch series ending at:
https://patchwork.kernel.org/patch/10095527/
...but it could be applied independently of that series without any
bad effects.
For some more details on this bug, you can refer to:
https://bugs.chromium.org/p/chromium/issues/detail?id=783464
Change-Id: I7909731247739694f56bf89ab3064889f2b34d3c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(am from https://patchwork.kernel.org/patch/10105833/)
The ahbcfg of dwc2_core_params can be used to overwrite
the default value of the GAHBCFG register. But the current
code don't use this parameter for dwc2 gadget, and always
set the burst length of GAHBCFG to INCR4. This patch sets
the the burst length of GAHBCFG to INCR4 only if ahbcfg is
-1, otherwise, overwrite the GAHBCFG with the ahbcfg value.
Change-Id: I78ed8f797a4b94b34f610789ee3bd61bcc8ed985
Signed-off-by: William Wu <william.wu@rock-chips.com>
RK3368/RK3399 mpll input clock rate is twice of mpll output
in YCBCR420 mode. This patch introduce mpll_cfg_420 to get
the platform YCBCR420 phy setting. If mpll_cfg_420 is not
exist, use mpll_cfg.
Change-Id: I7910a75394cf371a8008f8a83e3ab9ec14e9a68a
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
The configured value sets H13T PHY PLL to multiply pixel clock by the
factor in order to obtain the desired repetition clock. For the CEA
modes some are already defined with pixel repetition in the input video.
So for CEA modes this shall be always 0.
Change-Id: Iea4a00247f25c134dbd67ba77c00eb4393622385
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
To avoid screen flash when updating CSC, we introduce connector
atomic_begin. Before flush crtc and connector, it's need to send
AVMUTE flag to make screen black, and clear flag after CSC updated.
AVMUTE -> Update CRTC -> Update HDMI -> Clear AVMUTE
Change-Id: Id47caac1e25fcce5a5aa7b879da4a6b9a9bab8a1
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
atomic_begin is used to prepare for update flush.
Change-Id: I1d3a2afaea4022c065bda2b4c0746464cc0c1303
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
1.vepu need core_clk define
2.there is no ION_HEAP function,replace it with the same definition
Change-Id: I7cf02c9e446976f0424d9489e081c9614b7e7e0c
Signed-off-by: Xinhuang Li <buluess.li@rock-chips.com>
1.vepu aclk is ACLK_H264 and hclk is HCLK_H264
2.vepu need clk_core clk define
3.add h264&h265 power domain
Change-Id: I419e544cf86d90b2b8d88dd13dfed49d31a24991
Signed-off-by: Xinhuang Li <buluess.li@rock-chips.com>
To support HDMI 4K output, hdmi connect to vopb by default.
Change-Id: I7cc184a7399954e47b4f44d02769fd43263e549b
Signed-off-by: Jerry Xu <xbl@rock-chips.com>
Accdording to CTS test result, for tmds clk rate above 140M,
RK3036 pre-emphasis should be 6 and driver is 0xb.
Change-Id: I7d4fed308a200eb4da4af1514c34c0501f551126
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Accroding to CTA-861, a Source shall set scan_mode = 1 or
scan_mode = 2 if it is confident of the accuracy of those
values. Otherwise, it shall set zero(no data).
By default, an SD Video Format shall be encoded according
to SMPTE 170M [1] color space, an HD Video Format shall be
encoded according to ITU-R BT.709 [7] color space. And a
Source shall be prohibited from setting colorimetry to 1 or
2 when colorspace is RGB.
Change-Id: I0da867cca5b757b3abcac69ff71616f990f2b7bb
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
According to HDMI CTS 7-31, audio sample width and frequency
should be zero.
Change-Id: Ida37483e3f58e152e6a1c55d8bb81d0e9e0fb2ed
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
RK3036 use grf register to set HSYNC/VSYNC polarity,
and fix hdelay and vdelay setting.
Change-Id: I3146a0a146b09f64c1d875642589d0f1dc6f27df
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Before adjusting voltage, increase clk_cpu div and reduce CPU frequency
Only support for RK312x chips.
Change-Id: Id327da9590f7d9d383450e79acd1b309e05cd024
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: shengfei Xu <xsf@rock-chips.com>
According to the SDIO standard interrupts are normally signalled in a
very complicated way. They require the card clock to be running and
require the controller to be paying close attention to the signals
coming from the card. This simply can't happen with the clock stopped
or with the controller in a low power mode.
To that end, we'll disable runtime_pm when we detect that an SDIO card
was inserted. This is much like with what we do with the special
"SDMMC_CLKEN_LOW_PWR" bit that dw_mmc supports.
NOTE: we specifically do this Runtime PM disabling at card init time
rather than in the enable_sdio_irq() callback. This is _different_
than how SDHCI does it. Why do we do it differently?
- Unlike SDHCI, dw_mmc uses the standard sdio_irq code in Linux (AKA
dw_mmc doesn't set MMC_CAP2_SDIO_IRQ_NOTHREAD).
- Because we use the standard sdio_irq code:
- We see a constant stream of enable_sdio_irq(0) and
enable_sdio_irq(1) calls. This is because the standard code
disables interrupts while processing and re-enables them after.
- While interrupts are disabled, there's technically a period where
we could get runtime disabled while processing interrupts.
- If we are runtime disabled while processing interrupts, we'll
reset the controller at resume time (see dw_mci_runtime_resume),
which seems like a terrible idea because we could possibly have
another interrupt pending.
To fix the above isues we'd want to put something in the standard
sdio_irq code that makes sure to call pm_runtime get/put when
interrupts are being actively being processed. That's possible to do,
but it seems like a more complicated mechanism when we really just
want the runtime pm disabled always for SDIO cards given that all the
other bits needed to get Runtime PM vs. SDIO just aren't there.
NOTE: at some point in time someone might come up with a fancy way to
do SDIO interrupts and still allow (some) amount of runtime PM.
Technically we could turn off the card clock if we used an alternate
way of signaling SDIO interrupts (and out of band interrupt is one way
to do this). We probably wouldn't actually want to fully runtime
suspend in this case though--at least not with the current
dw_mci_runtime_resume() which basically fully resets the controller at
resume time.
Change-Id: I29a687b2342b9cb921aad133a538689a8f7d9262
Fixes: e9ed8835e9 ("mmc: dw_mmc: add runtime PM callback")
Cc: <stable@vger.kernel.org>
Reported-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
This file is not used anymore, and the current driver
for rtc of the rk808 is rtc-rk808.c
Change-Id: I2e21f56c0a24af9452bc113c28f25a8eaec096f0
Signed-off-by: Randy Li <randy.li@rock-chips.com>
read MRV_MIPI_FRAME register in camsys_mrv_irq, and pass the
value fs_id and fe_id into isp library.
Change-Id: I98c43f1cac25c74c5058b90dbf25937ceb924f84
Signed-off-by: Wen Dingxian <shawn.wen@rock-chips.com>
Add the clock tree definition for the new px30 SoC.
Fix up the pll setting to support px30 SoC.
Change-Id: Ib9255094b0fdb58f0a8ba49c5bb9f075c7458940
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Add the dt-bindings header for the px30, that gets shared between
the clock controller and the clock references in the dts.
Add softreset ID for px30.
Change-Id: I643f5e40cf77fb5c3aeb41392172da79194d54c1
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.
Change-Id: I7f1c862012ce43bfaa1c44c5f44e89354eca5099
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
This adds the necessary data for handling io voltage domains on the px30.
As interesting tidbit, the px30 contains two separate iodomain areas.
One in the regular General Register Files (GRF) and one in PMUGRF in the
pmu power domain.
Change-Id: Icff058b310e8ffaa4e03b8090443b3a7dba35f1f
Signed-off-by: David Wu <david.wu@rock-chips.com>
The bank0 of px30 pinctrl is in the pmugrf, other banks are in
the grf, the bank1 ~ bank3 are 4-bit width's iomux.
Change-Id: I62cbd74105b6874a9a91f3ab6a7623990205edce
Signed-off-by: David Wu <david.wu@rock-chips.com>
NORMAL zone limits at 0x90000000.
The device cma region which is used by camera should be set to
NORMAL zone to avold memory fragment.
The device cma region info:
[ 0.000000] Reserved memory: created CMA memory pool at 0x88000000, size 24 MiB
[ 0.000000] Reserved memory: initialized node region@8f000000, compatible id shared-dma-pool
The default cma region info:
[ 0.000000] cma: Reserved 16 MiB at 0x9f000000
Change-Id: I8b1a099c5fa3a2d90acf709c4272d88b97e0c5bd
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
This stub pin node would prevent the whole pinctrl driver
being loading. Then any board files include the common
rk3399 linux would meet the power failure.
Change-Id: Ib223eb517c879b3819e9d8da4c0d5750886897c6
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Fixing the sequence of events in dwc3_core_init() error exit path.
dwc3_core_exit() call is also removed from the error path since,
whatever it's doing is already done.
Change-Id: I71f6aab189df0e5223d490fb6eaeebe1481a6b65
Fixes: c499ff7 usb: dwc3: core: re-factor init and exit paths
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Stable <stable@vger.kernel.org> # 4.8+
Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit 9b9d7cdd0a)
The current limit is small for Android Things Verity Boot args.
Bump it.
Change-Id: I091c7f6d4912fec57ecca7dcab38cc99c5b6dfb5
Signed-off-by: Cody Xie <cody.xie@rock-chips.com>
The default parent of i2s_src is 200MHz CPLL, it doesn't meet
the constraint of fractional divider that denominator must be
20 times larger than numerator.
Change-Id: I986525ca7a92cb5883facd1b6e89079398302856
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
