the OTG_SWITCH supply OTG, it doesn't need to be on When the driver initializes.
Signed-off-by: shengfei Xu <xsf@rock-chips.com>
Change-Id: I44f4fa618f66f18fa552353c425c7baa6831ab0c
stack frame size of 4416 bytes in function 'atags_to_fdt'
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I07d22e8ca0006b8797a0cfaf42d93e46fdd4ee5c
Some clk gates on Rockchip SoCs are part of the SGRF (secure general
register files) and thus only controllable from secure mode, with the
most prominent example being the watchdog.
In most cases we still want to define this as a real clock though,
to have complete clock tree and not reference the generic base-clock
from the devicetree.
So far we've just defined this as factor-1-1 clocks in the clock init,
so define a special clock-type for it so that this definition can be
part of the general tree-definition and save some boilerplate code.
Change-Id: I19ba9125781812dccb5703a9d914253ef54de7c5
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
(cherry picked from commit b3b723d8c4)
There is not need to set dev name without address.
Fixes: 76f27bdd76 ("drm: bridge: dw-hdmi: using extcon instead of switch")
Change-Id: I2c23e29ad8f7b4a0b05b2237ae319e14c69a1cb1
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
caused a bootup regression due to lack of entropy at bootup together
with arguably broken user space that was asking for secure random
numbers when it really didn't need to.
See commit 72dbcf7215 (Revert "ext4: make __ext4_get_inode_loc plug").
This aims to solve the issue by actively generating entropy noise using
the CPU cycle counter when waiting for the random number generator to
initialize. This only works when you have a high-frequency time stamp
counter available, but that's the case on all modern x86 CPU's, and on
most other modern CPU's too.
What we do is to generate jitter entropy from the CPU cycle counter
under a somewhat complex load: calling the scheduler while also
guaranteeing a certain amount of timing noise by also triggering a
timer.
I'm sure we can tweak this, and that people will want to look at other
alternatives, but there's been a number of papers written on jitter
entropy, and this should really be fairly conservative by crediting one
bit of entropy for every timer-induced jump in the cycle counter. Not
because the timer itself would be all that unpredictable, but because
the interaction between the timer and the loop is going to be.
Even if (and perhaps particularly if) the timer actually happens on
another CPU, the cacheline interaction between the loop that reads the
cycle counter and the timer itself firing is going to add perturbations
to the cycle counter values that get mixed into the entropy pool.
As Thomas pointed out, with a modern out-of-order CPU, even quite simple
loops show a fair amount of hard-to-predict timing variability even in
the absense of external interrupts. But this tries to take that further
by actually having a fairly complex interaction.
This is not going to solve the entropy issue for architectures that have
no CPU cycle counter, but it's not clear how (and if) that is solvable,
and the hardware in question is largely starting to be irrelevant. And
by doing this we can at least avoid some of the even more contentious
approaches (like making the entropy waiting time out in order to avoid
the possibly unbounded waiting).
Change-Id: I77f527785e5d3fa90c14c8887201c2c0ae8b85db
Cc: Ahmed Darwish <darwish.07@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Nicholas Mc Guire <hofrat@opentech.at>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 50ee7529ec)
Base the Change-Id: I14ae67d0bfa76d2581eebae100ebf6bad15f8614
One task attach once instead of each fd translate.
Change-Id: I158ef1ee32f9e7a62dc45de3f25de4decee8c112
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
The current driver set CC pull up current to 180uA, but FUSB302B was
designed with 80uA for sink detection which means it only guarantee
FUSB302B will works well with that setting. So we change the CC pull
up current to 80uA.
Change-Id: I5bcb0caaffafbcdf7972396b64f296606bbf3986
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
We found that the Type-C OTG cable was plugged in while the system
was suspending, it may fail to detect the Type-C OTG cable after
resume. That's because the fusb302 registers will fail to operate
during suspend, this will cause the fusb302 CC logic to be abnormal.
So we should not operate queue_work function while the suspend.
Change-Id: Idc675c25de5452ec39513eb484cfaa75534790cd
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
4.19 kernel will check mode valid before encoder atomic check
when resolution switch. Because when checking mode the
detailed color format and color depth are not considered, some
mode can be mistaken for unsupported, such as 4K-60HZ YUV420 10 bits.
So bus width should be set 8 bits when check mode valid.
Change-Id: I0869868b73060bc0f539243d7fccb6c775141ec4
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
some broadcom bt chip need bt host wake is high level when power on,
like ap6356
Change-Id: I509268b84d22b8c17a0996cdd3b2c3e4e05af1bb
Signed-off-by: Weiguo Hu <hwg@rock-chips.com>
The div offset of some clocks are different from their mux offset
and the COMPOSITE clock-type require that div and mux offset are
the same, so add a new COMPOSITE_DIV_OFFSET clock-type to handle
that.
Change-Id: I1c97f7464c3c80ea6dbd7d4052565dd4e35c0931
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Avoid clang warning:
s/select.c:594:5: warning: stack frame size of 1056 bytes in function 'core_sys_select' [-Wframe-larger-than=]
int core_sys_select(int n, fd_set __user *inp, fd_set __user *outp,
^
net/core/ethtool.c:2628:5: warning: stack frame size of 1216 bytes in function 'dev_ethtool' [-Wframe-larger-than=]
int dev_ethtool(struct net *net, struct ifreq *ifr)
^
Change-Id: Id2d961993e9823fe74854d33cd24d28869a541ef
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
drivers/net/wireless/rockchip_wlan/rtl8723cs/os_dep/linux/ioctl_cfg80211.c:3876:20: warning: implicit conversion from enumeration type 'enum mlme_auth_type' to different enumeration type 'enum nl80211_auth_type' [-Wenum-conversion]
sme->auth_type = MLME_AUTHTYPE_SAE;
~ ^~~~~~~~~~~~~~~~~
MLME_AUTHTYPE_SAE == NL80211_AUTHTYPE_SAE, so this fix is safe.
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: Ia3fc1afc6375cc86168c0d9a744e0817df9614c7
drivers/net/wireless/rockchip_wlan/rtl8723cs/os_dep/linux/rtw_cfgvendor.c:177:25: warning: implicit conversion from 'unsigned int' to 'u16' (aka 'unsigned short') changes value from 4718624 to 32 [-Wconstant-conversion]
kflags = in_atomic() ? GFP_ATOMIC : GFP_KERNEL;
~ ^~~~~~~~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I2ade593775f56ef2276ff9e13aed5c0bb70132d6
drivers/net/wireless/rockchip_wlan/rtl8822bs/os_dep/linux/rtw_cfgvendor.c:177:25: warning: implicit conversion from 'unsigned int' to 'u16' (aka 'unsigned short') changes value from 4718624 to 32 [-Wconstant-conversion]
kflags = in_atomic() ? GFP_ATOMIC : GFP_KERNEL;
~ ^~~~~~~~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I4b648f20f665f563d7af7130d983918ff4889100
drivers/video/rockchip/rga2/rga2_mmu_info.c:326:20: warning: explicitly assigning value of variable of type 'uint32_t' (aka 'unsigned int') to itself [-Wself-assign]
stride = stride;
~~~~~~ ^ ~~~~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I8143bbe53f4e106c6b875e2db562d11240d7de34
on arm32-arch, domain stored in mapping created by arm32-arch,
we need to re-attach when master start to work
Change-Id: I14ae67d0bfa76d2581eebae100ebf6bad15f8614
Signed-off-by: Simon Xue <xxm@rock-chips.com>
1. select ARM_DMA_USE_IOMMU only ARM32
2. fix iova hole
__alloc_iova will return un-continuous va if align non-zero
3. don't break iommu_attach_device
iommu_attach_device will break if iommu shared by two or more
masters
Change-Id: Ifd1c652341e2270bfde57ebe1e0cd00d51d38eec
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Disable it default, because we found it is unstable when using
some ddr chip.
Change-Id: Iffd98a0f5ab9c9256ec9a1450ce105a5b7f6127b
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
This patch adds Kconfig option for i2s-tdm controller
Change-Id: I428e311402220ff14441c48e13fa51356ced46e8
Signed-off-by: Fenrir Lin <fenrir.lin@rock-chips.com>
This patch adds Kconfig for multicodecs machine driver.
Change-Id: I77d3e9c10d03c2b8809c6d82b5268dba279ee6f0
Signed-off-by: Fenrir Lin <fenrir.lin@rock-chips.com>
If the power domain of iommu is not change, it will be
return when iommu attach. So there must refresh pm_runtime
for iommu really attach.
Change-Id: I0c8443bd7b9c640c24c23af1693261930144674b
Signed-off-by: Grey Li <grey.li@rock-chips.com>
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
When alloc task failed, it must return NULL instead of the PTR_ERR.
Change-Id: I309e934badd0c88a66beccbb8f03096f1eb91745
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
