07 May, 2020

1 commit


29 Apr, 2020

1 commit


08 Mar, 2020

1 commit

  • Merge Linux stable release v5.4.24 into imx_5.4.y

    * tag 'v5.4.24': (3306 commits)
    Linux 5.4.24
    blktrace: Protect q->blk_trace with RCU
    kvm: nVMX: VMWRITE checks unsupported field before read-only field
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    arch/arm/boot/dts/imx6sll-evk.dts
    arch/arm/boot/dts/imx7ulp.dtsi
    arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
    drivers/clk/imx/clk-composite-8m.c
    drivers/gpio/gpio-mxc.c
    drivers/irqchip/Kconfig
    drivers/mmc/host/sdhci-of-esdhc.c
    drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
    drivers/net/can/flexcan.c
    drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
    drivers/net/ethernet/mscc/ocelot.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
    drivers/net/phy/realtek.c
    drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
    drivers/perf/fsl_imx8_ddr_perf.c
    drivers/tee/optee/shm_pool.c
    drivers/usb/cdns3/gadget.c
    kernel/sched/cpufreq.c
    net/core/xdp.c
    sound/soc/fsl/fsl_esai.c
    sound/soc/fsl/fsl_sai.c
    sound/soc/sof/core.c
    sound/soc/sof/imx/Kconfig
    sound/soc/sof/loader.c

    Jason Liu
     

13 Feb, 2020

1 commit

  • This allows the HDP i.MX8QM driver to load the firmware on init
    and resume. In order to have backward compatibility, if there is
    no firmware-name property defined in the hdmi node, the driver
    probing sequence skips the firmware loading.

    Also, if u-boot has loaded already a firmware, we run with that
    but when probing the driver, the request_firmware_nowait is used
    to locate and keep safe the firmware for when suspend/resume happens.

    This leads to 4 possible scenarios:

    1. u-boot loads the firmware, the kernel driver finds the firmware
    when rootfs is mounted. This is the most desirable scenario. Also
    this is the only scenario that allows the hdmi to work after resume.

    2. u-boot loads the firmware, the kernel driver _doesn't_ find
    the firmware in rootfs. If there is no suspend ever happening,
    the kernel driver will keep using the firmware that was loaded by
    u-boot. On the first suspend/resume, the firmware is lost
    because the HDMI IP gets powered down.

    3. u-boot doesn't load the firmare, the kernel driver probing
    tries to load the firmware, assuming this is available
    (see CONFIG_EXTRA_FIRMWARE).

    4. u-boot doesn't load the firmware and the kernel driver is not
    able to find it either. The probing fails and there is no HDMI
    available in linux.

    Signed-off-by: Abel Vesa
    Reviewed-by: Sandor Yu

    Abel Vesa
     

19 Jan, 2020

1 commit


31 Dec, 2019

1 commit

  • [ Upstream commit 268de6530aa18fe5773062367fd119f0045f6e88 ]

    Spec says[1] Allocated_PBN is 16 bits

    [1]- DisplayPort 1.2 Spec, Section 2.11.9.8, Table 2-98

    Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
    Cc: Lyude Paul
    Cc: Todd Previte
    Cc: Dave Airlie
    Cc: Maarten Lankhorst
    Cc: Maxime Ripard
    Cc: Sean Paul
    Cc: David Airlie
    Cc: Daniel Vetter
    Cc: dri-devel@lists.freedesktop.org
    Reviewed-by: Lyude Paul
    Signed-off-by: Sean Paul
    Link: https://patchwork.freedesktop.org/patch/msgid/20190829165223.129662-1-sean@poorly.run
    Signed-off-by: Sasha Levin

    Sean Paul
     

25 Dec, 2019

1 commit

  • In DRM framework, when hdmi/dp cable plugout/plugin in the same HDMI
    sink, because the video mode is same, DRM will not call mode_set.
    But for HDMI 2.0 sink the SCDC configurate will lost, and DP sink
    linktraning status will lost too after cable plugout then plugin.

    Currently, hdmi/dp driver will call mode_set function in HPD thread,
    But the mode_set function is called out of DRM framework, and it have
    chance to fail.
    In the patch add force_mode_set flag, set the crtc_state->mode_changed
    to force drm call mode_set when cable plugin.

    Signed-off-by: Sandor Yu

    Sandor Yu
     

03 Dec, 2019

1 commit


02 Dec, 2019

2 commits


29 Nov, 2019

1 commit


27 Nov, 2019

1 commit


25 Nov, 2019

16 commits


07 Nov, 2019

2 commits

  • Add missing docbook comments to madvise fields in struct
    drm_gem_shmem_object which fixes these warnings:

    include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member 'madv' not described in 'drm_gem_shmem_object'
    include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member 'madv_list' not described in 'drm_gem_shmem_object'

    Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
    Reported-by: Sean Paul
    Cc: Maarten Lankhorst
    Cc: Maxime Ripard
    Cc: David Airlie
    Cc: Daniel Vetter
    Signed-off-by: Rob Herring
    Reviewed-by: Sean Paul
    Link: https://patchwork.freedesktop.org/patch/msgid/20191101153754.22803-1-robh@kernel.org

    Rob Herring
     
  • drm_self_refresh_helper_update_avg_times() was incorrectly accessing the
    new incoming state after drm_atomic_helper_commit_hw_done(). But this
    state might have already been superceeded by an !nonblock atomic update
    resulting in dereferencing an already free'd crtc_state.

    TODO I *think* this will more or less do the right thing.. althought I'm
    not 100% sure if, for example, we enter psr in a nonblock commit, and
    then leave psr in a !nonblock commit that overtakes the completion of
    the nonblock commit. Not sure if this sort of scenario can happen in
    practice. But not crashing is better than crashing, so I guess we
    should either take this patch or rever the self-refresh helpers until
    Sean can figure out a better solution.

    Fixes: d4da4e33341c ("drm: Measure Self Refresh Entry/Exit times to avoid thrashing")
    Cc: Sean Paul
    Signed-off-by: Rob Clark
    [seanpaul fixed up some checkpatch warns]
    Signed-off-by: Sean Paul
    Link: https://patchwork.freedesktop.org/patch/msgid/20191104173737.142558-1-robdclark@gmail.com

    Rob Clark
     

19 Sep, 2019

3 commits

  • Currently the self refresh idle timer is a const set by the crtc. This
    is fine if the self refresh entry/exit times are well-known for all
    panels used on that crtc. However panels and workloads can vary quite a
    bit, and a timeout which works well for one doesn't work well for
    another.

    In the extreme, if the timeout is too short we could get in a situation
    where the self refresh exits are taking so long we queue up a self refresh
    entry before the exit commit is even finished.

    This patch changes the idle timeout to a moving average of the entry
    times + a moving average of exit times + the crtc constant.

    This patch was tested on rockchip, with a kevin CrOS panel the idle
    delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On
    the same board, the bob panel idle delay lands around ~340ms (90 entry
    + 150 exit + 100 const).

    WRT the dedicated mutex in self_refresh_data, it would be nice if we
    could rely on drm_crtc.mutex to protect the average times, but there are
    a few reasons why a separate lock is a better choice:
    - We can't rely on drm_crtc.mutex being held if we're doing a nonblocking
    commit
    - We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us
    whether the lock was already held in the acquire context (it eats
    -EALREADY), so we can't tell if we should drop it or not
    - We don't need such a heavy-handed lock for what we're trying to do,
    commit ordering doesn't matter, so a point-of-use lock will be less
    contentious

    Reviewed-by: Daniel Vetter
    Signed-off-by: Sean Paul
    Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-sean@poorly.run
    Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-2-sean@poorly.run

    Changes in v2:
    - Migrate locking explanation from comment to commit msg (Daniel)
    - Turf constant entry delay and multiply the avg times by 2 (Daniel)

    Sean Paul
     
  • Artifacts of previous revisions.

    Reviewed-by: Daniel Vetter
    Signed-off-by: Sean Paul
    Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-1-sean@poorly.run
    Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-1-sean@poorly.run

    Changes in v2:
    - None

    Sean Paul
     
  • It's the only flag anyone actually cares about. Plus if we're unlucky,
    the atomic ioctl might need a different flag for async flips. So
    better to abstract this away from the uapi a bit.

    Reviewed-by: Maarten Lankhorst
    Reviewed-by: Nicholas Kazlauskas
    Cc: Maarten Lankhorst
    Cc: Michel Dänzer
    Cc: Alex Deucher
    Cc: Adam Jackson
    Cc: Sean Paul
    Cc: David Airlie
    Signed-off-by: Daniel Vetter
    Cc: Maxime Ripard
    Cc: Daniel Vetter
    Cc: Nicholas Kazlauskas
    Cc: Leo Li
    Cc: Harry Wentland
    Cc: David Francis
    Cc: Mario Kleiner
    Cc: Bhawanpreet Lakha
    Cc: Ben Skeggs
    Cc: "Christian König"
    Cc: Ilia Mirkin
    Cc: Sam Ravnborg
    Cc: Chris Wilson
    Link: https://patchwork.freedesktop.org/patch/msgid/20190903190642.32588-3-daniel.vetter@ffwll.ch

    Daniel Vetter
     

28 Aug, 2019

1 commit

  • Lockdep reports a circular locking dependency with pages_lock taken in
    the shrinker callback. The deadlock can't actually happen with current
    users at least as a BO will never be purgeable when pages_lock is held.
    To be safe, let's use mutex_trylock() instead and bail if a BO is locked
    already.

    WARNING: possible circular locking dependency detected
    5.3.0-rc1+ #100 Tainted: G L
    ------------------------------------------------------
    kswapd0/171 is trying to acquire lock:
    000000009b9823fd (&shmem->pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40

    but task is already holding lock:
    00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (fs_reclaim){+.+.}:
    fs_reclaim_acquire.part.18+0x34/0x40
    fs_reclaim_acquire+0x20/0x28
    __kmalloc_node+0x6c/0x4c0
    kvmalloc_node+0x38/0xa8
    drm_gem_get_pages+0x80/0x1d0
    drm_gem_shmem_get_pages+0x58/0xa0
    drm_gem_shmem_get_pages_sgt+0x48/0xd0
    panfrost_mmu_map+0x38/0xf8 [panfrost]
    panfrost_gem_open+0xc0/0xe8 [panfrost]
    drm_gem_handle_create_tail+0xe8/0x198
    drm_gem_handle_create+0x3c/0x50
    panfrost_gem_create_with_handle+0x70/0xa0 [panfrost]
    panfrost_ioctl_create_bo+0x48/0x80 [panfrost]
    drm_ioctl_kernel+0xb8/0x110
    drm_ioctl+0x244/0x3f0
    do_vfs_ioctl+0xbc/0x910
    ksys_ioctl+0x78/0xa8
    __arm64_sys_ioctl+0x1c/0x28
    el0_svc_common.constprop.0+0x90/0x168
    el0_svc_handler+0x28/0x78
    el0_svc+0x8/0xc

    -> #0 (&shmem->pages_lock){+.+.}:
    __lock_acquire+0xa2c/0x1d70
    lock_acquire+0xdc/0x228
    __mutex_lock+0x8c/0x800
    mutex_lock_nested+0x1c/0x28
    drm_gem_shmem_purge+0x20/0x40
    panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost]
    do_shrink_slab+0x208/0x500
    shrink_slab+0x10c/0x2c0
    shrink_node+0x28c/0x4d8
    balance_pgdat+0x2c8/0x570
    kswapd+0x22c/0x638
    kthread+0x128/0x130
    ret_from_fork+0x10/0x18

    other info that might help us debug this:

    Possible unsafe locking scenario:

    CPU0 CPU1
    ---- ----
    lock(fs_reclaim);
    lock(&shmem->pages_lock);
    lock(fs_reclaim);
    lock(&shmem->pages_lock);

    *** DEADLOCK ***

    3 locks held by kswapd0/171:
    #0: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40
    #1: 00000000ceb37808 (shrinker_rwsem){++++}, at: shrink_slab+0xbc/0x2c0
    #2: 00000000f31efa81 (&pfdev->shrinker_lock){+.+.}, at: panfrost_gem_shrinker_scan+0x34/0x180 [panfrost]

    Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
    Cc: Maarten Lankhorst
    Cc: Maxime Ripard
    Cc: Sean Paul
    Cc: David Airlie
    Cc: Daniel Vetter
    Signed-off-by: Rob Herring
    Reviewed-by: Steven Price
    Acked-by: Alyssa Rosenzweig
    Link: https://patchwork.freedesktop.org/patch/msgid/20190823021216.5862-6-robh@kernel.org

    Rob Herring
     

27 Aug, 2019

1 commit


22 Aug, 2019

1 commit

  • We need the rename of reservation_object to dma_resv.

    The solution on this merge came from linux-next:
    From: Stephen Rothwell
    Date: Wed, 14 Aug 2019 12:48:39 +1000
    Subject: [PATCH] drm: fix up fallout from "dma-buf: rename reservation_object to dma_resv"

    Signed-off-by: Stephen Rothwell
    ---
    drivers/gpu/drm/i915/gt/intel_engine_pool.c | 8 ++++----
    3 files changed, 7 insertions(+), 7 deletions(-)

    diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c b/drivers/gpu/drm/i915/gt/intel_engine_pool.c
    index 03d90b49584a..4cd54c569911 100644
    --- a/drivers/gpu/drm/i915/gt/intel_engine_pool.c
    +++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.c
    @@ -43,12 +43,12 @@ static int pool_active(struct i915_active *ref)
    {
    struct intel_engine_pool_node *node =
    container_of(ref, typeof(*node), active);
    - struct reservation_object *resv = node->obj->base.resv;
    + struct dma_resv *resv = node->obj->base.resv;
    int err;

    - if (reservation_object_trylock(resv)) {
    - reservation_object_add_excl_fence(resv, NULL);
    - reservation_object_unlock(resv);
    + if (dma_resv_trylock(resv)) {
    + dma_resv_add_excl_fence(resv, NULL);
    + dma_resv_unlock(resv);
    }

    err = i915_gem_object_pin_pages(node->obj);

    which is a simplified version from a previous one which had:
    Reviewed-by: Christian König

    Signed-off-by: Rodrigo Vivi

    Rodrigo Vivi
     

21 Aug, 2019

1 commit

  • drm-misc-next for 5.4:

    UAPI Changes:

    Cross-subsystem Changes:

    Core Changes:
    - dma-buf: add reservation_object_fences helper, relax
    reservation_object_add_shared_fence, remove
    reservation_object seq number (and then
    restored)
    - dma-fence: Shrinkage of the dma_fence structure,
    Merge dma_fence_signal and dma_fence_signal_locked,
    Store the timestamp in struct dma_fence in a union with
    cb_list

    Driver Changes:
    - More dt-bindings YAML conversions
    - More removal of drmP.h includes
    - dw-hdmi: Support get_eld and various i2s improvements
    - gm12u320: Few fixes
    - meson: Global cleanup
    - panfrost: Few refactors, Support for GPU heap allocations
    - sun4i: Support for DDC enable GPIO
    - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02,
    Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1
    Toppoly TD043MTEA1

    Signed-off-by: Dave Airlie
    [airlied: fixup dma_resv rename fallout]

    From: Maxime Ripard
    Link: https://patchwork.freedesktop.org/patch/msgid/20190819141923.7l2adietcr2pioct@flea

    Dave Airlie
     

16 Aug, 2019

1 commit

  • The BSpec has added three new IDS for CML.
    Update the IDs in accordance to the Spec.

    Cc: Lucas De Marchi
    Cc: José Roberto de Souza
    Signed-off-by: Anusha Srivatsa
    Reviewed-by: Anshuman Gupta
    Link: https://patchwork.freedesktop.org/patch/msgid/20190812222737.29356-1-anusha.srivatsa@intel.com

    Anusha Srivatsa
     

14 Aug, 2019

1 commit

  • Part of the channel count setup done in dw-hdmi ahb should
    actually be done whatever the interface providing the data.

    Let's move it to dw-hdmi driver instead.

    Reviewed-by: Jonas Karlman
    Signed-off-by: Jerome Brunet
    Reviewed-by: Neil Armstrong
    Signed-off-by: Neil Armstrong
    Link: https://patchwork.freedesktop.org/patch/msgid/20190812120726.1528-3-jbrunet@baylibre.com

    Jerome Brunet
     

13 Aug, 2019

1 commit