Eric Lee / smarc-fsl-linux-kernel

30 May, 2020

1 commit

  • c159d5614   HSM-292 firmware: imx: seco_mu: Increase MAX_DATA_SIZE_PER_USER ... Browse Code »

    For AES CMAC, the max supported message length is (2^16)-1. In order to
    support this type of message the MAX_DATA_SIZE_PER_USER must be
    increased to bigger value, in order to contains the message header and
    the entire message data

    Signed-off-by: Hugo Dupras
    Reviewed-by: Stéphane Dion
    (cherry picked from commit 80438c2b525f0273c93c820c3f3ac6dc68709624)

    Hugo Dupras
     

29 May, 2020

4 commits

28 May, 2020

2 commits

27 May, 2020

3 commits

26 May, 2020

1 commit

  • abecdef94   MLK-23540 dmaengine: imx-sdma: restore DONEx_CONFIG register ... Browse Code »

    There are two more DONE0_CONFIG/DONE1_CONFIG registers on i.mx8m family.
    Add them to save/restore register list during systerm level suspend/
    resume to restore them after resume back, otherwise, PDM case maybe failed
    in suspend/resume case.

    Signed-off-by: Robin Gong
    Reviewed-by: Shengjiu Wang
    (cherry picked from commit 2c213d8ac495065f5ec4182335c151d32d0eb482)

    Robin Gong
     

22 May, 2020

2 commits

  • 9c0918aea   LF-1043: drm/bridge: nwl-dsi: Assert mipi resets before enable ... Browse Code »

    Apparently, in order to enable the MIPI block, the reset signals must
    be in asserted mode, in order to proper de-assert and initialize the
    MIPI block. So, before the enable process, assert all the MIPI resets.

    Signed-off-by: Robert Chiras

    Robert Chiras
     
  • 1a318ed76   MLK-24090 mxc: ipu3: ipu_device: Fix AB-BA deadlock between vdoa_lock and ipu_ch_tbl.lock ... Browse Code »

    In VDOA_MODE, _get_vdoa_ipu_res() would lock ipu_ch_tbl.lock mutex first,
    then lock vdoa_lock mutex and finally unlock ipu_ch_tbl.lock mutex.
    The vdoa_lock mutex is unlocked until put_vdoa_ipu_res(). Since the two
    mutexes are not unlocked in a reversed order as they are locked, AB-BA
    deadlock issue may happen as the below warning shows, which can be detected
    with the debug option CONFIG_PROVE_LOCKING enabled.

    [ 52.398770] ======================================================
    [ 52.404957] WARNING: possible circular locking dependency detected
    [ 52.411145] 5.4.24 #1477 Not tainted
    [ 52.414728] ------------------------------------------------------
    [ 52.420915] ipu1_task/92 is trying to acquire lock:
    [ 52.425800] 81f02274 (&ipu_ch_tbl.lock){+.+.}, at: get_res_do_task+0x144/0x77c
    [ 52.433050]
    [ 52.433050] but task is already holding lock:
    [ 52.438888] 8183189c (vdoa_lock){+.+.}, at: vdoa_get_handle+0x64/0x158
    [ 52.445434]
    [ 52.445434] which lock already depends on the new lock.
    [ 52.445434]
    [ 52.453615]
    [ 52.453615] the existing dependency chain (in reverse order) is:
    [ 52.461101]
    [ 52.461101] -> #1 (vdoa_lock){+.+.}:
    [ 52.466175] __mutex_lock+0xb8/0xaa8
    [ 52.470283] mutex_lock_nested+0x2c/0x34
    [ 52.474735] vdoa_get_handle+0x64/0x158
    [ 52.479100] _get_vdoa_ipu_res+0x2b4/0x338
    [ 52.483726] get_res_do_task+0x34/0x77c
    [ 52.488092] ipu_task_thread+0x148/0xeb0
    [ 52.492551] kthread+0x168/0x170
    [ 52.496310] ret_from_fork+0x14/0x20
    [ 52.500414] 0x0
    [ 52.502779]
    [ 52.502779] -> #0 (&ipu_ch_tbl.lock){+.+.}:
    [ 52.508457] __lock_acquire+0x15d0/0x2588
    [ 52.512995] lock_acquire+0xdc/0x280
    [ 52.517103] __mutex_lock+0xb8/0xaa8
    [ 52.521210] mutex_lock_nested+0x2c/0x34
    [ 52.525662] get_res_do_task+0x144/0x77c
    [ 52.530113] ipu_task_thread+0x148/0xeb0
    [ 52.534566] kthread+0x168/0x170
    [ 52.538322] ret_from_fork+0x14/0x20
    [ 52.542425] 0x0
    [ 52.544790]
    [ 52.544790] other info that might help us debug this:
    [ 52.544790]
    [ 52.552797] Possible unsafe locking scenario:
    [ 52.552797]
    [ 52.558721] CPU0 CPU1
    [ 52.563256] ---- ----
    [ 52.567790] lock(vdoa_lock);
    [ 52.570853] lock(&ipu_ch_tbl.lock);
    [ 52.577040] lock(vdoa_lock);
    [ 52.582619] lock(&ipu_ch_tbl.lock);
    [ 52.586289]
    [ 52.586289] *** DEADLOCK ***
    [ 52.586289]
    [ 52.592215] 1 lock held by ipu1_task/92:
    [ 52.596142] #0: 8183189c (vdoa_lock){+.+.}, at: vdoa_get_handle+0x64/0x158
    [ 52.603123]
    [ 52.603123] stack backtrace:
    [ 52.607493] CPU: 0 PID: 92 Comm: ipu1_task Not tainted 5.4.24 #1477
    [ 52.613765] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
    [ 52.620298] Backtrace:
    [ 52.622764] [] (dump_backtrace) from [] (show_stack+0x20/0x24)
    [ 52.630345] r7:818641a8 r6:00000000 r5:600f0193 r4:818641a8
    [ 52.636026] [] (show_stack) from [] (dump_stack+0xbc/0xe8)
    [ 52.643261] [] (dump_stack) from [] (print_circular_bug+0x1c4/0x214)
    [ 52.651361] r10:a8330000 r9:ffffffff r8:a8330000 r7:a8330550 r6:81d13b1c r5:81d13ac0
    [ 52.659197] r4:81d13ac0 r3:46e9f8d1
    [ 52.662783] [] (print_circular_bug) from [] (check_noncircular+0x204/0x21c)
    [ 52.671492] r9:00000001 r8:81708f50 r7:00000000 r6:a8423a98 r5:a8330530 r4:a8330550
    [ 52.679245] [] (check_noncircular) from [] (__lock_acquire+0x15d0/0x2588)
    [ 52.687778] r8:81708f50 r7:81d13ac0 r6:00000001 r5:81e93d7c r4:a8330530
    [ 52.694491] [] (__lock_acquire) from [] (lock_acquire+0xdc/0x280)
    [ 52.702334] r10:00000000 r9:00000000 r8:00000000 r7:81f02274 r6:600f0113 r5:81708724
    [ 52.710169] r4:00000000
    [ 52.712717] [] (lock_acquire) from [] (__mutex_lock+0xb8/0xaa8)
    [ 52.720384] r10:81e93d7c r9:0000f6d0 r8:81f022e8 r7:00008f50 r6:00000000 r5:ffffe000
    [ 52.728219] r4:81f02240
    [ 52.730765] [] (__mutex_lock) from [] (mutex_lock_nested+0x2c/0x34)
    [ 52.738778] r10:00000000 r9:a8423ccc r8:81f022e8 r7:000002d0 r6:8188b6f8 r5:81f02234
    [ 52.746613] r4:a4540400
    [ 52.749162] [] (mutex_lock_nested) from [] (get_res_do_task+0x144/0x77c)
    [ 52.757612] [] (get_res_do_task) from [] (ipu_task_thread+0x148/0xeb0)
    [ 52.765886] r10:a8139bd0 r9:a8423ccc r8:81f022e8 r7:a4540400 r6:81831604 r5:a454053c
    [ 52.773721] r4:600f0013
    [ 52.776269] [] (ipu_task_thread) from [] (kthread+0x168/0x170)
    [ 52.783849] r10:a8139bd0 r9:80b8d558 r8:81f022e8 r7:a8422000 r6:00000000 r5:a840cd00
    [ 52.791684] r4:a83cc080
    [ 52.794231] [] (kthread) from [] (ret_from_fork+0x14/0x20)
    [ 52.801460] Exception stack(0xa8423fb0 to 0xa8423ff8)
    [ 52.806521] 3fa0: 00000000 00000000 00000000 00000000
    [ 52.814711] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    [ 52.822898] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
    [ 52.829521] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:80168360
    [ 52.837356] r4:a840cd00

    This patch corrects the locking/unlocking sequence for the two mutexes
    to fix the deadlock issue.

    Reviewed-by: Sandor Yu
    Signed-off-by: Liu Ying
    (cherry picked from commit c18ff376db6529818037a66b2cafaa3f512577d8)

    Liu Ying
     

21 May, 2020

2 commits

20 May, 2020

2 commits

  • 334a82c65   MLK-23860: media: imx: improve calculation for csi RXHS_SETTLE parameter ... Browse Code »

    According to Mixel MIPI CSI PHY spec, the minimum value for RXHS_SETTLE
    is 85ns + 6*UI and the maximum value for RXHS_SETTLE is 145ns + 10*UI,
    so get average value of maximum and minimum as RXHS_SETTLE typical value.

    Signed-off-by: Guoniu.zhou
    Reviewed-by: Sandor Yu
    (cherry picked from commit af684872dceece899b439b6167343b1e7655a251)

    Guoniu.zhou
     
  • c8078eb46   MLK-24071 dmaengine: imx-sdma: fix random channel stop ... Browse Code »

    The legacy terminate_worker may terminate the next transfer if it comes
    before all jobs done in terminated_worker, or refuse to setup next transfer
    since sdmac->desc may not be NULL in sdma_issue_pending(). That case could
    be easily caught in Audio play in case underrun happen at ALSA level which
    means dma channel will be terminated and start again very frequently.
    So move the logic part of 'sdmac->desc' into sdma_disable_channel_async but
    leave the desc free in the work to kill the above case.

    Signed-off-by: Robin Gong
    Reviewed-by: Shengjiu Wang
    (cherry picked from commit acf2a79f1f73b1cf59b2e3dc096ff4340cfe7687)

    Robin Gong
     

19 May, 2020

1 commit

  • 32ddab975   MLK-24045 drm/imx: sec-dsim: let host unregister later than device ... Browse Code »

    During the unbind() procedure, drm_encoder_cleanup() will
    detach the downstream DSI bridge if exists. And the DSI
    bridge's detach() will detach itself from the DSI host.
    So DSI host should be unregistered later than DSI device
    detach. Otherwise, below kernel panic happens:

    [ 2.437740] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000007
    [ 2.446534] Mem abort info:
    [ 2.449327] ESR = 0x96000004
    [ 2.452401] EC = 0x25: DABT (current EL), IL = 32 bits
    [ 2.457717] SET = 0, FnV = 0
    [ 2.460777] EA = 0, S1PTW = 0
    [ 2.463921] Data abort info:
    [ 2.466808] ISV = 0, ISS = 0x00000004
    [ 2.470649] CM = 0, WnR = 0
    [ 2.473617] [0000000000000007] user address but active_mm is swapper
    [ 2.479978] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [ 2.485550] Modules linked in:
    [ 2.488609] CPU: 0 PID: 188 Comm: kworker/0:2 Not tainted 5.4.24-04902-g14319eb2bae3 #1683
    [ 2.496871] Hardware name: NXP i.MX8MPlus EVK board (DT)
    [ 2.502188] Workqueue: events deferred_probe_work_func
    [ 2.507328] pstate: 80000005 (Nzcv daif -PAN -UAO)
    [ 2.512121] pc : mipi_dsi_detach+0x10/0x38
    [ 2.516219] lr : adv7533_detach_dsi+0x18/0x30
    [ 2.520574] sp : ffff80001242b6e0
    [ 2.523885] x29: ffff80001242b6e0 x28: ffff8000119d6000
    [ 2.529196] x27: 0000000000000000 x26: 00000000fffffdfb
    [ 2.534507] x25: 0000000000000001 x24: ffff8000115159f0
    [ 2.539819] x23: ffff000176652120 x22: ffff800011b94000
    [ 2.545132] x21: ffff000177882000 x20: ffff0001778766e8
    [ 2.550444] x19: ffff000177876880 x18: 0000000000000000
    [ 2.555756] x17: ffff800011e0d000 x16: 0000000000000000
    [ 2.561068] x15: 0000000000000004 x14: ffffffffffffffff
    [ 2.566381] x13: 0000000000000000 x12: ffff0001745765c8
    [ 2.571694] x11: ffff000174576480 x10: 0000000000000040
    [ 2.577006] x9 : ffff000176020e98 x8 : ffff000176020e90
    [ 2.582318] x7 : 0000000000000001 x6 : 0000000000000001
    [ 2.587630] x5 : 0000000000000000 x4 : 0000000000000000
    [ 2.592943] x3 : ffff800011a398b0 x2 : ffffffffffffffff
    [ 2.598255] x1 : ffff0001778d5c00 x0 : ffff0001778d6400
    [ 2.603569] Call trace:
    [ 2.606018] mipi_dsi_detach+0x10/0x38
    [ 2.609769] adv7511_bridge_detach+0x6c/0x80
    [ 2.614041] drm_bridge_detach+0x2c/0x50
    [ 2.617964] drm_encoder_cleanup+0x2c/0xa0
    [ 2.622063] imx_sec_dsim_unbind+0x50/0x68
    [ 2.626159] component_unbind.isra.0+0x2c/0x50
    [ 2.630601] component_bind_all+0x1e0/0x228
    [ 2.634784] imx_drm_bind+0xb8/0x150
    [ 2.638357] try_to_bring_up_master+0x164/0x1c0
    [ 2.642887] __component_add+0xa0/0x168
    [ 2.646721] component_add+0x10/0x18
    [ 2.650297] lcdifv3_crtc_probe+0x4c/0x78
    [ 2.654309] platform_drv_probe+0x50/0xa0
    [ 2.658317] really_probe+0xd4/0x318
    [ 2.661891] driver_probe_device+0x54/0xe8
    [ 2.665991] __device_attach_driver+0x80/0xb8
    [ 2.670348] bus_for_each_drv+0x74/0xc0
    [ 2.674183] __device_attach+0xdc/0x138
    [ 2.678020] device_initial_probe+0x10/0x18
    [ 2.682204] bus_probe_device+0x90/0x98
    [ 2.686042] device_add+0x378/0x648
    [ 2.689531] platform_device_add+0xfc/0x228
    [ 2.693718] imx_lcdifv3_probe+0x2b0/0x388
    [ 2.697814] platform_drv_probe+0x50/0xa0
    [ 2.701825] really_probe+0xd4/0x318
    [ 2.705403] driver_probe_device+0x54/0xe8
    [ 2.709502] __device_attach_driver+0x80/0xb8
    [ 2.713859] bus_for_each_drv+0x74/0xc0
    [ 2.717696] __device_attach+0xdc/0x138
    [ 2.721535] device_initial_probe+0x10/0x18
    [ 2.725721] bus_probe_device+0x90/0x98
    [ 2.729555] deferred_probe_work_func+0x64/0x98
    [ 2.734089] process_one_work+0x198/0x320
    [ 2.738100] worker_thread+0x1f0/0x420
    [ 2.741850] kthread+0xf0/0x120
    [ 2.744993] ret_from_fork+0x10/0x18
    [ 2.748573] Code: aa0003e1 f9400000 f9400402 b4000102 (f9400442)
    [ 2.754667] ---[ end trace 756e3cdcc6c5557e ]---

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

    Fancy Fang
     

18 May, 2020

2 commits

16 May, 2020

2 commits

15 May, 2020

11 commits

  • 4d1398fb5   LF-621: drm/imx/dcss: add back disabled formats ... Browse Code »

    The YUV formats were removed from graphics plane and RGB ones were removed from
    video planes. That's because, in general, one will use a window manager and the
    UI will always reside on the graphics plane, while video playback will go to
    the overlay planes.

    However, this move affects users using custom applications that would like to
    use 2 graphics planes and one video plane. Or 3 graphics planes.

    DCSS is perfectly capable of scanning out RGB/YUV linear formats on all 3
    pipes. Only tiled and tiled-compressed formats need special treatment:
    tiled-compressed graphics has to always go to pipe 1 (since DEC400D is needed
    for uncompressing the graphics format) whilst tiled-uncompressed and
    tiled-compressed VPU formats need to always go to pipes 2 and 3 (DTRC will
    handle de-tiling and decompression).

    Signed-off-by: Laurentiu Palcu
    Reviewed-by: Robert Chiras

    Laurentiu Palcu
     
  • c6407ffb3   MLK-24002-2 drm/imx: lcdifv3: put controller enable to CRTC ... Browse Code »

    Move the controller enablement from atomic plane update to
    the CRTC's atomic enable, since some bridge(e.g. IT6263)
    requires data stream from CRTC to be ready for its config.

    But this controller enablement change won't cause any side
    effect, since the CRTC enable and plane update can be done
    in one frame interval and to next frame all configurations
    can take effect, which has the same behavior as before.

    Signed-off-by: Fancy Fang
    Reviewed-by: Liu Ying
    (cherry picked from commit ea4f7e2d01e9dde69a34a3e2f0a4d194f60080d2)

    Fancy Fang
     
  • 092c084f7   MLK-24002-1 drm/imx: lcdifv3: enable shadow load for plane update ... Browse Code »

    After the atomic plane update, the shadow load should be
    enabled to make sure its update can take effect on next
    frame in any cases. And this enable is better to be done
    in CRTC's atomic_flush() which is called after plane's
    atomic_update() is called.

    Besides, the shadow load enable in controller enable is
    unnecessary, so remove it.

    Signed-off-by: Fancy Fang
    Reviewed-by: Liu Ying
    (cherry picked from commit bfa7236c8477e8993f074a3068ddc64c1614db06)

    Fancy Fang
     
  • c78d56a52   MA-17115 mxc: vpu_malone: send error event when firmware exception ... Browse Code »

    When firmware exception, send error event instead of eos event,
    avoid doubt or might send eos event twice(exception + parsed eos data).

    Signed-off-by: Shijie Qin
    Reviewed-by: ming_qian
    (cherry picked from commit 2f97227dd635efa0c6ea965ab2d9f7fc9bafe9fb)

    Shijie Qin
     
  • 3a6c993ff   MLK-24009-4 arm64: imx8mq: vpu: g1/g2: fix build issue as module ... Browse Code »

    fix clk use-after-free issue

    Signed-off-by: Zhou Peng
    (cherry picked from commit 0d1b3814c976cb2148958f48c4c4f4701ced6b4e)

    Zhou Peng
     
  • 8714ba9e3   MLK-24009-3 arm64: imx8mm: vpu: h1: fix build issue as module ... Browse Code »

    release clk to avoid memory leak

    Signed-off-by: Zhou Peng
    (cherry picked from commit 420a357a1b43c57383c74a548a9a3714b6da7de2)

    Zhou Peng
     
  • d6ff32fcb   MLK-24009-2 arm64: imx8mp: vpu: g1/g2: fix build issue as module ... Browse Code »

    release clk to avoid memory leak

    Signed-off-by: Zhou Peng
    (cherry picked from commit 76d95bf26376a7f774f2939052e3595b8d2aefdb)

    Zhou Peng
     
  • 7482f2b33   MLK-24009-1 arm64: imx8mp: vpu: vc8000e: fix build issue as module ... Browse Code »

    change module device table name to fix build error as module
    rename the c source name to avoid conflict with h1
    release clk avoid memory leak
    fix typo error in core index

    Signed-off-by: Zhou Peng
    (cherry picked from commit 099a3ae272672978b7720257f012dcf38e537dc0)

    Zhou Peng
     
  • 484750502   MLK-24040: drm: imx: pavi: Combine pai and pvi powerup/down function ... Browse Code »

    Combine pvi and pai power up/down functions to pavi_powerup/down
    function. Move clock enable/disable function to power function.

    Signed-off-by: Sandor Yu

    Sandor Yu
     
  • 60cab0b5b   MLK-24011: mtd: nand: gpmi: removed the redundant runtime_pm ops ... Browse Code »

    remove the redundant pm_runtime_get_sync introduced in last code rebase

    Signed-off-by: Han Xu
    (cherry picked from commit 529d3dc133ad98f56f97a1f95880959943ff6084)

    Han Xu
     
  • 9e5a6994f   MLK-24007: mtd: rawnand: gpmi: fix the random DMA timeout issue ... Browse Code »

    To get better performance, current gpmi driver collected and chained all
    small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and
    wait for complete at the end.

    But some random DMA timeout found in this new driver, with the help of
    ftrace, we found the root cause is as follows:

    Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6
    DMA transfers and the DMA chain triggered at the end. It waits for bch
    completion and check jiffies if it's timeout. The typical function graph
    shown below,

    63.216351 | 1) | gpmi_ecc_read_page() {
    63.216352 | 1) 0.750 us | gpmi_bch_layout_std();
    63.216354 | 1) | gpmi_nfc_exec_op() {
    63.216355 | 1) | gpmi_chain_command() {
    63.216356 | 1) | mxs_dma_prep_slave_sg() {
    63.216357 | 1) | /* mxs chan ccw idx: 0 */
    63.216358 | 1) 1.750 us | }
    63.216359 | 1) | mxs_dma_prep_slave_sg() {
    63.216360 | 1) | /* mxs chan ccw idx: 1 */
    63.216361 | 1) 2.000 us | }
    63.216361 | 1) 6.500 us | }
    63.216362 | 1) | gpmi_chain_command() {
    63.216363 | 1) | mxs_dma_prep_slave_sg() {
    63.216364 | 1) | /* mxs chan ccw idx: 2 */
    63.216365 | 1) 1.750 us | }
    63.216366 | 1) | mxs_dma_prep_slave_sg() {
    63.216367 | 1) | /* mxs chan ccw idx: 3 */
    63.216367 | 1) 1.750 us | }
    63.216368 | 1) 5.875 us | }
    63.216369 | 1) | /* gpmi_chain_wait_ready */
    63.216370 | 1) | mxs_dma_prep_slave_sg() {
    63.216372 | 1) | /* mxs chan ccw idx: 4 */
    63.216373 | 1) 3.000 us | }
    63.216374 | 1) | /* gpmi_chain_data_read */
    63.216376 | 1) | mxs_dma_prep_slave_sg() {
    63.216377 | 1) | /* mxs chan ccw idx: 5 */
    63.216378 | 1) 2.000 us | }
    63.216379 | 1) 1.125 us | mxs_dma_tx_submit();
    63.216381 | 1) 1.000 us | mxs_dma_enable_chan();
    63.216712 | 0) 2.625 us | mxs_dma_int_handler();
    63.216717 | 0) 4.250 us | bch_irq();
    63.216723 | 0) 1.250 us | mxs_dma_tasklet();
    63.216723 | 1) | /* jiffies left 250 */
    63.216725 | 1) ! 372.000 us | }
    63.216726 | 1) 2.625 us | gpmi_count_bitflips();
    63.216730 | 1) ! 379.125 us | }

    but it's not gurantee that bch irq handled always after dma irq handled,
    sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore,
    another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ
    handled, this messed up the next DMA chain and causes DMA timeout. Check
    the trace log when issue happened.

    63.218923 | 1) | gpmi_ecc_read_page() {
    63.218924 | 1) 0.625 us | gpmi_bch_layout_std();
    63.218926 | 1) | gpmi_nfc_exec_op() {
    63.218927 | 1) | gpmi_chain_command() {
    63.218928 | 1) | mxs_dma_prep_slave_sg() {
    63.218929 | 1) | /* mxs chan ccw idx: 0 */
    63.218929 | 1) 1.625 us | }
    63.218931 | 1) | mxs_dma_prep_slave_sg() {
    63.218931 | 1) | /* mxs chan ccw idx: 1 */
    63.218932 | 1) 1.750 us | }
    63.218933 | 1) 5.875 us | }
    63.218934 | 1) | gpmi_chain_command() {
    63.218934 | 1) | mxs_dma_prep_slave_sg() {
    63.218935 | 1) | /* mxs chan ccw idx: 2 */
    63.218936 | 1) 1.875 us | }
    63.218937 | 1) | mxs_dma_prep_slave_sg() {
    63.218938 | 1) | /* mxs chan ccw idx: 3 */
    63.218939 | 1) 1.625 us | }
    63.218939 | 1) 5.875 us | }
    63.218940 | 1) | /* gpmi_chain_wait_ready */
    63.218941 | 1) | mxs_dma_prep_slave_sg() {
    63.218942 | 1) | /* mxs chan ccw idx: 4 */
    63.218942 | 1) 1.625 us | }
    63.218943 | 1) | /* gpmi_chain_data_read */
    63.218944 | 1) | mxs_dma_prep_slave_sg() {
    63.218945 | 1) | /* mxs chan ccw idx: 5 */
    63.218947 | 1) 2.375 us | }
    63.218948 | 1) 0.625 us | mxs_dma_tx_submit();
    63.218949 | 1) 1.000 us | mxs_dma_enable_chan();
    63.219276 | 0) 5.125 us | bch_irq();
    (cherry picked from commit 5dde5bcfd7fab7a6cb9974b79f7d36cbf64b85fb)

    Han Xu
     

14 May, 2020

1 commit

13 May, 2020

1 commit

  • 24daeb3a8   MLK-23995 mailbox: imx: fix build warning ... Browse Code »

    Fix below build warning:
    warning: format ‘%li’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
    "Exceed max msg size (%li) on TX, got: %i\n",

    Reviewed-by: Ye Li
    Signed-off-by: Peng Fan
    (cherry picked from commit 6566c7b54aef56d7a4bf83f75615c7c4d39f98ad)

    Peng Fan
     

12 May, 2020

5 commits