There are four adc keys on rk3399 sapphire excavator board, these are
ESC/MENU/VOL+/VOL- key.
Change-Id: I7ddb6343fd22240739a198665d9ccf82d4529af9
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Currently, unreserve_highatomic_pageblock bails out if it found highatomic
pageblock regardless of really moving free pages from the one so that it
could mitigate unreserve logic's goal which saves OOM of a process.
This patch makes unreserve functions bail out only if it moves some pages
out of !highatomic free list to avoid such false positive.
Another potential problem is that by race between page freeing and reserve
highatomic function, pages could be in highatomic free list even though
the pageblock is !high atomic migratetype. In that case,
unreserve_highatomic_pageblock can be void if count of highatomic reserve
is less than pageblock_nr_pages. We could solve it simply via draining
all of reserved pages before the OOM. It would have a safeguard role to
exhuast reserved pages before converging to OOM.
BUG=chrome-os-partner:60028
TEST=for i in $(seq 100); do ./launchBalloons.sh 6 700 30 >/dev/null; done
Conflicts:
mm/page_alloc.c
...this conflict resolution is trivial based on the conflict
resolution that was done as part of ("mm: try to exhaust highatomic
reserve before the OOM")
Link: http://lkml.kernel.org/r/1476259429-18279-5-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Sangseok Lee <sangseok.lee@lge.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
(cherry picked from akpm via linuxnext
commit df6e3cc2c9168bdbf3abecec2821a6f9ae1a2128)
Reviewed-on: https://chromium-review.googlesource.com/414640
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Change-Id: Ib3e9764c0aaa3b43e3afd05192a8c43e225adb81
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Patch series "use up highorder free pages before OOM", v3.
I got OOM report from production team with v4.4 kernel. It had enough
free memory but failed to allocate GFP_KERNEL order-0 page and finally
encountered OOM kill. It occured during QA process which launches
several apps, switching and so on. It happned rarely. IOW, In normal
situation, it was not a problem but if we are unluck so that several
apps uses peak memory at the same time, it can happen. If we manage to
pass the phase, the system can go working well.
I could reproduce it with my test(memory spike easily. Look at below.
The reason is free pages(19M) of DMA32 zone are reserved for
HIGHORDERATOMIC and doesn't unreserved before the OOM.
balloon invoked oom-killer: gfp_mask=0x24280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0
balloon cpuset=/ mems_allowed=0
CPU: 1 PID: 8473 Comm: balloon Tainted: G W OE 4.8.0-rc7-00219-g3f74c9559583-dirty #3161
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
dump_stack+0x63/0x90
dump_header+0x5c/0x1ce
oom_kill_process+0x22e/0x400
out_of_memory+0x1ac/0x210
__alloc_pages_nodemask+0x101e/0x1040
handle_mm_fault+0xa0a/0xbf0
__do_page_fault+0x1dd/0x4d0
trace_do_page_fault+0x43/0x130
do_async_page_fault+0x1a/0xa0
async_page_fault+0x28/0x30
Mem-Info:
active_anon:383949 inactive_anon:106724 isolated_anon:0
active_file:15 inactive_file:44 isolated_file:0
unevictable:0 dirty:0 writeback:24 unstable:0
slab_reclaimable:2483 slab_unreclaimable:3326
mapped:0 shmem:0 pagetables:1906 bounce:0
free:6898 free_pcp:291 free_cma:0
Node 0 active_anon:1535796kB inactive_anon:426896kB active_file:60kB inactive_file:176kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:96kB shmem:0kB writeback_tmp:0kB unstable:0kB pages_scanned:1418 all_unreclaimable? no
DMA free:8188kB min:44kB low:56kB high:68kB active_anon:7648kB inactive_anon:0kB active_file:0kB inactive_file:4kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:20kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 1952 1952 1952
DMA32 free:19404kB min:5628kB low:7624kB high:9620kB active_anon:1528148kB inactive_anon:426896kB active_file:60kB inactive_file:420kB unevictable:0kB writepending:96kB present:2080640kB managed:2030092kB mlocked:0kB slab_reclaimable:9932kB slab_unreclaimable:13284kB kernel_stack:2496kB pagetables:7624kB bounce:0kB free_pcp:900kB local_pcp:112kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0
DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 2*4096kB (H) = 8192kB
DMA32: 7*4kB (H) 8*8kB (H) 30*16kB (H) 31*32kB (H) 14*64kB (H) 9*128kB (H) 2*256kB (H) 2*512kB (H) 4*1024kB (H) 5*2048kB (H) 0*4096kB = 19484kB
51131 total pagecache pages
50795 pages in swap cache
Swap cache stats: add 3532405601, delete 3532354806, find 124289150/1822712228
Free swap = 8kB
Total swap = 255996kB
524158 pages RAM
0 pages HighMem/MovableOnly
12658 pages reserved
0 pages cma reserved
0 pages hwpoisoned
Another example exceeded the limit by the race is
in:imklog: page allocation failure: order:0, mode:0x2280020(GFP_ATOMIC|__GFP_NOTRACK)
CPU: 0 PID: 476 Comm: in:imklog Tainted: G E 4.8.0-rc7-00217-g266ef83c51e5-dirty #3135
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
dump_stack+0x63/0x90
warn_alloc_failed+0xdb/0x130
__alloc_pages_nodemask+0x4d6/0xdb0
new_slab+0x339/0x490
___slab_alloc.constprop.74+0x367/0x480
__slab_alloc.constprop.73+0x20/0x40
__kmalloc+0x1a4/0x1e0
alloc_indirect.isra.14+0x1d/0x50
virtqueue_add_sgs+0x1c4/0x470
__virtblk_add_req+0xae/0x1f0
virtio_queue_rq+0x12d/0x290
__blk_mq_run_hw_queue+0x239/0x370
blk_mq_run_hw_queue+0x8f/0xb0
blk_mq_insert_requests+0x18c/0x1a0
blk_mq_flush_plug_list+0x125/0x140
blk_flush_plug_list+0xc7/0x220
blk_finish_plug+0x2c/0x40
__do_page_cache_readahead+0x196/0x230
filemap_fault+0x448/0x4f0
ext4_filemap_fault+0x36/0x50
__do_fault+0x75/0x140
handle_mm_fault+0x84d/0xbe0
__do_page_fault+0x1dd/0x4d0
trace_do_page_fault+0x43/0x130
do_async_page_fault+0x1a/0xa0
async_page_fault+0x28/0x30
Mem-Info:
active_anon:363826 inactive_anon:121283 isolated_anon:32
active_file:65 inactive_file:152 isolated_file:0
unevictable:0 dirty:0 writeback:46 unstable:0
slab_reclaimable:2778 slab_unreclaimable:3070
mapped:112 shmem:0 pagetables:1822 bounce:0
free:9469 free_pcp:231 free_cma:0
Node 0 active_anon:1455304kB inactive_anon:485132kB active_file:260kB inactive_file:608kB unevictable:0kB isolated(anon):128kB isolated(file):0kB mapped:448kB dirty:0kB writeback:184kB shmem:0kB writeback_tmp:0kB unstable:0kB pages_scanned:13641 all_unreclaimable? no
DMA free:7748kB min:44kB low:56kB high:68kB active_anon:7944kB inactive_anon:104kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:108kB kernel_stack:0kB pagetables:4kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 1952 1952 1952
DMA32 free:30128kB min:5628kB low:7624kB high:9620kB active_anon:1447360kB inactive_anon:485028kB active_file:260kB inactive_file:608kB unevictable:0kB writepending:184kB present:2080640kB managed:2030132kB mlocked:0kB slab_reclaimable:11112kB slab_unreclaimable:12172kB kernel_stack:2400kB pagetables:7284kB bounce:0kB free_pcp:924kB local_pcp:72kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0
DMA: 7*4kB (UE) 3*8kB (UH) 1*16kB (M) 0*32kB 2*64kB (U) 1*128kB (M) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 1*4096kB (H) = 7748kB
DMA32: 10*4kB (H) 3*8kB (H) 47*16kB (H) 38*32kB (H) 5*64kB (H) 1*128kB (H) 2*256kB (H) 3*512kB (H) 3*1024kB (H) 3*2048kB (H) 4*4096kB (H) = 30128kB
2775 total pagecache pages
2536 pages in swap cache
Swap cache stats: add 206786828, delete 206784292, find 7323106/106686077
Free swap = 108744kB
Total swap = 255996kB
524158 pages RAM
0 pages HighMem/MovableOnly
12648 pages reserved
0 pages cma reserved
0 pages hwpoisoned
During the investigation, I found some problems with highatomic so this
patch aims to solve the problems and the final goal is to unreserve
every highatomic free pages before the OOM kill.
This patch (of 4):
In page freeing path, migratetype is racy so that a highorderatomic page
could free into non-highorderatomic free list. If that page is
allocated, VM can change the pageblock from higorderatomic to something.
In that case, highatomic pageblock accounting is broken so it doesn't
work(e.g., VM cannot reserve highorderatomic pageblocks any more
although it doesn't reach 1% limit).
So, this patch prohibits the changing from highatomic to other type.
It's no problem because MIGRATE_HIGHATOMIC is not listed in fallback
array so stealing will only happen due to unexpected races which is
really rare. Also, such prohibiting keeps highatomic pageblock more
longer so it would be better for highorderatomic page allocation.
Link: http://lkml.kernel.org/r/1476259429-18279-2-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Sangseok Lee <sangseok.lee@lge.com>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 88ed365ea2)
Change-Id: I446fe4977b45d56da322638d051f3ac0eb35238d
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
This patch adds a new RGB media bus formats that describe
18-bit samples transferred over an LVDS bus with three
differential data pairs, serialized into 7 time slots,
using standard JEIDA data ordering.
Change-Id: Ia0bedd53e57aa34829a0d61b144aa99a1c98cffd
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The sysfs device link can only be created after regulator device
registered.
Otherwise, the regulator always have some warning logs.
...
[ 1.033024] DCDC_REG1: supplied by vcc5v0_sys
[ 1.033427] vcc5v0_sys: could not add device link regulator.3 err -2
[ 1.034302] vdd_center: 750 <--> 1350 mV at 900 mV
[ 1.034862] rk808 0-0020: Looking up vcc2-supply from device tree
[ 1.034907] DCDC_REG2: supplied by vcc5v0_sys
[ 1.035298] vcc5v0_sys: could not add device link regulator.4 err -2
[ 1.036301] vdd_cpu_l: 750 <--> 1350 mV at 900 mV
[ 1.036837] rk808 0-0020: Looking up vcc3-supply from device tree
[ 1.036880] DCDC_REG3: supplied by vcc5v0_sys
[ 1.037271] vcc5v0_sys: could not add device link regulator.5 err -2
[ 1.037985] vcc_ddr: at 500 mV
[ 1.038508] rk808 0-0020: Looking up vcc4-supply from device tree
[ 1.038550] DCDC_REG4: supplied by vcc5v0_sys
[ 1.038941] vcc5v0_sys: could not add device link regulator.6 err -2
[ 1.039657] vcc3v3_sys: 3300 mV
[ 1.040179] rk808 0-0020: Looking up vcc9-supply from device tree
[ 1.040223] DCDC_REG5: supplied by vcc5v0_sys
Fixes: c438b9d017 ("regulator: core: Move registration of regulator device")
Change-Id: Ie20421eab45f3f8229a5bedf3fecf99c757160bb
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
fix following camera err:
rkisp1: CIF_ISP_PIC_SIZE_ERROR (0x00000002)
Change-Id: I6168d352d521cf75d7537ffe70a9af6f2ec07282
Signed-off-by: Wang Panzhenzhuan <randy.wang@rock-chips.com>
The ioremap operation for the msg_region move to the bottom of the
rockchip_cfg_atu to make msg_region make sense which used for sending
PME_TURN_OFF message to make PCIe link enter L2 state
Change-Id: I50d1bef5d534102ed5b7db474c3f819e656fd626
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Fixes: 0b8c593910 ("BACKPORT: drm/bridge: analogix: Do not use device's drvdata")
Change-Id: I4b4bd81e895022ddee0bbfd727bf05eb4d7864f2
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Programmable THRE Interrupt mode in order to increase system
performance.
Change-Id: Ic1ef9ecae0c6feb00170ad97ee3c6245ca3bf068
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
Most SOCS have only 8 or 6 channels, but have more than 16
peripherals. If those peripherals work together, some
fails to request dma channel, because there are no enough
channels. And maybe it's unnecessary to use dma for uart
tx. It is necessary for uart rx when hardware auto flow
control is not used.
&uart0 {
dma-names = "!tx", "rx"; // disable uart tx with dma
status = "okay";
};
Change-Id: Ia74477514ba57300a4d19a5c2565ae7b5b8ab521
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
If the referenced regulator is a dummy, the voltage is invalid,
but someone doesn't need the voltage, just need the adc value,
so don't return fail at probe when the regulator is dummy. If
he wants the voltage, configures the actual referenced regulator
at dts.
Change-Id: I8eaecc1a8e7e57c3a87aa69b9b852735bf4a025a
Signed-off-by: David Wu <david.wu@rock-chips.com>
As the wifi module used the ap6398s on rk3399pro evb, not the ap6255.
Even though the wifi chip name isn't effect to load wifi module, at least
it won't be misunderstand.
Change-Id: Icd44ce27d9aebcdb0d252f7c8c1dabce657cd573
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
This patch enables the ramoops to fetch some logs for debugging and
testing, the log will save on /sys/fs/pstore/console-ramoops*.
Change-Id: I47c9efbd1a0e17228e07fd6ad87a446babb265ab
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
dvp input raw/y, will output 16bit per pixel,
so output format shuold be raw16/y16.
Change-Id: I13e05ebe62b8802fa3a4c51f603c420e8127b929
Signed-off-by: Cai YiWei <cyw@rock-chips.com>
This patch uses the devm_extcon_register_notifier to
manage the resource automatically.
Change-Id: I427c54d59283ee97623ad829e42dac40516c3df4
Signed-off-by: William Wu <william.wu@rock-chips.com>
RK3399 Excavator Board has an USB 3.0 PHY power on issue
when Type-A USB 3.0 Host port connects with an USB 3.0
device and do system PM suspend/resume test.
When the issue happens, we gets the following error log:
phy phy-ff800000.phy.4: phy poweron failed --> -110
dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110
PM: Device fe900000.dwc3 failed to resume: error -110
xhci-hcd xhci-hcd.12.auto: port 0 resume PLC timeout
It's because that the Type-C PHY docs say that the DWC3
controller "needs to be held in reset to set the PIPE
power state in P2 before initializing the Type-C PHY",
but actually the PIPE is in P0 state because an USB 3.0
device is connected, and the current code doesn't reset
the DWC3 controller upon PM resume.
This patch prevents powering off the USB 3.0 PHY of
RK3399 Type-A USB 3.0 Host port when system enters
syspend. As a side effect, the power consumption in
standby mode will increase. However, if you want to
optimize the power consumption in standby mode and
allow the USB device to be reenumerated upon PM resume,
you can add a property "needs-reset-on-resume" in
DWC3 DTS like this:
&usbdrd3_1 {
needs-reset-on-resume;
};
Change-Id: Ia1cdf6e09cac520e99931a15423b8de7be2ba52b
Signed-off-by: William Wu <william.wu@rock-chips.com>
This patch adds a new property "needs-reset-on-resume" for
Rockchip DWC3 IP. We can use it if we want to reset the DWC3
controller upon PM resume.
Change-Id: I8ae7f8fe46388cdc9e265e758d9edeb82840d284
Signed-off-by: William Wu <william.wu@rock-chips.com>
If the discard_granularity of the NAND flash block device has not
been initialized, then the DM device will not set max_discard_sectors
while it is created,and f2fs will have exceptions when it performs
the discard function.
bug:
WARNING: at fs/f2fs/segment.c:1212
[ 28.075747] Hardware name: Rockchip rk3326 863 avb board (DT)
[ 28.075767] task: ffffffc03b08d100 task.stack: ffffffc02f0b4000
[ 28.075802] PC is at __submit_discard_cmd+0x1b4/0x4ec
[ 28.075840] LR is at __issue_discard_cmd+0x1b8/0x248
[ 28.075859] pc : [<ffffff800831f218>] lr : [<ffffff800831f8d0>] pstate: 60400145
[ 28.075874] sp : ffffffc02f0b7be0
Change-Id: I940728a675e7a30a05742bf2a7dcace92f7a2354
Signed-off-by: Yifeng Zhao <zyf@rock-chips.com>
