[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #129 from Chris Waters  ---
> If I disable the lowest 300 MHz shader clock, so that the minimum shader
> clock is 500 MHz and maximum is 1000 MHz, the flickering disappears.

What about lower settings than 500 MHz?  Did you try 400 MHz or even 350?

What is the performance like?

-- 
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/20161103/61331bab/attachment.html>

[PATCHv3 2/4] drm/tilcdc: Stop using struct drm_driver load() callback

[Jyri Sarha]

On 11/03/16 20:15, Laurent Pinchart wrote:
> Hi Jyri,
> 
> Thank you for the patch.
> 
> On Wednesday 02 Nov 2016 17:57:50 Jyri Sarha wrote:
>> Stop using struct drm_driver load() and unload() callbacks. The
>> callbacks should not be used anymore. Instead of using load the
>> drm_device is allocated with drm_dev_alloc() and registered with
>> drm_dev_register() only after the driver is completely initialized.
>> The deinitialization is done directly either in component unbind
>> callback or in platform driver demove callback.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 124 ++--
>>  1 file changed, 70 insertions(+), 54 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 5cf534c..11f3262 100644
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
>> @@ -194,18 +194,22 @@ static int cpufreq_transition(struct notifier_block
>> *nb, * DRM operations:
>>   */
>>
>> -static int tilcdc_unload(struct drm_device *dev)
>> +static void tilcdc_fini(struct drm_device *dev)
>>  {
>>  struct tilcdc_drm_private *priv = dev->dev_private;
>>
>> -tilcdc_remove_external_encoders(dev);
>> +drm_modeset_lock_crtc(priv->crtc, NULL);
>> +tilcdc_crtc_disable(priv->crtc);
>> +drm_modeset_unlock_crtc(priv->crtc);
>> +
>> +drm_dev_unregister(dev);
>>
>> -drm_fbdev_cma_fini(priv->fbdev);
>>  drm_kms_helper_poll_fini(dev);
>> +drm_fbdev_cma_fini(priv->fbdev);
> 
> Is there a need to reorder these ?

I am not sure actually. When the things did not work properly in the
beginning I just ordered unloading to happen strictly in the reverse
order compared to loading. I did not go back to check what changes were
actually needed when I got things working.

> 
>> +drm_irq_uninstall(dev);
>>  drm_mode_config_cleanup(dev);
>> -drm_vblank_cleanup(dev);
>>
>> -drm_irq_uninstall(dev);
>> +tilcdc_remove_external_encoders(dev);
>>
>>  #ifdef CONFIG_CPU_FREQ
>>  cpufreq_unregister_notifier(>freq_transition,
>> @@ -225,28 +229,34 @@ static int tilcdc_unload(struct drm_device *dev)
>>
>>  pm_runtime_disable(dev->dev);
>>
>> -return 0;
>> +drm_dev_unref(dev);
>>  }
>>
>> -static int tilcdc_load(struct drm_device *dev, unsigned long flags)
>> +static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
>>  {
>> -struct platform_device *pdev = dev->platformdev;
>> -struct device_node *node = pdev->dev.of_node;
>> +struct drm_device *ddev;
>> +struct platform_device *pdev = to_platform_device(dev);
>> +struct device_node *node = dev->of_node;
>>  struct tilcdc_drm_private *priv;
>>  struct resource *res;
>>  u32 bpp = 0;
>>  int ret;
>>
>> -priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
>> +priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>  if (!priv) {
>> -dev_err(dev->dev, "failed to allocate private data\n");
>> +dev_err(dev, "failed to allocate private data\n");
>>  return -ENOMEM;
>>  }
>>
>> -dev->dev_private = priv;
>> +ddev = drm_dev_alloc(ddrv, dev);
> 
> As a follow-up patch you might want to move tilcdc_driver above this function 
> and use it directly to remove the ddrv argument.
> 

Ok, thanks.

> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
>> +if (IS_ERR(ddev))
>> +return PTR_ERR(ddev);
>> +
>> +ddev->platformdev = pdev;
>> +ddev->dev_private = priv;
> 
> [snip]
> 

[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

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

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

--- Comment #12 from Alex Deucher  ---
Created attachment 127736
  --> https://bugs.freedesktop.org/attachment.cgi?id=127736=edit
possible fix

This should fix it.

-- 
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/20161103/71d691a8/attachment.html>

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

On 11/3/2016 9:33 PM, Daniel Vetter wrote:
> On Thu, Nov 3, 2016 at 2:49 PM, Ville Syrjälä
>  wrote:
>>> If you still think you should send this revert, I am removing my NACK.
>>> Pls Go ahead.
>> The other option is to not revert and instead slap a fix on top. But
>> that would have to be done reasonably quickly so that the thing is
>> ready in time for 4.10. We're closing in on 4.9-rc4 now so I guess
>> we should still have a few weeks to fix things up. Whether that's
>> enough I don't know. If not, then we should revert.
> 1 week and then revert is the guideline. Please don't bend the rules
> for regressions all the time, it makes things painful for everyone
> else.
> -Daniel
I don't remember breaking it for first time itself.
As I mentioned in the other thread, please add the regression details.
After that, revert it if you want (I saw you have already given 
maintainers-ack)

Regards
Shashank

[PATCH] dma-buf/fence-array: enable_signaling from wq

[Chris Wilson]

On Thu, Nov 03, 2016 at 04:31:14PM -0400, Rob Clark wrote:
> Currently with fence-array, we have a potential deadlock situation.  If we
> fence_add_callback() on an array-fence, the array-fence's lock is aquired
> first, and in it's ->enable_signaling() callback, it will install cb's on
> it's array-member fences, so the array-member's lock is acquired second.
> 
> But in the signal path, the array-member's lock is acquired first, and the
> array-fence's lock acquired second.

Could mention that this is only an issue if the same fence->lock
appeared more than once in the array. Which is possible.

> diff --git a/drivers/dma-buf/dma-fence-array.c 
> b/drivers/dma-buf/dma-fence-array.c
> index 67eb7c8..274bbb5 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -43,9 +43,10 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
>   dma_fence_put(>base);
>  }
>  
> -static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
> +static void enable_signaling_worker(struct work_struct *w)
>  {
> - struct dma_fence_array *array = to_dma_fence_array(fence);
> + struct dma_fence_array *array =
> + container_of(w, struct dma_fence_array, 
> enable_signaling_worker);
>   struct dma_fence_array_cb *cb = (void *)([1]);
>   unsigned i;
>  
> @@ -63,11 +64,18 @@ static bool dma_fence_array_enable_signaling(struct 
> dma_fence *fence)
>   if (dma_fence_add_callback(array->fences[i], [i].cb,
>  dma_fence_array_cb_func)) {
>   dma_fence_put(>base);
> - if (atomic_dec_and_test(>num_pending))
> - return false;
> + if (atomic_dec_and_test(>num_pending)) {
> + dma_fence_signal(>base);
> + return;
> + }
>   }
>   }
> +}
>  
> +static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
> +{
> + struct dma_fence_array *array = to_dma_fence_array(fence);
> + queue_work(system_unbound_wq, >enable_signaling_worker);

I think you need a dma_fence_get(fence) here with a corresponding put in
the worker. Sadly I still can't poke a hole in the lockdep warning.

What I might suggest is that we try

static bool is_signaled(struct dma_fence *fence)
{
if (test_bit(SIGNALED_BIT, >flags))
return true;

return fence->ops->signaled && fence->ops->signaled(fence);
}

static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
{
struct dma_fence_array *array = to_dma_fence_array(fence);
int num_pending = atomic_read(>num_pending);
int i;

for (i = 0; i < array->num_fences; i++)
if (is_signaled(array->fences[i]) && !--num_pending) {
atomic_set(>num_pending, 0);
return false;
}

dma_fence_get(>base);
queue_work(system_unbound_wq, >enable_signaling_worker);
}
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

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

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

--- Comment #11 from Johannes Hirte  ---
As the dmesg shows a problem in the ACP code, I've just disabled it now and it
works. Don't know what's the real problem, but without ACP my system reboot
fine.

-- 
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/20161103/bf6d8cba/attachment-0001.html>

[Bug 98578] AMDGPU white glitches in some games

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

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

--- Comment #5 from Lukas Jirkovsky  ---
Created attachment 127735
  --> https://bugs.freedesktop.org/attachment.cgi?id=127735=edit
the glitch on the last frame of the trace

-- 
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/20161103/3152a657/attachment.html>

[Bug 98578] AMDGPU white glitches in some games

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

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

--- Comment #4 from Lukas Jirkovsky  ---
I was able to get a smaller trace:
https://drive.google.com/open?id=0B2YvkwbBDwKYY1pPaUh0T1dlWjQ

The glitch appears on the last frame on the top of the tower for me. See the
attached screenshot.

I can't tell for sure, but according to the update logs it must have been
occurring with llvm 282xxx, too.

-- 
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/20161103/0a75426a/attachment.html>

[PATCH] drm: move check for min/max width/height for atomic drivers

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 02:37:30PM -0400, Rob Clark wrote:
> On Thu, Nov 3, 2016 at 2:32 PM, Ville Syrjälä
>  wrote:
> > On Thu, Nov 03, 2016 at 11:22:37AM -0400, Rob Clark wrote:
> >> On Thu, Nov 3, 2016 at 10:55 AM, Ville Syrjälä
> >>  wrote:
> >> > On Thu, Nov 03, 2016 at 10:14:20AM -0400, Rob Clark wrote:
> >> >> On Thu, Nov 3, 2016 at 10:12 AM, Ville Syrjälä
> >> >>  wrote:
> >> >> > On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
> >> >> >> drm-hwc + android tries to create an fb for the wallpaper layer, 
> >> >> >> which
> >> >> >> is larger than the screen resolution, and potentially larger than
> >> >> >> mode_config->max_{width,height}.  But the plane src_w/src_h is within
> >> >> >> the max limits, so it is something the hardware can otherwise do.
> >> >> >>
> >> >> >> For atomic drivers, defer the check to drm_atomic_plane_check().
> >> >> >>
> >> >> >> Signed-off-by: Rob Clark 
> >> >> >> ---
> >> >> >>  drivers/gpu/drm/drm_atomic.c | 17 +
> >> >> >>  drivers/gpu/drm/drm_crtc.c   | 26 +-
> >> >> >>  2 files changed, 34 insertions(+), 9 deletions(-)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c 
> >> >> >> b/drivers/gpu/drm/drm_atomic.c
> >> >> >> index 34edd4f..fb0f07ce 100644
> >> >> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> >> >> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state 
> >> >> >> *state,
> >> >> >>  static int drm_atomic_plane_check(struct drm_plane *plane,
> >> >> >>   struct drm_plane_state *state)
> >> >> >>  {
> >> >> >> + struct drm_mode_config *config = >dev->mode_config;
> >> >> >>   unsigned int fb_width, fb_height;
> >> >> >> + unsigned int min_width, max_width, min_height, max_height;
> >> >> >>   int ret;
> >> >> >>
> >> >> >>   /* either *both* CRTC and FB must be set, or neither */
> >> >> >> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct 
> >> >> >> drm_plane *plane,
> >> >> >>   return -ENOSPC;
> >> >> >>   }
> >> >> >>
> >> >> >> + min_width = config->min_width << 16;
> >> >> >> + max_width = config->max_width << 16;
> >> >> >> + min_height = config->min_height << 16;
> >> >> >> + max_height = config->max_height << 16;
> >> >> >> +
> >> >> >> + /* Make sure source dimensions are within bounds. */
> >> >> >> + if (min_width > state->src_w || state->src_w > max_width ||
> >> >> >> + min_height > state->src_h || state->src_h > max_height) {
> >> >> >> + DRM_DEBUG_ATOMIC("Invalid source size "
> >> >> >> +  "%u.%06ux%u.%06u\n",
> >> >> >> +  state->src_w >> 16, ((state->src_w & 
> >> >> >> 0x) * 15625) >> 10,
> >> >> >> +  state->src_h >> 16, ((state->src_h & 
> >> >> >> 0x) * 15625) >> 10);
> >> >> >> + return -ERANGE;
> >> >> >> + }
> >> >> >> +
> >> >> >>   if (plane_switching_crtc(state->state, plane, state)) {
> >> >> >>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC 
> >> >> >> directly\n",
> >> >> >>plane->base.id, plane->name);
> >> >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> >> >> index b4b973f..7294bde 100644
> >> >> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> >> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> >> >> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct 
> >> >> >> drm_device *dev,
> >> >> >>   return ERR_PTR(-EINVAL);
> >> >> >>   }
> >> >> >>
> >> >> >> - if ((config->min_width > r->width) || (r->width > 
> >> >> >> config->max_width)) {
> >> >> >> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= 
> >> >> >> %d && <= %d\n",
> >> >> >> -   r->width, config->min_width, 
> >> >> >> config->max_width);
> >> >> >> - return ERR_PTR(-EINVAL);
> >> >> >> - }
> >> >> >> - if ((config->min_height > r->height) || (r->height > 
> >> >> >> config->max_height)) {
> >> >> >> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= 
> >> >> >> %d && <= %d\n",
> >> >> >> -   r->height, config->min_height, 
> >> >> >> config->max_height);
> >> >> >> - return ERR_PTR(-EINVAL);
> >> >> >> + /* for atomic drivers, we check the src dimensions in
> >> >> >> +  * drm_atomic_plane_check().. allow creation of a fb
> >> >> >> +  * that is larger than what can be scanned out, as
> >> >> >> +  * long as userspace doesn't try to scanout a portion
> >> >> >> +  * of the fb that is too large.
> >> >> >> +  */
> >> >> >> + if (!file_priv->atomic) {
> >> >> >> + if ((config->min_width > r->width) || (r->width > 
> >> >> >> config->max_width)) {
> >> >> >> + DRM_DEBUG_KMS("bad framebuffer width %d, 
> >> >> >> should be >= %d && <= %d\n",
> >> >> >> + 

[PATCH] drm: move check for min/max width/height for atomic drivers

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 09:35:24AM -0600, Sean Paul wrote:
> On Thu, Nov 3, 2016 at 9:22 AM, Rob Clark  wrote:
> > On Thu, Nov 3, 2016 at 10:55 AM, Ville Syrjälä
> >  wrote:
> >> On Thu, Nov 03, 2016 at 10:14:20AM -0400, Rob Clark wrote:
> >>> On Thu, Nov 3, 2016 at 10:12 AM, Ville Syrjälä
> >>>  wrote:
> >>> > On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
> >>> >> drm-hwc + android tries to create an fb for the wallpaper layer, which
> >>> >> is larger than the screen resolution, and potentially larger than
> >>> >> mode_config->max_{width,height}.  But the plane src_w/src_h is within
> >>> >> the max limits, so it is something the hardware can otherwise do.
> >>> >>
> >>> >> For atomic drivers, defer the check to drm_atomic_plane_check().
> >>> >>
> >>> >> Signed-off-by: Rob Clark 
> >>> >> ---
> >>> >>  drivers/gpu/drm/drm_atomic.c | 17 +
> >>> >>  drivers/gpu/drm/drm_crtc.c   | 26 +-
> >>> >>  2 files changed, 34 insertions(+), 9 deletions(-)
> >>> >>
> >>> >> diff --git a/drivers/gpu/drm/drm_atomic.c 
> >>> >> b/drivers/gpu/drm/drm_atomic.c
> >>> >> index 34edd4f..fb0f07ce 100644
> >>> >> --- a/drivers/gpu/drm/drm_atomic.c
> >>> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> >> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state 
> >>> >> *state,
> >>> >>  static int drm_atomic_plane_check(struct drm_plane *plane,
> >>> >>   struct drm_plane_state *state)
> >>> >>  {
> >>> >> + struct drm_mode_config *config = >dev->mode_config;
> >>> >>   unsigned int fb_width, fb_height;
> >>> >> + unsigned int min_width, max_width, min_height, max_height;
> >>> >>   int ret;
> >>> >>
> >>> >>   /* either *both* CRTC and FB must be set, or neither */
> >>> >> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct 
> >>> >> drm_plane *plane,
> >>> >>   return -ENOSPC;
> >>> >>   }
> >>> >>
> >>> >> + min_width = config->min_width << 16;
> >>> >> + max_width = config->max_width << 16;
> >>> >> + min_height = config->min_height << 16;
> >>> >> + max_height = config->max_height << 16;
> >>> >> +
> >>> >> + /* Make sure source dimensions are within bounds. */
> >>> >> + if (min_width > state->src_w || state->src_w > max_width ||
> >>> >> + min_height > state->src_h || state->src_h > max_height) {
> >>> >> + DRM_DEBUG_ATOMIC("Invalid source size "
> >>> >> +  "%u.%06ux%u.%06u\n",
> >>> >> +  state->src_w >> 16, ((state->src_w & 
> >>> >> 0x) * 15625) >> 10,
> >>> >> +  state->src_h >> 16, ((state->src_h & 
> >>> >> 0x) * 15625) >> 10);
> >>> >> + return -ERANGE;
> >>> >> + }
> >>> >> +
> >>> >>   if (plane_switching_crtc(state->state, plane, state)) {
> >>> >>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC 
> >>> >> directly\n",
> >>> >>plane->base.id, plane->name);
> >>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >>> >> index b4b973f..7294bde 100644
> >>> >> --- a/drivers/gpu/drm/drm_crtc.c
> >>> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >>> >> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device 
> >>> >> *dev,
> >>> >>   return ERR_PTR(-EINVAL);
> >>> >>   }
> >>> >>
> >>> >> - if ((config->min_width > r->width) || (r->width > 
> >>> >> config->max_width)) {
> >>> >> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d 
> >>> >> && <= %d\n",
> >>> >> -   r->width, config->min_width, 
> >>> >> config->max_width);
> >>> >> - return ERR_PTR(-EINVAL);
> >>> >> - }
> >>> >> - if ((config->min_height > r->height) || (r->height > 
> >>> >> config->max_height)) {
> >>> >> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= 
> >>> >> %d && <= %d\n",
> >>> >> -   r->height, config->min_height, 
> >>> >> config->max_height);
> >>> >> - return ERR_PTR(-EINVAL);
> >>> >> + /* for atomic drivers, we check the src dimensions in
> >>> >> +  * drm_atomic_plane_check().. allow creation of a fb
> >>> >> +  * that is larger than what can be scanned out, as
> >>> >> +  * long as userspace doesn't try to scanout a portion
> >>> >> +  * of the fb that is too large.
> >>> >> +  */
> >>> >> + if (!file_priv->atomic) {
> >>> >> + if ((config->min_width > r->width) || (r->width > 
> >>> >> config->max_width)) {
> >>> >> + DRM_DEBUG_KMS("bad framebuffer width %d, should 
> >>> >> be >= %d && <= %d\n",
> >>> >> +   r->width, config->min_width, 
> >>> >> config->max_width);
> >>> >> + return ERR_PTR(-EINVAL);
> >>> >> + }
> >>> >> + if ((config->min_height > r->height) || (r->height > 
> >>> >> config->max_height)) {
> >>> >> +  

[PATCH] drm: move check for min/max width/height for atomic drivers

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 11:22:37AM -0400, Rob Clark wrote:
> On Thu, Nov 3, 2016 at 10:55 AM, Ville Syrjälä
>  wrote:
> > On Thu, Nov 03, 2016 at 10:14:20AM -0400, Rob Clark wrote:
> >> On Thu, Nov 3, 2016 at 10:12 AM, Ville Syrjälä
> >>  wrote:
> >> > On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
> >> >> drm-hwc + android tries to create an fb for the wallpaper layer, which
> >> >> is larger than the screen resolution, and potentially larger than
> >> >> mode_config->max_{width,height}.  But the plane src_w/src_h is within
> >> >> the max limits, so it is something the hardware can otherwise do.
> >> >>
> >> >> For atomic drivers, defer the check to drm_atomic_plane_check().
> >> >>
> >> >> Signed-off-by: Rob Clark 
> >> >> ---
> >> >>  drivers/gpu/drm/drm_atomic.c | 17 +
> >> >>  drivers/gpu/drm/drm_crtc.c   | 26 +-
> >> >>  2 files changed, 34 insertions(+), 9 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> >> index 34edd4f..fb0f07ce 100644
> >> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> >> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state *state,
> >> >>  static int drm_atomic_plane_check(struct drm_plane *plane,
> >> >>   struct drm_plane_state *state)
> >> >>  {
> >> >> + struct drm_mode_config *config = >dev->mode_config;
> >> >>   unsigned int fb_width, fb_height;
> >> >> + unsigned int min_width, max_width, min_height, max_height;
> >> >>   int ret;
> >> >>
> >> >>   /* either *both* CRTC and FB must be set, or neither */
> >> >> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct drm_plane 
> >> >> *plane,
> >> >>   return -ENOSPC;
> >> >>   }
> >> >>
> >> >> + min_width = config->min_width << 16;
> >> >> + max_width = config->max_width << 16;
> >> >> + min_height = config->min_height << 16;
> >> >> + max_height = config->max_height << 16;
> >> >> +
> >> >> + /* Make sure source dimensions are within bounds. */
> >> >> + if (min_width > state->src_w || state->src_w > max_width ||
> >> >> + min_height > state->src_h || state->src_h > max_height) {
> >> >> + DRM_DEBUG_ATOMIC("Invalid source size "
> >> >> +  "%u.%06ux%u.%06u\n",
> >> >> +  state->src_w >> 16, ((state->src_w & 
> >> >> 0x) * 15625) >> 10,
> >> >> +  state->src_h >> 16, ((state->src_h & 
> >> >> 0x) * 15625) >> 10);
> >> >> + return -ERANGE;
> >> >> + }
> >> >> +
> >> >>   if (plane_switching_crtc(state->state, plane, state)) {
> >> >>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC 
> >> >> directly\n",
> >> >>plane->base.id, plane->name);
> >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> >> index b4b973f..7294bde 100644
> >> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> >> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device 
> >> >> *dev,
> >> >>   return ERR_PTR(-EINVAL);
> >> >>   }
> >> >>
> >> >> - if ((config->min_width > r->width) || (r->width > 
> >> >> config->max_width)) {
> >> >> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d 
> >> >> && <= %d\n",
> >> >> -   r->width, config->min_width, config->max_width);
> >> >> - return ERR_PTR(-EINVAL);
> >> >> - }
> >> >> - if ((config->min_height > r->height) || (r->height > 
> >> >> config->max_height)) {
> >> >> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d 
> >> >> && <= %d\n",
> >> >> -   r->height, config->min_height, 
> >> >> config->max_height);
> >> >> - return ERR_PTR(-EINVAL);
> >> >> + /* for atomic drivers, we check the src dimensions in
> >> >> +  * drm_atomic_plane_check().. allow creation of a fb
> >> >> +  * that is larger than what can be scanned out, as
> >> >> +  * long as userspace doesn't try to scanout a portion
> >> >> +  * of the fb that is too large.
> >> >> +  */
> >> >> + if (!file_priv->atomic) {
> >> >> + if ((config->min_width > r->width) || (r->width > 
> >> >> config->max_width)) {
> >> >> + DRM_DEBUG_KMS("bad framebuffer width %d, should 
> >> >> be >= %d && <= %d\n",
> >> >> +   r->width, config->min_width, 
> >> >> config->max_width);
> >> >> + return ERR_PTR(-EINVAL);
> >> >> + }
> >> >> + if ((config->min_height > r->height) || (r->height > 
> >> >> config->max_height)) {
> >> >> + DRM_DEBUG_KMS("bad framebuffer height %d, should 
> >> >> be >= %d && <= %d\n",
> >> >> +   r->height, config->min_height, 
> >> >> 

[PATCHv3 2/4] drm/tilcdc: Stop using struct drm_driver load() callback

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Wednesday 02 Nov 2016 17:57:50 Jyri Sarha wrote:
> Stop using struct drm_driver load() and unload() callbacks. The
> callbacks should not be used anymore. Instead of using load the
> drm_device is allocated with drm_dev_alloc() and registered with
> drm_dev_register() only after the driver is completely initialized.
> The deinitialization is done directly either in component unbind
> callback or in platform driver demove callback.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 124 ++--
>  1 file changed, 70 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 5cf534c..11f3262 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -194,18 +194,22 @@ static int cpufreq_transition(struct notifier_block
> *nb, * DRM operations:
>   */
> 
> -static int tilcdc_unload(struct drm_device *dev)
> +static void tilcdc_fini(struct drm_device *dev)
>  {
>   struct tilcdc_drm_private *priv = dev->dev_private;
> 
> - tilcdc_remove_external_encoders(dev);
> + drm_modeset_lock_crtc(priv->crtc, NULL);
> + tilcdc_crtc_disable(priv->crtc);
> + drm_modeset_unlock_crtc(priv->crtc);
> +
> + drm_dev_unregister(dev);
> 
> - drm_fbdev_cma_fini(priv->fbdev);
>   drm_kms_helper_poll_fini(dev);
> + drm_fbdev_cma_fini(priv->fbdev);

Is there a need to reorder these ?

> + drm_irq_uninstall(dev);
>   drm_mode_config_cleanup(dev);
> - drm_vblank_cleanup(dev);
> 
> - drm_irq_uninstall(dev);
> + tilcdc_remove_external_encoders(dev);
> 
>  #ifdef CONFIG_CPU_FREQ
>   cpufreq_unregister_notifier(>freq_transition,
> @@ -225,28 +229,34 @@ static int tilcdc_unload(struct drm_device *dev)
> 
>   pm_runtime_disable(dev->dev);
> 
> - return 0;
> + drm_dev_unref(dev);
>  }
> 
> -static int tilcdc_load(struct drm_device *dev, unsigned long flags)
> +static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
>  {
> - struct platform_device *pdev = dev->platformdev;
> - struct device_node *node = pdev->dev.of_node;
> + struct drm_device *ddev;
> + struct platform_device *pdev = to_platform_device(dev);
> + struct device_node *node = dev->of_node;
>   struct tilcdc_drm_private *priv;
>   struct resource *res;
>   u32 bpp = 0;
>   int ret;
> 
> - priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>   if (!priv) {
> - dev_err(dev->dev, "failed to allocate private data\n");
> + dev_err(dev, "failed to allocate private data\n");
>   return -ENOMEM;
>   }
> 
> - dev->dev_private = priv;
> + ddev = drm_dev_alloc(ddrv, dev);

As a follow-up patch you might want to move tilcdc_driver above this function 
and use it directly to remove the ddrv argument.

Apart from that,

Reviewed-by: Laurent Pinchart 

> + if (IS_ERR(ddev))
> + return PTR_ERR(ddev);
> +
> + ddev->platformdev = pdev;
> + ddev->dev_private = priv;

[snip]

-- 
Regards,

Laurent Pinchart

[Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 07:55:20PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 03:45:43PM -0200, Paulo Zanoni wrote:
> > Em Qui, 2016-11-03 às 18:45 +0200, Ville Syrjälä escreveu:
> > > On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> > > > 
> > > > Signed-off-by: Maarten Lankhorst  > > > >
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > index faa67624e1ed..0028335fc1bb 100644
> > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct
> > > > drm_i915_private *dev_priv,
> > > >  
> > > >    mutex_lock(>lock);
> > > >  
> > > > -   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > > >    if (fbc->crtc == to_intel_crtc(crtc)) {
> > > >    fbc_crtc_present = true;
> > > >    break;
> > > > @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct
> > > > drm_i915_private *dev_priv,
> > > >     * plane. We could go for fancier schemes such as checking
> > > > the plane
> > > >     * size, but this would just affect the few platforms that
> > > > don't tie FBC
> > > >     * to pipe or plane A. */
> > > > -   for_each_plane_in_state(state, plane, plane_state, i) {
> > > > +   for_each_new_plane_in_state(state, plane, plane_state, i)
> > > > {
> > > >    struct intel_plane_state *intel_plane_state =
> > > >    to_intel_plane_state(plane_state);
> > > >  
> > > >    if (!intel_plane_state->base.visible)
> > > >    continue;
> > > 
> > > Unrelated but this thing looks somewhat bogus. FBC is tied to the
> > > primary plane only, so why do we care about the visibility of the
> > > other
> > > planes? Adding Paulo to Cc...
> > 
> > Looks like you've found a bug... Thanks! We should really be iterating
> > over primary planes only. Adding to the TODO list.
> > 
> > > 
> > > > 
> > > >  
> > > > -   for_each_crtc_in_state(state, crtc, crtc_state, j)
> > > > {
> > > > +   for_each_new_crtc_in_state(state, crtc,
> > > > crtc_state, j) {
> > > 
> > > Also, can't this inner loop be replaced with a simple
> > > crtc = plane_state->crtc ?
> > 
> > Is there a way to get the proposed crtc_state without the loop?
> 
> ...get_existing_crtc_state(plane_state->crtc);
> 
> since the plane is part of the state the crtc should be too, I think.

Well, I guess Maarten wants to change it to get_new_state() soon enough.

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 03:45:43PM -0200, Paulo Zanoni wrote:
> Em Qui, 2016-11-03 às 18:45 +0200, Ville Syrjälä escreveu:
> > On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> > > 
> > > Signed-off-by: Maarten Lankhorst  > > >
> > > ---
> > >  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > index faa67624e1ed..0028335fc1bb 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct
> > > drm_i915_private *dev_priv,
> > >  
> > >  mutex_lock(>lock);
> > >  
> > > - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > >  if (fbc->crtc == to_intel_crtc(crtc)) {
> > >  fbc_crtc_present = true;
> > >  break;
> > > @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct
> > > drm_i915_private *dev_priv,
> > >   * plane. We could go for fancier schemes such as checking
> > > the plane
> > >   * size, but this would just affect the few platforms that
> > > don't tie FBC
> > >   * to pipe or plane A. */
> > > - for_each_plane_in_state(state, plane, plane_state, i) {
> > > + for_each_new_plane_in_state(state, plane, plane_state, i)
> > > {
> > >  struct intel_plane_state *intel_plane_state =
> > >  to_intel_plane_state(plane_state);
> > >  
> > >  if (!intel_plane_state->base.visible)
> > >  continue;
> > 
> > Unrelated but this thing looks somewhat bogus. FBC is tied to the
> > primary plane only, so why do we care about the visibility of the
> > other
> > planes? Adding Paulo to Cc...
> 
> Looks like you've found a bug... Thanks! We should really be iterating
> over primary planes only. Adding to the TODO list.
> 
> > 
> > > 
> > >  
> > > - for_each_crtc_in_state(state, crtc, crtc_state, j)
> > > {
> > > + for_each_new_crtc_in_state(state, crtc,
> > > crtc_state, j) {
> > 
> > Also, can't this inner loop be replaced with a simple
> > crtc = plane_state->crtc ?
> 
> Is there a way to get the proposed crtc_state without the loop?

...get_existing_crtc_state(plane_state->crtc);

since the plane is part of the state the crtc should be too, I think.

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

[David Weinehall]

On Thu, Nov 03, 2016 at 11:42:38AM -0400, Lyude wrote:
> Now that we don't run the connector reprobing from i915_drm_resume(), we
> need to make it so we don't have to wait for reprobing to finish so that
> we actually speed things up. In order to do this, we need to make sure
> that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
> while trying to acquire the mode_config lock that
> drm_kms_helper_poll_enable() needs to acquire.
> 
> The easiest way to do this is to just enable polling before hpd. This
> shouldn't break anything since at that point we have everything else we
> need for polling enabled.
> 
> As well, this should result in a rather significant improvement in how
> quickly we can resume the system.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 

Tested-by: David Weinehall 
Reviewed-by: David Weinehall 
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 532cc0f..f605dde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1595,6 +1595,8 @@ static int i915_drm_resume(struct drm_device *dev)
>  
>   intel_display_resume(dev);
>  
> + drm_kms_helper_poll_enable(dev);
> +
>   /*
>* ... but also need to make sure that hotplug processing
>* doesn't cause havoc. Like in the driver load code we don't
> @@ -1614,7 +1616,6 @@ static int i915_drm_resume(struct drm_device *dev)
>   intel_opregion_notify_adapter(dev_priv, PCI_D0);
>  
>   intel_autoenable_gt_powersave(dev_priv);
> - drm_kms_helper_poll_enable(dev);
>  
>   enable_rpm_wakeref_asserts(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[David Weinehall]

On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> Weine's investigation on benchmarking the suspend/resume process pointed
> out a lot of the time in suspend/resume is being spent reprobing. While
> the reprobing process is a lengthy one for good reason, we don't need to
> hold up the entire suspend/resume process while we wait for it to
> finish. Luckily as it turns out, we already trigger a full connector
> reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> i915_drm_resume() entirely.
> 
> This won't lead to less time spent resuming just yet since now the
> bottleneck will be waiting for the mode_config lock in
> drm_kms_helper_poll_enable(), since that will be held as long as
> i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> address that in the next patch.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 

Tested-by: David Weinehall 
Reviewed-by: David Weinehall 
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bfb2efd..532cc0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
>* notifications.
>* */
>   intel_hpd_init(dev_priv);
> - /* Config may have changed between suspend and resume */
> - drm_helper_hpd_irq_event(dev);
>  
>   intel_opregion_register(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Wednesday 02 Nov 2016 18:32:17 Jyri Sarha wrote:
> Adds drm bride support for attaching drm bridge drivers to tilcdc. The
> decision whether a video port leads to an external encoder or bridge
> is made simply based on remote device's compatible string. The code
> has been tested with BeagleBone-Black with and without BeagleBone
> DVI-D Cape Rev A3 using ti-tfp410 driver.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  .../devicetree/bindings/display/tilcdc/tilcdc.txt  |   7 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c|   7 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h|   2 +
>  drivers/gpu/drm/tilcdc/tilcdc_external.c   | 140 ++---
>  drivers/gpu/drm/tilcdc/tilcdc_external.h   |   1 +
>  5 files changed, 135 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt index
> 6fddb4f..ae7a942 100644
> --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> @@ -34,9 +34,10 @@ Optional properties:
> 
>  Optional nodes:
> 
> - - port/ports: to describe a connection to an external encoder. The
> -   binding follows Documentation/devicetree/bindings/graph.txt and
> -   suppors a single port with a single endpoint.
> + - port/ports: to describe a connection to an external encoder or
> +   bridge. The binding follows

What's the difference between encoder and bridge here ? drm_bridge and 
drm_encoder are irrelevant to DT bindings, we should only care about the 
hardware view of the system here.

> +   Documentation/devicetree/bindings/graph.txt and suppors a single
> +   port with a single endpoint.
> 
>   - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
> Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for
> connecting diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index dcc9621..ec22576 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -384,9 +384,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct
> device *dev) ret = tilcdc_add_external_encoders(ddev);
>   if (ret < 0)
>   goto init_failed;
> + } else {
> + ret = tilcdc_attach_remote_device(ddev);
> + if (ret)
> + goto init_failed;
>   }
> 
> - if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
> + if (!priv->remote_encoder &&
> + ((priv->num_encoders == 0) || (priv->num_connectors == 0))) {
>   dev_err(dev, "no encoders/connectors found\n");
>   ret = -ENXIO;
>   goto init_failed;
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h index d31fe5d..283ff28 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -90,6 +90,8 @@ struct tilcdc_drm_private {
>   struct drm_connector *connectors[8];
>   const struct drm_connector_helper_funcs *connector_funcs[8];
> 
> + struct drm_encoder *remote_encoder;
> +
>   bool is_registered;
>   bool is_componentized;
>  };
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> b/drivers/gpu/drm/tilcdc/tilcdc_external.c index 06a4c58..bcb1324 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
> @@ -28,6 +28,18 @@
>   .raster_order   = 0,
>  };
> 
> +static const struct tilcdc_panel_info panel_info_default = {
> + .ac_bias= 255,
> + .ac_bias_intrpt = 0,
> + .dma_burst_sz   = 16,
> + .bpp= 16,
> + .fdd= 0x80,
> + .tft_alt_mode   = 0,
> + .sync_edge  = 0,
> + .sync_ctrl  = 1,
> + .raster_order   = 0,
> +};
> +
>  static int tilcdc_external_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
>  {
> @@ -130,6 +142,101 @@ void tilcdc_remove_external_encoders(struct drm_device
> *dev) priv->connector_funcs[i]);
>  }
> 
> +static struct drm_encoder_funcs tilcdc_remote_encoder_funcs = {
> + .destroy= drm_encoder_cleanup,
> +};
> +
> +static
> +int tilcdc_attach_bridge(struct drm_device *ddev, struct drm_bridge
> *bridge) +{
> + struct tilcdc_drm_private *priv = ddev->dev_private;
> + int ret;
> +
> + priv->remote_encoder->possible_crtcs = BIT(0);
> + priv->remote_encoder->bridge = bridge;
> + bridge->encoder = priv->remote_encoder;
> +
> + ret = drm_bridge_attach(ddev, bridge);
> + if (ret) {
> + dev_err(ddev->dev, "drm_bridge_attach() failed %d\n", ret);
> + 

[PATCH] drm/rockchip: Use an enum to identify Rockchip VOPs

[Kristian Høgsberg]

drm/rockchip/rockchip_drm_vop.c
> > @@ -141,6 +141,13 @@ struct vop {
> > struct vop_win win[];
> >  };
> >
> > +enum vop_id vop_get_crtc_vop_id(struct drm_crtc *crtc)
> > +{
> > +   struct vop *vop = to_vop(crtc);
> > +
> > +   return vop->data->id;
> > +}
> > +
> >  static inline void vop_writel(struct vop *vop, uint32_t offset,
> uint32_t v)
> >  {
> > writel(v, vop->regs + offset);
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > index 5a4faa85..2c54bcc 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> > @@ -135,8 +135,16 @@ struct vop_win_data {
> > enum drm_plane_type type;
> >  };
> >
> > +enum vop_id {
> > +   RK3036_VOP,
> > +   RK3288_VOP,
> > +   RK3399_VOP_BIG,
> > +   RK3399_VOP_LIT,
> > +};
> > +
> >  struct vop_data {
> > const struct vop_reg_data *init_table;
> > +   uint32_t id;
> > unsigned int table_size;
> > const struct vop_ctrl *ctrl;
> > const struct vop_intr *intr;
> > @@ -321,5 +329,7 @@ static inline int scl_vop_cal_lb_mode(int width,
> bool is_yuv)
> > return lb_mode;
> >  }
> >
> > +enum vop_id vop_get_crtc_vop_id(struct drm_crtc *crtc);
> > +
> >  extern const struct component_ops vop_component_ops;
> >  #endif /* _ROCKCHIP_DRM_VOP_H */
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > index aaede6b..a46e2c8 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> > @@ -131,6 +131,7 @@ static const struct vop_reg_data
> rk3036_vop_init_reg_table[] = {
> >  };
> >
> >  static const struct vop_data rk3036_vop = {
> > +   .id = RK3036_VOP,
> > .init_table = rk3036_vop_init_reg_table,
> > .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
> > .ctrl = _ctrl_data,
> > @@ -272,6 +273,7 @@ static const struct vop_intr rk3288_vop_intr = {
> >  };
> >
> >  static const struct vop_data rk3288_vop = {
> > +   .id = RK3288_VOP,
> > .init_table = rk3288_init_reg_table,
> > .table_size = ARRAY_SIZE(rk3288_init_reg_table),
> > .intr = _vop_intr,
> > @@ -340,6 +342,7 @@ static const struct vop_reg_data
> rk3399_init_reg_table[] = {
> >  };
> >
> >  static const struct vop_data rk3399_vop_big = {
> > +   .id = RK3399_VOP_BIG,
> > .init_table = rk3399_init_reg_table,
> > .table_size = ARRAY_SIZE(rk3399_init_reg_table),
> > .intr = _vop_intr,
> > @@ -359,6 +362,7 @@ static const struct vop_win_data
> rk3399_vop_lit_win_data[] = {
> >  };
> >
> >  static const struct vop_data rk3399_vop_lit = {
> > +   .id = RK3399_VOP_LIT,
> > .init_table = rk3399_init_reg_table,
> > .table_size = ARRAY_SIZE(rk3399_init_reg_table),
> > .intr = _vop_intr,
> > --
> > 2.8.0.rc3.226.g39d4020
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161103/093a54b4/attachment-0001.html>

[PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Wednesday 02 Nov 2016 18:32:16 Jyri Sarha wrote:
> Add very basic ti-ftp410 HDMI transmitter driver. The only feature
> separating this from a completely dummy bridge is the DDC i2c
> support. However, other HW specific features may be added later when
> needed. For instance there is a set of registers behind i2c if it is
> connected. The implementations is tested against my new tilcdc bridge
> support and works with BeagleBone DVI-D Cape Rev A3. A DT binding
> document is also added.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  .../bindings/display/bridge/ti,tfp410.txt  |  30 
>  drivers/gpu/drm/bridge/Kconfig |   7 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/ti-tfp410.c | 199 ++
>  4 files changed, 237 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt create mode
> 100644 drivers/gpu/drm/bridge/ti-tfp410.c
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file
> mode 100644
> index 000..dc93713
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> @@ -0,0 +1,30 @@
> +TFP410 HDMI/DVI bridge bindings

I'd name the document "TI TFP410 DVI Transmitter". DVI bridge doesn't tell 
whether the device is a receiver or transmitter.

> +Required properties:
> + - compatible: "ti,tfp410"

The device is an I2C slave, it should have a reg property. Given that the chip 
can be used without being controlled through I2C, the reg property should be 
optional. You should document this clearly, and explain how the DT node can be 
instantiated as a child of an I2C controller when the I2C interface is used, 
or in other parts of the device tree otherwise.

> +Optional properties:
> + - ddc-i2c: phandle of an I2C controller used for DDC EDID probing

The TFP410 doesn't handle DDC, this property should be part of the connector 
node.

> +Optional subnodes:
> + - video input: this subnode can contain a video input port node
> +   to connect the bridge to a display controller output (See this
> +   documentation [1]).

You also need an output port for the DVI output. Those two ports should be 
required, not optional.

> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + hdmi-bridge {
> + compatible = "ti,tfp410";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + bridge_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };


> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index bd6acc8..a424e03 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
>   ---help---
> Toshiba TC358767 eDP bridge chip driver.
> 
> +config DRM_TI_TFP410
> + tristate "TI TFP410 DVI/HDMI bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + ---help---
> +   Texas Instruments TFP410 DVI/HDMI Transmitter driver
> +
>  source "drivers/gpu/drm/bridge/analogix/Kconfig"
> 
>  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile
> b/drivers/gpu/drm/bridge/Makefile index 97ed1a5..8b065d9 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> +obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c new file mode 100644
> index 000..b0753d2
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 Texas Instruments
> + * Author: Jyri Sarha 
> + *
> + * 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.
> + *
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct tfp410 {
> + struct drm_bridge   bridge;
> + struct drm_connectorconnector;
> +
> + struct i2c_adapter  *ddc;
> +
> + struct device *dev;
> +};
> +
> +static inline struct tfp410 *
> +drm_bridge_to_tfp410(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct tfp410, bridge);
> +}
> +
> +static inline struct tfp410 *
> 

[PATCH] dma-buf/fence-array: enable_signaling from wq

[Rob Clark]

On Thu, Nov 3, 2016 at 5:41 PM, Chris Wilson  
wrote:
> On Thu, Nov 03, 2016 at 04:31:14PM -0400, Rob Clark wrote:
>> Currently with fence-array, we have a potential deadlock situation.  If we
>> fence_add_callback() on an array-fence, the array-fence's lock is aquired
>> first, and in it's ->enable_signaling() callback, it will install cb's on
>> it's array-member fences, so the array-member's lock is acquired second.
>>
>> But in the signal path, the array-member's lock is acquired first, and the
>> array-fence's lock acquired second.
>
> Could mention that this is only an issue if the same fence->lock
> appeared more than once in the array. Which is possible.

hmm, lockdep will care more about lock classes than lock instances..

>> diff --git a/drivers/dma-buf/dma-fence-array.c 
>> b/drivers/dma-buf/dma-fence-array.c
>> index 67eb7c8..274bbb5 100644
>> --- a/drivers/dma-buf/dma-fence-array.c
>> +++ b/drivers/dma-buf/dma-fence-array.c
>> @@ -43,9 +43,10 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
>>   dma_fence_put(>base);
>>  }
>>
>> -static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
>> +static void enable_signaling_worker(struct work_struct *w)
>>  {
>> - struct dma_fence_array *array = to_dma_fence_array(fence);
>> + struct dma_fence_array *array =
>> + container_of(w, struct dma_fence_array, 
>> enable_signaling_worker);
>>   struct dma_fence_array_cb *cb = (void *)([1]);
>>   unsigned i;
>>
>> @@ -63,11 +64,18 @@ static bool dma_fence_array_enable_signaling(struct 
>> dma_fence *fence)
>>   if (dma_fence_add_callback(array->fences[i], [i].cb,
>>  dma_fence_array_cb_func)) {
>>   dma_fence_put(>base);
>> - if (atomic_dec_and_test(>num_pending))
>> - return false;
>> + if (atomic_dec_and_test(>num_pending)) {
>> + dma_fence_signal(>base);
>> + return;
>> + }
>>   }
>>   }
>> +}
>>
>> +static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
>> +{
>> + struct dma_fence_array *array = to_dma_fence_array(fence);
>> + queue_work(system_unbound_wq, >enable_signaling_worker);
>
> I think you need a dma_fence_get(fence) here with a corresponding put in
> the worker. Sadly I still can't poke a hole in the lockdep warning.

oh, right, extra get/put makes sense.. fwiw it should be easy enough
to trigger with some code that merges a sw-sync fence w/ other
fences..

> What I might suggest is that we try
>
> static bool is_signaled(struct dma_fence *fence)
> {
> if (test_bit(SIGNALED_BIT, >flags))
> return true;
>
> return fence->ops->signaled && fence->ops->signaled(fence);
> }
>
> static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
> {
> struct dma_fence_array *array = to_dma_fence_array(fence);
> int num_pending = atomic_read(>num_pending);
> int i;
>
> for (i = 0; i < array->num_fences; i++)
> if (is_signaled(array->fences[i]) && !--num_pending) {
> atomic_set(>num_pending, 0);
> return false;
> }
>
> dma_fence_get(>base);
> queue_work(system_unbound_wq, >enable_signaling_worker);
> }

hmm, I guess just to try to avoid the wq?

BR,
-R

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre

[Bug 98578] AMDGPU white glitches in some games

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

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

--- Comment #3 from Andy Furniss  ---
(In reply to Nicolai Hähnle from comment #2)
> Hi Lukas, thanks for the report. People often use Google Drive to upload
> traces, that would be helpful.

I recently files a LLVM bug that looks similar(ish) corruption wise (small
squares). If this started recently then maybe it's -

https://llvm.org/bugs/show_bug.cgi?id=30894

-- 
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/20161103/dfad188c/attachment.html>

[Intel-gfx] [PATCH 19/19] drm/atomic: Rename atomic oldnew iterator

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:18PM +0200, Maarten Lankhorst wrote:
> With the old users of for_each_obj_in_state gone, we can rename
> for_each_oldnew_obj_in_state back to that name. It's slightly less
> ugly.
> 
> Signed-off-by: Maarten Lankhorst 

Simple sed/coccinelle job I presume. Assuming the tool works
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 34 
> ++---
>  drivers/gpu/drm/drm_blend.c |  4 ++--
>  drivers/gpu/drm/i915/intel_display.c| 16 +++---
>  drivers/gpu/drm/imx/imx-drm-core.c  |  2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  2 +-
>  drivers/gpu/drm/msm/msm_atomic.c|  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
>  drivers/gpu/drm/vc4/vc4_kms.c   |  2 +-
>  include/drm/drm_atomic.h| 30 +++--
>  9 files changed, 35 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c8aba493fc17..8fb955181641 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -241,7 +241,7 @@ steal_encoder(struct drm_atomic_state *state,
>   struct drm_connector_state *old_connector_state, *new_connector_state;
>   int i;
>  
> - for_each_oldnew_connector_in_state(state, connector, 
> old_connector_state, new_connector_state, i) {
> + for_each_connector_in_state(state, connector, old_connector_state, 
> new_connector_state, i) {
>   struct drm_crtc *encoder_crtc;
>  
>   if (new_connector_state->best_encoder != encoder)
> @@ -482,7 +482,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   struct drm_connector_state *old_connector_state, *new_connector_state;
>   int i, ret;
>  
> - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
>   if (!drm_mode_equal(_crtc_state->mode, 
> _crtc_state->mode)) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode changed\n",
>crtc->base.id, crtc->name);
> @@ -510,7 +510,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> - for_each_oldnew_connector_in_state(state, connector, 
> old_connector_state, new_connector_state, i) {
> + for_each_connector_in_state(state, connector, old_connector_state, 
> new_connector_state, i) {
>   /*
>* This only sets crtc->connectors_changed for routing changes,
>* drivers must set crtc->connectors_changed themselves when
> @@ -529,7 +529,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>* configuration. This must be done before calling mode_fixup in case a
>* crtc only changed its mode but has the same set of connectors.
>*/
> - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
>   bool has_connectors =
>   !!new_crtc_state->connector_mask;
>  
> @@ -685,7 +685,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   int i;
>  
> - for_each_oldnew_connector_in_state(old_state, connector, 
> old_conn_state, new_conn_state, i) {
> + for_each_connector_in_state(old_state, connector, old_conn_state, 
> new_conn_state, i) {
>   const struct drm_encoder_helper_funcs *funcs;
>   struct drm_encoder *encoder;
>  
> @@ -733,7 +733,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   drm_bridge_post_disable(encoder->bridge);
>   }
>  
> - for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + for_each_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, 
> i) {
>   const struct drm_crtc_helper_funcs *funcs;
>  
>   /* Shut down everything that needs a full modeset. */
> @@ -785,7 +785,7 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
> drm_device *dev,
>   int i;
>  
>   /* clear out existing links and update dpms */
> - for_each_oldnew_connector_in_state(old_state, connector, 
> old_conn_state, new_conn_state, i) {
> + for_each_connector_in_state(old_state, connector, old_conn_state, 
> new_conn_state, i) {
>   if (connector->encoder) {
>   WARN_ON(!connector->encoder->crtc);
>  
> @@ -1074,7 +1074,7 @@ bool drm_atomic_helper_framebuffer_changed(struct 
> drm_device *dev,
>   struct drm_plane_state *old_plane_state, *new_plane_state;
>   int i;
>  
> - for_each_oldnew_plane_in_state(old_state, plane, 

[Intel-gfx] [PATCH 15/19] drm/i915: Use new atomic iterator macros in ddi

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:14PM +0200, Maarten Lankhorst wrote:
> Also make the function static, it's only used inside intel_ddi.c
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
>  drivers/gpu/drm/i915/intel_drv.h | 2 --
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 15d47c87def6..0e79c84e14e0 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -740,7 +740,7 @@ intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
>   return ret;
>  }
>  
> -struct intel_encoder *
> +static struct intel_encoder *
>  intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> @@ -753,7 +753,7 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
> *crtc_state)
>  
>   state = crtc_state->base.state;
>  
> - for_each_connector_in_state(state, connector, connector_state, i) {
> + for_each_new_connector_in_state(state, connector, connector_state, i) {
>   if (connector_state->crtc != crtc_state->base.crtc)
>   continue;

Reviewed-by: Ville Syrjälä 

>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8fd16adf069b..588d8af68043 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1156,8 +1156,6 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
> *intel_dp);
>  bool intel_ddi_connector_get_hw_state(struct intel_connector 
> *intel_connector);
>  void intel_ddi_get_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config);
> -struct intel_encoder *
> -intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state);
>  
>  void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
>  void intel_ddi_clock_get(struct intel_encoder *encoder,
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[Bug 98578] AMDGPU white glitches in some games

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

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

--- Comment #2 from Nicolai Hähnle  ---
Hi Lukas, thanks for the report. People often use Google Drive to upload
traces, that would be helpful.

-- 
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/20161103/34e55ccd/attachment.html>

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards

Shashank


On 11/3/2016 6:56 PM, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 06:40:11PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/3/2016 6:32 PM, Ville Syrjälä wrote:
>>> On Thu, Nov 03, 2016 at 12:47:39PM +, Sharma, Shashank wrote:
 Hi Ville,
 (-dri-devel)
 I would appreciate an internal discussion before going to dri-devel. a
>>> Added back. Private discussions are pointless.
>> Noted.
 What did this patch break ?
>>> Intel ddx. It will reject any mode with flags it doesn't know about.
>>> Other ddxen like -ati or -modesetting will also suffer, but potentially
>>> in a different way since they don't even check the flags and instead
>>> just directly stuff them into the randr mode flags, which will result
>>> in an out of spec mode as far randr is concerned.
>> Then its a fault of intel-ddx design. We are adding new flags to
>> indicate aspect ratios, so its obvious that the implementation should be
>> modified to accept new flags.
>> I dont see why you should revert patch for it.
> Rule 1 of kernel development: You simply don't break existing userspace
Again, we are adding something new, for which userspace should be modified.
If the userspace in written in such a way that it wont accept changes, 
its not saleable design.

Even in this case, we should go and extend the userspace (which I am 
ready to do) instead of reverting the patch.
If you still think you should send this revert, I am removing my NACK. 
Pls Go ahead.
 This is exposed in the same way, as the 3D flags.
>>> Not it isn't. We have a client cap for 3D flags.
>>>
 The information is already available in form of flags, all you have to do 
 in userspace is read and print that. Its already being done in Android.
>>> Please stop relying on Android for testing upstream patches. Test with
>>> actual userspace people are using.
>> Please note that android goes through HDMI compliance certification, and
>> several commercial test infrastructures, so
>> that's one of the best infrastructure to test. And when we have common
>> branch for all of Linux flavors, we should consider all.
> You can test with Android as much as you like. That probably won't
> catch ABI breaks and whatnot though since you don't generally just plop
> a new kernel onto an existing Android device.
>
> So you really must test with normal userspace as well. That has a long
> history and so any ABI/behaviour change is actually a big deal.
>

 NACK until we get to the right reason.

 Regards
 Shashank
 -Original Message-
 From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at 
 linux.intel.com]
 Sent: Thursday, November 3, 2016 6:02 PM
 To: dri-devel at lists.freedesktop.org
 Cc: Sharma, Shashank ; Lin; Jia, Lin A 
 ; Sharma, Akashdeep >>> intel.com>; Jim Bride ; Jose Abreu 
 ; Daniel Vetter ; 
 Emil Velikov 
 Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM 
 layer"

 From: Ville Syrjälä 

 This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.

 Adding new mode flags willy nilly breaks existing userspace. We need to 
 coordinate this better, potentially with a new client cap that only 
 exposes the aspect ratio flags when userspace is prepared for them 
 (similar to what we do with stereo 3D modes).

 Cc: Shashank Sharma 
 Cc: Lin, Jia 
 Cc: Akashdeep Sharma 
 Cc: Jim Bride 
 Cc: Jose Abreu 
 Cc: Daniel Vetter 
 Cc: Emil Velikov 
 Cc: Daniel Vetter 
 Signed-off-by: Ville Syrjälä 
 ---
drivers/gpu/drm/drm_modes.c | 12   
 include/uapi/drm/drm_mode.h |  6 --
2 files changed, 18 deletions(-)

 diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c 
 index f64ac86deb84..725faa6409aa 100644
 --- a/drivers/gpu/drm/drm_modes.c
 +++ b/drivers/gpu/drm/drm_modes.c
 @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
 drm_mode_modeinfo *out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
 -  case HDMI_PICTURE_ASPECT_64_27:
 -  out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
 -  break;
 -  case DRM_MODE_PICTURE_ASPECT_256_135:
 -  out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
 -  break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 
 +1574,6 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
 -  case DRM_MODE_FLAG_PIC_AR_64_27:
 -  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
 -

[Intel-gfx] [PATCH 18/19] drm/i915: Use new atomic iterator macros in display code

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:17PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 156 
> ++-
>  1 file changed, 80 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3bd3f6a93c12..d310abace86a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3510,7 +3510,12 @@ __intel_display_resume(struct drm_device *dev,
>   if (!state)
>   return 0;
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + /*
> +  * We've duplicated the state, pointers to the old state are invalid.
> +  *
> +  * Don't attempt to use the old state until we commit the duplicated 
> state.
> +  */
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   /*
>* Force recalculation even if we restore
>* current state. With fast modeset this may not result
> @@ -5078,13 +5083,12 @@ static void intel_post_plane_update(struct 
> intel_crtc_state *old_crtc_state)
>   }
>  }
>  
> -static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
> +static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
> +struct intel_crtc_state *pipe_config)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc_state *pipe_config =
> - to_intel_crtc_state(crtc->base.state);
>   struct drm_atomic_state *old_state = old_crtc_state->base.state;
>   struct drm_plane *primary = crtc->base.primary;
>   struct drm_plane_state *old_pri_state =
> @@ -5186,12 +5190,11 @@ static void intel_encoders_pre_pll_enable(struct 
> drm_crtc *crtc,
> struct intel_crtc_state *crtc_state,
> struct drm_atomic_state *old_state)
>  {
> - struct drm_connector_state *old_conn_state;
> + struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> - struct drm_connector_state *conn_state = conn->state;
> + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(conn_state->best_encoder);
>  
> @@ -5207,12 +5210,11 @@ static void intel_encoders_pre_enable(struct drm_crtc 
> *crtc,
> struct intel_crtc_state *crtc_state,
> struct drm_atomic_state *old_state)
>  {
> - struct drm_connector_state *old_conn_state;
> + struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> - struct drm_connector_state *conn_state = conn->state;
> + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(conn_state->best_encoder);
>  
> @@ -5228,12 +5230,11 @@ static void intel_encoders_enable(struct drm_crtc 
> *crtc,
> struct intel_crtc_state *crtc_state,
> struct drm_atomic_state *old_state)
>  {
> - struct drm_connector_state *old_conn_state;
> + struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> - struct drm_connector_state *conn_state = conn->state;
> + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(conn_state->best_encoder);
>  
> @@ -5253,7 +5254,7 @@ static void intel_encoders_disable(struct drm_crtc 
> *crtc,
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> + for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(old_conn_state->best_encoder);
>  
> @@ -5273,7 +5274,7 @@ static void intel_encoders_post_disable(struct drm_crtc 
> *crtc,
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> + for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(old_conn_state->best_encoder);
>  
> @@ -5293,7 +5294,7 @@ static void 

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards

Shashank


On 11/3/2016 6:39 PM, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 03:04:04PM +0200, Ville Syrjälä wrote:
>> On Thu, Nov 03, 2016 at 03:02:53PM +0200, Ville Syrjälä wrote:
>>> On Thu, Nov 03, 2016 at 12:47:39PM +, Sharma, Shashank wrote:
 Hi Ville,
 (-dri-devel)
 I would appreciate an internal discussion before going to dri-devel. a
>>> Added back. Private discussions are pointless.
>> Now added for reals.
Noted for future.
>>
 What did this patch break ?
>>> Intel ddx. It will reject any mode with flags it doesn't know about.
>>> Other ddxen like -ati or -modesetting will also suffer, but potentially
>>> in a different way since they don't even check the flags and instead
>>> just directly stuff them into the randr mode flags, which will result
>>> in an out of spec mode as far randr is concerned.
We are adding new flags to indicate aspect ratios, so its obvious that 
the implementation should be modified to accept new flags.
I dont see why you should revert patch for it. This is instead option to 
extend the support.
> BTW outside of the userspace issues there were some issues with the way
> the mode matching was being done. Before I realized the userspace breakage
Again, this is not a break, we need to extend the test-setup for new flags.
> I had cooked up a few additonal patch to adjust the mode matching a bit.
> I pushed those to [1] in case anyone wants to take a look, but obviously
> they need to be put on hold a bit until we sort out the userspace part.
>
> [1] git://github.com/vsyrjala/linux.git cea_f_vics
I think we had several rounds of code reviews on this, since months. So 
I don't really see why are we discussing this now.
 This is exposed in the same way, as the 3D flags.
>>> Not it isn't. We have a client cap for 3D flags.
>>>
 The information is already available in form of flags, all you have to do 
 in userspace is read and print that. Its already being done in Android.
>>> Please stop relying on Android for testing upstream patches. Test with
>>> actual userspace people are using.
Please note that android goes through HDMI compliance certification, and 
several commercial test infrastructures, so
that's one of the best infrastructure to test. And when we have common 
branch for all of Linux flavors, we should consider all.
I dont really think how breaking / blocking Android implementation is 
going to help others.
Also, the breaks what you are reporting are with the test tools / 
infrastructures, which is specific to one setup.

Honestly, thats one of the setup which uses aspect ratio in practical 
use cases, so I dont find a reason why not.
>>>
   
 NACK until we get to the right reason.

My nack continues.

 Regards
 Shashank
 -Original Message-
 From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at 
 linux.intel.com]
 Sent: Thursday, November 3, 2016 6:02 PM
 To: dri-devel at lists.freedesktop.org
 Cc: Sharma, Shashank ; Lin; Jia, Lin A 
 ; Sharma, Akashdeep >>> intel.com>; Jim Bride ; Jose Abreu 
 ; Daniel Vetter ; 
 Emil Velikov 
 Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM 
 layer"

 From: Ville Syrjälä 

 This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.

 Adding new mode flags willy nilly breaks existing userspace. We need to 
 coordinate this better, potentially with a new client cap that only 
 exposes the aspect ratio flags when userspace is prepared for them 
 (similar to what we do with stereo 3D modes).

 Cc: Shashank Sharma 
 Cc: Lin, Jia 
 Cc: Akashdeep Sharma 
 Cc: Jim Bride 
 Cc: Jose Abreu 
 Cc: Daniel Vetter 
 Cc: Emil Velikov 
 Cc: Daniel Vetter 
 Signed-off-by: Ville Syrjälä 
 ---
   drivers/gpu/drm/drm_modes.c | 12   
 include/uapi/drm/drm_mode.h |  6 --
   2 files changed, 18 deletions(-)

 diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c 
 index f64ac86deb84..725faa6409aa 100644
 --- a/drivers/gpu/drm/drm_modes.c
 +++ b/drivers/gpu/drm/drm_modes.c
 @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
 drm_mode_modeinfo *out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
 -  case HDMI_PICTURE_ASPECT_64_27:
 -  out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
 -  break;
 -  case DRM_MODE_PICTURE_ASPECT_256_135:
 -  out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
 -  break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 +1574,6 @@ 
 int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;

[Intel-gfx] [PATCH 17/19] drm/i915: Use new atomic iterator macros in wm code

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:16PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2df06b703e3d..163b73b493bf 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3227,7 +3227,7 @@ skl_get_total_relative_data_rate(struct 
> intel_crtc_state *intel_cstate)
>   return 0;
>  
>   /* Calculate and cache data rate for each plane */
> - for_each_plane_in_state(state, plane, pstate, i) {
> + for_each_new_plane_in_state(state, plane, pstate, i) {

Looks like this patch needs a refresh due to my tardiness in reviewing
it.

Also unrelated, but I recently noticed that
skl_get_total_relative_data_rate() doesn't exclude the cursor plane
from the calculation. I'm thinking it should. Adding some Cc:s...

>   id = skl_wm_plane_id(to_intel_plane(plane));
>   intel_plane = to_intel_plane(plane);
>  
> @@ -3364,14 +3364,14 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   alloc_size -= cursor_blocks;
>  
>   /* 1. Allocate the mininum required blocks for each active plane */
> - for_each_plane_in_state(state, plane, pstate, i) {
> + for_each_new_plane_in_state(state, plane, pstate, i) {
>   intel_plane = to_intel_plane(plane);
>   id = skl_wm_plane_id(intel_plane);
>  
>   if (intel_plane->pipe != pipe)
>   continue;
>  
> - if (!to_intel_plane_state(pstate)->base.visible) {
> + if (!pstate->visible) {
>   minimum[id] = 0;
>   y_minimum[id] = 0;
>   continue;
> @@ -3933,7 +3933,7 @@ pipes_modified(struct drm_atomic_state *state)
>   struct drm_crtc_state *cstate;
>   uint32_t i, ret = 0;
>  
> - for_each_crtc_in_state(state, crtc, cstate, i)
> + for_each_new_crtc_in_state(state, crtc, cstate, i)
>   ret |= drm_crtc_mask(crtc);
>  
>   return ret;
> @@ -4048,7 +4048,7 @@ skl_compute_wm(struct drm_atomic_state *state)
>* since any racing commits that want to update them would need to
>* hold _all_ CRTC state mutexes.
>*/
> - for_each_crtc_in_state(state, crtc, cstate, i)
> + for_each_new_crtc_in_state(state, crtc, cstate, i)
>   changed = true;
>   if (!changed)
>   return 0;
> @@ -4070,7 +4070,7 @@ skl_compute_wm(struct drm_atomic_state *state)
>* should allow skl_update_pipe_wm() to return failure in cases where
>* no suitable watermark values can be found.
>*/
> - for_each_crtc_in_state(state, crtc, cstate, i) {
> + for_each_new_crtc_in_state(state, crtc, cstate, i) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_crtc_state *intel_cstate =
>   to_intel_crtc_state(cstate);
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index faa67624e1ed..0028335fc1bb 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>  
>   mutex_lock(>lock);
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   if (fbc->crtc == to_intel_crtc(crtc)) {
>   fbc_crtc_present = true;
>   break;
> @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>* plane. We could go for fancier schemes such as checking the plane
>* size, but this would just affect the few platforms that don't tie FBC
>* to pipe or plane A. */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> + for_each_new_plane_in_state(state, plane, plane_state, i) {
>   struct intel_plane_state *intel_plane_state =
>   to_intel_plane_state(plane_state);
>  
>   if (!intel_plane_state->base.visible)
>   continue;

Unrelated but this thing looks somewhat bogus. FBC is tied to the
primary plane only, so why do we care about the visibility of the other
planes? Adding Paulo to Cc...

>  
> - for_each_crtc_in_state(state, crtc, crtc_state, j) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, j) {

Also, can't this inner loop be replaced with a simple
crtc = plane_state->crtc ?

>   struct intel_crtc_state *intel_crtc_state =
>   to_intel_crtc_state(crtc_state);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[Spice-devel] [drm/qxl 5/6] qxl: Don't notify userspace when monitors config is unchanged

[Emil Velikov]

Hi guys,

On 2 November 2016 at 16:31, Christophe Fergeau  wrote:
> Hey,
>
> On Mon, Oct 31, 2016 at 08:00:09AM -0400, Frediano Ziglio wrote:
>> > diff --git a/drivers/gpu/drm/qxl/qxl_display.c
>> > b/drivers/gpu/drm/qxl/qxl_display.c
>> > index 156b7de..edb90f6 100644
>> > --- a/drivers/gpu/drm/qxl/qxl_display.c
>> > +++ b/drivers/gpu/drm/qxl/qxl_display.c
>> > @@ -57,11 +57,18 @@ static void qxl_alloc_client_monitors_config(struct
>> > qxl_device *qdev, unsigned c
>> > qdev->client_monitors_config->count = count;
>> >  }
>> >
>> > +enum MonitorsConfigCopyStatus {
>> > +   MONITORS_CONFIG_COPIED,
>> > +   MONITORS_CONFIG_UNCHANGED,
>> > +   MONITORS_CONFIG_BAD_CRC,
>> > +};
>> > +
>>
>> I don't remember exactly kernel style, a
>>
>> typedef enum {
>>   MONITORS_CONFIG_COPIED,
>>   MONITORS_CONFIG_UNCHANGED,
>>   MONITORS_CONFIG_BAD_CRC,
>> } MonitorsConfigCopyStatus;
>>
>> could make following code shorter.
>
> A git grep enum in qxl/ returns a dozen results, none of these using
> typedef, I guess I just followed that style.
>
Kernel coding style advises against both typedefs and CamelCase. We do
have a few "offenders" but it's better to not add more.

Ftw when in doubt do search/grep through the document - I don't thinks
there's many people who've read the thing in one go :-)

Thanks
Emil

[Intel-gfx] [PATCH 14/19] drm/mediatek: Use new atomic iterator macros

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:13PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 

Patches 13-14
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index db61aa5f32ef..414e848d8cbf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -50,8 +50,8 @@ static void mtk_atomic_wait_for_fences(struct 
> drm_atomic_state *state)
>   struct drm_plane_state *plane_state;
>   int i;
>  
> - for_each_plane_in_state(state, plane, plane_state, i)
> - mtk_fb_wait(plane->state->fb);
> + for_each_new_plane_in_state(state, plane, plane_state, i)
> + mtk_fb_wait(plane_state->fb);
>  }
>  
>  static void mtk_atomic_complete(struct mtk_drm_private *private,
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH 12/19] drm/msm: Use new atomic iterator macros

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:11PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  4 ++--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  6 +++---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  3 ++-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  4 ++--
>  drivers/gpu/drm/msm/msm_atomic.c  | 16 
>  5 files changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index 571a91ee9607..d18d0a0e0a35 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -113,7 +113,7 @@ static void mdp4_prepare_commit(struct msm_kms *kms, 
> struct drm_atomic_state *st
>   mdp4_enable(mdp4_kms);
>  
>   /* see 119ecb7fd */
> - for_each_crtc_in_state(state, crtc, crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
>   drm_crtc_vblank_get(crtc);
>  }
>  
> @@ -125,7 +125,7 @@ static void mdp4_complete_commit(struct msm_kms *kms, 
> struct drm_atomic_state *s
>   struct drm_crtc_state *crtc_state;
>  
>   /* see 119ecb7fd */
> - for_each_crtc_in_state(state, crtc, crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
>   drm_crtc_vblank_put(crtc);

post-swap, but crtc_state not used in either. So lgtm.

I wonder if you should go all in and try to rename all the foo_state variables
as new_foo_state and old_foo_state to make sure you didn't miss any uses which
might not agree with your new choice if iterator macro? Eg. if in this
case crtc_state was actually used but you failed notice it you would have
just broken something by using the _new_ iterator.

>  
>   mdp4_disable(mdp4_kms);
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index ed7143d35b25..7cfeb0455039 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -82,10 +82,10 @@ static void mdp5_complete_commit(struct msm_kms *kms, 
> struct drm_atomic_state *s
>   int i;
>   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
>   struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *old_state, *new_state;
>  
> - for_each_plane_in_state(state, plane, plane_state, i)
> - mdp5_plane_complete_commit(plane, plane_state);
> + for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i)
> + mdp5_plane_complete_commit(plane, old_state, new_state);
>  
>   mdp5_disable(mdp5_kms);
>  }
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> index 03738927be10..90e80619fc54 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> @@ -198,7 +198,8 @@ void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
>  uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
>  void mdp5_plane_complete_flip(struct drm_plane *plane);
>  void mdp5_plane_complete_commit(struct drm_plane *plane,
> - struct drm_plane_state *state);
> + struct drm_plane_state *old_state,
> + struct drm_plane_state *new_state);
>  enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
>  struct drm_plane *mdp5_plane_init(struct drm_device *dev,
>   enum mdp5_pipe pipe, bool private_plane,
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 951c002b05df..19c44b968f4e 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -859,13 +859,13 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
>  
>  /* called after vsync in thread context */
>  void mdp5_plane_complete_commit(struct drm_plane *plane,
> - struct drm_plane_state *state)
> + struct drm_plane_state *old_state, struct drm_plane_state *new_state)
>  {
>   struct mdp5_kms *mdp5_kms = get_kms(plane);
>   struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
>   enum mdp5_pipe pipe = mdp5_plane->pipe;
>  
> - if (!plane_enabled(plane->state) && mdp5_kms->smp) {
> + if (!plane_enabled(new_state) && mdp5_kms->smp) {
>   DBG("%s: free SMP", mdp5_plane->name);
>   mdp5_smp_release(mdp5_kms->smp, pipe);
>   }

Doesn't look like this guy actually needs the old state. Not sure why it
was getting passed in. The replacement for plane->state looks correct
nonetheless.

> diff --git a/drivers/gpu/drm/msm/msm_atomic.c 
> b/drivers/gpu/drm/msm/msm_atomic.c
> index db193f835298..333c379e6561 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -89,8 +89,8 @@ static void msm_atomic_wait_for_commit_done(struct 
> drm_device *dev,
>   struct msm_kms *kms = priv->kms;
>   int i;
>  
> - 

[Intel-gfx] [PATCH 07/19] drm/atomic: Fix atomic helpers to use the new iterator macros.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:06PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 302 
> +++-
>  1 file changed, 157 insertions(+), 145 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index fcb6e5b55217..c8aba493fc17 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -103,7 +103,7 @@ static int handle_conflicting_encoders(struct 
> drm_atomic_state *state,
>* part of the state. If the same encoder is assigned to multiple
>* connectors bail out.
>*/
> - for_each_connector_in_state(state, connector, conn_state, i) {
> + for_each_new_connector_in_state(state, connector, conn_state, i) {
>   const struct drm_connector_helper_funcs *funcs = 
> connector->helper_private;
>   struct drm_encoder *new_encoder;
>  
> @@ -238,22 +238,22 @@ steal_encoder(struct drm_atomic_state *state,
>  {
>   struct drm_crtc_state *crtc_state;
>   struct drm_connector *connector;
> - struct drm_connector_state *connector_state;
> + struct drm_connector_state *old_connector_state, *new_connector_state;
>   int i;
>  
> - for_each_connector_in_state(state, connector, connector_state, i) {
> + for_each_oldnew_connector_in_state(state, connector, 
> old_connector_state, new_connector_state, i) {
>   struct drm_crtc *encoder_crtc;
>  
> - if (connector_state->best_encoder != encoder)
> + if (new_connector_state->best_encoder != encoder)
>   continue;
>  
> - encoder_crtc = connector->state->crtc;
> + encoder_crtc = old_connector_state->crtc;
>  
>   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
> stealing it\n",
>encoder->base.id, encoder->name,
>encoder_crtc->base.id, encoder_crtc->name);
>  
> - set_best_encoder(state, connector_state, NULL);
> + set_best_encoder(state, new_connector_state, NULL);
>  
>   crtc_state = drm_atomic_get_existing_crtc_state(state, 
> encoder_crtc);
>   crtc_state->connectors_changed = true;
> @@ -265,7 +265,8 @@ steal_encoder(struct drm_atomic_state *state,
>  static int
>  update_connector_routing(struct drm_atomic_state *state,
>struct drm_connector *connector,
> -  struct drm_connector_state *connector_state)
> +  struct drm_connector_state *old_connector_state,
> +  struct drm_connector_state *new_connector_state)
>  {
>   const struct drm_connector_helper_funcs *funcs;
>   struct drm_encoder *new_encoder;
> @@ -275,24 +276,24 @@ update_connector_routing(struct drm_atomic_state *state,
>connector->base.id,
>connector->name);
>  
> - if (connector->state->crtc != connector_state->crtc) {
> - if (connector->state->crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(state, 
> connector->state->crtc);
> + if (old_connector_state->crtc != new_connector_state->crtc) {
> + if (old_connector_state->crtc) {
> + crtc_state = drm_atomic_get_existing_crtc_state(state, 
> old_connector_state->crtc);
>   crtc_state->connectors_changed = true;
>   }
>  
> - if (connector_state->crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(state, 
> connector_state->crtc);
> + if (new_connector_state->crtc) {
> + crtc_state = drm_atomic_get_existing_crtc_state(state, 
> new_connector_state->crtc);
>   crtc_state->connectors_changed = true;
>   }
>   }
>  
> - if (!connector_state->crtc) {
> + if (!new_connector_state->crtc) {
>   DRM_DEBUG_ATOMIC("Disabling [CONNECTOR:%d:%s]\n",
>   connector->base.id,
>   connector->name);
>  
> - set_best_encoder(state, connector_state, NULL);
> + set_best_encoder(state, new_connector_state, NULL);
>  
>   return 0;
>   }
> @@ -301,7 +302,7 @@ update_connector_routing(struct drm_atomic_state *state,
>  
>   if (funcs->atomic_best_encoder)
>   new_encoder = funcs->atomic_best_encoder(connector,
> -  connector_state);
> +  new_connector_state);
>   else if (funcs->best_encoder)
>   new_encoder = funcs->best_encoder(connector);
>   else
> @@ -314,33 +315,33 @@ update_connector_routing(struct drm_atomic_state *state,
>   return -EINVAL;
>   }
>  
> - if 

[PATCH] drm/bridge: analogix_dp: return error if transfer none byte

[Jianqun Xu]

Reference from drm_dp_aux description (about transfer):
Upon success, the implementation should return the number of payload bytes
that were transferred, or a negative error-code on failure. Helpers
propagate errors from the .transfer() function, with the exception of
the -EBUSY error, which causes a transaction to be retried. On a short,
helpers will return -EPROTO to make it simpler to check for failure.

The analogix_dp_transfer will return num_transferred, but if there is none
byte been transferred, the return value will be 0, which means success, we
should return error-code if transfer none byte.

for (retry = 0; retry < 32; retry++) {
err = aux->transfer(aux, );
if (err < 0) {
if (err == -EBUSY)
continue;

goto unlock;
}
}

Cc: zain wang 
Cc: Sean Paul 
Signed-off-by: Jianqun Xu 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cd37ac0..303083a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ)
msg->reply = DP_AUX_NATIVE_REPLY_ACK;

-   return num_transferred;
+   return num_transferred > 0 ? num_transferred : -EBUSY;
 }
-- 
1.9.1

[drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Gerd Hoffmann]

On Do, 2016-11-03 at 12:41 +0100, Christophe Fergeau wrote:
> On Thu, Nov 03, 2016 at 09:53:48AM +0100, Gerd Hoffmann wrote:
> > On Mi, 2016-11-02 at 18:00 +0100, Christophe Fergeau wrote:
> > > The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
> > > the resolutions we are going to present to user-space are going to be
> > > rounded down to a multiple of 8. In the QXL arbitrary resolution case,
> > > this is not useful.
> > > This commit forces the actual width/height that was requested by the
> > > client in the drm_display_mode structure rather than keeping the
> > > rounded version.
> > 
> > Hmm, not sure this is a good idea.  There are probably reasons why
> > drm_cvt_mode is rounding down ...
> 
> Yeah, I'm sure there are reasons, but I don't know what they are.
> drm_cvt_mode seems to be calculating various frequencies and timings
> related to refreshing real world monitors, and this seems to be defined
> by some VESA standard. Maybe the rounding down is because the real-world
> monitors or VESA require it.

No worries here, we are in the virtual world, it for sure wouldn't break
monitors ;)

> Or maybe other parts of the
> kernel/userspace rely on this rounding down.

This is where I suspect we could run in trouble.  Odd resolutions simply
don't happen on physical hardware, all usual resolutions are a multiple
of 8, most of them are even a multiple of 16.

Various image/video formats use 16x16 blocks.
The qemu vnc server operates on 16x16 blocks too (and we had bugs in the
past with odd resolutions).

Also scanlines and cachelines align nicely if you don't use odd
resolutions.

> I unfortunately don't know
> :(

I don't have definitive answers too, just a gut feeling that this might
cause trouble.

Maybe we should add a module option for this?  So there is an easy
(as-in: doesn't require a kernel rebuild) way out in case it causes
trouble in certain setups?

cheers,
  Gerd

[PATCH] drm/amd/powerplay: return false instead of -EINVAL

[Andrew Shadura]

On 03/11/16 17:39, Deucher, Alexander wrote:
>> Returning -EINVAL from a bool-returning function
>> phm_check_smc_update_required_for_display_configuration has an
>> unexpected
>> effect of returning true, which is probably not what was intended.
>> Replace -EINVAL by false.
>>
>> The only place this function is called from is
>> psm_adjust_power_state_dynamic in
>> drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:
>>
>>  if (!equal ||
>> phm_check_smc_update_required_for_display_configuration(hwmgr)) {
>>  phm_apply_state_adjust_rules(hwmgr, requested,
>> pcurrent);
>>  phm_set_power_state(hwmgr, >hardware,
>> >hardware);
>>  hwmgr->current_ps = requested;
>>  }
>>
>> It seems to expect a boolean value here.
>>
>> This issue has been found using the following Coccinelle semantic patch
>> written by Peter Senna Tschudin:
>> 
>> @@
>> identifier f;
>> constant C;
>> typedef bool;
>> @@
>> bool f (...){
>> <+...
>> * return -C;
>> ...+>
>> }
>> 
>>
>> Signed-off-by: Andrew Shadura 
> 
> Reviewed-by: Alex Deucher 
> 
> I'll pick this up shortly. Thanks!

Great, thanks! I wonder who should I prod for this one:
https://patchwork.kernel.org/patch/7206081/

-- 
Cheers,
  Andrew

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

[PATCH] drm/msm: Fix error handling crashes seen when VRAM allocation fails

[Archit Taneja]

If VRAM allocation fails, the error handling path crashes in
msm_drm_uninit(). The following changes are made to fix this:

msm_gem_shrinker_cleanup() is fixed to unregister the shrinker only
if it was init-ed in the first place.

Before calling kms->funcs->destroy(), we check if kms->funcs is also
non-NULL. This is needed for MDP5, since during msm_drm_int(), priv->kms
becomes non-NULL early, but msm_kms_init() is called on it only later
in mdp5_kms_init().

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_drv.c  | 2 +-
 drivers/gpu/drm/msm/msm_gem_shrinker.c | 7 +--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index fb5c0b0..46568fc 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -228,7 +228,7 @@ static int msm_drm_uninit(struct device *dev)
flush_workqueue(priv->atomic_wq);
destroy_workqueue(priv->atomic_wq);

-   if (kms)
+   if (kms && kms->funcs)
kms->funcs->destroy(kms);

if (gpu) {
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c 
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 283d284..192b2d3 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -163,6 +163,9 @@ void msm_gem_shrinker_init(struct drm_device *dev)
 void msm_gem_shrinker_cleanup(struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
-   WARN_ON(unregister_vmap_purge_notifier(>vmap_notifier));
-   unregister_shrinker(>shrinker);
+
+   if (priv->shrinker.nr_deferred) {
+   WARN_ON(unregister_vmap_purge_notifier(>vmap_notifier));
+   unregister_shrinker(>shrinker);
+   }
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[Intel-gfx] [PATCH 06/19] drm/atomic: Use new atomic iterator macros.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:05PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1915ec44f7eb..6672ea93ee73 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1369,7 +1369,7 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>  
>   DRM_DEBUG_ATOMIC("checking %p\n", state);
>  
> - for_each_plane_in_state(state, plane, plane_state, i) {
> + for_each_new_plane_in_state(state, plane, plane_state, i) {
>   ret = drm_atomic_plane_check(plane, plane_state);
>   if (ret) {
>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic core check 
> failed\n",
> @@ -1378,7 +1378,7 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   ret = drm_atomic_crtc_check(crtc, crtc_state);
>   if (ret) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] atomic core check 
> failed\n",
> @@ -1391,7 +1391,7 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   ret = config->funcs->atomic_check(state->dev, state);
>  
>   if (!state->allow_modeset) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   if (drm_atomic_crtc_needs_modeset(crtc_state)) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requires full 
> modeset\n",
>crtc->base.id, crtc->name);

All part of the check phase. Check.

> @@ -1732,7 +1732,7 @@ retry:
>   }
>  
>   if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   struct drm_pending_vblank_event *e;
>  
>   e = create_vblank_event(dev, file_priv, NULL,
> @@ -1768,7 +1768,7 @@ out:
>* for TEST_ONLY too.
>*/
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   if (!crtc_state->event)
>   continue;

This latter one runs after the commit, but since it's only executed when
the check/commit failed, we wouldn't have swapped the state yet.

Reviewed-by: Ville Syrjälä 

>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH 05/19] drm/atomic: Make add_affected_connectors look at crtc_state.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:04PM +0200, Maarten Lankhorst wrote:
> This kills another dereference of connector->state. connector_mask
> holds all unchanged connectors at least and any changed connectors
> are already in state anyway.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 120775fcfb70..1915ec44f7eb 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1230,8 +1230,13 @@ drm_atomic_add_affected_connectors(struct 
> drm_atomic_state *state,
>   struct drm_mode_config *config = >dev->mode_config;
>   struct drm_connector *connector;
>   struct drm_connector_state *conn_state;
> + struct drm_crtc_state *crtc_state;
>   int ret;
>  
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
>   ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
>   if (ret)
>   return ret;
> @@ -1240,11 +1245,11 @@ drm_atomic_add_affected_connectors(struct 
> drm_atomic_state *state,
>crtc->base.id, crtc->name, state);
>  
>   /*
> -  * Changed connectors are already in @state, so only need to look at the
> -  * current configuration.
> +  * Changed connectors are already in @state, so only need to look
> +  * at the connector_mask in crtc_state.
>*/
>   drm_for_each_connector(connector, state->dev) {
> - if (connector->state->crtc != crtc)
> + if (!(crtc_state->connector_mask & (1 << 
> drm_connector_index(connector
>   continue;

So this being the new crtc state, connector_mask will include all newly enabled
connectors (these will have been already added to the top level state), and
also any connector that was already enabled and isn't getting disabled (these
are the ones we need to explicitly add to the top level state here).

/me wishes the top level state would be renamed to drm_atomic_transaction or 
something...

Any connector that is getting disabled will already have been added to
the top level state as well, so them not being included in the new crtc
state's connectors_mask is fine.

Reviewed-by: Ville Syrjälä 

>  
>   conn_state = drm_atomic_get_connector_state(state, connector);
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

[PATCH 04/19] drm/blend: Use new atomic iterator macros.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:03PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 

Patches 02-04 looks sane to me, so for them
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_blend.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 85172a977bf3..70c03eb032fc 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -367,27 +367,27 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
> struct drm_atomic_state *state)
>  {
>   struct drm_crtc *crtc;
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *old_plane_state, *new_plane_state;
>   int i, ret = 0;
>  
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - crtc = plane_state->crtc;
> + for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
> new_plane_state, i) {
> + crtc = new_plane_state->crtc;
>   if (!crtc)
>   continue;
> - if (plane->state->zpos != plane_state->zpos) {
> - crtc_state =
> + if (old_plane_state->zpos != new_plane_state->zpos) {
> + new_crtc_state =
>   drm_atomic_get_existing_crtc_state(state, crtc);
> - crtc_state->zpos_changed = true;
> + new_crtc_state->zpos_changed = true;
>   }
>   }
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (crtc_state->plane_mask != crtc->state->plane_mask ||
> - crtc_state->zpos_changed) {
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + if (old_crtc_state->plane_mask != new_crtc_state->plane_mask ||
> + new_crtc_state->zpos_changed) {
>   ret = drm_atomic_helper_crtc_normalize_zpos(crtc,
> - crtc_state);
> + 
> new_crtc_state);
>   if (ret)
>   return ret;
>   }
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[Bug 98578] AMDGPU white glitches in some games

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

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

--- Comment #1 from Lukas Jirkovsky  ---
Created attachment 127733
  --> https://bugs.freedesktop.org/attachment.cgi?id=127733=edit
glxinfo

-- 
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/20161103/20a0c21e/attachment.html>

[Bug 98578] AMDGPU white glitches in some games

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

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

Lukas Jirkovsky  changed:

   What|Removed |Added

   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
  Component|Drivers/Vulkan/radeon   |Drivers/Gallium/radeonsi
 QA Contact|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org

-- 
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/20161103/bd35f26d/attachment.html>

linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Liviu Dudau]

On Tue, Oct 25, 2016 at 11:20:44AM +1100, Stephen Rothwell wrote:
> Hi Liviu,

Hi Stephen,

> 
> Today's linux-next merge of the mali-dp tree got a conflict in:
> 
>   drivers/gpu/drm/arm/malidp_planes.c
> 
> between commit:
> 
>   ea0e1ce20f73 ("drm/arm: Use per-plane rotation property")
> 
> from the drm-misc tree and commit:
> 
>   9ebb89762c30 ("drm: mali-dp: Refactor plane initialisation")
> 
> from the mali-dp tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Sorry for delay in answering, I was on holiday.

I have revamped the mali-dp tree and rebased it on the newer
version of drm-next (which includes the drm-misc change) and pushed the
updated patch in my tree.

Best regards,
Liviu


> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/arm/malidp_planes.c
> index abaca03b9d36,9020c0d8399c..
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@@ -254,23 -284,33 +284,30 @@@ int malidp_de_planes_init(struct drm_de
>   if (ret < 0)
>   goto cleanup;
>   
> + drm_plane_helper_add(>base,
> +  _de_plane_helper_funcs);
> + plane->hwdev = malidp->dev;
> + plane->layer = >layers[i];
> + 
> + /* Skip the features which the SMART layer doesn't have */
> + if (id == DE_SMART)
> + continue;
> + 
>  -if (!drm->mode_config.rotation_property) {
>  +/* SMART layer can't be rotated */
>  +if (id != DE_SMART) {
>   unsigned long flags = DRM_ROTATE_0 |
> DRM_ROTATE_90 |
> DRM_ROTATE_180 |
> DRM_ROTATE_270 |
> DRM_REFLECT_X |
> DRM_REFLECT_Y;
>  -drm->mode_config.rotation_property =
>  -drm_mode_create_rotation_property(drm, flags);
>  +drm_plane_create_rotation_property(>base,
>  +   DRM_ROTATE_0,
>  +   flags);
>   }
>   
> - drm_plane_helper_add(>base,
> -  _de_plane_helper_funcs);
> - plane->hwdev = malidp->dev;
> - plane->layer = >layers[i];
>  -if (drm->mode_config.rotation_property)
>  -drm_object_attach_property(>base.base,
>  -   
> drm->mode_config.rotation_property,
>  -   DRM_ROTATE_0);
>  -
> + malidp_hw_write(malidp->dev, MALIDP_ALPHA_LUT,
> + plane->layer->base + MALIDP_LAYER_COMPOSE);
>   }
>   
>   kfree(formats);
> 

-- 

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

[Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 09:28:46AM +0100, Maarten Lankhorst wrote:
> Op 01-11-16 om 14:41 schreef Ville Syrjälä:
> > On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
> >> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
> >>> On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
>  Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
>  replace the old for_each_xxx_in_state ones. This is useful for >1 flip
>  depth and getting rid of all xxx->state dereferences.
> 
>  Signed-off-by: Maarten Lankhorst 
>  ---
>   drivers/gpu/drm/drm_atomic.c |  6 +++
>   drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
>   drivers/gpu/drm/i915/intel_display.c | 11 ++---
>   include/drm/drm_atomic.h | 81 
>  ++--
>   include/drm/drm_atomic_helper.h  |  3 ++
>   5 files changed, 142 insertions(+), 11 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>  index 5dd70540219c..120775fcfb70 100644
>  --- a/drivers/gpu/drm/drm_atomic.c
>  +++ b/drivers/gpu/drm/drm_atomic.c
>  @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state 
>  *state,
>   return ERR_PTR(-ENOMEM);
>   
>   state->crtcs[index].state = crtc_state;
>  +state->crtcs[index].old_state = crtc->state;
>  +state->crtcs[index].new_state = crtc_state;
>   state->crtcs[index].ptr = crtc;
>   crtc_state->state = state;
>   
>  @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
>  *state,
>   
>   state->planes[index].state = plane_state;
>   state->planes[index].ptr = plane;
>  +state->planes[index].old_state = plane->state;
>  +state->planes[index].new_state = plane_state;
>   plane_state->state = state;
>   
>   DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
>  @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct 
>  drm_atomic_state *state,
>   
>   drm_connector_reference(connector);
>   state->connectors[index].state = connector_state;
>  +state->connectors[index].old_state = connector->state;
>  +state->connectors[index].new_state = connector_state;
>   state->connectors[index].ptr = connector;
>   connector_state->state = state;
>   
>  diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>  b/drivers/gpu/drm/drm_atomic_helper.c
>  index 07b432f43b98..fcb6e5b55217 100644
>  --- a/drivers/gpu/drm/drm_atomic_helper.c
>  +++ b/drivers/gpu/drm/drm_atomic_helper.c
>  @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
>    *
>    * See also:
>    * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
>  - * drm_atomic_helper_resume()
>  + * drm_atomic_helper_resume(), 
>  drm_atomic_helper_commit_duplicated_state()
>    */
>   struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device 
>  *dev)
>   {
>  @@ -2536,6 +2536,52 @@ unlock:
>   EXPORT_SYMBOL(drm_atomic_helper_suspend);
>   
>   /**
>  + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
>  + * @state: duplicated atomic state to commit
>  + * @ctx: pointer to acquire_ctx to use for commit.
>  + * @nonblock: commit the state non-blocking.
>  + *
>  + * The state returned by drm_atomic_helper_duplicate_state() and
>  + * drm_atomic_helper_suspend() is partially invalid, and needs to
>  + * be fixed up before commit.
> >>> So the old_state pointers are potentially invalid because whatever->state
> >>> may have changed since we duplicated the state?
> >> Yes when you use drm_atomic_helper_duplicate_state, and commit a different 
> >> state before committing the duplicated state.
> >> This only happens during suspend/resume and gpu reset.
> > Should we maybe have something like drm_atomic_refresh_old_state(state)?
> > Would allow the caller then to check something in the old vs. new state
> > before committing?
> 
> iirc that was the first approach I took, but then you shouldn't do anything 
> with a duplicated state after
> creating a except commit it, so creating a commit_duplicated_state should be 
> enough.
> 
> Can you think of any case where you do the following?
> 
> Duplicate state
> commit different state
> Look at duplicated state, tinker with it, commit it.

Not really. Oh, and we do still run the thing through the check phase
when we commit it, don't we? That sounds like it should let the driver
do whatever it needs to do.

So my only other concern is just the 'bool nonblock' parameter. It's a
bit funny looking that we pass that in, then branch off to the nonblocking
vs. blocking commits, 

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Thu, Nov 3, 2016 at 2:49 PM, Ville Syrjälä
 wrote:
>> If you still think you should send this revert, I am removing my NACK.
>> Pls Go ahead.
>
> The other option is to not revert and instead slap a fix on top. But
> that would have to be done reasonably quickly so that the thing is
> ready in time for 4.10. We're closing in on 4.9-rc4 now so I guess
> we should still have a few weeks to fix things up. Whether that's
> enough I don't know. If not, then we should revert.

1 week and then revert is the guideline. Please don't bend the rules
for regressions all the time, it makes things painful for everyone
else.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Thu, Nov 3, 2016 at 1:47 PM, Sharma, Shashank
 wrote:
> Hi Ville,
> (-dri-devel)
> I would appreciate an internal discussion before going to dri-devel.

Nack on internal discssion. We do development in the open.

> What did this patch break ?
> This is exposed in the same way, as the 3D flags.
> The information is already available in form of flags, all you have to do in 
> userspace is read and print that. Its already being done in Android.

Yeah, the patch is missing details on the bug report and how it falls
apart, but if that's added revert might be the appropriate thing to do
here. Maintainer-ack on the revert if that crucial information is
added.
-Daniel

> NACK until we get to the right reason.
>
> Regards
> Shashank
> -Original Message-
> From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at 
> linux.intel.com]
> Sent: Thursday, November 3, 2016 6:02 PM
> To: dri-devel at lists.freedesktop.org
> Cc: Sharma, Shashank ; Lin; Jia, Lin A 
> ; Sharma, Akashdeep ; 
> Jim Bride ; Jose Abreu  synopsys.com>; Daniel Vetter ; Emil Velikov 
> 
> Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM 
> layer"
>
> From: Ville Syrjälä 
>
> This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
>
> Adding new mode flags willy nilly breaks existing userspace. We need to 
> coordinate this better, potentially with a new client cap that only exposes 
> the aspect ratio flags when userspace is prepared for them (similar to what 
> we do with stereo 3D modes).
>
> Cc: Shashank Sharma 
> Cc: Lin, Jia 
> Cc: Akashdeep Sharma 
> Cc: Jim Bride 
> Cc: Jose Abreu 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_modes.c | 12   include/uapi/drm/drm_mode.h | 
>  6 --
>  2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 
> f64ac86deb84..725faa6409aa 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
> case HDMI_PICTURE_ASPECT_16_9:
> out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> break;
> -   case HDMI_PICTURE_ASPECT_64_27:
> -   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> -   break;
> -   case DRM_MODE_PICTURE_ASPECT_256_135:
> -   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> -   break;
> case HDMI_PICTURE_ASPECT_RESERVED:
> default:
> out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 +1574,6 
> @@ int drm_mode_convert_umode(struct drm_display_mode *out,
> case DRM_MODE_FLAG_PIC_AR_16_9:
> out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> break;
> -   case DRM_MODE_FLAG_PIC_AR_64_27:
> -   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> -   break;
> -   case DRM_MODE_FLAG_PIC_AR_256_135:
> -   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> -   break;
> default:
> out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> break;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 
> 084b50a02dc5..5c142b1387ac 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -81,8 +81,6 @@ extern "C" {
>  #define DRM_MODE_PICTURE_ASPECT_NONE   0
>  #define DRM_MODE_PICTURE_ASPECT_4_31
>  #define DRM_MODE_PICTURE_ASPECT_16_9   2
> -#define DRM_MODE_PICTURE_ASPECT_64_27  3
> -#define DRM_MODE_PICTURE_ASPECT_256_1354
>
>  /* Aspect ratio flag bitmask (4 bits 22:19) */
>  #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
> @@ -92,10 +90,6 @@ extern "C" {
> (DRM_MODE_PICTURE_ASPECT_4_3<<19)
>  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
> (DRM_MODE_PICTURE_ASPECT_16_9<<19)
> -#define  DRM_MODE_FLAG_PIC_AR_64_27 \
> -   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
> -#define  DRM_MODE_FLAG_PIC_AR_256_135 \
> -   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
>
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> --
> 2.7.4
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: move check for min/max width/height for atomic drivers

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 10:14:20AM -0400, Rob Clark wrote:
> On Thu, Nov 3, 2016 at 10:12 AM, Ville Syrjälä
>  wrote:
> > On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
> >> drm-hwc + android tries to create an fb for the wallpaper layer, which
> >> is larger than the screen resolution, and potentially larger than
> >> mode_config->max_{width,height}.  But the plane src_w/src_h is within
> >> the max limits, so it is something the hardware can otherwise do.
> >>
> >> For atomic drivers, defer the check to drm_atomic_plane_check().
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  drivers/gpu/drm/drm_atomic.c | 17 +
> >>  drivers/gpu/drm/drm_crtc.c   | 26 +-
> >>  2 files changed, 34 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 34edd4f..fb0f07ce 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> >> +++ b/drivers/gpu/drm/drm_atomic.c
> >> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state *state,
> >>  static int drm_atomic_plane_check(struct drm_plane *plane,
> >>   struct drm_plane_state *state)
> >>  {
> >> + struct drm_mode_config *config = >dev->mode_config;
> >>   unsigned int fb_width, fb_height;
> >> + unsigned int min_width, max_width, min_height, max_height;
> >>   int ret;
> >>
> >>   /* either *both* CRTC and FB must be set, or neither */
> >> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct drm_plane 
> >> *plane,
> >>   return -ENOSPC;
> >>   }
> >>
> >> + min_width = config->min_width << 16;
> >> + max_width = config->max_width << 16;
> >> + min_height = config->min_height << 16;
> >> + max_height = config->max_height << 16;
> >> +
> >> + /* Make sure source dimensions are within bounds. */
> >> + if (min_width > state->src_w || state->src_w > max_width ||
> >> + min_height > state->src_h || state->src_h > max_height) {
> >> + DRM_DEBUG_ATOMIC("Invalid source size "
> >> +  "%u.%06ux%u.%06u\n",
> >> +  state->src_w >> 16, ((state->src_w & 
> >> 0x) * 15625) >> 10,
> >> +  state->src_h >> 16, ((state->src_h & 
> >> 0x) * 15625) >> 10);
> >> + return -ERANGE;
> >> + }
> >> +
> >>   if (plane_switching_crtc(state->state, plane, state)) {
> >>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
> >>plane->base.id, plane->name);
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index b4b973f..7294bde 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device *dev,
> >>   return ERR_PTR(-EINVAL);
> >>   }
> >>
> >> - if ((config->min_width > r->width) || (r->width > 
> >> config->max_width)) {
> >> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && 
> >> <= %d\n",
> >> -   r->width, config->min_width, config->max_width);
> >> - return ERR_PTR(-EINVAL);
> >> - }
> >> - if ((config->min_height > r->height) || (r->height > 
> >> config->max_height)) {
> >> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && 
> >> <= %d\n",
> >> -   r->height, config->min_height, config->max_height);
> >> - return ERR_PTR(-EINVAL);
> >> + /* for atomic drivers, we check the src dimensions in
> >> +  * drm_atomic_plane_check().. allow creation of a fb
> >> +  * that is larger than what can be scanned out, as
> >> +  * long as userspace doesn't try to scanout a portion
> >> +  * of the fb that is too large.
> >> +  */
> >> + if (!file_priv->atomic) {
> >> + if ((config->min_width > r->width) || (r->width > 
> >> config->max_width)) {
> >> + DRM_DEBUG_KMS("bad framebuffer width %d, should be 
> >> >= %d && <= %d\n",
> >> +   r->width, config->min_width, 
> >> config->max_width);
> >> + return ERR_PTR(-EINVAL);
> >> + }
> >> + if ((config->min_height > r->height) || (r->height > 
> >> config->max_height)) {
> >> + DRM_DEBUG_KMS("bad framebuffer height %d, should be 
> >> >= %d && <= %d\n",
> >> +   r->height, config->min_height, 
> >> config->max_height);
> >> + return ERR_PTR(-EINVAL);
> >> + }
> >
> > So why not just bump max_foo in your driver?
> >
> > Removing the restriction from the core seems likely to break some
> > drivers as they would now have to check the fb dimensions themselves.
> 
> that is why I did it only for atomic drivers, so we could rely on the
> checking in drm_atomic_plane_check()..

That's not used to check the 

[PATCH] drm/amd/powerplay: return false instead of -EINVAL

[Deucher, Alexander]

> -Original Message-
> From: Andrew Shadura [mailto:andrew.shadura at collabora.co.uk]
> Sent: Thursday, November 03, 2016 12:42 PM
> To: Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
> devel at lists.freedesktop.org; Koenig, Christian; David Airlie
> Cc: Zhu, Rex; Jammy Zhou
> Subject: Re: [PATCH] drm/amd/powerplay: return false instead of -EINVAL
> 
> On 03/11/16 17:39, Deucher, Alexander wrote:
> >> Returning -EINVAL from a bool-returning function
> >> phm_check_smc_update_required_for_display_configuration has an
> >> unexpected
> >> effect of returning true, which is probably not what was intended.
> >> Replace -EINVAL by false.
> >>
> >> The only place this function is called from is
> >> psm_adjust_power_state_dynamic in
> >> drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:
> >>
> >>if (!equal ||
> >> phm_check_smc_update_required_for_display_configuration(hwmgr)) {
> >>phm_apply_state_adjust_rules(hwmgr, requested,
> >> pcurrent);
> >>phm_set_power_state(hwmgr, >hardware,
> >> >hardware);
> >>hwmgr->current_ps = requested;
> >>}
> >>
> >> It seems to expect a boolean value here.
> >>
> >> This issue has been found using the following Coccinelle semantic patch
> >> written by Peter Senna Tschudin:
> >> 
> >> @@
> >> identifier f;
> >> constant C;
> >> typedef bool;
> >> @@
> >> bool f (...){
> >> <+...
> >> * return -C;
> >> ...+>
> >> }
> >> 
> >>
> >> Signed-off-by: Andrew Shadura 
> >
> > Reviewed-by: Alex Deucher 
> >
> > I'll pick this up shortly. Thanks!
> 
> Great, thanks! I wonder who should I prod for this one:
> https://patchwork.kernel.org/patch/7206081/

PowerPC developers?

Alex

> 
> --
> Cheers,
>   Andrew

[PATCH] drm/amd/powerplay: return false instead of -EINVAL

[Deucher, Alexander]

> -Original Message-
> From: Andrew Shadura [mailto:andrew.shadura at collabora.co.uk]
> Sent: Thursday, November 03, 2016 6:09 AM
> To: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; 
> Deucher,
> Alexander; Koenig, Christian; David Airlie
> Cc: Zhu, Rex; Jammy Zhou
> Subject: [PATCH] drm/amd/powerplay: return false instead of -EINVAL
> 
> Returning -EINVAL from a bool-returning function
> phm_check_smc_update_required_for_display_configuration has an
> unexpected
> effect of returning true, which is probably not what was intended.
> Replace -EINVAL by false.
> 
> The only place this function is called from is
> psm_adjust_power_state_dynamic in
> drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:
> 
>   if (!equal ||
> phm_check_smc_update_required_for_display_configuration(hwmgr)) {
>   phm_apply_state_adjust_rules(hwmgr, requested,
> pcurrent);
>   phm_set_power_state(hwmgr, >hardware,
> >hardware);
>   hwmgr->current_ps = requested;
>   }
> 
> It seems to expect a boolean value here.
> 
> This issue has been found using the following Coccinelle semantic patch
> written by Peter Senna Tschudin:
> 
> @@
> identifier f;
> constant C;
> typedef bool;
> @@
> bool f (...){
> <+...
> * return -C;
> ...+>
> }
> 
> 
> Signed-off-by: Andrew Shadura 

Reviewed-by: Alex Deucher 

I'll pick this up shortly. Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> index 789f98a..82038b08 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
> @@ -306,7 +306,7 @@ bool
> phm_check_smc_update_required_for_display_configuration(struct
> pp_hwmgr *hw
>   PHM_FUNC_CHECK(hwmgr);
> 
>   if (hwmgr->hwmgr_func-
> >check_smc_update_required_for_display_configuration == NULL)
> - return -EINVAL;
> + return false;
> 
>   return hwmgr->hwmgr_func-
> >check_smc_update_required_for_display_configuration(hwmgr);
>  }
> --
> 2.7.4
> 

[PATCH] dma-buf/fence-array: enable_signaling from wq

[Rob Clark]

Currently with fence-array, we have a potential deadlock situation.  If we
fence_add_callback() on an array-fence, the array-fence's lock is aquired
first, and in it's ->enable_signaling() callback, it will install cb's on
it's array-member fences, so the array-member's lock is acquired second.

But in the signal path, the array-member's lock is acquired first, and the
array-fence's lock acquired second.

To solve that, punt adding the callbacks on the array member fences to a
worker.

lockdep splat:

 ==
[ INFO: possible circular locking dependency detected ]
4.7.0-rc7+ #489 Not tainted
---
surfaceflinger/2034 is trying to acquire lock:
 (&(>lock)->rlock){..}, at: [] 
fence_signal+0x5c/0xf8

but task is already holding lock:
 (&(>child_list_lock)->rlock){..}, at: [] 
sw_sync_ioctl+0x228/0x3b0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&(>child_list_lock)->rlock){..}:
   [] __lock_acquire+0x173c/0x18d8
   [] lock_acquire+0x4c/0x68
   [] _raw_spin_lock_irqsave+0x54/0x70
   [] fence_add_callback+0x3c/0x100
   [] fence_array_enable_signaling+0x80/0x170
   [] fence_add_callback+0xb8/0x100
   [] sync_file_poll+0xd4/0xf0
   [] do_sys_poll+0x220/0x438
   [] SyS_ppoll+0x1b0/0x1d8
   [] el0_svc_naked+0x24/0x28

-> #0 (&(>lock)->rlock){..}:
   [] print_circular_bug+0x80/0x2e0
   [] __lock_acquire+0x17c4/0x18d8
   [] lock_acquire+0x4c/0x68
   [] _raw_spin_lock_irqsave+0x54/0x70
   [] fence_signal+0x5c/0xf8
   [] fence_array_cb_func+0x78/0x88
   [] fence_signal_locked+0x80/0xe0
   [] sw_sync_ioctl+0x2f8/0x3b0
   [] do_vfs_ioctl+0xa4/0x790
   [] SyS_ioctl+0x8c/0xa0
   [] el0_svc_naked+0x24/0x28

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(&(>child_list_lock)->rlock);
   lock(&(>lock)->rlock);
   lock(&(>child_list_lock)->rlock);
  lock(&(>lock)->rlock);

 *** DEADLOCK ***

1 lock held by surfaceflinger/2034:
 #0:  (&(>child_list_lock)->rlock){..}, at: [] 
sw_sync_ioctl+0x228/0x3b0

Signed-off-by: Rob Clark 
---
 drivers/dma-buf/dma-fence-array.c | 18 ++
 include/linux/dma-fence-array.h   |  4 
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 67eb7c8..274bbb5 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -43,9 +43,10 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
dma_fence_put(>base);
 }

-static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
+static void enable_signaling_worker(struct work_struct *w)
 {
-   struct dma_fence_array *array = to_dma_fence_array(fence);
+   struct dma_fence_array *array =
+   container_of(w, struct dma_fence_array, 
enable_signaling_worker);
struct dma_fence_array_cb *cb = (void *)([1]);
unsigned i;

@@ -63,11 +64,18 @@ static bool dma_fence_array_enable_signaling(struct 
dma_fence *fence)
if (dma_fence_add_callback(array->fences[i], [i].cb,
   dma_fence_array_cb_func)) {
dma_fence_put(>base);
-   if (atomic_dec_and_test(>num_pending))
-   return false;
+   if (atomic_dec_and_test(>num_pending)) {
+   dma_fence_signal(>base);
+   return;
+   }
}
}
+}

+static bool dma_fence_array_enable_signaling(struct dma_fence *fence)
+{
+   struct dma_fence_array *array = to_dma_fence_array(fence);
+   queue_work(system_unbound_wq, >enable_signaling_worker);
return true;
 }

@@ -141,6 +149,8 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
array->fences = fences;

+   INIT_WORK(>enable_signaling_worker, enable_signaling_worker);
+
return array;
 }
 EXPORT_SYMBOL(dma_fence_array_create);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 5900945..f48e8f4 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -35,6 +35,8 @@ struct dma_fence_array_cb {
 /**
  * struct dma_fence_array - fence to represent an array of fences
  * @base: fence base class
+ * @enable_signaling_worker: _struct for deferring enable_signaling
+ *to context not holding fence->lock
  * @lock: spinlock for fence handling
  * @num_fences: number of fences in the array
  * @num_pending: fences in the array still pending
@@ -43,6 +45,8 @@ struct 

[Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[Chris Wilson]

On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote:
> On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote:
> > On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote:
> > > 
> > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> > > > 
> > > > 
> > > > Weine's investigation on benchmarking the suspend/resume process pointed
> > > > out a lot of the time in suspend/resume is being spent reprobing. While
> > > > the reprobing process is a lengthy one for good reason, we don't need to
> > > > hold up the entire suspend/resume process while we wait for it to
> > > > finish. Luckily as it turns out, we already trigger a full connector
> > > > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> > > > i915_drm_resume() entirely.
> > > > 
> > > > This won't lead to less time spent resuming just yet since now the
> > > > bottleneck will be waiting for the mode_config lock in
> > > > drm_kms_helper_poll_enable(), since that will be held as long as
> > > > i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> > > > address that in the next patch.
> > > > 
> > > > Signed-off-by: Lyude 
> > > > Cc: David Weinehall 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index bfb2efd..532cc0f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
> > > >     * notifications.
> > > >     * */
> > > >    intel_hpd_init(dev_priv);
> > > > -   /* Config may have changed between suspend and resume */
> > > > -   drm_helper_hpd_irq_event(dev);
> > > 
> > > The comment is still apt. This code is known to be broken since it
> > > doesn't detect a change in monitors (e.g. a change in external connectors
> > > from docking) between suspend and resend. We still have to send the 
> > > uevent.
> > > 
> > > + drm_kms_helper_hotplug_event(dev);
> > 
> > I might not have explained myself very well. The way things should look with
> > this patch is like this:
> > 
> > i915_drm_resume()
> >  -> intel_hpd_init()
> >    -> sets dev_priv->hotplug.poll_enabled to true
> Whoops, s/true/false/
> 
> >    -> schedules dev_priv->hotplug.poll_init_work
> >  -> continue resume…
> > 
> > at the same time:
> > 
> > i915_hpd_poll_init_work() gets scheduled and starts
> >  -> since dev_priv->hotplug.poll_enabled == false, 
> > drm_helper_hpd_irq_event()
> > is called
> >   -> drm_helper_hpd_irq_event() reprobes connectors
> >    -> if anything changed, drm_kms_helper_hotplug_event() gets called.

drm_helper_hpd_irq_event() does not detect a change in monitors, for
example, so there is no uevent in that case.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: move check for min/max width/height for atomic drivers

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
> drm-hwc + android tries to create an fb for the wallpaper layer, which
> is larger than the screen resolution, and potentially larger than
> mode_config->max_{width,height}.  But the plane src_w/src_h is within
> the max limits, so it is something the hardware can otherwise do.
> 
> For atomic drivers, defer the check to drm_atomic_plane_check().
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_atomic.c | 17 +
>  drivers/gpu/drm/drm_crtc.c   | 26 +-
>  2 files changed, 34 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 34edd4f..fb0f07ce 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state *state,
>  static int drm_atomic_plane_check(struct drm_plane *plane,
>   struct drm_plane_state *state)
>  {
> + struct drm_mode_config *config = >dev->mode_config;
>   unsigned int fb_width, fb_height;
> + unsigned int min_width, max_width, min_height, max_height;
>   int ret;
>  
>   /* either *both* CRTC and FB must be set, or neither */
> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct drm_plane 
> *plane,
>   return -ENOSPC;
>   }
>  
> + min_width = config->min_width << 16;
> + max_width = config->max_width << 16;
> + min_height = config->min_height << 16;
> + max_height = config->max_height << 16;
> +
> + /* Make sure source dimensions are within bounds. */
> + if (min_width > state->src_w || state->src_w > max_width ||
> + min_height > state->src_h || state->src_h > max_height) {
> + DRM_DEBUG_ATOMIC("Invalid source size "
> +  "%u.%06ux%u.%06u\n",
> +  state->src_w >> 16, ((state->src_w & 0x) * 
> 15625) >> 10,
> +  state->src_h >> 16, ((state->src_h & 0x) * 
> 15625) >> 10);
> + return -ERANGE;
> + }
> +
>   if (plane_switching_crtc(state->state, plane, state)) {
>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>plane->base.id, plane->name);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b4b973f..7294bde 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device *dev,
>   return ERR_PTR(-EINVAL);
>   }
>  
> - if ((config->min_width > r->width) || (r->width > config->max_width)) {
> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= 
> %d\n",
> -   r->width, config->min_width, config->max_width);
> - return ERR_PTR(-EINVAL);
> - }
> - if ((config->min_height > r->height) || (r->height > 
> config->max_height)) {
> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && <= 
> %d\n",
> -   r->height, config->min_height, config->max_height);
> - return ERR_PTR(-EINVAL);
> + /* for atomic drivers, we check the src dimensions in
> +  * drm_atomic_plane_check().. allow creation of a fb
> +  * that is larger than what can be scanned out, as
> +  * long as userspace doesn't try to scanout a portion
> +  * of the fb that is too large.
> +  */
> + if (!file_priv->atomic) {
> + if ((config->min_width > r->width) || (r->width > 
> config->max_width)) {
> + DRM_DEBUG_KMS("bad framebuffer width %d, should be >= 
> %d && <= %d\n",
> +   r->width, config->min_width, 
> config->max_width);
> + return ERR_PTR(-EINVAL);
> + }
> + if ((config->min_height > r->height) || (r->height > 
> config->max_height)) {
> + DRM_DEBUG_KMS("bad framebuffer height %d, should be >= 
> %d && <= %d\n",
> +   r->height, config->min_height, 
> config->max_height);
> + return ERR_PTR(-EINVAL);
> + }

So why not just bump max_foo in your driver?

Removing the restriction from the core seems likely to break some
drivers as they would now have to check the fb dimensions themselves.

>   }
>  
>   if (r->flags & DRM_MODE_FB_MODIFIERS &&
> -- 
> 2.7.4

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm/uapi: Add a warning that mode flags must match the xrandr definitions

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

Existing userspace expected the mode flags to match the xrandr
definitions 1:1, and even adding new flags in he previously unused
bits is likely to break existing userspace. Add a comment warning
people about this potential trap.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
 include/uapi/drm/drm_mode.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 084b50a02dc5..01000c9f7c2c 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -47,7 +47,15 @@ extern "C" {
 #define DRM_MODE_TYPE_DRIVER   (1<<6)

 /* Video mode flags */
-/* bit compatible with the xorg definitions. */
+/* bit compatible with the xrandr RR_ definitions (bits 0-13)
+ *
+ * ABI warning: Existing userspace really expects
+ * the mode flags to match the xrandr definitions. Any
+ * changes that don't match the xrandr definitions will
+ * likely need a new client cap or some other mechanism
+ * to avoid breaking existing userspace. This includes
+ * allocating new flags in the previously unused bits!
+ */
 #define DRM_MODE_FLAG_PHSYNC   (1<<0)
 #define DRM_MODE_FLAG_NHSYNC   (1<<1)
 #define DRM_MODE_FLAG_PVSYNC   (1<<2)
-- 
2.7.4

[Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[Chris Wilson]

On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> Weine's investigation on benchmarking the suspend/resume process pointed
> out a lot of the time in suspend/resume is being spent reprobing. While
> the reprobing process is a lengthy one for good reason, we don't need to
> hold up the entire suspend/resume process while we wait for it to
> finish. Luckily as it turns out, we already trigger a full connector
> reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> i915_drm_resume() entirely.
> 
> This won't lead to less time spent resuming just yet since now the
> bottleneck will be waiting for the mode_config lock in
> drm_kms_helper_poll_enable(), since that will be held as long as
> i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> address that in the next patch.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bfb2efd..532cc0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
>* notifications.
>* */
>   intel_hpd_init(dev_priv);
> - /* Config may have changed between suspend and resume */
> - drm_helper_hpd_irq_event(dev);

The comment is still apt. This code is known to be broken since it
doesn't detect a change in monitors (e.g. a change in external connectors
from docking) between suspend and resend. We still have to send the uevent.

+   drm_kms_helper_hotplug_event(dev);

which also depends upon us actually reseting the connector->status to
unknown in drm_mode_config_reset(), Daniel!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 98573] Mesa build fail since radeonsi: use PS epilog for monolithic shaders

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

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

Nicolai Hähnle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Nicolai Hähnle  ---
Fixed in master.

-- 
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/20161103/fa65cb19/attachment.html>

[Intel-gfx] [PATCH 17/19] drm/i915: Use new atomic iterator macros in wm code

[Paulo Zanoni]

Em Qui, 2016-11-03 às 18:49 +0200, Ville Syrjälä escreveu:
> On Mon, Oct 17, 2016 at 02:37:16PM +0200, Maarten Lankhorst wrote:
> > 
> > Signed-off-by: Maarten Lankhorst  > >
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 2df06b703e3d..163b73b493bf 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3227,7 +3227,7 @@ skl_get_total_relative_data_rate(struct
> > intel_crtc_state *intel_cstate)
> >    return 0;
> >  
> >    /* Calculate and cache data rate for each plane */
> > -   for_each_plane_in_state(state, plane, pstate, i) {
> > +   for_each_new_plane_in_state(state, plane, pstate, i) {
> 
> Looks like this patch needs a refresh due to my tardiness in
> reviewing
> it.
> 
> Also unrelated, but I recently noticed that
> skl_get_total_relative_data_rate() doesn't exclude the cursor plane
> from the calculation. I'm thinking it should. Adding some Cc:s...

It seems we're safe because skl_plane_relative_data_rate() returns 0
for cursor. But an explicitly check at the caller would probably be
much much better instead of hidden deep in the code. OTOH, Matt's plans
to exclude cursor case-handling would remove this need again.

> 
> > 
> >    id = skl_wm_plane_id(to_intel_plane(plane));
> >    intel_plane = to_intel_plane(plane);
> >  
> > @@ -3364,14 +3364,14 @@ skl_allocate_pipe_ddb(struct
> > intel_crtc_state *cstate,
> >    alloc_size -= cursor_blocks;
> >  
> >    /* 1. Allocate the mininum required blocks for each active
> > plane */
> > -   for_each_plane_in_state(state, plane, pstate, i) {
> > +   for_each_new_plane_in_state(state, plane, pstate, i) {
> >    intel_plane = to_intel_plane(plane);
> >    id = skl_wm_plane_id(intel_plane);
> >  
> >    if (intel_plane->pipe != pipe)
> >    continue;
> >  
> > -   if (!to_intel_plane_state(pstate)->base.visible) {
> > +   if (!pstate->visible) {
> >    minimum[id] = 0;
> >    y_minimum[id] = 0;
> >    continue;
> > @@ -3933,7 +3933,7 @@ pipes_modified(struct drm_atomic_state
> > *state)
> >    struct drm_crtc_state *cstate;
> >    uint32_t i, ret = 0;
> >  
> > -   for_each_crtc_in_state(state, crtc, cstate, i)
> > +   for_each_new_crtc_in_state(state, crtc, cstate, i)
> >    ret |= drm_crtc_mask(crtc);
> >  
> >    return ret;
> > @@ -4048,7 +4048,7 @@ skl_compute_wm(struct drm_atomic_state
> > *state)
> >     * since any racing commits that want to update them would
> > need to
> >     * hold _all_ CRTC state mutexes.
> >     */
> > -   for_each_crtc_in_state(state, crtc, cstate, i)
> > +   for_each_new_crtc_in_state(state, crtc, cstate, i)
> >    changed = true;
> >    if (!changed)
> >    return 0;
> > @@ -4070,7 +4070,7 @@ skl_compute_wm(struct drm_atomic_state
> > *state)
> >     * should allow skl_update_pipe_wm() to return failure in
> > cases where
> >     * no suitable watermark values can be found.
> >     */
> > -   for_each_crtc_in_state(state, crtc, cstate, i) {
> > +   for_each_new_crtc_in_state(state, crtc, cstate, i) {
> >    struct intel_crtc *intel_crtc =
> > to_intel_crtc(crtc);
> >    struct intel_crtc_state *intel_cstate =
> >    to_intel_crtc_state(cstate);
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 07:04:37PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/3/2016 6:56 PM, Ville Syrjälä wrote:
> > On Thu, Nov 03, 2016 at 06:40:11PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/3/2016 6:32 PM, Ville Syrjälä wrote:
> >>> On Thu, Nov 03, 2016 at 12:47:39PM +, Sharma, Shashank wrote:
>  Hi Ville,
>  (-dri-devel)
>  I would appreciate an internal discussion before going to dri-devel. a
> >>> Added back. Private discussions are pointless.
> >> Noted.
>  What did this patch break ?
> >>> Intel ddx. It will reject any mode with flags it doesn't know about.
> >>> Other ddxen like -ati or -modesetting will also suffer, but potentially
> >>> in a different way since they don't even check the flags and instead
> >>> just directly stuff them into the randr mode flags, which will result
> >>> in an out of spec mode as far randr is concerned.
> >> Then its a fault of intel-ddx design. We are adding new flags to
> >> indicate aspect ratios, so its obvious that the implementation should be
> >> modified to accept new flags.
> >> I dont see why you should revert patch for it.
> > Rule 1 of kernel development: You simply don't break existing userspace
> Again, we are adding something new, for which userspace should be modified.
> If the userspace in written in such a way that it wont accept changes, 
> its not saleable design.

Whether the design is good or not is besides the point. It already
exists, so we have to live with it.

> 
> Even in this case, we should go and extend the userspace (which I am 
> ready to do) instead of reverting the patch.

We can't retroactively fix the binaries on everyone's machine.

> If you still think you should send this revert, I am removing my NACK. 
> Pls Go ahead.

The other option is to not revert and instead slap a fix on top. But 
that would have to be done reasonably quickly so that the thing is
ready in time for 4.10. We're closing in on 4.9-rc4 now so I guess
we should still have a few weeks to fix things up. Whether that's
enough I don't know. If not, then we should revert.

>  This is exposed in the same way, as the 3D flags.
> >>> Not it isn't. We have a client cap for 3D flags.
> >>>
>  The information is already available in form of flags, all you have to 
>  do in userspace is read and print that. Its already being done in 
>  Android.
> >>> Please stop relying on Android for testing upstream patches. Test with
> >>> actual userspace people are using.
> >> Please note that android goes through HDMI compliance certification, and
> >> several commercial test infrastructures, so
> >> that's one of the best infrastructure to test. And when we have common
> >> branch for all of Linux flavors, we should consider all.
> > You can test with Android as much as you like. That probably won't
> > catch ABI breaks and whatnot though since you don't generally just plop
> > a new kernel onto an existing Android device.
> >
> > So you really must test with normal userspace as well. That has a long
> > history and so any ABI/behaviour change is actually a big deal.
> >
> 
>  NACK until we get to the right reason.
> 
>  Regards
>  Shashank
>  -Original Message-
>  From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at 
>  linux.intel.com]
>  Sent: Thursday, November 3, 2016 6:02 PM
>  To: dri-devel at lists.freedesktop.org
>  Cc: Sharma, Shashank ; Lin; Jia, Lin A 
>  ; Sharma, Akashdeep   intel.com>; Jim Bride ; Jose Abreu 
>  ; Daniel Vetter ; 
>  Emil Velikov 
>  Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in 
>  DRM layer"
> 
>  From: Ville Syrjälä 
> 
>  This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
> 
>  Adding new mode flags willy nilly breaks existing userspace. We need to 
>  coordinate this better, potentially with a new client cap that only 
>  exposes the aspect ratio flags when userspace is prepared for them 
>  (similar to what we do with stereo 3D modes).
> 
>  Cc: Shashank Sharma 
>  Cc: Lin, Jia 
>  Cc: Akashdeep Sharma 
>  Cc: Jim Bride 
>  Cc: Jose Abreu 
>  Cc: Daniel Vetter 
>  Cc: Emil Velikov 
>  Cc: Daniel Vetter 
>  Signed-off-by: Ville Syrjälä 
>  ---
> drivers/gpu/drm/drm_modes.c | 12   
>  include/uapi/drm/drm_mode.h |  6 --
> 2 files changed, 18 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c 
>  index f64ac86deb84..725faa6409aa 100644
>  --- a/drivers/gpu/drm/drm_modes.c
>  +++ b/drivers/gpu/drm/drm_modes.c
>  @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
>  drm_mode_modeinfo *out,
>   case HDMI_PICTURE_ASPECT_16_9:
>   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
>  

[Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Paulo Zanoni]

Em Qui, 2016-11-03 às 18:45 +0200, Ville Syrjälä escreveu:
> On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> > 
> > Signed-off-by: Maarten Lankhorst  > >
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index faa67624e1ed..0028335fc1bb 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> >  
> >    mutex_lock(>lock);
> >  
> > -   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> >    if (fbc->crtc == to_intel_crtc(crtc)) {
> >    fbc_crtc_present = true;
> >    break;
> > @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> >     * plane. We could go for fancier schemes such as checking
> > the plane
> >     * size, but this would just affect the few platforms that
> > don't tie FBC
> >     * to pipe or plane A. */
> > -   for_each_plane_in_state(state, plane, plane_state, i) {
> > +   for_each_new_plane_in_state(state, plane, plane_state, i)
> > {
> >    struct intel_plane_state *intel_plane_state =
> >    to_intel_plane_state(plane_state);
> >  
> >    if (!intel_plane_state->base.visible)
> >    continue;
> 
> Unrelated but this thing looks somewhat bogus. FBC is tied to the
> primary plane only, so why do we care about the visibility of the
> other
> planes? Adding Paulo to Cc...

Looks like you've found a bug... Thanks! We should really be iterating
over primary planes only. Adding to the TODO list.

> 
> > 
> >  
> > -   for_each_crtc_in_state(state, crtc, crtc_state, j)
> > {
> > +   for_each_new_crtc_in_state(state, crtc,
> > crtc_state, j) {
> 
> Also, can't this inner loop be replaced with a simple
> crtc = plane_state->crtc ?

Is there a way to get the proposed crtc_state without the loop?


> 
> > 
> >    struct intel_crtc_state *intel_crtc_state
> > =
> >    to_intel_crtc_state(crtc_state);
> >  
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 06:40:11PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/3/2016 6:32 PM, Ville Syrjälä wrote:
> > On Thu, Nov 03, 2016 at 12:47:39PM +, Sharma, Shashank wrote:
> >> Hi Ville,
> >> (-dri-devel)
> >> I would appreciate an internal discussion before going to dri-devel. a
> > Added back. Private discussions are pointless.
> Noted.
> >> What did this patch break ?
> > Intel ddx. It will reject any mode with flags it doesn't know about.
> > Other ddxen like -ati or -modesetting will also suffer, but potentially
> > in a different way since they don't even check the flags and instead
> > just directly stuff them into the randr mode flags, which will result
> > in an out of spec mode as far randr is concerned.
> Then its a fault of intel-ddx design. We are adding new flags to 
> indicate aspect ratios, so its obvious that the implementation should be 
> modified to accept new flags.
> I dont see why you should revert patch for it.

Rule 1 of kernel development: You simply don't break existing userspace

> >> This is exposed in the same way, as the 3D flags.
> > Not it isn't. We have a client cap for 3D flags.
> >
> >> The information is already available in form of flags, all you have to do 
> >> in userspace is read and print that. Its already being done in Android.
> > Please stop relying on Android for testing upstream patches. Test with
> > actual userspace people are using.
> Please note that android goes through HDMI compliance certification, and 
> several commercial test infrastructures, so
> that's one of the best infrastructure to test. And when we have common 
> branch for all of Linux flavors, we should consider all.

You can test with Android as much as you like. That probably won't
catch ABI breaks and whatnot though since you don't generally just plop
a new kernel onto an existing Android device.

So you really must test with normal userspace as well. That has a long
history and so any ABI/behaviour change is actually a big deal.

> >>   
> >> NACK until we get to the right reason.
> >>
> >> Regards
> >> Shashank
> >> -Original Message-
> >> From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at 
> >> linux.intel.com]
> >> Sent: Thursday, November 3, 2016 6:02 PM
> >> To: dri-devel at lists.freedesktop.org
> >> Cc: Sharma, Shashank ; Lin; Jia, Lin A 
> >> ; Sharma, Akashdeep  >> intel.com>; Jim Bride ; Jose Abreu 
> >> ; Daniel Vetter ; 
> >> Emil Velikov 
> >> Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM 
> >> layer"
> >>
> >> From: Ville Syrjälä 
> >>
> >> This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
> >>
> >> Adding new mode flags willy nilly breaks existing userspace. We need to 
> >> coordinate this better, potentially with a new client cap that only 
> >> exposes the aspect ratio flags when userspace is prepared for them 
> >> (similar to what we do with stereo 3D modes).
> >>
> >> Cc: Shashank Sharma 
> >> Cc: Lin, Jia 
> >> Cc: Akashdeep Sharma 
> >> Cc: Jim Bride 
> >> Cc: Jose Abreu 
> >> Cc: Daniel Vetter 
> >> Cc: Emil Velikov 
> >> Cc: Daniel Vetter 
> >> Signed-off-by: Ville Syrjälä 
> >> ---
> >>   drivers/gpu/drm/drm_modes.c | 12   
> >> include/uapi/drm/drm_mode.h |  6 --
> >>   2 files changed, 18 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c 
> >> index f64ac86deb84..725faa6409aa 100644
> >> --- a/drivers/gpu/drm/drm_modes.c
> >> +++ b/drivers/gpu/drm/drm_modes.c
> >> @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
> >> drm_mode_modeinfo *out,
> >>case HDMI_PICTURE_ASPECT_16_9:
> >>out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> >>break;
> >> -  case HDMI_PICTURE_ASPECT_64_27:
> >> -  out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> >> -  break;
> >> -  case DRM_MODE_PICTURE_ASPECT_256_135:
> >> -  out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> >> -  break;
> >>case HDMI_PICTURE_ASPECT_RESERVED:
> >>default:
> >>out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 +1574,6 @@ 
> >> int drm_mode_convert_umode(struct drm_display_mode *out,
> >>case DRM_MODE_FLAG_PIC_AR_16_9:
> >>out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> >>break;
> >> -  case DRM_MODE_FLAG_PIC_AR_64_27:
> >> -  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> >> -  break;
> >> -  case DRM_MODE_FLAG_PIC_AR_256_135:
> >> -  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> >> -  break;
> >>default:
> >>out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> >>break;
> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h 
> >> index 084b50a02dc5..5c142b1387ac 100644
> >> --- a/include/uapi/drm/drm_mode.h
> >> +++ b/include/uapi/drm/drm_mode.h
> >> @@ -81,8 +81,6 @@ extern "C" {
> >>   #define 

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Sean Paul]

On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard
 wrote:
> Hi Russell,
>
> On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote:
>> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
>> > The first one is that this overscanning should be reported by the
>> > connector I guess? but this is really TV specific, so we need one way
>> > to let the user tell how the image is displayed on its side, and we
>> > cannot really autodetect it, and this needs to be done at runtime so
>> > that we can present some shiny interface to let it select which
>> > overscan ratio works for him/her.
>>
>> See xbmc... they go through a nice shiny setup which includes adjusting
>> the visible area.  From what I remember, it has pointers on each corner
>> which you can adjust to be just visible on the screen, so xbmc knows
>> how much overscan there is, and xbmc itself reduces down to the user
>> set size.
>
> Yes. And that is an XBMC only solution, that doesn't work with the
> fbdev emulation and is probably doing an additional composition to
> scale down and center their frames through OpenGL.
>
> We might not have a GPU in the system, and we might not even have an
> entire graphic stack on top either, so I don't think fixing at the
> user-space level is a good option (especially since we already have an
> overscan property in DRM).
>

Hi Maxime,
I took a quick look at the first 2 patches in the series and they look
good at first glance. I have them in my queue to review more
carefully.

Can you explain why you can't fix this by specifying a new mode with
big porches (as Russell suggested)?

Sean


>> > The second one is that we still need to expose the reduced modes to
>> > userspace, and not only the displayed size, so that the applications
>> > know what they must draw on. But I guess this could be adjusted by the
>> > core too.
>> >
>> > In order to work consistently, I think all planes should be adjusted
>> > that way, so that relative coordinates are from the primary plane
>> > origin, and not the display origin. But that could be adjusted too by
>> > the core I guess.
>>
>> I'm not sure about that - we want the graphics to be visible, but that
>> may not be appropriate for an video overlay frame.  It's quite common
>> for (eg) broadcast video to contain dead pixels or other artifacts on
>> the right hand side, and the broadcast video expects overscan to be
>> present.
>>
>> I know this because I have run my TV with overscan disabled, even for
>> broadcast TV.
>
> I know, but on this particular hardware, composite really is just
> another video output. There's not even a TV receiver in it, so I don't
> think we have to worry about it.
>
>> > The fourth one being the major one. Every time I raised the issue on
>> > IRC, the answer basically was "we don't care about analog", so I'm a
>> > bit pessimistic about whether dealing with this in the core would be
>> > accepted, hence why I chose to deal with this at the driver level.
>>
>> Yea, that's quite sad, "analog" has become a dirty word, but really
>> this has nothing to do with "analog" at all - there are LCD TVs (and
>> some monitors) out there which take HDMI signals but refuse to
>> disable overscan no matter what you do to them if you provide them
>> with a "broadcast"  mode - so the analog excuse is very poor.
>
> I'd agree with you, but I was also told to not turn that into a
> generic code and deal with that in my driver.
>
> Do you have any suggestions?
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 03:04:04PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 03:02:53PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 03, 2016 at 12:47:39PM +, Sharma, Shashank wrote:
> > > Hi Ville, 
> > > (-dri-devel)
> > > I would appreciate an internal discussion before going to dri-devel. a
> > 
> > Added back. Private discussions are pointless.
> 
> Now added for reals.
> 
> > 
> > > 
> > > What did this patch break ? 
> > 
> > Intel ddx. It will reject any mode with flags it doesn't know about. 
> > Other ddxen like -ati or -modesetting will also suffer, but potentially
> > in a different way since they don't even check the flags and instead
> > just directly stuff them into the randr mode flags, which will result
> > in an out of spec mode as far randr is concerned.

BTW outside of the userspace issues there were some issues with the way
the mode matching was being done. Before I realized the userspace breakage
I had cooked up a few additonal patch to adjust the mode matching a bit.
I pushed those to [1] in case anyone wants to take a look, but obviously
they need to be put on hold a bit until we sort out the userspace part.

[1] git://github.com/vsyrjala/linux.git cea_f_vics

> > 
> > > This is exposed in the same way, as the 3D flags.
> > 
> > Not it isn't. We have a client cap for 3D flags.
> > 
> > > The information is already available in form of flags, all you have to do 
> > > in userspace is read and print that. Its already being done in Android. 
> > 
> > Please stop relying on Android for testing upstream patches. Test with
> > actual userspace people are using.
> > 
> > >  
> > > NACK until we get to the right reason. 
> > > 
> > > Regards
> > > Shashank
> > > -Original Message-
> > > From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at 
> > > linux.intel.com] 
> > > Sent: Thursday, November 3, 2016 6:02 PM
> > > To: dri-devel at lists.freedesktop.org
> > > Cc: Sharma, Shashank ; Lin; Jia, Lin A 
> > > ; Sharma, Akashdeep  > > intel.com>; Jim Bride ; Jose Abreu 
> > > ; Daniel Vetter ; 
> > > Emil Velikov 
> > > Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM 
> > > layer"
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
> > > 
> > > Adding new mode flags willy nilly breaks existing userspace. We need to 
> > > coordinate this better, potentially with a new client cap that only 
> > > exposes the aspect ratio flags when userspace is prepared for them 
> > > (similar to what we do with stereo 3D modes).
> > > 
> > > Cc: Shashank Sharma 
> > > Cc: Lin, Jia 
> > > Cc: Akashdeep Sharma 
> > > Cc: Jim Bride 
> > > Cc: Jose Abreu 
> > > Cc: Daniel Vetter 
> > > Cc: Emil Velikov 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_modes.c | 12   
> > > include/uapi/drm/drm_mode.h |  6 --
> > >  2 files changed, 18 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c 
> > > index f64ac86deb84..725faa6409aa 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
> > > drm_mode_modeinfo *out,
> > >   case HDMI_PICTURE_ASPECT_16_9:
> > >   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> > >   break;
> > > - case HDMI_PICTURE_ASPECT_64_27:
> > > - out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> > > - break;
> > > - case DRM_MODE_PICTURE_ASPECT_256_135:
> > > - out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> > > - break;
> > >   case HDMI_PICTURE_ASPECT_RESERVED:
> > >   default:
> > >   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 +1574,6 @@ 
> > > int drm_mode_convert_umode(struct drm_display_mode *out,
> > >   case DRM_MODE_FLAG_PIC_AR_16_9:
> > >   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> > >   break;
> > > - case DRM_MODE_FLAG_PIC_AR_64_27:
> > > - out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> > > - break;
> > > - case DRM_MODE_FLAG_PIC_AR_256_135:
> > > - out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> > > - break;
> > >   default:
> > >   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> > >   break;
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h 
> > > index 084b50a02dc5..5c142b1387ac 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -81,8 +81,6 @@ extern "C" {
> > >  #define DRM_MODE_PICTURE_ASPECT_NONE 0
> > >  #define DRM_MODE_PICTURE_ASPECT_4_3  1
> > >  #define DRM_MODE_PICTURE_ASPECT_16_9 2
> > > -#define DRM_MODE_PICTURE_ASPECT_64_273
> > > -#define DRM_MODE_PICTURE_ASPECT_256_135  4
> > >  
> > >  /* Aspect ratio flag bitmask (4 bits 22:19) */
> > >  #define 

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 03:02:53PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 12:47:39PM +, Sharma, Shashank wrote:
> > Hi Ville, 
> > (-dri-devel)
> > I would appreciate an internal discussion before going to dri-devel. a
> 
> Added back. Private discussions are pointless.

Now added for reals.

> 
> > 
> > What did this patch break ? 
> 
> Intel ddx. It will reject any mode with flags it doesn't know about. 
> Other ddxen like -ati or -modesetting will also suffer, but potentially
> in a different way since they don't even check the flags and instead
> just directly stuff them into the randr mode flags, which will result
> in an out of spec mode as far randr is concerned.
> 
> > This is exposed in the same way, as the 3D flags.
> 
> Not it isn't. We have a client cap for 3D flags.
> 
> > The information is already available in form of flags, all you have to do 
> > in userspace is read and print that. Its already being done in Android. 
> 
> Please stop relying on Android for testing upstream patches. Test with
> actual userspace people are using.
> 
> >  
> > NACK until we get to the right reason. 
> > 
> > Regards
> > Shashank
> > -Original Message-
> > From: ville.syrjala at linux.intel.com [mailto:ville.syrjala at 
> > linux.intel.com] 
> > Sent: Thursday, November 3, 2016 6:02 PM
> > To: dri-devel at lists.freedesktop.org
> > Cc: Sharma, Shashank ; Lin; Jia, Lin A 
> > ; Sharma, Akashdeep  > intel.com>; Jim Bride ; Jose Abreu 
> > ; Daniel Vetter ; 
> > Emil Velikov 
> > Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM 
> > layer"
> > 
> > From: Ville Syrjälä 
> > 
> > This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
> > 
> > Adding new mode flags willy nilly breaks existing userspace. We need to 
> > coordinate this better, potentially with a new client cap that only exposes 
> > the aspect ratio flags when userspace is prepared for them (similar to what 
> > we do with stereo 3D modes).
> > 
> > Cc: Shashank Sharma 
> > Cc: Lin, Jia 
> > Cc: Akashdeep Sharma 
> > Cc: Jim Bride 
> > Cc: Jose Abreu 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_modes.c | 12   include/uapi/drm/drm_mode.h 
> > |  6 --
> >  2 files changed, 18 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c 
> > index f64ac86deb84..725faa6409aa 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
> > drm_mode_modeinfo *out,
> > case HDMI_PICTURE_ASPECT_16_9:
> > out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> > break;
> > -   case HDMI_PICTURE_ASPECT_64_27:
> > -   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> > -   break;
> > -   case DRM_MODE_PICTURE_ASPECT_256_135:
> > -   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> > -   break;
> > case HDMI_PICTURE_ASPECT_RESERVED:
> > default:
> > out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 +1574,6 @@ 
> > int drm_mode_convert_umode(struct drm_display_mode *out,
> > case DRM_MODE_FLAG_PIC_AR_16_9:
> > out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> > break;
> > -   case DRM_MODE_FLAG_PIC_AR_64_27:
> > -   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> > -   break;
> > -   case DRM_MODE_FLAG_PIC_AR_256_135:
> > -   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> > -   break;
> > default:
> > out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> > break;
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h 
> > index 084b50a02dc5..5c142b1387ac 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -81,8 +81,6 @@ extern "C" {
> >  #define DRM_MODE_PICTURE_ASPECT_NONE   0
> >  #define DRM_MODE_PICTURE_ASPECT_4_31
> >  #define DRM_MODE_PICTURE_ASPECT_16_9   2
> > -#define DRM_MODE_PICTURE_ASPECT_64_27  3
> > -#define DRM_MODE_PICTURE_ASPECT_256_1354
> >  
> >  /* Aspect ratio flag bitmask (4 bits 22:19) */
> >  #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
> > @@ -92,10 +90,6 @@ extern "C" {
> > (DRM_MODE_PICTURE_ASPECT_4_3<<19)
> >  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
> > (DRM_MODE_PICTURE_ASPECT_16_9<<19)
> > -#define  DRM_MODE_FLAG_PIC_AR_64_27 \
> > -   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
> > -#define  DRM_MODE_FLAG_PIC_AR_256_135 \
> > -   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
> >  
> >  /* DPMS flags */
> >  /* bit compatible with the xorg definitions. */
> > --
> > 2.7.4
> > 
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Ville Syrjälä
Intel OTC

[PATCH 2/2] drm/edid: Consider alternate cea timings to be the same VIC

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

CEA-861 specifies that the vertical front porch may vary by one or two
lines for specific VICs. Up to now we've only considered a mode to match
the VIC if it matched the shortest possible vertical front porch length
(as that is the variant we store in cea_modes[]). Let's allow our VIC
matching to work with the other timings variants as well so that that
we'll send out the correct VIC if the variant actually used isn't the
one with the shortest vertical front porch.

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 66 +-
 1 file changed, 54 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7eec18925b70..728990fee4ef 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2613,6 +2613,41 @@ cea_mode_alternate_clock(const struct drm_display_mode 
*cea_mode)
return clock;
 }

+static bool
+cea_mode_alternate_timings(u8 vic, struct drm_display_mode *mode)
+{
+   /*
+* For certain VICs the spec allows the vertical
+* front porch to vary by one or two lines.
+*
+* cea_modes[] stores the variant with the shortest
+* vertical front porch. We can adjust the mode to
+* get the other variants by simply increasing the
+* vertical front porch length.
+*/
+   BUILD_BUG_ON(edid_cea_modes[8].vtotal != 262 ||
+edid_cea_modes[9].vtotal != 262 ||
+edid_cea_modes[12].vtotal != 262 ||
+edid_cea_modes[13].vtotal != 262 ||
+edid_cea_modes[23].vtotal != 312 ||
+edid_cea_modes[24].vtotal != 312 ||
+edid_cea_modes[27].vtotal != 312 ||
+edid_cea_modes[28].vtotal != 312);
+
+   if (((vic == 8 || vic == 9 ||
+ vic == 12 || vic == 13) && mode->vtotal < 263) ||
+   ((vic == 23 || vic == 24 ||
+ vic == 27 || vic == 28) && mode->vtotal < 314)) {
+   mode->vsync_start++;
+   mode->vsync_end++;
+   mode->vtotal++;
+
+   return true;
+   }
+
+   return false;
+}
+
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
@@ -2622,19 +2657,21 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
return 0;

for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
-   const struct drm_display_mode *cea_mode = _cea_modes[vic];
+   struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;

/* Check both 60Hz and 59.94Hz */
-   clock1 = cea_mode->clock;
-   clock2 = cea_mode_alternate_clock(cea_mode);
+   clock1 = cea_mode.clock;
+   clock2 = cea_mode_alternate_clock(_mode);

if (abs(to_match->clock - clock1) > clock_tolerance &&
abs(to_match->clock - clock2) > clock_tolerance)
continue;

-   if (drm_mode_equal_no_clocks(to_match, cea_mode))
-   return vic;
+   do {
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   return vic;
+   } while (cea_mode_alternate_timings(vic, _mode));
}

return 0;
@@ -2655,18 +2692,23 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
return 0;

for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
-   const struct drm_display_mode *cea_mode = _cea_modes[vic];
+   struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;

/* Check both 60Hz and 59.94Hz */
-   clock1 = cea_mode->clock;
-   clock2 = cea_mode_alternate_clock(cea_mode);
+   clock1 = cea_mode.clock;
+   clock2 = cea_mode_alternate_clock(_mode);

-   if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
-KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
-   drm_mode_equal_no_clocks_no_stereo(to_match, cea_mode))
-   return vic;
+   if (KHZ2PICOS(to_match->clock) != KHZ2PICOS(clock1) &&
+   KHZ2PICOS(to_match->clock) != KHZ2PICOS(clock2))
+   continue;
+
+   do {
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   return vic;
+   } while (cea_mode_alternate_timings(vic, _mode));
}
+
return 0;
 }
 EXPORT_SYMBOL(drm_match_cea_mode);
-- 

[PATCH 1/2] drm/edid: Add the missing "Hz" to VIC 58,59 comment

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

All the VICs apart from 58 and 59 have the word "Hz" included in the
comment. Include it for 59 and 59 as well.

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9506933b41cd..7eec18925b70 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -957,13 +957,13 @@ static const struct drm_display_mode edid_cea_modes[] = {
   798, 858, 0, 480, 489, 495, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
  .vrefresh = 240, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 58 - 720(1440)x480i at 240 */
+   /* 58 - 720(1440)x480i at 240Hz */
{ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 54000, 720, 739,
   801, 858, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 240, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
-   /* 59 - 720(1440)x480i at 240 */
+   /* 59 - 720(1440)x480i at 240Hz */
{ DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 54000, 720, 739,
   801, 858, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
-- 
2.7.4

[Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

[Rob Clark]

On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom  wrote:
> Signed-off-by: Eric Engestrom 
> ---
>
> I moved the main bits to be the first diffs, shouldn't affect anything
> when applying the patch, but I wanted to ask:
> I don't like the hard-coded `32` the appears in both kmalloc() and
> snprintf(), what do you think? If you don't like it either, what would
> you suggest? Should I #define it?
>
> Second question is about the patch mail itself: should I send this kind
> of patch separated by module, with a note requesting them to be squashed
> when applying? It has to land as a single patch, but for review it might
> be easier if people only see the bits they each care about, as well as
> to collect ack's/r-b's.
>
> Cheers,
>   Eric
>
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  6 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  6 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  6 ++--
>  drivers/gpu/drm/drm_atomic.c|  5 ++--
>  drivers/gpu/drm/drm_crtc.c  | 21 -
>  drivers/gpu/drm/drm_fourcc.c| 17 ++-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  6 ++--
>  drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  6 ++--
>  drivers/gpu/drm/i915/intel_display.c| 39 
> -
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 12 +---
>  include/drm/drm_fourcc.h|  2 +-
>  12 files changed, 89 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 0645c85..38216a1 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -39,16 +39,14 @@ static char printable_char(int c)
>   * drm_get_format_name - return a string for drm fourcc format
>   * @format: format to compute name of
>   *
> - * Note that the buffer used by this function is globally shared and owned by
> - * the function itself.
> - *
> - * FIXME: This isn't really multithreading safe.
> + * Note that the buffer returned by this function is owned by the caller
> + * and will need to be freed.
>   */
>  const char *drm_get_format_name(uint32_t format)
>  {
> -   static char buf[32];
> +   char *buf = kmalloc(32, GFP_KERNEL);


hmm, I guess I wasn't paying attention at the time this patch came by,
but unfortunately this makes drm_get_format_name() no longer safe in
atomic contexts :-/

We should probably either revert this or have two variants of
drm_get_format_name()?  (ie. one that is not thread safe but is good
enough for debugging)

BR,
-R

> -   snprintf(buf, sizeof(buf),
> +   snprintf(buf, 32,
>  "%c%c%c%c %s-endian (0x%08x)",
>  printable_char(format & 0xff),
>  printable_char((format >> 8) & 0xff),
> @@ -73,6 +71,8 @@ EXPORT_SYMBOL(drm_get_format_name);
>  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
>   int *bpp)
>  {
> +   const char *format_name;
> +
> switch (format) {
> case DRM_FORMAT_C8:
> case DRM_FORMAT_RGB332:
> @@ -127,8 +127,9 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int 
> *depth,
> *bpp = 32;
> break;
> default:
> -   DRM_DEBUG_KMS("unsupported pixel format %s\n",
> - drm_get_format_name(format));
> +   format_name = drm_get_format_name(format);
> +   DRM_DEBUG_KMS("unsupported pixel format %s\n", format_name);
> +   kfree(format_name);
> *depth = 0;
> *bpp = 0;
> break;
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 7f90a39..030d22d 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -32,6 +32,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
>  int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
> -const char *drm_get_format_name(uint32_t format);
> +const char *drm_get_format_name(uint32_t format) __malloc;
>
>  #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index c1b04e9..0bf8959 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2071,6 +2071,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> +   const char *format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> @@ -2182,8 +2183,9 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
> bypass_lut = true;
>   

[Bug 98573] Mesa build fail since radeonsi: use PS epilog for monolithic shaders

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

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

--- Comment #2 from Andy Furniss  ---
(In reply to Nicolai Hähnle from comment #1)
> Yeah, this has been reported on IRC as well. I don't know why my build setup
> isn't affected by this. In any case,
> https://patchwork.freedesktop.org/patch/119816/ should fix it.

Yea, Ok with that, thanks.

-- 
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/20161103/fd4d815c/attachment.html>

[PATCH] drm: move check for min/max width/height for atomic drivers

[Rob Clark]

On Thu, Nov 3, 2016 at 2:32 PM, Ville Syrjälä
 wrote:
> On Thu, Nov 03, 2016 at 11:22:37AM -0400, Rob Clark wrote:
>> On Thu, Nov 3, 2016 at 10:55 AM, Ville Syrjälä
>>  wrote:
>> > On Thu, Nov 03, 2016 at 10:14:20AM -0400, Rob Clark wrote:
>> >> On Thu, Nov 3, 2016 at 10:12 AM, Ville Syrjälä
>> >>  wrote:
>> >> > On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
>> >> >> drm-hwc + android tries to create an fb for the wallpaper layer, which
>> >> >> is larger than the screen resolution, and potentially larger than
>> >> >> mode_config->max_{width,height}.  But the plane src_w/src_h is within
>> >> >> the max limits, so it is something the hardware can otherwise do.
>> >> >>
>> >> >> For atomic drivers, defer the check to drm_atomic_plane_check().
>> >> >>
>> >> >> Signed-off-by: Rob Clark 
>> >> >> ---
>> >> >>  drivers/gpu/drm/drm_atomic.c | 17 +
>> >> >>  drivers/gpu/drm/drm_crtc.c   | 26 +-
>> >> >>  2 files changed, 34 insertions(+), 9 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/drm_atomic.c 
>> >> >> b/drivers/gpu/drm/drm_atomic.c
>> >> >> index 34edd4f..fb0f07ce 100644
>> >> >> --- a/drivers/gpu/drm/drm_atomic.c
>> >> >> +++ b/drivers/gpu/drm/drm_atomic.c
>> >> >> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state 
>> >> >> *state,
>> >> >>  static int drm_atomic_plane_check(struct drm_plane *plane,
>> >> >>   struct drm_plane_state *state)
>> >> >>  {
>> >> >> + struct drm_mode_config *config = >dev->mode_config;
>> >> >>   unsigned int fb_width, fb_height;
>> >> >> + unsigned int min_width, max_width, min_height, max_height;
>> >> >>   int ret;
>> >> >>
>> >> >>   /* either *both* CRTC and FB must be set, or neither */
>> >> >> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct 
>> >> >> drm_plane *plane,
>> >> >>   return -ENOSPC;
>> >> >>   }
>> >> >>
>> >> >> + min_width = config->min_width << 16;
>> >> >> + max_width = config->max_width << 16;
>> >> >> + min_height = config->min_height << 16;
>> >> >> + max_height = config->max_height << 16;
>> >> >> +
>> >> >> + /* Make sure source dimensions are within bounds. */
>> >> >> + if (min_width > state->src_w || state->src_w > max_width ||
>> >> >> + min_height > state->src_h || state->src_h > max_height) {
>> >> >> + DRM_DEBUG_ATOMIC("Invalid source size "
>> >> >> +  "%u.%06ux%u.%06u\n",
>> >> >> +  state->src_w >> 16, ((state->src_w & 
>> >> >> 0x) * 15625) >> 10,
>> >> >> +  state->src_h >> 16, ((state->src_h & 
>> >> >> 0x) * 15625) >> 10);
>> >> >> + return -ERANGE;
>> >> >> + }
>> >> >> +
>> >> >>   if (plane_switching_crtc(state->state, plane, state)) {
>> >> >>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC 
>> >> >> directly\n",
>> >> >>plane->base.id, plane->name);
>> >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> >> index b4b973f..7294bde 100644
>> >> >> --- a/drivers/gpu/drm/drm_crtc.c
>> >> >> +++ b/drivers/gpu/drm/drm_crtc.c
>> >> >> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device 
>> >> >> *dev,
>> >> >>   return ERR_PTR(-EINVAL);
>> >> >>   }
>> >> >>
>> >> >> - if ((config->min_width > r->width) || (r->width > 
>> >> >> config->max_width)) {
>> >> >> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d 
>> >> >> && <= %d\n",
>> >> >> -   r->width, config->min_width, 
>> >> >> config->max_width);
>> >> >> - return ERR_PTR(-EINVAL);
>> >> >> - }
>> >> >> - if ((config->min_height > r->height) || (r->height > 
>> >> >> config->max_height)) {
>> >> >> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= 
>> >> >> %d && <= %d\n",
>> >> >> -   r->height, config->min_height, 
>> >> >> config->max_height);
>> >> >> - return ERR_PTR(-EINVAL);
>> >> >> + /* for atomic drivers, we check the src dimensions in
>> >> >> +  * drm_atomic_plane_check().. allow creation of a fb
>> >> >> +  * that is larger than what can be scanned out, as
>> >> >> +  * long as userspace doesn't try to scanout a portion
>> >> >> +  * of the fb that is too large.
>> >> >> +  */
>> >> >> + if (!file_priv->atomic) {
>> >> >> + if ((config->min_width > r->width) || (r->width > 
>> >> >> config->max_width)) {
>> >> >> + DRM_DEBUG_KMS("bad framebuffer width %d, should 
>> >> >> be >= %d && <= %d\n",
>> >> >> +   r->width, config->min_width, 
>> >> >> config->max_width);
>> >> >> + return ERR_PTR(-EINVAL);
>> >> >> + }
>> >> >> + if ((config->min_height > r->height) || (r->height > 
>> >> >> config->max_height)) {
>> >> >> +  

[PATCH 2/2] Revert "drm: Add aspect ratio parsing in DRM layer"

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

This reverts commit 6dffd431e2296cda08e7e4f0242e02df1d1698cd.

Adding new mode flags willy nilly breaks existing userspace. We need to
coordinate this better, potentially with a new client cap that only
exposes the aspect ratio flags when userspace is prepared for them
(similar to what we do with stereo 3D modes).

This also broke things so that we would always send out VIC==0 in
the AVI infoframe unless the user specified an aspect ratio via
the mode flags. And the automagic RGB full vs. limited range
handling was similartly broken as the user mode would never match
any CEA mode.

Cc: Shashank Sharma 
Cc: Lin, Jia 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 725faa6409aa..18442b5bb34c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1001,7 +1001,6 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
-   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1504,21 +1503,6 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
-   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
-
-   switch (in->picture_aspect_ratio) {
-   case HDMI_PICTURE_ASPECT_4_3:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
-   break;
-   case HDMI_PICTURE_ASPECT_16_9:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
-   break;
-   case HDMI_PICTURE_ASPECT_RESERVED:
-   default:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
-   break;
-   }
-
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1564,21 +1548,6 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;

-   /* Clearing picture aspect ratio bits from out flags */
-   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
-
-   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
-   case DRM_MODE_FLAG_PIC_AR_4_3:
-   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
-   break;
-   case DRM_MODE_FLAG_PIC_AR_16_9:
-   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
-   break;
-   default:
-   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
-   break;
-   }
-
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
2.7.4

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.

Adding new mode flags willy nilly breaks existing userspace. We need to
coordinate this better, potentially with a new client cap that only
exposes the aspect ratio flags when userspace is prepared for them
(similar to what we do with stereo 3D modes).

Cc: Shashank Sharma 
Cc: Lin, Jia 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 --
 2 files changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f64ac86deb84..725faa6409aa 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
-   case HDMI_PICTURE_ASPECT_64_27:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
-   break;
-   case DRM_MODE_PICTURE_ASPECT_256_135:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
-   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1580,12 +1574,6 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
-   case DRM_MODE_FLAG_PIC_AR_64_27:
-   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
-   break;
-   case DRM_MODE_FLAG_PIC_AR_256_135:
-   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
-   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 084b50a02dc5..5c142b1387ac 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,8 +81,6 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
-#define DRM_MODE_PICTURE_ASPECT_64_27  3
-#define DRM_MODE_PICTURE_ASPECT_256_1354

 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -92,10 +90,6 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
-#define  DRM_MODE_FLAG_PIC_AR_64_27 \
-   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
-#define  DRM_MODE_FLAG_PIC_AR_256_135 \
-   (DRM_MODE_PICTURE_ASPECT_256_135<<19)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
2.7.4

[Bug 98573] Mesa build fail since radeonsi: use PS epilog for monolithic shaders

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

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

--- Comment #1 from Nicolai Hähnle  ---
Yeah, this has been reported on IRC as well. I don't know why my build setup
isn't affected by this. In any case,
https://patchwork.freedesktop.org/patch/119816/ should fix it.

-- 
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/20161103/434d8517/attachment.html>

[Bug 98573] Mesa build fail since radeonsi: use PS epilog for monolithic shaders

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

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

Bug ID: 98573
   Summary: Mesa build fail since  radeonsi: use PS epilog for
monolithic shaders
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Making all in targets/pipe-loader
make[4]: Entering directory
'/mnt/sdb1/Gits/mesa/src/gallium/targets/pipe-loader'
  CXXLDpipe_radeonsi.la
../../../../src/gallium/drivers/radeonsi/.libs/libradeonsi.a(si_shader.o): In
function `si_build_wrapper_function':
/mnt/sdb1/Gits/mesa/src/gallium/drivers/radeonsi/si_shader.c:6861: undefined
reference to `ac_is_sgpr_param'
/mnt/sdb1/Gits/mesa/src/gallium/drivers/radeonsi/si_shader.c:6951: undefined
reference to `ac_is_sgpr_param'
collect2: error: ld returned 1 exit status

commit 7115e56c21ace07cf04f5073ba73a533e2182099
Author: Nicolai Hähnle 
Date:   Fri Oct 28 14:45:59 2016 +0200

radeonsi: use PS epilog for monolithic shaders

-- 
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/20161103/2c2c3e4f/attachment.html>

[PATCH 3/3] drm/amdgpu: return first signaled fence index in status parameter

[Alex Deucher]

From: "monk.liu" 

Return the index of the first signaled fence in the fences ioctl.
This information is useful in some APIs like Vulkan.

Signed-off-by: monk.liu 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 2 +-
 include/uapi/drm/amdgpu_drm.h  | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index f0c3c356..f748162 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1216,6 +1216,7 @@ static int amdgpu_cs_wait_any_fence(struct amdgpu_device 
*adev,
 {
unsigned long timeout = amdgpu_gem_timeout(wait->in.timeout_ns);
uint32_t fence_count = wait->in.fence_count;
+   uint32_t first = ~0;
struct fence **array;
unsigned i;
long r;
@@ -1241,13 +1242,14 @@ static int amdgpu_cs_wait_any_fence(struct 
amdgpu_device *adev,
}
}

-   r = fence_wait_any_timeout(array, fence_count, true, timeout);
+   r = fence_wait_any_timeout(array, fence_count, true, timeout, );
if (r < 0)
goto err_free_fence_array;

 out:
memset(wait, 0, sizeof(*wait));
wait->out.status = (r > 0);
+   wait->out.first_signaled = first;
/* set return value 0 to indicate success */
r = 0;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
index d8af37a..ed50d77 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
@@ -361,7 +361,7 @@ int amdgpu_sa_bo_new(struct amdgpu_sa_manager *sa_manager,
if (count) {
spin_unlock(_manager->wq.lock);
t = fence_wait_any_timeout(fences, count, false,
-  MAX_SCHEDULE_TIMEOUT);
+  MAX_SCHEDULE_TIMEOUT, NULL);
for (i = 0; i < count; ++i)
fence_put(fences[i]);

diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index b726095..bca630c 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -328,7 +328,8 @@ struct drm_amdgpu_wait_fences_in {
 };

 struct drm_amdgpu_wait_fences_out {
-   __u64 status;
+   __u32 status;
+   __u32 first_signaled;
 };

 union drm_amdgpu_wait_fences {
-- 
2.5.5

[PATCH 2/3] drm/amdgpu: add the interface of waiting multiple fences (v3)

[Alex Deucher]

From: Junwei Zhang 

v2: agd: rebase and squash in all the previous optimizations and
changes so everything compiles.
v3: squash in Slava's 32bit build fix

Signed-off-by: Junwei Zhang 
Reviewed-by: Monk Liu 
Reviewed-by: Jammy Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 171 
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |   1 +
 include/uapi/drm/amdgpu_drm.h   |  27 +
 4 files changed, 201 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8d0c689..c2050c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1214,6 +1214,8 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *filp);
 int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp);
 int amdgpu_cs_wait_ioctl(struct drm_device *dev, void *data, struct drm_file 
*filp);
+int amdgpu_cs_wait_fences_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);

 int amdgpu_gem_metadata_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4068504..f0c3c356 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1130,6 +1130,177 @@ int amdgpu_cs_wait_ioctl(struct drm_device *dev, void 
*data,
 }

 /**
+ * amdgpu_cs_get_fence - helper to get fence from drm_amdgpu_fence
+ *
+ * @adev: amdgpu device
+ * @filp: file private
+ * @user: drm_amdgpu_fence copied from user space
+ */
+static struct fence *amdgpu_cs_get_fence(struct amdgpu_device *adev,
+struct drm_file *filp,
+struct drm_amdgpu_fence *user)
+{
+   struct amdgpu_ring *ring;
+   struct amdgpu_ctx *ctx;
+   struct fence *fence;
+   int r;
+
+   r = amdgpu_cs_get_ring(adev, user->ip_type, user->ip_instance,
+  user->ring, );
+   if (r)
+   return ERR_PTR(r);
+
+   ctx = amdgpu_ctx_get(filp->driver_priv, user->ctx_id);
+   if (ctx == NULL)
+   return ERR_PTR(-EINVAL);
+
+   fence = amdgpu_ctx_get_fence(ctx, ring, user->seq_no);
+   amdgpu_ctx_put(ctx);
+
+   return fence;
+}
+
+/**
+ * amdgpu_cs_wait_all_fence - wait on all fences to signal
+ *
+ * @adev: amdgpu device
+ * @filp: file private
+ * @wait: wait parameters
+ * @fences: array of drm_amdgpu_fence
+ */
+static int amdgpu_cs_wait_all_fences(struct amdgpu_device *adev,
+struct drm_file *filp,
+union drm_amdgpu_wait_fences *wait,
+struct drm_amdgpu_fence *fences)
+{
+   uint32_t fence_count = wait->in.fence_count;
+   unsigned i;
+   long r = 1;
+
+   for (i = 0; i < fence_count; i++) {
+   struct fence *fence;
+   unsigned long timeout = amdgpu_gem_timeout(wait->in.timeout_ns);
+
+   fence = amdgpu_cs_get_fence(adev, filp, [i]);
+   if (IS_ERR(fence))
+   return PTR_ERR(fence);
+   else if (!fence)
+   continue;
+
+   r = fence_wait_timeout(fence, true, timeout);
+   if (r < 0)
+   return r;
+
+   if (r == 0)
+   break;
+   }
+
+   memset(wait, 0, sizeof(*wait));
+   wait->out.status = (r > 0);
+
+   return 0;
+}
+
+/**
+ * amdgpu_cs_wait_any_fence - wait on any fence to signal
+ *
+ * @adev: amdgpu device
+ * @filp: file private
+ * @wait: wait parameters
+ * @fences: array of drm_amdgpu_fence
+ */
+static int amdgpu_cs_wait_any_fence(struct amdgpu_device *adev,
+   struct drm_file *filp,
+   union drm_amdgpu_wait_fences *wait,
+   struct drm_amdgpu_fence *fences)
+{
+   unsigned long timeout = amdgpu_gem_timeout(wait->in.timeout_ns);
+   uint32_t fence_count = wait->in.fence_count;
+   struct fence **array;
+   unsigned i;
+   long r;
+
+   /* Prepare the fence array */
+   array = (struct fence **)kcalloc(fence_count, sizeof(struct fence *),
+   GFP_KERNEL);
+   if (array == NULL)
+   return -ENOMEM;
+
+   for (i = 0; i < fence_count; i++) {
+   struct fence *fence;
+
+   fence = amdgpu_cs_get_fence(adev, filp, [i]);
+   if (IS_ERR(fence)) {
+   r = PTR_ERR(fence);
+   goto err_free_fence_array;
+   } else if (fence) {
+   array[i] = fence;
+  

[PATCH 1/3] dma-buf: return index of the first signaled fence

[Alex Deucher]

From: "monk.liu" 

Return the index of the first signaled fence.  This information
is useful in some APIs like Vulkan.

Signed-off-by: monk.liu 
Signed-off-by: Alex Deucher 
Cc: Sumit Semwal 
---
 drivers/dma-buf/fence.c | 19 ++-
 include/linux/fence.h   |  2 +-
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 64478f9..32fdce1 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -397,14 +397,17 @@ out:
 EXPORT_SYMBOL(fence_default_wait);

 static bool
-fence_test_signaled_any(struct fence **fences, uint32_t count)
+fence_test_signaled_any(struct fence **fences, uint32_t count, uint32_t *idx)
 {
int i;

for (i = 0; i < count; ++i) {
struct fence *fence = fences[i];
-   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
+   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   if (idx)
+   *idx = i;
return true;
+   }
}
return false;
 }
@@ -416,6 +419,7 @@ fence_test_signaled_any(struct fence **fences, uint32_t 
count)
  * @count: [in]number of fences to wait on
  * @intr:  [in]if true, do an interruptible wait
  * @timeout:   [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
+ * @idx:   [out]   the first signaled fence index, meaninful only on 
Returns positive
  *
  * Returns -EINVAL on custom fence wait implementation, -ERESTARTSYS if
  * interrupted, 0 if the wait timed out, or the remaining timeout in jiffies
@@ -427,7 +431,7 @@ fence_test_signaled_any(struct fence **fences, uint32_t 
count)
  */
 signed long
 fence_wait_any_timeout(struct fence **fences, uint32_t count,
-  bool intr, signed long timeout)
+  bool intr, signed long timeout, uint32_t *idx)
 {
struct default_wait_cb *cb;
signed long ret = timeout;
@@ -438,8 +442,11 @@ fence_wait_any_timeout(struct fence **fences, uint32_t 
count,

if (timeout == 0) {
for (i = 0; i < count; ++i)
-   if (fence_is_signaled(fences[i]))
+   if (fence_is_signaled(fences[i])) {
+   if (idx)
+   *idx = i;
return 1;
+   }

return 0;
}
@@ -462,6 +469,8 @@ fence_wait_any_timeout(struct fence **fences, uint32_t 
count,
if (fence_add_callback(fence, [i].base,
   fence_default_wait_cb)) {
/* This fence is already signaled */
+   if (idx)
+   *idx = i;
goto fence_rm_cb;
}
}
@@ -472,7 +481,7 @@ fence_wait_any_timeout(struct fence **fences, uint32_t 
count,
else
set_current_state(TASK_UNINTERRUPTIBLE);

-   if (fence_test_signaled_any(fences, count))
+   if (fence_test_signaled_any(fences, count, idx))
break;

ret = schedule_timeout(ret);
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 44d945e..6a7e68a 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -327,7 +327,7 @@ static inline struct fence *fence_later(struct fence *f1, 
struct fence *f2)

 signed long fence_wait_timeout(struct fence *, bool intr, signed long timeout);
 signed long fence_wait_any_timeout(struct fence **fences, uint32_t count,
-  bool intr, signed long timeout);
+  bool intr, signed long timeout, uint32_t 
*idx);

 /**
  * fence_wait - sleep until the fence gets signaled
-- 
2.5.5

[Bug 67713] Freezes on Trinity 7500G

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

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

Mike Lothian  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #13 from Mike Lothian  ---
Hi Erik

You're probably best creating your own new bug and supply all the info required
for the dev's to investigate. I no longer have access to this hardware anymore
and your issues might be from a different bug

-- 
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/20161103/e1c063c8/attachment.html>

[Bug 93478] [amdgpu] [tonga] VM Faults and card lock up

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

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

Mike Lothian  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Mike Lothian  ---
This was fixed a long time ago

-- 
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/20161103/f3140d2d/attachment-0001.html>

[Bug 97248] [regression] [amdgpu] New regression in 4.8-rc1

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

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

Mike Lothian  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

-- 
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/20161103/aa3505e2/attachment.html>

[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled

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

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

Mike Lothian  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Mike Lothian  ---
Might as well close this now

-- 
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/20161103/90de0fe2/attachment.html>

[PATCH 2/2] Revert "drm: Add aspect ratio parsing in DRM layer"

[Sharma, Shashank]

NACK until we get to the right reason.

-Original Message-
From: ville.syrjala at linux.intel.com [mailto:ville.syrj...@linux.intel.com] 
Sent: Thursday, November 3, 2016 6:02 PM
To: dri-devel at lists.freedesktop.org
Cc: Sharma, Shashank ; Lin; Jia, Lin A ; Sharma, Akashdeep ; Jim Bride 
; Jose Abreu ; Daniel 
Vetter ; Emil Velikov 
Subject: [PATCH 2/2] Revert "drm: Add aspect ratio parsing in DRM layer"

From: Ville Syrjälä 

This reverts commit 6dffd431e2296cda08e7e4f0242e02df1d1698cd.

Adding new mode flags willy nilly breaks existing userspace. We need to 
coordinate this better, potentially with a new client cap that only exposes the 
aspect ratio flags when userspace is prepared for them (similar to what we do 
with stereo 3D modes).

This also broke things so that we would always send out VIC==0 in the AVI 
infoframe unless the user specified an aspect ratio via the mode flags. And the 
automagic RGB full vs. limited range handling was similartly broken as the user 
mode would never match any CEA mode.

Cc: Shashank Sharma 
Cc: Lin, Jia 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 
725faa6409aa..18442b5bb34c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1001,7 +1001,6 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
-   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1504,21 +1503,6 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
-   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
-
-   switch (in->picture_aspect_ratio) {
-   case HDMI_PICTURE_ASPECT_4_3:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
-   break;
-   case HDMI_PICTURE_ASPECT_16_9:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
-   break;
-   case HDMI_PICTURE_ASPECT_RESERVED:
-   default:
-   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
-   break;
-   }
-
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;  } @@ -1564,21 +1548,6 @@ int 
drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;

-   /* Clearing picture aspect ratio bits from out flags */
-   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
-
-   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
-   case DRM_MODE_FLAG_PIC_AR_4_3:
-   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
-   break;
-   case DRM_MODE_FLAG_PIC_AR_16_9:
-   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
-   break;
-   default:
-   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
-   break;
-   }
-
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
--
2.7.4

[PATCH v2] drm/rockchip: Use an enum to identify Rockchip VOPs

[Kristian H. Kristensen]

We used to call drm_of_encoder_active_endpoint_id() from
rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the
active encoder. However, the encoder isn't necessarily active at this
point or it may be connected to different crtc than what we're switching
to. Instead, look at the crtc from the drm_crtc_state.  This fixes wrong
colors when driving the eDP with the big VOP.  Further, we can identify
the type of VOP we're dealing with by just putting a VOP id enum in the
vop_data.

On way to test this is to use the modetest tool from libdrm:

  $ modetest -M rockchip -s 32 at 28:2400x1600

which displays dark or black colors because we fail to look up the
endpoint and use default 0 (which is ROCKCHIP_OUT_MODE_P888) for big
VOP instead of RGB10 as required.

For reference,

  $ modetest -M rockchip -s 32 at 25:2400x1600

drives the eDP from little VOP and displays correctly.

Signed-off-by: Kristian H. Kristensen 
---
v2: Stripped chromeos annotations, fix compile errors for drivers I didn't
compile when I first wrote the patch.

drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 45 ++---
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 19 +--
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 12 ---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  7 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  4 +++
 6 files changed, 56 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 558a3bc..9ae4a9c 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -196,14 +196,16 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
int ret;
u32 val;

-   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
-   if (ret < 0)
-   return;
-
-   if (ret)
+   switch (vop_get_crtc_vop_id(encoder->crtc)) {
+   case RK3399_VOP_LIT:
val = dp->data->lcdsel_lit;
-   else
+   break;
+   case RK3399_VOP_BIG:
val = dp->data->lcdsel_big;
+   break;
+   default:
+   return;
+   }

dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");

@@ -231,34 +233,23 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder 
*encoder,
  struct drm_connector_state *conn_state)
 {
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
-   struct rockchip_dp_device *dp = to_dp(encoder);
-   int ret;

-   /*
-* The hardware IC designed that VOP must output the RGB10 video
-* format to eDP contoller, and if eDP panel only support RGB8,
-* then eDP contoller should cut down the video data, not via VOP
-* contoller, that's why we need to hardcode the VOP output mode
-* to RGA10 here.
-*/
-
-   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
-   if (ret < 0)
-   return 0;
-
-   switch (dp->data->chip_type) {
-   case RK3399_EDP:
+   switch (vop_get_crtc_vop_id(crtc_state->crtc)) {
+   case RK3399_VOP_LIT:
/*
 * For RK3399, VOP Lit must code the out mode to RGB888,
 * VOP Big must code the out mode to RGB10.
 */
-   if (ret)
-   s->output_mode = ROCKCHIP_OUT_MODE_P888;
-   else
-   s->output_mode = ROCKCHIP_OUT_MODE_;
+   s->output_mode = ROCKCHIP_OUT_MODE_P888;
break;
-
default:
+   /*
+* The hardware IC designed that VOP must output the RGB10 video
+* format to eDP contoller, and if eDP panel only support RGB8,
+* then eDP contoller should cut down the video data, not via 
VOP
+* contoller, that's why we need to hardcode the VOP output mode
+* to RGA10 here.
+*/
s->output_mode = ROCKCHIP_OUT_MODE_;
break;
}
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index f020e2e..b9e6184 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -570,21 +570,20 @@ static void cdn_dp_encoder_mode_set(struct drm_encoder 
*encoder,
video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);

-   ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
-   if (ret < 0) {
-   DRM_DEV_ERROR(dp->dev, "Could not get vop id, %d", ret);
-   return;
-   }
-
-   DRM_DEV_DEBUG_KMS(dp->dev, "vop %s output to cdn-dp\n",
- 

[Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[Lyude Paul]

On Thu, 2016-11-03 at 16:25 +, Chris Wilson wrote:
> On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote:
> > 
> > On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote:
> > > 
> > > On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote:
> > > > 
> > > > 
> > > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > Weine's investigation on benchmarking the suspend/resume process
> > > > > pointed
> > > > > out a lot of the time in suspend/resume is being spent reprobing.
> > > > > While
> > > > > the reprobing process is a lengthy one for good reason, we don't need
> > > > > to
> > > > > hold up the entire suspend/resume process while we wait for it to
> > > > > finish. Luckily as it turns out, we already trigger a full connector
> > > > > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing
> > > > > in
> > > > > i915_drm_resume() entirely.
> > > > > 
> > > > > This won't lead to less time spent resuming just yet since now the
> > > > > bottleneck will be waiting for the mode_config lock in
> > > > > drm_kms_helper_poll_enable(), since that will be held as long as
> > > > > i915_hpd_poll_init_work() is reprobing all of the connectors. But
> > > > > we'll
> > > > > address that in the next patch.
> > > > > 
> > > > > Signed-off-by: Lyude 
> > > > > Cc: David Weinehall 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > index bfb2efd..532cc0f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device
> > > > > *dev)
> > > > >   * notifications.
> > > > >   * */
> > > > >  intel_hpd_init(dev_priv);
> > > > > - /* Config may have changed between suspend and resume */
> > > > > - drm_helper_hpd_irq_event(dev);
> > > > 
> > > > The comment is still apt. This code is known to be broken since it
> > > > doesn't detect a change in monitors (e.g. a change in external
> > > > connectors
> > > > from docking) between suspend and resend. We still have to send the
> > > > uevent.
> > > > 
> > > > +   drm_kms_helper_hotplug_event(dev);
> > > 
> > > I might not have explained myself very well. The way things should look
> > > with
> > > this patch is like this:
> > > 
> > > i915_drm_resume()
> > >  -> intel_hpd_init()
> > >    -> sets dev_priv->hotplug.poll_enabled to true
> > Whoops, s/true/false/
> > 
> > > 
> > >    -> schedules dev_priv->hotplug.poll_init_work
> > >  -> continue resume…
> > > 
> > > at the same time:
> > > 
> > > i915_hpd_poll_init_work() gets scheduled and starts
> > >  -> since dev_priv->hotplug.poll_enabled == false,
> > > drm_helper_hpd_irq_event()
> > > is called
> > >   -> drm_helper_hpd_irq_event() reprobes connectors
> > >    -> if anything changed, drm_kms_helper_hotplug_event() gets called.
> 
> drm_helper_hpd_irq_event() does not detect a change in monitors, for
> example, so there is no uevent in that case.

I still think you're mistaken (and I wouldn't blame you,
drm_helper_hpd_irq_event() has a rather misleading name). Contents
of drm_helper_hpd_irq_event()

bool drm_helper_hpd_irq_event(struct drm_device *dev)
{
struct drm_connector *connector;
enum drm_connector_status old_status;
bool changed = false;

if (!dev->mode_config.poll_enabled)
return false;

mutex_lock(>mode_config.mutex);
drm_for_each_connector(connector, dev) {

/* Only handle HPD capable connectors. */
if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;

old_status = connector->status;

connector->status = connector->funcs->detect(connector, false);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s\n",
      connector->base.id,
      connector->name,
      drm_get_connector_status_name(old_status),
      
drm_get_connector_status_name(connector->status));
if (old_status != connector->status)
changed = true;
}

mutex_unlock(>mode_config.mutex);

if (changed)
drm_kms_helper_hotplug_event(dev);

return changed;
}

Unless I made a mistake somewhere down the line of writing these: poll_enabled
will be set to true (due to the change done in the second patch where we move
the call for enabling polling up so that it gets called before
intel_hpd_init()), which causes it to go through all the connectors and call
connector->funcs->detect() (which will be intel_dp_detect(),
intel_hdmi_detect(), etc. And then send a uevent if their status 

[drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Christophe Fergeau]

On Thu, Nov 03, 2016 at 09:53:48AM +0100, Gerd Hoffmann wrote:
> On Mi, 2016-11-02 at 18:00 +0100, Christophe Fergeau wrote:
> > The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
> > the resolutions we are going to present to user-space are going to be
> > rounded down to a multiple of 8. In the QXL arbitrary resolution case,
> > this is not useful.
> > This commit forces the actual width/height that was requested by the
> > client in the drm_display_mode structure rather than keeping the
> > rounded version.
> 
> Hmm, not sure this is a good idea.  There are probably reasons why
> drm_cvt_mode is rounding down ...

Yeah, I'm sure there are reasons, but I don't know what they are.
drm_cvt_mode seems to be calculating various frequencies and timings
related to refreshing real world monitors, and this seems to be defined
by some VESA standard. Maybe the rounding down is because the real-world
monitors or VESA require it. Or maybe other parts of the
kernel/userspace rely on this rounding down. I unfortunately don't know
:( Any guidance there whether that's ok, or whether I should approach
this differently would be very useful.

Christophe
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161103/013280ea/attachment.sig>

[PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver

[Tomi Valkeinen]

On 02/11/16 18:32, Jyri Sarha wrote:
> Add very basic ti-ftp410 HDMI transmitter driver. The only feature

It's DVI encoder, not HDMI.

 Tomi

-- 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/20161103/e54fda85/attachment.sig>

[pull] radeon and amdgpu drm-fixes-4.9

[Alex Deucher]

Hi Dave,

A few more fixes for 4.9.

The following changes since commit a2941d01267437b6edcd3e769ae9a461fe36ae62:

  drm/amd/powerplay: fix bug get wrong evv voltage of Polaris. (2016-10-27 
13:59:36 -0400)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.9

for you to fetch changes up to 245ae5e915853ced749eb47a343749cf0a9c4109:

  drm/amdgpu: add some error handling to amdgpu_init v2 (2016-10-31 12:44:58 
-0400)


Alex Deucher (5):
  drm/amdgpu: add support for new smc firmware on tonga
  drm/amdgpu: add support for new smc firmware on iceland
  drm/radeon: disable runtime pm in certain cases
  drm/amdgpu: disable runtime pm in certain cases
  drm/amdgpu: make sure ddc_bus is valid in connector unregister

Christian König (2):
  drm/amd: fix scheduler fence teardown order v2
  drm/amdgpu: add some error handling to amdgpu_init v2

Grazvydas Ignotas (1):
  drm/amd/powerplay: don't succeed in getters if fan is missing

Larry Finger (1):
  drm/radeon: Fix kernel panic on shutdown

 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c| 13 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 26 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|  2 ++
 drivers/gpu/drm/amd/amdgpu/vi.c|  2 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_thermal.c |  6 ++---
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c  | 13 ---
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h  |  6 ++---
 drivers/gpu/drm/amd/scheduler/sched_fence.c| 19 
 drivers/gpu/drm/radeon/radeon_connectors.c |  2 +-
 drivers/gpu/drm/radeon/radeon_device.c | 13 +++
 11 files changed, 79 insertions(+), 25 deletions(-)

[Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[Lyude Paul]

On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote:
> On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote:
> > 
> > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> > > 
> > > 
> > > Weine's investigation on benchmarking the suspend/resume process pointed
> > > out a lot of the time in suspend/resume is being spent reprobing. While
> > > the reprobing process is a lengthy one for good reason, we don't need to
> > > hold up the entire suspend/resume process while we wait for it to
> > > finish. Luckily as it turns out, we already trigger a full connector
> > > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> > > i915_drm_resume() entirely.
> > > 
> > > This won't lead to less time spent resuming just yet since now the
> > > bottleneck will be waiting for the mode_config lock in
> > > drm_kms_helper_poll_enable(), since that will be held as long as
> > > i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> > > address that in the next patch.
> > > 
> > > Signed-off-by: Lyude 
> > > Cc: David Weinehall 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index bfb2efd..532cc0f 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
> > >   * notifications.
> > >   * */
> > >  intel_hpd_init(dev_priv);
> > > - /* Config may have changed between suspend and resume */
> > > - drm_helper_hpd_irq_event(dev);
> > 
> > The comment is still apt. This code is known to be broken since it
> > doesn't detect a change in monitors (e.g. a change in external connectors
> > from docking) between suspend and resend. We still have to send the uevent.
> > 
> > +   drm_kms_helper_hotplug_event(dev);
> 
> I might not have explained myself very well. The way things should look with
> this patch is like this:
> 
> i915_drm_resume()
>  -> intel_hpd_init()
>    -> sets dev_priv->hotplug.poll_enabled to true
Whoops, s/true/false/

>    -> schedules dev_priv->hotplug.poll_init_work
>  -> continue resume…
> 
> at the same time:
> 
> i915_hpd_poll_init_work() gets scheduled and starts
>  -> since dev_priv->hotplug.poll_enabled == false, drm_helper_hpd_irq_event()
> is called
>   -> drm_helper_hpd_irq_event() reprobes connectors
>    -> if anything changed, drm_kms_helper_hotplug_event() gets called.
> 
> So we're still polling the connectors when coming out of resume just like
> before, except now we're doing it without needlessly making the whole resume
> process stall until we're done. We're also no longer reprobing display
> connectors twice…
> 
> > 
> > 
> > which also depends upon us actually reseting the connector->status to
> > unknown in drm_mode_config_reset(), Daniel!
> > -Chris
> > 

[Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[Lyude Paul]

On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote:
> On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote:
> > 
> > Weine's investigation on benchmarking the suspend/resume process pointed
> > out a lot of the time in suspend/resume is being spent reprobing. While
> > the reprobing process is a lengthy one for good reason, we don't need to
> > hold up the entire suspend/resume process while we wait for it to
> > finish. Luckily as it turns out, we already trigger a full connector
> > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> > i915_drm_resume() entirely.
> > 
> > This won't lead to less time spent resuming just yet since now the
> > bottleneck will be waiting for the mode_config lock in
> > drm_kms_helper_poll_enable(), since that will be held as long as
> > i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> > address that in the next patch.
> > 
> > Signed-off-by: Lyude 
> > Cc: David Weinehall 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index bfb2efd..532cc0f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
> >     * notifications.
> >     * */
> >    intel_hpd_init(dev_priv);
> > -   /* Config may have changed between suspend and resume */
> > -   drm_helper_hpd_irq_event(dev);
> 
> The comment is still apt. This code is known to be broken since it
> doesn't detect a change in monitors (e.g. a change in external connectors
> from docking) between suspend and resend. We still have to send the uevent.
> 
> + drm_kms_helper_hotplug_event(dev);

I might not have explained myself very well. The way things should look with
this patch is like this:

i915_drm_resume()
 -> intel_hpd_init()
   -> sets dev_priv->hotplug.poll_enabled to true
   -> schedules dev_priv->hotplug.poll_init_work
 -> continue resume…

at the same time:

i915_hpd_poll_init_work() gets scheduled and starts
 -> since dev_priv->hotplug.poll_enabled == false, drm_helper_hpd_irq_event() 
is called
  -> drm_helper_hpd_irq_event() reprobes connectors
   -> if anything changed, drm_kms_helper_hotplug_event() gets called.

So we're still polling the connectors when coming out of resume just like
before, except now we're doing it without needlessly making the whole resume
process stall until we're done. We're also no longer reprobing display
connectors twice…

> 
> which also depends upon us actually reseting the connector->status to
> unknown in drm_mode_config_reset(), Daniel!
> -Chris
> 

[Bug 97402] AMDGPU/Iceland kernel panic on shutdown

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

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

Armin K  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Armin K  ---
Fixed in 4.9-rc2

-- 
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/20161103/db250b80/attachment-0001.html>

[PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

[Lyude]

Now that we don't run the connector reprobing from i915_drm_resume(), we
need to make it so we don't have to wait for reprobing to finish so that
we actually speed things up. In order to do this, we need to make sure
that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
while trying to acquire the mode_config lock that
drm_kms_helper_poll_enable() needs to acquire.

The easiest way to do this is to just enable polling before hpd. This
shouldn't break anything since at that point we have everything else we
need for polling enabled.

As well, this should result in a rather significant improvement in how
quickly we can resume the system.

Signed-off-by: Lyude 
Cc: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 532cc0f..f605dde 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1595,6 +1595,8 @@ static int i915_drm_resume(struct drm_device *dev)

intel_display_resume(dev);

+   drm_kms_helper_poll_enable(dev);
+
/*
 * ... but also need to make sure that hotplug processing
 * doesn't cause havoc. Like in the driver load code we don't
@@ -1614,7 +1616,6 @@ static int i915_drm_resume(struct drm_device *dev)
intel_opregion_notify_adapter(dev_priv, PCI_D0);

intel_autoenable_gt_powersave(dev_priv);
-   drm_kms_helper_poll_enable(dev);

enable_rpm_wakeref_asserts(dev_priv);

-- 
2.7.4

[PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

[Lyude]

Weine's investigation on benchmarking the suspend/resume process pointed
out a lot of the time in suspend/resume is being spent reprobing. While
the reprobing process is a lengthy one for good reason, we don't need to
hold up the entire suspend/resume process while we wait for it to
finish. Luckily as it turns out, we already trigger a full connector
reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
i915_drm_resume() entirely.

This won't lead to less time spent resuming just yet since now the
bottleneck will be waiting for the mode_config lock in
drm_kms_helper_poll_enable(), since that will be held as long as
i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
address that in the next patch.

Signed-off-by: Lyude 
Cc: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bfb2efd..532cc0f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
 * notifications.
 * */
intel_hpd_init(dev_priv);
-   /* Config may have changed between suspend and resume */
-   drm_helper_hpd_irq_event(dev);

intel_opregion_register(dev_priv);

-- 
2.7.4

[PATCH 0/2] Small fixes to speed up resume

[Lyude]

Recently David Weinehall has been investigating how we can make the resume
process in i915 faster, and poked me to take a look at why we were taking so
long while reprobing. As it turns out the main issue is just that we hold up
the entire resume process while we reprobe connectors, which isn't really
necessary. This fixes things so we can actually run the connector reprobing on
resume asynchronously.

Cc: David Weinehall 

Lyude (2):
  drm/i915: Remove redundant reprobe in i915_drm_resume
  drm/i915: Reinit polling before hpd when resuming

 drivers/gpu/drm/i915/i915_drv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH] drm: move check for min/max width/height for atomic drivers

[Rob Clark]

On Thu, Nov 3, 2016 at 10:55 AM, Ville Syrjälä
 wrote:
> On Thu, Nov 03, 2016 at 10:14:20AM -0400, Rob Clark wrote:
>> On Thu, Nov 3, 2016 at 10:12 AM, Ville Syrjälä
>>  wrote:
>> > On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
>> >> drm-hwc + android tries to create an fb for the wallpaper layer, which
>> >> is larger than the screen resolution, and potentially larger than
>> >> mode_config->max_{width,height}.  But the plane src_w/src_h is within
>> >> the max limits, so it is something the hardware can otherwise do.
>> >>
>> >> For atomic drivers, defer the check to drm_atomic_plane_check().
>> >>
>> >> Signed-off-by: Rob Clark 
>> >> ---
>> >>  drivers/gpu/drm/drm_atomic.c | 17 +
>> >>  drivers/gpu/drm/drm_crtc.c   | 26 +-
>> >>  2 files changed, 34 insertions(+), 9 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> >> index 34edd4f..fb0f07ce 100644
>> >> --- a/drivers/gpu/drm/drm_atomic.c
>> >> +++ b/drivers/gpu/drm/drm_atomic.c
>> >> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state *state,
>> >>  static int drm_atomic_plane_check(struct drm_plane *plane,
>> >>   struct drm_plane_state *state)
>> >>  {
>> >> + struct drm_mode_config *config = >dev->mode_config;
>> >>   unsigned int fb_width, fb_height;
>> >> + unsigned int min_width, max_width, min_height, max_height;
>> >>   int ret;
>> >>
>> >>   /* either *both* CRTC and FB must be set, or neither */
>> >> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct drm_plane 
>> >> *plane,
>> >>   return -ENOSPC;
>> >>   }
>> >>
>> >> + min_width = config->min_width << 16;
>> >> + max_width = config->max_width << 16;
>> >> + min_height = config->min_height << 16;
>> >> + max_height = config->max_height << 16;
>> >> +
>> >> + /* Make sure source dimensions are within bounds. */
>> >> + if (min_width > state->src_w || state->src_w > max_width ||
>> >> + min_height > state->src_h || state->src_h > max_height) {
>> >> + DRM_DEBUG_ATOMIC("Invalid source size "
>> >> +  "%u.%06ux%u.%06u\n",
>> >> +  state->src_w >> 16, ((state->src_w & 
>> >> 0x) * 15625) >> 10,
>> >> +  state->src_h >> 16, ((state->src_h & 
>> >> 0x) * 15625) >> 10);
>> >> + return -ERANGE;
>> >> + }
>> >> +
>> >>   if (plane_switching_crtc(state->state, plane, state)) {
>> >>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>> >>plane->base.id, plane->name);
>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> index b4b973f..7294bde 100644
>> >> --- a/drivers/gpu/drm/drm_crtc.c
>> >> +++ b/drivers/gpu/drm/drm_crtc.c
>> >> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device 
>> >> *dev,
>> >>   return ERR_PTR(-EINVAL);
>> >>   }
>> >>
>> >> - if ((config->min_width > r->width) || (r->width > 
>> >> config->max_width)) {
>> >> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && 
>> >> <= %d\n",
>> >> -   r->width, config->min_width, config->max_width);
>> >> - return ERR_PTR(-EINVAL);
>> >> - }
>> >> - if ((config->min_height > r->height) || (r->height > 
>> >> config->max_height)) {
>> >> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d 
>> >> && <= %d\n",
>> >> -   r->height, config->min_height, 
>> >> config->max_height);
>> >> - return ERR_PTR(-EINVAL);
>> >> + /* for atomic drivers, we check the src dimensions in
>> >> +  * drm_atomic_plane_check().. allow creation of a fb
>> >> +  * that is larger than what can be scanned out, as
>> >> +  * long as userspace doesn't try to scanout a portion
>> >> +  * of the fb that is too large.
>> >> +  */
>> >> + if (!file_priv->atomic) {
>> >> + if ((config->min_width > r->width) || (r->width > 
>> >> config->max_width)) {
>> >> + DRM_DEBUG_KMS("bad framebuffer width %d, should be 
>> >> >= %d && <= %d\n",
>> >> +   r->width, config->min_width, 
>> >> config->max_width);
>> >> + return ERR_PTR(-EINVAL);
>> >> + }
>> >> + if ((config->min_height > r->height) || (r->height > 
>> >> config->max_height)) {
>> >> + DRM_DEBUG_KMS("bad framebuffer height %d, should be 
>> >> >= %d && <= %d\n",
>> >> +   r->height, config->min_height, 
>> >> config->max_height);
>> >> + return ERR_PTR(-EINVAL);
>> >> + }
>> >
>> > So why not just bump max_foo in your driver?
>> >
>> > Removing the restriction from the core seems likely to break some
>> > drivers as they would now have to check the fb 

[PATCH] drm/amd/powerplay: return false instead of -EINVAL

[Andrew Shadura]

Returning -EINVAL from a bool-returning function
phm_check_smc_update_required_for_display_configuration has an unexpected
effect of returning true, which is probably not what was intended.
Replace -EINVAL by false.

The only place this function is called from is
psm_adjust_power_state_dynamic in
drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:

if (!equal || 
phm_check_smc_update_required_for_display_configuration(hwmgr)) {
phm_apply_state_adjust_rules(hwmgr, requested, pcurrent);
phm_set_power_state(hwmgr, >hardware, 
>hardware);
hwmgr->current_ps = requested;
}

It seems to expect a boolean value here.

This issue has been found using the following Coccinelle semantic patch
written by Peter Senna Tschudin:

@@
identifier f;
constant C;
typedef bool;
@@
bool f (...){
<+...
* return -C;
...+>
}


Signed-off-by: Andrew Shadura 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
index 789f98a..82038b08 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
@@ -306,7 +306,7 @@ bool 
phm_check_smc_update_required_for_display_configuration(struct pp_hwmgr *hw
PHM_FUNC_CHECK(hwmgr);

if 
(hwmgr->hwmgr_func->check_smc_update_required_for_display_configuration == NULL)
-   return -EINVAL;
+   return false;

return 
hwmgr->hwmgr_func->check_smc_update_required_for_display_configuration(hwmgr);
 }
-- 
2.7.4

[git pull] drm fixes for 4.9-rc4

[Dave Airlie]

Hi Linus,

Hope kernel summit is going well, this is a bit larger than I'd like,
but I had some stuff I meant to send for -rc3 but was waiting for the
PAT regression fix to land. So this is really fixes for rc3 and rc4 in
one go.

There are a set of fixes for an oops we've been seeing around MST
display unplug, along with more suspend/resume and shutdown fixes for
amdgpu, one power management follow on fix for nouveau, and set of imx
fixes, and a single virtio-gpu regression fix.

Dave.

The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.9-rc4

for you to fetch changes up to 7ec30fca2c966293c4593e20459861b106fd62e9:

  Merge tag 'drm-intel-fixes-2016-11-01' of
git://anongit.freedesktop.org/drm-intel into drm-fixes (2016-11-03
10:18:20 +1000)


drm fixes for amdgpu, radeon, intel, imx and virtio-gpu


Alex Deucher (10):
  drm/amdgpu/powerplay/smu7: fix static checker warning
  drm/amdgpu: drop atom scratch save/restore in gpu reset
  drm/amdgpu: move atom scratch register save/restore to common code
  drm/amdgpu/st: move ATC CG golden init from gfx to mc
  drm/amdgpu: explicitly set pg_flags for ST
  drm/amdgpu: cancel reset work on fini
  drm/amdgpu/dpm: flush any thermal work on fini
  drm/amdgpu/vce3: only enable 3 rings on new enough firmware (v2)
  drm/radeon/si_dpm: workaround for SI kickers
  drm/amdgpu/si_dpm: workaround for SI kickers

Arnd Bergmann (1):
  drm/imx: hide an unused label

Chris Wilson (1):
  drm/i915: Use fence_write() from rpm resume

Dan Carpenter (2):
  drm/imx: drm_dev_alloc() returns error pointers
  drm/i915: fix a read size argument

Daniel Stone (1):
  drm: i915: Wait for fences on new fb, not old

Dave Airlie (5):
  Merge tag 'drm-misc-fixes-2016-10-27' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.9' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge branch 'drm-fixes-staging' of
ssh://people.freedesktop.org/~/linux into drm-fixes
  Merge tag 'imx-drm-fixes-20161021' of
git://git.pengutronix.de/pza/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2016-11-01' of
git://anongit.freedesktop.org/drm-intel into drm-fixes

Evan Quan (1):
  drm/amd/amdgpu: expose max engine and memory clock for powerplay
enabled case

Felix Monninger (1):
  drm: Release reference from blob lookup after replacing property

Gerd Hoffmann (1):
  virtio-gpu: fix vblank events

Grazvydas Ignotas (5):
  drm/amd/powerplay: don't give up if DPM is already running
  drm/amdgpu: fix sched fence slab teardown
  drm/amdgpu: fix a vm_flush fence leak
  drm/amdgpu: update kernel-doc for some functions
  drm/amdgpu: fix fence slab teardown

Imre Deak (1):
  drm/i915: Fix mismatched INIT power domain disabling during suspend

Jani Nikula (2):
  drm/i915: keep declarations in i915_drv.h
  drm/i915: workaround sparse warning on variable length arrays

Liu Ying (3):
  drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset
  drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't need modeset
  drm/imx: ipuv3-plane: Access old u/vbo properly in
->atomic_check for YU12/YV12

Lucas Stach (1):
  drm/radeon: drop register readback in cayman_cp_int_cntl_setup

Michel Dänzer (1):
  Revert "drm/radeon: fix DP link training issue with second 4K monitor"

Paulo Zanoni (3):
  drm/i915/gen9: fix DDB partitioning for multi-screen cases
  drm/i915/gen9: fix watermarks when using the pipe scaler
  drm/i915/fbc: fix CFB size calculation for gen8+

Peter Wu (1):
  drm/nouveau/acpi: fix check for power resources support

Philipp Zabel (2):
  drm/imx: ipuv3-plane: make sure x/y offsets are even in case of
chroma subsampling
  drm/imx: ipuv3-plane: disable local alpha for planes without alpha channel

Rex Zhu (3):
  drm/amd/powerplay: fix static checker warning in process_pptables_v1_0.c
  drm/amdgpu: fix s3 resume back, uvd dpm randomly can't disable.
  drm/amd/powerplay: fix bug get wrong evv voltage of Polaris.

Takashi Iwai (1):
  drm/fb-helper: Don't call dirty callback for untouched clips

Tom St Denis (1):
  drm/radeon/si_dpm: Limit clocks on HD86xx part

Tvrtko Ursulin (2):
  drm/i915: Rotated view does not need a fence
  drm/i915: Remove two invalid warns

Ville Syrjälä (8):
  drm/fb-helper: Fix connector ref leak on error
  drm: Don't force all planes to be added to the state due to zpos
  drm/fb-helper: Keep references for the current set of used connectors
  drm/dp/mst: Clear port->pdt when tearing down the i2c adapter
  

[RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections

[Paul Bolle]

On Thu, 2016-11-03 at 02:16 -0700, Joe Perches wrote:
> Yes, it's been reported and should be fixed in -mm.
> The fix should show up in -next in a little bit.

Great.

> For now, try:
> $ sed -i -e 's/\xA0/ /g' scripts/get_maintainer.pl

Thanks,


Paul Bolle

[PATCH] drm: move check for min/max width/height for atomic drivers

[Rob Clark]

On Thu, Nov 3, 2016 at 10:12 AM, Ville Syrjälä
 wrote:
> On Wed, Nov 02, 2016 at 10:27:44AM -0400, Rob Clark wrote:
>> drm-hwc + android tries to create an fb for the wallpaper layer, which
>> is larger than the screen resolution, and potentially larger than
>> mode_config->max_{width,height}.  But the plane src_w/src_h is within
>> the max limits, so it is something the hardware can otherwise do.
>>
>> For atomic drivers, defer the check to drm_atomic_plane_check().
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/gpu/drm/drm_atomic.c | 17 +
>>  drivers/gpu/drm/drm_crtc.c   | 26 +-
>>  2 files changed, 34 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 34edd4f..fb0f07ce 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state *state,
>>  static int drm_atomic_plane_check(struct drm_plane *plane,
>>   struct drm_plane_state *state)
>>  {
>> + struct drm_mode_config *config = >dev->mode_config;
>>   unsigned int fb_width, fb_height;
>> + unsigned int min_width, max_width, min_height, max_height;
>>   int ret;
>>
>>   /* either *both* CRTC and FB must be set, or neither */
>> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct drm_plane 
>> *plane,
>>   return -ENOSPC;
>>   }
>>
>> + min_width = config->min_width << 16;
>> + max_width = config->max_width << 16;
>> + min_height = config->min_height << 16;
>> + max_height = config->max_height << 16;
>> +
>> + /* Make sure source dimensions are within bounds. */
>> + if (min_width > state->src_w || state->src_w > max_width ||
>> + min_height > state->src_h || state->src_h > max_height) {
>> + DRM_DEBUG_ATOMIC("Invalid source size "
>> +  "%u.%06ux%u.%06u\n",
>> +  state->src_w >> 16, ((state->src_w & 0x) 
>> * 15625) >> 10,
>> +  state->src_h >> 16, ((state->src_h & 0x) 
>> * 15625) >> 10);
>> + return -ERANGE;
>> + }
>> +
>>   if (plane_switching_crtc(state->state, plane, state)) {
>>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>>plane->base.id, plane->name);
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index b4b973f..7294bde 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device *dev,
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>> - if ((config->min_width > r->width) || (r->width > config->max_width)) {
>> - DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= 
>> %d\n",
>> -   r->width, config->min_width, config->max_width);
>> - return ERR_PTR(-EINVAL);
>> - }
>> - if ((config->min_height > r->height) || (r->height > 
>> config->max_height)) {
>> - DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && 
>> <= %d\n",
>> -   r->height, config->min_height, config->max_height);
>> - return ERR_PTR(-EINVAL);
>> + /* for atomic drivers, we check the src dimensions in
>> +  * drm_atomic_plane_check().. allow creation of a fb
>> +  * that is larger than what can be scanned out, as
>> +  * long as userspace doesn't try to scanout a portion
>> +  * of the fb that is too large.
>> +  */
>> + if (!file_priv->atomic) {
>> + if ((config->min_width > r->width) || (r->width > 
>> config->max_width)) {
>> + DRM_DEBUG_KMS("bad framebuffer width %d, should be >= 
>> %d && <= %d\n",
>> +   r->width, config->min_width, 
>> config->max_width);
>> + return ERR_PTR(-EINVAL);
>> + }
>> + if ((config->min_height > r->height) || (r->height > 
>> config->max_height)) {
>> + DRM_DEBUG_KMS("bad framebuffer height %d, should be >= 
>> %d && <= %d\n",
>> +   r->height, config->min_height, 
>> config->max_height);
>> + return ERR_PTR(-EINVAL);
>> + }
>
> So why not just bump max_foo in your driver?
>
> Removing the restriction from the core seems likely to break some
> drivers as they would now have to check the fb dimensions themselves.

that is why I did it only for atomic drivers, so we could rely on the
checking in drm_atomic_plane_check()..

BR,
-R

>>   }
>>
>>   if (r->flags & DRM_MODE_FB_MODIFIERS &&
>> --
>> 2.7.4
>
> --
> Ville Syrjälä
> Intel OTC

[RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections

[Paul Bolle]

On Mon, 2016-10-24 at 11:05 -0700, Joe Perches wrote:
> Jani Nikula proposes patches to add a few new letter prefixes
> for "B:" bug reporting and "C:" maintainer chatting to the
> various sections of MAINTAINERS.
> 
> Add a generic mechanism to get_maintainer.pl to find sections that
> have any combination of "[A-Z]" letter prefix types in a section.
> 
> Signed-off-by: Joe Perches 

This patch made it into linux-next (ie, next-20161028).

> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl

> @@ -271,7 +273,8 @@ $output_multiline = 0 if ($output_separator ne ", ");
>  $output_rolestats = 1 if ($interactive);
>  $output_roles = 1 if ($output_rolestats);
>  
> -if ($sections) {
> +if ($sections || $letters ne "") {
> +    $sections = 1;

This triggers:
    Unrecognized character \xA0; marked by <-- HERE after <-- HERE near 
column 1 at ./scripts/get_maintainer.pl line 277.

Git blame shows:
    git blame -L 277,+1 ./scripts/get_maintainer.pl
b67071653d3fc (Joe Perches 2016-10-28 13:22:01 +1100 277) 
$sections = 1;

(A0 seems to be the no break space. That character was inserted more
often further down the patch.)

Anybody else seeing this?


Paul Bolle

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Maxime Ripard]

Hi Russell,

On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> > The first one is that this overscanning should be reported by the
> > connector I guess? but this is really TV specific, so we need one way
> > to let the user tell how the image is displayed on its side, and we
> > cannot really autodetect it, and this needs to be done at runtime so
> > that we can present some shiny interface to let it select which
> > overscan ratio works for him/her.
> 
> See xbmc... they go through a nice shiny setup which includes adjusting
> the visible area.  From what I remember, it has pointers on each corner
> which you can adjust to be just visible on the screen, so xbmc knows
> how much overscan there is, and xbmc itself reduces down to the user
> set size.

Yes. And that is an XBMC only solution, that doesn't work with the
fbdev emulation and is probably doing an additional composition to
scale down and center their frames through OpenGL.

We might not have a GPU in the system, and we might not even have an
entire graphic stack on top either, so I don't think fixing at the
user-space level is a good option (especially since we already have an
overscan property in DRM).

> > The second one is that we still need to expose the reduced modes to
> > userspace, and not only the displayed size, so that the applications
> > know what they must draw on. But I guess this could be adjusted by the
> > core too.
> > 
> > In order to work consistently, I think all planes should be adjusted
> > that way, so that relative coordinates are from the primary plane
> > origin, and not the display origin. But that could be adjusted too by
> > the core I guess.
> 
> I'm not sure about that - we want the graphics to be visible, but that
> may not be appropriate for an video overlay frame.  It's quite common
> for (eg) broadcast video to contain dead pixels or other artifacts on
> the right hand side, and the broadcast video expects overscan to be
> present.
>
> I know this because I have run my TV with overscan disabled, even for
> broadcast TV.

I know, but on this particular hardware, composite really is just
another video output. There's not even a TV receiver in it, so I don't
think we have to worry about it.

> > The fourth one being the major one. Every time I raised the issue on
> > IRC, the answer basically was "we don't care about analog", so I'm a
> > bit pessimistic about whether dealing with this in the core would be
> > accepted, hence why I chose to deal with this at the driver level.
> 
> Yea, that's quite sad, "analog" has become a dirty word, but really
> this has nothing to do with "analog" at all - there are LCD TVs (and
> some monitors) out there which take HDMI signals but refuse to
> disable overscan no matter what you do to them if you provide them
> with a "broadcast"  mode - so the analog excuse is very poor.

I'd agree with you, but I was also told to not turn that into a
generic code and deal with that in my driver.

Do you have any suggestions?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161103/29a096c4/attachment.sig>

[PATCH] drm: move check for min/max width/height for atomic drivers

[Rob Clark]

On Wed, Nov 2, 2016 at 10:27 AM, Rob Clark  wrote:
> drm-hwc + android tries to create an fb for the wallpaper layer, which
> is larger than the screen resolution, and potentially larger than
> mode_config->max_{width,height}.  But the plane src_w/src_h is within
> the max limits, so it is something the hardware can otherwise do.
>
> For atomic drivers, defer the check to drm_atomic_plane_check().
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/drm_atomic.c | 17 +
>  drivers/gpu/drm/drm_crtc.c   | 26 +-
>  2 files changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 34edd4f..fb0f07ce 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -846,7 +846,9 @@ plane_switching_crtc(struct drm_atomic_state *state,
>  static int drm_atomic_plane_check(struct drm_plane *plane,
> struct drm_plane_state *state)
>  {
> +   struct drm_mode_config *config = >dev->mode_config;
> unsigned int fb_width, fb_height;
> +   unsigned int min_width, max_width, min_height, max_height;
> int ret;
>
> /* either *both* CRTC and FB must be set, or neither */
> @@ -909,6 +911,21 @@ static int drm_atomic_plane_check(struct drm_plane 
> *plane,
> return -ENOSPC;
> }
>
> +   min_width = config->min_width << 16;
> +   max_width = config->max_width << 16;
> +   min_height = config->min_height << 16;
> +   max_height = config->max_height << 16;
> +
> +   /* Make sure source dimensions are within bounds. */
> +   if (min_width > state->src_w || state->src_w > max_width ||
> +   min_height > state->src_h || state->src_h > max_height) {
> +   DRM_DEBUG_ATOMIC("Invalid source size "
> +"%u.%06ux%u.%06u\n",
> +state->src_w >> 16, ((state->src_w & 0x) 
> * 15625) >> 10,
> +state->src_h >> 16, ((state->src_h & 0x) 
> * 15625) >> 10);
> +   return -ERANGE;
> +   }
> +
> if (plane_switching_crtc(state->state, plane, state)) {
> DRM_DEBUG_ATOMIC("[PLANE:%d:%s] switching CRTC directly\n",
>  plane->base.id, plane->name);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b4b973f..7294bde 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3369,15 +3369,23 @@ internal_framebuffer_create(struct drm_device *dev,
> return ERR_PTR(-EINVAL);
> }
>
> -   if ((config->min_width > r->width) || (r->width > config->max_width)) 
> {
> -   DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && 
> <= %d\n",
> - r->width, config->min_width, config->max_width);
> -   return ERR_PTR(-EINVAL);
> -   }
> -   if ((config->min_height > r->height) || (r->height > 
> config->max_height)) {
> -   DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && 
> <= %d\n",
> - r->height, config->min_height, config->max_height);
> -   return ERR_PTR(-EINVAL);
> +   /* for atomic drivers, we check the src dimensions in
> +* drm_atomic_plane_check().. allow creation of a fb
> +* that is larger than what can be scanned out, as
> +* long as userspace doesn't try to scanout a portion
> +* of the fb that is too large.
> +*/
> +   if (!file_priv->atomic) {

btw, possibly we should loosen this restriction to just DRIVER_ATOMIC?
 It is a problem w/ x11 and multiple screens as well.

BR,
-R

> +   if ((config->min_width > r->width) || (r->width > 
> config->max_width)) {
> +   DRM_DEBUG_KMS("bad framebuffer width %d, should be >= 
> %d && <= %d\n",
> + r->width, config->min_width, 
> config->max_width);
> +   return ERR_PTR(-EINVAL);
> +   }
> +   if ((config->min_height > r->height) || (r->height > 
> config->max_height)) {
> +   DRM_DEBUG_KMS("bad framebuffer height %d, should be 
> >= %d && <= %d\n",
> + r->height, config->min_height, 
> config->max_height);
> +   return ERR_PTR(-EINVAL);
> +   }
> }
>
> if (r->flags & DRM_MODE_FB_MODIFIERS &&
> --
> 2.7.4
>

[PATCH 0/5] drm/sun4i: Handle TV overscan

[Russell King - ARM Linux]

On Thu, Nov 03, 2016 at 10:01:06AM +0100, Maxime Ripard wrote:
> Hi Russell,
> 
> On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote:
> > On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> > > The first one is that this overscanning should be reported by the
> > > connector I guess? but this is really TV specific, so we need one way
> > > to let the user tell how the image is displayed on its side, and we
> > > cannot really autodetect it, and this needs to be done at runtime so
> > > that we can present some shiny interface to let it select which
> > > overscan ratio works for him/her.
> > 
> > See xbmc... they go through a nice shiny setup which includes adjusting
> > the visible area.  From what I remember, it has pointers on each corner
> > which you can adjust to be just visible on the screen, so xbmc knows
> > how much overscan there is, and xbmc itself reduces down to the user
> > set size.

I was replying to your comment "so we need one way to let the user tell
how the image is displayed".

> Yes. And that is an XBMC only solution, that doesn't work with the
> fbdev emulation and is probably doing an additional composition to
> scale down and center their frames through OpenGL.

Well, it will have to be doing a scaling step anyway.  If the video
frame is a different size to the active area, scaling is required
no matter what.  A 576p SD image needs to be scaled up, and a 1080p
image would need to be scaled down for a 1080p overscanned display
with a reduced active area to counter the overscanning - no matter
how you do it.

For graphics, userspace could add mode(s) with increased porches and
reduced active area itself to achieve an underscanned display on a
timing which the display device always overscans - there's no need to
do that in the kernel, all the APIs are there to be able to do it
already.

That means your framebuffer will be smaller, but that's the case
anyway.

> > > The second one is that we still need to expose the reduced modes to
> > > userspace, and not only the displayed size, so that the applications
> > > know what they must draw on. But I guess this could be adjusted by the
> > > core too.
> > > 
> > > In order to work consistently, I think all planes should be adjusted
> > > that way, so that relative coordinates are from the primary plane
> > > origin, and not the display origin. But that could be adjusted too by
> > > the core I guess.
> > 
> > I'm not sure about that - we want the graphics to be visible, but that
> > may not be appropriate for an video overlay frame.  It's quite common
> > for (eg) broadcast video to contain dead pixels or other artifacts on
> > the right hand side, and the broadcast video expects overscan to be
> > present.
> >
> > I know this because I have run my TV with overscan disabled, even for
> > broadcast TV.
> 
> I know, but on this particular hardware, composite really is just
> another video output. There's not even a TV receiver in it, so I don't
> think we have to worry about it.

Whether or not there's a TV receiver is irrelevant - if you can decode
broadcast video, then you run into the problem.  For example, if you
plug in a USB DVB stick, stream it across the network, etc.

Remember, you're proposing a generic solution, so making arguments
about things that are not possible with your specific hardware isn't
really that relevant to a generic solution.

So, I may want my graphics to appear on an overscanned display such
that I can see the borders, but I may want the overlaid video to use
the full active area (including overscan) to hide some of the broadcast
mess at the edges of the screen.

> > Yea, that's quite sad, "analog" has become a dirty word, but really
> > this has nothing to do with "analog" at all - there are LCD TVs (and
> > some monitors) out there which take HDMI signals but refuse to
> > disable overscan no matter what you do to them if you provide them
> > with a "broadcast"  mode - so the analog excuse is very poor.
> 
> I'd agree with you, but I was also told to not turn that into a
> generic code and deal with that in my driver.

I guess whoever told you that was wrong.  I used to have a cheap TV
here which took HDMI, and always overscans broadcast modes, and
underscans PC modes.  No amount of fiddling with various settings
(either in the TV or AVI frames) changes that.

I've run into that with a _monitor_ that Andrew Hutton has, which has
a HDMI input - exactly the same thing - 1080p, 720p etc are all
unconditionally overscanned, 1024x768 etc are all unconditionally
underscanned and there's nothing that can be done to change it.

The problem is that TVs are at liberty to have this behaviour, so
the overscaned problem is always going to be there, and each driver
should not be dealing with it in their own specific ways.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[drm/qxl v2 7/7] qxl: Allow resolution which are not multiple of 8

[Gerd Hoffmann]

On Mi, 2016-11-02 at 18:00 +0100, Christophe Fergeau wrote:
> The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
> the resolutions we are going to present to user-space are going to be
> rounded down to a multiple of 8. In the QXL arbitrary resolution case,
> this is not useful.
> This commit forces the actual width/height that was requested by the
> client in the drm_display_mode structure rather than keeping the
> rounded version.

Hmm, not sure this is a good idea.  There are probably reasons why
drm_cvt_mode is rounding down ...

cheers,
  Gerd