Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Change-Id: I519527efaf88b1e5c1b30db1fd23e59d45b88d50
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry pick from 2c5b2cccdb)
A single blank line is enough to separate Kconfig entries.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Change-Id: I325951cc36a4429a8313b61e3f3a44aa24e49958
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry pick from dae91e4d1c)
For consistency with other drivers, use dashes instead of underscores in
filenames.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Change-Id: Ie872685143935c365b40c3aaf2a104879478ea66
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(cherry pick from 248a86fc30)
We don't use swiotlb, so keep the size as small as possible.
Change-Id: I1377f4b31112902a5841eafde094d2d12f48e97c
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
This allows monitoring external connectors by userspace
via sysfs and uevent and supports external connectors with
multiple states. And extcon notifier mechanism is also
useful.
Change-Id: I670da8efbe20f8f12529e9e062fc38b514524dc3
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
This allows monitoring external connectors by userspace
via sysfs and uevent and supports external connectors with
multiple states. And extcon notifier mechanism is also
useful.
Change-Id: I7aba50c294b04d48bf5d43bfd90a8280fcbd1081
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
If "CONFIG_ANDROID" and "CONFIG_SWITCH" are enabled,
/sys/class/switch/* are created in switch classe driver,
so we can't create switch class again in extcon.
Change-Id: Ida627cfdbb3ecb6f0aa40af146a66897edafd2fe
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
In less than 10 ms, the temperature of soc will arise 10 degree. 250 ms
is too big for soc tempeture control. Setting 2.5 ms will speed up
temperature accessing speed but introduce no more cpu's computing overhead.
We set AUTO_PERIOD_TIME and TSADCV3_AUTO_PERIOD_HT_TIME the same value,
because normal temperature update speed is also our consern in IPA.
Change-Id: Ie8038a1ae5837ad4aa31b04d1f3ace299f82e396
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
Big cores' power consumption is as much as 8 times of little cores'.
Eas tends to bring tasks to big cores to assure the performance, and
this will make the temperature of soc out of control. To resolve this
issue, we set the power request weight of both little cores and gpu is
10 times of big cores, when temperature control occurs. Meanwhile, we
decrease passive polling interval to make temperature control more
accurate.
Change-Id: Ib01948c6a4f4383f03f1317b2397f07fbdc3487e
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
Commit e22579713a ("ASoC: simple card: set cpu-dai sysclk
with mclk-fs") added sysclk / SND_SOC_CLOCK_OUT setting, that makes
asoc_simple_card_hw_params fail if the operation is not supported,
although the intention clearly was to ignore ENOTSUPP. Fix it.
The patch fixes audio playback on Kirkwood / OpenRD client,
where the following errors are seen:
asoc-simple-card sound: ASoC: machine hw_params failed: -524
alsa-lib: /alsa-lib-1.0.28/src/pcm/pcm_hw.c:327:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS failed (-524): Unknown error 524
Fixes: e22579713a ("ASoC: simple card: set cpu-dai sysclk with mclk-fs")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit git.kernel.org broonie/sound.git for-next
ee43a1a0cd)
Change-Id: I979297fa31aa065338804186ee35de948c63a6a4
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
LSK 16.06 v4.4-android
* tag 'lsk-v4.4-16.06-android': (447 commits)
Linux 4.4.14
netfilter: x_tables: introduce and use xt_copy_counters_from_user
netfilter: x_tables: do compat validation via translate_table
netfilter: x_tables: xt_compat_match_from_user doesn't need a retval
netfilter: ip6_tables: simplify translate_compat_table args
netfilter: ip_tables: simplify translate_compat_table args
netfilter: arp_tables: simplify translate_compat_table args
netfilter: x_tables: don't reject valid target size on some architectures
netfilter: x_tables: validate all offsets and sizes in a rule
netfilter: x_tables: check for bogus target offset
netfilter: x_tables: check standard target size too
netfilter: x_tables: add compat version of xt_check_entry_offsets
netfilter: x_tables: assert minimum target size
netfilter: x_tables: kill check_entry helper
netfilter: x_tables: add and use xt_check_entry_offsets
netfilter: x_tables: validate targets of jumps
netfilter: x_tables: don't move to non-existent next rule
drm/core: Do not preserve framebuffer on rmfb, v4.
crypto: qat - fix adf_ctl_drv.c:undefined reference to adf_init_pf_wq
netfilter: x_tables: fix unconditional helper
...
This reverts commit 857ad0187f.
Fixes by LSK commit b42fb9a710
("Revert "cpufreq: interactive: build fixes for 4.4"")
and commit de5723c8a6
("cpufreq: interactive: drop cpufreq_{get,put}_global_kobject func calls")
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
If mask is NULL skip the mask matching against the DMA device capabilities.
Change-Id: Iee44026c8d43493e4e73d8d483545267dc2e08a7
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from git.kernel.org next/linux-next.git master
commit 26b64256e0)
It would be better to name OPP nodes as opp@<opp-hz> as that will ensure
that multiple DT nodes don't contain the same frequency. Of course we
expect the writer to name the node with its opp-hz frequency and not any
other frequency.
And that will let the compile error out if multiple nodes are using the
same opp-hz frequency.
Change-Id: Icefba93f7a95752e344b5a092a83931bf4d1e682
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
This reverts commit b664a51a07.
Upstream commit f55d84b07c ("stmmac: do not sleep in atomic context for mdio_reset")
fixes this bug.
Change-Id: I7332b3586640667f551c7e83eafff560a4f5a478
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
stmmac_mdio_reset() has been updated to use msleep rather udelay
(as some PHY requires a one second delay there).
It called from stmmac_resume() within the spin_lock_irqsave block
atomic context triggering 'scheduling while atomic'.
The stmmac_priv lock usage is not fully documented, but it seems
to protect the access to the MAC registers / DMA structures rather
than the MDIO bus or the PHY (which have separate locking),
so we can push the spin_lock after the stmmac_mdio_reset call.
Change-Id: I0e8a0f7e798f89678d59eefdfd251f217c00787e
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit f55d84b07c)
Otherwise, clk_gpu won't be disabled actually in the runtime.
Change-Id: If1e32061cbffc1564a5cf95fbf01aa91c827550d
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
When the input color format is YUV, we need to do some external scale
for CBCR. Like,
* In YUV420 data format:
cbcr_xscale = dst_w / src_w * 2;
cbcr_yscale = dst_h / src_h * 2;
* In YUV422 data format:
cbcr_xscale = dst_w / src_w * 2;
cbcr_yscale = dst_h / src_h;
* In YUV444 data format
cbcr_xscale = dst_w / src_w;
cbcr_yscale = dst_h / src_h;
Change-Id: I08678fdcc13a5c4055fcc46f20b378ad7fa16761
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9157353/)
The WIN0 of RK3036 VOP could support YUV data format, but driver
forget to add the uv_vir register field for it.
Change-Id: I1fd6be43308468cf0718b113be74d2170f71eebe
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9157349/)
The dw_mmc driver stores the physical address of the MMIO registers
in a pointer, which requires the use of type casts, and is actually
broken if anyone ever has this device on a 32-bit SoC in registers
above 4GB. Gcc warns about this possibility when the driver is built
with ARM LPAE enabled:
mmc/host/dw_mmc.c: In function 'dw_mci_edmac_start_dma':
mmc/host/dw_mmc.c:702:17: warning: cast from pointer to integer of different size
cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);
^
mmc/host/dw_mmc-pltfm.c: In function 'dw_mci_pltfm_register':
mmc/host/dw_mmc-pltfm.c:63:19: warning: cast to pointer from integer of different size
host->phy_regs = (void *)(regs->start);
This changes the code to use resource_size_t, which gets rid of the
warning, the bug and the useless casts.
Change-Id: I894c49cede8f0626efb80a9a3181a5385bbb2bcd
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 260b316436)
We must preserve the same order of how we acquire and release the lock for
genpd, as otherwise we may encounter deadlocks.
The power on phase of a genpd starts by acquiring its lock. Then it walks
the hierarchy of its parent domains to be able to power on these first, as
per design of genpd.
From a locking perspective this means the locks of the parents becomes
acquired after the lock of the subdomain.
Let's fix pm_genpd_add|remove_subdomain() to maintain the same order of
acquiring/releasing the genpd lock as being applied in the power on/off
sequence.
Change-Id: I7f56875b7620eee6247efecd502a3ada4bfa4e24
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit cdb300a041)
During genpd_poweron, genpd->lock is acquired recursively for each
parent (master) domain, which are separate objects. This confuses
lockdep, which considers every operation on genpd->lock as being done on
the same lock class. This leads to the following false positive warning:
=============================================
[ INFO: possible recursive locking detected ]
4.4.0-rc4-xu3s #32 Not tainted
---------------------------------------------
swapper/0/1 is trying to acquire lock:
(&genpd->lock){+.+...}, at: [<c0361550>] __genpd_poweron+0x64/0x108
but task is already holding lock:
(&genpd->lock){+.+...}, at: [<c0361af8>] genpd_dev_pm_attach+0x168/0x1b8
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&genpd->lock);
lock(&genpd->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by swapper/0/1:
#0: (&dev->mutex){......}, at: [<c0350910>] __driver_attach+0x48/0x98
#1: (&dev->mutex){......}, at: [<c0350920>] __driver_attach+0x58/0x98
#2: (&genpd->lock){+.+...}, at: [<c0361af8>] genpd_dev_pm_attach+0x168/0x1b8
stack backtrace:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c0016c98>] (unwind_backtrace) from [<c00139c4>] (show_stack+0x10/0x14)
[<c00139c4>] (show_stack) from [<c0270df0>] (dump_stack+0x84/0xc4)
[<c0270df0>] (dump_stack) from [<c00780b8>] (__lock_acquire+0x1f88/0x215c)
[<c00780b8>] (__lock_acquire) from [<c007886c>] (lock_acquire+0xa4/0xd0)
[<c007886c>] (lock_acquire) from [<c0641f2c>] (mutex_lock_nested+0x70/0x4d4)
[<c0641f2c>] (mutex_lock_nested) from [<c0361550>] (__genpd_poweron+0x64/0x108)
[<c0361550>] (__genpd_poweron) from [<c0361b00>] (genpd_dev_pm_attach+0x170/0x1b8)
[<c0361b00>] (genpd_dev_pm_attach) from [<c03520a8>] (platform_drv_probe+0x2c/0xac)
[<c03520a8>] (platform_drv_probe) from [<c03507d4>] (driver_probe_device+0x208/0x2fc)
[<c03507d4>] (driver_probe_device) from [<c035095c>] (__driver_attach+0x94/0x98)
[<c035095c>] (__driver_attach) from [<c034ec14>] (bus_for_each_dev+0x68/0x9c)
[<c034ec14>] (bus_for_each_dev) from [<c034fec8>] (bus_add_driver+0x1a0/0x218)
[<c034fec8>] (bus_add_driver) from [<c035115c>] (driver_register+0x78/0xf8)
[<c035115c>] (driver_register) from [<c0338488>] (exynos_drm_register_drivers+0x28/0x74)
[<c0338488>] (exynos_drm_register_drivers) from [<c0338594>] (exynos_drm_init+0x6c/0xc4)
[<c0338594>] (exynos_drm_init) from [<c00097f4>] (do_one_initcall+0x90/0x1dc)
[<c00097f4>] (do_one_initcall) from [<c0895e08>] (kernel_init_freeable+0x158/0x1f8)
[<c0895e08>] (kernel_init_freeable) from [<c063ecac>] (kernel_init+0x8/0xe8)
[<c063ecac>] (kernel_init) from [<c000f7d0>] (ret_from_fork+0x14/0x24)
This patch replaces mutex_lock with mutex_lock_nested() and uses
recursion depth to annotate each genpd->lock operation with separate
lockdep subclass.
Change-Id: I9b94b2a571f906ea9e5300abc6f40db343af49e3
Reported-by: Anand Moon <linux.amoon@gmail.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from commit 0106ef5146)
Return -EINVAL would cause mipi dsi bad behavior, probe defer
to ensure mipi find the correct mode,
Change-Id: I0bb8e97dd6bd19f66052b4e985e95d8d82faf29b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
HardWare limited, the bottom layer not support per-pixel alpha,
Change-Id: I174da1d3d3cfff8d0b6cd6dfab4873438895e56d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
