Re: [Intel-gfx] [PATCH v2] PM / runtime: Add new helper for conditional usage count incrementation

[Ulf Hansson]

On 17 December 2015 at 02:54, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
> that will increment the device's runtime PM usage counter and
> return 'true' if its status is RPM_ACTIVE and its usage counter
> is greater than 0 at the same time ('false' will be returned
> otherwise).
>
> This is useful for things that should only be done if the device
> is active (from the runtime PM perspective) and used by somebody
> (as indicated by the usage counter) already and they are not worth
> bothering otherwise.
>
> Requested-by: Imre Deak 
> Signed-off-by: Rafael J. Wysocki 

Reviewed-by: Ulf Hansson 

Kind regards
Uffe

> ---
>
> Changes from v1:
> - kerneldoc and runtime PM doc changes as suggested by Alan.
> - The new function returns an int now and -EINVAL is returned for devices
>   with runtime PM disabled.
>
> ---
>  Documentation/power/runtime_pm.txt |6 ++
>  drivers/base/power/runtime.c   |   24 
>  include/linux/pm_runtime.h |5 +
>  3 files changed, 35 insertions(+)
>
> Index: linux-pm/drivers/base/power/runtime.c
> ===
> --- linux-pm.orig/drivers/base/power/runtime.c
> +++ linux-pm/drivers/base/power/runtime.c
> @@ -966,6 +966,30 @@ int __pm_runtime_resume(struct device *d
>  EXPORT_SYMBOL_GPL(__pm_runtime_resume);
>
>  /**
> + * pm_runtime_get_if_in_use - Conditionally bump up the device's usage 
> counter.
> + * @dev: Device to handle.
> + *
> + * Return -EINVAL if runtime PM is disabled for the device.
> + *
> + * If that's not the case and if the device's runtime PM status is RPM_ACTIVE
> + * and the runtime PM usage counter is nonzero, increment the counter and
> + * return 1.  Otherwise return 0 without changing the counter.
> + */
> +int pm_runtime_get_if_in_use(struct device *dev)
> +{
> +   unsigned long flags;
> +   int retval;
> +
> +   spin_lock_irqsave(>power.lock, flags);
> +   retval = dev->power.disable_depth > 0 ? -EINVAL :
> +   dev->power.runtime_status == RPM_ACTIVE
> +   && atomic_inc_not_zero(>power.usage_count);
> +   spin_unlock_irqrestore(>power.lock, flags);
> +   return retval;
> +}
> +EXPORT_SYMBOL_GPL(pm_runtime_get_if_in_use);
> +
> +/**
>   * __pm_runtime_set_status - Set runtime PM status of a device.
>   * @dev: Device to handle.
>   * @status: New runtime PM status of the device.
> Index: linux-pm/include/linux/pm_runtime.h
> ===
> --- linux-pm.orig/include/linux/pm_runtime.h
> +++ linux-pm/include/linux/pm_runtime.h
> @@ -39,6 +39,7 @@ extern int pm_runtime_force_resume(struc
>  extern int __pm_runtime_idle(struct device *dev, int rpmflags);
>  extern int __pm_runtime_suspend(struct device *dev, int rpmflags);
>  extern int __pm_runtime_resume(struct device *dev, int rpmflags);
> +extern int pm_runtime_get_if_in_use(struct device *dev);
>  extern int pm_schedule_suspend(struct device *dev, unsigned int delay);
>  extern int __pm_runtime_set_status(struct device *dev, unsigned int status);
>  extern int pm_runtime_barrier(struct device *dev);
> @@ -143,6 +144,10 @@ static inline int pm_schedule_suspend(st
>  {
> return -ENOSYS;
>  }
> +static inline int pm_runtime_get_if_in_use(struct device *dev)
> +{
> +   return -EINVAL;
> +}
>  static inline int __pm_runtime_set_status(struct device *dev,
> unsigned int status) { return 0; }
>  static inline int pm_runtime_barrier(struct device *dev) { return 0; }
> Index: linux-pm/Documentation/power/runtime_pm.txt
> ===
> --- linux-pm.orig/Documentation/power/runtime_pm.txt
> +++ linux-pm/Documentation/power/runtime_pm.txt
> @@ -371,6 +371,12 @@ drivers/base/power/runtime.c and include
>  - increment the device's usage counter, run pm_runtime_resume(dev) and
>return its result
>
> +  int pm_runtime_get_if_in_use(struct device *dev);
> +- return -EINVAL if 'power.disable_depth' is nonzero; otherwise, if the
> +  runtime PM status is RPM_ACTIVE and the runtime PM usage counter is
> +  nonzero, increment the counter and return 1; otherwise return 0 without
> +  changing the counter
> +
>void pm_runtime_put_noidle(struct device *dev);
>  - decrement the device's usage counter
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] dim: Add support for native git worktrees

[Daniel Vetter]

git 2.5 gained native support for worktrees, so let's use them.

Since this is fairly new I don't think we should switch the general
dim setup over to using it (for e.g. the maintainer-tools and other
auxiliary branches) since 2.5 was only released July 2015.

Signed-off-by: Daniel Vetter 
---
 dim | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index e30fc84a8567..854b5a61b399 100755
--- a/dim
+++ b/dim
@@ -556,7 +556,14 @@ function create_workdir
 
echo Creating separate workdir for $branch
 
-   $DRY git-new-workdir ${DIM_DRM_INTEL} $branch $branch
+   if git help worktree &> /dev/null; then
+   # native worktree support was added in git 2.5
+   cd $DIM_DRM_INTEL
+   $DRY git worktree add $DIM_PREFIX/$branch $branch
+   cd $DIM_PREFIX
+   else
+   $DRY git-new-workdir $DIM_DRM_INTEL $branch $branch
+   fi
done
 }
 
-- 
2.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 9/9] drm/atomic: Add encoder_mask to crtc_state.

[Maarten Lankhorst]

Op 15-12-15 om 10:17 schreef Daniel Vetter:
> On Mon, Dec 14, 2015 at 01:06:12PM +0100, Maarten Lankhorst wrote:
>> Op 04-12-15 om 09:12 schreef Daniel Vetter:
>>> On Thu, Dec 03, 2015 at 12:01:02PM +0100, Maarten Lankhorst wrote:
 Op 03-12-15 om 10:53 schreef Daniel Vetter:
> On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote:
>> This allows iteration over encoders without requiring connection_mutex.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c  | 4 
>>  drivers/gpu/drm/i915/intel_display.c | 3 +++
>>  include/drm/drm_crtc.h   | 2 ++
>>  3 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index fb79c54b2aed..f3fd8f131f92 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -269,6 +269,8 @@ mode_fixup(struct drm_atomic_state *state)
>>  continue;
>>  
>>  drm_mode_copy(_state->adjusted_mode, 
>> _state->mode);
>> +
>> +crtc_state->encoder_mask = 0;
> Hm, I think a small function to set the best_encoder (like we do to set
> the crtc for connector or planes) would be good. Otherwise we'll frob
> around the code and forget this, and much confusion will ensue.
>
> That helper should probably be in core drm_atomic.c, like the other
> set_foo_for_bar helpers.
 As always only i915 assigns best_encoder outside 
 drm_atomic_helper_check_modeset, and the i915 calls can't be fixed because 
 of hw readout. :(
 At the time of mode_fixup all encoders should have been updated, so I'm 
 not sure adding a helper for best_encoder would help much..
>>> I've meant just for the atomic helpers. i915 is a mess, yes, but that's
>>> not really an excuse to not make shared code pretty ;-)
>>>
>> It's not really possible to do it in a helper. The encoder might be
>> moved with the connector, or have a fixed mapping depending on crtc.
>> (i915 MST)
>>
>> So unfortunately there can be no generic helper, but it has to be dealt
>> with in this function, when assigning best_encoder per crtc.
> I meant a drm_atomic_set_best_encoder function, which sets both
> best_encoder and updates the encoder_mask for the crtc. Why would that not
> work? Of course actually figuring out what the best_encoder is would not
> be done by that function, it would only update the book-keeping. And then
> we could reuse it in our state reconstruction code too.
How do you want to do this race free in case of a fixed mapping of encoder to 
crtc?

MST display, con 1 & 2 with enc 1 & 2 and crtc 1 & 2.

crtc1 has con1 and enc1
crtc2 has con2 and enc2

Modeset with con1 moved to crtc2, and con2 to crtc1.

No matter what order you use, if you clear anything in 
drm_atomic_set_best_encoder you would have a mismatch here.

con1 first mapped to enc2:

crtc1->encoder_mask = 0
crtc2->encoder_mask = enc2 | enc2 = enc2

con2 mapped to enc1, it was previously mapped to enc2, so lets clear it..:
crtc1->encoder_mask = enc1.
crtc2->encoder_mask = 0 <-- Oops!

Same story if you do con2 first.

This is why I chose to clear encoder_mask in mode_fixup instead.

~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 9/9] drm/atomic: Add encoder_mask to crtc_state.

[Daniel Vetter]

On Thu, Dec 17, 2015 at 10:06:53AM +0100, Maarten Lankhorst wrote:
> Op 15-12-15 om 10:17 schreef Daniel Vetter:
> > On Mon, Dec 14, 2015 at 01:06:12PM +0100, Maarten Lankhorst wrote:
> >> Op 04-12-15 om 09:12 schreef Daniel Vetter:
> >>> On Thu, Dec 03, 2015 at 12:01:02PM +0100, Maarten Lankhorst wrote:
>  Op 03-12-15 om 10:53 schreef Daniel Vetter:
> > On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote:
> >> This allows iteration over encoders without requiring connection_mutex.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/drm_atomic_helper.c  | 4 
> >>  drivers/gpu/drm/i915/intel_display.c | 3 +++
> >>  include/drm/drm_crtc.h   | 2 ++
> >>  3 files changed, 9 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index fb79c54b2aed..f3fd8f131f92 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -269,6 +269,8 @@ mode_fixup(struct drm_atomic_state *state)
> >>continue;
> >>  
> >>drm_mode_copy(_state->adjusted_mode, 
> >> _state->mode);
> >> +
> >> +  crtc_state->encoder_mask = 0;
> > Hm, I think a small function to set the best_encoder (like we do to set
> > the crtc for connector or planes) would be good. Otherwise we'll frob
> > around the code and forget this, and much confusion will ensue.
> >
> > That helper should probably be in core drm_atomic.c, like the other
> > set_foo_for_bar helpers.
>  As always only i915 assigns best_encoder outside 
>  drm_atomic_helper_check_modeset, and the i915 calls can't be fixed 
>  because of hw readout. :(
>  At the time of mode_fixup all encoders should have been updated, so I'm 
>  not sure adding a helper for best_encoder would help much..
> >>> I've meant just for the atomic helpers. i915 is a mess, yes, but that's
> >>> not really an excuse to not make shared code pretty ;-)
> >>>
> >> It's not really possible to do it in a helper. The encoder might be
> >> moved with the connector, or have a fixed mapping depending on crtc.
> >> (i915 MST)
> >>
> >> So unfortunately there can be no generic helper, but it has to be dealt
> >> with in this function, when assigning best_encoder per crtc.
> > I meant a drm_atomic_set_best_encoder function, which sets both
> > best_encoder and updates the encoder_mask for the crtc. Why would that not
> > work? Of course actually figuring out what the best_encoder is would not
> > be done by that function, it would only update the book-keeping. And then
> > we could reuse it in our state reconstruction code too.
> How do you want to do this race free in case of a fixed mapping of encoder to 
> crtc?
> 
> MST display, con 1 & 2 with enc 1 & 2 and crtc 1 & 2.
> 
> crtc1 has con1 and enc1
> crtc2 has con2 and enc2
> 
> Modeset with con1 moved to crtc2, and con2 to crtc1.
> 
> No matter what order you use, if you clear anything in 
> drm_atomic_set_best_encoder you would have a mismatch here.
> 
> con1 first mapped to enc2:
> 
> crtc1->encoder_mask = 0
> crtc2->encoder_mask = enc2 | enc2 = enc2
> 
> con2 mapped to enc1, it was previously mapped to enc2, so lets clear it..:
> crtc1->encoder_mask = enc1.
> crtc2->encoder_mask = 0 <-- Oops!
> 
> Same story if you do con2 first.
> 
> This is why I chose to clear encoder_mask in mode_fixup instead.

With the recent fix to reassing encoders only once this should work, since
it's really 4 steps:

1. steal enc2  from crtc2. We already figure out which connector enc2 has
used, and by looking at con2->state->crtc we can get at the old crtc. So
should be easy to clear crtc2_state->encoder_mask to no longer contain
enc2. I.e. we have enc2, conn2 as known, so just do:

get_crtc_state(conn2->state->crtc)->encoder_mask &= ~encoder_id(enc2);

2. We notice that conn1 already has a encoder assigned (enc1), and we need
to clear that first. This step is new (well we could hide it in the
set_best_encoder function), but works exactly like step 1.

3. add enc2 to crtc1: That's the easy part, just or in the new bit. Easy:

crtc1_sate->encoder_mask |= encoder_id(enc2);   

With this enc2 is updated, and enc1 is cleared everywhere, including
encoder_masks.

4. add enc1 for con1 like step 3.

The important bit is simply to not overwrite a pointer before clearing the
mask for the old value completely. If you look at set_crtc_* funcs that's
exactly what they're doing. And since we can always get at the old state
it should always be possible to clear out the old mask.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Clearing buffer objects via CPU/GTT

[Tvrtko Ursulin]

Hi,

On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:

From: Ankitprasad Sharma 

This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
region.

v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
variable assignments (Tvrtko)

v3: Map object page by page to the gtt if the pinning of the whole object
to the ggtt fails, Corrected function name (Chris)

v4: Clear the buffer page by page, and not map the whole object in the gtt
aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.

Testcase: igt/gem_stolen

Signed-off-by: Ankitprasad Sharma 
---
  drivers/gpu/drm/i915/i915_drv.h |  1 +
  drivers/gpu/drm/i915/i915_gem.c | 44 +
  2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a10b866..e195fee 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2897,6 +2897,7 @@ int i915_gem_obj_prepare_shmem_read(struct 
drm_i915_gem_object *obj,
int *needs_clflush);

  int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+int i915_gem_object_clear(struct drm_i915_gem_object *obj);

  static inline int __sg_page_count(struct scatterlist *sg)
  {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 46c1e75..e50a91b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5293,3 +5293,47 @@ fail:
drm_gem_object_unreference(>base);
return ERR_PTR(ret);
  }
+
+/**
+ * i915_gem_object_clear() - Clear buffer object via CPU/GTT
+ * @obj: Buffer object to be cleared
+ *
+ * Return: 0 - success, non-zero - failure
+ */
+int i915_gem_object_clear(struct drm_i915_gem_object *obj)
+{
+   int ret, i;
+   char __iomem *base;
+   size_t size = obj->base.size;
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct drm_mm_node node;
+
+   lockdep_assert_held(>base.dev->struct_mutex);
+   memset(, 0, sizeof(node));
+   ret = i915_gem_insert_node_in_range(i915, , 4096, 0,


Use PAGE_SIZE instead of 4096 since it is used it the for loop below?


+   0, i915->gtt.mappable_end);
+   if (ret)
+   goto out;
+
+   i915_gem_object_pin_pages(obj);


Does it need a call to i915_gem_object_get_pages to work with all 
objects in all scenarios?



+   base = io_mapping_map_wc(i915->gtt.mappable, node.start);
+   for (i = 0; i < size/PAGE_SIZE; i++) {
+   wmb();
+   i915->gtt.base.insert_page(>gtt.base,
+  i915_gem_object_get_dma_address(obj, 
i),
+  node.start,
+  I915_CACHE_NONE, 0);
+   wmb();
+   memset_io(base, 0, 4096);


Again, maybe also use PAGE_SIZE so it is consistent with the for loop?


+   }
+
+   wmb();
+   io_mapping_unmap(base);
+   i915->gtt.base.clear_range(>gtt.base,
+   node.start, node.size,
+   true);
+   drm_mm_remove_node();
+   i915_gem_object_unpin_pages(obj);
+out:
+   return ret;
+}



Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/11] drm/i915/opregion: handle VBT sizes bigger than 6 KB

[Jani Nikula]

On Thu, 17 Dec 2015, Mika Kahola  wrote:
> On Mon, 2015-12-14 at 12:50 +0200, Jani Nikula wrote:
>> The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
>> mailbox may specify an alternate location for VBT instead of mailbox #4.
>> Use the alternate location if available and valid, falling back to
>> mailbox #4 otherwise.
>> 
> Tested-by: Mika Kahola 
>> Signed-off-by: Jani Nikula 

Pushed to drm-intel-next-queued, thanks for the review and testing.

BR,
Jani.


>> ---
>>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>>  drivers/gpu/drm/i915/intel_opregion.c | 25 +++--
>>  2 files changed, 24 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index ca8c2a64bc6d..8cfac7398568 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -457,6 +457,7 @@ struct intel_opregion {
>>  u32 swsci_gbda_sub_functions;
>>  u32 swsci_sbcb_sub_functions;
>>  struct opregion_asle *asle;
>> +void *rvda;
>>  const void *vbt;
>>  u32 vbt_size;
>>  u32 *lid_state;
>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
>> b/drivers/gpu/drm/i915/intel_opregion.c
>> index e89ee2383fe1..a139889dd45b 100644
>> --- a/drivers/gpu/drm/i915/intel_opregion.c
>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>> @@ -837,6 +837,10 @@ void intel_opregion_fini(struct drm_device *dev)
>>  
>>  /* just clear all opregion memory pointers now */
>>  memunmap(opregion->header);
>> +if (opregion->rvda) {
>> +memunmap(opregion->rvda);
>> +opregion->rvda = NULL;
>> +}
>>  opregion->header = NULL;
>>  opregion->acpi = NULL;
>>  opregion->swsci = NULL;
>> @@ -987,12 +991,29 @@ int intel_opregion_setup(struct drm_device *dev)
>>  DRM_DEBUG_DRIVER("ASLE extension supported\n");
>>  
>>  if (!dmi_check_system(intel_no_opregion_vbt)) {
>> -const void *vbt = base + OPREGION_VBT_OFFSET;
>> -u32 vbt_size = OPREGION_ASLE_EXT_OFFSET - OPREGION_VBT_OFFSET;
>> +const void *vbt = NULL;
>> +u32 vbt_size = 0;
>> +
>> +if (opregion->header->opregion_ver >= 2 && opregion->asle &&
>> +opregion->asle->rvda && opregion->asle->rvds) {
>> +opregion->rvda = memremap(opregion->asle->rvda,
>> +  opregion->asle->rvds,
>> +  MEMREMAP_WB);
>> +vbt = opregion->rvda;
>> +vbt_size = opregion->asle->rvds;
>> +}
>>  
>>  if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
>>  opregion->vbt = vbt;
>>  opregion->vbt_size = vbt_size;
>> +DRM_DEBUG_DRIVER("VBT from RVDA\n");
>> +} else {
>> +vbt = base + OPREGION_VBT_OFFSET;
>> +vbt_size = OPREGION_ASLE_EXT_OFFSET - 
>> OPREGION_VBT_OFFSET;
>> +if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
>> +opregion->vbt = vbt;
>> +opregion->vbt_size = vbt_size;
>> +}
>>  }
>>  }
>>  
>
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Allow use of get_dma_address for stolen backed objects

[Tvrtko Ursulin]

On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:

From: Ankitprasad Sharma 

i915_gem_object_get_dma_address function is used to retrieve the dma address
of a particular page so as to map it in a given GTT entry for CPU access.
This function would be used for stolen backed objects also for tasks like
pwrite,  clearing of the pages etc. So the obj->get_page.sg needs to be
initialized for the stolen objects also.

Signed-off-by: Ankitprasad Sharma 
---
  drivers/gpu/drm/i915/i915_gem_stolen.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 598ed2f..5384767 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -569,6 +569,9 @@ _i915_gem_object_create_stolen(struct drm_device *dev,
if (obj->pages == NULL)
goto cleanup;

+   obj->get_page.sg = obj->pages->sgl;
+   obj->get_page.last = 0;
+
i915_gem_object_pin_pages(obj);
obj->stolen = stolen;




Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Mark the context and address space as closed

[Chris Wilson]

On Thu, Dec 17, 2015 at 12:37:13PM +, Tvrtko Ursulin wrote:
> >-static void i915_vma_close(struct i915_vma *vma)
> 
> Can't find this in this series?

Should be the previous patch (9/11: Release vma when the handle is
closed) that hooks in gem_object_close to mark each vma as closed if it
is owned by the file.

http://patchwork.freedesktop.org/patch/68086/

> >diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> >b/drivers/gpu/drm/i915/i915_gem_context.c
> >index c4a8a64cd1b2..9669547c7c2d 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_context.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
> > struct intel_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
> >
> > trace_i915_context_free(ctx);
> >+RQ_BUG_ON(!ctx->closed);
> 
> Normal BUG_ON I think.

You want a BUG_ON! :-p Just enable them.

> >+for (phase = phases; *phase; phase++) {
> >+struct i915_vma *vma, *vn;
> >+
> >+list_for_each_entry_safe(vma, vn, *phase, vm_link)
> >+i915_vma_close(vma);
> 
> Can't really carry on since I don't see the implementation of this.
> 
> Does it wait for retirement?

No. i915_vma_close() uses vma tracking to defer the unbind until idle.

> >+/**
> >+ * List of vma that have been unbound.
> >+ *
> >+ * A reference is not held on the buffer while on this list.
> 
> s/buffer/object/

They are buffer objects! The comment was cut'n'paste. I don't think it
is entirely apt to be talking about the object level active reference
here anyway. But I didn't feel inclined to write something that was even
more confusing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Mark the context and address space as closed

[Tvrtko Ursulin]

On 17/12/15 12:48, Chris Wilson wrote:

On Thu, Dec 17, 2015 at 12:37:13PM +, Tvrtko Ursulin wrote:

-static void i915_vma_close(struct i915_vma *vma)


Can't find this in this series?


Should be the previous patch (9/11: Release vma when the handle is
closed) that hooks in gem_object_close to mark each vma as closed if it
is owned by the file.

http://patchwork.freedesktop.org/patch/68086/


Yeah found it later, mail filtering split the thread to different folders.


diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index c4a8a64cd1b2..9669547c7c2d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
struct intel_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);

trace_i915_context_free(ctx);
+   RQ_BUG_ON(!ctx->closed);


Normal BUG_ON I think.


You want a BUG_ON! :-p Just enable them.


No I just gave up on you seeing the light! :>

Point is RQ_BUG_ON is behind CONFIG_DRM_I915_DEBUG_REQUESTS so it is 
wrong to use it for other things.



+   for (phase = phases; *phase; phase++) {
+   struct i915_vma *vma, *vn;
+
+   list_for_each_entry_safe(vma, vn, *phase, vm_link)
+   i915_vma_close(vma);


Can't really carry on since I don't see the implementation of this.

Does it wait for retirement?


No. i915_vma_close() uses vma tracking to defer the unbind until idle.


+   /**
+* List of vma that have been unbound.
+*
+* A reference is not held on the buffer while on this list.


s/buffer/object/


They are buffer objects! The comment was cut'n'paste. I don't think it
is entirely apt to be talking about the object level active reference
here anyway. But I didn't feel inclined to write something that was even
more confusing.


# grep buffer i915_gem.c | grep -v ring | grep -v front | grep -v batch 
| grep -v execbuffer | grep -v scanout | wc -l

8

Ok, there is some precedence for the term.

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Mark the context and address space as closed

[Chris Wilson]

On Thu, Dec 17, 2015 at 02:15:52PM +, Tvrtko Ursulin wrote:
> >+static void i915_ppgtt_close(struct i915_address_space *vm)
> >+{
> >+struct list_head *phases[] = {
> >+>active_list,
> >+>inactive_list,
> >+>unbound_list,
> >+NULL,
> >+}, **phase;
> >+
> >+RQ_BUG_ON(vm->is_ggtt);
> >+RQ_BUG_ON(vm->closed);
> >+vm->closed = true;
> >+
> >+for (phase = phases; *phase; phase++) {
> >+struct i915_vma *vma, *vn;
> >+
> >+list_for_each_entry_safe(vma, vn, *phase, vm_link)
> >+i915_vma_close(vma);
> >+}
> >+}
> 
> Hm so VMAs get unlinked from everywhere, but then on retire goes
> back to inactive. Is it not a bit weird?

Very weird. In the end, I have to stop unlinking in i915_vma_close()
from the vm lists.
 
> Why it is needed to unlink VMAs from everywhere when marking them as closed?

Indeed, it was just to try and keep this walk short. But I realised that
this would actually also foul up the evict/shrinker (by hiding objects
from them that should be thrown away).
 
> And actually on retire objects are ahead of VMAs in the
> req->active_list so the last object unreference happens before the
> last vma is retired, which is even weirder.
> 
> Am I missing something?

That shouldn't happen. The i915_gem_object_retire_read is run after the
i915_vma_retire.

I had added some commentary to i915_vma_move_to_active() that hopefully
explains the interdependences between retire callbacks (mostly to try
and prevent breakage later).

@@ -1075,7 +1075,13 @@ void i915_vma_move_to_active(struct i915_vma *vma,
 
obj->dirty = 1; /* be paranoid  */
 
-   /* Add a reference if we're newly entering the active list. */
+   /* Add a reference if we're newly entering the active list.
+* The order in which we add operations to the retirement queue is
+* vital here: mark_active adds to the start of the callback list,
+* such that subsequent callbacks are called first. Therefore we
+* add the active reference first and queue for it to be dropped
+* *last*.
+*/
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 00/10] drm/i915: improve the RPM device suspended assert

[Imre Deak]

On ti, 2015-12-15 at 20:10 +0200, Imre Deak wrote:
> This is v4 of [1]. It has the following changes:
> - fix module reload that got broken in v3 due to removal of HAS_RUNTIME_PM 
>   (added patch 1-3 + revised patch 4)
> - disable the wakeref asserts in the IRQ handlers and RPS work too
>   (revised patch 7)

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-November/080005.html

Thanks for all the reviews, I pushed the patchset to dinq.

> Imre Deak (10):
>   drm/i915: clarify comment about mandatory RPM put/get during driver
> load/unload
>   drm/i915: disable power well support on platforms without runtime PM
> support
>   drm/i915: refactor RPM disabling due to RC6 being disabled
>   drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
>   drm/i915: add assert_rpm_wakelock_held helper
>   drm/i915: use assert_rpm_wakelock_held instead of opencoding it
>   drm/i915: add support for checking if we hold an RPM reference
>   drm/i915: check that we hold an RPM wakelock ref before we put it
>   drm/i915: add support for checking RPM atomic sections
>   drm/i915: check that we are in an RPM atomic section in GGTT PTE
> updaters
> 
>  drivers/gpu/drm/i915/i915_dma.c |  7 
>  drivers/gpu/drm/i915/i915_drv.c | 39 --
>  drivers/gpu/drm/i915/i915_drv.h |  2 +
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 33 +++
>  drivers/gpu/drm/i915/i915_irq.c | 73 
> ++---
>  drivers/gpu/drm/i915/intel_drv.h| 72 
>  drivers/gpu/drm/i915/intel_pm.c | 17 
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 57 -
>  drivers/gpu/drm/i915/intel_uncore.c | 23 ---
>  9 files changed, 270 insertions(+), 53 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/5] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 5/5] drm/i915: Add support for new aspect ratios

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds support for these aspect ratios in
I915 driver, at various places.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c   | 12 
 drivers/gpu/drm/i915/intel_hdmi.c |  6 ++
 drivers/gpu/drm/i915/intel_sdvo.c |  6 ++
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 7824a63..7e27854 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1483,6 +1483,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PAR16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PAR64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PAR256_135;
+   break;
case HDMI_PICTURE_ASPECT_NONE:
case HDMI_PICTURE_ASPECT_RESERVED:
default:
@@ -1545,6 +1551,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PAR16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PAR64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PAR256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6825543..6d5c3ad 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1533,6 +1533,12 @@ intel_hdmi_set_property(struct drm_connector *connector,
case DRM_MODE_PICTURE_ASPECT_16_9:
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_PICTURE_ASPECT_64_27:
+   intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 2e1da06..83f30d6 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2069,6 +2069,12 @@ intel_sdvo_set_property(struct drm_connector *connector,
case DRM_MODE_PICTURE_ASPECT_16_9:
intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_PICTURE_ASPECT_64_27:
+   intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
return -EINVAL;
}
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/11] drm/i915: Release vma when the handle is closed

[Chris Wilson]

On Thu, Dec 17, 2015 at 01:46:58PM +, Tvrtko Ursulin wrote:
> > list_for_each_entry_safe(vma, next, >vma_list, obj_link) {
> >-int ret;
> >-
> > vma->pin_count = 0;
> >-ret = i915_vma_unbind(vma);
> >-if (WARN_ON(ret == -ERESTARTSYS)) {
> >-bool was_interruptible;
> >-
> >-was_interruptible = dev_priv->mm.interruptible;
> >-dev_priv->mm.interruptible = false;
> >-
> >-WARN_ON(i915_vma_unbind(vma));
> >-
> >-dev_priv->mm.interruptible = was_interruptible;
> >-}
> >+i915_vma_close(vma);
> 
> In what circumstances can there be any VMAs still left unclosed at
> this point? I thought i915_gem_close_object would had closed them
> all.


diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 688162703070..edfa5ebc4e77 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3857,7 +3857,14 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
 
trace_i915_gem_object_destroy(obj);
 
+   /* All file-owned VMA should have been released by this point (through
+* i915_gem_close_object). However, the object may also be bound into
+* the global GTT (e.g. older GPUs without per-process support, or
+* for direct access through the GTT either for the user or for
+* scanout). Those VMA still need to unbound now.
+*/
list_for_each_entry_safe(vma, next, >vma_list, obj_link) {
+   RQ_BUG_ON(!i915_is_ggtt(vma->vm));
RQ_BUG_ON(vma->active);
vma->pin_count = 0;
i915_vma_close(vma);

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Mark the context and address space as closed

[Tvrtko Ursulin]

Hi,

On 14/12/15 11:36, Chris Wilson wrote:

When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two purposes.
First it allows us to flag the closed context and detect internal errors if
we to create any new objects for it (as it is removed from the user's
namespace, these should be internal bugs only). And secondly, it allows
us to immediately reap stale vma.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  4 
  drivers/gpu/drm/i915/i915_gem.c | 15 -
  drivers/gpu/drm/i915/i915_gem_context.c | 39 +
  drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++---
  drivers/gpu/drm/i915/i915_gem_gtt.h |  9 
  drivers/gpu/drm/i915/i915_gem_stolen.c  |  2 +-
  6 files changed, 66 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 696469a06715..66ecd6b3df95 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -892,6 +892,8 @@ struct intel_context {
} engine[I915_NUM_RINGS];

struct list_head link;
+
+   bool closed:1;
  };

  enum fb_op_origin {
@@ -2720,6 +2722,8 @@ int __must_check i915_vma_unbind(struct i915_vma *vma);
   * _guarantee_ VMA in question is _not in use_ anywhere.
   */
  int __must_check __i915_vma_unbind_no_wait(struct i915_vma *vma);
+void i915_vma_close(struct i915_vma *vma);
+
  int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
  void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
  void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7c13c27a6470..08ea0b7eda8b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2367,12 +2367,13 @@ i915_gem_object_flush_active(struct drm_i915_gem_object 
*obj)
return 0;
  }

-static void i915_vma_close(struct i915_vma *vma)


Can't find this in this series?


+void i915_vma_close(struct i915_vma *vma)
  {
RQ_BUG_ON(vma->closed);
vma->closed = true;

list_del_init(>obj_link);
+   list_del_init(>vm_link);
if (!vma->active)
WARN_ON(i915_vma_unbind(vma));
  }
@@ -2620,12 +2621,13 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
return ret;
}

-   trace_i915_vma_unbind(vma);
-
-   vma->vm->unbind_vma(vma);
+   if (likely(!vma->vm->closed)) {
+   trace_i915_vma_unbind(vma);
+   vma->vm->unbind_vma(vma);
+   }
vma->bound = 0;

-   list_del_init(>vm_link);
+   list_move_tail(>vm_link, >vm->unbound_list);
if (vma->is_ggtt) {
if (vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
obj->map_and_fenceable = false;
@@ -2882,7 +2884,7 @@ search_free:
goto err_remove_node;

list_move_tail(>global_list, _priv->mm.bound_list);
-   list_add_tail(>vm_link, >inactive_list);
+   list_move_tail(>vm_link, >inactive_list);

return vma;

@@ -3890,6 +3892,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
if (!list_empty(>exec_list))
return;

+   list_del(>vm_link);
if (!vma->is_ggtt)
i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index c4a8a64cd1b2..9669547c7c2d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
struct intel_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);

trace_i915_context_free(ctx);
+   RQ_BUG_ON(!ctx->closed);


Normal BUG_ON I think.



if (i915.enable_execlists)
intel_lr_context_free(ctx);
@@ -209,6 +210,36 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t 
size)
return obj;
  }

+static void i915_ppgtt_close(struct i915_address_space *vm)
+{
+   struct list_head *phases[] = {
+   >active_list,
+   >inactive_list,
+   >unbound_list,
+   NULL,
+   }, **phase;
+
+   RQ_BUG_ON(vm->is_ggtt);
+   RQ_BUG_ON(vm->closed);


More, and elsewhere.


+   vm->closed = true;
+
+   for (phase = phases; *phase; phase++) {
+   struct i915_vma *vma, *vn;
+
+   list_for_each_entry_safe(vma, vn, *phase, vm_link)
+   i915_vma_close(vma);


Can't really carry on since I don't see the implementation of this.

Does it wait for retirement?


+   }
+}
+
+static void context_close(struct intel_context *ctx)
+{
+   RQ_BUG_ON(ctx->closed);
+   ctx->closed = true;
+   if (ctx->ppgtt)
+   

[Intel-gfx] [PATCH] drm: add picture aspect ratio flags

[Shashank Sharma]

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

Signed-off-by: Shashank Sharma 
---
 include/uapi/drm/drm_mode.h | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50adb46..3389bd1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -73,6 +73,19 @@
 #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
 #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
 
+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
+/* Aspect ratio flag bitmask (4 bits 21:19) */
+#define DRM_MODE_FLAG_PARMASK  (0x0F<<19)
+#define  DRM_MODE_FLAG_PARNONE \
+   (DRM_MODE_PICTURE_ASPECT_NONE << 19)
+#define  DRM_MODE_FLAG_PAR4_3 \
+   (DRM_MODE_PICTURE_ASPECT_4_3 << 19)
+#define  DRM_MODE_FLAG_PAR16_9 \
+   (DRM_MODE_PICTURE_ASPECT_16_9 << 19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
@@ -88,11 +101,6 @@
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */
 
-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE   0
-#define DRM_MODE_PICTURE_ASPECT_4_31
-#define DRM_MODE_PICTURE_ASPECT_16_9   2
-
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/11] drm/i915: Release vma when the handle is closed

[Chris Wilson]

On Thu, Dec 17, 2015 at 01:46:58PM +, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 14/12/15 11:36, Chris Wilson wrote:
> >In order to prevent a leak of the vma on shared objects, we need to
> >hook into the object_close callback to destroy the vma on the object for
> >this file. However, if we destroyed that vma immediately we may cause
> >unexpected application stalls as we try to unbind a busy vma - hence we
> >defer the unbind to when we retire the vma.
> >
> >Testcase: igt/gem_ppggtt/flink-and-close-vma-leak
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Daniele Ceraolo Spurio  >---
> >  drivers/gpu/drm/i915/i915_drv.c |  1 +
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_gem.c | 41 
> > ++---
> >  drivers/gpu/drm/i915/i915_gem_gtt.c |  2 ++
> >  drivers/gpu/drm/i915/i915_gem_gtt.h |  1 +
> >  5 files changed, 30 insertions(+), 16 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> >b/drivers/gpu/drm/i915/i915_drv.c
> >index e7eef5fd6918..70979339d58a 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.c
> >+++ b/drivers/gpu/drm/i915/i915_drv.c
> >@@ -1656,6 +1656,7 @@ static struct drm_driver driver = {
> > .debugfs_init = i915_debugfs_init,
> > .debugfs_cleanup = i915_debugfs_cleanup,
> >  #endif
> >+.gem_close_object = i915_gem_close_object,
> > .gem_free_object = i915_gem_free_object,
> > .gem_vm_ops = _gem_vm_ops,
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index eb775eb1c693..696469a06715 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -2686,6 +2686,7 @@ struct drm_i915_gem_object 
> >*i915_gem_alloc_object(struct drm_device *dev,
> >   size_t size);
> >  struct drm_i915_gem_object *i915_gem_object_create_from_data(
> > struct drm_device *dev, const void *data, size_t size);
> >+void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file 
> >*file);
> >  void i915_gem_free_object(struct drm_gem_object *obj);
> >  void i915_gem_vma_destroy(struct i915_vma *vma);
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 1d21c5b79215..7c13c27a6470 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2367,6 +2367,30 @@ i915_gem_object_flush_active(struct 
> >drm_i915_gem_object *obj)
> > return 0;
> >  }
> >
> >+static void i915_vma_close(struct i915_vma *vma)
> >+{
> >+RQ_BUG_ON(vma->closed);
> 
> Same complaint as in the previous patch, cannot use RQ_BUG_ON. Maybe
> need GEM_BUG_ON then, don't know.

Hopefully Joonas will jump in to the rescue. GEM_BUG_ON() works for me.
 
> >+vma->closed = true;
> 
> Hmmm, vma->detached? Because VMA is not really closed. And
> i915_vma_detach - it would symbolise then that VMA has been detached
> from the object and is lingering only on the VM lists.

Perhaps. I chose _close() simply because that it the user action that
initiated all the actitive (either GEM_CLOSE or GEM_CONTEXT_CLOSE, or
the implicit close from close(fd)/task_exit).

detach feels a little too undefined, close at least implies termination
to me.

Of course on the vfs side, close() is handled by fput/delayed_fput!

Maybe:

gem_object_close -> i915_vma_release
context_close -> i915_ppgtt_release -> i915_vma_release

though release is already used by kref tracking (i915_ppgtt_release).

I'm not keen on using i915_vma_get/i915_vma_put, precisely because we
have managed to avoid using kref vma so far (and so we are not doing
typical reference tracking).

gem_object_close -> i915_vma_detach
context_close -> i915_ppgtt_detach -> i915_vma_detach

Still liking the consistency of close.

gem_object_close -> i915_vma_close
context_close -> i915_ppgtt_close -> i915_vma_close

Could be worse, but also there may easily be a better naming pattern.

> >@@ -3792,20 +3813,8 @@ void i915_gem_free_object(struct drm_gem_object 
> >*gem_obj)
> > trace_i915_gem_object_destroy(obj);
> >
> > list_for_each_entry_safe(vma, next, >vma_list, obj_link) {
> >-int ret;
> >-
> > vma->pin_count = 0;
> >-ret = i915_vma_unbind(vma);
> >-if (WARN_ON(ret == -ERESTARTSYS)) {
> >-bool was_interruptible;
> >-
> >-was_interruptible = dev_priv->mm.interruptible;
> >-dev_priv->mm.interruptible = false;
> >-
> >-WARN_ON(i915_vma_unbind(vma));
> >-
> >-dev_priv->mm.interruptible = was_interruptible;
> >-}
> >+i915_vma_close(vma);
> 
> In what circumstances can there be any VMAs still left unclosed at
> this point? I thought i915_gem_close_object would had closed them
> all.

vma belonging to GGTT are not 

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Mark the context and address space as closed

[Tvrtko Ursulin]

On 14/12/15 11:36, Chris Wilson wrote:

When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two purposes.
First it allows us to flag the closed context and detect internal errors if
we to create any new objects for it (as it is removed from the user's
namespace, these should be internal bugs only). And secondly, it allows
us to immediately reap stale vma.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  4 
  drivers/gpu/drm/i915/i915_gem.c | 15 -
  drivers/gpu/drm/i915/i915_gem_context.c | 39 +
  drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++---
  drivers/gpu/drm/i915/i915_gem_gtt.h |  9 
  drivers/gpu/drm/i915/i915_gem_stolen.c  |  2 +-
  6 files changed, 66 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 696469a06715..66ecd6b3df95 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -892,6 +892,8 @@ struct intel_context {
} engine[I915_NUM_RINGS];

struct list_head link;
+
+   bool closed:1;
  };

  enum fb_op_origin {
@@ -2720,6 +2722,8 @@ int __must_check i915_vma_unbind(struct i915_vma *vma);
   * _guarantee_ VMA in question is _not in use_ anywhere.
   */
  int __must_check __i915_vma_unbind_no_wait(struct i915_vma *vma);
+void i915_vma_close(struct i915_vma *vma);
+
  int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
  void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
  void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7c13c27a6470..08ea0b7eda8b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2367,12 +2367,13 @@ i915_gem_object_flush_active(struct drm_i915_gem_object 
*obj)
return 0;
  }

-static void i915_vma_close(struct i915_vma *vma)
+void i915_vma_close(struct i915_vma *vma)
  {
RQ_BUG_ON(vma->closed);
vma->closed = true;

list_del_init(>obj_link);
+   list_del_init(>vm_link);
if (!vma->active)
WARN_ON(i915_vma_unbind(vma));
  }
@@ -2620,12 +2621,13 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
return ret;
}

-   trace_i915_vma_unbind(vma);
-
-   vma->vm->unbind_vma(vma);
+   if (likely(!vma->vm->closed)) {
+   trace_i915_vma_unbind(vma);
+   vma->vm->unbind_vma(vma);
+   }
vma->bound = 0;

-   list_del_init(>vm_link);
+   list_move_tail(>vm_link, >vm->unbound_list);
if (vma->is_ggtt) {
if (vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
obj->map_and_fenceable = false;
@@ -2882,7 +2884,7 @@ search_free:
goto err_remove_node;

list_move_tail(>global_list, _priv->mm.bound_list);
-   list_add_tail(>vm_link, >inactive_list);
+   list_move_tail(>vm_link, >inactive_list);

return vma;

@@ -3890,6 +3892,7 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
if (!list_empty(>exec_list))
return;

+   list_del(>vm_link);
if (!vma->is_ggtt)
i915_ppgtt_put(i915_vm_to_ppgtt(vma->vm));

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index c4a8a64cd1b2..9669547c7c2d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -153,6 +153,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
struct intel_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);

trace_i915_context_free(ctx);
+   RQ_BUG_ON(!ctx->closed);

if (i915.enable_execlists)
intel_lr_context_free(ctx);
@@ -209,6 +210,36 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t 
size)
return obj;
  }

+static void i915_ppgtt_close(struct i915_address_space *vm)
+{
+   struct list_head *phases[] = {
+   >active_list,
+   >inactive_list,
+   >unbound_list,
+   NULL,
+   }, **phase;
+
+   RQ_BUG_ON(vm->is_ggtt);
+   RQ_BUG_ON(vm->closed);
+   vm->closed = true;
+
+   for (phase = phases; *phase; phase++) {
+   struct i915_vma *vma, *vn;
+
+   list_for_each_entry_safe(vma, vn, *phase, vm_link)
+   i915_vma_close(vma);
+   }
+}


Hm so VMAs get unlinked from everywhere, but then on retire goes back to 
inactive. Is it not a bit weird?


Why it is needed to unlink VMAs from everywhere when marking them as closed?

And actually on retire objects are ahead of VMAs in the req->active_list 
so the last object unreference happens before the last vma is retired, 
which is even weirder.


Am I 

Re: [Intel-gfx] [PATCH v5 04/10] drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers

[Joonas Lahtinen]

On to, 2015-12-17 at 13:48 +0200, Imre Deak wrote:
> We don't really need to check this flag in the get/put/assert
> helpers,
> as on platforms without RPM support we won't ever enable RPM. That
> means
> pm.suspend will be always false and the assert will be always true.
> 
> Do this to simplify the code and to let us extend the RPM asserts to
> all
> platforms for a better coverage.
> 
> Motivated by Ville.
> 
> v2-v3:
> - unchanged
> v4:
> - remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too
>   made possible by the previous two patches
> v5:
> - rebased on the previous new patch in the series that keeps
>   HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent
>   reference taken there
> 
> Signed-off-by: Imre Deak 
> Reviewed-by: Chris Wilson  (v3)
> Reviewed-by: Joonas Lahtinen  (v4)

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 9 -
>  drivers/gpu/drm/i915/intel_uncore.c | 3 +--
>  2 files changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index bf2492f..cc0492e 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2241,9 +2241,6 @@ void intel_runtime_pm_get(struct
> drm_i915_private *dev_priv)
>   struct drm_device *dev = dev_priv->dev;
>   struct device *device = >pdev->dev;
>  
> - if (!HAS_RUNTIME_PM(dev))
> - return;
> -
>   pm_runtime_get_sync(device);
>   WARN(dev_priv->pm.suspended, "Device still suspended.\n");
>  }
> @@ -2270,9 +2267,6 @@ void intel_runtime_pm_get_noresume(struct
> drm_i915_private *dev_priv)
>   struct drm_device *dev = dev_priv->dev;
>   struct device *device = >pdev->dev;
>  
> - if (!HAS_RUNTIME_PM(dev))
> - return;
> -
>   WARN(dev_priv->pm.suspended, "Getting nosync-ref while
> suspended.\n");
>   pm_runtime_get_noresume(device);
>  }
> @@ -2290,9 +2284,6 @@ void intel_runtime_pm_put(struct
> drm_i915_private *dev_priv)
>   struct drm_device *dev = dev_priv->dev;
>   struct device *device = >pdev->dev;
>  
> - if (!HAS_RUNTIME_PM(dev))
> - return;
> -
>   pm_runtime_mark_last_busy(device);
>   pm_runtime_put_autosuspend(device);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index fcf04fe..0226776 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -53,8 +53,7 @@ intel_uncore_forcewake_domain_to_str(const enum
> forcewake_domain_id id)
>  static void
>  assert_device_not_suspended(struct drm_i915_private *dev_priv)
>  {
> - WARN_ONCE(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv
> ->pm.suspended,
> -   "Device suspended\n");
> + WARN_ONCE(dev_priv->pm.suspended, "Device suspended\n");
>  }
>  
>  static inline void
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915: Disable fast link training if DP config changes

[Mika Kahola]

Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link training is started with zero values.

v4: Parameter and debug message naming improvements.
Fix for link parameter check (Ville)

v3: Remove cached old link parameters. Instead, disable
fast link training feature when link parameters are
set (Ville)

v2: Readout DPCD register to check if no aux handshaking is
required in link training (Ander)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c   |  8 +++-
 drivers/gpu/drm/i915/intel_dp_link_training.c | 17 +
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 31ba241..82504f0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1677,6 +1677,12 @@ found:
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  const struct intel_crtc_state *pipe_config)
 {
+   if (intel_dp->link_rate != pipe_config->port_clock ||
+   intel_dp->lane_count != pipe_config->lane_count) {
+   intel_dp->train_set_valid = false;
+   DRM_DEBUG_KMS("setting train set valid as false\n");
+   }
+
intel_dp->link_rate = pipe_config->port_clock;
intel_dp->lane_count = pipe_config->lane_count;
 }
@@ -3849,7 +3855,7 @@ intel_dp_link_down(struct intel_dp *intel_dp)
intel_dp->DP = DP;
 }
 
-static bool
+bool
 intel_dp_get_dpcd(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 793..e46bad6 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -85,6 +85,23 @@ static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
 {
+   bool has_dpcd;
+   bool no_aux_handshake = false;
+
+   has_dpcd = intel_dp_get_dpcd(intel_dp);
+
+   if (has_dpcd) {
+   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
+   no_aux_handshake = (intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
+   DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
+   }
+   }
+
+   intel_dp->train_set_valid &= no_aux_handshake;
+
+   DRM_DEBUG_KMS("link training optimization: %s\n",
+ intel_dp->train_set_valid ? "true" : "false");
+
if (!intel_dp->train_set_valid)
memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 798463e..94041fd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1239,6 +1239,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
 bool intel_dp_compute_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config);
 bool intel_dp_is_edp(struct drm_device *dev, enum port port);
+bool intel_dp_get_dpcd(struct intel_dp *intel_dp);
 enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
  bool long_hpd);
 void intel_edp_backlight_on(struct intel_dp *intel_dp);
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/11] drm/i915: Release vma when the handle is closed

[Tvrtko Ursulin]

Hi,

On 14/12/15 11:36, Chris Wilson wrote:

In order to prevent a leak of the vma on shared objects, we need to
hook into the object_close callback to destroy the vma on the object for
this file. However, if we destroyed that vma immediately we may cause
unexpected application stalls as we try to unbind a busy vma - hence we
defer the unbind to when we retire the vma.

Testcase: igt/gem_ppggtt/flink-and-close-vma-leak
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio closed);


Same complaint as in the previous patch, cannot use RQ_BUG_ON. Maybe 
need GEM_BUG_ON then, don't know.



+   vma->closed = true;


Hmmm, vma->detached? Because VMA is not really closed. And 
i915_vma_detach - it would symbolise then that VMA has been detached 
from the object and is lingering only on the VM lists.



+
+   list_del_init(>obj_link);
+   if (!vma->active)
+   WARN_ON(i915_vma_unbind(vma));
+}
+
+void i915_gem_close_object(struct drm_gem_object *gem,
+  struct drm_file *file)
+{
+   struct drm_i915_gem_object *obj = to_intel_bo(gem);
+   struct drm_i915_file_private *fpriv = file->driver_priv;
+   struct i915_vma *vma, *vn;
+
+   mutex_lock(>base.dev->struct_mutex);
+   list_for_each_entry_safe(vma, vn, >vma_list, obj_link)
+   if (vma->vm->file == fpriv)
+   i915_vma_close(vma);
+   mutex_unlock(>base.dev->struct_mutex);
+}
+
  /**
   * i915_gem_wait_ioctl - implements DRM_IOCTL_I915_GEM_WAIT
   * @DRM_IOCTL_ARGS: standard ioctl arguments
@@ -2577,9 +2601,6 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
RQ_BUG_ON(vma->active);
}

-   if (list_empty(>obj_link))
-   return 0;
-
if (!drm_mm_node_allocated(>node)) {
i915_gem_vma_destroy(vma);
return 0;
@@ -3792,20 +3813,8 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
trace_i915_gem_object_destroy(obj);

list_for_each_entry_safe(vma, next, >vma_list, obj_link) {
-   int ret;
-
vma->pin_count = 0;
-   ret = i915_vma_unbind(vma);
-   if (WARN_ON(ret == -ERESTARTSYS)) {
-   bool was_interruptible;
-
-   was_interruptible = dev_priv->mm.interruptible;
-   dev_priv->mm.interruptible = false;
-
-   WARN_ON(i915_vma_unbind(vma));
-
-   dev_priv->mm.interruptible = was_interruptible;
-   }
+   i915_vma_close(vma);


In what circumstances can there be any VMAs still left unclosed at this 
point? I thought i915_gem_close_object would had closed them all.



}

/* Stolen objects don't hold a ref, but do hold pin count. Fix that up
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5505603f52af..9f594c33bd0a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ 

Re: [Intel-gfx] [PATCH 09/11] drm/i915: Release vma when the handle is closed

[Tvrtko Ursulin]

On 17/12/15 14:21, Chris Wilson wrote:

On Thu, Dec 17, 2015 at 01:46:58PM +, Tvrtko Ursulin wrote:

list_for_each_entry_safe(vma, next, >vma_list, obj_link) {
-   int ret;
-
vma->pin_count = 0;
-   ret = i915_vma_unbind(vma);
-   if (WARN_ON(ret == -ERESTARTSYS)) {
-   bool was_interruptible;
-
-   was_interruptible = dev_priv->mm.interruptible;
-   dev_priv->mm.interruptible = false;
-
-   WARN_ON(i915_vma_unbind(vma));
-
-   dev_priv->mm.interruptible = was_interruptible;
-   }
+   i915_vma_close(vma);


In what circumstances can there be any VMAs still left unclosed at
this point? I thought i915_gem_close_object would had closed them
all.



diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 688162703070..edfa5ebc4e77 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3857,7 +3857,14 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)

 trace_i915_gem_object_destroy(obj);

+   /* All file-owned VMA should have been released by this point (through
+* i915_gem_close_object). However, the object may also be bound into
+* the global GTT (e.g. older GPUs without per-process support, or
+* for direct access through the GTT either for the user or for
+* scanout). Those VMA still need to unbound now.
+*/
 list_for_each_entry_safe(vma, next, >vma_list, obj_link) {
+   RQ_BUG_ON(!i915_is_ggtt(vma->vm));
 RQ_BUG_ON(vma->active);
 vma->pin_count = 0;
 i915_vma_close(vma);



Ah yes, I've missed that detail. Very good to have it in a comment (and 
assert).


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/5] drm/i915: Add support for new aspect ratios

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds support for these aspect ratios in
I915 driver, at various places.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c   | 12 
 drivers/gpu/drm/i915/intel_hdmi.c |  6 ++
 drivers/gpu/drm/i915/intel_sdvo.c |  6 ++
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 7824a63..7e27854 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1483,6 +1483,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PAR16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PAR64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PAR256_135;
+   break;
case HDMI_PICTURE_ASPECT_NONE:
case HDMI_PICTURE_ASPECT_RESERVED:
default:
@@ -1545,6 +1551,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PAR16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PAR64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PAR256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6825543..6d5c3ad 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1533,6 +1533,12 @@ intel_hdmi_set_property(struct drm_connector *connector,
case DRM_MODE_PICTURE_ASPECT_16_9:
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_PICTURE_ASPECT_64_27:
+   intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 2e1da06..83f30d6 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2069,6 +2069,12 @@ intel_sdvo_set_property(struct drm_connector *connector,
case DRM_MODE_PICTURE_ASPECT_16_9:
intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_PICTURE_ASPECT_64_27:
+   intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
return -EINVAL;
}
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/5]: Add aspect ratio parsing

[Shashank Sharma]

Currently DRM framework doesn't parse aspect ratio of a videomode
while converting it from a umode->kmode or viceversa. This causes
modeset of CEA modes with incorrect aspect ratio.

While running HDMI complaince, tests (like 7-27) expect the DUT
to apply the mode as per the VIC, but as driver does not consider
the aspect ratio part while searching a mode from modedb, we end
up setting mode with a wrong VIC, causing the test to fail.  

What this patch set does:
Patch 1-2
- Adds aspect ratio flags in the DRM layer, in form of flags.
- Adds parsing of aspect ratio, during conversion of a umode->kmode
  and viceversa.
- Adds aspect ratio check while finding a mode, during modeset.

Patch 3-5
- Adds some new aspect ratio defined in CEA-861-F specs to
  support HDMI 2.0 displays, in DRM and I915 layer.

Shashank Sharma (5):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add flags for new aspect ratios
  drm/i915: Add support for new aspect ratios

 drivers/gpu/drm/drm_modes.c   | 46 +++
 drivers/gpu/drm/i915/intel_hdmi.c |  6 +
 drivers/gpu/drm/i915/intel_sdvo.c |  6 +
 drivers/video/hdmi.c  |  4 
 include/linux/hdmi.h  |  2 ++
 include/uapi/drm/drm_mode.h   | 24 +++-
 6 files changed, 83 insertions(+), 5 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/5] drm: Add flags for new aspect ratios

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds DRM flags for the new aspect ratios
in the existing aspect ratio flags.

Signed-off-by: Shashank Sharma 
---
 include/uapi/drm/drm_mode.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 62fbf1f..971a58b 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,8 @@
 #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 21:19) */
 #define DRM_MODE_FLAG_PARMASK  (0x0F<<19)
@@ -86,6 +88,10 @@
(DRM_MODE_PICTURE_ASPECT_4_3 << 19)
 #define  DRM_MODE_FLAG_PAR16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9 << 19)
+#define  DRM_MODE_FLAG_PAR64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27 << 19)
+#define  DRM_MODE_FLAG_PAR256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135 << 19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/5] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/5] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
---
 drivers/gpu/drm/drm_modes.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 20775c0..7824a63 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,6 +939,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode 
*mode1, const struct
(mode2->flags & DRM_MODE_FLAG_3D_MASK))
return false;
 
+   if (mode1->picture_aspect_ratio != mode2->picture_aspect_ratio)
+   return false;
+
return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
 }
 EXPORT_SYMBOL(drm_mode_equal_no_clocks);
@@ -967,6 +970,7 @@ 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;
@@ -1470,6 +1474,22 @@ 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_PARMASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PAR4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PAR16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_NONE:
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PARNONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1515,6 +1535,20 @@ 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_PARMASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PARMASK) {
+   case DRM_MODE_FLAG_PAR4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PAR16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: Disable fast link training if DP config changes

[Ville Syrjälä]

On Thu, Dec 17, 2015 at 02:46:03PM +0200, Mika Kahola wrote:
> Disable DP fast link training if DP link configuration
> changes. If one of the DP link parameters i.e. link
> bandwidth, lane count, rate selection, port clock or bpp

This list of things we check should be updated to match the actual
patch.

> changes the link training does no longer apply the
> previously computed voltage swing and pre-emphasis values.
> Instead, the link training is started with zero values.
> 
> v4: Parameter and debug message naming improvements.
> Fix for link parameter check (Ville)
> 
> v3: Remove cached old link parameters. Instead, disable
> fast link training feature when link parameters are
> set (Ville)
> 
> v2: Readout DPCD register to check if no aux handshaking is
> required in link training (Ander)
> 
> Signed-off-by: Mika Kahola 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   |  8 +++-
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 17 +
>  drivers/gpu/drm/i915/intel_drv.h  |  1 +
>  3 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 31ba241..82504f0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1677,6 +1677,12 @@ found:
>  void intel_dp_set_link_params(struct intel_dp *intel_dp,
> const struct intel_crtc_state *pipe_config)
>  {
> + if (intel_dp->link_rate != pipe_config->port_clock ||
> + intel_dp->lane_count != pipe_config->lane_count) {
> + intel_dp->train_set_valid = false;
> + DRM_DEBUG_KMS("setting train set valid as false\n");

Maybe "Link parameters changed, resetting vswing and pre-emphasis" ?

Also maybe check for train_set_valid being true as well so that we
don't print the debug message unless we're really resetting the flag.

> + }
> +
>   intel_dp->link_rate = pipe_config->port_clock;
>   intel_dp->lane_count = pipe_config->lane_count;
>  }
> @@ -3849,7 +3855,7 @@ intel_dp_link_down(struct intel_dp *intel_dp)
>   intel_dp->DP = DP;
>  }
>  
> -static bool
> +bool
>  intel_dp_get_dpcd(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 793..e46bad6 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -85,6 +85,23 @@ static bool
>  intel_dp_reset_link_train(struct intel_dp *intel_dp,
>   uint8_t dp_train_pat)
>  {
> + bool has_dpcd;
> + bool no_aux_handshake = false;
> +
> + has_dpcd = intel_dp_get_dpcd(intel_dp);
> +
> + if (has_dpcd) {
> + if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
> + no_aux_handshake = (intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
> + DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
> + }
> + }
> +
> + intel_dp->train_set_valid &= no_aux_handshake;

This should be separate patch. And I'm not convinced it's correct
anyway. At least it's not anything mandated by the spec AFAICS, so
there should be a comment why we're doing it. Also there's no
mention of  this change in the commit message either.

> +
> + DRM_DEBUG_KMS("link training optimization: %s\n",
> +   intel_dp->train_set_valid ? "true" : "false");
> +
>   if (!intel_dp->train_set_valid)
>   memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
>   intel_dp_set_signal_levels(intel_dp);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 798463e..94041fd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1239,6 +1239,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
> *crc);
>  bool intel_dp_compute_config(struct intel_encoder *encoder,
>struct intel_crtc_state *pipe_config);
>  bool intel_dp_is_edp(struct drm_device *dev, enum port port);
> +bool intel_dp_get_dpcd(struct intel_dp *intel_dp);
>  enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
> bool long_hpd);
>  void intel_edp_backlight_on(struct intel_dp *intel_dp);
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Mark the context and address space as closed

[Tvrtko Ursulin]

On 17/12/15 14:26, Chris Wilson wrote:

On Thu, Dec 17, 2015 at 02:15:52PM +, Tvrtko Ursulin wrote:

+static void i915_ppgtt_close(struct i915_address_space *vm)
+{
+   struct list_head *phases[] = {
+   >active_list,
+   >inactive_list,
+   >unbound_list,
+   NULL,
+   }, **phase;
+
+   RQ_BUG_ON(vm->is_ggtt);
+   RQ_BUG_ON(vm->closed);
+   vm->closed = true;
+
+   for (phase = phases; *phase; phase++) {
+   struct i915_vma *vma, *vn;
+
+   list_for_each_entry_safe(vma, vn, *phase, vm_link)
+   i915_vma_close(vma);
+   }
+}


Hm so VMAs get unlinked from everywhere, but then on retire goes
back to inactive. Is it not a bit weird?


Very weird. In the end, I have to stop unlinking in i915_vma_close()
from the vm lists.


Why it is needed to unlink VMAs from everywhere when marking them as closed?


Indeed, it was just to try and keep this walk short. But I realised that
this would actually also foul up the evict/shrinker (by hiding objects
from them that should be thrown away).


And actually on retire objects are ahead of VMAs in the
req->active_list so the last object unreference happens before the
last vma is retired, which is even weirder.

Am I missing something?


That shouldn't happen. The i915_gem_object_retire_read is run after the
i915_vma_retire.

I had added some commentary to i915_vma_move_to_active() that hopefully
explains the interdependences between retire callbacks (mostly to try
and prevent breakage later).

@@ -1075,7 +1075,13 @@ void i915_vma_move_to_active(struct i915_vma *vma,

 obj->dirty = 1; /* be paranoid  */

-   /* Add a reference if we're newly entering the active list. */
+   /* Add a reference if we're newly entering the active list.
+* The order in which we add operations to the retirement queue is
+* vital here: mark_active adds to the start of the callback list,
+* such that subsequent callbacks are called first. Therefore we
+* add the active reference first and queue for it to be dropped
+* *last*.
+*/


I don't know how I concluded active VMA is after the active object, and 
I specifically saw the order and list_move.


Again, very good to document that, so something good at least came out 
of it. :)



Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 10/11] drm/i915: Mark the context and address space as closed

[Tvrtko Ursulin]

On 17/12/15 12:37, Tvrtko Ursulin wrote:


Hi,

On 14/12/15 11:36, Chris Wilson wrote:

When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two
purposes.
First it allows us to flag the closed context and detect internal
errors if
we to create any new objects for it (as it is removed from the user's
namespace, these should be internal bugs only). And secondly, it allows
us to immediately reap stale vma.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  4 
  drivers/gpu/drm/i915/i915_gem.c | 15 -
  drivers/gpu/drm/i915/i915_gem_context.c | 39
+
  drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++---
  drivers/gpu/drm/i915/i915_gem_gtt.h |  9 
  drivers/gpu/drm/i915/i915_gem_stolen.c  |  2 +-
  6 files changed, 66 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 696469a06715..66ecd6b3df95 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -892,6 +892,8 @@ struct intel_context {
  } engine[I915_NUM_RINGS];

  struct list_head link;
+
+bool closed:1;
  };

  enum fb_op_origin {
@@ -2720,6 +2722,8 @@ int __must_check i915_vma_unbind(struct i915_vma
*vma);
   * _guarantee_ VMA in question is _not in use_ anywhere.
   */
  int __must_check __i915_vma_unbind_no_wait(struct i915_vma *vma);
+void i915_vma_close(struct i915_vma *vma);
+
  int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
  void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
  void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 7c13c27a6470..08ea0b7eda8b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2367,12 +2367,13 @@ i915_gem_object_flush_active(struct
drm_i915_gem_object *obj)
  return 0;
  }

-static void i915_vma_close(struct i915_vma *vma)


Can't find this in this series?


Ooops it is in a different mail folder, I did not sport the break in 
patch numbers...


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ failure: UK.CI.checkpatch.pl

[Patchwork]

== Summary ==

  • Testing [v2] drm/i915: Introduce drm_i915_gem_request_active for request 
tracking
  • Testing [02/11] drm/i915: Refactor activity tracking for requests

WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
than BUG() or BUG_ON()
#680: FILE: drivers/gpu/drm/i915/i915_gem_request.h:123:
+#define RQ_BUG_ON(expr) BUG_ON(expr)

WARNING: storage class should be at the beginning of the declaration
#701: FILE: drivers/gpu/drm/i915/i915_gem_request.h:218:
+inline static void init_request_active(struct drm_i915_gem_request_active 
*active,

ERROR: inline keyword should sit between storage class and type
#701: FILE: drivers/gpu/drm/i915/i915_gem_request.h:218:
+inline static void init_request_active(struct drm_i915_gem_request_active 
*active,


Your patch has style problems, please review.

NOTE: Ignored message types: BLOCK_COMMENT_STYLE COMMIT_LOG_LONG_LINE 
COMPLEX_MACRO FILE_PATH_CHANGES GIT_COMMIT_ID SPLIT_STRING

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

  • Testing [03/11] drm/i915: Rename vma->*_list to *_link for consistency
  • Testing [04/11] drm/i915: Amalgamate GGTT/ppGTT vma debug list walkers
  • Testing [05/11] drm/i915: Reduce the pointer dance of i915_is_ggtt()
  • Testing [06/11] drm/i915: Store owning file on the i915_address_space
  • Testing [07/11] drm/i915: i915_vma_move_to_active prep patch

WARNING: Missing a blank line after declarations
#134: FILE: drivers/gpu/drm/i915/i915_gem_execbuffer.c:1097:
+   struct drm_i915_private *dev_priv = req->i915;
+   
list_move_tail(_priv->fence_regs[obj->fence_reg].lru_list,


Your patch has style problems, please review.

NOTE: Ignored message types: BLOCK_COMMENT_STYLE COMMIT_LOG_LONG_LINE 
COMPLEX_MACRO FILE_PATH_CHANGES GIT_COMMIT_ID SPLIT_STRING

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

  • Testing [08/11] drm/i915: Track active vma requests
  • Testing [10/11] drm/i915: Mark the context and address space as closed
  • Testing [11/11] Revert "drm/i915: Clean up associated VMAs on context 
destruction"

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Store owning file on the i915_address_space

[Chris Wilson]

On Thu, Dec 17, 2015 at 11:52:06AM +, Tvrtko Ursulin wrote:
> >-ret = __hw_ppgtt_init(dev, ppgtt);
> >+ret = __hw_ppgtt_init(ppgtt, dev_priv);
> > if (ret == 0) {
> > kref_init(>ref);
> > i915_address_space_init(>base, dev_priv);
> >+ppgtt->base.file = file_priv;
> 
> I would keep using file_priv since that's what's it's called all
> over the place but whatever.

Personally I have been working towards dropping the _priv from our
nomenclature inside our driver (only on the boundaries from drm do we
care about translating from drm objects to ours) - in a parallel fashion
to using crtc and crtc->base instead of intel_crtc / crtc.

> >diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> >b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >index bae005a62cfc..4e9553ace33f 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >@@ -273,12 +273,11 @@ struct i915_pml4 {
> >  struct i915_address_space {
> > struct drm_mm mm;
> > struct drm_device *dev;
> >+struct drm_i915_file_private *file;
> 
> Suggest putting a comment documenting when it is NULL and when it is
> valid. Commit says so, but I think comment is also needed.

+   /* Every address space belongs to a struct file - except for the global
+* GTT that is owned by the driver (and so @file is set to NULL). In
+* principle, no information should leak from one context to another
+* (or between files/processes etc) unless explicitly shared by the
+* owner. Tracking the owner is important in order to free up per-file
+* objects along with the file, to aide resource tracking, and to
+* assign blame.
+*/
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/5] drm: add picture aspect ratio flags

[Shashank Sharma]

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

Signed-off-by: Shashank Sharma 
---
 include/uapi/drm/drm_mode.h | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50adb46..3389bd1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -73,6 +73,19 @@
 #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
 #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
 
+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
+/* Aspect ratio flag bitmask (4 bits 21:19) */
+#define DRM_MODE_FLAG_PARMASK  (0x0F<<19)
+#define  DRM_MODE_FLAG_PARNONE \
+   (DRM_MODE_PICTURE_ASPECT_NONE << 19)
+#define  DRM_MODE_FLAG_PAR4_3 \
+   (DRM_MODE_PICTURE_ASPECT_4_3 << 19)
+#define  DRM_MODE_FLAG_PAR16_9 \
+   (DRM_MODE_PICTURE_ASPECT_16_9 << 19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
@@ -88,11 +101,6 @@
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */
 
-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE   0
-#define DRM_MODE_PICTURE_ASPECT_4_31
-#define DRM_MODE_PICTURE_ASPECT_16_9   2
-
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 0/5] Add aspect ratio parsing

[Shashank Sharma]

Currently DRM framework doesn't parse aspect ratio of a videomode
while converting it from a umode->kmode or viceversa. This causes
modeset of CEA modes with incorrect aspect ratio.

While running HDMI complaince, tests (like 7-27) expect the DUT
to apply the mode as per the VIC, but as driver does not consider
the aspect ratio part while searching a mode from modedb, we end
up setting mode with a wrong VIC, causing the test to fail.

What this patch set does:
Patch 1-2
- Adds aspect ratio flags in the DRM layer, in form of flags.
- Adds parsing of aspect ratio, during conversion of a umode->kmode
  and viceversa.
- Adds aspect ratio check while finding a mode, during modeset.

Patch 3-5
- Adds some new aspect ratio defined in CEA-861-F specs to
  support HDMI 2.0 displays, in DRM and I915 layer.

V2: needed a rebase

Shashank Sharma (5):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add flags for new aspect ratios
  drm/i915: Add support for new aspect ratios

 drivers/gpu/drm/drm_modes.c   | 46 +++
 drivers/gpu/drm/i915/intel_hdmi.c |  6 +
 drivers/gpu/drm/i915/intel_sdvo.c |  6 +
 drivers/video/hdmi.c  |  4 
 include/linux/hdmi.h  |  2 ++
 include/uapi/drm/drm_mode.h   | 24 +++-
 6 files changed, 83 insertions(+), 5 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 4/5] drm: Add flags for new aspect ratios

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds DRM flags for the new aspect ratios
in the existing aspect ratio flags.

Signed-off-by: Shashank Sharma 
---
 include/uapi/drm/drm_mode.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 3389bd1..b482d73 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,8 @@
 #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 21:19) */
 #define DRM_MODE_FLAG_PARMASK  (0x0F<<19)
@@ -86,6 +88,10 @@
(DRM_MODE_PICTURE_ASPECT_4_3 << 19)
 #define  DRM_MODE_FLAG_PAR16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9 << 19)
+#define  DRM_MODE_FLAG_PAR64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27 << 19)
+#define  DRM_MODE_FLAG_PAR256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135 << 19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/5] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
---
 drivers/gpu/drm/drm_modes.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 20775c0..7824a63 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,6 +939,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode 
*mode1, const struct
(mode2->flags & DRM_MODE_FLAG_3D_MASK))
return false;
 
+   if (mode1->picture_aspect_ratio != mode2->picture_aspect_ratio)
+   return false;
+
return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
 }
 EXPORT_SYMBOL(drm_mode_equal_no_clocks);
@@ -967,6 +970,7 @@ 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;
@@ -1470,6 +1474,22 @@ 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_PARMASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PAR4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PAR16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_NONE:
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PARNONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1515,6 +1535,20 @@ 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_PARMASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PARMASK) {
+   case DRM_MODE_FLAG_PAR4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PAR16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ failure: UK.CI.checkpatch.pl

[Patchwork]

== Summary ==

  • Testing drm/i915: edp resume/On time optimization.

WARNING: Duplicate signature
#17: 
Signed-off-by: Abhay Kumar 

WARNING: line over 100 characters
#60: FILE: drivers/gpu/drm/i915/intel_dp.c:2055:
+   panel_power_off_duration  = 
(intel_dp->panel_power_on_timestamp.tv_sec-intel_dp->panel_power_off_timestamp.tv_sec)
 * 100 +  
intel_dp->panel_power_on_timestamp.tv_usec-intel_dp->panel_power_off_timestamp.tv_usec;

WARNING: space prohibited before semicolon
#61: FILE: drivers/gpu/drm/i915/intel_dp.c:2056:
+   panel_power_off_duration = panel_power_off_duration / 1000 ;

ERROR: space required before the open parenthesis '('
#64: FILE: drivers/gpu/drm/i915/intel_dp.c:2059:
+   if(panel_power_off_duration >= intel_dp->panel_power_cycle_delay) {

WARNING: braces {} are not necessary for any arm of this statement
#64: FILE: drivers/gpu/drm/i915/intel_dp.c:2059:
+   if(panel_power_off_duration >= intel_dp->panel_power_cycle_delay) {
[...]
+   } else {
[...]

WARNING: line over 100 characters
#67: FILE: drivers/gpu/drm/i915/intel_dp.c:2062:
+   intel_dp->panel_power_cycle_delay = 
intel_dp->panel_power_cycle_delay - panel_power_off_duration;


Your patch has style problems, please review.

NOTE: Ignored message types: BLOCK_COMMENT_STYLE COMMIT_LOG_LONG_LINE 
COMPLEX_MACRO FILE_PATH_CHANGES GIT_COMMIT_ID SPLIT_STRING

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/vlv: Take forcewake on media engine writes

[Mika Kuoppala]

Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
for forcewake Individual power wells.") we have only taken
media engine forcewake correctly on reads, but only taken render
engine forcewake on media engine writes and omitted the media
domain.

This asymmetry might have caused unstable behaviour on
media ring access.

Fix is to take media engine forcewake symmetrically to writes.

References: https://bugs.freedesktop.org/show_bug.cgi?id=88012
Cc: Deepak S 
Cc: Jesse Barnes 
Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_uncore.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 277e60ae0e47..a2e204088aa5 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -902,6 +902,23 @@ hsw_write##x(struct drm_i915_private *dev_priv, i915_reg_t 
reg, u##x val, bool t
GEN6_WRITE_FOOTER; \
 }
 
+#define __vlv_write(x) \
+static void \
+vlv_write##x(struct drm_i915_private *dev_priv, i915_reg_t reg, u##x val, bool 
trace) { \
+   enum forcewake_domains fw_engine = 0; \
+   GEN6_WRITE_HEADER; \
+   if (!NEEDS_FORCE_WAKE(offset)) \
+   fw_engine = 0; \
+   else if (FORCEWAKE_VLV_RENDER_RANGE_OFFSET(offset)) \
+   fw_engine = FORCEWAKE_RENDER; \
+   else if (FORCEWAKE_VLV_MEDIA_RANGE_OFFSET(offset)) \
+   fw_engine = FORCEWAKE_MEDIA; \
+   if (fw_engine) \
+   __force_wake_get(dev_priv, fw_engine); \
+   __raw_i915_write##x(dev_priv, reg, val); \
+   GEN6_WRITE_FOOTER; \
+}
+
 static const i915_reg_t gen8_shadowed_regs[] = {
FORCEWAKE_MT,
GEN6_RPNSWREQ,
@@ -1019,6 +1036,10 @@ __gen8_write(8)
 __gen8_write(16)
 __gen8_write(32)
 __gen8_write(64)
+__vlv_write(8)
+__vlv_write(16)
+__vlv_write(32)
+__vlv_write(64)
 __hsw_write(8)
 __hsw_write(16)
 __hsw_write(32)
@@ -1031,6 +1052,7 @@ __gen6_write(64)
 #undef __gen9_write
 #undef __chv_write
 #undef __gen8_write
+#undef __vlv_write
 #undef __hsw_write
 #undef __gen6_write
 #undef GEN6_WRITE_FOOTER
@@ -1243,6 +1265,8 @@ void intel_uncore_init(struct drm_device *dev)
case 6:
if (IS_HASWELL(dev)) {
ASSIGN_WRITE_MMIO_VFUNCS(hsw);
+   } else if (IS_VALLEYVIEW(dev)) {
+   ASSIGN_WRITE_MMIO_VFUNCS(vlv);
} else {
ASSIGN_WRITE_MMIO_VFUNCS(gen6);
}
-- 
2.5.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ warning: Fi.CI.BAT

[Patchwork]

== Summary ==

Built on 8463389e40c3815b2e9b052f34145b1d728975be drm-intel-nightly: 
2015y-12m-17d-14h-39m-21s UTC integration manifest

Test igt@kms_flip@basic-flip-vs-wf_vblank on snb-x220t dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-wf_vblank on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence on bdw-nuci7 
dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@hang-read-crc-pipe-a on snb-x220t pass -> dmesg-warn
Test igt@kms_flip@basic-plain-flip on bdw-nuci7 pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-a on snb-x220t dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-a on skl-i7k-2 pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c on skl-i5k-2 dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-b on snb-dellxps dmesg-warn -> pass
Test igt@kms_setmode@basic-clone-single-crtc on snb-dellxps pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-modeset on bsw-nuc-2 pass -> dmesg-warn

bdw-nuci7total:135  pass:124  dwarn:2   dfail:0   fail:0   skip:9  
bsw-nuc-2total:135  pass:113  dwarn:2   dfail:0   fail:0   skip:20 
hsw-brixbox  total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2  total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p  total:135  pass:100  dwarn:0   dfail:0   fail:2   skip:33 
ivb-t430stotal:135  pass:128  dwarn:1   dfail:1   fail:1   skip:4  
skl-i5k-2total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
skl-i7k-2total:135  pass:122  dwarn:5   dfail:0   fail:0   skip:8  
snb-dellxps  total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220ttotal:135  pass:122  dwarn:1   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_703/

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Take forcewake on media engine writes

[Ville Syrjälä]

On Thu, Dec 17, 2015 at 05:14:54PM +0200, Mika Kuoppala wrote:
> Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
> for forcewake Individual power wells.") we have only taken
> media engine forcewake correctly on reads, but only taken render
> engine forcewake on media engine writes and omitted the media
> domain.
> 
> This asymmetry might have caused unstable behaviour on
> media ring access.
> 
> Fix is to take media engine forcewake symmetrically to writes.

We don't take any forcewake on writes pre-gen8. That's what the
wake FIFO is for.

> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=88012
> Cc: Deepak S 
> Cc: Jesse Barnes 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 277e60ae0e47..a2e204088aa5 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -902,6 +902,23 @@ hsw_write##x(struct drm_i915_private *dev_priv, 
> i915_reg_t reg, u##x val, bool t
>   GEN6_WRITE_FOOTER; \
>  }
>  
> +#define __vlv_write(x) \
> +static void \
> +vlv_write##x(struct drm_i915_private *dev_priv, i915_reg_t reg, u##x val, 
> bool trace) { \
> + enum forcewake_domains fw_engine = 0; \
> + GEN6_WRITE_HEADER; \
> + if (!NEEDS_FORCE_WAKE(offset)) \
> + fw_engine = 0; \
> + else if (FORCEWAKE_VLV_RENDER_RANGE_OFFSET(offset)) \
> + fw_engine = FORCEWAKE_RENDER; \
> + else if (FORCEWAKE_VLV_MEDIA_RANGE_OFFSET(offset)) \
> + fw_engine = FORCEWAKE_MEDIA; \
> + if (fw_engine) \
> + __force_wake_get(dev_priv, fw_engine); \
> + __raw_i915_write##x(dev_priv, reg, val); \
> + GEN6_WRITE_FOOTER; \
> +}
> +
>  static const i915_reg_t gen8_shadowed_regs[] = {
>   FORCEWAKE_MT,
>   GEN6_RPNSWREQ,
> @@ -1019,6 +1036,10 @@ __gen8_write(8)
>  __gen8_write(16)
>  __gen8_write(32)
>  __gen8_write(64)
> +__vlv_write(8)
> +__vlv_write(16)
> +__vlv_write(32)
> +__vlv_write(64)
>  __hsw_write(8)
>  __hsw_write(16)
>  __hsw_write(32)
> @@ -1031,6 +1052,7 @@ __gen6_write(64)
>  #undef __gen9_write
>  #undef __chv_write
>  #undef __gen8_write
> +#undef __vlv_write
>  #undef __hsw_write
>  #undef __gen6_write
>  #undef GEN6_WRITE_FOOTER
> @@ -1243,6 +1265,8 @@ void intel_uncore_init(struct drm_device *dev)
>   case 6:
>   if (IS_HASWELL(dev)) {
>   ASSIGN_WRITE_MMIO_VFUNCS(hsw);
> + } else if (IS_VALLEYVIEW(dev)) {
> + ASSIGN_WRITE_MMIO_VFUNCS(vlv);
>   } else {
>   ASSIGN_WRITE_MMIO_VFUNCS(gen6);
>   }
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Take forcewake on media engine writes

[Chris Wilson]

On Thu, Dec 17, 2015 at 05:39:39PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 17, 2015 at 05:14:54PM +0200, Mika Kuoppala wrote:
> > Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
> > for forcewake Individual power wells.") we have only taken
> > media engine forcewake correctly on reads, but only taken render
> > engine forcewake on media engine writes and omitted the media
> > domain.
> > 
> > This asymmetry might have caused unstable behaviour on
> > media ring access.
> > 
> > Fix is to take media engine forcewake symmetrically to writes.
> 
> We don't take any forcewake on writes pre-gen8. That's what the
> wake FIFO is for.

On the other hand, if something magically starts working, I think we can
conclude that our FIFO handling or the FIFO is broken. One or the other.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Take forcewake on media engine writes

[Jesse Barnes]

On 12/17/2015 07:14 AM, Mika Kuoppala wrote:
> Since commit 940aece471bd ("drm/i915/vlv: Valleyview support
> for forcewake Individual power wells.") we have only taken
> media engine forcewake correctly on reads, but only taken render
> engine forcewake on media engine writes and omitted the media
> domain.
> 
> This asymmetry might have caused unstable behaviour on
> media ring access.
> 
> Fix is to take media engine forcewake symmetrically to writes.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=88012
> Cc: Deepak S 
> Cc: Jesse Barnes 
> Cc: Chris Wilson 
> Signed-off-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 277e60ae0e47..a2e204088aa5 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -902,6 +902,23 @@ hsw_write##x(struct drm_i915_private *dev_priv, 
> i915_reg_t reg, u##x val, bool t
>   GEN6_WRITE_FOOTER; \
>  }
>  
> +#define __vlv_write(x) \
> +static void \
> +vlv_write##x(struct drm_i915_private *dev_priv, i915_reg_t reg, u##x val, 
> bool trace) { \
> + enum forcewake_domains fw_engine = 0; \
> + GEN6_WRITE_HEADER; \
> + if (!NEEDS_FORCE_WAKE(offset)) \
> + fw_engine = 0; \
> + else if (FORCEWAKE_VLV_RENDER_RANGE_OFFSET(offset)) \
> + fw_engine = FORCEWAKE_RENDER; \
> + else if (FORCEWAKE_VLV_MEDIA_RANGE_OFFSET(offset)) \
> + fw_engine = FORCEWAKE_MEDIA; \
> + if (fw_engine) \
> + __force_wake_get(dev_priv, fw_engine); \
> + __raw_i915_write##x(dev_priv, reg, val); \
> + GEN6_WRITE_FOOTER; \
> +}
> +
>  static const i915_reg_t gen8_shadowed_regs[] = {
>   FORCEWAKE_MT,
>   GEN6_RPNSWREQ,
> @@ -1019,6 +1036,10 @@ __gen8_write(8)
>  __gen8_write(16)
>  __gen8_write(32)
>  __gen8_write(64)
> +__vlv_write(8)
> +__vlv_write(16)
> +__vlv_write(32)
> +__vlv_write(64)
>  __hsw_write(8)
>  __hsw_write(16)
>  __hsw_write(32)
> @@ -1031,6 +1052,7 @@ __gen6_write(64)
>  #undef __gen9_write
>  #undef __chv_write
>  #undef __gen8_write
> +#undef __vlv_write
>  #undef __hsw_write
>  #undef __gen6_write
>  #undef GEN6_WRITE_FOOTER
> @@ -1243,6 +1265,8 @@ void intel_uncore_init(struct drm_device *dev)
>   case 6:
>   if (IS_HASWELL(dev)) {
>   ASSIGN_WRITE_MMIO_VFUNCS(hsw);
> + } else if (IS_VALLEYVIEW(dev)) {
> + ASSIGN_WRITE_MMIO_VFUNCS(vlv);
>   } else {
>   ASSIGN_WRITE_MMIO_VFUNCS(gen6);
>   }
> 

Looks good.  Looks like we also have it on chv, so I guess it was just
an oversight.

Reviewed-by: Jesse Barnes 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

[Daniel Vetter]

On Thu, Dec 10, 2015 at 05:41:30PM +0100, Takashi Iwai wrote:
> On Thu, 10 Dec 2015 17:36:04 +0100,
> Ville Syrjälä wrote:
> > 
> > On Fri, Dec 04, 2015 at 04:05:26PM +, Chris Wilson wrote:
> > > A long time ago (before 3.14) we relied on a permanent pinning of the
> > > ifbdev to lock the fb in place inside the GGTT. However, the
> > > introduction of stealing the BIOS framebuffer and reusing its address in
> > > the GGTT for the fbdev has muddied waters and we use an inherited fb.
> > > However, the inherited fb is only pinned whilst it is active and we no
> > > longer have an explicit pin for the info->system_base mmapping used by
> > > the fbdev. The result is that after some aperture pressure the fbdev may
> > > be evicted, but we continue to write the fbcon into the same GGTT
> > > address - overwriting anything else that may be put into that offset.
> > > The effect is most pronounced across suspend/resume as
> > > intel_fbdev_set_suspend() does a full clear over the whole scanout.
> > > 
> > > v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from
> > > the BIOS, we do not own the pinned vma (except for the reference we add
> > > in this patch for our access via info->screen_base).
> > > 
> > > v3: Finish balancing the vma pinning for the normal !preallocated case.
> > > 
> > > v4: Try to simplify the pinning even further.
> > > v5: Leak the VMA (cleaned up by object-free) to avoid complicated error 
> > > paths.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: "Goel, Akash" 
> > > Cc: Daniel Vetter 
> > > Cc: Jesse Barnes 
> > > Cc: Lukas Wunner 
> > > Cc: sta...@vger.kernel.org
> > 
> > This seems to have fixed my garbled text+fbcon dead after
> > suspend/hibernate issues. Well, only had the patch in for a day or so,
> > but so far so good.
> > 
> > Tested-by: Ville Syrjälä 
> > 
> > Takashi, don't know if you already found this patch, but it's definitely
> > something you should try as well.
> 
> Great, I'll give this a try.  Thanks!

Pulled both patches into dinq. Jani, can you please cherry-pick?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ warning: Fi.CI.BAT

[Patchwork]

== Summary ==

Built on 8463389e40c3815b2e9b052f34145b1d728975be drm-intel-nightly: 
2015y-12m-17d-14h-39m-21s UTC integration manifest

Test igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence on bdw-nuci7 
dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-dpms on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_force_connector_basic@prune-stale-modes on snb-x220t pass -> skip
Test igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a on snb-x220t pass -> 
dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-a on snb-x220t dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-c on bdw-nuci7 pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c on skl-i5k-2 dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-b on snb-dellxps dmesg-warn -> pass
Test igt@kms_setmode@basic-clone-single-crtc on snb-dellxps pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-modeset on hsw-gt2 pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-modeset on bsw-nuc-2 pass -> dmesg-warn

bdw-nuci7total:135  pass:124  dwarn:2   dfail:0   fail:0   skip:9  
bsw-nuc-2total:135  pass:113  dwarn:2   dfail:0   fail:0   skip:20 
hsw-brixbox  total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2  total:135  pass:129  dwarn:2   dfail:0   fail:0   skip:4  
ilk-hp8440p  total:135  pass:100  dwarn:0   dfail:0   fail:2   skip:33 
ivb-t430stotal:135  pass:128  dwarn:1   dfail:1   fail:1   skip:4  
skl-i5k-2total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
skl-i7k-2total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
snb-dellxps  total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220ttotal:135  pass:120  dwarn:2   dfail:0   fail:1   skip:12 

Results at /archive/results/CI_IGT_test/Patchwork_702/

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] KMS color management tests

[Lionel Landwerlin]

Hi there,

Here are a few patches for testing the color management.

This tests only support split degamma/gamma mode. I believe we could
add the additional modes (10/12bits) tests on top of that.

I will also provide additional legacy gamma tests on top of this to
make sure we don't break the existing feature.

Cheers,

-
Lionel


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] lib: kms: add helpers to get/set properties on pipes

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 lib/igt_kms.c | 40 
 lib/igt_kms.h |  9 -
 2 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index eeed468..1f37489 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1285,6 +1285,16 @@ static igt_plane_t *igt_pipe_get_plane(igt_pipe_t *pipe, 
enum igt_plane plane)
return >planes[idx];
 }
 
+bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
+  uint32_t *prop_id, uint64_t *value,
+  drmModePropertyPtr *prop)
+{
+   return get_crtc_property(pipe->display->drm_fd,
+pipe->crtc_id,
+name,
+prop_id, value, prop);
+}
+
 static uint32_t igt_plane_get_fb_id(igt_plane_t *plane)
 {
if (plane->fb)
@@ -1924,6 +1934,36 @@ void igt_plane_set_rotation(igt_plane_t *plane, 
igt_rotation_t rotation)
plane->rotation_changed = true;
 }
 
+int
+igt_pipe_set_blob_property(igt_pipe_t *pipe,
+  const char *name,
+  void *data,
+  size_t length)
+{
+   igt_display_t *display = pipe->display;
+   uint32_t blob_id = 0, prop_id;
+   int ret;
+
+   if (!igt_pipe_get_property(pipe, name, _id, NULL, NULL))
+   return -1;
+
+   if (length > 0) {
+   ret = drmModeCreatePropertyBlob(display->drm_fd,
+   data, length, _id);
+   CHECK_RETURN(ret, true);
+   }
+
+   ret = drmModeObjectSetProperty(display->drm_fd, pipe->crtc_id,
+  DRM_MODE_OBJECT_CRTC,
+  prop_id, blob_id);
+   CHECK_RETURN(ret, true);
+
+   if (blob_id != 0)
+   ret = drmModeDestroyPropertyBlob(display->drm_fd, blob_id);
+
+   return ret;
+}
+
 /**
  * igt_crtc_set_background:
  * @pipe: pipe pointer to which background color to be set
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index c12c2e1..fb8fc8a 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -256,6 +256,14 @@ static inline bool igt_plane_supports_rotation(igt_plane_t 
*plane)
return plane->rotation_property != 0;
 }
 
+bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
+  uint32_t *prop_id, uint64_t *value,
+  drmModePropertyPtr *prop);
+#define igt_pipe_has_property(pipe, prop) \
+   igt_pipe_get_property(pipe, prop, NULL, NULL, NULL)
+int igt_pipe_set_blob_property(igt_pipe_t *pipe, const char *name,
+  void *data, size_t length);
+
 void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
 void igt_plane_set_position(igt_plane_t *plane, int x, int y);
 void igt_plane_set_size(igt_plane_t *plane, int w, int h);
@@ -291,4 +299,3 @@ const unsigned char* igt_kms_get_alt_edid(void);
 
 
 #endif /* __IGT_KMS_H__ */
-
-- 
2.6.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] lib: kms: add crtc_id to igt_pipe_t

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 lib/igt_kms.c | 1 +
 lib/igt_kms.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 5d5a95c..eeed468 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1004,6 +1004,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
int p = IGT_PLANE_2;
int j, type;
 
+   pipe->crtc_id = resources->crtcs[i];
pipe->display = display;
pipe->pipe = i;
 
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 94f315f..c12c2e1 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -212,6 +212,7 @@ struct igt_pipe {
uint64_t background; /* Background color MSB BGR 16bpc LSB */
uint32_t background_changed : 1;
uint32_t background_property;
+   uint32_t crtc_id;
 };
 
 typedef struct {
-- 
2.6.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] tests/kms_color: New test for color management

[Lionel Landwerlin]

This test enables testing of :

* degamma LUTs
* csc matrix
* gamma LUTs

Signed-off-by: Lionel Landwerlin 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/kms_color.c  | 611 +
 3 files changed, 613 insertions(+)
 create mode 100644 tests/kms_color.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 7f20f2b..6fc4782 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -130,6 +130,7 @@ gen7_forcewake_mt
 kms_3d
 kms_addfb_basic
 kms_atomic
+kms_color
 kms_crtc_background_color
 kms_cursor_crc
 kms_draw_crc
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index d594038..f2af648 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -68,6 +68,7 @@ TESTS_progs_M = \
gem_write_read_ring_switch \
kms_addfb_basic \
kms_atomic \
+   kms_color \
kms_cursor_crc \
kms_draw_crc \
kms_fbc_crc \
diff --git a/tests/kms_color.c b/tests/kms_color.c
new file mode 100644
index 000..f1492a2
--- /dev/null
+++ b/tests/kms_color.c
@@ -0,0 +1,611 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+  * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include "drmtest.h"
+#include "drm.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "igt_core.h"
+#include "intel_io.h"
+#include "intel_chipset.h"
+#include "igt_aux.h"
+#include
+#include
+#include 
+#include 
+
+
+IGT_TEST_DESCRIPTION("Test Color Features at Pipe level");
+
+/* Data structures for gamma/degamma ramps & ctm matrix. */
+struct _drm_r32g32b32 {
+   __u32 r32;
+   __u32 g32;
+   __u32 b32;
+   __u32 reserved;
+};
+
+struct _drm_palette {
+   struct _drm_r32g32b32 lut[0];
+};
+
+struct _drm_ctm {
+   __s64 ctm_coeff[9];
+};
+
+/* Internal */
+typedef struct {
+   float r, g, b;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+
+   uint32_t color_depth;
+   uint64_t coeffs_after_ctm;
+   uint64_t coeffs_before_ctm;
+} data_t;
+
+
+static float ctm_identity[] = {
+   1.0, 0.0, 0.0,
+   0.0, 1.0, 0.0,
+   0.0, 0.0, 1.0
+};
+
+static void paint_gradient_rectangles(data_t *data,
+ drmModeModeInfo *mode,
+ color_t *colors,
+ struct igt_fb *fb)
+{
+   cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, fb);
+   int i, l = mode->hdisplay / 3;
+
+   /* Paint 3 gradient rectangles with red/green/blue between 1.0
+* and 0.5. We want to avoid 0 so each max LUTs only affect
+* their own rectangle.
+*/
+   for (i = 0 ; i < 3; i++) {
+   igt_paint_color_gradient_range(cr, i * l, 0, l, mode->vdisplay,
+  colors[i].r != 0 ? 0.5 : 0,
+  colors[i].g != 0 ? 0.5 : 0,
+  colors[i].b != 0 ? 0.5 : 0,
+  colors[i].r,
+  colors[i].g,
+  colors[i].b);
+   }
+
+   cairo_destroy(cr);
+}
+
+static void paint_rectangles(data_t *data,
+drmModeModeInfo *mode,
+color_t *colors,
+struct igt_fb *fb)
+{
+   cairo_t *cr = igt_get_cairo_ctx(data->drm_fd, fb);
+   int i, l = mode->hdisplay / 3;
+
+   /* Paint 3 solid rectangles. */
+   for (i = 0 ; i < 3; i++)
+   igt_paint_color(cr, i * l, 0, l, mode->vdisplay,
+   colors[i].r, colors[i].g, colors[i].b);
+
+   cairo_destroy(cr);
+}
+
+static float *generate_table(uint32_t lut_size, float exp)
+{
+   float *coeffs = 

[Intel-gfx] [PATCH 3/4] lib: fb: add igt_paint_color_gradient_range

[Lionel Landwerlin]

This is a helper to draw a gradient between 2 colors.

Signed-off-by: Lionel Landwerlin 
---
 lib/igt_fb.c | 34 ++
 lib/igt_fb.h |  3 +++
 2 files changed, 37 insertions(+)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 3ea9915..781851c 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -200,6 +200,40 @@ igt_paint_color_gradient(cairo_t *cr, int x, int y, int w, 
int h,
cairo_pattern_destroy(pat);
 }
 
+/**
+ * igt_paint_color_gradient_range:
+ * @cr: cairo drawing context
+ * @x: pixel x-coordination of the fill rectangle
+ * @y: pixel y-coordination of the fill rectangle
+ * @w: width of the fill rectangle
+ * @h: height of the fill rectangle
+ * @sr: red value to use as start gradient color
+ * @sg: green value to use as start gradient color
+ * @sb: blue value to use as start gradient color
+ * @er: red value to use as end gradient color
+ * @eg: green value to use as end gradient color
+ * @eb: blue value to use as end gradient color
+ *
+ * This functions draws a gradient into the rectangle which fades in
+ * from one color to the other using the drawing context @cr.
+ */
+void
+igt_paint_color_gradient_range(cairo_t *cr, int x, int y, int w, int h,
+  double sr, double sg, double sb,
+  double er, double eg, double eb)
+{
+   cairo_pattern_t *pat;
+
+   pat = cairo_pattern_create_linear(x, y, x + w, y + h);
+   cairo_pattern_add_color_stop_rgba(pat, 1, sr, sg, sb, 1);
+   cairo_pattern_add_color_stop_rgba(pat, 0, er, eg, eb, 1);
+
+   cairo_rectangle(cr, x, y, w, h);
+   cairo_set_source(cr, pat);
+   cairo_fill(cr);
+   cairo_pattern_destroy(pat);
+}
+
 static void
 paint_test_patterns(cairo_t *cr, int width, int height)
 {
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 37892b5..6111c55 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -92,6 +92,9 @@ void igt_paint_color_alpha(cairo_t *cr, int x, int y, int w, 
int h,
   double r, double g, double b, double a);
 void igt_paint_color_gradient(cairo_t *cr, int x, int y, int w, int h,
  int r, int g, int b);
+void igt_paint_color_gradient_range(cairo_t *cr, int x, int y, int w, int h,
+   double sr, double sg, double sb,
+   double er, double eg, double eb);
 void igt_paint_test_pattern(cairo_t *cr, int width, int height);
 void igt_paint_image(cairo_t *cr, const char *filename,
 int dst_x, int dst_y, int dst_width, int dst_height);
-- 
2.6.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/13] staging/android/sync: Support sync points created from dma-fences

[Jesse Barnes]

On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: Maarten Lankhorst 
> 
> Debug output assumes all sync points are built on top of Android sync points
> and when we start creating them from dma-fences will NULL ptr deref unless
> taught about this.
> 
> v4: Corrected patch ownership.
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Maarten Lankhorst 
> Cc: de...@driverdev.osuosl.org
> Cc: Riley Andrews 
> Cc: Greg Kroah-Hartman 
> Cc: Arve Hjønnevåg 
> ---
>  drivers/staging/android/sync_debug.c | 42 
> +++-
>  1 file changed, 22 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/staging/android/sync_debug.c 
> b/drivers/staging/android/sync_debug.c
> index 91ed2c4..f45d13c 100644
> --- a/drivers/staging/android/sync_debug.c
> +++ b/drivers/staging/android/sync_debug.c
> @@ -82,36 +82,42 @@ static const char *sync_status_str(int status)
>   return "error";
>  }
>  
> -static void sync_print_pt(struct seq_file *s, struct sync_pt *pt, bool fence)
> +static void sync_print_pt(struct seq_file *s, struct fence *pt, bool fence)
>  {
>   int status = 1;
> - struct sync_timeline *parent = sync_pt_parent(pt);
>  
> - if (fence_is_signaled_locked(>base))
> - status = pt->base.status;
> + if (fence_is_signaled_locked(pt))
> + status = pt->status;
>  
>   seq_printf(s, "  %s%spt %s",
> -fence ? parent->name : "",
> +fence && pt->ops->get_timeline_name ?
> +pt->ops->get_timeline_name(pt) : "",
>  fence ? "_" : "",
>  sync_status_str(status));
>  
>   if (status <= 0) {
>   struct timespec64 ts64 =
> - ktime_to_timespec64(pt->base.timestamp);
> + ktime_to_timespec64(pt->timestamp);
>  
>   seq_printf(s, "@%lld.%09ld", (s64)ts64.tv_sec, ts64.tv_nsec);
>   }
>  
> - if (parent->ops->timeline_value_str &&
> - parent->ops->pt_value_str) {
> + if ((!fence || pt->ops->timeline_value_str) &&
> + pt->ops->fence_value_str) {
>   char value[64];
> + bool success;
>  
> - parent->ops->pt_value_str(pt, value, sizeof(value));
> - seq_printf(s, ": %s", value);
> - if (fence) {
> - parent->ops->timeline_value_str(parent, value,
> - sizeof(value));
> - seq_printf(s, " / %s", value);
> + pt->ops->fence_value_str(pt, value, sizeof(value));
> + success = strlen(value);
> +
> + if (success)
> + seq_printf(s, ": %s", value);
> +
> + if (success && fence) {
> + pt->ops->timeline_value_str(pt, value, sizeof(value));
> +
> + if (strlen(value))
> + seq_printf(s, " / %s", value);
>   }
>   }
>  
> @@ -138,7 +144,7 @@ static void sync_print_obj(struct seq_file *s, struct 
> sync_timeline *obj)
>   list_for_each(pos, >child_list_head) {
>   struct sync_pt *pt =
>   container_of(pos, struct sync_pt, child_list);
> - sync_print_pt(s, pt, false);
> + sync_print_pt(s, >base, false);
>   }
>   spin_unlock_irqrestore(>child_list_lock, flags);
>  }
> @@ -153,11 +159,7 @@ static void sync_print_fence(struct seq_file *s, struct 
> sync_fence *fence)
>  sync_status_str(atomic_read(>status)));
>  
>   for (i = 0; i < fence->num_fences; ++i) {
> - struct sync_pt *pt =
> - container_of(fence->cbs[i].sync_pt,
> -  struct sync_pt, base);
> -
> - sync_print_pt(s, pt, true);
> + sync_print_pt(s, fence->cbs[i].sync_pt, true);
>   }
>  
>   spin_lock_irqsave(>wq.lock, flags);
> 

Reviewed-by: Jesse Barnes 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/13] drm/i915: Convert requests to use struct fence

[Jesse Barnes]

On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> There is a construct in the linux kernel called 'struct fence' that is
> intended to keep track of work that is executed on hardware. I.e. it
> solves the basic problem that the drivers 'struct
> drm_i915_gem_request' is trying to address. The request structure does
> quite a lot more than simply track the execution progress so is very
> definitely still required. However, the basic completion status side
> could be updated to use the ready made fence implementation and gain
> all the advantages that provides.
> 
> This patch makes the first step of integrating a struct fence into the
> request. It replaces the explicit reference count with that of the
> fence. It also replaces the 'is completed' test with the fence's
> equivalent. Currently, that simply chains on to the original request
> implementation. A future patch will improve this.
> 
> v3: Updated after review comments by Tvrtko Ursulin. Added fence
> context/seqno pair to the debugfs request info. Renamed fence 'driver
> name' to just 'i915'. Removed BUG_ONs.
> 
> For: VIZ-5190
> Signed-off-by: John Harrison 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  5 +--
>  drivers/gpu/drm/i915/i915_drv.h | 45 +-
>  drivers/gpu/drm/i915/i915_gem.c | 56 
> ++---
>  drivers/gpu/drm/i915/intel_lrc.c|  1 +
>  drivers/gpu/drm/i915/intel_ringbuffer.c |  1 +
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  3 ++
>  6 files changed, 81 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 7415606..5b31186 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -709,11 +709,12 @@ static int i915_gem_request_info(struct seq_file *m, 
> void *data)
>   task = NULL;
>   if (req->pid)
>   task = pid_task(req->pid, PIDTYPE_PID);
> - seq_printf(m, "%x @ %d: %s [%d]\n",
> + seq_printf(m, "%x @ %d: %s [%d], fence = %u.%u\n",
>  req->seqno,
>  (int) (jiffies - req->emitted_jiffies),
>  task ? task->comm : "",
> -task ? task->pid : -1);
> +task ? task->pid : -1,
> +req->fence.context, req->fence.seqno);
>   rcu_read_unlock();
>   }
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 436149e..aa5cba7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -51,6 +51,7 @@
>  #include 
>  #include 
>  #include "intel_guc.h"
> +#include 
>  
>  /* General customization:
>   */
> @@ -2174,7 +2175,17 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
>   * initial reference taken using kref_init
>   */
>  struct drm_i915_gem_request {
> - struct kref ref;
> + /**
> +  * Underlying object for implementing the signal/wait stuff.
> +  * NB: Never call fence_later() or return this fence object to user
> +  * land! Due to lazy allocation, scheduler re-ordering, pre-emption,
> +  * etc., there is no guarantee at all about the validity or
> +  * sequentiality of the fence's seqno! It is also unsafe to let
> +  * anything outside of the i915 driver get hold of the fence object
> +  * as the clean up when decrementing the reference count requires
> +  * holding the driver mutex lock.
> +  */
> + struct fence fence;
>  
>   /** On Which ring this request was generated */
>   struct drm_i915_private *i915;
> @@ -2251,7 +2262,13 @@ int i915_gem_request_alloc(struct intel_engine_cs 
> *ring,
>  struct intel_context *ctx,
>  struct drm_i915_gem_request **req_out);
>  void i915_gem_request_cancel(struct drm_i915_gem_request *req);
> -void i915_gem_request_free(struct kref *req_ref);
> +
> +static inline bool i915_gem_request_completed(struct drm_i915_gem_request 
> *req,
> +   bool lazy_coherency)
> +{
> + return fence_is_signaled(>fence);
> +}
> +
>  int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
>  struct drm_file *file);
>  
> @@ -2271,7 +2288,7 @@ static inline struct drm_i915_gem_request *
>  i915_gem_request_reference(struct drm_i915_gem_request *req)
>  {
>   if (req)
> - kref_get(>ref);
> + fence_get(>fence);
>   return req;
>  }
>  
> @@ -2279,7 +2296,7 @@ static inline void
>  i915_gem_request_unreference(struct drm_i915_gem_request *req)
>  {
>   

[Intel-gfx] ✗ warning: Fi.CI.BAT

[Patchwork]

== Summary ==

Built on ac2305b6c91b9a84cc12566016ece257c3ebcba3 drm-intel-nightly: 
2015y-12m-17d-16h-19m-23s UTC integration manifest

Test igt@kms_flip@basic-flip-vs-wf_vblank on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-wf_vblank on skl-i7k-2 dmesg-fail -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence on bsw-nuc-2 
dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-dpms on ilk-hp8440p pass -> dmesg-warn
Test igt@pm_rpm@basic-rte on ilk-hp8440p fail -> skip
Test igt@pm_rpm@basic-rte on ivb-t430s dmesg-fail -> skip
Test igt@pm_rpm@basic-pci-d3-state on ilk-hp8440p fail -> skip
Test igt@pm_rpm@basic-pci-d3-state on ivb-t430s fail -> skip
Test igt@kms_flip@basic-plain-flip on ivb-t430s pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b on snb-x220t dmesg-warn -> 
pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-a on snb-x220t pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c on skl-i7k-2 dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-modeset on bsw-nuc-2 dmesg-warn -> pass

bsw-nuc-2total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
hsw-brixbox  total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2  total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p  total:135  pass:99   dwarn:1   dfail:0   fail:0   skip:35 
ivb-t430stotal:135  pass:127  dwarn:2   dfail:0   fail:0   skip:6  
skl-i5k-2total:135  pass:122  dwarn:5   dfail:0   fail:0   skip:8  
skl-i7k-2total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
snb-dellxps  total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220ttotal:135  pass:121  dwarn:2   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_705/

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/13] drm/i915: Add per context timelines to fence object

[Jesse Barnes]

On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The fence object used inside the request structure requires a sequence
> number. Although this is not used by the i915 driver itself, it could
> potentially be used by non-i915 code if the fence is passed outside of
> the driver. This is the intention as it allows external kernel drivers
> and user applications to wait on batch buffer completion
> asynchronously via the dma-buff fence API.
> 
> To ensure that such external users are not confused by strange things
> happening with the seqno, this patch adds in a per context timeline
> that can provide a guaranteed in-order seqno value for the fence. This
> is safe because the scheduler will not re-order batch buffers within a
> context - they are considered to be mutually dependent.
> 
> v2: New patch in series.
> 
> v3: Renamed/retyped timeline structure fields after review comments by
> Tvrtko Ursulin.
> 
> Added context information to the timeline's name string for better
> identification in debugfs output.
> 
> For: VIZ-5190
> Signed-off-by: John Harrison 
> Cc: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 25 ---
>  drivers/gpu/drm/i915/i915_gem.c | 80 
> +
>  drivers/gpu/drm/i915/i915_gem_context.c | 15 ++-
>  drivers/gpu/drm/i915/intel_lrc.c|  8 
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
>  5 files changed, 111 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index caf7897..7d6a7c0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -841,6 +841,15 @@ struct i915_ctx_hang_stats {
>   bool banned;
>  };
>  
> +struct i915_fence_timeline {
> + charname[32];
> + unsignedfence_context;
> + unsignednext;
> +
> + struct intel_context *ctx;
> + struct intel_engine_cs *ring;
> +};
> +
>  /* This must match up with the value previously used for execbuf2.rsvd1. */
>  #define DEFAULT_CONTEXT_HANDLE 0
>  
> @@ -885,6 +894,7 @@ struct intel_context {
>   struct drm_i915_gem_object *state;
>   struct intel_ringbuffer *ringbuf;
>   int pin_count;
> + struct i915_fence_timeline fence_timeline;
>   } engine[I915_NUM_RINGS];
>  
>   struct list_head link;
> @@ -2177,13 +2187,10 @@ void i915_gem_track_fb(struct drm_i915_gem_object 
> *old,
>  struct drm_i915_gem_request {
>   /**
>* Underlying object for implementing the signal/wait stuff.
> -  * NB: Never call fence_later() or return this fence object to user
> -  * land! Due to lazy allocation, scheduler re-ordering, pre-emption,
> -  * etc., there is no guarantee at all about the validity or
> -  * sequentiality of the fence's seqno! It is also unsafe to let
> -  * anything outside of the i915 driver get hold of the fence object
> -  * as the clean up when decrementing the reference count requires
> -  * holding the driver mutex lock.
> +  * NB: Never return this fence object to user land! It is unsafe to
> +  * let anything outside of the i915 driver get hold of the fence
> +  * object as the clean up when decrementing the reference count
> +  * requires holding the driver mutex lock.
>*/
>   struct fence fence;
>  
> @@ -2263,6 +2270,10 @@ int i915_gem_request_alloc(struct intel_engine_cs 
> *ring,
>  struct drm_i915_gem_request **req_out);
>  void i915_gem_request_cancel(struct drm_i915_gem_request *req);
>  
> +int i915_create_fence_timeline(struct drm_device *dev,
> +struct intel_context *ctx,
> +struct intel_engine_cs *ring);
> +
>  static inline bool i915_gem_request_completed(struct drm_i915_gem_request 
> *req)
>  {
>   return fence_is_signaled(>fence);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0801738..7a37fb7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2665,9 +2665,32 @@ static const char 
> *i915_gem_request_get_driver_name(struct fence *req_fence)
>  
>  static const char *i915_gem_request_get_timeline_name(struct fence 
> *req_fence)
>  {
> - struct drm_i915_gem_request *req = container_of(req_fence,
> -  typeof(*req), fence);
> - return req->ring->name;
> + struct drm_i915_gem_request *req;
> + struct i915_fence_timeline *timeline;
> +
> + req = container_of(req_fence, typeof(*req), fence);
> + timeline = >ctx->engine[req->ring->id].fence_timeline;
> +
> + return timeline->name;
> +}
> +
> +static void i915_gem_request_timeline_value_str(struct fence *req_fence, 
> char *str, int size)
> +{
> + struct drm_i915_gem_request *req;
> 

Re: [Intel-gfx] [PATCH] drm/i915: don't enable autosuspend on platforms without RPM support

[Imre Deak]

On to, 2015-12-17 at 17:19 +, Chris Wilson wrote:
> On Thu, Dec 17, 2015 at 07:04:33PM +0200, Imre Deak wrote:
> > Since
> > 
> > commit 357597e51dd1aa3cf764d322abf89217e3dcd7bb
> > Author: Imre Deak 
> > Date:   Tue Nov 10 06:12:22 2015 +0200
> > 
> > drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert
> > helpers
> > 
> > this file is writeable also on platforms without RPM support, but
> 
> Which file?

sysfs power/autosuspend_delay_ms is only writeable by userspace if we
call pm_runtime_use_autosuspend().

> 
> > userspace (at least IGT) depends on this file being unchangable to
> > determine whether the device supports autosuspend. So restore the
> > old
> > behavior.
> > 
> > This gets rid of igt/pm_rpm failures on old platforms without RPM
> > support, where the test should be skipped.
> > 
> > Testcase: igt/pm_rpm/basic-rte
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
> >  1 file changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index a0b9eaf..ddbdbff 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -2309,18 +2309,21 @@ void intel_runtime_pm_enable(struct
> > drm_i915_private *dev_priv)
> >     struct drm_device *dev = dev_priv->dev;
> >     struct device *device = >pdev->dev;
> >  
> > +   pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
> > +   pm_runtime_mark_last_busy(device);
> > +
> >     /*
> >      * Take a permanent reference to disable the RPM
> > functionality and drop
> >      * it only when unloading the driver. Use the low level
> > get/put helpers,
> >      * so the driver's own RPM reference tracking asserts also
> > work on
> >      * platforms without RPM support.
> >      */
> > -   if (!HAS_RUNTIME_PM(dev))
> > +   if (!HAS_RUNTIME_PM(dev)) {
> > +   pm_runtime_dont_use_autosuspend(device);
> >     pm_runtime_get_sync(device);
> > -
> > -   pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
> > -   pm_runtime_mark_last_busy(device);
> > -   pm_runtime_use_autosuspend(device);
> > +   } else {
> > +   pm_runtime_use_autosuspend(device);
> > +   }
> 
> This seems to make sense to me.
> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/13] staging/android/sync: add sync_fence_create_dma

[Jesse Barnes]

On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: Maarten Lankhorst 
> 
> This allows users of dma fences to create a android fence.
> 
> v2: Added kerneldoc. (Tvrtko Ursulin).
> 
> v4: Updated comments from review feedback my Maarten.
> 
> Signed-off-by: Maarten Lankhorst 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Jesse Barnes 
> Cc: de...@driverdev.osuosl.org
> Cc: Riley Andrews 
> Cc: Greg Kroah-Hartman 
> Cc: Arve Hjønnevåg 
> ---
>  drivers/staging/android/sync.c | 13 +
>  drivers/staging/android/sync.h | 10 ++
>  2 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index f83e00c..7f0e919 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -188,7 +188,7 @@ static void fence_check_cb_func(struct fence *f, struct 
> fence_cb *cb)
>  }
>  
>  /* TODO: implement a create which takes more that one sync_pt */
> -struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
> +struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt)
>  {
>   struct sync_fence *fence;
>  
> @@ -199,16 +199,21 @@ struct sync_fence *sync_fence_create(const char *name, 
> struct sync_pt *pt)
>   fence->num_fences = 1;
>   atomic_set(>status, 1);
>  
> - fence->cbs[0].sync_pt = >base;
> + fence->cbs[0].sync_pt = pt;
>   fence->cbs[0].fence = fence;
> - if (fence_add_callback(>base, >cbs[0].cb,
> -fence_check_cb_func))
> + if (fence_add_callback(pt, >cbs[0].cb, fence_check_cb_func))
>   atomic_dec(>status);
>  
>   sync_fence_debug_add(fence);
>  
>   return fence;
>  }
> +EXPORT_SYMBOL(sync_fence_create_dma);
> +
> +struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
> +{
> + return sync_fence_create_dma(name, >base);
> +}
>  EXPORT_SYMBOL(sync_fence_create);
>  
>  struct sync_fence *sync_fence_fdget(int fd)
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index 61f8a3a..afa0752 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -254,6 +254,16 @@ void sync_pt_free(struct sync_pt *pt);
>   */
>  struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt);
>  
> +/**
> + * sync_fence_create_dma() - creates a sync fence from dma-fence
> + * @name:name of fence to create
> + * @pt:  dma-fence to add to the fence
> + *
> + * Creates a fence containg @pt.  Once this is called, the fence takes
> + * ownership of @pt.
> + */
> +struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt);
> +
>  /*
>   * API for sync_fence consumers
>   */
> 

I've been using this one for awhile, so:
Reviewed-by: Jesse Barnes 
Tested-by: Jesse Barnes 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: don't enable autosuspend on platforms without RPM support

[Chris Wilson]

On Thu, Dec 17, 2015 at 07:04:33PM +0200, Imre Deak wrote:
> Since
> 
> commit 357597e51dd1aa3cf764d322abf89217e3dcd7bb
> Author: Imre Deak 
> Date:   Tue Nov 10 06:12:22 2015 +0200
> 
> drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
> 
> this file is writeable also on platforms without RPM support, but

Which file?

> userspace (at least IGT) depends on this file being unchangable to
> determine whether the device supports autosuspend. So restore the old
> behavior.
> 
> This gets rid of igt/pm_rpm failures on old platforms without RPM
> support, where the test should be skipped.
> 
> Testcase: igt/pm_rpm/basic-rte
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index a0b9eaf..ddbdbff 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2309,18 +2309,21 @@ void intel_runtime_pm_enable(struct drm_i915_private 
> *dev_priv)
>   struct drm_device *dev = dev_priv->dev;
>   struct device *device = >pdev->dev;
>  
> + pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
> + pm_runtime_mark_last_busy(device);
> +
>   /*
>* Take a permanent reference to disable the RPM functionality and drop
>* it only when unloading the driver. Use the low level get/put helpers,
>* so the driver's own RPM reference tracking asserts also work on
>* platforms without RPM support.
>*/
> - if (!HAS_RUNTIME_PM(dev))
> + if (!HAS_RUNTIME_PM(dev)) {
> + pm_runtime_dont_use_autosuspend(device);
>   pm_runtime_get_sync(device);
> -
> - pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
> - pm_runtime_mark_last_busy(device);
> - pm_runtime_use_autosuspend(device);
> + } else {
> + pm_runtime_use_autosuspend(device);
> + }

This seems to make sense to me.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] mm: Export {__}get_nr_swap_pages()

[Dave Gordon]

Some modules, like i915.ko, use swappable objects and may try to swap
them out under memory pressure (via the shrinker). Before doing so,
they want to check using get_nr_swap_pages() to see if any swap space
is available as otherwise they will waste time purging the object from
the device without recovering any memory for the system. This requires
the kernel function get_nr_swap_pages() to be exported to the modules.

The current implementation of this function is as a static inline
inside the header file swap.h>; this doesn't work when compiled in
a module, as the necessary global data is not visible. The original
proposed solution was to export the kernel global variable to modules,
but this was considered poor practice as it exposed more than necessary,
and in an uncontrolled fashion. Another idea was to turn it into a real
(non-inline) function; however this was considered to unnecessarily add
overhead for users within the base kernel.

Therefore, to avoid both objections, this patch leaves the base kernel
implementation unchanged, but adds a separate (read-only) functional
interface for callers in loadable kernel modules (LKMs). Which definition
is visible to code depends on the compile-time symbol MODULE, defined
by the Kbuild system when building an LKM.

Signed-off-by: Dave Gordon 
Cc: Chris Wilson 
Cc: "Goel, Akash" 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: linux...@kvack.org
Cc: intel-gfx@lists.freedesktop.org
---
 include/linux/swap.h | 12 
 mm/swapfile.c|  7 +++
 2 files changed, 19 insertions(+)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 7ba7dcc..7dac1fe 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -413,6 +413,10 @@ extern struct page *swapin_readahead(swp_entry_t, gfp_t,
struct vm_area_struct *vma, unsigned long addr);
 
 /* linux/mm/swapfile.c */
+
+#ifndefMODULE
+
+/* Inside the base kernel, code can see these variables */
 extern atomic_long_t nr_swap_pages;
 extern long total_swap_pages;
 
@@ -427,6 +431,14 @@ static inline long get_nr_swap_pages(void)
return atomic_long_read(_swap_pages);
 }
 
+#else  /* MODULE */
+
+/* Only this read-only interface is available to modules */
+extern long __get_nr_swap_pages(void);
+#defineget_nr_swap_pages   __get_nr_swap_pages
+
+#endif /* MODULE */
+
 extern void si_swapinfo(struct sysinfo *);
 extern swp_entry_t get_swap_page(void);
 extern swp_entry_t get_swap_page_of_type(int);
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 5887731..9309d6e 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -2754,6 +2754,13 @@ pgoff_t __page_file_index(struct page *page)
 }
 EXPORT_SYMBOL_GPL(__page_file_index);
 
+/* Trivial accessor exported to kernel modules */
+long __get_nr_swap_pages(void)
+{
+   return get_nr_swap_pages();
+}
+EXPORT_SYMBOL_GPL(__get_nr_swap_pages);
+
 /*
  * add_swap_count_continuation - called when a swap count is duplicated
  * beyond SWAP_MAP_MAX, it allocates a new page and links that to the entry's
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: don't enable autosuspend on platforms without RPM support

[Imre Deak]

Since

commit 357597e51dd1aa3cf764d322abf89217e3dcd7bb
Author: Imre Deak 
Date:   Tue Nov 10 06:12:22 2015 +0200

drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers

this file is writeable also on platforms without RPM support, but
userspace (at least IGT) depends on this file being unchangable to
determine whether the device supports autosuspend. So restore the old
behavior.

This gets rid of igt/pm_rpm failures on old platforms without RPM
support, where the test should be skipped.

Testcase: igt/pm_rpm/basic-rte
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index a0b9eaf..ddbdbff 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2309,18 +2309,21 @@ void intel_runtime_pm_enable(struct drm_i915_private 
*dev_priv)
struct drm_device *dev = dev_priv->dev;
struct device *device = >pdev->dev;
 
+   pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
+   pm_runtime_mark_last_busy(device);
+
/*
 * Take a permanent reference to disable the RPM functionality and drop
 * it only when unloading the driver. Use the low level get/put helpers,
 * so the driver's own RPM reference tracking asserts also work on
 * platforms without RPM support.
 */
-   if (!HAS_RUNTIME_PM(dev))
+   if (!HAS_RUNTIME_PM(dev)) {
+   pm_runtime_dont_use_autosuspend(device);
pm_runtime_get_sync(device);
-
-   pm_runtime_set_autosuspend_delay(device, 1); /* 10s */
-   pm_runtime_mark_last_busy(device);
-   pm_runtime_use_autosuspend(device);
+   } else {
+   pm_runtime_use_autosuspend(device);
+   }
 
/*
 * The core calls the driver load handler with an RPM reference held.
-- 
2.5.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/13] staging/android/sync: Move sync framework out of staging

[Jesse Barnes]

On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The sync framework is now used by the i915 driver. Therefore it can be
> moved out of staging and into the regular tree. Also, the public
> interfaces can actually be made public and exported.
> 
> v3: New patch for series.
> 
> Signed-off-by: John Harrison 
> Signed-off-by: Geoff Miller 
> ---
>  drivers/android/Kconfig|  28 ++
>  drivers/android/Makefile   |   2 +
>  drivers/android/sw_sync.c  | 260 
>  drivers/android/sw_sync.h  |  59 +++
>  drivers/android/sync.c | 734 
> +
>  drivers/android/sync.h | 366 
>  drivers/android/sync_debug.c   | 256 
>  drivers/android/trace/sync.h   |  82 
>  drivers/staging/android/Kconfig|  28 --
>  drivers/staging/android/Makefile   |   2 -
>  drivers/staging/android/sw_sync.c  | 260 
>  drivers/staging/android/sw_sync.h  |  59 ---
>  drivers/staging/android/sync.c | 734 
> -
>  drivers/staging/android/sync.h | 366 
>  drivers/staging/android/sync_debug.c   | 256 
>  drivers/staging/android/trace/sync.h   |  82 
>  drivers/staging/android/uapi/sw_sync.h |  32 --
>  drivers/staging/android/uapi/sync.h|  97 -
>  include/uapi/Kbuild|   1 +
>  include/uapi/sync/Kbuild   |   3 +
>  include/uapi/sync/sw_sync.h|  32 ++
>  include/uapi/sync/sync.h   |  97 +
>  22 files changed, 1920 insertions(+), 1916 deletions(-)
>  create mode 100644 drivers/android/sw_sync.c
>  create mode 100644 drivers/android/sw_sync.h
>  create mode 100644 drivers/android/sync.c
>  create mode 100644 drivers/android/sync.h
>  create mode 100644 drivers/android/sync_debug.c
>  create mode 100644 drivers/android/trace/sync.h
>  delete mode 100644 drivers/staging/android/sw_sync.c
>  delete mode 100644 drivers/staging/android/sw_sync.h
>  delete mode 100644 drivers/staging/android/sync.c
>  delete mode 100644 drivers/staging/android/sync.h
>  delete mode 100644 drivers/staging/android/sync_debug.c
>  delete mode 100644 drivers/staging/android/trace/sync.h
>  delete mode 100644 drivers/staging/android/uapi/sw_sync.h
>  delete mode 100644 drivers/staging/android/uapi/sync.h
>  create mode 100644 include/uapi/sync/Kbuild
>  create mode 100644 include/uapi/sync/sw_sync.h
>  create mode 100644 include/uapi/sync/sync.h
> 
> diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig
> index bdfc6c6..9edcd8f 100644
> --- a/drivers/android/Kconfig
> +++ b/drivers/android/Kconfig
> @@ -32,6 +32,34 @@ config ANDROID_BINDER_IPC_32BIT
>  
> Note that enabling this will break newer Android user-space.
>  
> +config SYNC
> + bool "Synchronization framework"
> + default n
> + select ANON_INODES
> + select DMA_SHARED_BUFFER
> + ---help---
> +   This option enables the framework for synchronization between multiple
> +   drivers.  Sync implementations can take advantage of hardware
> +   synchronization built into devices like GPUs.
> +
> +config SW_SYNC
> + bool "Software synchronization objects"
> + default n
> + depends on SYNC
> + ---help---
> +   A sync object driver that uses a 32bit counter to coordinate
> +   synchronization.  Useful when there is no hardware primitive backing
> +   the synchronization.
> +
> +config SW_SYNC_USER
> + bool "Userspace API for SW_SYNC"
> + default n
> + depends on SW_SYNC
> + ---help---
> +   Provides a user space API to the sw sync object.
> +   *WARNING* improper use of this can result in deadlocking kernel
> +   drivers from userspace.
> +
>  endif # if ANDROID

IIRC we wanted to drop the user ABI altogether?  I think we can de-stage this 
even before we push the new ABI on the i915 side to expose the sync points 
(since we'll need an open source userspace for that), and any changes/cleanups 
can happen outside of staging.

Thanks,
Jesse

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Hide one invalid cancellation bug in i915_switch_context()

[Chris Wilson]

As we add the VMA to the request early, it may be cancelled during
execbuf reservation. This will leave the context object pointing to a
dangling request; i915_wait_request() simply skips the wait and so we
may unbind the object whilst it is still active.

We can partially prevent such atrocity by doing the RCS context
initialisation earlier. This ensures that one callsite from blowing up
(and for igt this is a frequent culprit due to how the stressful batches
are submitted).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem_context.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 900ffd044db8..657686e6492f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -657,7 +657,6 @@ static int do_switch(struct drm_i915_gem_request *req)
struct drm_i915_private *dev_priv = ring->dev->dev_private;
struct intel_context *from = ring->last_context;
u32 hw_flags = 0;
-   bool uninitialized = false;
int ret, i;
 
if (from != NULL && ring == _priv->ring[RCS]) {
@@ -764,6 +763,15 @@ static int do_switch(struct drm_i915_gem_request *req)
to->remap_slice &= ~(1<legacy_hw_ctx.initialized) {
+   if (ring->init_context) {
+   ret = ring->init_context(req);
+   if (ret)
+   goto unpin_out;
+   }
+   to->legacy_hw_ctx.initialized = true;
+   }
+
/* The backing object for the context is done after switching to the
 * *next* context. Therefore we cannot retire the previous context until
 * the next context has already started running. In fact, the below code
@@ -772,6 +780,14 @@ static int do_switch(struct drm_i915_gem_request *req)
 */
if (from != NULL) {
from->legacy_hw_ctx.rcs_state->base.read_domains = 
I915_GEM_DOMAIN_INSTRUCTION;
+   /* XXX Note very well this is dangerous!
+* We are pinning this object using this request as our
+* active reference. However, this request may yet be cancelled
+* during the execbuf dispatch, leaving us waiting on a
+* dangling request. Waiting upon this dangling request is
+* ignored, which means that we may unbind the context whilst
+* the GPU is still writing to the backing storage.
+*/

i915_vma_move_to_active(i915_gem_obj_to_ggtt(from->legacy_hw_ctx.rcs_state), 
req);
/* As long as MI_SET_CONTEXT is serializing, ie. it flushes the
 * whole damn pipeline, we don't need to explicitly mark the
@@ -787,21 +803,10 @@ static int do_switch(struct drm_i915_gem_request *req)
i915_gem_context_unreference(from);
}
 
-   uninitialized = !to->legacy_hw_ctx.initialized;
-   to->legacy_hw_ctx.initialized = true;
-
 done:
i915_gem_context_reference(to);
ring->last_context = to;
 
-   if (uninitialized) {
-   if (ring->init_context) {
-   ret = ring->init_context(req);
-   if (ret)
-   DRM_ERROR("ring init context: %d\n", ret);
-   }
-   }
-
return 0;
 
 unpin_out:
-- 
2.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Add GuC ADS - scheduler policies

[Yu Dai]

On 12/16/2015 11:39 PM, Chris Wilson wrote:

On Wed, Dec 16, 2015 at 01:40:53PM -0800, yu@intel.com wrote:
> From: Alex Dai 
>
> GuC supports different scheduling policies for its four internal
> queues. Currently these have been set to the same default values
> as KMD_NORMAL queue.
>
> Particularly POLICY_MAX_NUM_WI is set to 15 to match GuC internal
> maximum submit queue numbers to avoid an out-of-space problem.
> This value indicates max number of work items allowed to be queued
> for one DPC process. A smaller value will let GuC schedule more
> frequently while a larger number may increase chances to optimize
> cmds (such as collapse cmds from same lrc) with risks that keeps
> CS idle.
>
> Signed-off-by: Alex Dai 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 31 +++-
>  drivers/gpu/drm/i915/intel_guc_fwif.h  | 45 
++
>  2 files changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 66d85c3..a5c555c 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -842,17 +842,39 @@ static void guc_create_log(struct intel_guc *guc)
>guc->log_flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
>  }
>
> +static void init_guc_policies(struct guc_policies *policies)
> +{
> +  struct guc_policy *policy;
> +  u32 p, i;
> +
> +  policies->dpc_promote_time = 50;
> +  policies->max_num_work_items = POLICY_MAX_NUM_WI;
> +
> +  for (p = 0; p < GUC_CTX_PRIORITY_NUM; p++)
> +  for (i = 0; i < I915_NUM_RINGS; i++) {

Please indent this properly.

> +  policy = >policy[p][i];
> +
> +  policy->execution_quantum = 100;
> +  policy->preemption_time = 50;
> +  policy->fault_time = 25;
> +  policy->policy_flags = 0;
> +  }
> +
> +  policies->is_valid = 1;
> +}
> +
>  static void guc_create_ads(struct intel_guc *guc)
>  {
>struct drm_i915_private *dev_priv = guc_to_i915(guc);
>struct drm_i915_gem_object *obj;
>struct guc_ads *ads;
> +  struct guc_policies *policies;
>struct intel_engine_cs *ring;
>struct page *page;
>u32 size, i;
>
>/* The ads obj includes the struct itself and buffers passed to GuC */
> -  size = sizeof(struct guc_ads);
> +  size = sizeof(struct guc_ads) + sizeof(struct guc_policies);
>
>obj = guc->ads_obj;
>if (!obj) {
> @@ -884,6 +906,13 @@ static void guc_create_ads(struct intel_guc *guc)
>for_each_ring(ring, dev_priv, i)
>ads->eng_state_size[i] = intel_lr_context_size(ring);
>
> +  /* GuC scheduling policies */
> +  policies = (void *)ads + sizeof(struct guc_ads);
> +  init_guc_policies(policies);

Please limit atomic context to only the critical section, i.e. don't
make me have to read every single function to check for violations.


Could you clarify this? I am not sure what's the atomic context and 
critical section you mentioned here.


Alex

> +
> +  ads->scheduler_policies = i915_gem_obj_ggtt_offset(obj) +
> +  sizeof(struct guc_ads);
> +
>kunmap_atomic(ads);



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/13] android/sync: Improved debug dump to dmesg

[Jesse Barnes]

On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The sync code has a facility for dumping current state information via
> debugfs. It also has a way to re-use the same code for dumping to the
> kernel log on an internal error. However, the redirection was rather
> clunky and split the output across multiple prints at arbitrary
> boundaries. This made it difficult to read and could result in output
> from different sources being randomly interspersed.
> 
> This patch improves the redirection code to split the output on line
> feed boundaries instead. It also adds support for highlighting the
> offending fence object that caused the state dump in the first place.
> 
> v4: New patch in series.
> 
> Signed-off-by: John Harrison 
> ---
>  drivers/android/sync.c   |  9 ++--
>  drivers/android/sync.h   |  5 +++--
>  drivers/android/sync_debug.c | 50 
> 
>  3 files changed, 47 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/android/sync.c b/drivers/android/sync.c
> index 7f0e919..db4a54b 100644
> --- a/drivers/android/sync.c
> +++ b/drivers/android/sync.c
> @@ -86,6 +86,11 @@ static void sync_timeline_put(struct sync_timeline *obj)
>  
>  void sync_timeline_destroy(struct sync_timeline *obj)
>  {
> + if (!list_empty(>active_list_head)) {
> + pr_info("destroying timeline with outstanding fences!\n");
> + sync_dump_timeline(obj);
> + }
> +
>   obj->destroyed = true;
>   /*
>* Ensure timeline is marked as destroyed before
> @@ -397,7 +402,7 @@ int sync_fence_wait(struct sync_fence *fence, long 
> timeout)
>   if (timeout) {
>   pr_info("fence timeout on [%p] after %dms\n", fence,
>   jiffies_to_msecs(timeout));
> - sync_dump();
> + sync_dump(fence);
>   }
>   return -ETIME;
>   }
> @@ -405,7 +410,7 @@ int sync_fence_wait(struct sync_fence *fence, long 
> timeout)
>   ret = atomic_read(>status);
>   if (ret) {
>   pr_info("fence error %ld on [%p]\n", ret, fence);
> - sync_dump();
> + sync_dump(fence);
>   }
>   return ret;
>  }
> diff --git a/drivers/android/sync.h b/drivers/android/sync.h
> index 4ccff01..d57fa0a 100644
> --- a/drivers/android/sync.h
> +++ b/drivers/android/sync.h
> @@ -351,14 +351,15 @@ void sync_timeline_debug_add(struct sync_timeline *obj);
>  void sync_timeline_debug_remove(struct sync_timeline *obj);
>  void sync_fence_debug_add(struct sync_fence *fence);
>  void sync_fence_debug_remove(struct sync_fence *fence);
> -void sync_dump(void);
> +void sync_dump(struct sync_fence *fence);
> +void sync_dump_timeline(struct sync_timeline *timeline);
>  
>  #else
>  # define sync_timeline_debug_add(obj)
>  # define sync_timeline_debug_remove(obj)
>  # define sync_fence_debug_add(fence)
>  # define sync_fence_debug_remove(fence)
> -# define sync_dump()
> +# define sync_dump(fence)
>  #endif
>  int sync_fence_wake_up_wq(wait_queue_t *curr, unsigned mode,
>int wake_flags, void *key);
> diff --git a/drivers/android/sync_debug.c b/drivers/android/sync_debug.c
> index f45d13c..9b87e0a 100644
> --- a/drivers/android/sync_debug.c
> +++ b/drivers/android/sync_debug.c
> @@ -229,28 +229,52 @@ late_initcall(sync_debugfs_init);
>  
>  #define DUMP_CHUNK 256
>  static char sync_dump_buf[64 * 1024];
> -void sync_dump(void)
> +
> +static void sync_dump_dfs(struct seq_file *s, void *targetPtr)
> +{
> + char *start, *end;
> + char targetStr[100];
> +
> + if (targetPtr)
> + snprintf(targetStr, sizeof(targetStr) - 1, "%p", targetPtr);
> +
> + start = end = s->buf;
> + while( (end = strchr(end, '\n'))) {
> + *end = 0;
> + if (targetPtr && strstr(start, targetStr))
> + pr_info("*** %s ***\n", start);
> + else
> + pr_info("%s\n", start);
> + start = ++end;
> + }
> +
> + if ((start - s->buf) < s->count)
> + pr_info("%d vs %d: >?>%sbuf), 
> (uint32_t) s->count, start);
> +}
> +
> +void sync_dump(struct sync_fence *targetPtr)
>  {
>   struct seq_file s = {
>   .buf = sync_dump_buf,
>   .size = sizeof(sync_dump_buf) - 1,
>   };
> - int i;
>  
>   sync_debugfs_show(, NULL);
>  
> - for (i = 0; i < s.count; i += DUMP_CHUNK) {
> - if ((s.count - i) > DUMP_CHUNK) {
> - char c = s.buf[i + DUMP_CHUNK];
> + sync_dump_dfs(, targetPtr);
> +}
>  
> - s.buf[i + DUMP_CHUNK] = 0;
> - pr_cont("%s", s.buf + i);
> - s.buf[i + DUMP_CHUNK] = c;
> - } else {
> - s.buf[s.count] = 0;
> - pr_cont("%s", s.buf + i);
> -   

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation

[kbuild test robot]

Hi Alex,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20151217]
[cannot apply to v4.4-rc5]

url:
https://github.com/0day-ci/linux/commits/yu-dai-intel-com/drm-i915-guc-Add-GuC-ADS-Addition-Data-Structure-allocation/20151218-030155
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-nfsroot (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_guc_submission.c: In function 'guc_create_ads':
>> drivers/gpu/drm/i915/i915_guc_submission.c:870:28: error: implicit 
>> declaration of function 'intel_lr_context_size' 
>> [-Werror=implicit-function-declaration]
  ads->eng_state_size[i] = intel_lr_context_size(ring);
   ^
   cc1: some warnings being treated as errors

vim +/intel_lr_context_size +870 drivers/gpu/drm/i915/i915_guc_submission.c

   864   * to find it.
   865   */
   866  ring = _priv->ring[RCS];
   867  ads->golden_context_lrca = ring->status_page.gfx_addr;
   868  
   869  for_each_ring(ring, dev_priv, i)
 > 870  ads->eng_state_size[i] = intel_lr_context_size(ring);
   871  
   872  kunmap_atomic(ads);
   873  }

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] mm: Export {__}get_nr_swap_pages()

[Johannes Weiner]

On Thu, Dec 17, 2015 at 06:15:44PM +, Dave Gordon wrote:
> Some modules, like i915.ko, use swappable objects and may try to swap
> them out under memory pressure (via the shrinker). Before doing so,
> they want to check using get_nr_swap_pages() to see if any swap space
> is available as otherwise they will waste time purging the object from
> the device without recovering any memory for the system. This requires
> the kernel function get_nr_swap_pages() to be exported to the modules.
> 
> The current implementation of this function is as a static inline
> inside the header file swap.h>; this doesn't work when compiled in
> a module, as the necessary global data is not visible. The original
> proposed solution was to export the kernel global variable to modules,
> but this was considered poor practice as it exposed more than necessary,
> and in an uncontrolled fashion. Another idea was to turn it into a real
> (non-inline) function; however this was considered to unnecessarily add
> overhead for users within the base kernel.
> 
> Therefore, to avoid both objections, this patch leaves the base kernel
> implementation unchanged, but adds a separate (read-only) functional
> interface for callers in loadable kernel modules (LKMs). Which definition
> is visible to code depends on the compile-time symbol MODULE, defined
> by the Kbuild system when building an LKM.

I'm sorry, but this is beyond silly. 19 lines of code to fix a
non-existent problem? This lacks any sort of proportionality.

NAK
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/6] drm/i915: Add i915.debug parameter

[Joonas Lahtinen]

Add i915.debug parameter to control output in cases where the debug output
amount will be massive and as such is unsuitable for everyday use, but still
significant in value when solving bugs.

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h| 1 -
 drivers/gpu/drm/i915/i915_params.c | 6 ++
 drivers/gpu/drm/i915/i915_params.h | 1 +
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ae4b433..37fce5a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2659,7 +2659,6 @@ extern int i915_max_ioctl;
 extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state);
 extern int i915_resume_switcheroo(struct drm_device *dev);
 
-/* i915_dma.c */
 extern int i915_driver_load(struct drm_device *, unsigned long flags);
 extern int i915_driver_unload(struct drm_device *);
 extern int i915_driver_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 8d90c25..e76af8d 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -57,6 +57,7 @@ struct i915_params i915 __read_mostly = {
.edp_vswing = 0,
.enable_guc_submission = false,
.guc_log_level = -1,
+   .debug = false,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -203,3 +204,8 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC 
submission (default:false)")
 module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
 MODULE_PARM_DESC(guc_log_level,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
+
+module_param_named(debug, i915.debug, bool, 0600);
+MODULE_PARM_DESC(debug,
+   "Enable verbose debug output unsuitable for everyday use (default: 
false). "
+   "For developers only.");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index a748ebc..9a7c540 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -60,6 +60,7 @@ struct i915_params {
bool enable_guc_submission;
bool verbose_state_checks;
bool nuclear_pageflip;
+   bool debug;
 };
 
 extern struct i915_params i915 __read_mostly;
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915: Use I915_WARN_RECUR for recurring warning messages

[Joonas Lahtinen]

Avoid flooding end users kernel log with warnings and mark recurring
warnings as such. This is a case when multiple code paths trigger a
warning and only displaying it once masks multiple errors in CI.

Cc: Imre Deak 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 2 +-
 drivers/gpu/drm/i915/intel_drv.h | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 07240af..20306e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -133,7 +133,7 @@
if (WARN(unlikely(!__warned || i915.debug), format))\
__warned = true;\
}   \
-   unlikely(__ret_debug_on);   \
+   unlikely(__ret_warn_on);\
 })
 
 static inline const char *yesno(bool v)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d523ebb..c9e9f42 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1434,7 +1434,7 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
 static inline void
 assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
 {
-   WARN_ONCE(dev_priv->pm.suspended,
+   I915_WARN_RECUR(dev_priv->pm.suspended,
  "Device suspended during HW access\n");
 }
 
@@ -1442,7 +1442,7 @@ static inline void
 assert_rpm_wakelock_held(struct drm_i915_private *dev_priv)
 {
assert_rpm_device_not_suspended(dev_priv);
-   WARN_ONCE(!atomic_read(_priv->pm.wakeref_count),
+   I915_WARN_RECUR(!atomic_read(_priv->pm.wakeref_count),
  "RPM wakelock ref not held during HW access");
 }
 
@@ -1459,7 +1459,7 @@ assert_rpm_atomic_begin(struct drm_i915_private *dev_priv)
 static inline void
 assert_rpm_atomic_end(struct drm_i915_private *dev_priv, int begin_seq)
 {
-   WARN_ONCE(atomic_read(_priv->pm.atomic_seq) != begin_seq,
+   I915_WARN_RECUR(atomic_read(_priv->pm.atomic_seq) != begin_seq,
  "HW access outside of RPM atomic section\n");
 }
 
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915: Reorder i915_params struct.

[Joonas Lahtinen]

Move all the bool variables to the end as per the comment.

Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_params.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index a341525..a748ebc 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,6 +45,10 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+   int guc_log_level;
+   int use_mmio_flip;
+   int mmio_debug;
+   int edp_vswing;
/* leave bools at the end to not create holes */
bool enable_hangcheck;
bool fastboot;
@@ -54,12 +58,8 @@ struct i915_params {
bool disable_display;
bool disable_vtd_wa;
bool enable_guc_submission;
-   int guc_log_level;
-   int use_mmio_flip;
-   int mmio_debug;
bool verbose_state_checks;
bool nuclear_pageflip;
-   int edp_vswing;
 };
 
 extern struct i915_params i915 __read_mostly;
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/6] drm/i915: Decouple struct i915_params i915 into i915_params.h

[Joonas Lahtinen]

Otherwise usage in the i915 debug macros yields problems due to
i915_drv.h <-> i915_trace.h <-> intel_drv.h include loops.

Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h| 40 ++
 drivers/gpu/drm/i915/i915_params.c |  1 +
 drivers/gpu/drm/i915/i915_params.h | 68 ++
 3 files changed, 71 insertions(+), 38 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_params.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe3e76d..ae4b433 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include "i915_params.h"
 #include "i915_reg.h"
 #include "intel_bios.h"
 #include "intel_ringbuffer.h"
@@ -2658,44 +2659,7 @@ extern int i915_max_ioctl;
 extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state);
 extern int i915_resume_switcheroo(struct drm_device *dev);
 
-/* i915_params.c */
-struct i915_params {
-   int modeset;
-   int panel_ignore_lid;
-   int semaphores;
-   int lvds_channel_mode;
-   int panel_use_ssc;
-   int vbt_sdvo_panel_type;
-   int enable_rc6;
-   int enable_dc;
-   int enable_fbc;
-   int enable_ppgtt;
-   int enable_execlists;
-   int enable_psr;
-   unsigned int preliminary_hw_support;
-   int disable_power_well;
-   int enable_ips;
-   int invert_brightness;
-   int enable_cmd_parser;
-   /* leave bools at the end to not create holes */
-   bool enable_hangcheck;
-   bool fastboot;
-   bool prefault_disable;
-   bool load_detect_test;
-   bool reset;
-   bool disable_display;
-   bool disable_vtd_wa;
-   bool enable_guc_submission;
-   int guc_log_level;
-   int use_mmio_flip;
-   int mmio_debug;
-   bool verbose_state_checks;
-   bool nuclear_pageflip;
-   int edp_vswing;
-};
-extern struct i915_params i915 __read_mostly;
-
-   /* i915_dma.c */
+/* i915_dma.c */
 extern int i915_driver_load(struct drm_device *, unsigned long flags);
 extern int i915_driver_unload(struct drm_device *);
 extern int i915_driver_open(struct drm_device *dev, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 835d609..8d90c25 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -22,6 +22,7 @@
  * IN THE SOFTWARE.
  */
 
+#include "i915_params.h"
 #include "i915_drv.h"
 
 struct i915_params i915 __read_mostly = {
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
new file mode 100644
index 000..a341525
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef _I915_PARAMS_H_
+#define _I915_PARAMS_H_
+
+#include 
+
+struct i915_params {
+   int modeset;
+   int panel_ignore_lid;
+   int semaphores;
+   int lvds_channel_mode;
+   int panel_use_ssc;
+   int vbt_sdvo_panel_type;
+   int enable_rc6;
+   int enable_dc;
+   int enable_fbc;
+   int enable_ppgtt;
+   int enable_execlists;
+   int enable_psr;
+   unsigned int preliminary_hw_support;
+   int disable_power_well;
+   int enable_ips;
+   int invert_brightness;
+   int enable_cmd_parser;
+   /* leave bools at the end to not create holes */
+   bool enable_hangcheck;
+   bool fastboot;
+   bool prefault_disable;
+   bool load_detect_test;
+   bool reset;
+   bool disable_display;
+   bool disable_vtd_wa;
+   bool enable_guc_submission;
+   int guc_log_level;
+   int use_mmio_flip;
+   int mmio_debug;
+   bool 

[Intel-gfx] [PATCH 1/6] drm/i915: Compile time concatenate WARN_ON macro strings

[Joonas Lahtinen]

Using __stringify(x) instead of #x adds support for macros as
a parameter and reduces runtime overhead.

Slightly increases the .text size but should not matter.

Cc: Rob Clark 
Acked-by: Daniel Vetter 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1d28d90..fe3e76d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -69,11 +69,11 @@
BUILD_BUG_ON(__i915_warn_cond); \
WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
 #else
-#define WARN_ON(x) WARN((x), "WARN_ON(%s)", #x )
+#define WARN_ON(x) WARN((x), "WARN_ON(" __stringify(x) ")")
 #endif
 
 #undef WARN_ON_ONCE
-#define WARN_ON_ONCE(x) WARN_ONCE((x), "WARN_ON_ONCE(%s)", #x )
+#define WARN_ON_ONCE(x) WARN_ONCE((x), "WARN_ON_ONCE(" __stringify(x) ")")
 
 #define MISSING_CASE(x) WARN(1, "Missing switch case (%lu) in %s\n", \
 (long) (x), __func__);
@@ -97,12 +97,14 @@
 })
 
 #define I915_STATE_WARN_ON(condition) ({   \
+   static const char __warn_on_txt[] = \
+   "WARN_ON(" __stringify(condition) ")\n";\
int __ret_warn_on = !!(condition);  \
if (unlikely(__ret_warn_on)) {  \
if (i915.verbose_state_checks)  \
-   WARN(1, "WARN_ON(" #condition ")\n");   \
+   WARN(1, __warn_on_txt); \
else\
-   DRM_ERROR("WARN_ON(" #condition ")\n"); \
+   DRM_ERROR(__warn_on_txt);   \
}   \
unlikely(__ret_warn_on);\
 })
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915: Add helpers to reduce (repetitive) noise

[Joonas Lahtinen]

Add helpers to reduce the amount of noise. Use the i915.debug parameter
introduced in the previous patch to decide on whether to display all
debug messages or just ones that are meaningful to end user.

Take for example the CI environment, we want to see all possible warning
messages even though the system continues to operate. Opposite to that is
environment in daily use, repeating errors should be displayed once to
indicate the need for a bug report, but if the machine continues to work,
we should not spam the user continuously.

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 37fce5a..07240af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -110,6 +110,32 @@
unlikely(__ret_warn_on);\
 })
 
+#define I915_DEBUG(condition, format...) ({\
+   int __ret_debug_on = !!(condition); \
+   if (unlikely(__ret_debug_on))   \
+   WARN(unlikely(i915.debug), format); \
+   unlikely(__ret_debug_on);   \
+})
+
+#define I915_DEBUG_ON(condition) ({\
+   static const char __debug_on_txt[] =\
+   "I915_DEBUG_ON(" __stringify(condition) ")\n";  \
+   int __ret_debug_on = !!(condition); \
+   if (unlikely( __ret_debug_on))  \
+   WARN(unlikely(i915.debug), __debug_on_txt); \
+   unlikely(__ret_debug_on);   \
+})
+
+#define I915_WARN_RECUR(condition, format...) ({   \
+   static bool __section(.data.unlikely) __warned; \
+   int __ret_warn_on = !!(condition);  \
+   if (unlikely(__ret_warn_on)) {  \
+   if (WARN(unlikely(!__warned || i915.debug), format))\
+   __warned = true;\
+   }   \
+   unlikely(__ret_debug_on);   \
+})
+
 static inline const char *yesno(bool v)
 {
return v ? "yes" : "no";
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC][PATCH 0/6] Optionally display recurring warning messages

[Joonas Lahtinen]

Wakeref series introduced multiple WARN_ONCE clauses which might be
triggered from several sources (hangcheck or cache flusing for example),
this series adds an i915.debug option to make them always WARN which is
useful in the CI.

Had to reorder i915_params to get rid of circular include dependency.

Compile tested, comments welcome.

Joonas Lahtinen (6):
  drm/i915: Compile time concatenate WARN_ON macro strings
  drm/i915: Decouple struct i915_params i915 into i915_params.h
  drm/i915: Reorder i915_params struct.
  drm/i915: Add i915.debug parameter
  drm/i915: Add helpers to reduce (repetitive) noise
  drm/i915: Use I915_WARN_RECUR for recurring warning messages

 drivers/gpu/drm/i915/i915_drv.h| 75 +-
 drivers/gpu/drm/i915/i915_params.c |  7 
 drivers/gpu/drm/i915/i915_params.h | 69 +++
 drivers/gpu/drm/i915/intel_drv.h   |  6 +--
 4 files changed, 112 insertions(+), 45 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_params.h

-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/6] drm/i915: Disable plane gamma

[Lionel Landwerlin]

From: Shashank Sharma 

In plane enabling sequence, plane gamma bit is by default enabled.
Plane gamma gets higher priority than pipe gamma, if both enabled.

This patch disables plane gamma from sequence. If required, plane
gamma can be enabled via the color manager drm interface.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kumar, Kiran S 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_sprite.c  | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e04906d..a05ba28 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2829,7 +2829,7 @@ static void ironlake_update_primary_plane(struct drm_crtc 
*crtc,
 
pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
 
-   dspcntr = DISPPLANE_GAMMA_ENABLE;
+   dspcntr = (DISPPLANE_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);
 
dspcntr |= DISPLAY_PLANE_ENABLE;
 
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 4ff7a1f..337167f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -203,7 +203,8 @@ skl_update_plane(struct drm_plane *drm_plane, struct 
drm_crtc *crtc,
 
plane_ctl = PLANE_CTL_ENABLE |
PLANE_CTL_PIPE_GAMMA_ENABLE |
-   PLANE_CTL_PIPE_CSC_ENABLE;
+   PLANE_CTL_PIPE_CSC_ENABLE |
+   PLANE_CTL_PLANE_GAMMA_DISABLE;
 
plane_ctl |= skl_plane_ctl_format(fb->pixel_format);
plane_ctl |= skl_plane_ctl_tiling(fb->modifier[0]);
@@ -402,7 +403,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc 
*crtc,
 * Enable gamma to match primary/cursor plane behaviour.
 * FIXME should be user controllable via propertiesa.
 */
-   sprctl |= SP_GAMMA_ENABLE;
+   sprctl |= (SP_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);
 
if (obj->tiling_mode != I915_TILING_NONE)
sprctl |= SP_TILED;
@@ -521,7 +522,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
 * Enable gamma to match primary/cursor plane behaviour.
 * FIXME should be user controllable via propertiesa.
 */
-   sprctl |= SPRITE_GAMMA_ENABLE;
+   sprctl |= (SPRITE_GAMMA_ENABLE | PLANE_CTL_PLANE_GAMMA_DISABLE);
 
if (obj->tiling_mode != I915_TILING_NONE)
sprctl |= SPRITE_TILED;
-- 
2.6.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/6] drm/i915: Add set property interface for CRTC

[Lionel Landwerlin]

From: Shashank Sharma 

This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index abd2d29..e04906d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13610,6 +13610,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.page_flip = intel_crtc_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
+   .set_property = drm_atomic_helper_crtc_set_property,
 };
 
 static bool ibx_pch_dpll_get_hw_state(struct drm_i915_private *dev_priv,
-- 
2.6.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/6] drm/i915: Register color correction capabilities

[Lionel Landwerlin]

From: Shashank Sharma 

Register cm_coeff_after_ctm_property & cm_coeff_before_ctm_property
indicating the size of the LUT to be supplied to palette_after_ctm &
palette_before_ctm and also register the ctm property to enable color
correction matrix.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/intel_color_manager.c | 53 ++
 drivers/gpu/drm/i915/intel_display.c   |  1 +
 2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
index bca07c1..b50665b 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -801,4 +801,57 @@ void intel_color_manager_commit(struct drm_device *dev,
 
 void intel_crtc_attach_color_properties(struct drm_crtc *crtc)
 {
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = >mode_config;
+   struct drm_mode_object *mode_obj = >base;
+
+   /*
+   * Register:
+   * =
+   * Gamma correction as palette_after_ctm property
+   * Degamma correction as palette_before_ctm property
+   *
+   * Load:
+   * =
+   * no. of coefficients supported on this platform for gamma
+   * and degamma with the query properties. A user
+   * space agent should read these query property, and prepare
+   * the color correction values accordingly. Its expected from the
+   * driver to load the right number of coefficients during the init
+   * phase.
+   */
+   if (config->cm_coeff_after_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_after_ctm_property,
+   INTEL_INFO(dev)->num_samples_after_ctm);
+   DRM_DEBUG_DRIVER("Gamma query property initialized\n");
+   }
+
+   if (config->cm_coeff_before_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_coeff_before_ctm_property,
+   INTEL_INFO(dev)->num_samples_before_ctm);
+   DRM_DEBUG_DRIVER("Degamma query property initialized\n");
+   }
+
+   /* Gamma correction */
+   if (config->cm_palette_after_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_palette_after_ctm_property, 0);
+   DRM_DEBUG_DRIVER("gamma property attached to CRTC\n");
+   }
+
+   /* Degamma correction */
+   if (config->cm_palette_before_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_palette_before_ctm_property, 0);
+   DRM_DEBUG_DRIVER("degamma property attached to CRTC\n");
+   }
+
+   /* CSC */
+   if (config->cm_ctm_property) {
+   drm_object_attach_property(mode_obj,
+   config->cm_ctm_property, 0);
+   DRM_DEBUG_DRIVER("CSC property attached to CRTC\n");
+   }
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b9eb507..7cf56cb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14264,6 +14264,7 @@ static void intel_crtc_init(struct drm_device *dev, int 
pipe)
intel_crtc->cursor_size = ~0;
 
intel_crtc->wm.cxsr_allowed = true;
+   intel_crtc_attach_color_properties(_crtc->base);
 
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
   dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
-- 
2.6.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/6] drm/i915/bdw+: Implement color management

[Lionel Landwerlin]

From: Shashank Sharma 

Implement degamma, csc and gamma steps on BDW+.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c|  14 +
 drivers/gpu/drm/i915/i915_reg.h|  43 ++-
 drivers/gpu/drm/i915/intel_color_manager.c | 451 +
 drivers/gpu/drm/i915/intel_color_manager.h |  20 ++
 4 files changed, 525 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4396300..395e5ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -289,22 +289,30 @@ static const struct intel_device_info 
intel_haswell_m_info = {
 static const struct intel_device_info intel_broadwell_d_info = {
HSW_FEATURES,
.gen = 8,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
 };
 
 static const struct intel_device_info intel_broadwell_m_info = {
HSW_FEATURES,
.gen = 8, .is_mobile = 1,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
 };
 
 static const struct intel_device_info intel_broadwell_gt3d_info = {
HSW_FEATURES,
.gen = 8,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
 static const struct intel_device_info intel_broadwell_gt3m_info = {
HSW_FEATURES,
.gen = 8, .is_mobile = 1,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
@@ -324,12 +332,16 @@ static const struct intel_device_info intel_skylake_info 
= {
HSW_FEATURES,
.is_skylake = 1,
.gen = 9,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
HSW_FEATURES,
.is_skylake = 1,
.gen = 9,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
@@ -339,6 +351,8 @@ static const struct intel_device_info intel_broxton_info = {
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
+   .num_samples_after_ctm = BDW_SPLITGAMMA_MAX_VALS,
+   .num_samples_before_ctm = BDW_DEGAMMA_MAX_VALS,
.num_pipes = 3,
.has_ddi = 1,
.has_fpga_dbg = 1,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 36bb320..c4da842 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5748,11 +5748,19 @@ enum skl_disp_power_wells {
 /* legacy palette */
 #define _LGC_PALETTE_A   0x4a000
 #define _LGC_PALETTE_B   0x4a800
-#define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B) 
+ (i) * 4)
+#define _LGC_PALETTE_C   0x4b000
+#define LGC_PALETTE(pipe, i) _MMIO(_PIPE3(pipe, \
+ _LGC_PALETTE_A, \
+ _LGC_PALETTE_B, \
+ _LGC_PALETTE_C) + (i) * 4)
 
 #define _GAMMA_MODE_A  0x4a480
 #define _GAMMA_MODE_B  0x4ac80
-#define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
+#define _GAMMA_MODE_C  0x4b480
+#define GAMMA_MODE(pipe) _MMIO(_PIPE3(pipe, \
+ _GAMMA_MODE_A, \
+ _GAMMA_MODE_B, \
+ _GAMMA_MODE_C))
 #define GAMMA_MODE_MODE_MASK   (3 << 0)
 #define GAMMA_MODE_MODE_8BIT   (0 << 0)
 #define GAMMA_MODE_MODE_10BIT  (1 << 0)
@@ -8178,6 +8186,35 @@ enum skl_disp_power_wells {
 #define _PIPE_CSC_BASE(pipe) \
(_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
 
-
+/* BDW gamma correction */
+#define PAL_PREC_INDEX_A   0x4A400
+#define PAL_PREC_INDEX_B   0x4AC00
+#define PAL_PREC_INDEX_C   0x4B400
+#define PAL_PREC_DATA_A0x4A404
+#define PAL_PREC_DATA_B0x4AC04
+#define PAL_PREC_DATA_C0x4B404
+#define PAL_PREC_GC_MAX_A  0x4A410
+#define PAL_PREC_GC_MAX_B  0x4AC10
+#define PAL_PREC_GC_MAX_C  0x4B410
+#define PAL_PREC_EXT_GC_MAX_A  0x4A420
+#define PAL_PREC_EXT_GC_MAX_B  0x4AC20
+#define PAL_PREC_EXT_GC_MAX_C  0x4B420
+
+#define 

[Intel-gfx] [PATCH 4/6] drm/i915/chv: Implement color management

[Lionel Landwerlin]

From: Shashank Sharma 

Implement degamma, csc and gamma steps on CHV.

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.c|   5 +-
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_reg.h|  26 +++
 drivers/gpu/drm/i915/intel_color_manager.c | 353 +
 drivers/gpu/drm/i915/intel_color_manager.h |  91 
 drivers/gpu/drm/i915/intel_display.c   |   2 +
 drivers/gpu/drm/i915/intel_drv.h   |   4 +
 8 files changed, 484 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..c66d56a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -64,7 +64,8 @@ i915-y += intel_audio.o \
  intel_overlay.o \
  intel_psr.o \
  intel_sideband.o \
- intel_sprite.o
+ intel_sprite.o \
+ intel_color_manager.o
 i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
 i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3ac616d..4396300 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -34,6 +34,7 @@
 #include "i915_drv.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
+#include "intel_color_manager.h"
 
 #include 
 #include 
@@ -311,7 +312,9 @@ static const struct intel_device_info intel_cherryview_info 
= {
.gen = 8, .num_pipes = 3,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
-   .is_cherryview = 1,
+   .is_valleyview = 1,
+   .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
+   .num_samples_before_ctm = CHV_DEGAMMA_MAX_VALS,
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1d28d90..4eb0fab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -793,6 +793,8 @@ struct intel_device_info {
u8 num_sprites[I915_MAX_PIPES];
u8 gen;
u8 ring_mask; /* Rings supported by the HW */
+   u16 num_samples_after_ctm;
+   u16 num_samples_before_ctm;
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
/* Register offsets for the various display pipes and transcoders */
int pipe_offsets[I915_MAX_TRANSCODERS];
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 007ae83..36bb320 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8154,4 +8154,30 @@ enum skl_disp_power_wells {
 #define GEN9_VEBOX_MOCS(i) _MMIO(0xcb00 + (i) * 4) /* Video MOCS registers 
*/
 #define GEN9_BLT_MOCS(i)   _MMIO(0xcc00 + (i) * 4) /* Blitter MOCS 
registers */
 
+/* Color Management */
+#define PIPEA_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x67A00)
+#define PIPEB_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x69A00)
+#define PIPEC_CGM_CONTROL  (VLV_DISPLAY_BASE + 0x6BA00)
+#define PIPEA_CGM_GAMMA(VLV_DISPLAY_BASE + 0x67000)
+#define PIPEB_CGM_GAMMA(VLV_DISPLAY_BASE + 0x69000)
+#define PIPEC_CGM_GAMMA(VLV_DISPLAY_BASE + 0x6B000)
+#define _PIPE_CGM_CONTROL(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
+#define _PIPE_GAMMA_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
+
+#define PIPEA_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x66000)
+#define PIPEB_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x68000)
+#define PIPEC_CGM_DEGAMMA  (VLV_DISPLAY_BASE + 0x6A000)
+#define _PIPE_DEGAMMA_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
+
+#define PIPEA_CGM_CSC  (VLV_DISPLAY_BASE + 0x67900)
+#define PIPEB_CGM_CSC  (VLV_DISPLAY_BASE + 0x69900)
+#define PIPEC_CGM_CSC  (VLV_DISPLAY_BASE + 0x6B900)
+#define _PIPE_CSC_BASE(pipe) \
+   (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
+
+
+
 #endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..02eee98
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,353 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this 

Re: [Intel-gfx] [PATCH] [v2] drm/i915: Limit VF cache invalidate workaround usage to gen9

[Imre Deak]

On Thu, 2015-12-17 at 09:49 -0800, Ben Widawsky wrote:
> It is unclear if this is even required on BXT.

I'm not sure either, I only added it on the premise that it was marked
as SKL+ originally in BSpec. The revision log entry in BSpec has this
much to say:
"""
The workaround that requires an empty PIPE_CONTROL before a
PIPE_CONTROL with a VF Cache Invalidation Enable is only for SKL and
not SKL+. The bug was fixed in CNL with the following HSD:...
"""
Which doesn't make this clear either imo.

> v2: Make sure to set the default value to false. Uncertain how my compiler
> doesn't complain with v1.
> 
> Cc: Imre Deak 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 519cea32..af1e001 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1695,7 +1695,7 @@ static int gen8_emit_flush_render(struct 
> drm_i915_gem_request *request,
>   struct intel_ringbuffer *ringbuf = request->ringbuf;
>   struct intel_engine_cs *ring = ringbuf->ring;
>   u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES;
> - bool vf_flush_wa;
> + bool vf_flush_wa = false;
>   u32 flags = 0;
>   int ret;
>  
> @@ -1716,14 +1716,14 @@ static int gen8_emit_flush_render(struct 
> drm_i915_gem_request *request,
>   flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
>   flags |= PIPE_CONTROL_QW_WRITE;
>   flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
> - }
>  
> - /*
> -  * On GEN9+ Before VF_CACHE_INVALIDATE we need to emit a NULL pipe
> -  * control.
> -  */
> - vf_flush_wa = INTEL_INFO(ring->dev)->gen >= 9 &&
> -   flags & PIPE_CONTROL_VF_CACHE_INVALIDATE;
> + /*
> +  * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
> +  * pipe control.
> +  */
> +>if (IS_GEN9(ring->dev))

Nitpick: INTEL_INFO()->gen == 9 is the preferred way. Either way:
Reviewed-by: Imre Deak 

> + vf_flush_wa = true;
> + }
>  
>   ret = intel_logical_ring_begin(request, vf_flush_wa ? 12 : 6);
>   if (ret)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/6] drm: Create Color Management DRM properties

[Lionel Landwerlin]

From: Shashank Sharma 

Color Management is an extension to DRM framework to allow hardware color
correction and enhancement capabilities.

DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
   color transformation matrix of 9 correction values gets
   applied as correction.
2. "palette_before_ctm": for corrections which get applied
   beore color transformation matrix correction.
3. "palette_after_ctm": for corrections which get applied
   after color transformation matrix correction.

These color correction capabilities may differ per platform, supporting
various different no. of correction coefficients. So DRM color manager
support few properties using which a user space can query the platform's
capability, and prepare color correction accordingly.
These query properties are:
1. cm_coeff_after_ctm_property
2. cm_coeff_before_ctm_property
  (CTM is fix to 9 coefficients across industry)

Signed-off-by: Shashank Sharma 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/drm_atomic.c| 67 +++--
 drivers/gpu/drm/drm_atomic_helper.c |  9 +
 drivers/gpu/drm/drm_crtc.c  | 32 ++
 include/drm/drm_crtc.h  | 24 +
 include/uapi/drm/drm.h  | 30 +
 5 files changed, 160 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6a21e5c..ebdb98d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -388,6 +388,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
 EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
 
 /**
+ * drm_atomic_crtc_set_blob - find and set a blob
+ * @state_blob: reference pointer to the color blob in the crtc_state
+ * @blob_id: blob_id coming from set_property() call
+ *
+ * Set a color correction blob (originating from a set blob property) on the
+ * desired CRTC state. This function will take reference of the blob property
+ * in the CRTC state, finds the blob based on blob_id (which comes from
+ * set_property call) and set the blob at the proper place.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure.
+ */
+static int drm_atomic_crtc_set_blob(struct drm_device *dev,
+   struct drm_property_blob **state_blob, uint32_t blob_id)
+{
+   struct drm_property_blob *blob;
+
+   blob = drm_property_lookup_blob(dev, blob_id);
+   if (!blob) {
+   DRM_DEBUG_KMS("Invalid Blob ID\n");
+   return -EINVAL;
+   }
+
+   if (*state_blob)
+   drm_property_unreference_blob(*state_blob);
+
+   /* Attach the blob to be committed in state */
+   *state_blob = blob;
+   return 0;
+}
+
+/**
  * drm_atomic_crtc_set_property - set property on CRTC
  * @crtc: the drm CRTC to set a property on
  * @state: the state object to update with the new property value
@@ -419,8 +451,31 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
drm_property_unreference_blob(mode);
return ret;
-   }
-   else if (crtc->funcs->atomic_set_property)
+   } else if (property == config->cm_palette_after_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >palette_after_ctm_blob, val);
+   if (ret)
+   DRM_DEBUG_KMS("Failed to load blob 
palette_after_ctm\n");
+   else
+   state->color_correction_changed = true;
+   return ret;
+   } else if (property == config->cm_palette_before_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >palette_before_ctm_blob, val);
+   if (ret)
+   DRM_DEBUG_KMS("Failed to load blob 
palette_before_ctm\n");
+   else
+   state->color_correction_changed = true;
+   return ret;
+   } else if (property == config->cm_ctm_property) {
+   ret = drm_atomic_crtc_set_blob(dev,
+   >ctm_blob, val);
+   if (ret)
+   DRM_DEBUG_KMS("Failed to load blob ctm\n");
+   else
+   state->color_correction_changed = true;
+   return ret;
+   } else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
else
return -EINVAL;
@@ -456,6 +511,14 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->active;
else if (property == config->prop_mode_id)
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
+   else if (property == config->cm_palette_after_ctm_property)
+  

[Intel-gfx] [PATCH 0/6] Color Management for DRM framework v10

[Lionel Landwerlin]

Hi,

Here is an update on the color management serie by Shashank.
This one squashes things a bit to make it a bit easier to review.

This also includes a number of fixes,

for Braswell :

 - Read the right values from the degamma blob.

for Broadwell :

 - Always reset the lut index when writing the values for split mode,
otherwise writing the degamma lut twice will set the gamma lut on
   the second write.

Cheers,

-
Lionel

Shashank Sharma (6):
  drm: Create Color Management DRM properties
  drm/i915: Add set property interface for CRTC
  drm/i915: Disable plane gamma
  drm/i915/chv: Implement color management
  drm/i915/bdw+: Implement color management
  drm/i915: Register color correction capabilities

 drivers/gpu/drm/drm_atomic.c   |  67 ++-
 drivers/gpu/drm/drm_atomic_helper.c|   9 +
 drivers/gpu/drm/drm_crtc.c |  32 ++
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.c|  19 +-
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_reg.h|  67 ++-
 drivers/gpu/drm/i915/intel_color_manager.c | 857 +
 drivers/gpu/drm/i915/intel_color_manager.h | 111 
 drivers/gpu/drm/i915/intel_display.c   |   6 +-
 drivers/gpu/drm/i915/intel_drv.h   |   4 +
 drivers/gpu/drm/i915/intel_sprite.c|   7 +-
 include/drm/drm_crtc.h |  24 +
 include/uapi/drm/drm.h |  30 +
 14 files changed, 1228 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

--
2.6.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: mark the global default (intel_)context as such

[Dave Gordon]

On 17/12/15 12:27, Chris Wilson wrote:

On Thu, Dec 17, 2015 at 11:09:54AM +, Nick Hoath wrote:

On 16/12/2015 19:30, Chris Wilson wrote:

On Wed, Dec 16, 2015 at 07:22:52PM +, Dave Gordon wrote:

On 16/12/15 18:57, Chris Wilson wrote:

On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:

Some of the LRC-specific context-destruction code has to special-case
the global default context, because the HWSP is part of that context. At
present it deduces it indirectly by checking for the backpointer from
the engine to the context, but that's an unsafe assumption if the setup
and teardown code is reorganised. (It could also test !ctx->file_priv,
but again that's a detail that might be subject to change).

So here we explicitly flag the default context at the point of creation,
and then reorganise the code in intel_lr_context_free() not to rely on
the ring->default_pointer (still) being set up; to iterate over engines
in reverse (as this is teardown code); and to reduce the nesting level
so it's easier to read.

Signed-off-by: Dave Gordon 


#define intel_context_is_global(ctx) ((ctx)->file_priv == NULL)


Why not
#define intel_context_is_global(ctx)((ctx)->is_global) /* ! */


The last sentence of the first paragraph of the commit message above
notes that we *could* use that as a test, but I don't regard it as a
safe test, in either direction. That is, it could give a false
negative if we someday associate some (internal) fd with the default
context, or (more likely) a false positive if the file association
were broken and the pointer nulled in an earlier stage of the
teardown of a non-global (user-created) context.

int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
 struct drm_i915_gem_context_destroy *args = data;
 struct drm_i915_file_private *file_priv = file->driver_priv;
 struct intel_context *ctx;
 int ret;

 if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
 return -ENOENT;

 ret = i915_mutex_lock_interruptible(dev);
 if (ret)
 return ret;

 ctx = i915_gem_context_get(file_priv, args->ctx_id);
 if (IS_ERR(ctx)) {
 mutex_unlock(>struct_mutex);
 return PTR_ERR(ctx);
 }

 idr_remove(>file_priv->context_idr, ctx->user_handle);
 i915_gem_context_unreference(ctx);
 mutex_unlock(>struct_mutex);

 DRM_DEBUG_DRIVER("HW context %d destroyed\n", args->ctx_id);
 return 0;
}

At present, i915_gem_context_destroy_ioctl() above removes the
context from the file's list-of-contexts but DOESN'T clear the
ctx->file_priv, which means there's a somewhat inconsistent (but
transient) state during which a soon-to-be-destroyed context links
to a file, but the file doesn't have a link back. It probably
doesn't matter, because the code holds the mutex across the two
operations ...


And that the ctx was created to belong to the file still holds true.


... unless of course the context's refcount isn't 1 at this point,
in which case I suppose someone else *might* go from the context to
the file and then be mystified as to why the context isn't on the
list ...

... and if we changed the code above, then file_priv would *always*
be NULL by the time the destructor was called!

So it's surely safer to have a flag that explicitly says "I'm the
global default context" than to guess based on some other contingent
property.


No, we have a flag that says this context was created belonging to a
file, with the corollary that only one context doesn't belong to any
file.

Using pointers like this to provide 'magic' secondary state information
just adds to the fragility of the driver.


It's primary. Ownership information is fundamental to the driver.
The change is irrelevant to the bugfix.

If you want to make such a big change, eliminate the default_ctx from
execlists.
-Chris


No, we need the default (or global) context for idling the engines, as 
well as for sending initialisation commands during startup. We can't 
make the GPU stop using any given (user) context within a known bounded 
time except by telling it to switch to another context. Ergo, to stop 
using ANY user context, there must exist a non-user context that we can 
switch to.


And this is not a BIG change, it's a trivial change, to identify THE 
GLOBAL CONTEXT by means of *specific* information contained within that 
context, rather than by relying on information stored in a different 
structure.


Your suggested #define also does that much, but in a less obvious way 
that I consider lays a trap for a future maintainer who doesn't realise 
that the code relies on a subtle distinction between "a context created 
internally by the driver, without an owning fd" and "a context that has 
become detached from the fd that originally created it".


Eliminating such obscure and 

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Add GuC ADS - scheduler policies

[Chris Wilson]

On Thu, Dec 17, 2015 at 10:36:02AM -0800, Yu Dai wrote:
> On 12/16/2015 11:39 PM, Chris Wilson wrote:
> >On Wed, Dec 16, 2015 at 01:40:53PM -0800, yu@intel.com wrote:
> >> From: Alex Dai 
> >> @@ -884,6 +906,13 @@ static void guc_create_ads(struct intel_guc *guc)
> >>for_each_ring(ring, dev_priv, i)
> >>ads->eng_state_size[i] = intel_lr_context_size(ring);
> >>
> >> +  /* GuC scheduling policies */
> >> +  policies = (void *)ads + sizeof(struct guc_ads);
> >> +  init_guc_policies(policies);
> >
> >Please limit atomic context to only the critical section, i.e. don't
> >make me have to read every single function to check for violations.
> 
> Could you clarify this? I am not sure what's the atomic context and
> critical section you mentioned here.

This is inside an kmap_atomic()/kunmap_atomic() section. That means this
code is in atomic context and cannot sleep or be preempted i.e. there
are restrictions placed on what the code can do and what it can call.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add i915.debug parameter

[Chris Wilson]

On Thu, Dec 17, 2015 at 09:25:49PM +0200, Joonas Lahtinen wrote:
> Add i915.debug parameter to control output in cases where the debug output
> amount will be massive and as such is unsuitable for everyday use, but still
> significant in value when solving bugs.
> 
> Cc: Chris Wilson 
> Signed-off-by: Joonas Lahtinen 

Maybe i915.verbose_checks ?

Too similar to i915.verbose_state_checks though?

Just trying to differentiate from drm.debug which we will also be
settings.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/6] drm: Create Color Management DRM properties

[kbuild test robot]

Hi Shashank,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20151217]
[cannot apply to v4.4-rc5]

url:
https://github.com/0day-ci/linux/commits/Lionel-Landwerlin/Color-Management-for-DRM-framework-v10/20151218-025917
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_irq.c:2647: warning: No description found for 
parameter 'wedged'
   drivers/gpu/drm/i915/i915_irq.c:2647: warning: No description found for 
parameter 'fmt'
>> drivers/gpu/drm/drm_atomic.c:405: warning: No description found for 
>> parameter 'dev'
   include/drm/drm_crtc.h:324: warning: No description found for parameter 
'mode_blob'
   include/drm/drm_crtc.h:751: warning: No description found for parameter 
'tile_blob_ptr'
   include/drm/drm_crtc.h:790: warning: No description found for parameter 
'rotation'
   include/drm/drm_crtc.h:886: warning: No description found for parameter 
'mutex'
   include/drm/drm_crtc.h:886: warning: No description found for parameter 
'helper_private'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tile_idr'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'delayed_event'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'edid_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'dpms_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'path_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tile_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'plane_type_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'rotation_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_src_x'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_src_y'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_src_w'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_src_h'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_crtc_x'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_crtc_y'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_crtc_w'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_crtc_h'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_fb_id'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_crtc_id'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_active'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'prop_mode_id'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'dvi_i_subconnector_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'dvi_i_select_subconnector_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_subconnector_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_select_subconnector_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_mode_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_left_margin_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_right_margin_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_top_margin_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_bottom_margin_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_brightness_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_contrast_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_flicker_reduction_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_overscan_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_saturation_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'tv_hue_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'scaling_mode_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'aspect_ratio_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'dirty_info_property'
   include/drm/drm_crtc.h:1185: warning: No description found for parameter 
'suggested_x_property'
   include/drm/drm_crtc.h:1185: warning: No description f

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Add helpers to reduce (repetitive) noise

[Chris Wilson]

On Thu, Dec 17, 2015 at 09:25:50PM +0200, Joonas Lahtinen wrote:
> Add helpers to reduce the amount of noise. Use the i915.debug parameter
> introduced in the previous patch to decide on whether to display all
> debug messages or just ones that are meaningful to end user.
> 
> Take for example the CI environment, we want to see all possible warning
> messages even though the system continues to operate. Opposite to that is
> environment in daily use, repeating errors should be displayed once to
> indicate the need for a bug report, but if the machine continues to work,
> we should not spam the user continuously.

One thing, if we have a helper that we think will be generally useful
(outside of our module), we have taken the liberty in the past in giving
it a non-specific name, e.g. WARN_RECUR();

That would mean we would use WARN_RECUR(cond, i915.debug, "foo has barred\n"))
instead.

The theory being is that if it is useful we can then lift it to the
core.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] [v2] drm/i915: Limit VF cache invalidate workaround usage to gen9

[Ben Widawsky]

On Thu, Dec 17, 2015 at 10:49:24PM +0200, Imre Deak wrote:
> On Thu, 2015-12-17 at 09:49 -0800, Ben Widawsky wrote:
> > It is unclear if this is even required on BXT.
> 
> I'm not sure either, I only added it on the premise that it was marked
> as SKL+ originally in BSpec. The revision log entry in BSpec has this
> much to say:
> """
> The workaround that requires an empty PIPE_CONTROL before a
> PIPE_CONTROL with a VF Cache Invalidation Enable is only for SKL and
> not SKL+. The bug was fixed in CNL with the following HSD:...
> """
> Which doesn't make this clear either imo.
> 
> > v2: Make sure to set the default value to false. Uncertain how my compiler
> > doesn't complain with v1.
> > 
> > Cc: Imre Deak 
> > Signed-off-by: Ben Widawsky 
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 519cea32..af1e001 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1695,7 +1695,7 @@ static int gen8_emit_flush_render(struct 
> > drm_i915_gem_request *request,
> >     struct intel_ringbuffer *ringbuf = request->ringbuf;
> >     struct intel_engine_cs *ring = ringbuf->ring;
> >     u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES;
> > -   bool vf_flush_wa;
> > +   bool vf_flush_wa = false;
> >     u32 flags = 0;
> >     int ret;
> >  
> > @@ -1716,14 +1716,14 @@ static int gen8_emit_flush_render(struct 
> > drm_i915_gem_request *request,
> >     flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
> >     flags |= PIPE_CONTROL_QW_WRITE;
> >     flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
> > -   }
> >  
> > -   /*
> > -    * On GEN9+ Before VF_CACHE_INVALIDATE we need to emit a NULL pipe
> > -    * control.
> > -    */
> > -   vf_flush_wa = INTEL_INFO(ring->dev)->gen >= 9 &&
> > -     flags & PIPE_CONTROL_VF_CACHE_INVALIDATE;
> > +   /*
> > +    * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
> > +    * pipe control.
> > +    */
> > +>  if (IS_GEN9(ring->dev))
> 
> Nitpick: INTEL_INFO()->gen == 9 is the preferred way. Either way:
> Reviewed-by: Imre Deak 
> 

Sounds good to me. Does someone mind fixing this up when they push? This patch
is a pre-requisite to another internal patch I have at the moment.

> > +   vf_flush_wa = true;
> > +   }
> >  
> >     ret = intel_logical_ring_begin(request, vf_flush_wa ? 12 : 6);
> >     if (ret)

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Reorder i915_params struct.

[Chris Wilson]

On Thu, Dec 17, 2015 at 09:25:48PM +0200, Joonas Lahtinen wrote:
> Move all the bool variables to the end as per the comment.
> 
> Signed-off-by: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Decouple struct i915_params i915 into i915_params.h

[Chris Wilson]

On Thu, Dec 17, 2015 at 09:25:47PM +0200, Joonas Lahtinen wrote:
> +#ifndef _I915_PARAMS_H_
> +#define _I915_PARAMS_H_
> +
Is it worth saying

#include  /* for __read_mostly */

or am I alone in not knowing that?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.

[abhay . kumar]

From: Abhay Kumar 

Make resume codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.

Change-Id: Ied0f10f82776af8e6e8ff561bb4e5c0ce1dad4b3
Signed-off-by: Abhay Kumar 
---
 drivers/gpu/drm/i915/intel_ddi.c |  3 +++
 drivers/gpu/drm/i915/intel_dp.c  | 21 +
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 3 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cbabcb4..fe99d72 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2347,6 +2347,9 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
+
+   /* storing panel power off time */
+   intel_dp->panel_power_off_time = 
ktime_get_with_offset(TK_OFFS_BOOT);
}
 
if (IS_SKYLAKE(dev))
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index acda70e..509da67 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -38,7 +38,6 @@
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
-
 #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)
 
 /* Compliance test status bits  */
@@ -1654,13 +1653,21 @@ static void wait_panel_off(struct intel_dp *intel_dp)
 
 static void wait_panel_power_cycle(struct intel_dp *intel_dp)
 {
+   ktime_t panel_power_on_time;
+   u32 panel_power_off_duration;
+
DRM_DEBUG_KMS("Wait for panel power cycle\n");
 
-   /* When we disable the VDD override bit last we have to do the manual
-* wait. */
-   wait_remaining_ms_from_jiffies(intel_dp->last_power_cycle,
-  intel_dp->panel_power_cycle_delay);
+/* take the diffrence of currrent time and panel power off time
+   and then make panel wait for t11_t12 if needed */
+panel_power_on_time = ktime_get_with_offset(TK_OFFS_BOOT);
+panel_power_off_duration = (panel_power_on_time.tv64 - 
intel_dp->panel_power_off_time.tv64) / 100;
 
+   /* When we disable the VDD override bit last we have to do the manual
+* wait */
+   if (panel_power_off_duration < intel_dp->panel_power_cycle_delay)
+   wait_remaining_ms_from_jiffies(jiffies,
+  (intel_dp->panel_power_cycle_delay - 
panel_power_off_duration));
wait_panel_status(intel_dp, IDLE_CYCLE_MASK, IDLE_CYCLE_VALUE);
 }
 
@@ -1811,7 +1818,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
 
if ((pp & POWER_TARGET_ON) == 0)
-   intel_dp->last_power_cycle = jiffies;
+   intel_dp->panel_power_off_time = 
ktime_get_with_offset(TK_OFFS_BOOT);
 
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_put(dev_priv, power_domain);
@@ -1960,7 +1967,6 @@ static void edp_panel_off(struct intel_dp *intel_dp)
I915_WRITE(pp_ctrl_reg, pp);
POSTING_READ(pp_ctrl_reg);
 
-   intel_dp->last_power_cycle = jiffies;
wait_panel_off(intel_dp);
 
/* We got a reference when we enabled the VDD. */
@@ -5196,7 +5202,6 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct 
drm_connector *connect
 
 static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
 {
-   intel_dp->last_power_cycle = jiffies;
intel_dp->last_power_on = jiffies;
intel_dp->last_backlight_off = jiffies;
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d44f2f5..ef82e8f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -722,9 +722,9 @@ struct intel_dp {
int backlight_off_delay;
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
-   unsigned long last_power_cycle;
unsigned long last_power_on;
unsigned long last_backlight_off;
+   ktime_t panel_power_off_time;
 
struct notifier_block edp_notifier;
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.

[kbuild test robot]

Hi Abhay,

[auto build test ERROR on v4.4-rc3]
[also build test ERROR on next-20151217]
[cannot apply to drm-intel/for-linux-next v4.4-rc5 v4.4-rc4]

url:
https://github.com/0day-ci/linux/commits/abhay-kumar-intel-com/drm-i915-edp-resume-On-time-optimization/20151218-143043
config: i386-randconfig-i0-201550 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `wait_panel_power_cycle':
>> intel_dp.c:(.text+0x306552): undefined reference to `__divdi3'
   intel_dp.c:(.text+0x3065b9): undefined reference to `__divdi3'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ warning: Fi.CI.BAT

[Patchwork]

== Summary ==

Built on ac2305b6c91b9a84cc12566016ece257c3ebcba3 drm-intel-nightly: 
2015y-12m-17d-16h-19m-23s UTC integration manifest

Test igt@kms_flip@basic-flip-vs-wf_vblank on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-wf_vblank on skl-i7k-2 dmesg-fail -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence on bsw-nuc-2 
dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-b on snb-dellxps dmesg-warn -> pass
Test igt@kms_setmode@basic-clone-single-crtc on snb-dellxps pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-modeset on hsw-brixbox pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-modeset on bsw-nuc-2 dmesg-warn -> pass

bsw-nuc-2total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
hsw-brixbox  total:135  pass:126  dwarn:2   dfail:0   fail:0   skip:7  
hsw-gt2  total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p  total:135  pass:100  dwarn:0   dfail:0   fail:2   skip:33 
ivb-t430stotal:135  pass:128  dwarn:1   dfail:1   fail:1   skip:4  
skl-i5k-2total:135  pass:122  dwarn:5   dfail:0   fail:0   skip:8  
skl-i7k-2total:135  pass:122  dwarn:5   dfail:0   fail:0   skip:8  
snb-dellxps  total:135  pass:121  dwarn:2   dfail:0   fail:0   skip:12 
snb-x220ttotal:135  pass:121  dwarn:2   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_707/

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ warning: Fi.CI.BAT

[Patchwork]

== Summary ==

Built on ac2305b6c91b9a84cc12566016ece257c3ebcba3 drm-intel-nightly: 
2015y-12m-17d-16h-19m-23s UTC integration manifest

Test igt@kms_flip@basic-flip-vs-wf_vblank on snb-x220t dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-wf_vblank on bsw-nuc-2 pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-wf_vblank on skl-i7k-2 dmesg-fail -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c-frame-sequence on bsw-nuc-2 
dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@hang-read-crc-pipe-a on snb-x220t pass -> dmesg-warn
Test igt@kms_flip@basic-flip-vs-dpms on ilk-hp8440p pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b on snb-x220t dmesg-warn -> 
pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-a on snb-x220t pass -> dmesg-warn
Test igt@kms_pipe_crc_basic@read-crc-pipe-c on skl-i7k-2 dmesg-warn -> pass
Test igt@kms_pipe_crc_basic@read-crc-pipe-b on snb-dellxps dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-modeset on bsw-nuc-2 dmesg-warn -> pass
Test igt@kms_flip@basic-flip-vs-modeset on skl-i5k-2 dmesg-warn -> pass

bsw-nuc-2total:135  pass:114  dwarn:1   dfail:0   fail:0   skip:20 
hsw-brixbox  total:135  pass:127  dwarn:1   dfail:0   fail:0   skip:7  
hsw-gt2  total:135  pass:130  dwarn:1   dfail:0   fail:0   skip:4  
ilk-hp8440p  total:135  pass:99   dwarn:1   dfail:0   fail:2   skip:33 
ivb-t430stotal:135  pass:128  dwarn:1   dfail:1   fail:1   skip:4  
skl-i5k-2total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
skl-i7k-2total:135  pass:123  dwarn:4   dfail:0   fail:0   skip:8  
snb-dellxps  total:135  pass:122  dwarn:1   dfail:0   fail:0   skip:12 
snb-x220ttotal:135  pass:121  dwarn:2   dfail:0   fail:1   skip:11 

Results at /archive/results/CI_IGT_test/Patchwork_706/

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/11] drm/i915: i915_vma_move_to_active prep patch

[Tvrtko Ursulin]

On 14/12/15 11:36, Chris Wilson wrote:

This patch is broken out of the next just to remove the code motion from
that patch and make it more readable. What we do here is move the
i915_vma_move_to_active() to i915_gem_execbuffer.c and put the three
stages (read, write, fenced) together so that future modifications to
active handling are all located in the same spot. The importance of this
is so that we can more simply control the order in which the requests
are place in the retirement list (i.e. control the order at which we
retire and so control the lifetimes to avoid having to hold onto
references).

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h  |  3 +-
  drivers/gpu/drm/i915/i915_gem.c  | 15 ---
  drivers/gpu/drm/i915/i915_gem_context.c  |  7 ++--
  drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 63 ++--
  drivers/gpu/drm/i915/i915_gem_render_state.c |  2 +-
  5 files changed, 49 insertions(+), 41 deletions(-)


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko



diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b32a00f60e98..eb775eb1c693 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2775,7 +2775,8 @@ int __must_check i915_mutex_lock_interruptible(struct 
drm_device *dev);
  int i915_gem_object_sync(struct drm_i915_gem_object *obj,
 struct drm_i915_gem_request *to);
  void i915_vma_move_to_active(struct i915_vma *vma,
-struct drm_i915_gem_request *req);
+struct drm_i915_gem_request *req,
+unsigned flags);
  int i915_gem_dumb_create(struct drm_file *file_priv,
 struct drm_device *dev,
 struct drm_mode_create_dumb *args);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 144e92df8137..8a824c5d5348 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2016,21 +2016,6 @@ void *i915_gem_object_pin_vmap(struct 
drm_i915_gem_object *obj)
return obj->vmapping;
  }

-void i915_vma_move_to_active(struct i915_vma *vma,
-struct drm_i915_gem_request *req)
-{
-   struct drm_i915_gem_object *obj = vma->obj;
-   struct intel_engine_cs *engine = req->engine;
-
-   /* Add a reference if we're newly entering the active list. */
-   if (obj->active == 0)
-   drm_gem_object_reference(>base);
-   obj->active |= intel_engine_flag(engine);
-
-   i915_gem_request_mark_active(req, >last_read[engine->id]);
-   list_move_tail(>vm_link, >vm->active_list);
-}
-
  static void
  i915_gem_object_retire__fence(struct drm_i915_gem_request_active *active,
  struct drm_i915_gem_request *req)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index dcb4603a7f03..c4a8a64cd1b2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -766,8 +766,8 @@ static int do_switch(struct drm_i915_gem_request *req)
 * MI_SET_CONTEXT instead of when the next seqno has completed.
 */
if (from != NULL) {
-   from->legacy_hw_ctx.rcs_state->base.read_domains = 
I915_GEM_DOMAIN_INSTRUCTION;
-   
i915_vma_move_to_active(i915_gem_obj_to_ggtt(from->legacy_hw_ctx.rcs_state), 
req);
+   struct drm_i915_gem_object *obj = from->legacy_hw_ctx.rcs_state;
+
/* As long as MI_SET_CONTEXT is serializing, ie. it flushes the
 * whole damn pipeline, we don't need to explicitly mark the
 * object dirty. The only exception is that the context must be
@@ -775,7 +775,8 @@ static int do_switch(struct drm_i915_gem_request *req)
 * able to defer doing this until we know the object would be
 * swapped, but there is no way to do that yet.
 */
-   from->legacy_hw_ctx.rcs_state->dirty = 1;
+   obj->base.read_domains = I915_GEM_DOMAIN_INSTRUCTION;
+   i915_vma_move_to_active(i915_gem_obj_to_ggtt(obj), req, 0);

/* obj is kept alive until the next request by its active ref */
i915_gem_object_ggtt_unpin(from->legacy_hw_ctx.rcs_state);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6788f71ad989..6de8681bb64c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1064,6 +1064,44 @@ i915_gem_validate_context(struct drm_device *dev, struct 
drm_file *file,
return ctx;
  }

+void i915_vma_move_to_active(struct i915_vma *vma,
+struct drm_i915_gem_request *req,
+unsigned flags)
+{
+   

Re: [Intel-gfx] [PATCH 08/11] drm/i915: Track active vma requests

[Tvrtko Ursulin]

Hi,

On 14/12/15 11:36, Chris Wilson wrote:

Hook the vma itself into the i915_gem_request_retire() so that we can
accurately track when a solitary vma is inactive (as opposed to having


s/solitary/individual/ ?


to wait for the entire object to be idle). This improves the interaction
when using multiple contexts (with full-ppgtt) and eliminates some
frequent list walking.


What list walking are you referring to? Maybe clarify in the commit message.

Anyway, looks surprisingly simple. Almost suspiciously simple, but I 
can't fault it:


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko



A side-effect is that we get an active vma reference for free. The
consequence of this is shown in the next patch...

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
  drivers/gpu/drm/i915/i915_gem.c| 36 --
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 ++
  drivers/gpu/drm/i915/i915_gem_gtt.c| 20 +
  drivers/gpu/drm/i915/i915_gem_gtt.h|  5 +
  5 files changed, 47 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 179e3c5c5022..4df4ebbd56d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -356,7 +356,7 @@ static int per_file_stats(int id, void *ptr, void *data)
continue;
}

-   if (obj->active) /* XXX per-vma statistic */
+   if (vma->active)
stats->active += vma->node.size;
else
stats->inactive += vma->node.size;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8a824c5d5348..1d21c5b79215 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2040,7 +2040,6 @@ i915_gem_object_retire__read(struct 
drm_i915_gem_request_active *active,
int ring = request->engine->id;
struct drm_i915_gem_object *obj =
container_of(active, struct drm_i915_gem_object, 
last_read[ring]);
-   struct i915_vma *vma;

RQ_BUG_ON((obj->flags & (1 << (ring + I915_BO_ACTIVE_SHIFT))) == 0);

@@ -2052,12 +2051,9 @@ i915_gem_object_retire__read(struct 
drm_i915_gem_request_active *active,
 * so that we don't steal from recently used but inactive objects
 * (unless we are forced to ofc!)
 */
-   list_move_tail(>global_list, >i915->mm.bound_list);
-
-   list_for_each_entry(vma, >vma_list, obj_link) {
-   if (!list_empty(>vm_link))
-   list_move_tail(>vm_link, >vm->inactive_list);
-   }
+   if (!list_empty(>vma_list))
+   list_move_tail(>global_list,
+  >i915->mm.bound_list);

drm_gem_object_unreference(>base);
  }
@@ -2567,7 +2563,19 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)
  {
struct drm_i915_gem_object *obj = vma->obj;
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
-   int ret;
+   int ret, i;
+
+   /* First wait upon any activity as retiring the request may
+* have side-effects such as unpinning or even unbinding this vma.
+*/
+   if (vma->active && wait) {
+   for (i = 0; i < ARRAY_SIZE(vma->last_read); i++) {
+   ret = i915_wait_request(vma->last_read[i].request);
+   if (ret)
+   return ret;
+   }
+   RQ_BUG_ON(vma->active);
+   }

if (list_empty(>obj_link))
return 0;
@@ -2582,12 +2590,6 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool 
wait)

BUG_ON(obj->pages == NULL);

-   if (wait) {
-   ret = i915_gem_object_wait_rendering(obj, false);
-   if (ret)
-   return ret;
-   }
-
if (vma->is_ggtt && vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
i915_gem_object_finish_gtt(obj);

@@ -3023,9 +3025,8 @@ i915_gem_object_set_to_gtt_domain(struct 
drm_i915_gem_object *obj, bool write)

/* And bump the LRU for this access */
vma = i915_gem_obj_to_ggtt(obj);
-   if (vma && drm_mm_node_allocated(>node) && !obj->active)
-   list_move_tail(>vm_link,
-  _i915(obj->base.dev)->gtt.base.inactive_list);
+   if (vma && drm_mm_node_allocated(>node) && !vma->active)
+   list_move_tail(>vm_link, >vm->inactive_list);

return 0;
  }
@@ -3874,6 +3875,7 @@ struct i915_vma *i915_gem_obj_to_ggtt_view(struct 
drm_i915_gem_object *obj,
  void i915_gem_vma_destroy(struct i915_vma *vma)
  {
WARN_ON(vma->node.allocated);
+   RQ_BUG_ON(vma->active);

/* Keep the vma as a placeholder in the execbuffer reservation lists */
  

Re: [Intel-gfx] [PATCH 2/4] drm/i915: mark the global default (intel_)context as such

[Chris Wilson]

On Thu, Dec 17, 2015 at 11:09:54AM +, Nick Hoath wrote:
> On 16/12/2015 19:30, Chris Wilson wrote:
> >On Wed, Dec 16, 2015 at 07:22:52PM +, Dave Gordon wrote:
> >>On 16/12/15 18:57, Chris Wilson wrote:
> >>>On Wed, Dec 16, 2015 at 06:36:49PM +, Dave Gordon wrote:
> Some of the LRC-specific context-destruction code has to special-case
> the global default context, because the HWSP is part of that context. At
> present it deduces it indirectly by checking for the backpointer from
> the engine to the context, but that's an unsafe assumption if the setup
> and teardown code is reorganised. (It could also test !ctx->file_priv,
> but again that's a detail that might be subject to change).
> 
> So here we explicitly flag the default context at the point of creation,
> and then reorganise the code in intel_lr_context_free() not to rely on
> the ring->default_pointer (still) being set up; to iterate over engines
> in reverse (as this is teardown code); and to reduce the nesting level
> so it's easier to read.
> 
> Signed-off-by: Dave Gordon 
> >>>
> >>>#define intel_context_is_global(ctx) ((ctx)->file_priv == NULL)
> >>
> >>The last sentence of the first paragraph of the commit message above
> >>notes that we *could* use that as a test, but I don't regard it as a
> >>safe test, in either direction. That is, it could give a false
> >>negative if we someday associate some (internal) fd with the default
> >>context, or (more likely) a false positive if the file association
> >>were broken and the pointer nulled in an earlier stage of the
> >>teardown of a non-global (user-created) context.
> >>
> >>int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
> >>struct drm_file *file)
> >>{
> >> struct drm_i915_gem_context_destroy *args = data;
> >> struct drm_i915_file_private *file_priv = file->driver_priv;
> >> struct intel_context *ctx;
> >> int ret;
> >>
> >> if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
> >> return -ENOENT;
> >>
> >> ret = i915_mutex_lock_interruptible(dev);
> >> if (ret)
> >> return ret;
> >>
> >> ctx = i915_gem_context_get(file_priv, args->ctx_id);
> >> if (IS_ERR(ctx)) {
> >> mutex_unlock(>struct_mutex);
> >> return PTR_ERR(ctx);
> >> }
> >>
> >> idr_remove(>file_priv->context_idr, ctx->user_handle);
> >> i915_gem_context_unreference(ctx);
> >> mutex_unlock(>struct_mutex);
> >>
> >> DRM_DEBUG_DRIVER("HW context %d destroyed\n", args->ctx_id);
> >> return 0;
> >>}
> >>
> >>At present, i915_gem_context_destroy_ioctl() above removes the
> >>context from the file's list-of-contexts but DOESN'T clear the
> >>ctx->file_priv, which means there's a somewhat inconsistent (but
> >>transient) state during which a soon-to-be-destroyed context links
> >>to a file, but the file doesn't have a link back. It probably
> >>doesn't matter, because the code holds the mutex across the two
> >>operations ...
> >
> >And that the ctx was created to belong to the file still holds true.
> >
> >>... unless of course the context's refcount isn't 1 at this point,
> >>in which case I suppose someone else *might* go from the context to
> >>the file and then be mystified as to why the context isn't on the
> >>list ...
> >>
> >>... and if we changed the code above, then file_priv would *always*
> >>be NULL by the time the destructor was called!
> >>
> >>So it's surely safer to have a flag that explicitly says "I'm the
> >>global default context" than to guess based on some other contingent
> >>property.
> >
> >No, we have a flag that says this context was created belonging to a
> >file, with the corollary that only one context doesn't belong to any
> >file.
> Using pointers like this to provide 'magic' secondary state information
> just adds to the fragility of the driver.

It's primary. Ownership information is fundamental to the driver.
The change is irrelevant to the bugfix.

If you want to make such a big change, eliminate the default_ctx from
execlists.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/6] Color Management for DRM framework v10

[Sharma, Shashank]

Hi Lionel, Rob

NACK. 
We never agreed to squash the patches. 
The patches should be as it is, in sequence.

Regards
Shashank
-Original Message-
From: Landwerlin, Lionel G 
Sent: Friday, December 18, 2015 12:28 AM
To: intel-gfx@lists.freedesktop.org
Cc: Sharma, Shashank; Landwerlin, Lionel G
Subject: [PATCH 0/6] Color Management for DRM framework v10

Hi,

Here is an update on the color management serie by Shashank.
This one squashes things a bit to make it a bit easier to review.

This also includes a number of fixes,

for Braswell :

 - Read the right values from the degamma blob.

for Broadwell :

 - Always reset the lut index when writing the values for split mode,
otherwise writing the degamma lut twice will set the gamma lut on
   the second write.

Cheers,

-
Lionel

Shashank Sharma (6):
  drm: Create Color Management DRM properties
  drm/i915: Add set property interface for CRTC
  drm/i915: Disable plane gamma
  drm/i915/chv: Implement color management
  drm/i915/bdw+: Implement color management
  drm/i915: Register color correction capabilities

 drivers/gpu/drm/drm_atomic.c   |  67 ++-
 drivers/gpu/drm/drm_atomic_helper.c|   9 +
 drivers/gpu/drm/drm_crtc.c |  32 ++
 drivers/gpu/drm/i915/Makefile  |   3 +-
 drivers/gpu/drm/i915/i915_drv.c|  19 +-
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_reg.h|  67 ++-
 drivers/gpu/drm/i915/intel_color_manager.c | 857 + 
 drivers/gpu/drm/i915/intel_color_manager.h | 111 
 drivers/gpu/drm/i915/intel_display.c   |   6 +-
 drivers/gpu/drm/i915/intel_drv.h   |   4 +
 drivers/gpu/drm/i915/intel_sprite.c|   7 +-
 include/drm/drm_crtc.h |  24 +
 include/uapi/drm/drm.h |  30 +
 14 files changed, 1228 insertions(+), 10 deletions(-)  create mode 100644 
drivers/gpu/drm/i915/intel_color_manager.c
 create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h

--
2.6.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/9] drm/i915: Add support for stealing purgable stolen pages

[Tvrtko Ursulin]

On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:

From: Chris Wilson 

If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - and you will be forgiven for thinking that the code looks
very similar.

At the moment, we do not allow userspace to allocate objects in stolen,
so there is neither the memory pressure to trigger stolen eviction nor
any purgeable objects inside the stolen arena. However, this will change
in the near future, and so better management and defragmentation of
stolen memory will become a real issue.

v2: Remember to remove the drm_mm_node.

v3: Rebased to the latest drm-intel-nightly (Ankit)

v4: corrected if-else braces format (Tvrtko/kerneldoc)

v5: Rebased to the latest drm-intel-nightly (Ankit)
Added a seperate list to maintain purgable objects from stolen memory
region (Chris/Daniel)

v6: Compiler optimization (merging 2 single loops into one for() loop),
corrected code for object eviction, retire_requests before starting
object eviction (Chris)

v7: Added kernel doc for i915_gem_object_create_stolen()

v8: Check for struct_mutex lock before creating object from stolen
region (Tvrtko)

v9: Renamed variables to make usage clear, added comment, removed onetime
used macro (Tvrtko)

v10: Avoid masking of error when stolen_alloc fails (Tvrtko)

Testcase: igt/gem_stolen

Signed-off-by: Chris Wilson 
Signed-off-by: Ankitprasad Sharma 
---
  drivers/gpu/drm/i915/i915_debugfs.c|   6 +-
  drivers/gpu/drm/i915/i915_drv.h|  17 +++-
  drivers/gpu/drm/i915/i915_gem.c|  16 
  drivers/gpu/drm/i915/i915_gem_stolen.c | 170 +
  drivers/gpu/drm/i915/intel_pm.c|   4 +-
  5 files changed, 188 insertions(+), 25 deletions(-)



Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko



diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a8721fc..f0aa3d4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -174,7 +174,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
seq_puts(m, ")");
}
if (obj->stolen)
-   seq_printf(m, " (stolen: %08llx)", obj->stolen->start);
+   seq_printf(m, " (stolen: %08llx)", obj->stolen->base.start);
if (obj->pin_display || obj->fault_mappable) {
char s[3], *t = s;
if (obj->pin_display)
@@ -253,9 +253,9 @@ static int obj_rank_by_stolen(void *priv,
struct drm_i915_gem_object *b =
container_of(B, struct drm_i915_gem_object, obj_exec_link);

-   if (a->stolen->start < b->stolen->start)
+   if (a->stolen->base.start < b->stolen->base.start)
return -1;
-   if (a->stolen->start > b->stolen->start)
+   if (a->stolen->base.start > b->stolen->base.start)
return 1;
return 0;
  }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dcdfb97..479703b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -841,6 +841,12 @@ struct i915_ctx_hang_stats {
bool banned;
  };

+struct i915_stolen_node {
+   struct drm_mm_node base;
+   struct list_head mm_link;
+   struct drm_i915_gem_object *obj;
+};
+
  /* This must match up with the value previously used for execbuf2.rsvd1. */
  #define DEFAULT_CONTEXT_HANDLE 0

@@ -1251,6 +1257,13 @@ struct i915_gem_mm {
 */
struct list_head unbound_list;

+   /**
+* List of stolen objects that have been marked as purgeable and
+* thus available for reaping if we need more space for a new
+* allocation. Ordered by time of marking purgeable.
+*/
+   struct list_head stolen_list;
+
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* limited to low memory (32-bit) */

@@ -2031,7 +2044,7 @@ struct drm_i915_gem_object {
struct list_head vma_list;

/** Stolen memory for this object, instead of being backed by shmem. */
-   struct drm_mm_node *stolen;
+   struct i915_stolen_node *stolen;
struct list_head global_list;

struct list_head ring_list[I915_NUM_RINGS];
@@ -2039,6 +2052,8 @@ struct drm_i915_gem_object {
struct list_head obj_exec_link;

struct list_head batch_pool_link;
+   /** Used during stolen memory allocations to temporarily hold a ref */
+   struct list_head stolen_link;

/**
 * This is set if the object is on the active lists (has pending
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05505de..8a508cd 100644
--- 

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Use insert_page for pwrite_fast

[Chris Wilson]

On Thu, Dec 17, 2015 at 10:45:15AM +, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 14/12/15 05:46, ankitprasad.r.sha...@intel.com wrote:
> >From: Ankitprasad Sharma 
> >
> >In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> >we try a nonblocking pin for the whole object (since that is fastest if
> >reused), then failing that we try to grab one page in the mappable
> >aperture. It also allows us to handle objects larger than the mappable
> >aperture (e.g. if we need to pwrite with vGPU restricting the aperture
> >to a measely 8MiB or something like that).
> >
> >v2: Pin pages before starting pwrite, Combined duplicate loops (Chris)
> >
> >v3: Combined loops based on local patch by Chris (Chris)
> >
> >v4: Added i915 wrapper function for drm_mm_insert_node_in_range (Chris)
> >
> >Signed-off-by: Ankitprasad Sharma 
> >Signed-off-by: Chris Wilson 
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 86 
> > ++---
> >  1 file changed, 64 insertions(+), 22 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index bf7f203..46c1e75 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -61,6 +61,21 @@ static bool cpu_write_needs_clflush(struct 
> >drm_i915_gem_object *obj)
> > return obj->pin_display;
> >  }
> >
> >+static int
> >+i915_gem_insert_node_in_range(struct drm_i915_private *i915,
> >+  struct drm_mm_node *node, u64 size,
> >+  unsigned alignment, u64 start, u64 end)
> >+{
> >+int ret;
> >+
> >+ret = drm_mm_insert_node_in_range_generic(>gtt.base.mm, node,
> >+  size, alignment, 0, start,
> >+  end, DRM_MM_SEARCH_DEFAULT,
> >+  DRM_MM_SEARCH_DEFAULT);
> >+
> >+return ret;
> >+}
> >+
> >  /* some bookkeeping */
> >  static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
> >   size_t size)
> >@@ -760,20 +775,29 @@ fast_user_write(struct io_mapping *mapping,
> >   * user into the GTT, uncached.
> >   */
> >  static int
> >-i915_gem_gtt_pwrite_fast(struct drm_device *dev,
> >+i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
> >  struct drm_i915_gem_object *obj,
> >  struct drm_i915_gem_pwrite *args,
> >  struct drm_file *file)
> >  {
> >-struct drm_i915_private *dev_priv = dev->dev_private;
> >-ssize_t remain;
> >-loff_t offset, page_base;
> >+struct drm_mm_node node;
> >+uint64_t remain, offset;
> > char __user *user_data;
> >-int page_offset, page_length, ret;
> >+int ret;
> >
> > ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
> >-if (ret)
> >-goto out;
> >+if (ret) {
> >+memset(, 0, sizeof(node));
> >+ret = i915_gem_insert_node_in_range(i915, , 4096, 0,
> >+0, i915->gtt.mappable_end);
> 
> Suggest PAGE_SIZE instead of 4096 to match the main loop below.
> 
> >+if (ret)
> >+goto out;
> >+
> >+i915_gem_object_pin_pages(obj);
> 
> i915_gem_object_get_pages is missing again before pin pages I think.

That's due to rebasing my patch where I merge the get_pages call into
pin_pages, sorry.

> If true it means we need an IGT to exercise this path. Should be
> easy with a huge object and just pwrite a small chunk?

Hmm, it should be hit by gem_pwrite/big-gtt + huge-gtt. If not, then we
do indeed more testing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Rename vma->*_list to *_link for consistency

[Chris Wilson]

On Thu, Dec 17, 2015 at 11:14:54AM +, Tvrtko Ursulin wrote:
> 
> On 14/12/15 11:36, Chris Wilson wrote:
> >Elsewhere we have adopted the convention of using '_link' to denote
> >elements in the list (and '_list' for the actual list_head itself), and
> >that the name should indicate which list the link belongs to (and
> >preferrably not just where the link is being stored).
> >
> >s/vma_link/obj_link/ (we iterate over obj->vma_list)
> >s/mm_list/vm_link/ (we iterate over vm->[in]active_list)
> 
> A little bit of pain for the established muscle memory but I think
> good in general. Assuming you compile tested it:
> 
> Reviewed-by: Tvrtko Ursulin 
> 
> Btw perhaps rename the link in  i915_gem_active to request_link so
> that the good initiative is not questioned. :)

I think I have:

drm_i915_gem_request.active_list
i915_gem_active.link

There's still a drm_i915_gem_request.client_list to be fixed up, but I
can do that when I show off a scary patch to do lock-free client tracking.

I've read LWN today, my brian is mush. But at least I learnt about the
term lock-free locking.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

[Ville Syrjälä]

On Wed, Dec 16, 2015 at 11:52:17AM +0100, Daniel Vetter wrote:
> On Sun, Dec 06, 2015 at 09:33:20PM +0100, Lukas Wunner wrote:
> > Hi Chris,
> > 
> > On Fri, Dec 04, 2015 at 04:05:26PM +, Chris Wilson wrote:
> > > A long time ago (before 3.14) we relied on a permanent pinning of the
> > > ifbdev to lock the fb in place inside the GGTT. However, the
> > > introduction of stealing the BIOS framebuffer and reusing its address in
> > > the GGTT for the fbdev has muddied waters and we use an inherited fb.
> > > However, the inherited fb is only pinned whilst it is active and we no
> > > longer have an explicit pin for the info->system_base mmapping used by
> > > the fbdev. The result is that after some aperture pressure the fbdev may
> > > be evicted, but we continue to write the fbcon into the same GGTT
> > > address - overwriting anything else that may be put into that offset.
> > > The effect is most pronounced across suspend/resume as
> > > intel_fbdev_set_suspend() does a full clear over the whole scanout.
> > > 
> > > v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from
> > > the BIOS, we do not own the pinned vma (except for the reference we add
> > > in this patch for our access via info->screen_base).
> > > 
> > > v3: Finish balancing the vma pinning for the normal !preallocated case.
> > > 
> > > v4: Try to simplify the pinning even further.
> > > v5: Leak the VMA (cleaned up by object-free) to avoid complicated error 
> > > paths.
> > 
> > It's beautiful how little code is needed to fix this. The only remaining
> > thing I noticed now while looking over the error paths is that these
> > lines in intelfb_alloc() become obsolete with your patch:
> > 
> >  out:
> > mutex_unlock(>struct_mutex);
> > -   if (!IS_ERR_OR_NULL(fb))
> > -   drm_framebuffer_unreference(fb);
> > return ret;
> >  }
> > 
> > Because at each of the remaining "goto out" in the function,
> > fb can be only either an ERR_PTR or NULL.
> > 
> > Also, further up in the function, the declaration of fb can then be
> > changed thus:
> > 
> > -   struct drm_framebuffer *fb = NULL;
> > +   struct drm_framebuffer *fb;
> > 
> > Kind regards,
> 
> Yeah there's room for follow-up polish, but this seems good enough at
> least for -fixes.

I just tested when we started to fail things, and for me it only happens
with 4.4-rc releases (tested with [1]). 4.3.3 OTOH still had the fbcon fb
pinned while X was running.

[1] airlied/drm-fixes 4655a12b81ed ("drm: Don't overwrite UNVERFIED mode status 
to OK")

> 
> Reviewed-by: Daniel Vetter 
> 
> Lukas, feel like supplying a patch to apply the polish you've spotted on
> top?
> 
> Thanks, Daniel
> 
> > 
> > Lukas
> > 
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: "Goel, Akash" 
> > > Cc: Daniel Vetter 
> > > Cc: Jesse Barnes 
> > > Cc: Lukas Wunner 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/i915/intel_fbdev.c | 20 +---
> > >  1 file changed, 13 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> > > b/drivers/gpu/drm/i915/intel_fbdev.c
> > > index 7ccde58f8c98..bea75cafc623 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > > @@ -163,13 +163,6 @@ static int intelfb_alloc(struct drm_fb_helper 
> > > *helper,
> > >   goto out;
> > >   }
> > >  
> > > - /* Flush everything out, we'll be doing GTT only from now on */
> > > - ret = intel_pin_and_fence_fb_obj(NULL, fb, NULL);
> > > - if (ret) {
> > > - DRM_ERROR("failed to pin obj: %d\n", ret);
> > > - goto out;
> > > - }
> > > -
> > >   mutex_unlock(>struct_mutex);
> > >  
> > >   ifbdev->fb = to_intel_framebuffer(fb);
> > > @@ -225,6 +218,14 @@ static int intelfb_create(struct drm_fb_helper 
> > > *helper,
> > >  
> > >   mutex_lock(>struct_mutex);
> > >  
> > > + /* Pin the GGTT vma for our access via info->screen_base.
> > > +  * This also validates that any existing fb inherited from the
> > > +  * BIOS is suitable for own access.
> > > +  */
> > > + ret = intel_pin_and_fence_fb_obj(NULL, >fb->base, NULL);
> > > + if (ret)
> > > + goto out_unlock;
> > > +
> > >   info = drm_fb_helper_alloc_fbi(helper);
> > >   if (IS_ERR(info)) {
> > >   DRM_ERROR("Failed to allocate fb_info\n");
> > > @@ -287,6 +288,7 @@ out_destroy_fbi:
> > >   drm_fb_helper_release_fbi(helper);
> > >  out_unpin:
> > >   i915_gem_object_ggtt_unpin(obj);
> > > +out_unlock:
> > >   mutex_unlock(>struct_mutex);
> > >   return ret;
> > >  }
> > > @@ -524,6 +526,10 @@ static const struct drm_fb_helper_funcs 
> > > intel_fb_helper_funcs = {
> > >  static void intel_fbdev_destroy(struct drm_device *dev,
> > >   struct intel_fbdev *ifbdev)
> > >  {
> > > + /* We rely on the object-free to release the VMA pinning for
> > 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: tidy up initialisation failure paths (legacy)

[Nick Hoath]

On 16/12/2015 18:36, Gordon, David S wrote:

1. Fix intel_cleanup_ring_buffer() to handle the error cleanup
case where the ringbuffer has been allocated but map-and-pin
failed. Unpin it iff it's previously been mapped-and-pinned.

2. Fix the error path in intel_init_ring_buffer(), which already
called intel_destroy_ringbuffer_obj(), but failed to free the
actual ringbuffer structure. Calling intel_ringbuffer_free()
instead does both in one go.

3. With the above change, intel_destroy_ringbuffer_obj() is only
called in one place (intel_ringbuffer_free()), so flatten it
into that function.

4. move low-level register accesses from intel_cleanup_ring_buffer()
(which calls intel_stop_ring_buffer(ring) which calls stop_ring())
down into stop_ring() itself), which is already doing low-level
register accesses. Then, intel_cleanup_ring_buffer() no longer
needs 'dev_priv'.


Reviewed-by: Nick Hoath 


Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/intel_ringbuffer.c | 47 +++--
  1 file changed, 22 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index eefce9a..2853754 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -549,6 +549,8 @@ static bool stop_ring(struct intel_engine_cs *ring)
I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
}

+   WARN_ON(!IS_GEN2(ring->dev) && (I915_READ_MODE(ring) & MODE_IDLE) == 0);
+
return (I915_READ_HEAD(ring) & HEAD_ADDR) == 0;
  }

@@ -2057,12 +2059,6 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return 0;
  }

-static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
-{
-   drm_gem_object_unreference(>obj->base);
-   ringbuf->obj = NULL;
-}
-
  static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
  struct intel_ringbuffer *ringbuf)
  {
@@ -2125,11 +2121,14 @@ intel_engine_create_ringbuffer(struct intel_engine_cs 
*engine, int size)
  }

  void
-intel_ringbuffer_free(struct intel_ringbuffer *ring)
+intel_ringbuffer_free(struct intel_ringbuffer *ringbuf)
  {
-   intel_destroy_ringbuffer_obj(ring);
-   list_del(>link);
-   kfree(ring);
+   if (ringbuf->obj) {
+   drm_gem_object_unreference(>obj->base);
+   ringbuf->obj = NULL;
+   }
+   list_del(>link);
+   kfree(ringbuf);
  }

  static int intel_init_ring_buffer(struct drm_device *dev,
@@ -2157,6 +2156,13 @@ static int intel_init_ring_buffer(struct drm_device *dev,
}
ring->buffer = ringbuf;

+   ret = intel_pin_and_map_ringbuffer_obj(dev, ringbuf);
+   if (ret) {
+   DRM_ERROR("Failed to pin and map ringbuffer %s: %d\n",
+   ring->name, ret);
+   goto error;
+   }
+
if (I915_NEED_GFX_HWS(dev)) {
ret = init_status_page(ring);
if (ret)
@@ -2168,14 +2174,6 @@ static int intel_init_ring_buffer(struct drm_device *dev,
goto error;
}

-   ret = intel_pin_and_map_ringbuffer_obj(dev, ringbuf);
-   if (ret) {
-   DRM_ERROR("Failed to pin and map ringbuffer %s: %d\n",
-   ring->name, ret);
-   intel_destroy_ringbuffer_obj(ringbuf);
-   goto error;
-   }
-
ret = i915_cmd_parser_init_ring(ring);
if (ret)
goto error;
@@ -2189,19 +2187,18 @@ error:

  void intel_cleanup_ring_buffer(struct intel_engine_cs *ring)
  {
-   struct drm_i915_private *dev_priv;
+   struct intel_ringbuffer *ringbuf;

if (!intel_ring_initialized(ring))
return;

-   dev_priv = to_i915(ring->dev);
-
-   if (ring->buffer) {
+   ringbuf = ring->buffer;
+   if (ringbuf) {
intel_stop_ring_buffer(ring);
-   WARN_ON(!IS_GEN2(ring->dev) && (I915_READ_MODE(ring) & 
MODE_IDLE) == 0);

-   intel_unpin_ringbuffer_obj(ring->buffer);
-   intel_ringbuffer_free(ring->buffer);
+   if (ringbuf->virtual_start)
+   intel_unpin_ringbuffer_obj(ringbuf);
+   intel_ringbuffer_free(ringbuf);
ring->buffer = NULL;
}




___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx