28 Nov, 2018
12 commits
-
This is a work-around for the shifted display issue when using DCSS with
the DDR self-refresh disabled.Also, make sure it works with LCDIF as well.
Increasing VSYNC length gives DCSS more time to fetch the data from RAM
before the next frame kicks in.Signed-off-by: Laurentiu Palcu
(cherry picked from commit 3c53532c466add234ac3ca2e70cefe80ea308b4f) -
When the master imx-drm-core binding fails, component_bind_all()
in imx-drm-core ->bind() callback will unbind all bound components
first and then call drm_mode_config_cleanup(). Since the encoder
and connector(located in imx_ldb.imx_ldb_channel) are freed after
the ldb ->unbind() callback, drm_mode_config_cleanup() would
accidentally access the freed encoder and connector again. To fix
this issue, we should cleanup the encoder and connector, i.e.,
remove them from the global encoder and connector lists, in the
->unbind() callback, so that, drm_mode_config_cleanup() won't find
them again in the lists. However, we have to make sure they exist
before the cleanup in the ->unbind() callback, because imx-drm-core
->unbind() calls drm_mode_config_cleanup() first and then unbinds
all components via component_unbind_all(). Moreover, the connector
isn't created at the first place if a bridge exists, so the check
before the cleanup makes sense for this reason as well.Signed-off-by: Liu Ying
(cherry picked from commit 6d3fd1316d67ff0e62fae4067b61fd3f2809dfa5) -
When the master imx-drm-core binding fails, component_bind_all()
in imx-drm-core ->bind() callback will unbind all bound components
first and then call drm_mode_config_cleanup(). Since the crtc as
a member(base) of dpu_crtc is freed after the dpu crtc ->unbind()
callback, drm_mode_config_cleanup() would accidentally access the
freed crtc again. To fix this issue, we should cleanup the crtc,
i.e., remove the crtc from the global crtc list, in the ->unbind()
callback, so that drm_mode_config_cleanup() won't find the crtc
again in the list. However, we have to make sure the crtc exists
before the cleanup in the ->unbind() callback, because imx-drm-core
->unbind() calls drm_mode_config_cleanup() first and then unbinds
all components via component_unbind_all().There is a probe deferral caused by the LDB component(later probed
GPIO resource) on some platforms(e.g., i.MX8QXP MEK), which causes
multiple times to try binding and triggers the issue described above.This patch may fix the issue reported by KASAN:
[ 3.217996] BUG: KASAN: use-after-free in drm_mode_config_cleanup+0x220/0x448
[ 3.225149] Read of size 8 at addr ffff80000ad719b0 by task swapper/0/1
[ 3.231769]
[ 3.233279] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.78-05529-ge53ea0dba88e-dirty #43
[ 3.241642] Hardware name: Freescale i.MX8QXP MEK (DT)
[ 3.246793] Call trace:
[ 3.249270] [] dump_backtrace+0x0/0x390
[ 3.254690] [] show_stack+0x14/0x20
[ 3.259769] [] dump_stack+0xf8/0x158
[ 3.264932] [] print_address_description+0x60/0x270
[ 3.271396] [] kasan_report+0x210/0x2f0
[ 3.276818] [] __asan_load8+0x84/0xa8
[ 3.282065] [] drm_mode_config_cleanup+0x220/0x448
[ 3.288447] [] imx_drm_bind+0x2b4/0x358
[ 3.293863] [] try_to_bring_up_master+0x20c/0x278
[ 3.300148] [] component_add+0x180/0x300
[ 3.305653] [] dpu_bliteng_probe+0x30/0x48
[ 3.311339] [] platform_drv_probe+0x74/0x108
[ 3.317198] [] driver_probe_device+0x3a0/0x4a8
[ 3.323226] [] __driver_attach+0xd0/0xd8
[ 3.328735] [] bus_for_each_dev+0xc0/0x140
[ 3.334419] [] driver_attach+0x30/0x40
[ 3.339749] [] bus_add_driver+0x2a8/0x320
[ 3.345344] [] driver_register+0xb4/0x190
[ 3.350941] [] __platform_driver_register+0x7c/0x88
[ 3.357410] [] dpu_bliteng_driver_init+0x1c/0x24
[ 3.363613] [] do_one_initcall+0xe0/0x260
[ 3.369211] [] kernel_init_freeable+0x230/0x2d8
[ 3.375330] [] kernel_init+0x10/0x118
[ 3.380574] [] ret_from_fork+0x10/0x18
[ 3.385894]
[ 3.387393] Allocated by task 1:
[ 3.390642] kasan_kmalloc+0xd0/0x180
[ 3.394322] kasan_slab_alloc+0x14/0x20
[ 3.398174] __kmalloc_node_track_caller+0x1ec/0x278
[ 3.403157] devm_kmalloc+0x8c/0x128
[ 3.406753] dpu_crtc_bind+0x38/0xbe0
[ 3.410434] component_bind_all+0x254/0x438
[ 3.414638] imx_drm_bind+0x1b0/0x358
[ 3.418314] try_to_bring_up_master+0x20c/0x278
[ 3.422857] component_add+0x180/0x300
[ 3.426622] dpu_bliteng_probe+0x30/0x48
[ 3.430559] platform_drv_probe+0x74/0x108
[ 3.434676] driver_probe_device+0x3a0/0x4a8
[ 3.438966] __driver_attach+0xd0/0xd8
[ 3.442730] bus_for_each_dev+0xc0/0x140
[ 3.446663] driver_attach+0x30/0x40
[ 3.450251] bus_add_driver+0x2a8/0x320
[ 3.454103] driver_register+0xb4/0x190
[ 3.457960] __platform_driver_register+0x7c/0x88
[ 3.462687] dpu_bliteng_driver_init+0x1c/0x24
[ 3.467147] do_one_initcall+0xe0/0x260
[ 3.470997] kernel_init_freeable+0x230/0x2d8
[ 3.475366] kernel_init+0x10/0x118
[ 3.478867] ret_from_fork+0x10/0x18
[ 3.482447]
[ 3.483941] Freed by task 1:
[ 3.486837] kasan_slab_free+0x88/0x198
[ 3.490691] kfree+0x70/0x210
[ 3.493672] release_nodes+0x538/0x5c0
[ 3.497432] devres_release_group+0x164/0x200
[ 3.501801] component_unbind.isra.4+0x98/0xb8
[ 3.506257] component_bind_all+0x3c8/0x438
[ 3.510456] imx_drm_bind+0x1b0/0x358
[ 3.514131] try_to_bring_up_master+0x20c/0x278
[ 3.518671] component_add+0x180/0x300
[ 3.522434] dpu_bliteng_probe+0x30/0x48
[ 3.526375] platform_drv_probe+0x74/0x108
[ 3.530490] driver_probe_device+0x3a0/0x4a8
[ 3.534781] __driver_attach+0xd0/0xd8
[ 3.538551] bus_for_each_dev+0xc0/0x140
[ 3.542488] driver_attach+0x30/0x40
[ 3.546083] bus_add_driver+0x2a8/0x320
[ 3.549941] driver_register+0xb4/0x190
[ 3.553793] __platform_driver_register+0x7c/0x88
[ 3.558519] dpu_bliteng_driver_init+0x1c/0x24
[ 3.562979] do_one_initcall+0xe0/0x260
[ 3.566827] kernel_init_freeable+0x230/0x2d8
[ 3.571199] kernel_init+0x10/0x118
[ 3.574698] ret_from_fork+0x10/0x18
[ 3.578277]
[ 3.579783] The buggy address belongs to the object at ffff80000ad71980
[ 3.579783] which belongs to the cache kmalloc-2048 of size 2048
[ 3.592501] The buggy address is located 48 bytes inside of
[ 3.592501] 2048-byte region [ffff80000ad71980, ffff80000ad72180)
[ 3.604258] The buggy address belongs to the page:
[ 3.609072] page:ffff7e00002b5c00 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0
[ 3.618926] flags: 0xfffc00000008100(slab|head)
[ 3.623484] raw: 0fffc00000008100 0000000000000000 0000000000000000 00000001800f000f
[ 3.631252] raw: dead000000000100 dead000000000200 ffff800010703400 0000000000000000
[ 3.639007] page dumped because: kasan: bad access detected
[ 3.644590]
[ 3.646086] Memory state around the buggy address:
[ 3.650898] ffff80000ad71880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.658134] ffff80000ad71900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 3.665370] >ffff80000ad71980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.672599] ^
[ 3.677402] ffff80000ad71a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 3.684641] ffff80000ad71a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fbSigned-off-by: Liu Ying
(cherry picked from commit 5fc482dbf423fff005214db5ac4ac2dcd5cae028) -
The dpu_plane is allocated with kzalloc() in dpu_plane_init().
In case, dpu_plane_init() fails after that allocation, the bailout path
should free the dpu_plane, otherwise, there will be memory leakage.Signed-off-by: Liu Ying
(cherry picked from commit 99cb80f855aafbe524519db635c3d03bd4cc8d85) -
1.avoid illegal wptr, rptr, start and end.
2.function show_instance_info is too long, split it into several small
functions
3.export dma detail infoSigned-off-by: ming_qian
-
1. Remove debug log when boot
2. Add 8 for the vp8 frame length
3. correct some codesSigned-off-by: Huang Chaofan
(cherry picked from commit 1cbc438fade80f4d91851f1495852e43d2807f9d) -
The current keep-alive check mechanism uses a static variable
that is initialized to 0. When the function is first called, it may
happen to catch the 8-bit keep-alive counter right when it
overflows, hence returning BUSY.This patch will keep checking the counter for 10us, every 1us,
but it will immediately return if the keep-alive counter changed.Signed-off-by: Laurentiu Palcu
Signed-off-by: Sandor Yu
(cherry picked from commit 4ad828b95e78a652f509110688a6f907fc286ea9) -
hal/kernel/gc_hal_kernel_command.c: In function gckCOMMAND_Commit:
hal/kernel/gc_hal_kernel_command.c:2718:1:
error: the frame size of 2288 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]removed _commandBufferObject instrance, use kmalloc to avoid kasan error.
Date: Jul 13, 2017
Signed-off-by: Xianzhong
(cherry picked from commit d8d57e43a24bd02b375d7c6bd633ed236db19337)
(cherry picked from commit 484e3073adf47d27581482f268b01fe5fe219d18) -
Add DRM_VIV_GEM_VIRTUAL_POOL flags.
Switch to virtual pool when this flag is set.Change-Id: I6e1e799cd0b4f81ed1ffbfdabe8f105325fa9644
Signed-off-by: Ivan.liu
(cherry picked from commit c4bd0fc803409c54d06e3554f4857922d6640925) -
Signed-off-by: ming_qian
-
When an atomic commit contains an active CRTC with no plane,
it may cause two potential issues:First, this CRTC will fetch its last attached plane data
or has no data can be fetched depending on the plane
driver's atomic_disable() implementation.Second, this CRTC's 'plane_changed' will be false during
the whole commit tail stage, and this will make vblank
wait to be bypassed which directly causes the later wait
flip done timeout.So add this commit case check to the LCDIF CRTC's atomic
check to block this kind of commits.Signed-off-by: Fancy Fang
(cherry picked from commit 67ced65259a4dbf040ce4a931325be6ba97e5131) -
Signed-off-by: ming_qian
27 Nov, 2018
11 commits
-
Enable debugfs to export some firmware internal log
Signed-off-by: Huang Chaofan
(cherry picked from commit d4ccecbec66b27c305b2a4a4b79d28f176fb499b) -
When pixel combiner is used, it turns out that on-the-fly switch from
tile framebuffer to linear framebuffer would cause hardware malfunction
- right half display would be missing and master&slave content shadow
load done event won't come. Thus, go for a full modeset as a workaround.
Note that we check if the original framebuffer is tile or not for both
primary and overlay planes. So, this could be over-kill. The issue was
found when we use 32bit GPU super tile as the original framebuffer on the
primary plane(restart Weston frequently). However, since we usually
don't do this kind of switch in real graphics, it should be fine.Signed-off-by: Liu Ying
(cherry picked from commit 9245bbf650fdeb79ebf869d48b6bd1b43c2bcf3b) -
1. get boot size and rpc size from dts file
2. set p[18]=1 in vpu_firmware_download()Signed-off-by: Huang Chaofan
(cherry picked from commit b859b67f2cc6ea05ece69294a960e85eb198d61e) -
Adding more statistic info for debug
Signed-off-by: Huang Chaofan
(cherry picked from commit ebef17b0a54a307a5f98d5912a7848b922bb863d) -
1. Add dma memory counting
2. Delay the free of instance file when firmware hangSigned-off-by: Huang Chaofan
(cherry picked from commit 431eb4f32b31ef82500c2405c690775c6eb87d33) -
update function
1. Modified EOS filling size
2. add mb() before function rpc_update_cmd_buffer_ptr and
rpc_update_msg_buffer_ptr
3. modify some log print functionSigned-off-by: Huang Chaofan
(cherry picked from commit b58bbfe0e75568e7f3104589a06519d1eaddb01a) -
Signed-off-by: ming_qian
-
Register setting for ov5640 30fps is the same with 15fps, so
correct itSigned-off-by: Guoniu.Zhou
(cherry picked from commit 80b4f71476ffa3f45de01ccbac88fb131a3c444c) -
Signed-off-by: ming_qian
-
Signed-off-by: ming_qian
-
1.get frame size from uFrameSize reported by frame_done event
2.strip stuff data at the end of frame
3.avoid merging two frames into oneSigned-off-by: ming_qian
26 Nov, 2018
2 commits
-
The system can be wakeuped only when system is totally suspend, when the
wakeup event comes during suspend will cause the system hang. For the reason
that CAN will not call flexcan_noirq_resume() callback if the wakeup event
comes before noirq suspend stage.The way to fix the issue is that assure the system to call
flexcan_noirq_suspend() during suspend and then call
flexcan_noirq_resume() during resume.Signed-off-by: Joakim Zhang
-
When dev->power.can_wakeup set to true, device_prepare() may runtime resume the device:
dpm_suspend_start()
dpm_prepare(state);
dev->driver->pm->prepare()
pm_genpd_prepare()
if (resume_needed(dev, genpd))
pm_runtime_resume(dev);And imx8qm/qxp power domain driver don't implement the active_wakeup() callback, then
resume_needed() always return "true" when dev->power.can_wakeup is true.Once CAN device is runtime active status, then CAN's clock's count is 1 during system
suspend. And CAN0/CAN1/CAN2 share the same module clock, so we can say all CAN's module
clock is enabled during system suspended.flexcan_runtime_resume()
flexcan_clks_enable(priv);i.MX8QM/QXP SCU code clock logic requires linux kernel clocks should be disabled during
suspend, otherwise SCU don't enable them after system resume back.There are two ways to fix the issue:
1. CAN driver should check the runtime status to ensure all clocks are disabled during
system suspend.
2. Don't set CAN wakeup capability during probe, move it into flexcan_open().Signed-off-by: Fugang Duan
Signed-off-by: Joakim Zhang
23 Nov, 2018
8 commits
-
- Fix GPU-viv drivers to build without SMP
Signed-off-by: Cedric Neveux
(cherry picked from commit 6558c2881b0cd1441708933fa1ac397f54b5aa70) -
Coverity complains CID 3411292: Improper use of negative valure
(NEGATIVE_RETURNS), as possibly assign a negative value to unsigned
int, fix it by use an int temp value for negative value return.Acked-by: Peter Chen
Signed-off-by: Li Jun
(cherry picked from commit 9ab72e25fcda73a455a434993c8186663c241f27) -
The iMX6 platform does not support fardware GCM, more
recent iMX does so we enable it.Signed-off-by: Franck LENORMAND
(cherry picked from commit 2a4e35399f37caff111d420866a9d4beb494e2e9) -
A tagged key is a key which has been tagged with metadata
using tag_object.h API.We add the support for these keys to caamalg.
For each algo of caamalg which supports tagged keys , it is done by:
- Creating a modified version of the algo
- Registering the modified version
- When the modified transform is used, it gets
the load parameter of the key.Signed-off-by: Franck LENORMAND
(cherry picked from commit 88dee97d985890dbf37cafa7934c476d0ecfd0b3) -
Add functions to tag an object with metadata(configuration).
It is possible to:
- create metadata:
- init_tag_object_header
- init_blackey_conf
- set_tag_object_conf
- retrieve metadata:
- get_tag_object_conf
- get_blackey_confThe API expects an object to be a space a memory
with an address and a size.The implementation of the tag is currently exposed
but users shouldn't access it directly, they should
use the functions provided.Signed-off-by: Franck LENORMAND
(cherry picked from commit ebbb132da8e7f9de7f3d375eff8d87f684feb1eb) -
Signed-off-by: ming_qian
-
1. reset firmware if core is hang the next time you open it.
2. add mb() before rpc_update_cmd_buffer_ptr_encoderSigned-off-by: ming_qian
-
To make sure that the message wound't be discarded when
M4 is running normally or in the suspend mode. Only use
the timeout mechanism by the first notify when the vdev
is registered.Signed-off-by: Richard Zhu
(cherry picked from commit aaf42a6c2c224aa9bd88b13abcf8f848f2eab073)
22 Nov, 2018
6 commits
-
Add debug function print_nbuf_to_eoi, to print the decoder input frame.
Add module parameter mxc_jpeg_tracing.Signed-off-by: Mirela Rabulea
Reviewed-by: Laurentiu Palcu -
Set allow_zero_bytesused, to let gst-launch work, this lead to the need
to implement V4L2_DEC_CMD_STOP, dummy for now.Implement g_fmt_vid_cap, called by gst-launch before queuing any capture
buffers, this also required some fixes in jpeg_parse and buf_queue,
which wrongly assumed capture buffers are enqueued before output buffers.
So, import the resolution and pixel-format from the output queue,
if the capture queue is not set-up yet.Add release_active_buffers and use it in stop_streaming to properly
clean-up active buffers, this fixes warning at gst-launch stop with Ctrl+CCheck for decoding/encoding error in interrupt handler and print CAST IP
error status, found some yuv422 images with errors in SOS marker.Partially implemented subscribe_event, V4L2_EVENT_EOS is not working yet,
will be addressed in a subsequent fix.Signed-off-by: Mirela Rabulea
Reviewed-by: Laurentiu Palcu -
CID 3869707: Resource leak (RESOURCE_LEAK)
13. leaked_storage: Variable fhandler going out of scope leaks
the storage it points toSigned-off-by: Haibo Chen
(cherry picked from commit ddf57217892e9fefc4f04a09988f4b0ed3bf0f07) -
CID 3869705: Unsigned compared against 0 (NO_EFFECT)
unsigned_compare: This greater-than-or-equal-to-zero comparison of an
unsigned value is always true. attr_count >= 0.Signed-off-by: Haibo Chen
(cherry picked from commit 7380600ba0d0763b6081c07f5ddcb018a54314ca) -
CID 3869704: Wrong sizeof argument (SIZEOF_MISMATCH)
suspicious_sizeof: Passing argument f1a->button_control.txrx_map of
type unsigned char * and argument 8 /* sizeof (f1a->button_control.txrx_map) */
to function synaptics_rmi4_i2c_read is suspicious.Passing argument should be sizeof(unsigned char) rather than
sizeof(unsigned char *).Signed-off-by: Haibo Chen
(cherry picked from commit 4583a0bc1ff6684e1d850eb50308ad8ae2fea627) -
Unable to handle kernel paging request at virtual address 1000100
[] prefetch_freepointer.isra.37+0x8/0x14
[] sync_file_create+0x28/0xc0
[] gckOS_CreateNativeFence+0x74/0x110
[] gckKERNEL_Dispatch+0xa54/0x15b0
[] gckDEVICE_Dispatch+0x2e4/0x2f8
[] drv_ioctl+0x110/0x21c
[] do_vfs_ioctl+0xb8/0x8b0
[] SyS_ioctl+0x84/0x98The reference count should be increased in one spin lock cycle.
Move spin lock out of _QueryIntegerId function.
Move signal reference count to gckOS_CreateNativeFence.Change-Id: I1bf89b4de6055e5d0009baf7287f600696c4a529
Signed-off-by: Ivan.liu
20 Nov, 2018
1 commit
-
During the time window of noirq suspend and noirq resume, if a GPIO
pin is enabled as system wakeup source, the corresponding GPIO line's
IRQ will be unmasked, and GPIO bank will NOT lost power, when GPIO irq
arrives, generic irq handler will mask it until GPIO driver is ready
to handle it, but in GPIO noirq resume callback, current
implementation will restore the IMR register using the value saved in
previous noirq suspend callback which is unmasked, so this GPIO line
with IRQ pending will be unmasked again after GPIO IMR regitster is
restored, ARM will be triggered to handle this IRQ again, because of
the change of commit bf22ff45bed6 ("genirq: Avoid unnecessary low
level irq function calls"), the mask_irq function will check the
status of irq_data to decide whether to mask the irq, in this
scenario, since the GPIO IRQ is being masked before GPIO noirq resume,
IRQD_IRQ_MASKED flag is set, so the second time GPIO IRQ triggered by
restoring GPIO IMR register, the irq_mask callback will be skipped and
cause ARM busy handling the GPIO IRQ come all the way and no response to
user anymore.Signed-off-by: Bai Ping
Reviewed-by: Anson Huang
(cherry picked from commit c03d9ec1f861ff7cd04637ef01aa7e14388277b6)