There is playback's sound L/R channel conversion problem when recording is opened
Change-Id: Iae7160e25bdd834df9904fbd34fe964449c93560
Signed-off-by: Binyuan Lan <lby@rock-chips.com>
Currently, CTS+N is forced to zero as a workaround of the IP block for
i.MX platforms. This is requested in the datasheet of the corresponding
IP for AHB mode only. However, we have seen that it introduces glitches
or delays when playing a sound on HDMI for I2S mode. This proves that we
cannot keep the current functions for handling audio stream as-is if
these contain workaround that are specific to a mode.
This commit introduces two callbacks, one for each variant.
dw_hdmi_setup defines the right function depending on the detected
variant. Then, the exported functions dw_hdmi_audio_enable and
dw_hdmi_audio_disable calls the corresponding callbacks
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170414083113.4255-2-romain.perier@collabora.com
(cherry picked from commit a7d555d2f2)
Change-Id: Ie988cdd7ab54466fa01135ae940ce0d2c27431d2
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
For platforms that do not support YCbCr420 output, it is not enough
to check only the pixel clock.
Change-Id: I0113ffb18aa4667384c621c4e80de2b68e4e8469
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
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>
