when used the arm-linux-gnueabihf-gcc-7.2.1, had the below
warning information:
1) drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/siutils.c:607:14:
warning: self-comparison always evaluates to false
[-Wtautological-compare]
2) drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/dhd_common.c:3583:16:
warning: comparison between pointer and zero character constant
[-Wpointer-compare] error, forbidden warning: dhd_common.c:3583
Change-Id: Ida287252b7f20b17b68365b965edbff63ae7cbf9
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
The reboot bootloader flag has been written in misc,
do not need to write in the register
Change-Id: I161b94d554c3a0cb21f6d85b981a247aa1b110ff
Signed-off-by: Yankun Zheng <zyk@rock-chips.com>
when used the arm-linux-gnueabihf-gcc-7.2.1, had the below
warning information:
net/rfkill/rfkill-bt.c:711:5: warning: this ‘if’ clause does not
guard... [-Wmisleading-indentation] error, forbidden warning
Change-Id: I7834078bb731e1115f6e8328a56158b0d9f2991e
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Add "assigned-clocks" for rk3126 and rk3128 cru nodes, to intalize
clock rate for plls, bus and peripher.
Change-Id: Ie91c8b194feff5db91af6e9930d5f475175242f9
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
rk previous SOCs such as rk3126 have no tsadc module, so a virtual tsadc is
implemented to control the thermal problem.
the virtual tsadc is designed on considering 2 factors, one is heating
modules' heating time and the working frequences, the other one is current
leval monitored by coulometer.
Change-Id: I0c7d8b952004d4f7918a41c925c50d38aaa65673
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
userspace can control all leds by one ioctl through file node:
/dev/led_multi_ctrl.
Change-Id: I10ac19b86b46b3dc9a88809f1be5ebc95398212c
Signed-off-by: Wenping Zhang <wenping.zhang@rock-chips.com>
1. fix cpu stall issue during reboot:
In previous code, i2c write and read is executed in function
is31fl32xx_brightness_set,this function may be called in softirq
context if leds are in timer or oneshot trigger, so there are
possibilities cpu will be stalled during led operations.
Here we just move the i2c operation to workqueue to make sure
not in irq context.
2. fix reboot crash issue.
Change-Id: If8520528b092cf4d5c4f1c7dcf2d353acd1c9b9d
Signed-off-by: Wenping Zhang <wenping.zhang@rock-chips.com>
This function is used for led scrolling, set "default-trigger-delay-ms"
in led dts node to enable this function.
Change-Id: I4dff3ab29d8ef18344df4c3a0f18a595a404154c
Signed-off-by: Wenping Zhang <wenping.zhang@rock-chips.com>
According to HDMI 2.0 chapter 6.1, for TMDS character Rates
avove 340Mcsc, the TMDS Clock Rate shall be one fourth of
the TMDS Character Rate.
Change-Id: I4cc78aa1a5fbf6cec93e787dde49e482d0b4d342
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
The is32fl32xx led driver from upstream is written for new led
framework, so just modify this driver for some api difference
between our current led framework.
Change-Id: I0fd9af4bc2cd419d3e0bcd1b2348d34d166d652b
Signed-off-by: Wenping Zhang <wenping.zhang@rock-chips.com>
This driver is modified to support PX30 SoC.
Change-Id: I0226327d6d63302627a823bf73a5f8239b70adaf
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
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>
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>