- 21 Nov, 2020 1 commit
-
-
Rob Clark authored
Previously we only held obj lock in the _active_get() path, and relied on atomic_dec_return() to not be racy in the _active_put() path where obj lock was not held. But this is a false sense of security. Unlike obj lifetime refcnt, where you do not expect to *increase* the refcnt after the last put (which would mean that something has gone horribly wrong with the object liveness reference counting), the active_count can increase again from zero. Racing _active_put()s and _active_get()s could leave the obj on the wrong mm list. But in the retire path, immediately after the _active_put(), the _unpin_iova() would acquire obj lock. So just move the locking earlier and rely on that to protect obj->active_count. Fixes: c5c1643c ("drm/msm: Drop struct_mutex from the retire path") Signed-off-by: Rob Clark <robdclark@chromium.org>
-
- 10 Nov, 2020 8 commits
-
-
Abhinav Kumar authored
For sinks that do not support audio, there is no need to notify audio subsystem of the connection event. This will make sure that audio routes only to the primary display when connected to such sinks. changes in v2: - Added fixes tag - Removed nested if condition and removed usage of global pointer Fixes: d13e36d7 ("drm/msm/dp: add audio support for Display Port on MSM") Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kuogee Hsieh authored
Some dongles require link training done at irq_hpd request instead of plugin request. This patch promote irq_hpd handler to handle link training and setup hpd_state correctly. Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kuogee Hsieh authored
Some dongle will not clear LINK_STATUS_UPDATED bit after DPCD read which cause link training failed. This patch just read 6 bytes of DPCD link status from sink and return without checking LINK_STATUS_UPDATED bit. Only 8 bits are used to represent link rate at sinker DPCD. The really link rate is 2.7Mb times the 8 bits value. For example, 0x0A at DPCD is equal to 2.7Gb (10 * 2.7Mb). This patch also convert 8 bits value of DPCD to really link rate to fix worng link rate error during phy compliance test. Fixes: 6625e263 ("drm/msm/dp: DisplayPort PHY compliance tests fixup") Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kuogee Hsieh authored
DP compo phy have to be enable to start link training. When link training failed phy need to be disabled so that next link traning can be proceed smoothly at next plug in. This patch de-initialize mainlink to disable phy if link training failed. This prevent system crash due to disp_cc_mdss_dp_link_intf_clk stuck at "off" state. This patch also perform checking power_on flag at dp_display_enable() and dp_display_disable() to avoid crashing when unplug cable while display is off. Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kuogee Hsieh authored
Connection state is not set correctly happen when either failure of link train due to cable unplugged in the middle of aux channel reading or cable plugged in while in suspended state. This patch fixes these problems. This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF. Changes in V2: -- Add more information to commit message. Changes in V3: -- change base Changes in V4: -- add Fixes tag Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Kuogee Hsieh authored
During suspend, dp host controller and hpd block are disabled due to both ahb and aux clock are disabled. Therefore hpd plug/unplug interrupts will not be generated. At dp_pm_resume(), reinitialize both dp host controller and hpd block so that hpd plug/unplug interrupts will be generated and handled by driver so that hpd connection state is updated correctly. This patch will fix link training flaky issues. Changes in v2: -- use container_of to cast correct dp_display_private pointer at both dp_pm_suspend() and dp_pm_resume(). Changes in v3: -- replace hpd_state atomic_t with u32 Changes in v4 -- call dp_display_host_deinit() at dp_pm_suspend() -- call dp_display_host_init() at msm_dp_display_enable() -- fix phy->init_count unbalance which causes link training failed Changes in v5 -- add Fixes tag Fixes: 8ede2ecc (drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets) Tested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Similar to the previous patch, clear shadow on suspend to avoid timeouts waiting for ringbuffer space. Fixes: 8907afb4 ("drm/msm: Allow a5xx to mark the RPTR shadow as privileged") Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Clear the shadow rptr on suspend. Otherwise, when we resume, we can have a stale value until CP_WHERE_AM_I executes. If we suspend near the ringbuffer wraparound point, this can lead to a chicken/egg situation where we are waiting for ringbuffer space to write the CP_WHERE_AM_I (or CP_INIT) packet, because we mistakenly believe that the ringbuffer is full (due to stale rptr value in the shadow). Fixes errors like: [drm:adreno_wait_ring [msm]] *ERROR* timeout waiting for space in ringbuffer 0 in the resume path. Fixes: d3a569fc ("drm/msm: a6xx: Use WHERE_AM_I for eligible targets") Signed-off-by: Rob Clark <robdclark@chromium.org>
-
- 05 Nov, 2020 25 commits
-
-
Akhil P Oommen authored
Add cooling device support to gpu. A cooling device is bound to a thermal zone to allow thermal mitigation. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Akhil P Oommen authored
Register GPU as a devfreq cooling device so that it can be passively cooled by the thermal framework. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Tested-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Now that the inactive_list is protected by mm_lock, and everything else on per-obj basis is protected by obj->resv, we no longer depend on struct_mutex. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
The obj->lock is sufficient for what we need. This *does* have the implication that userspace can try to shoot themselves in the foot by racing madvise(DONTNEED) with submit. But the result will be about the same if they did madvise(DONTNEED) before the submit ioctl, ie. they might not get want they want if they race with shrinker. But iova fault handling is robust enough, so userspace is only shooting it's own foot. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Now that we don't need struct_mutex in the free path, we can get rid of the asynchronous free altogether. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Now that active_list/inactive_list is protected by mm_lock, we no longer need dev->struct_mutex in the free_object() path. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Now that we are not relying on dev->struct_mutex to protect the ring->submits lists, drop the struct_mutex lock. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
It cannot be atomically updated with obj->active_count, and the only purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once retire_submits() is not serialized with incoming submits via struct_mutex) Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Before we remove dev->struct_mutex from the retire path, we have to deal with the situation of a submit retiring before the submit ioctl returns. To deal with this, ring->submits will hold a reference to the submit, which is dropped when the submit is retired. And the submit ioctl path holds it's own ref, which it drops when it is done with the submit. Also, add to submit list *after* getting/pinning bo's, to prevent badness in case the completed fence is corrupted, and retire_worker mistakenly believes the submit is done too early. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
One less place to rely on dev->struct_mutex. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Before adding another lock, give ring->lock a more descriptive name. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Rather than relying on the big dev->struct_mutex hammer, introduce a more specific lock for protecting the bo lists. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Small cleanup, update_fences() is used in the hangcheck path, but also in the normal retire path. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
It is somewhat redundant with the gpu tracepoints, and anyways not too useful to justify spamming the log when debug traces are enabled. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
We only want to use the _unlocked() variant in the unlocked case. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
This also converts the special msm_gem_get_vaddr_active() to expect the lock to already be held. There are two call-sites for this, one already has the lock held, so it is more straightforward to just open-code the locking for the other caller. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Unfortunately, due to an dev_pm_opp locking interaction with mm->mmap_sem, we need to do pm get before aquiring obj locks, otherwise we can have anger lockdep with the chain: opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex For an explicit fencing userspace, the impact should be minimal as we do all the fence waits before this point. It could result in some needless resumes in error cases, etc. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
We cannot switch to using obj->resv for locking without first moving all the copy_from_user() ahead of submit_lock_objects(). Otherwise in the mm fault path we aquire mm->mmap_sem before obj lock, but in the submit path the order is reversed. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to skip over bo's that are already locked. This gets rid of the nested lock classes. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
When we cut-over to using dma_resv_lock/etc instead of msm_obj->lock, we'll need these for the submit path (where resv->lock is already held). Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
We'll need to introduce a _locked() version of msm_gem_get_iova(), so we need to make that name available. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
This will make it easier to transition over to obj->resv locking for everything that is per-bo locking. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
The microcode bo's should never be madvise(WONTNEED), so these should not be using msm_gem_get_vaddr_active(). Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Dmitry Baryshkov authored
Reading VCO rate for this PLL can cause boot stalls, if it is not enabled. Guard clk_hw_get_rate with a call to dsi_pll_28nm_clk_is_enabled(). Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
- 04 Nov, 2020 6 commits
-
-
Akhil P Oommen authored
The dev_pm_opp_of_add_table() api initializes the icc nodes for gpu indirectly. So we can avoid using of_icc_get() api in the common probe path. To improve this, move of_icc_get() to target specific code where it is required. This patch helps to fix duplicate gpu node listed in the interconnect summary from the debugfs. Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Dmitry Baryshkov authored
c33b7c03 ("drm/msm/dpu: add support for clk and bw scaling for display") has added support for handling bandwidth voting in kms path in addition to old mdss path. However this broke all other platforms since _dpu_core_perf_crtc_update_bus() will now error out instead of properly calculating bandwidth and core clocks. Fix _dpu_core_perf_crtc_update_bus() to just skip bandwidth setting instead of returning an error in case kms->num_paths == 0 (MDSS is used for bandwidth management). Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: c33b7c03 ("drm/msm/dpu: add support for clk and bw scaling for display") Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Dmitry Baryshkov authored
Handle new merge_3d block setup in dpu encoder code. Pass correct mode and id. Note, that merge_3d blocks are not handled via usual RM reservation mechanism, as each merge_3d block is tied to two PPs, so by reserving PP you get merge_3d automatically. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Dmitry Baryshkov authored
Handle setting up merge mode in merge_3d hardware block. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Dmitry Baryshkov authored
Active HW CTL blocks need separate handling for merge_3d flushes. Implement necessary merge_3d configuration and flushing. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-
Dmitry Baryshkov authored
Add initial support for merge3D hardware block on SM8[12]50. Merge3D is reposible for merging contents of two LMs (two PPs) into single interface. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
-