Eric Lee / smarc-fsl-linux-kernel

05 Dec, 2018

1 commit

04 Dec, 2018

2 commits

03 Dec, 2018

3 commits

29 Nov, 2018

1 commit

28 Nov, 2018

12 commits

  • a49ffcd97   MLK-20361: drm/panel/raydium: increase vsync_len to 4 ... Browse Code »

    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)

    Laurentiu Palcu
     
  • bab01e658   MLK-20486 drm/imx: ldb: Cleanup enc&conn in ->unbind() if necessary ... Browse Code »

    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)

    Liu Ying
     
  • 4c828b1d0   MLK-16302-2 drm/imx: dpu: crtc: Cleanup crtc in ->unbind() if necessary ... Browse Code »

    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 fb

    Signed-off-by: Liu Ying
    (cherry picked from commit 5fc482dbf423fff005214db5ac4ac2dcd5cae028)

    Liu Ying
     
  • aed3e47d0   MLK-16302-1 drm/imx: dpu: plane: Free dpu_plane when bailout from dpu_plane_init ... Browse Code »

    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)

    Liu Ying
     
  • a767b27ad   MLK-20485: VPU Encoder:check encoder stream buf desc ... Browse Code »

    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 info

    Signed-off-by: ming_qian

    ming_qian
     
  • 7e11e44fc   MLK-20484 VPU: Remove debug log when boot and adjust some other codes ... Browse Code »

    1. Remove debug log when boot
    2. Add 8 for the vp8 frame length
    3. correct some codes

    Signed-off-by: Huang Chaofan
    (cherry picked from commit 1cbc438fade80f4d91851f1495852e43d2807f9d)

    Huang Chaofan
     
  • e3bc8fb1b   MLK-20481: hdp: change hdmi keep-alive check mechanism ... Browse Code »

    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)

    Sandor Yu
     
  • 84dc47287   MGS-3083 [#imx-662] fix kernel build error with kasan config ... Browse Code »

    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)

    Xianzhong
     
  • d95ae967a   MA-13450-1 [#ccc] Switch layer memory allocation to virtual pool to improve performance. ... Browse Code »

    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)

    Ivan.liu
     
  • 87307dfc2   MLK-20478:VPU Encoder:drop invalid frame ... Browse Code »

    Signed-off-by: ming_qian

    ming_qian
     
  • a2eb45252   MLK-20337 drm/imx: lcdif: block 'active CRTC with no plane' commit ... Browse Code »

    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)

    Fancy Fang
     
  • 7239adb68   MLK-20476:VPU Encoder:define max resolution and framerate in dts ... Browse Code »

    Signed-off-by: ming_qian

    ming_qian
     

27 Nov, 2018

11 commits

26 Nov, 2018

2 commits

  • 8220d7d4e   MLK-20166 can: flexcan: fix CAN can't wakeup system during suspend ... Browse Code »

    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

    Joakim Zhang
     
  • 0a182dbaf   MLK-20131 can: flexcan: fix CAN can't suspend/resume when CAN is only capable of wakeup ... Browse Code »

    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

    Fugang Duan
     

23 Nov, 2018

8 commits