[PATCH v2 05/11] Kbuild: don't add obj tree in additional includes

[Michal Marek]

On Wed, Jun 15, 2016 at 05:45:47PM +0200, Arnd Bergmann wrote:
> When building with separate object directories and driver specific
> Makefiles that add additional header include paths, Kbuild adjusts
> the gcc flags so that we include both the directory in the source
> tree and in the object tree.
> 
> However, due to another bug I fixed earlier, this did not actually
> include the correct directory in the object tree, so we know that
> we only really need the source tree here. Also, including the
> object tree sometimes causes warnings about nonexisting directories
> when the include path only exists in the source.
> 
> This changes the logic to only emit the -I argument for the srctree,
> not for objects. We still need both $(srctree)/$(src) and $(obj)
> though, so I'm adding them manually.
> 
> Signed-off-by: Arnd Bergmann 

Hi Arnd,

I applied the series up to this patch to kbuild.git#kbuild. The rest
seem to be related but not dependent patches, so I'll leave it up to the
respective maintainers to pick them up. Is that OK with you?

Thanks,
Michal

[pull] radeon and amdgpu drm-next-4.8

[Edward O'Callaghan]

d_smumgr.h => iceland_smum.h}|   0
>>  drivers/gpu/drm/amd/amdgpu/kv_dpm.c|   2 +
>>  drivers/gpu/drm/amd/amdgpu/ppsmc.h |   4 +
>>  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  43 ++-
>>  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  15 +-
>>  drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  | 143 ++
>>  drivers/gpu/drm/amd/amdgpu/vi.c|  14 -
>>  drivers/gpu/drm/amd/include/cgs_common.h   |   4 +
>>  .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  |   9 +-
>>  drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c   | 299 
>> -
>>  drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.h   |   1 +
>>  .../gpu/drm/amd/powerplay/hwmgr/processpptables.c  |  13 +
>>  .../gpu/drm/amd/powerplay/hwmgr/processpptables.h  |  17 +-
>>  drivers/gpu/drm/amd/powerplay/inc/smumgr.h |  29 ++
>>  drivers/gpu/drm/radeon/atombios_encoders.c |   1 +
>>  30 files changed, 469 insertions(+), 360 deletions(-)
>>  rename drivers/gpu/drm/amd/amdgpu/{iceland_smumgr.h => iceland_smum.h} 
>> (100%)
>> ___
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>> 
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/2041a2f6/attachment.sig>

[pull] radeon and amdgpu drm-next-4.8

[Edward O'Callaghan]

ed, 469 insertions(+), 360 deletions(-)
>  rename drivers/gpu/drm/amd/amdgpu/{iceland_smumgr.h => iceland_smum.h} (100%)
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/f64f0c0a/attachment-0001.sig>

[PATCH v2] drm/radeon: Remove deprecated create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 05:00:44PM +0530, Bhaktipriya Shridhar wrote:
> 
> alloc_workqueue replaces deprecated create_singlethread_workqueue().
> 
> Each hardware CRTC has a single flip work queue.
> When a radeon_flip_work_func item is queued, it needs to be executed
> ASAP because even a slight delay may cause the flip to be delayed by
> one refresh cycle.
> 
> Hence, a dedicated workqueue with WQ_HIGHPRI set, has been used here
> since a delay can cause the outcome to miss the refresh cycle.
> 
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary here.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

[PULL] topic/kbl-4.7-fixes

[Daniel Vetter]

Hi Dave,

As promised here's the pile of kbl cherry-picks assembled by Mika
It's a bit much, but all well-contained to kbl code and been tested for a
while in drm-intel-next. Still separate in case too much, but in that case
I think we'd need to disable kbl by default again (which would be annoying
too) in 4.7.

Cheers, Daniel


The following changes since commit 92d21ac74a9e3c09b0b01c764e530657e4c85c49:

  Linux 4.7-rc7 (2016-07-10 20:24:59 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/kbl-4.7-fixes-2016-07-18

for you to fetch changes up to a4a027a860ff58df8df0796d730397a3b30dbc9a:

  drm/i915/kbl: Introduce the first official DMC for Kabylake. (2016-07-18 
18:46:19 +0200)


Daniel Vetter (1):
  drm/i915/psr: Implement PSR2 w/a for gen9

Mika Kuoppala (23):
  drm/i915/skl: Add WaDisableGafsUnitClkGating
  drm/i915/kbl: Init gen9 workarounds
  drm/i915/kbl: Add REVID macro
  drm/i915/kbl: Add WaSkipStolenMemoryFirstPage for A0
  drm/i915/gen9: Always apply WaForceContextSaveRestoreNonCoherent
  drm/i915: Mimic skl with WaForceEnableNonCoherent
  drm/i915/kbl: Add WaEnableGapsTsvCreditFix
  drm/i915/kbl: Add WaDisableFenceDestinationToSLM for A0
  drm/i915/kbl: Add WaDisableSDEUnitClockGating
  drm/i915/kbl: Add WaDisableLSQCROPERFforOCL
  drm/i915/gen9: Enable must set chicken bits in config0 reg
  drm/i915/kbl: Add WaDisableGamClockGating
  drm/i915/kbl: Add WaDisableDynamicCreditSharing
  drm/i915: Add WaInsertDummyPushConstP for bxt and kbl
  drm/i915/kbl: Add WaForGAMHang
  drm/i915/kbl: Add WaDisableGafsUnitClkGating
  drm/i915/kbl: Add WaDisableSbeCacheDispatchPortSharing
  drm/i915/gen9: Add WaEnableChickenDCPR
  drm/i915/kbl: Add WaClearSlmSpaceAtContextSwitch
  drm/i915/gen9: Add WaFbcTurnOffFbcWatermark
  drm/i915/gen9: Add WaFbcWakeMemOn
  drm/i195/fbc: Add WaFbcNukeOnHostModify
  drm/i915/gen9: Add WaFbcHighMemBwCorruptionAvoidance

Rodrigo Vivi (2):
  drm/i915: Introduce Kabypoint PCH for Kabylake H/DT.
  drm/i915/kbl: Introduce the first official DMC for Kabylake.

Tim Gore (1):
  drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

arun.siluvery at linux.intel.com (1):
  drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear

 drivers/gpu/drm/i915/i915_drv.c |   4 +
 drivers/gpu/drm/i915/i915_drv.h |  12 +++
 drivers/gpu/drm/i915/i915_gem_stolen.c  |   6 +-
 drivers/gpu/drm/i915/i915_irq.c |   4 +-
 drivers/gpu/drm/i915/i915_reg.h |  21 +
 drivers/gpu/drm/i915/intel_csr.c|  30 ---
 drivers/gpu/drm/i915/intel_lrc.c|  59 +++-
 drivers/gpu/drm/i915/intel_panel.c  |   3 +-
 drivers/gpu/drm/i915/intel_pm.c |  64 -
 drivers/gpu/drm/i915/intel_ringbuffer.c | 153 
 10 files changed, 295 insertions(+), 61 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/ttm: Remove create_singlethread_workqueue

[Tejun Heo]

On Sat, Jul 16, 2016 at 01:50:17PM +0530, Bhaktipriya Shridhar wrote:
> swap_queue was created to handle shrinking in low memory situations.
> A separate workqueue was used in order to avoid other workqueue tasks
> from being blocked since work items on swap_queue spend a lot of time
> waiting for the GPU.
> 
> Since these long-running work items aren't involved in memory reclaim in
> any way, system_long_wq has been used.
> 
> Work item has been flushed in ttm_mem_global_release() to ensure that
> nothing is pending when the driver is disconnected.
> 
> Signed-off-by: Bhaktipriya Shridhar 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun

drm/ttm: Delete an unnecessary check before the function call "ttm_tt_destroy"

[SF Markus Elfring]

> When resending pls describe what changed (and why).

v3: A bit of reformatting with current software

v2: Broken patch where I managed to delete a "t" too much in a source code
line somehow.

v1: See also a similar update suggestion
https://lkml.org/lkml/2015/11/16/416


Would you like to pick such a software adjustment up?

Regards,
Markus

[PATCH] dma-buf: Release module reference on creation failure

[Sumit Semwal]

Hi Chris,

On 18 July 2016 at 17:40, Daniel Vetter  wrote:
> On Mon, Jul 18, 2016 at 12:16:22PM +0100, Chris Wilson wrote:
>> If we fail to create the anon file, we need to remember to release the
>> module reference on the owner.
>>
Thanks for the patch.

>> Signed-off-by: Chris Wilson 
>> Reviewed-by: Joonas Lahtinen 
>> Cc: Joonas Lahtinen 
>> Cc: Sumit Semwal 
>> Cc: Daniel Vetter 
>> Cc: linux-media at vger.kernel.org
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: linaro-mm-sig at lists.linaro.org
>> ---
>>  drivers/dma-buf/dma-buf.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index 20ce0687b111..ddaee60ae52a 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -334,6 +334,7 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   struct reservation_object *resv = exp_info->resv;
>>   struct file *file;
>>   size_t alloc_size = sizeof(struct dma_buf);
>> + int ret;
>
> Not sure this really helps readability, but meh. Will apply to drm-misc,
> with a cc: stable.
Daniel, fwiw, please feel free to add
Acked-by: Sumit Semwal 

> -Daniel

BR,
~Sumit.
>
>>
>>   if (!exp_info->resv)
>>   alloc_size += sizeof(struct reservation_object);
>> @@ -357,8 +358,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>
>>   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
>>   if (!dmabuf) {
>> - module_put(exp_info->owner);
>> - return ERR_PTR(-ENOMEM);
>> + ret = -ENOMEM;
>> + goto err_module;
>>   }
>>
>>   dmabuf->priv = exp_info->priv;
>> @@ -379,8 +380,8 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
>>   exp_info->flags);
>>   if (IS_ERR(file)) {
>> - kfree(dmabuf);
>> - return ERR_CAST(file);
>> + ret = PTR_ERR(file);
>> + goto err_dmabuf;
>>   }
>>
>>   file->f_mode |= FMODE_LSEEK;
>> @@ -394,6 +395,12 @@ struct dma_buf *dma_buf_export(const struct 
>> dma_buf_export_info *exp_info)
>>   mutex_unlock(_list.lock);
>>
>>   return dmabuf;
>> +
>> +err_dmabuf:
>> + kfree(dmabuf);
>> +err_module:
>> + module_put(exp_info->owner);
>> + return ERR_PTR(ret);
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_export);
>>
>> --
>> 2.8.1
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs

[Intel-gfx] [PATCH] drm/i915/skl: Fix redundant cursor update, fix cursor underruns

[Ville Syrjälä]

On Fri, Jul 15, 2016 at 06:13:56PM -0400, Lyude wrote:
> At long last, the time has finally come for Skylake users to plug their
> external displays back in.
> 
> During intel_atomic_commit() on Skylake, we've actually been arming the
> registers to update the cursor information twice instead of just once.
> Once in i9xx_update_cursor(), and once in skl_wm_flush_pipe(). This
> isn't actually necessary, and removing the later update in
> skl_wm_flush_pipe() has completely stopped the underruns on this T460p
> from occurring when moving the mouse cursor from one monitor to another.
> 
> Signed-off-by: Lyude 
> Cc: Radhakrishna Sripada 
> Cc: Hans de Goede 
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7ac71ec..4771a03 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3860,7 +3860,6 @@ skl_wm_flush_pipe(struct drm_i915_private *dev_priv, 
> enum pipe pipe, int pass)
>   I915_WRITE(PLANE_SURF(pipe, plane),
>  I915_READ(PLANE_SURF(pipe, plane)));
>   }
> - I915_WRITE(CURBASE(pipe), I915_READ(CURBASE(pipe)));

The WM/BUF_CFG register double buffering is armed by the plane surface
register, so if you're removing this write, all you actually end up
doing is skipping the watermark update. So this is just papering over
the bug.

This might even cause more explosions when enabling pipes, as the DDB
configuration for the cursors on the already enabled pipes might not
even get updated, and hence multiple planes migth end up trying to use
the same part of the DDB for their FIFOs.

-- 
Ville Syrjälä
Intel OTC

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Two more regression fixes for 4.7.

Cheers, Daniel


The following changes since commit aeddda06c1a704bb97c8a7bfe7a472120193bd56:

  drm/i915: Ignore panel type from OpRegion on SKL (2016-07-14 16:08:04 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-07-18

for you to fetch changes up to ed2eebbd61af8d378ca39ad7aef7017f29eed6f3:

  drm/i915: add missing condition for committing planes on crtc (2016-07-18 
14:34:51 +0200)


Lionel Landwerlin (1):
  drm/i915: add missing condition for committing planes on crtc

Ville Syrjälä (1):
  drm/i915: Treat eDP as always connected, again

 drivers/gpu/drm/i915/intel_display.c | 6 ++
 drivers/gpu/drm/i915/intel_dp.c  | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

DRM device memory writeback (Mali-DP)

[Daniel Vetter]

On Mon, Jul 18, 2016 at 12:47:38PM +0200, Hans Verkuil wrote:
> On 07/18/2016 12:29 PM, Brian Starkey wrote:
> > Hi,
> > 
> > On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote:
> >> Ville Syrjälä  writes:
> >>
> >>> On Fri, Jul 15, 2016 at 10:09:19AM +0100, Brian Starkey wrote:
>  Hi Daniel,
> 
>  Thanks for taking a look.
> 
>  (+Cc Laurent)
> 
>  On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:
> >> Hi,
> >>
> >> The Mali-DP display processors have a memory-writeback engine which
> >> can write the result of the composition (CRTC output) to a memory
> >> buffer in a variety of formats.
> >>
> >> We're looking for feedback/suggestions on how to expose this in the
> >> mali-dp DRM kernel driver - possibly via V4L2.
> >>
> >> We've got a few use cases where writeback is useful:
> >>- testing, to check the displayed image
> >
> > This might or might not need a separate interface. There are efforts to
> > make the intel kms validation tests in i-g-t generic (well under way
> > already), and part of that is creating a generic infrastructure to 
> > capture
> > display CRCs for functional tests (still in progress).
> >
> > But it might be better if userspace abstracts between full readback and
> > display CRC, assuming we can make full writeback cross-vendor enough for
> > that use-case.
> >
> 
>  I'd lean towards the userspace abstraction.
>  Encumbering a simple CRC interface with all the complexity of
>  full-writeback (size, scaling, pixel format, multi-planar etc.) sounds
>  a bit unnecessary.
> 
>  Of course, if v4l2 isn't going to be the cross-vendor full-writeback
>  implementation, then we need to be aiming to use whatever _is_ in
>  the mali-dp driver.
> 
> >>- screen recording
> >>- wireless display (e.g. Miracast)
> >>- dual-display clone mode
> >>- memory-to-memory composition
> >> Note that the HW is capable of writing one of the input planes instead
> >> of the CRTC output, but we've no good use-case for wanting to expose
> >> that.
> >>
> >> In our Android ADF driver[1] we exposed the memory write engine as
> >> part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
> >> doesn't have any similar support for memory output from CRTCs, but we
> >> want to expose the functionality in the mainline Mali-DP DRM driver.
> >>
> >> A previous discussion on the topic went towards exposing the
> >> memory-write engine via V4L2[2].
> >>
> >> I'm thinking to userspace this would look like two distinct devices:
> >>- A DRM KMS display controller.
> >>- A V4L2 video source.
> >> They'd both exist in the same kernel driver.
> >> A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
> >> the DRM driver would see if there's a buffer to dequeue every time a
> >> new modeset is received via the DRM API - if so, it can configure the
> >> HW to dump into it (one-shot operation).
> >>
> >> An implication of this is that if the screen is actively displaying a
> >> static scene and the V4L2 client queues up a buffer, it won't get
> >> filled until the DRM scene changes. This seems best, otherwise the
> >> V4L2 driver has to change the HW configuration out-of-band from the
> >> DRM device which sounds horribly racy.
> >>
> >> One further complication is scaling. Our HW has a scaler which can
> >> tasked with either scaling an input plane or the buffer being written
> >> to memory, but not both at the same time. This means we need to
> >> arbitrate the scaler between the DRM device (scaling input planes) and
> >> the V4L2 device (scaling output buffers).
> >>
> >> I think the simplest approach here is to allow V4L2 to "claim" the
> >> scaler by setting the image size (VIDIOC_S_FMT) to something other
> >> than the CRTC's current resolution. After that, any attempt to use the
> >> scaler on an input plane via DRM should fail atomic_check().
> >
> > That's perfectly fine atomic_check behaviour. Only trouble is that the 
> > v4l
> > locking must integrate into the drm locking, but that should be doable.
> > Worst case you must shadow all v4l locks with a wait/wound
> > drm_modeset_lock to avoid deadlocks (since you could try to grab locks
>  >from either end).
> >
> 
>  Yes, I haven't looked at the details of the locking but I'm hoping
>  it's manageable.
> 
> >> If the V4L2 client goes away or sets the image size to the CRTC's
> >> native resolution, then the DRM device is allowed to use the scaler.
> >> I don't know if/how the DRM device should communicate to userspace
> >> that the scaler is or 

[PATCH] drm/vgem: Remember to offset relative timeouts to mod_timer() by jiffies

[Daniel Vetter]

On Mon, Jul 18, 2016 at 10:31:18AM +0100, Chris Wilson wrote:
> mod_timer() takes an absolute jiffie value, not a relative timeout and
> quietly fixup the missed ret=0 otherwise gcc just always returns that
> the fence timed out.
> 
> Testcase: igt/vgem_basic/fence
> Fixes: 407779848445 ("drm/vgem: Attach sw fences to exported vGEM dma-buf")
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 

Oops. Applied to drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
> b/drivers/gpu/drm/vgem/vgem_fence.c
> index e77b52208699..892417ba2622 100644
> --- a/drivers/gpu/drm/vgem/vgem_fence.c
> +++ b/drivers/gpu/drm/vgem/vgem_fence.c
> @@ -107,7 +107,7 @@ static struct fence *vgem_fence_create(struct vgem_file 
> *vfile,
>   setup_timer(>timer, vgem_fence_timeout, (unsigned long)fence);
>  
>   /* We force the fence to expire within 10s to prevent driver hangs */
> - mod_timer(>timer, VGEM_FENCE_TIMEOUT);
> + mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);
>  
>   return >base;
>  }
> @@ -240,7 +240,7 @@ int vgem_fence_signal_ioctl(struct drm_device *dev,
>   struct vgem_file *vfile = file->driver_priv;
>   struct drm_vgem_fence_signal *arg = data;
>   struct fence *fence;
> - int ret;
> + int ret = 0;
>  
>   if (arg->flags)
>   return -EINVAL;
> -- 
> 2.8.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3] drm/ttm: Delete an unnecessary check before the function call "ttm_tt_destroy"

[Daniel Vetter]

On Mon, Jul 18, 2016 at 04:10:36PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Mon, 18 Jul 2016 16:06:18 +0200
> 
> The ttm_tt_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

When resending pls describe what changed (and why). Also I'd still like
that smatch included in the commit message.
-Daniel

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 39386f5..4e55863 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -146,9 +146,7 @@ static void ttm_bo_release_list(struct kref *list_kref)
>   BUG_ON(bo->mem.mm_node != NULL);
>   BUG_ON(!list_empty(>lru));
>   BUG_ON(!list_empty(>ddestroy));
> -
> - if (bo->ttm)
> - ttm_tt_destroy(bo->ttm);
> + ttm_tt_destroy(bo->ttm);
>   atomic_dec(>glob->bo_count);
>   if (bo->resv == >ttm_resv)
>   reservation_object_fini(>ttm_resv);
> -- 
> 2.9.2
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/7] de-stage SW_SYNC validation frawework

[Gustavo Padovan]

Hi,

Do you think there is time to get this in for 4.8?

Thanks.

2016-06-20 Gustavo Padovan :

> From: Gustavo Padovan 
> 
> Hi Greg,
> 
> This is the last step in the Sync Framwork de-stage task. It de-stage
> the SW_SYNC validation framework and the sync_debug info debugfs file.
> 
> The first 3 patches are clean up and improvements and the rest is preparation
> to de-stage and then finally the actual de-stage.
> 
> Please review,
> 
> Gustavo
> 
> ---
> Gustavo Padovan (7):
>   staging/android: move trace/sync.h to sync_trace.h
>   staging/android: remove doc from sw_sync
>   staging/android: display sync_pt name on debugfs
>   staging/android: do not let userspace trigger WARN_ON
>   staging/android: prepare sw_sync files for de-staging
>   dma-buf/sw_sync: de-stage SW_SYNC
>   staging/android: remove sync framework TODO
> 
>  drivers/dma-buf/Kconfig| 14 +++
>  drivers/dma-buf/Makefile   |  1 +
>  drivers/{staging/android => dma-buf}/sw_sync.c | 46 
> +++---
>  drivers/{staging/android => dma-buf}/sync_debug.c  |  7 ++--
>  drivers/{staging/android => dma-buf}/sync_debug.h  | 26 +---
>  .../android/trace/sync.h => dma-buf/sync_trace.h}  |  6 +--
>  drivers/staging/android/Kconfig| 13 --
>  drivers/staging/android/Makefile   |  1 -
>  drivers/staging/android/TODO   |  8 
>  9 files changed, 38 insertions(+), 84 deletions(-)
>  rename drivers/{staging/android => dma-buf}/sw_sync.c (84%)
>  rename drivers/{staging/android => dma-buf}/sync_debug.c (97%)
>  rename drivers/{staging/android => dma-buf}/sync_debug.h (72%)
>  rename drivers/{staging/android/trace/sync.h => dma-buf/sync_trace.h} (84%)
> 
> -- 
> 2.5.5
> 

Gustavo

[PATCH v3] drm/ttm: Delete an unnecessary check before the function call "ttm_tt_destroy"

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 18 Jul 2016 16:06:18 +0200

The ttm_tt_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 39386f5..4e55863 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -146,9 +146,7 @@ static void ttm_bo_release_list(struct kref *list_kref)
BUG_ON(bo->mem.mm_node != NULL);
BUG_ON(!list_empty(>lru));
BUG_ON(!list_empty(>ddestroy));
-
-   if (bo->ttm)
-   ttm_tt_destroy(bo->ttm);
+   ttm_tt_destroy(bo->ttm);
atomic_dec(>glob->bo_count);
if (bo->resv == >ttm_resv)
reservation_object_fini(>ttm_resv);
-- 
2.9.2

[PATCH 2/2] drm/imx: Remove imx_drm_crtc_id()

[Liu Ying]

There is no one calling imx_drm_crtc_id() and it is just a simple
wrapper of drm_crtc_index() without doing any thing fancy - the
drivers may call drm_crtc_index() directly.  So, let's remove the
wrapper.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 6 --
 drivers/gpu/drm/imx/imx-drm.h  | 2 --
 2 files changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 1fd1900..1aefced 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -58,12 +58,6 @@ static int legacyfb_depth = 16;
 module_param(legacyfb_depth, int, 0444);
 #endif

-unsigned int imx_drm_crtc_id(struct imx_drm_crtc *crtc)
-{
-   return drm_crtc_index(crtc->crtc);
-}
-EXPORT_SYMBOL_GPL(imx_drm_crtc_id);
-
 static void imx_drm_driver_lastclose(struct drm_device *drm)
 {
struct imx_drm_device *imxdrm = drm->dev_private;
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 0049b77f..bdaa381 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -13,8 +13,6 @@ struct drm_plane;
 struct imx_drm_crtc;
 struct platform_device;

-unsigned int imx_drm_crtc_id(struct imx_drm_crtc *crtc);
-
 struct imx_crtc_state {
struct drm_crtc_state   base;
u32 bus_format;
-- 
2.7.4

[PATCH 1/2] drm/imx: Remove imx_drm_crtc_vblank_get/_put()

[Liu Ying]

There is no one calling imx_drm_crtc_vblank_get/_put() and
they are just two simple wrappers of drm_crtc_vblank_get/_put()
without doing any thing fancy - the drivers may call
drm_crtc_vblank_get/_put() directly.  So, let's remove the two
wrappers.

Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 12 
 drivers/gpu/drm/imx/imx-drm.h  |  2 --
 2 files changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 9f7dafc..1fd1900 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -90,18 +90,6 @@ static int imx_drm_driver_unload(struct drm_device *drm)
return 0;
 }

-int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc)
-{
-   return drm_crtc_vblank_get(imx_drm_crtc->crtc);
-}
-EXPORT_SYMBOL_GPL(imx_drm_crtc_vblank_get);
-
-void imx_drm_crtc_vblank_put(struct imx_drm_crtc *imx_drm_crtc)
-{
-   drm_crtc_vblank_put(imx_drm_crtc->crtc);
-}
-EXPORT_SYMBOL_GPL(imx_drm_crtc_vblank_put);
-
 void imx_drm_handle_vblank(struct imx_drm_crtc *imx_drm_crtc)
 {
drm_crtc_handle_vblank(imx_drm_crtc->crtc);
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 07d33e4..0049b77f 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -44,8 +44,6 @@ int imx_drm_init_drm(struct platform_device *pdev,
int preferred_bpp);
 int imx_drm_exit_drm(void);

-int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc);
-void imx_drm_crtc_vblank_put(struct imx_drm_crtc *imx_drm_crtc);
 void imx_drm_handle_vblank(struct imx_drm_crtc *imx_drm_crtc);

 void imx_drm_mode_config_init(struct drm_device *drm);
-- 
2.7.4

[PATCH v2] drm/radeon: Remove deprecated create_singlethread_workqueue

[Christian König]

Am 16.07.2016 um 13:30 schrieb Bhaktipriya Shridhar:
> alloc_workqueue replaces deprecated create_singlethread_workqueue().
>
> Each hardware CRTC has a single flip work queue.
> When a radeon_flip_work_func item is queued, it needs to be executed
> ASAP because even a slight delay may cause the flip to be delayed by
> one refresh cycle.
>
> Hence, a dedicated workqueue with WQ_HIGHPRI set, has been used here
> since a delay can cause the outcome to miss the refresh cycle.
>
> Since there are only a fixed number of work items, explicit concurrency
> limit is unnecessary here.
>
> Signed-off-by: Bhaktipriya Shridhar 

Reviewed-by: Christian König 

> ---
>   Changes in v2:
>   -Used a dedicated work queue with WQ_HIGHPRI
>
>   drivers/gpu/drm/radeon/radeon_display.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 6a41b49..64b246e 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -711,7 +711,7 @@ static void radeon_crtc_init(struct drm_device *dev, int 
> index)
>
>   drm_mode_crtc_set_gamma_size(_crtc->base, 256);
>   radeon_crtc->crtc_id = index;
> - radeon_crtc->flip_queue = create_singlethread_workqueue("radeon-crtc");
> + radeon_crtc->flip_queue = alloc_workqueue("radeon-crtc", WQ_HIGHPRI, 0);
>   rdev->mode_info.crtcs[index] = radeon_crtc;
>
>   if (rdev->family >= CHIP_BONAIRE) {
> --
> 2.1.4
>

[PATCH v4 4/8] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

One comment inline.

On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
> 
> Signed-off-by: YT Shen 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|6 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   41 
> +++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |7 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |1 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   31 
>  6 files changed, 92 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index eb5c05e..1da0a71 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -286,11 +286,17 @@ static int mtk_disp_ovl_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct mtk_ddp_comp_driver_data mt2701_ovl_driver_data = {
> + .ovl = {0x0040, 1 << 12, 0}
> +};
> +
>  static const struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
>   .ovl = {0x0f40, 0, 1 << 12}
>  };
>  
>  static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-ovl",
> +   .data = _ovl_driver_data},
>   { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
>   {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index fb0db50..506a353 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -225,11 +225,17 @@ static int mtk_disp_rdma_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static const struct mtk_ddp_comp_driver_data mt2701_rdma_driver_data = {
> + .rdma_fifo_pseudo_size = SZ_4K,
> +};
> +
>  static const struct mtk_ddp_comp_driver_data mt8173_rdma_driver_data = {
>   .rdma_fifo_pseudo_size = SZ_8K,
>  };
>  
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> + { .compatible = "mediatek,mt2701-disp-rdma",
> +   .data = _rdma_driver_data},
>   { .compatible = "mediatek,mt8173-disp-rdma",
> .data = _rdma_driver_data},
>   {},
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index fa53806..ee0326a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -32,6 +32,10 @@
>  #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN   0x0c8
>  #define DISP_REG_CONFIG_MMSYS_CG_CON00x100
>  
> +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
> +#define DISP_REG_CONFIG_OUT_SEL  0x04c
> +#define DISP_REG_CONFIG_DSI_SEL  0x050
> +
>  #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
>  #define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
>  #define DISP_REG_MUTEX_RST(n)(0x28 + 0x20 * (n))
> @@ -54,6 +58,13 @@
>  #define MT8173_MUTEX_MOD_DISP_PWM1   BIT(24)
>  #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>  
> +#define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
> +#define MT2701_MUTEX_MOD_DISP_WDMA   BIT(6)
> +#define MT2701_MUTEX_MOD_DISP_COLOR  BIT(7)
> +#define MT2701_MUTEX_MOD_DISP_BLSBIT(9)
> +#define MT2701_MUTEX_MOD_DISP_RDMA0  BIT(10)
> +#define MT2701_MUTEX_MOD_DISP_RDMA1  BIT(12)
> +
>  #define MUTEX_SOF_SINGLE_MODE0
>  #define MUTEX_SOF_DSI0   1
>  #define MUTEX_SOF_DSI1   2
> @@ -69,6 +80,10 @@
>  #define DPI0_SEL_IN_RDMA10x1
>  #define COLOR1_SEL_IN_OVL1   0x1
>  
> +#define OVL_MOUT_EN_RDMA 0x1
> +#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
> +#define DSI_SEL_IN_BLS   0x0
> +
>  struct mtk_disp_mutex {
>   int id;
>   bool claimed;
> @@ -82,6 +97,15 @@ struct mtk_ddp {
>   const unsigned int  *mutex_mod;
>  };
>  
> +static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_BLS] = MT2701_MUTEX_MOD_DISP_BLS,
> + [DDP_COMPONENT_COLOR0] = MT2701_MUTEX_MOD_DISP_COLOR,
> + [DDP_COMPONENT_OVL0] = MT2701_MUTEX_MOD_DISP_OVL,
> + [DDP_COMPONENT_RDMA0] = MT2701_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2701_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> +};
> +
>  static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
>   [DDP_COMPONENT_AAL] = MT8173_MUTEX_MOD_DISP_AAL,
>   [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> @@ -109,6 +133,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id 
> cur,
>   if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
>   *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
>   value 

[PATCH v4 3/8] drm/mediatek: add shadow register support

[CK Hu]

Hi, YT:

One comment inline.


On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> We need to acquire mutex before using the resources,
> and need to release it after finished.
> So we don't need to write registers in the blanking period.
> 
> Signed-off-by: YT Shen 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   75 
> +++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   22 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |2 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |1 +
>  4 files changed, 71 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 24aa3ba..80d9641 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -315,6 +315,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
> *mtk_crtc)
>   pm_runtime_put(drm->dev);
>  }
>  
> +static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> +{
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> + struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
> + unsigned int i;
> +
> + /*
> +  * TODO: instead of updating the registers here, we should prepare
> +  * working registers in atomic_commit and let the hardware command
> +  * queue update module registers on vblank.
> +  */
> + if (state->pending_config) {
> + mtk_ddp_comp_config(ovl, state->pending_width,
> + state->pending_height,
> + state->pending_vrefresh);
> +
> + state->pending_config = false;
> + }
> +
> + if (mtk_crtc->pending_planes) {
> + for (i = 0; i < OVL_LAYER_NR; i++) {
> + struct drm_plane *plane = _crtc->planes[i].base;
> + struct mtk_plane_state *plane_state;
> +
> + plane_state = to_mtk_plane_state(plane->state);
> +
> + if (plane_state->pending.config) {
> + mtk_ddp_comp_layer_config(ovl, i, plane_state);
> + plane_state->pending.config = false;
> + }
> + }
> + mtk_crtc->pending_planes = false;
> + }
> +}
> +
>  static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
>  {
>   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> @@ -391,6 +427,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> *crtc,
> struct drm_crtc_state *old_crtc_state)
>  {
>   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
>   unsigned int pending_planes = 0;
>   int i;
>  
> @@ -409,6 +446,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   }
>   if (pending_planes)
>   mtk_crtc->pending_planes = true;
> +
> + if (priv->data->shadow_register) {
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
>  }
>  
>  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> @@ -453,36 +496,10 @@ err_cleanup_crtc:
>  void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
>  {
>   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> - struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> - unsigned int i;
> + struct mtk_drm_private *priv = crtc->dev->dev_private;
>  
> - /*
> -  * TODO: instead of updating the registers here, we should prepare
> -  * working registers in atomic_commit and let the hardware command
> -  * queue update module registers on vblank.
> -  */
> - if (state->pending_config) {
> - mtk_ddp_comp_config(ovl, state->pending_width,
> - state->pending_height,
> - state->pending_vrefresh);
> -
> - state->pending_config = false;
> - }
> -
> - if (mtk_crtc->pending_planes) {
> - for (i = 0; i < OVL_LAYER_NR; i++) {
> - struct drm_plane *plane = _crtc->planes[i].base;
> - struct mtk_plane_state *plane_state;
> -
> - plane_state = to_mtk_plane_state(plane->state);
> -
> - if (plane_state->pending.config) {
> - mtk_ddp_comp_layer_config(ovl, i, plane_state);
> - plane_state->pending.config = false;
> - }
> - }
> - mtk_crtc->pending_planes = false;
> - }
> + if (!priv->data->shadow_register)
> + mtk_crtc_ddp_config(crtc);
>  
>   mtk_drm_finish_page_flip(mtk_crtc);
>  }
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> 

Kernel stability on baytrail machines

[One Thousand Gnomes]

On Tue, 12 Jul 2016 16:41:58 -0300
Ezequiel Garcia  wrote:

> Hi Alan,
> 
> (Adding interested people to this thread)
> 
> On 09 Apr 08:14 PM, One Thousand Gnomes wrote:
> > > > I do feel that the importance of the mentioned bug is currently
> > > > underestimated. Can anyone here give a note, how much current linux
> > > > kernel is supposed to be stable on general baytrail machines?
> > > 
> > > If you did not get any replies... you might want to check MAINTAINERS 
> > > file, and
> > > put Intel x86 maintainers on Cc list.
> > > 
> > > I'm sure someone cares :-).  
> > 
> > Yes we care, and there are people looking at the various reports.
> >   
> 
> Are there any updates on the status of this issue?
> 
> The current bugzilla report [1] marks this as a power management
> issue. However, many reports indicate that it would only freeze
> when running X, so it's not completely clear if it's related to
> the gfx driver too.

There are two things we are currently tracking. One of them was merged
which seems to have made my machine stable at least and fixes a problem
related to the MMC. The second one we may need is a power related changed
to SPI to hold the CPU in C0/C1 whenever the ACPI _SEM is held.

Graphics shows these problems up because of the way the GPU causes power
state changes.

Alan

[PATCH v3 1/2] drm/dsi: Implement dcs set/get display brightness

[Emil Velikov]

On 18 July 2016 at 09:28, Vinay Simha BN  wrote:
> Provide a small convenience wrapper that set/get the
> display brightness value
>
> Cc: John Stultz 
> Cc: Sumit Semwal 
> Cc: Archit Taneja 
> Cc: Rob Clark 
> Cc: Jani Nikula 
> Cc: Thierry Reding 
> Cc: Emil Velikov 
> Signed-off-by: Vinay Simha BN 
>
> ---
> v1:
>  *tested in nexus7 2nd gen.
>
> v2:
>  * implemented jani review comments
>-functions name mapped accordingly
>-bl value increased from 0xff to 0x
>-backlight interface will be handled in panel driver,
> so it is moved from the mipi_dsi helper function
>
> v3:
>  * emil review comments
>(err < 0) supposed to be (err <= 0)
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 49 
> ++
>  include/drm/drm_mipi_dsi.h |  4 
>  2 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index af0d471..43aa743 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -1041,6 +1041,55 @@ int mipi_dsi_dcs_set_pixel_format(struct 
> mipi_dsi_device *dsi, u8 format)
>  }
>  EXPORT_SYMBOL(mipi_dsi_dcs_set_pixel_format);
>
> +/**
> + * mipi_dsi_dcs_get_display_brightness() - gets the current brightness value
> + * of the display
> + * @dsi: DSI peripheral device
> + * @brightness: brightness value
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
> +   u16 *brightness)
> +{
> +   ssize_t err;
> +
> +   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_BRIGHTNESS,
> +   brightness, sizeof(*brightness));
> +   if (err <= 0) {
> +   if (err == 0)
> +   err = -ENODATA;
> +
Looks better now. Thank you.

> +   return err;
Side note:
When sizeof(ssize_t) != sizeof(int) this might lead to some very
annoying bugs. In practise I doubt anyone uses error codes in the
SSIZE_MIN to INT_MIN range so we should be safe.

Reviewed-by: Emil Velikov 

Regards,
Emil

[PATCH] dma-buf: Release module reference on creation failure

[Daniel Vetter]

On Mon, Jul 18, 2016 at 12:16:22PM +0100, Chris Wilson wrote:
> If we fail to create the anon file, we need to remember to release the
> module reference on the owner.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Joonas Lahtinen 
> Cc: Joonas Lahtinen 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> ---
>  drivers/dma-buf/dma-buf.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 20ce0687b111..ddaee60ae52a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -334,6 +334,7 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>   struct reservation_object *resv = exp_info->resv;
>   struct file *file;
>   size_t alloc_size = sizeof(struct dma_buf);
> + int ret;

Not sure this really helps readability, but meh. Will apply to drm-misc,
with a cc: stable.
-Daniel

>  
>   if (!exp_info->resv)
>   alloc_size += sizeof(struct reservation_object);
> @@ -357,8 +358,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>  
>   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
>   if (!dmabuf) {
> - module_put(exp_info->owner);
> - return ERR_PTR(-ENOMEM);
> + ret = -ENOMEM;
> + goto err_module;
>   }
>  
>   dmabuf->priv = exp_info->priv;
> @@ -379,8 +380,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>   file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
>   exp_info->flags);
>   if (IS_ERR(file)) {
> - kfree(dmabuf);
> - return ERR_CAST(file);
> + ret = PTR_ERR(file);
> + goto err_dmabuf;
>   }
>  
>   file->f_mode |= FMODE_LSEEK;
> @@ -394,6 +395,12 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>   mutex_unlock(_list.lock);
>  
>   return dmabuf;
> +
> +err_dmabuf:
> + kfree(dmabuf);
> +err_module:
> + module_put(exp_info->owner);
> + return ERR_PTR(ret);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_export);
>  
> -- 
> 2.8.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v8 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

[Vinay Simha BN]

Add support for the JDI LT070ME05000 WUXGA DSI panel used in
Nexus 7 2013 devices.

Programming sequence for the panel is was originally found in the
android-msm-flo-3.4-lollipop-release branch from:
https://android.googlesource.com/kernel/msm.git

And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
file in:
git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27

Cc: Archit Taneja 
Cc: Rob Clark 
Cc: Sumit Semwal 
Cc: John Stultz 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: David Airlie 
Signed-off-by: Sumit Semwal 
Signed-off-by: John Stultz 
Signed-off-by: Vinay Simha BN 
Tested-by: John Stultz 
Reviewed-by: Emil Velikov 

---
v1:
 * sumit ported to drm/panel framework, john cherry-picked to mainline,
   folded down other fixes from Vinay and Archit, vinay removed interface
   setting cmd mode, video mode panel selected

v2:
 * incorporated code reviews from theiry, archit
   code style, alphabetical soring in Makefile, Kconfig, regulator_bulk,
   arrays of u8, generic helper function, documentation bindings,

v3:
 * dcs backlight support added
 * tested this panel driver in nexus7 2013 device

v4:
 * backlight interface added in the panel driver
 * incorporated width_mm and height_mm suggested by rob herring

v5:
 * theirry review comments incorporated
   panel model naming consistent, alphabetical soring in Kconfig
   Makefile, MAX_BRIGHTNESS dropped, regulator_names, parameterize
   panel width and height, descprition for control display, cabc
   and interface setting, temporary variable removed, consistent
   error reporting and commit message
 * removed tear on/off, scanline, since these are required only
   for command mode panels

v6:
 * emil review comments incorporated
   PANEL_NUM_REGULATORS dropped, return ret added at necessary
   places, if checks dropped for backlight and gpios

v7:
 * emil review comments incorporated
   added ARRAY_SIZE in struct, regulator_bulk_disable in poweroff,
   gpios checks dropped.
   some returns cannot be dropped, since drm panel framework return
   type required.

v8:
 * emil review commnets incorporated for jdi_panel_unprepare,
   dropped the returns (ref: panel-sharp-lq101r1sx01.c) and
   for jdi_panel_prepare(panel_on) it does not return prematurely
   and goes to poweroff if not success
 * few dev_err's for panel_init
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 518 +
 3 files changed, 530 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-jdi-lt070me05000.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 1500ab9..62aba97 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -18,6 +18,17 @@ config DRM_PANEL_SIMPLE
  that it can be automatically turned off when the panel goes into a
  low power state.

+config DRM_PANEL_JDI_LT070ME05000
+   tristate "JDI LT070ME05000 WUXGA DSI panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for JDI DSI video mode
+ panel as found in Google Nexus 7 (2013) devices.
+ The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
+ 24 bit per pixel.
+
 config DRM_PANEL_SAMSUNG_LD9040
tristate "Samsung LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f277eed..a5c7ec0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c 
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
new file mode 100644
index 000..3af35ad
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -0,0 +1,518 @@
+/*
+ * Copyright (C) 2016 InforceComputing
+ * Author: Vinay Simha BN 
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ * Author: Sumit Semwal 
+ *
+ * From internet archives, the panel for Nexus 7 2nd Gen, 2013 model is a
+ * JDI model LT070ME05000, and its data sheet is at:
+ * http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the 

[PATCH v3 1/2] drm/dsi: Implement dcs set/get display brightness

[Vinay Simha BN]

Provide a small convenience wrapper that set/get the
display brightness value

Cc: John Stultz 
Cc: Sumit Semwal 
Cc: Archit Taneja 
Cc: Rob Clark 
Cc: Jani Nikula 
Cc: Thierry Reding 
Cc: Emil Velikov 
Signed-off-by: Vinay Simha BN 

---
v1:
 *tested in nexus7 2nd gen.

v2:
 * implemented jani review comments
   -functions name mapped accordingly
   -bl value increased from 0xff to 0x
   -backlight interface will be handled in panel driver,
so it is moved from the mipi_dsi helper function

v3:
 * emil review comments
   (err < 0) supposed to be (err <= 0)
---
 drivers/gpu/drm/drm_mipi_dsi.c | 49 ++
 include/drm/drm_mipi_dsi.h |  4 
 2 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index af0d471..43aa743 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -1041,6 +1041,55 @@ int mipi_dsi_dcs_set_pixel_format(struct mipi_dsi_device 
*dsi, u8 format)
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_set_pixel_format);

+/**
+ * mipi_dsi_dcs_get_display_brightness() - gets the current brightness value
+ * of the display
+ * @dsi: DSI peripheral device
+ * @brightness: brightness value
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
+   u16 *brightness)
+{
+   ssize_t err;
+
+   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_BRIGHTNESS,
+   brightness, sizeof(*brightness));
+   if (err <= 0) {
+   if (err == 0)
+   err = -ENODATA;
+
+   return err;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_get_display_brightness);
+
+/**
+ * mipi_dsi_dcs_set_display_brightness() - sets the brightness value of
+ * the display
+ * @dsi: DSI peripheral device
+ * @brightness: brightness value
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int mipi_dsi_dcs_set_display_brightness(struct mipi_dsi_device *dsi,
+   u16 brightness)
+{
+   ssize_t err;
+   u8 bl_value[2] = { brightness & 0xff, brightness >> 8 };
+
+   err = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
+bl_value, sizeof(bl_value));
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_set_display_brightness);
+
 static int mipi_dsi_drv_probe(struct device *dev)
 {
struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 47ac925..404c373 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -270,6 +270,10 @@ int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
 int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
 enum mipi_dsi_dcs_tear_mode mode);
 int mipi_dsi_dcs_set_pixel_format(struct mipi_dsi_device *dsi, u8 format);
+int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
+   u16 *brightness);
+int mipi_dsi_dcs_set_display_brightness(struct mipi_dsi_device *dsi,
+   u16 brightness);

 /**
  * struct mipi_dsi_driver - DSI driver
-- 
2.1.2

[PATCH v8 4/4] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

[Vinay Simha]

On Fri, Jul 15, 2016 at 2:48 AM, Emil Velikov 
wrote:

> On 13 July 2016 at 19:58, John Stultz  wrote:
> > On Wed, Jul 13, 2016 at 9:44 AM, Vinay Simha BN 
> wrote:
> >> Add support for the JDI LT070ME05000 WUXGA DSI panel used in
> >> Nexus 7 2013 devices.
> >>
> >> Programming sequence for the panel is was originally found in the
> >> android-msm-flo-3.4-lollipop-release branch from:
> >> https://android.googlesource.com/kernel/msm.git
> >>
> >> And video mode setting is from dsi-panel-jdi-dualmipi1-video.dtsi
> >> file in:
> >> git://codeaurora.org/kernel/msm-3.10.git  LNX.LA.3.6_rb1.27
> >>
> >> Cc: Archit Taneja 
> >> Cc: Rob Clark 
> >> Cc: Sumit Semwal 
> >> Cc: John Stultz 
> >> Cc: Emil Velikov 
> >> Cc: Thierry Reding 
> >> Cc: David Airlie 
> >> Signed-off-by: Sumit Semwal 
> >> Signed-off-by: John Stultz 
> >> Signed-off-by: Vinay Simha BN 
> >
> > Just fyi, I've re-integrated this patch set into my flo-WIP branch and
> > its working well.
> >
> > I dunno if its of any use, but:
> > Tested-by: John Stultz 
> >
> It always is. Thank you!
>
> Vinay, thanks for the patience and I hope you grok the reason behind
> the requested changes.
>
yes.

premature returns should be avoided. it leads to the caller failure,
intermediate funcs also will not get executed (gpios, regulator disable).
In this case even the dsi fails, it should be panel(dsi write) failures
rather than the bridge/interface.

>
> The patch is
> Reviewed-by: Emil Velikov 
>
> Regards,
> Emil
>



-- 
Regards,

Vinay Simha.B.N.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/c7432098/attachment-0001.html>

[PATCH v2 3/4] drm/dsi: Implement dcs set/get display brightness

[Vinay Simha]

yes, it is wrong.
it supposed to be

if(err <= 0) {
  if(err == 0)

will resend a modified version

On Fri, Jul 15, 2016 at 2:50 AM, Emil Velikov 
wrote:

> On 13 July 2016 at 17:44, Vinay Simha BN  wrote:
>
> > +int mipi_dsi_dcs_get_display_brightness(struct mipi_dsi_device *dsi,
> > +   u16 *brightness)
> > +{
> > +   ssize_t err;
> > +
> > +   err = mipi_dsi_dcs_read(dsi, MIPI_DCS_GET_DISPLAY_BRIGHTNESS,
> > +   brightness, sizeof(*brightness));
> > +   if (err < 0) {
> > +   if (err == 0)
> Something looks fishy here. This can never be true, can it ?
>
>  -Emil
>



-- 
Regards,

Vinay Simha.B.N.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/6534a248/attachment-0001.html>

[Bug 96860] Aliasing when using vdpau with mpv

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96860

--- Comment #5 from Christian König  ---
I'm still curios what could have been the issue here.

But that doesn't sound like something we need to push on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/bdce3c74/attachment.html>

DRM device memory writeback (Mali-DP)

[Hans Verkuil]

On 07/18/2016 12:29 PM, Brian Starkey wrote:
> Hi,
> 
> On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote:
>> Ville Syrjälä  writes:
>>
>>> On Fri, Jul 15, 2016 at 10:09:19AM +0100, Brian Starkey wrote:
 Hi Daniel,

 Thanks for taking a look.

 (+Cc Laurent)

 On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:
> On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:
>> Hi,
>>
>> The Mali-DP display processors have a memory-writeback engine which
>> can write the result of the composition (CRTC output) to a memory
>> buffer in a variety of formats.
>>
>> We're looking for feedback/suggestions on how to expose this in the
>> mali-dp DRM kernel driver - possibly via V4L2.
>>
>> We've got a few use cases where writeback is useful:
>>- testing, to check the displayed image
>
> This might or might not need a separate interface. There are efforts to
> make the intel kms validation tests in i-g-t generic (well under way
> already), and part of that is creating a generic infrastructure to capture
> display CRCs for functional tests (still in progress).
>
> But it might be better if userspace abstracts between full readback and
> display CRC, assuming we can make full writeback cross-vendor enough for
> that use-case.
>

 I'd lean towards the userspace abstraction.
 Encumbering a simple CRC interface with all the complexity of
 full-writeback (size, scaling, pixel format, multi-planar etc.) sounds
 a bit unnecessary.

 Of course, if v4l2 isn't going to be the cross-vendor full-writeback
 implementation, then we need to be aiming to use whatever _is_ in
 the mali-dp driver.

>>- screen recording
>>- wireless display (e.g. Miracast)
>>- dual-display clone mode
>>- memory-to-memory composition
>> Note that the HW is capable of writing one of the input planes instead
>> of the CRTC output, but we've no good use-case for wanting to expose
>> that.
>>
>> In our Android ADF driver[1] we exposed the memory write engine as
>> part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
>> doesn't have any similar support for memory output from CRTCs, but we
>> want to expose the functionality in the mainline Mali-DP DRM driver.
>>
>> A previous discussion on the topic went towards exposing the
>> memory-write engine via V4L2[2].
>>
>> I'm thinking to userspace this would look like two distinct devices:
>>- A DRM KMS display controller.
>>- A V4L2 video source.
>> They'd both exist in the same kernel driver.
>> A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
>> the DRM driver would see if there's a buffer to dequeue every time a
>> new modeset is received via the DRM API - if so, it can configure the
>> HW to dump into it (one-shot operation).
>>
>> An implication of this is that if the screen is actively displaying a
>> static scene and the V4L2 client queues up a buffer, it won't get
>> filled until the DRM scene changes. This seems best, otherwise the
>> V4L2 driver has to change the HW configuration out-of-band from the
>> DRM device which sounds horribly racy.
>>
>> One further complication is scaling. Our HW has a scaler which can
>> tasked with either scaling an input plane or the buffer being written
>> to memory, but not both at the same time. This means we need to
>> arbitrate the scaler between the DRM device (scaling input planes) and
>> the V4L2 device (scaling output buffers).
>>
>> I think the simplest approach here is to allow V4L2 to "claim" the
>> scaler by setting the image size (VIDIOC_S_FMT) to something other
>> than the CRTC's current resolution. After that, any attempt to use the
>> scaler on an input plane via DRM should fail atomic_check().
>
> That's perfectly fine atomic_check behaviour. Only trouble is that the v4l
> locking must integrate into the drm locking, but that should be doable.
> Worst case you must shadow all v4l locks with a wait/wound
> drm_modeset_lock to avoid deadlocks (since you could try to grab locks
 >from either end).
>

 Yes, I haven't looked at the details of the locking but I'm hoping
 it's manageable.

>> If the V4L2 client goes away or sets the image size to the CRTC's
>> native resolution, then the DRM device is allowed to use the scaler.
>> I don't know if/how the DRM device should communicate to userspace
>> that the scaler is or isn't available for use.
>>
>> Any thoughts on this approach?
>> Is it acceptable to both V4L2 and DRM folks?
>
> For streaming a V4L2 capture device seems like the right interface. But if
> you want to use writeback in your compositor you must know which 

[PATCH] dma-buf: Release module reference on creation failure

[Chris Wilson]

If we fail to create the anon file, we need to remember to release the
module reference on the owner.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Cc: Joonas Lahtinen 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 20ce0687b111..ddaee60ae52a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -334,6 +334,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
struct reservation_object *resv = exp_info->resv;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
+   int ret;

if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
@@ -357,8 +358,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)

dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (!dmabuf) {
-   module_put(exp_info->owner);
-   return ERR_PTR(-ENOMEM);
+   ret = -ENOMEM;
+   goto err_module;
}

dmabuf->priv = exp_info->priv;
@@ -379,8 +380,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf,
exp_info->flags);
if (IS_ERR(file)) {
-   kfree(dmabuf);
-   return ERR_CAST(file);
+   ret = PTR_ERR(file);
+   goto err_dmabuf;
}

file->f_mode |= FMODE_LSEEK;
@@ -394,6 +395,12 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
mutex_unlock(_list.lock);

return dmabuf;
+
+err_dmabuf:
+   kfree(dmabuf);
+err_module:
+   module_put(exp_info->owner);
+   return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(dma_buf_export);

-- 
2.8.1

[pull] radeon and amdgpu drm-next-4.8

[StDenis, Tom]

rl.c   | 299 
> -
>  drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.h   |   1 +
>  .../gpu/drm/amd/powerplay/hwmgr/processpptables.c  |  13 +
>  .../gpu/drm/amd/powerplay/hwmgr/processpptables.h  |  17 +-
>  drivers/gpu/drm/amd/powerplay/inc/smumgr.h |  29 ++
>  drivers/gpu/drm/radeon/atombios_encoders.c |   1 +
>  30 files changed, 469 insertions(+), 360 deletions(-)
>  rename drivers/gpu/drm/amd/amdgpu/{iceland_smumgr.h => iceland_smum.h} (100%)
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/86635ead/attachment-0001.html>

[PATCH v2] drm/amdgpu: Disable RPM helpers while reprobing connectors on resume

[Lyude]

Just about all of amdgpu's connector probing functions try to acquire
runtime PM refs. If we try to do this in the context of
amdgpu_resume_kms by calling drm_helper_hpd_irq_event(), we end up
deadlocking the system.

Since we're guaranteed to be holding the spinlock for RPM in
amdgpu_resume_kms, and we already know the GPU is in working order, we
need to prevent the RPM helpers from trying to run during the initial
connector reprobe on resume.

There's a couple of solutions I've explored for fixing this, but this
one by far seems to be the simplest and most reliable (plus I'm pretty
sure that's what disable_depth is there for anyway).

Reproduction recipe:
  - Get any laptop dual GPUs using PRIME
  - Make sure runtime PM is enabled for amdgpu
  - Boot the machine
  - If the machine managed to boot without hanging, switch out of X to
another VT. This should definitely cause X to hang infinitely.

Changes since v1:
  - add appropriate #ifdef checks for CONFIG_PM. This is not very
useful, but it appears some kernel test suites test compiling amdgpu
with CONFIG_PM disabled, which results in this patch breaking the builds
if we don't include this #ifdef

Cc: stable at vger.kernel.org
Cc: Alex Deucher 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6e92008..b7f5650 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1841,7 +1841,23 @@ int amdgpu_resume_kms(struct drm_device *dev, bool 
resume, bool fbcon)
}

drm_kms_helper_poll_enable(dev);
+
+   /*
+* Most of the connector probing functions try to acquire runtime pm
+* refs to ensure that the GPU is powered on when connector polling is
+* performed. Since we're calling this from a runtime PM callback,
+* trying to acquire rpm refs will cause us to deadlock.
+*
+* Since we're guaranteed to be holding the rpm lock, it's safe to
+* temporarily disable the rpm helpers so this doesn't deadlock us.
+*/
+#ifdef CONFIG_PM
+   dev->dev->power.disable_depth++;
+#endif
drm_helper_hpd_irq_event(dev);
+#ifdef CONFIG_PM
+   dev->dev->power.disable_depth--;
+#endif

if (fbcon) {
amdgpu_fbdev_set_suspend(adev, 0);
-- 
2.7.4

DRM device memory writeback (Mali-DP)

[Brian Starkey]

Hi,

On Fri, Jul 15, 2016 at 10:42:01AM -0700, Eric Anholt wrote:
>Ville Syrjälä  writes:
>
>> On Fri, Jul 15, 2016 at 10:09:19AM +0100, Brian Starkey wrote:
>>> Hi Daniel,
>>>
>>> Thanks for taking a look.
>>>
>>> (+Cc Laurent)
>>>
>>> On Fri, Jul 15, 2016 at 09:33:34AM +0200, Daniel Vetter wrote:
>>> >On Thu, Jul 14, 2016 at 06:03:40PM +0100, Brian Starkey wrote:
>>> >> Hi,
>>> >>
>>> >> The Mali-DP display processors have a memory-writeback engine which
>>> >> can write the result of the composition (CRTC output) to a memory
>>> >> buffer in a variety of formats.
>>> >>
>>> >> We're looking for feedback/suggestions on how to expose this in the
>>> >> mali-dp DRM kernel driver - possibly via V4L2.
>>> >>
>>> >> We've got a few use cases where writeback is useful:
>>> >>- testing, to check the displayed image
>>> >
>>> >This might or might not need a separate interface. There are efforts to
>>> >make the intel kms validation tests in i-g-t generic (well under way
>>> >already), and part of that is creating a generic infrastructure to capture
>>> >display CRCs for functional tests (still in progress).
>>> >
>>> >But it might be better if userspace abstracts between full readback and
>>> >display CRC, assuming we can make full writeback cross-vendor enough for
>>> >that use-case.
>>> >
>>>
>>> I'd lean towards the userspace abstraction.
>>> Encumbering a simple CRC interface with all the complexity of
>>> full-writeback (size, scaling, pixel format, multi-planar etc.) sounds
>>> a bit unnecessary.
>>>
>>> Of course, if v4l2 isn't going to be the cross-vendor full-writeback
>>> implementation, then we need to be aiming to use whatever _is_ in
>>> the mali-dp driver.
>>>
>>> >>- screen recording
>>> >>- wireless display (e.g. Miracast)
>>> >>- dual-display clone mode
>>> >>- memory-to-memory composition
>>> >> Note that the HW is capable of writing one of the input planes instead
>>> >> of the CRTC output, but we've no good use-case for wanting to expose
>>> >> that.
>>> >>
>>> >> In our Android ADF driver[1] we exposed the memory write engine as
>>> >> part of the ADF device using ADF's "MEMORY" interface type. DRM/KMS
>>> >> doesn't have any similar support for memory output from CRTCs, but we
>>> >> want to expose the functionality in the mainline Mali-DP DRM driver.
>>> >>
>>> >> A previous discussion on the topic went towards exposing the
>>> >> memory-write engine via V4L2[2].
>>> >>
>>> >> I'm thinking to userspace this would look like two distinct devices:
>>> >>- A DRM KMS display controller.
>>> >>- A V4L2 video source.
>>> >> They'd both exist in the same kernel driver.
>>> >> A V4L2 client can queue up (CAPTURE) buffers in the normal way, and
>>> >> the DRM driver would see if there's a buffer to dequeue every time a
>>> >> new modeset is received via the DRM API - if so, it can configure the
>>> >> HW to dump into it (one-shot operation).
>>> >>
>>> >> An implication of this is that if the screen is actively displaying a
>>> >> static scene and the V4L2 client queues up a buffer, it won't get
>>> >> filled until the DRM scene changes. This seems best, otherwise the
>>> >> V4L2 driver has to change the HW configuration out-of-band from the
>>> >> DRM device which sounds horribly racy.
>>> >>
>>> >> One further complication is scaling. Our HW has a scaler which can
>>> >> tasked with either scaling an input plane or the buffer being written
>>> >> to memory, but not both at the same time. This means we need to
>>> >> arbitrate the scaler between the DRM device (scaling input planes) and
>>> >> the V4L2 device (scaling output buffers).
>>> >>
>>> >> I think the simplest approach here is to allow V4L2 to "claim" the
>>> >> scaler by setting the image size (VIDIOC_S_FMT) to something other
>>> >> than the CRTC's current resolution. After that, any attempt to use the
>>> >> scaler on an input plane via DRM should fail atomic_check().
>>> >
>>> >That's perfectly fine atomic_check behaviour. Only trouble is that the v4l
>>> >locking must integrate into the drm locking, but that should be doable.
>>> >Worst case you must shadow all v4l locks with a wait/wound
>>> >drm_modeset_lock to avoid deadlocks (since you could try to grab locks
>>> >from either end).
>>> >
>>>
>>> Yes, I haven't looked at the details of the locking but I'm hoping
>>> it's manageable.
>>>
>>> >> If the V4L2 client goes away or sets the image size to the CRTC's
>>> >> native resolution, then the DRM device is allowed to use the scaler.
>>> >> I don't know if/how the DRM device should communicate to userspace
>>> >> that the scaler is or isn't available for use.
>>> >>
>>> >> Any thoughts on this approach?
>>> >> Is it acceptable to both V4L2 and DRM folks?
>>> >
>>> >For streaming a V4L2 capture device seems like the right interface. But if
>>> >you want to use writeback in your compositor you must know which atomic
>>> >kms update results in which frame, since if you don't you can't use that
>>> 

DRM device memory writeback (Mali-DP)

[Rob Clark]

On Mon, Jul 18, 2016 at 11:01 AM, Daniel Vetter  wrote:
> On Mon, Jul 18, 2016 at 12:47:38PM +0200, Hans Verkuil wrote:
>> On 07/18/2016 12:29 PM, Brian Starkey wrote:
>> > OK, so let's talk about using connectors instead then :-)
>> >
>> > We can attach a generic fixed_mode property which can represent panel
>> > fitters or Mali-DP's writeback scaling, that sounds good.
>> >
>> > The DRM driver can create a new "virtual" encoder/connector pair, I
>> > guess with a new connector type specifically for memory-writeback?
>> > On this connector we allow the fb_id property to attach a framebuffer
>> > for writing into.
>> > We'd probably want an additional property to enable writeback, perhaps
>> > an enum: "disabled", "streaming", "oneshot".
>> >
>> > I think it makes sense to put the output buffer format, size etc.
>> > validation in the virtual encoder's atomic_check. It has access to
>> > both CRTC and connector state, and the encoder is supposed to
>> > represent the format/stream conversion element anyway.
>> >
>> > What I'm not so clear on is how to manage the API with userspace.
>>
>> I am not terribly enthusiastic (to say the least) if a new drm API is
>> created for video capture. That's what V4L2 is for and it comes with
>> kernel frameworks, documentation and utilities. Creating a new API will
>> not make userspace develoeprs happy.
>>
>> I know it is a pain to work with different subsystems, but reinventing
>> the wheel is a much bigger pain. For you and for the poor sods who have
>> to use yet another API to do the same thing.
>>
>> Of course this has to be hooked up to drm at the low level, and anything
>> that can be done to help out with that from the V4L2 side of things is
>> fine, but creating duplicate public APIs isn't the way IMHO.
>
> I agree for the streaming video use-case. But for compositors I do agree
> with Eric that a simple frame capture interface integrated with the drm
> atomic ioctl is what we want. At least my understanding of v4l is that
> it's not that well suited to grabbing specific (single) frames.

same here, we defn want to use v4l for the streaming case (so we can
take advantage of existing userspace support for
capture/encode/stream, etc)..  but for compositors, I think v4l would
be awkward.  Ideal case is single set of driver APIs, so driver
doesn't have to care so much about the use case, and then some drm_v4l
helpers to expose a v4l device for the streaming case.

There are some older patches floating around that implemented v4l
inside drm/msm.. which looked simple enough, although I don't think we
should need to do that in each drm driver..

BR,
-R

[PATCH 1/2] drm/imx: Remove imx_drm_crtc_vblank_get/_put()

[Philipp Zabel]

Hi Liu,

Am Montag, den 18.07.2016, 15:44 +0800 schrieb Liu Ying:
> There is no one calling imx_drm_crtc_vblank_get/_put() and
> they are just two simple wrappers of drm_crtc_vblank_get/_put()
> without doing any thing fancy - the drivers may call
> drm_crtc_vblank_get/_put() directly.  So, let's remove the two
> wrappers.
> 
> Signed-off-by: Liu Ying 

Applied both, thank you.

regards
Philipp

[PATCH v3 1/2] dt-bindings: tc358767: add DT documentation

[Philipp Zabel]

Am Sonntag, den 17.07.2016, 13:55 +0530 schrieb Archit Taneja:
> 
> On 7/17/2016 4:04 AM, Rob Herring wrote:
> > On Wed, Jul 13, 2016 at 09:07:10AM +0200, Philipp Zabel wrote:
> >> Add DT binding documentation for the Toshiba TC358767 eDP bridge.
> >>
> >> Signed-off-by: Philipp Zabel 
> >> ---
> >>   .../bindings/display/bridge/toshiba,tc358767.txt   | 51 
> >> ++
> >>   1 file changed, 51 insertions(+)
> >>   create mode 100644 
> >> Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt 
> >> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> >> new file mode 100644
> >> index 000..05ada28
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> >> @@ -0,0 +1,51 @@
> >> +Toshiba TC358767 eDP bridge bindings
> >> +
> >> +Required properties:
> >> + - compatible: "toshiba,tc358767"
> >> + - reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap 
> >> pins
> >> + - clock-names: should be "ref"
> >> + - clocks: OF device-tree clock specification for refclk input. The 
> >> reference
> >> +   clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz.
> >> +
> >> +Optional properties:
> >> + - shutdown-gpios: OF device-tree gpio specification for SD pin
> >> +   (active high shutdown input)
> >> + - reset-gpios: OF device-tree gpio specification for RSTX pin
> >> +(active low system reset)
> >> + - ports: the ports node can contain video interface port nodes to connect
> >> +   to a DPI/DSI source and to an eDP/DP sink according to [1][2]:
> >> +- port at 0: DSI input port
> >> +- port at 1: DPI input port
> >> +- port at 2: eDP/DP output port
> >> +
> >> +[1]: Documentation/devicetree/bindings/graph.txt
> >> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >> +
> >> +Example:
> >> +  edp-bridge at 68 {
> >> +  compatible = "toshiba,tc358767";
> >> +  reg = <0x68>;
> >> +  shutdown-gpios = < 23 GPIO_ACTIVE_HIGH>;
> >> +  reset-gpios = < 24 GPIO_ACTIVE_LOW>;
> >> +  clock-names = "ref";
> >> +  clocks = <_refclk>;
> >> +
> >> +  ports {
> >
> > You are missing #size-cells and #address-cells here, otherwise:
> >
> > Acked-by: Rob Herring 
> 
> Thanks, I'll fix it up before sending a pull request.

Thank you for the fixup.

regards
Philipp

[PATCH v4 3/8] drm/mediatek: add shadow register support

[Philipp Zabel]

Hi CK, YT,

Am Montag, den 18.07.2016, 14:32 +0800 schrieb CK Hu:
> Hi, YT:
> 
> One comment inline.
> 
> 
> On Fri, 2016-07-15 at 18:07 +0800, YT Shen wrote:
> > We need to acquire mutex before using the resources,
> > and need to release it after finished.
> > So we don't need to write registers in the blanking period.
> > 
> > Signed-off-by: YT Shen 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   75 
> > +++
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |   22 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |2 +
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |1 +
> >  4 files changed, 71 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..80d9641 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -315,6 +315,42 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc 
> > *mtk_crtc)
> > pm_runtime_put(drm->dev);
> >  }
> >  
> > +static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> > +{
> > +   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +   struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> > +   struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
> > +   unsigned int i;
> > +
> > +   /*
> > +* TODO: instead of updating the registers here, we should prepare
> > +* working registers in atomic_commit and let the hardware command
> > +* queue update module registers on vblank.
> > +*/
> > +   if (state->pending_config) {
> > +   mtk_ddp_comp_config(ovl, state->pending_width,
> > +   state->pending_height,
> > +   state->pending_vrefresh);
> > +
> > +   state->pending_config = false;
> > +   }
> > +
> > +   if (mtk_crtc->pending_planes) {
> > +   for (i = 0; i < OVL_LAYER_NR; i++) {
> > +   struct drm_plane *plane = _crtc->planes[i].base;
> > +   struct mtk_plane_state *plane_state;
> > +
> > +   plane_state = to_mtk_plane_state(plane->state);
> > +
> > +   if (plane_state->pending.config) {
> > +   mtk_ddp_comp_layer_config(ovl, i, plane_state);
> > +   plane_state->pending.config = false;
> > +   }
> > +   }
> > +   mtk_crtc->pending_planes = false;
> > +   }
> > +}
> > +
> >  static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
> >  {
> > struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > @@ -391,6 +427,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> >   struct drm_crtc_state *old_crtc_state)
> >  {
> > struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +   struct mtk_drm_private *priv = crtc->dev->dev_private;
> > unsigned int pending_planes = 0;
> > int i;
> >  
> > @@ -409,6 +446,12 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> > }
> > if (pending_planes)
> > mtk_crtc->pending_planes = true;
> > +
> > +   if (priv->data->shadow_register) {
> > +   mtk_disp_mutex_acquire(mtk_crtc->mutex);
> > +   mtk_crtc_ddp_config(crtc);
> > +   mtk_disp_mutex_release(mtk_crtc->mutex);
> > +   }
> >  }
> >  
> >  static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > @@ -453,36 +496,10 @@ err_cleanup_crtc:
> >  void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl)
> >  {
> > struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > -   struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> > -   unsigned int i;
> > +   struct mtk_drm_private *priv = crtc->dev->dev_private;
> >  
> > -   /*
> > -* TODO: instead of updating the registers here, we should prepare
> > -* working registers in atomic_commit and let the hardware command
> > -* queue update module registers on vblank.
> > -*/
> > -   if (state->pending_config) {
> > -   mtk_ddp_comp_config(ovl, state->pending_width,
> > -   state->pending_height,
> > -   state->pending_vrefresh);
> > -
> > -   state->pending_config = false;
> > -   }
> > -
> > -   if (mtk_crtc->pending_planes) {
> > -   for (i = 0; i < OVL_LAYER_NR; i++) {
> > -   struct drm_plane *plane = _crtc->planes[i].base;
> > -   struct mtk_plane_state *plane_state;
> > -
> > -   plane_state = to_mtk_plane_state(plane->state);
> > -
> > -   if (plane_state->pending.config) {
> > -   mtk_ddp_comp_layer_config(ovl, i, plane_state);
> > -   plane_state->pending.config = false;
> > -   }
> > -   }
> > -   mtk_crtc->pending_planes = false;
> > -   }
> > +   if (!priv->data->shadow_register)
> 

[PATCH v3 2/2] drm/mediatek: set mt8173 dithering function

[CK Hu]

Hi, Bibby:

Some comments inline.

On Thu, 2016-07-07 at 15:37 +0800, Bibby Hsieh wrote:
> Some panels only accept bpc (bit per color) 6-bit.
> But, the default bpc in mt8173 display data path is 8-bit.
> If we didn't enable dithering function to convert bpc,
> display cannot show the smooth grayscale image.
> 
> In mt8173, the dithering function in OD (OverDrive) and
> GAMMA module, we have to config them with
> connector->display_mode.bpc when CRTC initial.
> 
> 1. Clear the default value at *_DITHER_5 and *_DITHER_7 register.
> 2. Calculate the LSB_ERR_SHIFT bits and ADD_LSHIFT bits two values.
> i.e. Input bpc of OD is 10 bits, we assume the bpc of panel is 6-bit,
> so, we need to set 4-bit to LSB_ERR_SHIFT and ADD_LSHIFT bits respectively.
> 3. Then, set the OD or GAMMA to dithering mode depends on path-1 or path-2.
> 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |3 +-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|3 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   21 ++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   77 
> +++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |6 +--
>  5 files changed, 92 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 8f62671f..019b7ca 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -103,7 +103,8 @@ static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
>  }
>  
>  static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
> -unsigned int h, unsigned int vrefresh)
> +unsigned int h, unsigned int vrefresh,
> +unsigned int bpc)
>  {
>   if (w != 0 && h != 0)
>   writel_relaxed(h << 16 | w, comp->regs + DISP_REG_OVL_ROI_SIZE);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 5fb80cb..0df05f9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -106,7 +106,8 @@ static void mtk_rdma_stop(struct mtk_ddp_comp *comp)
>  }
>  
>  static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
> - unsigned int height, unsigned int vrefresh)
> + unsigned int height, unsigned int vrefresh,
> + unsigned int bpc)
>  {
>   unsigned int threshold;
>   unsigned int reg;
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index ee219bb..18c9d0d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -222,7 +222,9 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc 
> *mtk_crtc)
>  static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
>  {
>   struct drm_crtc *crtc = _crtc->base;
> - unsigned int width, height, vrefresh;
> + struct drm_connector *connector;
> + struct drm_encoder *encoder;
> + unsigned int width, height, vrefresh, bpc = 0;
>   int ret;
>   int i;
>  
> @@ -234,6 +236,19 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
> *mtk_crtc)
>   height = crtc->state->adjusted_mode.vdisplay;
>   vrefresh = crtc->state->adjusted_mode.vrefresh;
>  
> + drm_for_each_encoder(encoder, crtc->dev) {
> + if (encoder->crtc != crtc)
> + continue;
> +
> + drm_for_each_connector(connector, crtc->dev) {
> + if (connector->encoder != encoder)
> + continue;
> + if (connector->display_info.bpc >= 3 &&

I think you should left this HW constrain in mtk_od_config() and
mtk_gamma_config(). Here just calculate the expected bpc.

> + (bpc == 0 || bpc > connector->display_info.bpc))

I think bpc should be initialized as HW default bpc and you can remove
this condiction 'bpc == 0' because we should set bpc to HW default bpc
while all connnector bpc is greater than HW default bpc.

> + bpc = connector->display_info.bpc;
> + }
> + }
> +
>   ret = pm_runtime_get_sync(crtc->dev->dev);
>   if (ret < 0) {
>   DRM_ERROR("Failed to enable power domain: %d\n", ret);
> @@ -266,7 +281,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc 
> *mtk_crtc)
>   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
>   struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
>  
> - mtk_ddp_comp_config(comp, width, height, vrefresh);
> + mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
>   mtk_ddp_comp_start(comp);
>   }
>  
> @@ -469,7 +484,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct 
> mtk_ddp_comp *ovl)
>   if (state->pending_config) {
>   

[PATCH] drm/vgem: Remember to offset relative timeouts to mod_timer() by jiffies

[Chris Wilson]

mod_timer() takes an absolute jiffie value, not a relative timeout and
quietly fixup the missed ret=0 otherwise gcc just always returns that
the fence timed out.

Testcase: igt/vgem_basic/fence
Fixes: 407779848445 ("drm/vgem: Attach sw fences to exported vGEM dma-buf")
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index e77b52208699..892417ba2622 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -107,7 +107,7 @@ static struct fence *vgem_fence_create(struct vgem_file 
*vfile,
setup_timer(>timer, vgem_fence_timeout, (unsigned long)fence);

/* We force the fence to expire within 10s to prevent driver hangs */
-   mod_timer(>timer, VGEM_FENCE_TIMEOUT);
+   mod_timer(>timer, jiffies + VGEM_FENCE_TIMEOUT);

return >base;
 }
@@ -240,7 +240,7 @@ int vgem_fence_signal_ioctl(struct drm_device *dev,
struct vgem_file *vfile = file->driver_priv;
struct drm_vgem_fence_signal *arg = data;
struct fence *fence;
-   int ret;
+   int ret = 0;

if (arg->flags)
return -EINVAL;
-- 
2.8.1

[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94900

--- Comment #20 from Daniel T.  ---
I can confirm that setting R600_DEBUG=sbsafemath allows atleast octodad to be
launched and played without problems.

I currently do not have the other games installed, but I will start the
downloads and test ASAP.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/fc86e5be/attachment.html>

[PATCH] drm/hdlcd: Delete an unnecessary check before drm_fbdev_cma_hotplug_event()

[Liviu Dudau]

On Sat, Jul 16, 2016 at 09:20:02AM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 16 Jul 2016 09:10:40 +0200
> 
> The drm_fbdev_cma_hotplug_event() function tests whether its argument
> is NULL and then returns immediately.
> Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Liviu Dudau 

> ---
>  drivers/gpu/drm/arm/hdlcd_drv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 28b8cd1..9b1aefe 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -102,8 +102,7 @@ static void hdlcd_fb_output_poll_changed(struct 
> drm_device *drm)
>  {
>   struct hdlcd_drm_private *hdlcd = drm->dev_private;
>  
> - if (hdlcd->fbdev)
> - drm_fbdev_cma_hotplug_event(hdlcd->fbdev);
> + drm_fbdev_cma_hotplug_event(hdlcd->fbdev);
>  }
>  
>  static const struct drm_mode_config_funcs hdlcd_mode_config_funcs = {
> -- 
> 2.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯

[PATCH 0/8] drm/amdgpu: Fine-tuning for three function implementations

[Christian König]

Am 16.07.2016 um 16:33 schrieb SF Markus Elfring:
> From: Markus Elfring 
> Date: Sat, 16 Jul 2016 16:23:21 +0200
>
> Further update suggestions were taken into account after patches
> were applied from static source code analysis.

Small coding style nit pick on patch #7:
> - }
> + } else
> + temp_storage = NULL;
When an "if" has "{" and "}" the else should also use them even when it 
is only one line.

With that fixed the whole series is Reviewed-by: Christian König 
, but as Walter Harms pointed out as well 
there are a couple of other things we could make more as well.

Regards,
Christian.

>
> Markus Elfring (8):
>Delete an unnecessary check before drm_gem_object_unreference_unlocked()
>Delete unnecessary checks before the function call "kfree"
>One function call less in amdgpu_cgs_acpi_eval_object() after error 
> detection
>Delete a variable in amdgpu_cgs_acpi_eval_object()
>Delete an unnecessary variable initialisation in 
> amdgpu_cgs_acpi_eval_object()
>Change assignment for a variable in amdgpu_cgs_acpi_eval_object()
>Change assignment for a buffer variable in phm_dispatch_table()
>Delete an unnecessary variable initialisation in phm_dispatch_table()
>
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 28 
> ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  4 +---
>   .../gpu/drm/amd/powerplay/hwmgr/functiontables.c   | 12 --
>   3 files changed, 19 insertions(+), 25 deletions(-)
>

[PATCH -next] drm/hisilicon: Fix return value check in ade_dts_parse()

[Xinliang Liu]

On 13 July 2016 at 20:43,   wrote:
> From: Wei Yongjun 
>
> In case of error, the function devm_clk_get() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check
> should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun 

Hi, thanks. This patch had already applied to drm-hisilicon-next.

> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index 805f432..c3707d4 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -967,21 +967,21 @@ static int ade_dts_parse(struct platform_device *pdev, 
> struct ade_hw_ctx *ctx)
> }
>
> ctx->ade_core_clk = devm_clk_get(dev, "clk_ade_core");
> -   if (!ctx->ade_core_clk) {
> +   if (IS_ERR(ctx->ade_core_clk)) {
> DRM_ERROR("failed to parse clk ADE_CORE\n");
> -   return -ENODEV;
> +   return PTR_ERR(ctx->ade_core_clk);
> }
>
> ctx->media_noc_clk = devm_clk_get(dev, "clk_codec_jpeg");
> -   if (!ctx->media_noc_clk) {
> +   if (IS_ERR(ctx->media_noc_clk)) {
> DRM_ERROR("failed to parse clk CODEC_JPEG\n");
> -   return -ENODEV;
> +   return PTR_ERR(ctx->media_noc_clk);
> }
>
> ctx->ade_pix_clk = devm_clk_get(dev, "clk_ade_pix");
> -   if (!ctx->ade_pix_clk) {
> +   if (IS_ERR(ctx->ade_pix_clk)) {
> DRM_ERROR("failed to parse clk ADE_PIX\n");
> -   return -ENODEV;
> +   return PTR_ERR(ctx->ade_pix_clk);
> }
>
> return 0;
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm/hisilicon: Remove redundant dev_err call in ade_dts_parse()

[Xinliang Liu]

Hi, thanks. This patch had already applied to drm-hisilicon-next.


On 13 July 2016 at 20:44,   wrote:
> From: Wei Yongjun 
>
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index 805f432..3aea3bb 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -944,10 +944,8 @@ static int ade_dts_parse(struct platform_device *pdev, 
> struct ade_hw_ctx *ctx)
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> ctx->base = devm_ioremap_resource(dev, res);
> -   if (IS_ERR(ctx->base)) {
> -   DRM_ERROR("failed to remap ade io base\n");
> +   if (IS_ERR(ctx->base))
> return  PTR_ERR(ctx->base);
> -   }
>
> ctx->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(ctx->reset))
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next] drm/hisilicon: Fix non static symbol warning

[Xinliang Liu]

On 13 July 2016 at 20:43,   wrote:
> From: Wei Yongjun 
>
> Fixes the following sparse warning:
>
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c:107:5: warning:
>  symbol 'ade_get_channel_formats' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun 

Thanks, applied to drm-hisilicon-next.

> ---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index 805f432..2a913cc 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -104,7 +104,7 @@ static const u32 channel_formats1[] = {
> DRM_FORMAT_ABGR
>  };
>
> -u32 ade_get_channel_formats(u8 ch, const u32 **formats)
> +static u32 ade_get_channel_formats(u8 ch, const u32 **formats)
>  {
> switch (ch) {
> case ADE_CH1:
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/11] drm/doc: Add kerneldoc for @index

[Daniel Vetter]

On Fri, Jul 15, 2016 at 09:06:04PM +0100, Chris Wilson wrote:
> On Fri, Jul 15, 2016 at 09:47:59PM +0200, Daniel Vetter wrote:
> > Was forgotten when adding them all over. 0-day should complain about
> > new missing kernel-doc, not sure why that wasn't caught/fixed.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  include/drm/drm_crtc.h | 26 +-
> >  1 file changed, 21 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index ebf078685f86..656f189f1198 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -783,7 +783,10 @@ struct drm_crtc {
> > struct drm_plane *primary;
> > struct drm_plane *cursor;
> >  
> > -   /* position inside the mode_config.list, can be used as a [] idx */
> > +   /**
> > +* @index: Position inside the mode_config.list, can be used as an array
> 
> For all:
> 
> @index: Fixed position inside the mode_config.list, can be used as an
> array index. The @index is assigned when the crtc is inserted into the
> list, and it will remain at that position inside the list until the
> module is unloaded.
> 
> Just want to emphasis the unchanging nature of the @index. Second
> sentence may be overkill.

Just adding "It is invariant over the lifetime of $object." for brevity?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 00/21] drm: make fbdev support really optional

[Daniel Vetter]

On Fri, Jul 15, 2016 at 10:37:45AM -0400, Sean Paul wrote:
> On Fri, Jul 15, 2016 at 10:17 AM, Emil Velikov  
> wrote:
> > On 15 July 2016 at 14:37, Tobias Jakobi  
> > wrote:
> >> Hello Emil,
> >>
> >> Emil Velikov wrote:
> >>> On 15 July 2016 at 13:47, Tobias Jakobi  >>> math.uni-bielefeld.de> wrote:
>  Hello,
> 
>  as request by Daniel here 
>  (http://www.spinics.net/lists/dri-devel/msg112592.html) I went ahead and 
>  also cleaned up the other Kconfig files. I have mostly compile tested 
>  the changes on an ARMv7 system (COMPILE_TEST).
> 
> >>> Yay :-) IIRC some drivers don't fully use the fb_helpers (for example
> >>> vmwgfx still references the cfb_* API), so they should be updated as
> >>> well.
> >> I can only do this on ARM atm, so I suggest to just drop insufficient
> >> patches.
> >>
> > Without checking (build and/or grep) it'll be a bit hard to figure out
> > which patches are insufficient. At the end of the day it's up-to you
> > and DRM maintainer(s).
> >
> 
> I've compile tested atmel/nouveau/rcar/rockchip, I'll merge those in drm-misc.
> 
> Since I can't test the others easily, I'll leave them for now.

vmwgfx seems to be the only special case (it doesn't use any of the kms
helpers at all, so that's normal). I merged all the others.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/ttm: Delete an unnecessary check before the function call "ttm_tt_destroy"

[Daniel Vetter]

On Fri, Jul 15, 2016 at 08:28:18PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Fri, 15 Jul 2016 20:20:48 +0200
> 
> The ttm_tt_destroy() function tests whether its argument is NULL
> and then returns immediately. Thus the test around the call is not needed.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 39386f5..23809d0 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -146,9 +146,7 @@ static void ttm_bo_release_list(struct kref *list_kref)
>   BUG_ON(bo->mem.mm_node != NULL);
>   BUG_ON(!list_empty(>lru));
>   BUG_ON(!list_empty(>ddestroy));
> -
> - if (bo->ttm)
> - ttm_tt_destroy(bo->ttm);
> + tm_tt_destroy(bo->ttm);

This doesn't compile. Tsk, pls be more careful, and definitely
compile-test _all_ your changes before hitting send. I've dropped this one
from my queue, the others still look ok.
-Daniel

>   atomic_dec(>glob->bo_count);
>   if (bo->resv == >ttm_resv)
>   reservation_object_fini(>ttm_resv);
> -- 
> 2.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[GIT PULL] drm bridge drivers for 4.8

[Archit Taneja]

Hi Laurent,

On 07/17/2016 02:23 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Sunday 17 Jul 2016 14:09:21 Archit Taneja wrote:
>> Hi Dave,
>>
>> This pull request contains the following bridge driver updates:
>>
>> - Converts the ADV7511 i2c slave encoder driver to a bridge driver.
>>Adds support for the ADV7533 bridge chip.
>> - Add bridge driver for TC358767 (DSI/DPI to eDP) encoder chips.
>
> Is there a reason why you don't include the rcar-du change in the pull request
> ? I believe I've provided my Tested-by.

I wasn't sure if I was supposed to pick it up. I thought it might
have had to go via the rcar pull request. I can update the pull request
to include that commit if you think that's better.

Archit

>
>> The following changes since commit 2ae995887830b335f9bdab3040018071da54bcdb:
>>
>>drm: Fix a typo in drm_ioctl.c (2016-06-30 12:04:44 +0300)
>>
>> are available in the git repository at:
>>
>>https://github.com/boddob/linux.git drm_bridge_for_4.8
>>
>> for you to fetch changes up to 7caff0fc4296eba5e2e473e6719726c65f1b7c31:
>>
>>drm/bridge: tc358767: Add DPI to eDP bridge driver (2016-07-17 14:00:57
>> +0530)
>>
>> 
>> Andrey Gusakov (1):
>>drm/bridge: tc358767: Add DPI to eDP bridge driver
>>
>> Archit Taneja (8):
>>drm/i2c: adv7511: Convert to drm_bridge
>>drm/i2c: adv7511: Move to bridge folder
>>drm/bridge: adv7511: Fix mutex deadlock when interrupts are disabled
>>drm/bridge: adv7533: Initial support for ADV7533
>>drm/bridge: adv7533: Create a MIPI DSI device
>>drm/bridge: adv7533: Use internal timing generator
>>drm/bridge: adv7533: Change number of DSI lanes dynamically
>>dt-bindings: drm/bridge: Update bindings for ADV7533
>>
>> Philipp Zabel (1):
>>dt-bindings: tc358767: add DT documentation
>>
>>   .../bindings/display/bridge/adi,adv7511.txt|   26 +-
>>   .../bindings/display/bridge/toshiba,tc358767.txt   |   53 +
>>   drivers/gpu/drm/bridge/Kconfig |   11 +
>>   drivers/gpu/drm/bridge/Makefile|2 +
>>   drivers/gpu/drm/bridge/adv7511/Kconfig |   15 +
>>   drivers/gpu/drm/bridge/adv7511/Makefile|3 +
>>   drivers/gpu/drm/{i2c => bridge/adv7511}/adv7511.h  |  103 ++
>>   .../adv7511.c => bridge/adv7511/adv7511_drv.c} |  324 +++--
>>   drivers/gpu/drm/bridge/adv7511/adv7533.c   |  265 
>>   drivers/gpu/drm/bridge/tc358767.c  | 1413 +
>>   drivers/gpu/drm/i2c/Kconfig|6 -
>>   drivers/gpu/drm/i2c/Makefile   |2 -
>>   12 files changed, 2098 insertions(+), 125 deletions(-)
>>   create mode 100644
>> Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
>> create mode 100644 drivers/gpu/drm/bridge/adv7511/Kconfig
>>   create mode 100644 drivers/gpu/drm/bridge/adv7511/Makefile
>>   rename drivers/gpu/drm/{i2c => bridge/adv7511}/adv7511.h (82%)
>>   rename drivers/gpu/drm/{i2c/adv7511.c => bridge/adv7511/adv7511_drv.c}
>> (80%) create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7533.c
>>   create mode 100644 drivers/gpu/drm/bridge/tc358767.c
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94900

--- Comment #19 from iive at yahoo.com ---
Created attachment 125130
  --> https://bugs.freedesktop.org/attachment.cgi?id=125130=edit
Octrodad crashing pixel shader - TGSI, disassembly, sbdump of IR code and crash
backtrace

I've discovered few more things.

1. When retracing with mesa3d debug enabled, the shader backend internal
checker is run and it does detect errors (and crashes at failed assert). It
seems to error out at shader 70 (a draw command before the one that hangs).
I've attached a log that includes the output of `sbdump` too.

2. `R600_DEBUG=sbsafemath` could also be used to workaround the above crash and
the original lockup. (Please test if this works with the other titles too.)

Looking at the source, the 'safe math' option skips few optimization. The one
that seems to cause problem is the call to `fold_assoc()` in
`expr_handler::fold_alu_op2()` somewhere around `sb_expr.cpp:740`.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/7164dda4/attachment.html>

[PATCH] drm/fsl-dcu: Add gamma set for crtc

[Daniel Vetter]

On Fri, Jul 15, 2016 at 04:50:53PM +0800, Meng Yi wrote:
> Gamma correction is optional and can be used to adjust the color
> output values to match the gamut of a particular TFT LCD panel
> 
> Signed-off-by: Meng Yi 

Please use the new atomic color management properties instead. There's a
function to remap the old gamma table to these new properties for old
userspace.
-Daniel

> ---
>  drivers/gpu/drm/fsl-dcu/Kconfig|  6 +++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 63 
> ++
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  |  7 
>  3 files changed, 76 insertions(+)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig
> index b9c714d..ddfe3c4 100644
> --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> @@ -16,3 +16,9 @@ config DRM_FSL_DCU
>   help
> Choose this option if you have an Freescale DCU chipset.
> If M is selected the module will be called fsl-dcu-drm.
> +
> +config DRM_FSL_DCU_GAMMA
> + bool "Gamma Correction Support for NXP/Freescale DCU"
> + depends on DRM_FSL_DCU
> + help
> +   Enable support for gamma correction.
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c 
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> index 3371635..d8426b1 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
> @@ -46,6 +46,11 @@ static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
>  
>   drm_crtc_vblank_off(crtc);
>  
> +#ifdef CONFIG_DRM_FSL_DCU_GAMMA
> + regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
> +DCU_MODE_EN_GAMMA_MASK,
> +DCU_MODE_GAMMA_DISABLE);
> +#endif
>   regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
>  DCU_MODE_DCU_MODE_MASK,
>  DCU_MODE_DCU_MODE(DCU_MODE_OFF));
> @@ -58,6 +63,11 @@ static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
>   struct drm_device *dev = crtc->dev;
>   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
>  
> +#ifdef CONFIG_DRM_FSL_DCU_GAMMA
> + regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
> +DCU_MODE_EN_GAMMA_MASK,
> +DCU_MODE_GAMMA_ENABLE);
> +#endif
>   regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
>  DCU_MODE_DCU_MODE_MASK,
>  DCU_MODE_DCU_MODE(DCU_MODE_NORMAL));
> @@ -128,6 +138,58 @@ static const struct drm_crtc_helper_funcs 
> fsl_dcu_drm_crtc_helper_funcs = {
>   .mode_set_nofb = fsl_dcu_drm_crtc_mode_set_nofb,
>  };
>  
> +/*
> + * Gamma_R, Gamma_G and Gamma_B registers are little-endian registers while
> + * the rest of the address-space in 2D-ACE is big-endian. 2D-ACE Gamma_R,
> + * Gamma_G and Gamma_B registers are 32 bit registers, where the first 24
> + * bits are reserved and last 8 bits denote the gamma value. Because of a
> + * connection issue in the device, the first 8-bit [31:24] is connected and
> + * the rest of the 24-bits[23:0] are reserved.
> + * Workaround: Perform the byte_swapping for Gamma_[R/G/B]_registers.
> + * For example: While writing _00ABh to any of the gamma registers, byte
> + * swap the data so it results in AB00_h. Write this value to the gamma
> + * register.
> + */
> +static u32 swap_bytes(u16 var)
> +{
> + union res {
> + char byte[4];
> + u32 val;
> + };
> + union res in, out;
> + unsigned int i = 0;
> +
> + in.val = var;
> + for (i = 0; i < 4; i++)
> + out.byte[i] = in.byte[3-i];
> +
> + return out.val;
> +}
> +
> +static int fsl_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
> + uint32_t size)
> +{
> + struct rgb {
> + u32 r[size], g[size], b[size];
> + };
> +
> + struct drm_device *dev = crtc->dev;
> + struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> + unsigned int i;
> + struct rgb glut;
> +
> + for (i = 0; i < size; i++) {
> + glut.r[i] = swap_bytes(r[i]);
> + glut.g[i] = swap_bytes(g[i]);
> + glut.b[i] = swap_bytes(b[i]);
> + regmap_write(fsl_dev->regmap, FSL_GAMMA_R + 4 * i, glut.r[i]);
> + regmap_write(fsl_dev->regmap, FSL_GAMMA_G + 4 * i, glut.g[i]);
> + regmap_write(fsl_dev->regmap, FSL_GAMMA_B + 4 * i, glut.b[i]);
> + }
> +
> + return 0;
> +}
> +
>  static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs = {
>   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> @@ -135,6 +197,7 @@ static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs 
> = {
>   .page_flip = drm_atomic_helper_page_flip,
>   .reset = drm_atomic_helper_crtc_reset,
>   .set_config = drm_atomic_helper_set_config,
> + .gamma_set = fsl_crtc_gamma_set,
>  };
>  

[Bug 113891] [radeon] Display jitter

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=113891

Jean Delvare  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/ast: Delete an unnecessary check before drm_gem_object_unreference_unlocked()

[Daniel Vetter]

On Sat, Jul 16, 2016 at 10:04:34AM +0200, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 16 Jul 2016 09:54:22 +0200
> 
> The drm_gem_object_unreference_unlocked() function tests whether
> its argument is NULL and then returns immediately.
> Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Ok, I merged all the non-amd ones from your latest round to drm-misc. Two
small nitpicks:

- for cocci patches I prefer if you include the (simplified, if it's a
  large one) semantic patch in the commit message. Cocci is really badly
  documented, it's good to see new examples of how.

- threading seems funny in your series. Please generate mail threads using
  git format-patch --cover-letter $sha1_range and send them out using git
  send-email. That'll get all the details right. Also pls don't reply with
  new patches to an old series, that hides the patches and confuses the
  discussion. Just start a new thread (even when the patches are on the
  same or similar topic).

Thanks, Daniel

> ---
>  drivers/gpu/drm/ast/ast_main.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index 7bc3aa6..904beaa 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -295,9 +295,8 @@ static int ast_get_dram_info(struct drm_device *dev)
>  static void ast_user_framebuffer_destroy(struct drm_framebuffer *fb)
>  {
>   struct ast_framebuffer *ast_fb = to_ast_framebuffer(fb);
> - if (ast_fb->obj)
> - drm_gem_object_unreference_unlocked(ast_fb->obj);
>  
> + drm_gem_object_unreference_unlocked(ast_fb->obj);
>   drm_framebuffer_cleanup(fb);
>   kfree(fb);
>  }
> -- 
> 2.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/nouveau/fbcon: fix deadlock with FBIOPUT_CON2FBMAP

[Daniel Vetter]

On Fri, Jul 15, 2016 at 01:10:51PM +0200, Peter Wu wrote:
> On Wed, Jul 13, 2016 at 04:57:19PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 13, 2016 at 02:40:50PM +0200, Peter Wu wrote:
> > > On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote:
> > > > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote:
> > > > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is 
> > > > > called
> > > > > while nouveau was runtime suspended, a deadlock would occur due to
> > > > > nouveau_fbcon_set_suspend also trying to obtain console_lock().
> > > > > 
> > > > > Fix this by delaying the drm_fb_helper_set_suspend call. Based on the
> > > > > i915 code (which was done for performance reasons though).
> > > > > 
> > > > > Cc: Chris Wilson 
> > > > > Cc: Daniel Vetter 
> > > > > Signed-off-by: Peter Wu 
> > > > > ---
> > > > > Tested on top of v4.7-rc5, the deadlock is gone.
> > > > 
> > > > If we bother with this, it should imo be moved into the drm_fb_helper.c
> > > > function drm_fb_helper_set_suspend(). But this also smells like some 
> > > > kind
> > > > of bad duct-tape. I think Lukas is working on some other rpm vs. fbdev
> > > > deadlocks, maybe we could fix them all with one proper fix? I've made 
> > > > some
> > > > comments on Lukas' last patch series.
> > > 
> > > This patch is only needed for drivers that use console_lock (for
> > > drm_fb_helper_set_suspend) in their runtime resume functions.
> > > Lukas posted fixes for runtime PM reference leaks, those are different
> > > from this deadlock (see
> > > https://lists.freedesktop.org/archives/dri-devel/2016-July/113005.html
> > > for a backtrace for this issue).
> > > 
> > > The deadlock could also be avoided if the device backing the fbcon is
> > > somehow runtime-resumed outside the lock, but that feels like a larger
> > > hack that does not seem easy.
> > > 
> > > The i915 patch was done to reduce resume time (due to console_lock
> > > contention), that feature seems useful to all other drivers too even if
> > > the deadlock is fixed in a different way.
> > 
> > I might have imagined something, but I thought Lukas is already working on
> > some rpm vs. vga_switcheroo inversions. But looking again this was on the
> > audio side.
> > 
> > I think the proper solution for fbcon would be for the fbdev emulation to
> > also hold a runtime pm references when the console is in use.
> 
> nouveau does this by adding a fb_open and fb_release function that calls
> pm_runtime_get and pm_runtime_put respectively (and is the only driver
> doing this). So that is why it causes the console_lock issue for
> nouveau, but not for others.
> 
> > This should already happen correctly for vblank, the more tricky part
> > is fbdev mmap and fbcon:
> > 
> > - I have no idea, but there should be a way to intercept fbdev userspace
> >   mmaps and make sure that as long as an app has the fbdev mmapped we
> >   don't runtime suspend. No one really should be doing that (at least for
> >   normal setups), hence this shouldn't result in unsafe.
> 
> mmap normally needs a fd right? When the chardev /dev/fbX is opened, the
> fb_open function will be called. So nouveau should not have this issue
> with mmap/read/write to a fb while the device is suspended.
> 
> (This RPM thing was added in f231976c2e89 ("drm/nouveau/fbcon: take
> runpm reference when userspace has an open fd"), maybe it is not a bad
> idea for other drivers with RPM support either.)

Yes, looks like nouveau implements this correctly already. I guess we
could ponder whether we should lift this into the shared fbdev emulation,
using some fbdev_rpm_get/put functions in dev->mode_config.helper_private.
We can't just do the rpm stuff directly because:
- gross midlayer violation
- with the "pile of devices" approach arm chips employ it's unclear what
  exactly can't be runtime suspended when fbdev is still in use.

But as long as no one else cares I'd go meh.

> > - For fbcon, we could suspend it in the dpms off callbacks (maybe with a
> >   timer), and resume it only when enabling fbcon again - fbcon needs to
> >   redraw anyway on dpms on.
> 
> Would this guarantee that the fb is suspended before/during suspend (of
> the graphics device) and resumed somewhere during/after resume?
> 
> Suspending the fb also has the effect that reads/writes to /dev/fbN
> fail, maybe that is a bit too restricted since the framebuffer is just
> accessible until the device is suspended.
> 
> (Hmm, fb_read/fb_write does not seem to do any locking...)

Hm, annoying. That pretty much means runtime pm breaks fbcon. I guess in
practice no one will notice, since it generally should keep working for as
long as the output is on (if we ignore stuff like manual refresh panels
for a bit here ...).

> >   Another solution for fbcon might be to untangle the suspend/resume stuff
> >   and protect it by something else than console_lock. But that means
> >   fixing up fbcon locking horror shows.
> 
> console_lock seems needed for some 

[PATCH v4] drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)

[Daniel Vetter]

On Fri, Jul 15, 2016 at 09:31:11AM +0100, Chris Wilson wrote:
> vGEM buffers are useful for passing data between software clients and
> hardware renders. By allowing the user to create and attach fences to
> the exported vGEM buffers (on the dma-buf), the user can implement a
> deferred renderer and queue hardware operations like flipping and then
> signal the buffer readiness (i.e. this allows the user to schedule
> operations out-of-order, but have them complete in-order).
> 
> This also makes it much easier to write tightly controlled testcases for
> dma-buf fencing and signaling between hardware drivers.
> 
> v2: Don't pretend the fences exist in an ordered timeline, but allocate
> a separate fence-context for each fence so that the fences are
> unordered.
> v3: Make the debug output more interesting, and show the signaled status.
> v4: Automatically signal the fence to prevent userspace from
> indefinitely hanging drivers.
> 
> Testcase: igt/vgem_basic/dmabuf-fence
> Testcase: igt/vgem_slow/nohang
> Signed-off-by: Chris Wilson 
> Cc: Sean Paul 
> Cc: Zach Reizner 
> Cc: Gustavo Padovan 
> Cc: Daniel Vetter 
> Acked-by: Zach Reizner 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/vgem/Makefile |   2 +-
>  drivers/gpu/drm/vgem/vgem_drv.c   |  34 +
>  drivers/gpu/drm/vgem/vgem_drv.h   |  16 +++
>  drivers/gpu/drm/vgem/vgem_fence.c | 283 
> ++
>  include/uapi/drm/vgem_drm.h   |  62 +
>  5 files changed, 396 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/vgem/vgem_fence.c
>  create mode 100644 include/uapi/drm/vgem_drm.h
> 
> diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
> index 3f4c7b842028..bfcdea1330e6 100644
> --- a/drivers/gpu/drm/vgem/Makefile
> +++ b/drivers/gpu/drm/vgem/Makefile
> @@ -1,4 +1,4 @@
>  ccflags-y := -Iinclude/drm
> -vgem-y := vgem_drv.o
> +vgem-y := vgem_drv.o vgem_fence.o
>  
>  obj-$(CONFIG_DRM_VGEM)   += vgem.o
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 29c2aab3c1a7..c15bafb06665 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -83,6 +83,34 @@ static const struct vm_operations_struct vgem_gem_vm_ops = 
> {
>   .close = drm_gem_vm_close,
>  };
>  
> +static int vgem_open(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vgem_file *vfile;
> + int ret;
> +
> + vfile = kzalloc(sizeof(*vfile), GFP_KERNEL);
> + if (!vfile)
> + return -ENOMEM;
> +
> + file->driver_priv = vfile;
> +
> + ret = vgem_fence_open(vfile);
> + if (ret) {
> + kfree(vfile);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void vgem_preclose(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vgem_file *vfile = file->driver_priv;
> +
> + vgem_fence_close(vfile);
> + kfree(vfile);
> +}
> +
>  /* ioctls */
>  
>  static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
> @@ -164,6 +192,8 @@ unref:
>  }
>  
>  static struct drm_ioctl_desc vgem_ioctls[] = {
> + DRM_IOCTL_DEF_DRV(VGEM_FENCE_ATTACH, vgem_fence_attach_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VGEM_FENCE_SIGNAL, vgem_fence_signal_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>  };
>  
>  static int vgem_mmap(struct file *filp, struct vm_area_struct *vma)
> @@ -271,9 +301,12 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>  
>  static struct drm_driver vgem_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_PRIME,
> + .open   = vgem_open,
> + .preclose   = vgem_preclose,
>   .gem_free_object_unlocked   = vgem_gem_free_object,
>   .gem_vm_ops = _gem_vm_ops,
>   .ioctls = vgem_ioctls,
> + .num_ioctls = ARRAY_SIZE(vgem_ioctls),
>   .fops   = _driver_fops,
>  
>   .dumb_create= vgem_gem_dumb_create,
> @@ -328,5 +361,6 @@ module_init(vgem_init);
>  module_exit(vgem_exit);
>  
>  MODULE_AUTHOR("Red Hat, Inc.");
> +MODULE_AUTHOR("Intel Corporation");
>  MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_LICENSE("GPL and additional rights");
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.h b/drivers/gpu/drm/vgem/vgem_drv.h
> index 988cbaae7588..1f8798ad329c 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.h
> +++ b/drivers/gpu/drm/vgem/vgem_drv.h
> @@ -32,9 +32,25 @@
>  #include 
>  #include 
>  
> +#include 
> +
> +struct vgem_file {
> + struct idr fence_idr;
> + struct mutex fence_mutex;
> +};
> +
>  #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
>  struct drm_vgem_gem_object {
>   struct drm_gem_object base;
>  };
>  
> +int vgem_fence_open(struct vgem_file *file);
> +int vgem_fence_attach_ioctl(struct drm_device *dev,
> + void *data,
> +  

[PATCH 02/11] drm/doc: Add kerneldoc for @index

[Chris Wilson]

On Mon, Jul 18, 2016 at 09:15:35AM +0200, Daniel Vetter wrote:
> On Fri, Jul 15, 2016 at 09:06:04PM +0100, Chris Wilson wrote:
> > On Fri, Jul 15, 2016 at 09:47:59PM +0200, Daniel Vetter wrote:
> > > Was forgotten when adding them all over. 0-day should complain about
> > > new missing kernel-doc, not sure why that wasn't caught/fixed.
> > > 
> > > Cc: Chris Wilson 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  include/drm/drm_crtc.h | 26 +-
> > >  1 file changed, 21 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index ebf078685f86..656f189f1198 100644
> > > --- a/include/drm/drm_crtc.h
> > > +++ b/include/drm/drm_crtc.h
> > > @@ -783,7 +783,10 @@ struct drm_crtc {
> > >   struct drm_plane *primary;
> > >   struct drm_plane *cursor;
> > >  
> > > - /* position inside the mode_config.list, can be used as a [] idx */
> > > + /**
> > > +  * @index: Position inside the mode_config.list, can be used as an array
> > 
> > For all:
> > 
> > @index: Fixed position inside the mode_config.list, can be used as an
> > array index. The @index is assigned when the crtc is inserted into the
> > list, and it will remain at that position inside the list until the
> > module is unloaded.
> > 
> > Just want to emphasis the unchanging nature of the @index. Second
> > sentence may be overkill.
> 
> Just adding "It is invariant over the lifetime of $object." for brevity?

Wins.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 96964] R290X stuck at 100% GPU load / full core clock on non-x86 machines

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96964

--- Comment #11 from Timothy Pearson  ---
This bug is also triggered on x86 if the BIOS is set to not execute option ROMs
on installed PCI/PCIe cards.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/44fdb073/attachment.html>

[Bug 96964] R290X stuck at 100% GPU load / full core clock on non-x86 machines

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96964

--- Comment #10 from Timothy Pearson  ---
Created attachment 125126
  --> https://bugs.freedesktop.org/attachment.cgi?id=125126=edit
Hack around spurious GPU load indication

This is rather nasty but it does fix the problem.  DPM works perfectly on both
cards with this applied.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160718/b452740a/attachment.html>

[Bug 96964] R290X stuck at 100% GPU load / full core clock on non-x86 machines

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=96964

--- Comment #9 from Timothy Pearson  ---
A bit more information:
 * Disabling DPM does not fix the problem (dpm=0 on module load)
 * Using hard reset instead of soft reset just makes a complete mess / host
hang
 * It looks like only the CP block needs to be reset (GPU softreset: 0x0008
corresponds to RADEON_RESET_CP).
 * After reset DPM is broken, but DPM also breaks after unloading / reloading
the radeon module so this may be a red herring.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: