PD#172587
Problem:
screen blank after boot logo
Solution:
correct default display information
Verify:
verified on tl1 ref board
Change-Id: I94237b5241eacee6965bfe4ea0426bb8e9f494f1
Signed-off-by: Jian Cao <jian.cao@amlogic.com>
osd: tl1 hold line fix needn't shift workaround [1/1]
PD#172587
Problem:
tl1 hold line fix needn't shift workaround.
Solution:
remove shift workaround int tl1
Verify:
verified by x301
Change-Id: I96d99758ba6f93622c34a8e69c4a3f769fdfad49
Signed-off-by: pengcheng chen <pengcheng.chen@amlogic.com>
usb: bringup usb for tl1 [1/1]
PD#172587
Problem:
bringup usb for tl1
Solution:
bringup usb for tl1.
disable usb device sof interrupt for tl1.
Verify:
verify on tl1 skt.
Change-Id: Ifbcd3b406145ac39709ff2df795544086277f00e
Signed-off-by: Yue Wang <yue.wang@amlogic.com>
Signed-off-by: Luan Yuan <luan.yuan@amlogic.com>
Conflicts:
arch/arm/boot/dts/amlogic/mesontl1.dtsi
PD#SWPL-4035
Problem:
cpu driver need read efuse data
Solution:
add interface to read data
Verify:
g12a_skt
Change-Id: Ia5d74c3fa057d06426b4277652e508714400a30f
Signed-off-by: Shunzhou Jiang <shunzhou.jiang@amlogic.com>
PD#SWPL-4354
Problem:
alloc flag is not correct when free dma buffer
Solution:
reset alloc flag when free dma buffer
Verify:
test pass on g12a-u200
Change-Id: Idfc0be5b394d18799232f6239b3f6c6df9181ce0
Signed-off-by: Jian Cao <jian.cao@amlogic.com>
PD#SWPL-4354
Problem:
alloc flag is not correct when free dma buffer
Solution:
reset alloc flag when free dma buffer
Verify:
test pass on g12a-u200
Change-Id: I4aea27f38ebda72cfe77183423600c918b836d7c
Signed-off-by: Jian Cao <jian.cao@amlogic.com>
PD#SWPL-3381
Problem:
vd2 used postblend as default after g12a chip
Solution:
force vd2 using preblend when playing mvc
Verify:
Locally on u212
Change-Id: Ia7fab8ad70ed1e58b7ade241828afab288b94bec
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD#SWPL-3088
Problem:
g12b big-little cluster is different from other SoC with pmu
interrupts and registers.
software modifications must adapt to the difference.
Solution:
modify
Verify:
u200 w400
Change-Id: If9217c1025dff5c17d51790f8c216e31b7d6532b
Signed-off-by: Hanjie Lin <hanjie.lin@amlogic.com>
Signed-off-by: Luan Yuan <luan.yuan@amlogic.com>
PD#SWPL-915
Problem:
DOLBY only sets the enhancement for the first frame ->
Vd sets cur_dispubf2 according to enhance ->
codec_mm keeps the last frame according to cur_dispbuf2,
so it fails -> AFBC2 access to the released content causes the trigger.
Solution:
close afbc2
Verify:
r321
Change-Id: I03c431a6ea11b8aabf97b1f0b21f717024be2f62
Signed-off-by: Yi Zhou <yi.zhou@amlogic.com>
PD#SWPL-4320
Problem:
The meson8b and arm64_a32 are both selected in Kconfig,
which is quite misleading
Solution:
Disable meson8b when arm64_a32 is selected
Verify:
Locally passed for Ampere
Change-Id: I93f55239ea90bf8cf6b96e108b6fd4a239de32b4
Signed-off-by: Jiamin Ma <jiamin.ma@amlogic.com>
PD#SWPL-3951
Problem:
buffer malloc for dtb may failed
Solution:
malloc may sleep to wait for enough memory
Verify:
pass on p212
Change-Id: Ib4c266c17140d2a6abf2aea6c02b2ff591f0fe08
Signed-off-by: Ruixuan Li <ruixuan.li@amlogic.com>
PD#SWPL-4876
Problem:
32bit will operate led-trigger cpu0 in cpu idle enter/exit causing
system led flashing.
Solution:
give up using led-trigger cpu0.
Verify:
g12a_u211 g12a_u212
Change-Id: I106a4fe0e35923919f5bbc34113fa73a4ca28577
Signed-off-by: Bichao Zheng <bichao.zheng@amlogic.com>
Signed-off-by: Luan Yuan <luan.yuan@amlogic.com>
Conflicts:
arch/arm64/boot/dts/amlogic/g12b_a311x_w411_buildroot.dts
PD#SWPL-3359
Problem:
the bt656 clocks were missing
Solution:
1.add bt656 clocks
2.fix several errors for media clocks
Verify:
test passed on u200
Change-Id: Iff69e790c78335930d6b2ea54f7544aca464e1fb
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
PD#SWPL-85
Problem:
print into level control
Solution:
print into level control
Verify:
U212
Change-Id: Ib0fdc02f26e75c20e48171bca5ebef072947d78c
Signed-off-by: jintao xu <jintao.xu@amlogic.com>
PD#SWPL-85
Problem:
Upper layer need control osd and video layer zorder
Solution:
1.Add video layer zorder interface by sysfs and ioctl
2.Switch the osd and video layer order in vsync
Verify:
Verify on U212
Change-Id: Ic50e81784b865cc57e4ab9a63d74806f7a8721cf
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD#SWPL-85
Problem:
Need support two video layers feature
Solution:
1.Add vd2 mif config
2.Add vd2 pps calculation and config
3.Add vd2 axis/crop/screen mode interface by sysfs and ioctl
4.Add layer query/alloc/free interface
Verify:
Verify on U212
Change-Id: I71fc9ab2ae0230c3e84c4b790e77d2c790951642
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD#172587
Problem:
Add sr driver support for tl1
Solution:
add sr driver support for tl1
fix horizontal line when play video on 4K screen
Verify:
TL1 X301
Change-Id: I422f27eb5cf12f69dc57de295425536671e2df38
Signed-off-by: wenfeng.guo <wenfeng.guo@amlogic.com>
PD#172587
Problem:
Bringup TL1 vidoe driver.
TL1 need support YUV422/444 AFBC.
TL1 need check afbc source from decode or vdin.
TL1 need afbc compress loss mode.
Solution:
Merge from branch bringup/amlogic-4.9/tl1-20181111.
Verify:
verify on tl1
Change-Id: I0af62e7638db4e1c349df874ccffdeddcaa715af
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD#SWPL-3144
Problem:
The latch function cause the super scaler size asynchronous
Solution:
Disable sr core0 and core1 scaler latch
Verify:
T962x2 x301 board test pass
Change-Id: Iecbcc3e0c751093b6515f7b46973eca2157cd349
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD# 169839
After do suspend/resume circularly, sometimes ethernet can't recover from
suspend. Add a phy reset when every resume.
Change-Id: Id03223a9c62f4dcab1cdfbc4805cc3b4c0212cf5
Signed-off-by: Shen Liu <shen.liu@amlogic.com>
PD#SWPL-4331
Problem:
Same source clk doesn't recover to 48K
after playback 192k DDP stream.
Solution:
Add ways to recover the clk.
Verify:
Local verified
Change-Id: If410d9ca04446c35bafebe2913b01e19b5fee224
Signed-off-by: Shuai Li <shuai.li@amlogic.com>
PD#SWPL-5219
Problem:
audio glitch at tdm startup
Solution:
Pad 0 data to clear the remaining data
in the module.
Verify:
Local tested.
Change-Id: Iab526c6893a32030799567b57e05e7bb11b8fea0
Signed-off-by: Shuai Li <shuai.li@amlogic.com>
PD#SWPL-5131
Problem:
Some stream in tunnel mode, first audio pts is large than
AV_DISCONTINUE_THREDHOLD_MAX(60s). In audio_hw it will check pcr and
apts diff, so large difference between pcr and apts will lead sync mode
from amster to vmaster(egg:SYNC-HEVC-59FPS-DDP51)
Solution:
do not operate tsync_mode_switch before first video toggled
Verify:
verify by franklin
Change-Id: Icec2de71ea8f838146444aa3ea880f76ed8e0f13
Signed-off-by: Yingwei Long <yingwei.long@amlogic.com>
PD#SWPL-5113
Problem:
video flash when resolution change from 4K to 640x480
Solution:
temporary solution for video flash for u212
Verify:
verify by u212
Change-Id: I8b7ec009bf599032c7bff5f80b72b557403355da
Signed-off-by: shuanglong.wang <shuanglong.wang@amlogic.com>
PD#SWPL-4048
Problem:
video peek can not get first frame toggled on 64bit
Solution:
add the cmd to amvideo_compat_ioctl
Verify:
verify on p212
Change-Id: I6933f305382d636f5f98f4bf19fddcf6ce9471c1
Signed-off-by: Jian Wang <jian.wang@amlogic.com>
PD#SWPL-4079
Problem:
hdr->sdr must have 1.5s delay, when switching from sdr->hdr
the work queue can't be eliminated in time.
Solution:
eliminate the work of sdr effect when choosing hdr
Verify:
u212
Change-Id: I4c1d5467a58253ffa2fa12dfbac7f504d0388a00
Signed-off-by: Yi Zhou <yi.zhou@amlogic.com>
PD#SWPL-4317
Problem:
for video peek, before audio post audio start, video may have rended.
Solution:
do not post video start for video peek, all wait for audio start to
start pcr
Verify:
verify by p212
Change-Id: If5656154e30613164465f84c44d3fd1ee386d654
Signed-off-by: shuanglong.wang <shuanglong.wang@amlogic.com>
PD#SWPL-1207
Problem:
fix the filckered problem when playing transition
video in sdr tv
Solution:
when dv core2 don't run, the reset can't be executed
Verify:
r321
Change-Id: I719325f1722589e02a40d46442258b0d1e3feb17
Signed-off-by: Yi Zhou <yi.zhou@amlogic.com>
commit 6f496a555d upstream.
When KASLR and KASAN are both enabled, we keep the modules where they
are, and randomize the placement of the kernel so it is within 2 GB
of the module region. The reason for this is that putting modules in
the vmalloc region (like we normally do when KASLR is enabled) is not
possible in this case, given that the entire vmalloc region is already
backed by KASAN zero shadow pages, and so allocating dedicated KASAN
shadow space as required by loaded modules is not possible.
The default module allocation window is set to [_etext - 128MB, _etext]
in kaslr.c, which is appropriate for KASLR kernels booted without a
seed or with 'nokaslr' on the command line. However, as it turns out,
it is not quite correct for the KASAN case, since it still intersects
the vmalloc region at the top, where attempts to allocate shadow pages
will collide with the KASAN zero shadow pages, causing a WARN() and all
kinds of other trouble. So cap the top end to MODULES_END explicitly
when running with KASAN.
Cc: <stable@vger.kernel.org> # 4.9+
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[will: backport to 4.9.y]
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f93a4f297 upstream.
It is possible for an irq triggered by channel0 to be received later
after clks are disabled once firmware loaded during sdma probe. If
that happens then clearing them by writing to SDMA_H_INTR won't work
and the kernel will hang processing infinite interrupts. Actually,
don't need interrupt triggered on channel0 since it's pollling
SDMA_H_STATSTOP to know channel0 done rather than interrupt in
current code, just clear BD_INTR to disable channel0 interrupt to
avoid the above case.
This issue was brought by commit 1d069bfa3c ("dmaengine: imx-sdma:
ack channel 0 IRQ in the interrupt handler") which didn't take care
the above case.
Fixes: 1d069bfa3c ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler")
Cc: stable@vger.kernel.org #5.0+
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reported-by: Sven Van Asbroeck <thesven73@gmail.com>
Tested-by: Sven Van Asbroeck <thesven73@gmail.com>
Reviewed-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0b24cae4d5 upstream.
Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence.
Without this execution hazard barrier it's possible for the value read
back from the KScratch register to be the value from before the mtc0.
Reproducible on P5600 & P6600.
The hazard is documented in the MIPS Architecture Reference Manual Vol.
III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
6.03 table 8.1 which includes:
Producer | Consumer | Hazard
----------|----------|----------------------------
mtc0 | mfc0 | any coprocessor 0 register
Signed-off-by: Dmitry Korotin <dkorotin@wavecomp.com>
[paul.burton@mips.com:
- Commit message tweaks.
- Add Fixes tags.
- Mark for stable back to v3.15 where P5600 support was introduced.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes: 3d8bfdd030 ("MIPS: Use C0_KScratch (if present) to hold PGD pointer.")
Fixes: 829dcc0a95 ("MIPS: Add MIPS P5600 probe support")
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da9de5f852 upstream.
The call to sdma_progress() is called outside the wait lock.
In this case, there is a race condition where sdma_progress() can return
false and the sdma_engine can idle. If that happens, there will be no
more sdma interrupts to cause the wakeup and the user_sdma xmit will hang.
Fix by moving the lock to enclose the sdma_progress() call.
Also, delete busycount. The need for this was removed by:
commit bcad29137a ("IB/hfi1: Serve the most starved iowait entry first")
Cc: <stable@vger.kernel.org>
Fixes: 7724105686 ("IB/hfi1: add driver files")
Reviewed-by: Gary Leshner <Gary.S.Leshner@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb34e690e9 upstream.
Thomas reported that:
| Background:
|
| In preparation of supporting IPI shorthands I changed the CPU offline
| code to software disable the local APIC instead of just masking it.
| That's done by clearing the APIC_SPIV_APIC_ENABLED bit in the APIC_SPIV
| register.
|
| Failure:
|
| When the CPU comes back online the startup code triggers occasionally
| the warning in apic_pending_intr_clear(). That complains that the IRRs
| are not empty.
|
| The offending vector is the local APIC timer vector who's IRR bit is set
| and stays set.
|
| It took me quite some time to reproduce the issue locally, but now I can
| see what happens.
|
| It requires apicv_enabled=0, i.e. full apic emulation. With apicv_enabled=1
| (and hardware support) it behaves correctly.
|
| Here is the series of events:
|
| Guest CPU
|
| goes down
|
| native_cpu_disable()
|
| apic_soft_disable();
|
| play_dead()
|
| ....
|
| startup()
|
| if (apic_enabled())
| apic_pending_intr_clear() <- Not taken
|
| enable APIC
|
| apic_pending_intr_clear() <- Triggers warning because IRR is stale
|
| When this happens then the deadline timer or the regular APIC timer -
| happens with both, has fired shortly before the APIC is disabled, but the
| interrupt was not serviced because the guest CPU was in an interrupt
| disabled region at that point.
|
| The state of the timer vector ISR/IRR bits:
|
| ISR IRR
| before apic_soft_disable() 0 1
| after apic_soft_disable() 0 1
|
| On startup 0 1
|
| Now one would assume that the IRR is cleared after the INIT reset, but this
| happens only on CPU0.
|
| Why?
|
| Because our CPU0 hotplug is just for testing to make sure nothing breaks
| and goes through an NMI wakeup vehicle because INIT would send it through
| the boots-trap code which is not really working if that CPU was not
| physically unplugged.
|
| Now looking at a real world APIC the situation in that case is:
|
| ISR IRR
| before apic_soft_disable() 0 1
| after apic_soft_disable() 0 1
|
| On startup 0 0
|
| Why?
|
| Once the dying CPU reenables interrupts the pending interrupt gets
| delivered as a spurious interupt and then the state is clear.
|
| While that CPU0 hotplug test case is surely an esoteric issue, the APIC
| emulation is still wrong, Even if the play_dead() code would not enable
| interrupts then the pending IRR bit would turn into an ISR .. interrupt
| when the APIC is reenabled on startup.
From SDM 10.4.7.2 Local APIC State After It Has Been Software Disabled
* Pending interrupts in the IRR and ISR registers are held and require
masking or handling by the CPU.
In Thomas's testing, hardware cpu will not respect soft disable LAPIC
when IRR has already been set or APICv posted-interrupt is in flight,
so we can skip soft disable APIC checking when clearing IRR and set ISR,
continue to respect soft disable APIC when attempting to set IRR.
Reported-by: Rong Chen <rong.a.chen@intel.com>
Reported-by: Feng Tang <feng.tang@intel.com>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rong Chen <rong.a.chen@intel.com>
Cc: Feng Tang <feng.tang@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 423ea32554 ]
Make the forward declaration actually match the real function
definition, something that previous versions of gcc had just ignored.
This is another patch to fix new warnings from gcc-9 before I start the
merge window pulls. I don't want to miss legitimate new warnings just
because my system update brought a new compiler with new warnings.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit debd1c065d upstream.
Recent FITRIM work, namely bbbf7243d6 ("btrfs: combine device update
operations during transaction commit") combined the way certain
operations are recoded in a transaction. As a result an ASSERT was added
in dev_replace_finish to ensure the new code works correctly.
Unfortunately I got reports that it's possible to trigger the assert,
meaning that during a device replace it's possible to have an unfinished
chunk allocation on the source device.
This is supposed to be prevented by the fact that a transaction is
committed before finishing the replace oepration and alter acquiring the
chunk mutex. This is not sufficient since by the time the transaction is
committed and the chunk mutex acquired it's possible to allocate a chunk
depending on the workload being executed on the replaced device. This
bug has been present ever since device replace was introduced but there
was never code which checks for it.
The correct way to fix is to ensure that there is no pending device
modification operation when the chunk mutex is acquire and if there is
repeat transaction commit. Unfortunately it's not possible to just
exclude the source device from btrfs_fs_devices::dev_alloc_list since
this causes ENOSPC to be hit in transaction commit.
Fixing that in another way would need to add special cases to handle the
last writes and forbid new ones. The looped transaction fix is more
obvious, and can be easily backported. The runtime of dev-replace is
long so there's no noticeable delay caused by that.
Reported-by: David Sterba <dsterba@suse.com>
Fixes: 391cd9df81 ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace")
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 78c68e8f5c upstream.
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212 msec
This occurred due to:
1. driver starts up
2. fbcon comes along and restores fbdev, enabling vblank
3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
seq number and time set at current value
(some time later)
4. weston starts and does a modeset
5. atomic commit disables crtc while it does the modeset
6. ipu_crtc_atomic_disable sends vblank with old seq number and time
Fixes: a474478642 ("drm/imx: fix crtc vblank state regression")
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
