dri-devel October 2020

dri-devel@lists.freedesktop.org

304 participants
773 discussions

[PATCH] drm/atomic: Make the kerneldoc a bit clearer
by Daniel Vetter 02 Oct '20

02 Oct '20

Crank up the warning a notch and point at the right set of locking functions for atomic drivers. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- drivers/gpu/drm/drm_atomic.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index aac9122f1da2..b2d20eb6c807 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1642,11 +1642,11 @@ static void __drm_state_dump(struct drm_device *dev, struct drm_printer *p, * to dmesg in case of error irq's. (Hint, you probably want to * ratelimit this!) * - * The caller must drm_modeset_lock_all(), or if this is called - * from error irq handler, it should not be enabled by default. - * (Ie. if you are debugging errors you might not care that this - * is racey. But calling this without all modeset locks held is - * not inherently safe.) + * The caller must wrap this drm_modeset_lock_all_ctx() and + * drm_modeset_drop_locks(). If this is called from error irq handler, it should + * not be enabled by default - if you are debugging errors you might + * not care that this is racey, but calling this without all modeset locks held + * is inherently unsafe. */ void drm_state_dump(struct drm_device *dev, struct drm_printer *p) { -- 2.28.0

2 3

Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
by Jonathan Marek 02 Oct '20

02 Oct '20

On 10/2/20 3:53 AM, Christoph Hellwig wrote: >> @@ -8,6 +8,7 @@ >> #include <linux/shmem_fs.h> >> #include <linux/dma-buf.h> >> #include <linux/pfn_t.h> >> +#include <linux/dma-noncoherent.h> > > NAK, dma-noncoherent.h is not for driver use. And will in fact go > away in 5.10. > Not actually used, so can be removed. >> >> #include <drm/drm_prime.h> >> >> @@ -808,6 +809,20 @@ int msm_gem_cpu_fini(struct drm_gem_object *obj) >> return 0; >> } >> >> +void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags, >> + size_t range_start, size_t range_end) >> +{ >> + struct msm_gem_object *msm_obj = to_msm_bo(obj); >> + >> + /* TODO: sync only the required range, and don't invalidate on clean */ >> + >> + if (flags & MSM_GEM_SYNC_CACHE_CLEAN) >> + sync_for_device(msm_obj); >> + >> + if (flags & MSM_GEM_SYNC_CACHE_INVALIDATE) >> + sync_for_cpu(msm_obj); > > And make to these ones as well. They are complete abuses of the DMA > API, and while we had to live with that for now to not cause regressions > they absoutely must not be exposed in a userspace ABI like this. > How do you propose that cached non-coherent memory be implemented? It is a useful feature for userspace.

1 0

[PATCH v2] drm/sched: Avoid infinite waits in the drm_sched_entity_destroy() path
by Boris Brezillon 02 Oct '20

02 Oct '20

If we don't initialize the entity to idle and the entity is never scheduled before being destroyed we end up with an infinite wait in the destroy path. v2: - Add Steven's R-b Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> Reviewed-by: Steven Price <steven.price(a)arm.com> --- This is something I noticed while debugging another issue on panfrost causing the scheduler to be in a weird state where new entities were no longer scheduled. This was causing all userspace threads trying to close their DRM fd to be blocked in kernel space waiting for this "entity is idle" event. I don't know if that fix is legitimate (now that we fixed the other bug we don't seem to end up in that state anymore), but I thought I'd share it anyway. --- drivers/gpu/drm/scheduler/sched_entity.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 146380118962..f8ec277a6aa8 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -73,6 +73,9 @@ int drm_sched_entity_init(struct drm_sched_entity *entity, init_completion(&entity->entity_idle); + /* We start in an idle state. */ + complete(&entity->entity_idle); + spin_lock_init(&entity->rq_lock); spsc_queue_init(&entity->job_queue); -- 2.26.2

2 2

[PATCH v2] drm/panfrost: Fix job timeout handling
by Boris Brezillon 02 Oct '20

02 Oct '20

If more than two jobs end up timeout-ing concurrently, only one of them (the one attached to the scheduler acquiring the lock) is fully handled. The other one remains in a dangling state where it's no longer part of the scheduling queue, but still blocks something in scheduler, leading to repetitive timeouts when new jobs are queued. Let's make sure all bad jobs are properly handled by the thread acquiring the lock. v2: - Fix the subject prefix - Stop the scheduler before returning from panfrost_job_timedout() - Call cancel_delayed_work_sync() after drm_sched_stop() to make sure no timeout handlers are in flight when we reset the GPU (Steven Price) - Make sure we release the reset lock before restarting the schedulers (Steven Price) Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: <stable(a)vger.kernel.org> --- drivers/gpu/drm/panfrost/panfrost_job.c | 64 +++++++++++++++++++++---- 1 file changed, 55 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c index 30e7b7196dab..6e4bfb938fab 100644 --- a/drivers/gpu/drm/panfrost/panfrost_job.c +++ b/drivers/gpu/drm/panfrost/panfrost_job.c @@ -25,7 +25,8 @@ struct panfrost_queue_state { struct drm_gpu_scheduler sched; - + bool stopped; + struct mutex lock; u64 fence_context; u64 emit_seqno; }; @@ -369,6 +370,24 @@ void panfrost_job_enable_interrupts(struct panfrost_device *pfdev) job_write(pfdev, JOB_INT_MASK, irq_mask); } +static bool panfrost_scheduler_stop(struct panfrost_queue_state *queue, + struct drm_sched_job *bad) +{ + bool stopped = false; + + mutex_lock(&queue->lock); + if (!queue->stopped) { + drm_sched_stop(&queue->sched, bad); + if (bad) + drm_sched_increase_karma(bad); + queue->stopped = true; + stopped = true; + } + mutex_unlock(&queue->lock); + + return stopped; +} + static void panfrost_job_timedout(struct drm_sched_job *sched_job) { struct panfrost_job *job = to_panfrost_job(sched_job); @@ -392,19 +411,41 @@ static void panfrost_job_timedout(struct drm_sched_job *sched_job) job_read(pfdev, JS_TAIL_LO(js)), sched_job); + /* Scheduler is already stopped, nothing to do. */ + if (!panfrost_scheduler_stop(&pfdev->js->queue[js], sched_job)) + return; + if (!mutex_trylock(&pfdev->reset_lock)) return; + mutex_lock(&pfdev->sched_lock); for (i = 0; i < NUM_JOB_SLOTS; i++) { struct drm_gpu_scheduler *sched = &pfdev->js->queue[i].sched; - drm_sched_stop(sched, sched_job); - if (js != i) - /* Ensure any timeouts on other slots have finished */ + /* + * If the queue is still active, make sure we wait for any + * pending timeouts. + */ + if (!pfdev->js->queue[i].stopped) cancel_delayed_work_sync(&sched->work_tdr); - } - drm_sched_increase_karma(sched_job); + /* + * If the scheduler was not already stopped, there's a tiny + * chance a timeout has expired just before we stopped it, and + * drm_sched_stop() does not flush pending works. Let's flush + * them now so the timeout handler doesn't get called in the + * middle of a reset. + */ + if (panfrost_scheduler_stop(&pfdev->js->queue[i], NULL)) + cancel_delayed_work_sync(&sched->work_tdr); + + /* + * Now that we cancelled the pending timeouts, we can safely + * reset the stopped state. + */ + pfdev->js->queue[i].stopped = false; + } + mutex_unlock(&pfdev->sched_lock); spin_lock_irqsave(&pfdev->js->job_lock, flags); for (i = 0; i < NUM_JOB_SLOTS; i++) { @@ -421,11 +462,11 @@ static void panfrost_job_timedout(struct drm_sched_job *sched_job) for (i = 0; i < NUM_JOB_SLOTS; i++) drm_sched_resubmit_jobs(&pfdev->js->queue[i].sched); + mutex_unlock(&pfdev->reset_lock); + /* restart scheduler after GPU is usable again */ for (i = 0; i < NUM_JOB_SLOTS; i++) drm_sched_start(&pfdev->js->queue[i].sched, true); - - mutex_unlock(&pfdev->reset_lock); } static const struct drm_sched_backend_ops panfrost_sched_ops = { @@ -558,6 +599,7 @@ int panfrost_job_open(struct panfrost_file_priv *panfrost_priv) int ret, i; for (i = 0; i < NUM_JOB_SLOTS; i++) { + mutex_init(&js->queue[i].lock); sched = &js->queue[i].sched; ret = drm_sched_entity_init(&panfrost_priv->sched_entity[i], DRM_SCHED_PRIORITY_NORMAL, &sched, @@ -570,10 +612,14 @@ int panfrost_job_open(struct panfrost_file_priv *panfrost_priv) void panfrost_job_close(struct panfrost_file_priv *panfrost_priv) { + struct panfrost_device *pfdev = panfrost_priv->pfdev; + struct panfrost_job_slot *js = pfdev->js; int i; - for (i = 0; i < NUM_JOB_SLOTS; i++) + for (i = 0; i < NUM_JOB_SLOTS; i++) { drm_sched_entity_destroy(&panfrost_priv->sched_entity[i]); + mutex_destroy(&js->queue[i].lock); + } } int panfrost_job_is_idle(struct panfrost_device *pfdev) -- 2.26.2

2 2

Re: linux-next: manual merge of the akpm tree with the drm-intel tree
by Daniel Vetter 02 Oct '20

02 Oct '20

On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <hch(a)lst.de> wrote: > > On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the akpm tree got a conflict in: > > > > drivers/gpu/drm/i915/gem/i915_gem_pages.c > > > > between commit: > > > > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32") > > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported") Uh these patches shouldn't be in linux-next because they're for 5.11, not the 5.10 merge window that will open soon. Joonas? > > from the drm-intel tree and patch: > > > > "drm/i915: use vmap in i915_gem_object_map" > > > > from the akpm tree. > > > > I fixed it up (I just dropped the changes in the former commits) and > > Sigh. The solution is a bit more complicated, but I just redid my > patches to not depend on the above ones. I can revert back to the old > version, though. Andrew, let me know what works for you. Imo ignore, rebasing onto linux-next without those intel patches was the right thing for the 5.10 merge window. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

3 3

[drm-intel:drm-intel-next-queued 14/14] drivers/gpu/drm/i915/display/intel_lspcon.c:533:6: error: no previous prototype for function 'lspcon_init'
by kernel test robot 02 Oct '20

02 Oct '20

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: f542d671ffcec772a561cd41c7e2394392d9dafb commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon after HPD in intel_dp_detect() config: x86_64-randconfig-a005-20201001 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project bcd05599d0e53977a963799d6ee4f6e0bc21331b) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git remote add drm-intel git://anongit.freedesktop.org/drm-intel git fetch --no-tags drm-intel drm-intel-next-queued git checkout f542d671ffcec772a561cd41c7e2394392d9dafb # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All errors (new ones prefixed by >>): >> drivers/gpu/drm/i915/display/intel_lspcon.c:533:6: error: no previous prototype for function 'lspcon_init' [-Werror,-Wmissing-prototypes] bool lspcon_init(struct intel_digital_port *dig_port) ^ drivers/gpu/drm/i915/display/intel_lspcon.c:533:1: note: declare 'static' if the function is not intended to be used outside of this translation unit bool lspcon_init(struct intel_digital_port *dig_port) ^ static 1 error generated. vim +/lspcon_init +533 drivers/gpu/drm/i915/display/intel_lspcon.c 357c0ae9198ad7f drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-11-21 532 7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi 2020-06-30 @533 bool lspcon_init(struct intel_digital_port *dig_port) dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 534 { 7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi 2020-06-30 535 struct intel_dp *dp = &dig_port->dp; 7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi 2020-06-30 536 struct intel_lspcon *lspcon = &dig_port->lspcon; 668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 537 struct drm_connector *connector = &dp->attached_connector->base; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 538 dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 539 lspcon->active = false; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 540 lspcon->mode = DRM_LSPCON_MODE_INVALID; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 541 dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 542 if (!lspcon_probe(lspcon)) { dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 543 DRM_ERROR("Failed to probe lspcon\n"); dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 544 return false; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 545 } dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 546 b9936121d95b012 drivers/gpu/drm/i915/display/intel_lspcon.c Lyude Paul 2020-08-26 547 if (drm_dp_read_dpcd_caps(&dp->aux, dp->dpcd) != 0) { 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 548 DRM_ERROR("LSPCON DPCD read failed\n"); 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 549 return false; 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 550 } 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 551 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 552 if (!lspcon_detect_vendor(lspcon)) { 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 553 DRM_ERROR("LSPCON vendor detection failed\n"); 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 554 return false; 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 555 } 12a47a422862214 drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 556 668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 557 connector->ycbcr_420_allowed = true; 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 558 lspcon->active = true; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 559 DRM_DEBUG_KMS("Success: LSPCON init\n"); dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 560 return true; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 561 } f542d671ffcec77 drivers/gpu/drm/i915/display/intel_lspcon.c Kai-Heng Feng 2020-06-10 562 :::::: The code at line 533 was first introduced by commit :::::: 7801f3b792b0fd171b02f2cb974e758295e68e0f drm/i915/display: prefer dig_port to reference intel_digital_port :::::: TO: Lucas De Marchi <lucas.demarchi(a)intel.com> :::::: CC: Lucas De Marchi <lucas.demarchi(a)intel.com> --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

1 0

[PATCH RFC 0/1] drm/ttm: Allocate transparent huge pages without clearing __GFP_COMP
by Alex Goins 02 Oct '20

02 Oct '20

Hi Christian, I've been looking into the DMA-BUFs exported from AMDGPU / TTM. Would you mind giving some input on this? I noticed that your changes implementing transparent huge page support in TTM are allocating them as non-compound. I understand that using multiorder non-compound pages is common in device drivers, but I think this can cause a problem when these pages are exported to other drivers. It's possible for other drivers to access the DMA-BUF's pages via gem_prime_import_sg_table(), but without context from TTM, it's impossible for the importing driver to make sense of them; they simply appear as individual pages, with only the first page having a non-zero refcount. Making TTM's THP allocations compound puts them more in line with the standard definition of a THP, and allows DMA-BUF-importing drivers to make sense of the pages within. I would like to propose making these allocations compound, but based on patch history, it looks like the decision to make them non-compound was intentional, as there were difficulties figuring out how to map them into CPU page tables. I did some cursory testing with compound THPs, and nothing seems obviously broken. I was also able to map compound THP DMA-BUFs into userspace without issue, and access their contents. Are you aware of any other potential consequences? Commit 5c42c64f7d54 ("drm/ttm: fix the fix for huge compound pages") should probably also be reverted if this is applied. Thanks, Alex Alex Goins (1): drm-ttm: Allocate compound transparent huge pages drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.25.1

3 5

[PULL] drm-misc-next-fixes
by Maxime Ripard 02 Oct '20

02 Oct '20

Hi Daniel, Dave, Here's a few fixes for the next merge window Thanks! Maxime drm-misc-next-fixes-2020-10-02: Three fixes for vc4 that addresses dual-display breakages The following changes since commit 089d83418914abd4d908db117d9a3eca7f51a68c: drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing (2020-09-21 16:43:11 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-10-02 for you to fetch changes up to 8ba0b6d196315f68c271f549e8585129caefce97: drm/vc4: crtc: Keep the previously assigned HVS FIFO (2020-09-25 16:56:21 +0200) ---------------------------------------------------------------- Three fixes for vc4 that addresses dual-display breakages ---------------------------------------------------------------- Maxime Ripard (3): drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active drm/vc4: crtc: Rework a bit the CRTC state code drm/vc4: crtc: Keep the previously assigned HVS FIFO drivers/gpu/drm/vc4/vc4_crtc.c | 14 +++++++++++--- drivers/gpu/drm/vc4/vc4_drv.h | 2 ++ drivers/gpu/drm/vc4/vc4_kms.c | 22 ++++++++++++++++------ 3 files changed, 29 insertions(+), 9 deletions(-)

1 0

[drm-intel:drm-intel-next-queued 14/14] drivers/gpu/drm/i915/display/intel_lspcon.c:533:6: warning: no previous prototype for function 'lspcon_init'
by kernel test robot 02 Oct '20

02 Oct '20

tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: f542d671ffcec772a561cd41c7e2394392d9dafb commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon after HPD in intel_dp_detect() config: x86_64-randconfig-a003-20201001 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project bcd05599d0e53977a963799d6ee4f6e0bc21331b) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install x86_64 cross compiling tool for clang build # apt-get install binutils-x86-64-linux-gnu git remote add drm-intel git://anongit.freedesktop.org/drm-intel git fetch --no-tags drm-intel drm-intel-next-queued git checkout f542d671ffcec772a561cd41c7e2394392d9dafb # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All warnings (new ones prefixed by >>): >> drivers/gpu/drm/i915/display/intel_lspcon.c:533:6: warning: no previous prototype for function 'lspcon_init' [-Wmissing-prototypes] bool lspcon_init(struct intel_digital_port *dig_port) ^ drivers/gpu/drm/i915/display/intel_lspcon.c:533:1: note: declare 'static' if the function is not intended to be used outside of this translation unit bool lspcon_init(struct intel_digital_port *dig_port) ^ static 1 warning generated. vim +/lspcon_init +533 drivers/gpu/drm/i915/display/intel_lspcon.c 357c0ae9198ad7f drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-11-21 532 7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi 2020-06-30 @533 bool lspcon_init(struct intel_digital_port *dig_port) dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 534 { 7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi 2020-06-30 535 struct intel_dp *dp = &dig_port->dp; 7801f3b792b0fd1 drivers/gpu/drm/i915/display/intel_lspcon.c Lucas De Marchi 2020-06-30 536 struct intel_lspcon *lspcon = &dig_port->lspcon; 668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 537 struct drm_connector *connector = &dp->attached_connector->base; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 538 dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 539 lspcon->active = false; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 540 lspcon->mode = DRM_LSPCON_MODE_INVALID; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 541 dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 542 if (!lspcon_probe(lspcon)) { dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 543 DRM_ERROR("Failed to probe lspcon\n"); dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 544 return false; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 545 } dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 546 b9936121d95b012 drivers/gpu/drm/i915/display/intel_lspcon.c Lyude Paul 2020-08-26 547 if (drm_dp_read_dpcd_caps(&dp->aux, dp->dpcd) != 0) { 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 548 DRM_ERROR("LSPCON DPCD read failed\n"); 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 549 return false; 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 550 } 24e807e79f103cd drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 551 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 552 if (!lspcon_detect_vendor(lspcon)) { 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 553 DRM_ERROR("LSPCON vendor detection failed\n"); 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 554 return false; 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 555 } 12a47a422862214 drivers/gpu/drm/i915/intel_lspcon.c Imre Deak 2016-10-24 556 668b6c176c33f44 drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 557 connector->ycbcr_420_allowed = true; 96e35598cead98d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2018-10-12 558 lspcon->active = true; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 559 DRM_DEBUG_KMS("Success: LSPCON init\n"); dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 560 return true; dbe9e61b8e4306d drivers/gpu/drm/i915/intel_lspcon.c Shashank Sharma 2016-10-14 561 } f542d671ffcec77 drivers/gpu/drm/i915/display/intel_lspcon.c Kai-Heng Feng 2020-06-10 562 :::::: The code at line 533 was first introduced by commit :::::: 7801f3b792b0fd171b02f2cb974e758295e68e0f drm/i915/display: prefer dig_port to reference intel_digital_port :::::: TO: Lucas De Marchi <lucas.demarchi(a)intel.com> :::::: CC: Lucas De Marchi <lucas.demarchi(a)intel.com> --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

1 0

linux-next: manual merge of the drm tree with Linus' tree
by Stephen Rothwell 02 Oct '20

02 Oct '20

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c between commit: b19515253623 ("drm/amd/pm: setup APU dpm clock table in SMU HW initialization") from the Linus tree and commits: 82cac71c1b64 ("drm/amd/pm: put Navi1X umc cdr workaround in post_smu_init") 236b156f7388 ("drm/amd/pm: apply no power source workaround if dc reported by gpio") 1653a179c822 ("drm/amd/pm: move NAVI1X power mode switching workaround to post_init") from the drm tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c index 8dc5abb6931e,5c4b74f964fc..000000000000 --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c @@@ -955,35 -1013,6 +1002,17 @@@ static int smu_smc_hw_setup(struct smu_ return ret; } - ret = smu_disable_umc_cdr_12gbps_workaround(smu); - if (ret) { - dev_err(adev->dev, "Workaround failed to disable UMC CDR feature on 12Gbps SKU!\n"); - return ret; - } - - /* - * For Navi1X, manually switch it to AC mode as PMFW - * may boot it with DC mode. - */ - ret = smu_set_power_source(smu, - adev->pm.ac_power ? SMU_POWER_SOURCE_AC : - SMU_POWER_SOURCE_DC); - if (ret) { - dev_err(adev->dev, "Failed to switch to %s mode!\n", adev->pm.ac_power ? "AC" : "DC"); - return ret; - } - + /* + * Set initialized values (get from vbios) to dpm tables context such as + * gfxclk, memclk, dcefclk, and etc. And enable the DPM feature for each + * type of clks. + */ + ret = smu_set_default_dpm_table(smu); + if (ret) { + dev_err(adev->dev, "Failed to setup default dpm clock tables!\n"); + return ret; + } + ret = smu_notify_display_change(smu); if (ret) return ret;

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2020