27 Mar, 2020

1 commit


06 Dec, 2019

1 commit


25 Nov, 2019

1 commit


15 Nov, 2019

2 commits


14 Nov, 2019

1 commit


11 Nov, 2019

1 commit


05 Nov, 2019

1 commit


01 Nov, 2019

1 commit


18 Apr, 2019

1 commit

  • On i.MX8MM, we are running Dual Linux OS, with 1st Linux using SD Card
    as rootfs storage, 2nd Linux using eMMC as rootfs storage. We let the
    the 1st linux configure power/clock for the 2nd Linux.

    When the 2nd Linux is booting into rootfs stage, we let the 1st Linux
    to destroy the 2nd linux, then restart the 1st linux, we met SDHCI dump
    as following, after we clear the pending interrupt and halt CQCTL, issue
    gone.

    [ 1.334594] mmc2: Got command interrupt 0x00000001 even though no command operation was in progress.
    [ 1.334595] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
    [ 1.334599] mmc2: sdhci: Sys addr: 0xa05dcc00 | Version: 0x00000002
    [ 1.340819] lib80211: common routines for IEEE802.11 drivers
    [ 1.345538] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000000
    [ 1.345541] mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000033
    [ 1.345543] mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000031
    [ 1.345547] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080
    [ 1.357903] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000003f
    [ 1.357905] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000
    [ 1.357908] mmc2: sdhci: Int enab: 0x107f100b | Sig enab: 0x107f100b
    [ 1.357911] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502
    [ 1.370268] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400
    [ 1.370270] mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff
    [ 1.370273] mmc2: sdhci: Resp[0]: 0x00000b00 | Resp[1]: 0xffffffff
    [ 1.370276] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00
    [ 1.382132] mmc2: sdhci: Host ctl2: 0x00000000
    [ 1.382135] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xa2040208

    [ 2.060932] mmc2: Unexpected interrupt 0x00004000.
    [ 2.065538] mmc2: sdhci: ============ SDHCI REGISTER DUMP ===========
    [ 2.071720] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00000002
    [ 2.077902] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001
    [ 2.084083] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
    [ 2.090264] mmc2: sdhci: Present: 0x01f88009 | Host ctl: 0x00000011
    [ 2.096446] mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080
    [ 2.102627] mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x000010ff
    [ 2.108809] mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00004000
    [ 2.114990] mmc2: sdhci: Int enab: 0x007f1003 | Sig enab: 0x007f1003
    [ 2.121171] mmc2: sdhci: AC12 err: 0x00000000 | Slot int: 0x00000502
    [ 2.127353] mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x0000b400
    [ 2.133534] mmc2: sdhci: Cmd: 0x0000371a | Max curr: 0x00ffffff
    [ 2.139715] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0xffffffff
    [ 2.145896] mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d00f00
    [ 2.152077] mmc2: sdhci: Host ctl2: 0x00000000
    [ 2.156342] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000

    Signed-off-by: Peng Fan
    Reviewed-by: Haibo Chen

    Peng Fan
     

15 Apr, 2019

1 commit


14 Apr, 2019

1 commit

  • With small buffer size, the resume will be triggered after suspend
    immediately, if we reserve the period done message to be sent with
    the next command, one period time later, it will cause underrun in
    m4 side, for ALSA thought the appl_ptr is updated, but the command
    won't be sent to M4 immediately, M4 don't have enough data to play.

    In this patch, we check that if the left size in the buffer is less
    that one period, the work queue will be triggered to send the period
    done message immediately.

    Fixes: 348d47695622 ("MLK-21307: ASoC: fsl_rpmsg_i2s: optimize
    the message sent to m4")
    Signed-off-by: Shengjiu Wang

    (cherry picked from commit 3dfecae40765329c0b7de1157f97ade24ecfce6d)

    Shengjiu Wang
     

12 Apr, 2019

8 commits

  • The overlay fb can only be enabled when the LCDIF is not in
    running, otherwise overlay display may look like image shift.
    So during the system resume procedure, the overlay fb should
    be resumed before mxsfb unblank.

    Signed-off-by: Fancy Fang
    (cherry picked from commit f39662a3a38a2da082d55a006e634766cc85e347)

    Fancy Fang
     
  • Do HW reset for communication port after the port is registered
    if the UART controller support the feature.

    Do partition reset with LPUART's power on, LPUART registers will
    keep the previous status, like on i.MX8QM platform, which is not
    expected action, so reset the HW is required.

    Currently, only i.MX7ULP and i.MX8QM LPUART controllers include
    global register that support HW reset.

    Tested-by: Robin Gong
    Tested-by: Peng Fan
    Reviewed-by: Robby Cai
    Signed-off-by: Fugang Duan
    (cherry picked from commit c2bc1f62ec28981462c9cb5ceac17134931ca19f)

    Fugang Duan
     
  • edma interrupt maybe happened during reboot or watchdog reset, meanwhile
    gic never power down on i.mx8QM/QXP, thus the unexpect irq will come in
    once edma driver request irq at probe phase. Unfortunately, at that time
    that edma channel's power domain which power-up by customer driver such
    as audio/uart driver may not be ready, so kernel panic triggered once
    touch such edma registers which still not power up in interrupt handler.
    Move request irq from probe to alloc dma channel so that edma channel's
    power domain has already been powered, besides, clear meaningless
    interrupt before request irq.

    Signed-off-by: Robin Gong
    Acked-by: Fugang Duan
    (cherry picked from commit 0a0d8f8b944094342fda18f23f3ac13b8a73871d)

    Robin Gong
     
  • M4 complain that there are two much period done message sent to m4, that
    M4 don't have enough time to handle these messages.

    The solution for this issue is to reduce the number of period done message.
    We allocate a specific memory for period done message, every time there is
    period done coming, it will be writed to this memory, not write it directly
    to the work queue, that queue will not be overflow, and the old period done
    message will be overwrited.

    In the rpmsg_i2s_work, we first check if there is period done message, then
    send it first, after that, send the command in queue.

    Signed-off-by: Shengjiu Wang
    Reviewed-by: Daniel Baluta
    (cherry picked from commit caabdfa176453cc7c8d6521f7865a670a7265a18)

    Shengjiu Wang
     
  • Previously we add snd_soc_find_dai to check if the codec is probed or
    not, but this bring kernel dump issue when CONFIG_LOCKDEP=y.

    [ 2.823379] WARNING: CPU: 2 PID: 1 at sound/soc/soc-core.c:1016 snd_soc_find_dai+0x144/0x150
    [ 2.831827] Modules linked in:
    [ 2.834907] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.78-00007-g524e1b1f0b3f #18
    [ 2.842748] Hardware name: FSL i.MX8MM EVK board (DT)
    [ 2.847811] task: ffff8000624f0000 task.stack: ffff000008078000
    [ 2.853745] PC is at snd_soc_find_dai+0x144/0x150
    [ 2.858462] LR is at snd_soc_find_dai+0x140/0x150

    ...

    [ 3.469675] Call trace:
    [ 3.472135] Exception stack(0xffff00000807ba40 to 0xffff00000807bb80)
    [ 3.478590] ba40: 0000000000000000 00000000ffffffff 0000000000000000 0000000000000002
    [ 3.4864333.596564] [] bus_add_driver+0x110/0x230
    [ 3.602149] [] driver_register+0x68/0x100
    [ 3.607735] [] __platform_driver_register+0x54/0x60
    [ 3.614191] [] imx_rpmsg_driver_init+0x20/0x28
    [ 3.620213] [] do_one_initcall+0x44/0x130
    [ 3.625801] [] kernel_init_freeable+0x1e0/0x280
    [ 3.631909] [] kernel_init+0x18/0x110
    [ 3.637148] [] ret_from_fork+0x10/0x1c

    So we could't resolve the warning "snd_soc_register_card failed (-517)".

    Fixes: 2bf5f9704785 ("MLK-19854-1: ASoC: imx-cs42888: fix error when m4
    image is not loaded")
    Signed-off-by: Shengjiu Wang

    (cherry picked from commit 58ffdf239288cfa6904640fc8432c182cf56589b)

    Shengjiu Wang
     
  • Previously we add snd_soc_find_dai to check if the codec is probed or
    not, but this bring kernel dump issue when CONFIG_LOCKDEP=y.

    [ 2.823379] WARNING: CPU: 2 PID: 1 at sound/soc/soc-core.c:1016 snd_soc_find_dai+0x144/0x150
    [ 2.831827] Modules linked in:
    [ 2.834907] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.78-00007-g524e1b1f0b3f #18
    [ 2.842748] Hardware name: FSL i.MX8MM EVK board (DT)
    [ 2.847811] task: ffff8000624f0000 task.stack: ffff000008078000
    [ 2.853745] PC is at snd_soc_find_dai+0x144/0x150
    [ 2.858462] LR is at snd_soc_find_dai+0x140/0x150

    ...

    [ 3.469675] Call trace:
    [ 3.472135] Exception stack(0xffff00000807ba40 to 0xffff00000807bb80)
    [ 3.478590] ba40: 0000000000000000 00000000ffffffff 0000000000000000 0000000000000002
    [ 3.4864333.596564] [] bus_add_driver+0x110/0x230
    [ 3.602149] [] driver_register+0x68/0x100
    [ 3.607735] [] __platform_driver_register+0x54/0x60
    [ 3.614191] [] imx_rpmsg_driver_init+0x20/0x28
    [ 3.620213] [] do_one_initcall+0x44/0x130
    [ 3.625801] [] kernel_init_freeable+0x1e0/0x280
    [ 3.631909] [] kernel_init+0x18/0x110
    [ 3.637148] [] ret_from_fork+0x10/0x1c

    So we could't resolve the warning "snd_soc_register_card failed (-517)".

    Fixes: a52c88bc3932 ("MLK-19854-1: ASoC: imx-wm8960: fix error when m4
    image is not loaded")
    Signed-off-by: Shengjiu Wang

    (cherry picked from commit f5d9013702e172a243da74a42941a62283bbe4a8)

    Shengjiu Wang
     
  • Previously we add snd_soc_find_dai to check if the codec is probed or
    not, but this bring kernel dump issue when CONFIG_LOCKDEP=y.

    [ 2.823379] WARNING: CPU: 2 PID: 1 at sound/soc/soc-core.c:1016 snd_soc_find_dai+0x144/0x150
    [ 2.831827] Modules linked in:
    [ 2.834907] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.14.78-00007-g524e1b1f0b3f #18
    [ 2.842748] Hardware name: FSL i.MX8MM EVK board (DT)
    [ 2.847811] task: ffff8000624f0000 task.stack: ffff000008078000
    [ 2.853745] PC is at snd_soc_find_dai+0x144/0x150
    [ 2.858462] LR is at snd_soc_find_dai+0x140/0x150

    ...

    [ 3.469675] Call trace:
    [ 3.472135] Exception stack(0xffff00000807ba40 to 0xffff00000807bb80)
    [ 3.478590] ba40: 0000000000000000 00000000ffffffff 0000000000000000 0000000000000002
    [ 3.4864333.596564] [] bus_add_driver+0x110/0x230
    [ 3.602149] [] driver_register+0x68/0x100
    [ 3.607735] [] __platform_driver_register+0x54/0x60
    [ 3.614191] [] imx_rpmsg_driver_init+0x20/0x28
    [ 3.620213] [] do_one_initcall+0x44/0x130
    [ 3.625801] [] kernel_init_freeable+0x1e0/0x280
    [ 3.631909] [] kernel_init+0x18/0x110
    [ 3.637148] [] ret_from_fork+0x10/0x1c

    So we could't resolve the warning "snd_soc_register_card failed (-517)".

    Fixes: 75632b22a332 ("MLK-20247: ASoC: imx-rpmsg: fix error when
    m4 image is not loaded")
    Signed-off-by: Shengjiu Wang

    (cherry picked from commit bbc1868d1c3ec448301d76606e7199f74aa35581)

    Shengjiu Wang
     
  • With CONFIG_LOCKDEP=y, there will kernel dump

    [ 55.305563] INFO: trying to register non-static key.
    [ 55.310540] the code is fine but needs lockdep annotation.
    [ 55.316027] turning off the locking correctness validator.
    [ 55.321520] CPU: 0 PID: 32 Comm: kworker/0:1 Tainted: G W 4.14.78-00007-g524e1b1f0b3f #18
    [ 55.330827] Hardware name: FSL i.MX8MM EVK board (DT)
    [ 55.335892] Workqueue: events rpmsg_work_handler
    [ 55.340515] Call trace:
    [ 55.342971] [] dump_backtrace+0x0/0x270
    [ 55.348375] [] show_stack+0x24/0x30
    [ 55.353433] [] dump_stack+0xb8/0xf0
    [ 55.358490] [] register_lock_class+0x364/0x548
    [ 55.364501] [] __lock_acquire+0x7c/0x18a8
    [ 55.370077] [] lock_acquire+0xc8/0x290
    [ 55.375394] [] _raw_spin_lock_irqsave+0x54/0x70
    [ 55.381493] [] i2s_rpmsg_cb+0xe8/0x1b0
    [ 55.386810] [] rpmsg_recv_done+0x144/0x210
    [ 55.392476] [] vring_interrupt+0x44/0x78
    [ 55.397966] [] imx_mu_rpmsg_callback+0x6c/0x80
    [ 55.403977] [] notifier_call_chain+0x5c/0x98
    [ 55.409813] [] __blocking_notifier_call_chain+0x58/0xa0
    [ 55.416605] [] blocking_notifier_call_chain+0x3c/0x50
    [ 55.423223] [] rpmsg_work_handler+0x88/0xe8
    [ 55.428974] [] process_one_work+0x290/0x738
    [ 55.434723] [] worker_thread+0x58/0x460
    [ 55.440127] [] kthread+0x104/0x130
    [ 55.445096] [] ret_from_fork+0x10/0x1c

    The reason is that the spin lock is not initilized.

    Signed-off-by: Shengjiu Wang
    (cherry picked from commit 0e98ac55f17f6505f92c515c3c04581039e21865)

    Shengjiu Wang
     

11 Apr, 2019

1 commit


10 Apr, 2019

5 commits


29 Mar, 2019

4 commits


28 Mar, 2019

6 commits

  • It isn't used out side of the file for now.

    Signed-off-by: Liu Ying
    (cherry picked from commit 13a0d5c3b15e42834b872b0da904f874ff717500)

    Liu Ying
     
  • Due to TKT320590, we are asked to turn TCON into operation mode later after
    the first dumb frame is generated by DPU. This makes DPR/PRG be able to
    evade the frame. However, it turns out we have to set the TCON into operation
    mode first and then wait for Framegen frame counter moving, otherwise, the
    display pipeline cannot be setup correctly sometimes(If pixel combiner is used,
    one of the two display streams is likely broken). This is a mysterious issue.
    So, we've already taken a workaround for the cases where pixel combiner is used.

    It appears that the similar issue is likely to happen for cases where pixel
    combiner is unused. That is to say, if pixel combiner is unused and prefetch
    engine is used, the first atomic flush after the enablement is likely to fail -
    content shadow load irq doesn't come. The sequence which the patch takes is
    the same to the one taken by the previous workaround. Based on tests, it is
    valid for cases with or without pixel combiner.

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

    Liu Ying
     
  • To avoid potential division by zero in ipu_init_sync_panel(),
    let's check the rounded_pixel_clk rate prior to that.

    Detected by CoverityScan, CID#56278 ("Division or modulo by zero")

    Signed-off-by: Liu Ying
    (cherry picked from commit 1523150b71f1aa0610f61ea47a9f3bdbcda92522)

    Liu Ying
     
  • To avoid potential division by zero in ipu_init_async_panel(),
    let's check the di_clk rate prior to that.

    Detected by CoverityScan, CID#56264 ("Division or modulo by zero")

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

    Liu Ying
     
  • To avoid potential out of bounds array access on tbl->used[][],
    let's check the tsk->ipu_id prior to that. Based on the context,
    this is what we can do to make the coverity happy.

    Detected by CoverityScan, CID#17689 ("Derefernece before null check")

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

    Liu Ying
     
  • The check on !sp_tsk0 is unnecessary in ipu_task_thread(), because the
    beforehand "list_del(&sp_tsk0->node);" within the context implies sp_tsk0
    is not null, otherwise, we'll dereference a null pointer earlier.

    Detected by CoverityScan, CID#17842 ("Logically dead code")

    Signed-off-by: Liu Ying
    (cherry picked from commit 9ad5edd076d61bc8bb3a558e523cc7b31f2c3043)

    Liu Ying
     

27 Mar, 2019

4 commits

  • Because we are re-initializing the proxy at close it might
    happen that work is still pending which causes the following crash:

    [ 94.699835] Unable to handle kernel NULL pointer dereference at virtual address 00000008
    [ 94.707923] Mem abort info:
    [ 94.710722] Exception class = DABT (current EL), IL = 32 bits
    [ 94.716637] SET = 0, FnV = 0
    [ 94.719686] EA = 0, S1PTW = 0
    [ 94.722822] Data abort info:
    [ 94.725698] ISV = 0, ISS = 0x00000005
    [ 94.729530] CM = 0, WnR = 0
    [ 94.732504] user pgtable: 4k pages, 48-bit VAs, pgd = ffff8008d9ba3000
    [ 94.739035] [0000000000000008] *pgd=0000000938419003, *pud=0000000000000000
    [ 94.746015] Internal error: Oops: 96000005 [#1] PREEMPT SMP
    [ 94.751589] Modules linked in:
    [ 94.754652] CPU: 0 PID: 2068 Comm: kworker/0:2 Not tainted 4.14.98-dirty #75
    [ 94.761700] Hardware name: Freescale i.MX8QM MEK (DT)
    [ 94.766768] task: ffff8008f23ae200 task.stack: ffff000014378000
    [ 94.772705] PC is at process_one_work+0x34/0x414
    [ 94.777325] LR is at process_one_work+0x1e0/0x414

    In order to fix this, we make sure that no work is pending before starting
    the re-initialization.

    Signed-off-by: Daniel Baluta
    Reviewed-by: Shengjiu Wang
    (cherry picked from commit 2c00c24be5f8b63636e3f9005e15a3de42058438)

    Daniel Baluta
     
  • Double check that the DTG IRQ STATUS register bit is set when handling
    the vblank and CTXLD kick interrupts to make sure we avoid spurious
    interrupts and kick the CTXLD in a bad moment.

    Signed-off-by: Laurentiu Palcu
    Reviewed-by: Robert Chiras
    (cherry picked from commit cc56e4e07f623d0b831e0f8347f2f3198697ee20)

    Laurentiu Palcu
     
  • Using one completion variable is not feasible as we can hit corner cases like
    enabling and then quickly disabling DCSS where we end up signaling that DTG was
    correctly disabled when, in fact, a VBLANK interrupt was received.

    Signed-off-by: Laurentiu Palcu
    Reviewed-by: Robert Chiras
    (cherry picked from commit 8073e87dce34548bea758c34d3b3557819c75551)

    Laurentiu Palcu
     
  • Currently, we set the colorimetry to BT.2020 even if the color-depth is
    8 bit. This is not according to HDMI specification.

    This patch makes sure we follow the specs.

    Signed-off-by: Laurentiu Palcu
    CC: Sandor Yu
    Reviewed-by: Sandor Yu
    Reviewed-by: Robert Chiras
    (cherry picked from commit cdacfaadd5dccfdca5dd68640d8f08506f6a9114)

    Laurentiu Palcu