The secondary CPU starts up in ARM mode. When the kernel is compiled in
thumb2 mode we have to explicitly compile the secondary startup
trampoline in ARM mode.
Change-Id: I52d2167ab4c4e1da5ac1a800390ab04ba724dd72
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: If9635a5933d7addea8522ce3b9259faa5b455008
Reported-by: Andreas Ziegler <andreas.ziegler@fau.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit f458e6102c)
Commit 2cbbb579bc ("regmap: Add the LZO cache support") added support
for LZO compression in regcache, but there were never any users added
afterwards. Since LZO support itself has its own size, it currently is
rather a deoptimization.
So make it optional by introducing a symbol that can be selected by
drivers wanting to make use of it.
Saves e.g. ~46 kB on MIPS (size of LZO support + regcache LZO code).
Change-Id: I38a5164c2169f889a10f6c47968c1dbd187c6725
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 34a730aa74)
Fixes: 580ad3d371 ("rockchip: pm: add deep sleep support for rk3288")
Change-Id: I8034cd47f289f51b21c47ee8f68ee1ae125026e7
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
3399 ISP power management is wrong, correct it.
Change-Id: I6aa4e7a0dd941ec9ff02467c0e1e6b15f1771a2b
Signed-off-by: Zhang Yunlong <dalon.zhang@rock-chips.com>
If color depth is automatic, it is same as 8bit.
If tmdsclk > max_tmds_clock, fall back to 8bit.
Change-Id: Ia8cbf5206831ef99456ae59add94c6f8b5a33380
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Rockchip requires bo-pages to be in the DMA32 zone. Explicitly request this
by setting __GFP_DMA32 as mapping-gfp-mask during shmem initialization.
This drops HIGHMEM from the gfp-mask and uses DMA32 instead. shmem-core
takes care to relocate pages during swap-in in case they have been loaded
into the wrong zone.
It is _not_ possible to pass __GFP_DMA32 to shmem_read_mapping_page_gfp()
as the page might have already been swapped-in at that time. The zone-mask
must be set during initialization and be kept constant for now.
Change-Id: I6db4f9e8ed716a1f7c90c7d92920122a484bf45d
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
ARM32 system can run without trustos,
we should prevent arm_smccc_smc being called in such system.
Change-Id: Ic87b78107b464e3ab8dc72a3ca1fa9a64e358580
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
According to DWC2 datasheet, the reset value of NPTxFDep in GNPTXFSIZ
register is OTG_TX_HNPERIO_DFIFO_DEPTH parameter,it specifies the Maximum
Non-Periodic TxFIFO depth and the memory allocation for the host when the
controller is in host mode. Software init host_nperio_tx_fifo_size with
the value of NPTxFDep during dwc2 probe.
But in some platform such as rk3126c, it must delay at least 100ms to wait
the controller change to host mode, it will increase usb controller probe
time, this patch modifies the host nperio_tx_fifo_size directly after valiate
parameter to speed up boot kernel.
Change-Id: Ia7d0f4f2cc1d80742d764807a8ee44cbc03c43ce
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
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>
