Use dclk to adjust fps may effect many things, some display
controller also need to know dclk update, such as mipi.
So if we change fps by dclk, we need update mipi or other
display controller, it waste time and screen would flash
From the fps formula: fps = dclk / htotal * vtotal
Instead change dclk, we also can modify fps by htotal or vtotal.
On testing, vtotal would effect display, use htotal is more safe.
Change-Id: I67d58a815eae150b4e6390b6608557b87d43a27b
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Vop may access illegal address and cause bus error with:
1, vop iommu is disable
2, vop is enable and its window use a iommu mapping address
The illegal memory access may cause bus abnormal.
Change-Id: I17d52ae12140b9bf85d37123765f7163422ec8f5
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
The tcpc power domain will try to power up/down the power of Type-C PHY.
Hence, we need control it in Type-C PHY driver with the pm_runtime helper.
Change-Id: I7697c50bb8538c00bb0fa14c92cc1e55bcdd4025
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
(cherry picked from git.kernel.org next/linux-next.git master
commit 06ad4b2fad)
Adds pm_runtime support for rockchip Type-C, so that power domain is
enabled only when there is a transaction going on to help save power.
BUG=chrome-os-partner:52872
TEST=Check DP display and USB3
Change-Id: I072fd06eaa4dfc4b4f598c4a6a3972ee458b833f
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
(cherry picked from git.kernel.org kishon/linux-phy.git next
commit 15ab5499bd837b1d70287da747dc3d9762ab320a)
Reviewed-on: https://chromium-review.googlesource.com/382113
Reviewed-by: Brian Norris <briannorris@chromium.org>
Vikram reported that his ARM64 compiler managed to 'optimize' away the
preempt_count manipulations in code like:
preempt_enable_no_resched();
put_user();
preempt_disable();
Irrespective of that fact that that is horrible code that should be
fixed for many reasons, it does highlight a deficiency in the generic
preempt_count manipulators. As it is never right to combine/elide
preempt_count manipulations like this.
Therefore sprinkle some volatile in the two generic accessors to
ensure the compiler is aware of the fact that the preempt_count is
observed outside of the regular program-order view and thus cannot be
optimized away like this.
x86; the only arch not using the generic code is not affected as we
do all this in asm in order to use the segment base per-cpu stuff.
Change-Id: I13da06ddb17c533b8150f008514a4c74723b1742
Reported-by: Vikram Mulukutla <markivx@codeaurora.org>
Tested-by: Vikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: a787870924 ("sched, arch: Create asm/preempt.h")
Link: http://lkml.kernel.org/r/20160516131751.GH3205@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 2e636d5e66)
df9e01a6c5 ("android-recommended.cfg: enable fstack-protector-strong")
If compiler has stack protector support, set
CONFIG_CC_STACKPROTECTOR_STRONG.
Change-Id: Icd3535b88fb7d62c135da72ae0921f7f4949efe4
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
The D state of wait_on_all_pages_writeback should be waken by
function f2fs_write_end_io when all writeback pages have been
succesfully written to device. It's possible that wake_up comes
between get_pages and io_schedule. Maybe in this case it will
lost wake_up and still in D state even if all pages have been
write back to device, and finally, the whole system will be into
the hungtask state.
if (!get_pages(sbi, F2FS_WRITEBACK))
break;
<--------- wake_up
io_schedule();
Change-Id: I8a60393c91343d75b7d48df2ca19d1735d69cc51
Signed-off-by: Yunlei He <heyunlei@huawei.com>
Signed-off-by: Biao He <hebiao6@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 0ff21646f2)
Signed-off-by: Cliff Chen <cliff.chen@rock-chips.com>
This reverts commit cb3e42dc8c.
This will make usb port in my board can't work, no 5v voltage.
Is it no issues in android?
Change-Id: I95fbd957d0ddb5fddf215d3b00ef74aae8af08d3
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
The tcpc is the Type C Port Controller and Type C Port Delivery (tcpd)
is part of it, we haven't used them now, add it to save power consumption.
Change-Id: Ia1046fd3bb7382498811159d8280ee46b3753ebd
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 4a3a3d32c7)
In some cases, we have met the infinite loop in
rockchip_pmu_set_idle_request() or rockchip_do_pmu_set_power_domain().
As the crosbug.com/p/57351 reported, the boot hangs right after this
[1.629163] bootconsole [uart8250] disabled
[1.639286] [drm:drm_core_init] Initialized drm 1.1.0 20060810
[1.645926] [drm:drm_get_platform_dev] Initialized vgem 1.0.0 20120112..
[1.654558] iommu: Adding device ff8f0000.vop to group 0
[1.660569] iommu: Adding device ff900000.vop to group 1
<hang>
This patch adds the error message and timeout to avoid infinite loop if
it fails to get the ack.
Change-Id: Ia1e2edbdb48de3ec776f1304a941136d3e7a1854
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git.kernel.org mmind/linux-rockchip.git
v4.10-armsoc/drivers commit e4c8cd82d5)
This patch supports adjusting opp's voltage according to leakage
Change-Id: Ifbb6b6fec03abe0c7708a148affe4d7646ce38fa
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
This patch documents the Rockchip cpu avs device tree binding.
Change-Id: I4a86cd384f304a5d77ff2763b2347804699b9b93
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
On some SoCs the Adaptive Voltage Scaling (AVS) technique is
employed to optimize the operating voltage of a device. At a
given frequency, the hardware monitors dynamic factors and either
makes a suggestion for how much to adjust a voltage for the
current frequency, or it automatically adjusts the voltage
without software intervention. Add an API to the OPP library for
the former case, so that AVS type devices can update the voltages
for an OPP when the hardware determines the voltage should
change. The assumption is that drivers like CPUfreq or devfreq
will register for the OPP notifiers and adjust the voltage
according to suggestions that AVS makes.
Change-Id: Ia6dddc0976f116555965f784794b8eca37582737
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
* linux-linaro-lsk-v4.4-android: (1362 commits)
Linux 4.4.30
Revert "fix minor infoleak in get_user_ex()"
Revert "x86/mm: Expand the exception table logic to allow new handling options"
Linux 4.4.29
ARM: pxa: pxa_cplds: fix interrupt handling
powerpc/nvram: Fix an incorrect partition merge
mpt3sas: Don't spam logs if logging level is 0
perf symbols: Fixup symbol sizes before picking best ones
perf symbols: Check symbol_conf.allow_aliases for kallsyms loading too
perf hists browser: Fix event group display
clk: divider: Fix clk_divider_round_rate() to use clk_readl()
clk: qoriq: fix a register offset error
s390/con3270: fix insufficient space padding
s390/con3270: fix use of uninitialised data
s390/cio: fix accidental interrupt enabling during resume
x86/mm: Expand the exception table logic to allow new handling options
dmaengine: ipu: remove bogus NO_IRQ reference
power: bq24257: Fix use of uninitialized pointer bq->charger
staging: r8188eu: Fix scheduling while atomic splat
ASoC: dapm: Fix kcontrol creation for output driver widget
...
This reverts commit d4773e1407.
Fixed by commit abdb60d816
("FIXUP: sched/fair: Fix hang during suspend in sched_group_energy")
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
This reverts commit a9ad2b25a0.
Fixed by commit fc1d6c8c6a
("sched: Add Kconfig option DEFAULT_USE_ENERGY_AWARE to set ENERGY_AWARE feature flag")
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
This reverts commit 1047560640.
This commit 1047560 will reinit dwc3 controller mode
when resuming dwc3 core. Generally, this patch can be
used for "dr_mode = host", "dr_mode = peripheral" and
"dr_mode = otg".
However, rockchip dwc3 core don't support otg function,
but only support DRD mode. So on rockchip platform, we
set dr_mode to otg for DRD mode, then switch host and
peripheral dynamically by extcon notifier. Also, we will
enable dwc3 to be a wakeup source and enable usb3 power
domain in suspend mode if usb device is pluged in. So
dwc3 controller will not lost the mode when resuming dwc3
core.
Change-Id: I0ee4f5b02d4504e853d8ef81df3df9a8a4ac284f
Signed-off-by: William Wu <wulf@rock-chips.com>
We will add a avs driver to adjust opp's voltage according to leakage.
As it need register a notifier before cpufreq starts, and make cpufreq
defer probe is probably not really easy, so avs should probe earlier
than cpufreq, efuse should probe earlier than avs.
Change-Id: I817aa44c3b34d2fdf44148e6b9649ceed76d8f1f
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
The only use for this is for solving a hardware design problem in
usb of Rockchip RK3288.
Change-Id: I40b17f5c33125c77759808720763d2694dfc25f2
Signed-off-by: Randy Li <ayaka@soulik.info>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit cac18ecb6f)
The xhci hcd use the port polling timer (rh_timer) to poll the
roothub for port events. But we can't allow the USB core to poll
the port events during shutdown because the xhci controller may
be disable and can't be accessed in shutdown. If we access xhci
port registers with port polling timer after xhci shutdown, it
may cause kernel crash or unexpected behavior. So we need to stop
the port polling timer while shutdown xhci.
I can easily reproduce the issue on rk3399 platform, plug in a
Type-C hub and an USB ethernet dongle, then do reboot test,
result in a crash with the following backtrace.
Unhandled fault: synchronous external abort (0x96000010) at 0xffffff80002f0430
Internal error: : 96000010 [#1] PREEMPT SMP
task: ffffffc001092cb0 ti: ffffffc00107c000 task.ti: ffffffc00107c000
PC is at xhci_hub_status_data+0xec/0x1e4
LR is at xhci_hub_status_data+0xb0/0x1e4
[<ffffffc00067a210>] xhci_hub_status_data+0xec/0x1e4
[<ffffffc00063ebf8>] usb_hcd_poll_rh_status+0x54/0x148
[<ffffffc00063ed0c>] rh_timer_func+0x20/0x2c
[<ffffffc0002845cc>] call_timer_fn+0xa4/0x1c8
[<ffffffc000284964>] run_timer_softirq+0x248/0x2cc
[<ffffffc000200928>] __do_softirq+0x178/0x338
[<ffffffc000224b08>] irq_exit+0x78/0xc0
[<ffffffc00027089c>] __handle_domain_irq+0x9c/0xbc
[<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
BUG=chrome-os-partner:59111
TEST=Plug in a Type-C hub, then do reboot test, check if
kernel crash during shutdown.
Change-Id: I3ca3d12d101241cd78138ea5d995708a2893d1a0
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401121
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
On some sepcial platforms (e.g. rk3399 platform), they will call
usb_remove_hcd() to remove xhci hcd if no device connected, and
also call xhci_stop() to halt and reset xhci. So we don't need to
do the same thing in shutdown if hcd has been unregistered.
In addition to remove hcd, rk3399 platform will disable xhci power
domain in runtime suspend, if we try to access xhci registers in
shutdown, it might cause kernel crash or unexpected behavior.
BUG=chrome-os-partner:59111
TEST=reboot the system
Change-Id: I7ecfce068211ff1c4a884fc4a8a54ca5b84c1c09
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401120
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
The xhci driver provides xhci_shutdown() to be called with the main
usb_hcd (the USB3 roothub) while do reboot. But actually, xhci-plat
never call xhci_shutdwon() during reboot because it doesn't use the
usb_hcd_platform_shutdown() helper.
So we use use usb_hcd_platform_shutdown() for xhci-plat, and the
normal shutdown call trace is:
kernel_restart -> kernel_restart_prepare -> device_shutdown ->
platform_drv_shutdown -> usb_hcd_platform_shutdown -> xhci_shutdown
BUG=chrome-os-partner:59111
TEST=reboot the system
Change-Id: I9be424257ea6ba1e51521cbdd01f4698ae1752ad
Signed-off-by: William wu <wulf@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/401119
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
commit 9ba63e3cc8 upstream.
Since its initial commit, the driver is buggy for multiple interrupts
handling. The translation from the former lubbock.c file was not
complete, and might stall all interrupt handling when multiple
interrupts occur.
This is especially true when inside the interrupt handler and if a new
interrupt comes and is not handled, leaving the output line still held,
and not creating a transition as the GPIO block behind would expect to
trigger another cplds_irq_handler() call.
For the record, the hardware is working as follows.
The interrupt mechanism relies on :
- one status register
- one mask register
Let's suppose the input irq lines are called :
- i_sa1111
- i_lan91x
- i_mmc_cd
Let's suppose the status register for each irq line is called :
- status_sa1111
- status_lan91x
- status_mmc_cd
Let's suppose the interrupt mask for each irq line is called :
- irqen_sa1111
- irqen_lan91x
- irqen_mmc_cd
Let's suppose the output irq line, connected to GPIO0 is called :
- o_gpio0
The behavior is as follows :
- o_gpio0 = not((status_sa1111 & irqen_sa1111) |
(status_lan91x & irqen_lan91x) |
(status_mmc_cd & irqen_mmc_cd))
=> this is a N-to-1 NOR gate and multiple AND gates
- irqen_* is exactly as programmed by a write to the FPGA
- status_* behavior is governed by a bi-stable D flip-flop
=> on next FPGA clock :
- if i_xxx is high, status_xxx becomes 1
- if i_xxx is low, status_xxx remains as it is
- if software sets status_xxx to 0, the D flip-flop is reset
=> status_xxx becomes 0
=> on next FPGA clock cycle, if i_xxx is high, status_xxx becomes
1 again
Fixes: fc9e38c0f4 ("ARM: pxa: lubbock: use new pxa_cplds driver")
Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
