[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/Gen9+: optional IPC enablement (rev2)
== Series Details == Series: drm/i915/Gen9+: optional IPC enablement (rev2) URL : https://patchwork.freedesktop.org/series/5203/ State : success == Summary == Series 5203v2 drm/i915/Gen9+: optional IPC enablement http://patchwork.freedesktop.org/api/1.0/series/5203/revisions/2/mbox/ Test kms_force_connector_basic: Subgroup prune-stale-modes: skip -> PASS (ilk-hp8440p) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:16 pass:14 dwarn:0 dfail:0 fail:0 skip:1 ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1795/ aedfaaef290af9c8df7d9f4adf22cbe21704d091 drm-intel-nightly: 2016y-04m-04d-13h-09m-54s UTC integration manifest d20c9777a31b1e396102766eb749541314e2ad57 drm/i915/Gen9+: optional IPC enablement ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915/dsi: add support for DSI sequence block v2 gpio element
On Mon, 04 Apr 2016, Ville Syrjälä wrote:
> On Fri, Mar 18, 2016 at 01:11:10PM +0200, Jani Nikula wrote:
>> In sequence block v2, and only in v2, the gpio source (i.e. IOSF port)
>> is specified separately.
>>
>> v2: initialize gpio_source to 0 and handle v1 and v2 in the same branch
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Pushed to drm-intel-next-queued, thanks for the review.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 22 ++
>> 1 file changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> index f687b2e9d8ca..af1a47b5224f 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
>> @@ -198,7 +198,7 @@ static const u8 *mipi_exec_delay(struct intel_dsi
>> *intel_dsi, const u8 *data)
>>
>> static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
>> {
>> -u8 gpio_index, action;
>> +u8 gpio_source, gpio_index, action, port;
>> u16 function, pad;
>> u32 val;
>> struct drm_device *dev = intel_dsi->base.base.dev;
>> @@ -209,6 +209,12 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
>> *intel_dsi, const u8 *data)
>>
>> gpio_index = *data++;
>>
>> +/* gpio source in sequence v2 only */
>> +if (dev_priv->vbt.dsi.seq_version == 2)
>> +gpio_source = (*data >> 1) & 3;
>> +else
>> +gpio_source = 0;
>> +
>> /* pull up/down */
>> action = *data++ & 1;
>>
>> @@ -225,6 +231,15 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
>> *intel_dsi, const u8 *data)
>> if (dev_priv->vbt.dsi.seq_version >= 3) {
>> DRM_DEBUG_KMS("GPIO element v3 not supported\n");
>> goto out;
>> +} else {
>> +if (gpio_source == 0) {
>> +port = IOSF_PORT_GPIO_NC;
>> +} else if (gpio_source == 1) {
>> +port = IOSF_PORT_GPIO_SC;
>> +} else {
>> +DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
>> +goto out;
>> +}
>> }
>>
>> function = gtable[gpio_index].function_reg;
>> @@ -234,15 +249,14 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
>> *intel_dsi, const u8 *data)
>> if (!gtable[gpio_index].init) {
>> /* program the function */
>> /* FIXME: remove constant below */
>> -vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
>> - 0x2000CC00);
>> +vlv_iosf_sb_write(dev_priv, port, function, 0x2000CC00);
>> gtable[gpio_index].init = 1;
>> }
>>
>> val = 0x4 | action;
>>
>> /* pull up/down */
>> -vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, pad, val);
>> +vlv_iosf_sb_write(dev_priv, port, pad, val);
>> mutex_unlock(&dev_priv->sb_lock);
>>
>> out:
>> --
>> 2.1.4
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/chv: add more IOSF port definitions
On Mon, 04 Apr 2016, Ville Syrjälä wrote: > On Fri, Mar 18, 2016 at 01:11:15PM +0200, Jani Nikula wrote: >> Signed-off-by: Jani Nikula > > Reviewed-by: Ville Syrjälä Pushed to drm-intel-next-queued, thanks for the review. BR, Jani. > >> --- >> drivers/gpu/drm/i915/i915_reg.h | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index 07e04495cd9a..6e36c0d51023 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -623,6 +623,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) >> #define IOSF_PORT_GPIO_SC 0x48 >> #define IOSF_PORT_GPIO_SUS0xa8 >> #define IOSF_PORT_CCU 0xa9 >> +#define CHV_IOSF_PORT_GPIO_N 0x13 >> +#define CHV_IOSF_PORT_GPIO_SE 0x48 >> +#define CHV_IOSF_PORT_GPIO_E 0xa8 >> +#define CHV_IOSF_PORT_GPIO_SW 0xb2 >> #define VLV_IOSF_DATA _MMIO(VLV_DISPLAY_BASE >> + 0x2104) >> #define VLV_IOSF_ADDR _MMIO(VLV_DISPLAY_BASE >> + 0x2108) >> >> -- >> 2.1.4 -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/shrinker: Account for unshrinkable unbound pages
On ma, 2016-04-04 at 14:46 +0100, Chris Wilson wrote:
> Since we only attempt to purge an object if can_release_pages() report
> true, we should also only add it to the count of potential recoverable
> pages when can_release_pages() is true.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Akash Goel
> ---
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index d3c473ffb90a..e391ee3ec486 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -246,7 +246,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct
> shrink_control *sc)
>
> count = 0;
> list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list)
> - if (obj->pages_pin_count == 0)
> + if (can_release_pages(obj))
> count += obj->base.size >> PAGE_SHIFT;
>
> list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] mm/vmap: Add a notifier for when we run out of vmap address space
On ma, 2016-04-04 at 14:46 +0100, Chris Wilson wrote:
> vmaps are temporary kernel mappings that may be of long duration.
> Reusing a vmap on an object is preferrable for a driver as the cost of
> setting up the vmap can otherwise dominate the operation on the object.
> However, the vmap address space is rather limited on 32bit systems and
> so we add a notification for vmap pressure in order for the driver to
> release any cached vmappings.
>
> The interface is styled after the oom-notifier where the callees are
> passed a pointer to an unsigned long counter for them to indicate if they
> have freed any space.
>
> v2: Guard the blocking notifier call with gfpflags_allow_blocking()
> v3: Correct typo in forward declaration and move to head of file
>
> Signed-off-by: Chris Wilson
> Cc: Andrew Morton
> Cc: David Rientjes
> Cc: Roman Peniaev
> Cc: Mel Gorman
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Acked-by: Andrew Morton # for inclusion via DRM
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> ---
> include/linux/vmalloc.h | 4
> mm/vmalloc.c| 27 +++
> 2 files changed, 31 insertions(+)
>
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index d1f1d338af20..8b51df3ab334 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -8,6 +8,7 @@
> #include
>
> struct vm_area_struct; /* vma defining user mapping in
> mm_types.h */
> +struct notifier_block; /* in notifier.h */
>
> /* bits in flags of vmalloc's vm_struct below */
> #define VM_IOREMAP 0x0001 /* ioremap() and friends */
> @@ -187,4 +188,7 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms)
> #define VMALLOC_TOTAL 0UL
> #endif
>
> +int register_vmap_purge_notifier(struct notifier_block *nb);
> +int unregister_vmap_purge_notifier(struct notifier_block *nb);
> +
> #endif /* _LINUX_VMALLOC_H */
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ae7d20b447ff..293889d7f482 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -344,6 +345,8 @@ static void __insert_vmap_area(struct vmap_area *va)
>
> static void purge_vmap_area_lazy(void);
>
> +static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
> +
> /*
> * Allocate a region of KVA of the specified size and alignment, within the
> * vstart and vend.
> @@ -363,6 +366,8 @@ static struct vmap_area *alloc_vmap_area(unsigned long
> size,
> BUG_ON(offset_in_page(size));
> BUG_ON(!is_power_of_2(align));
>
> + might_sleep_if(gfpflags_allow_blocking(gfp_mask));
> +
> va = kmalloc_node(sizeof(struct vmap_area),
> gfp_mask & GFP_RECLAIM_MASK, node);
> if (unlikely(!va))
> @@ -468,6 +473,16 @@ overflow:
> purged = 1;
> goto retry;
> }
> +
> + if (gfpflags_allow_blocking(gfp_mask)) {
> + unsigned long freed = 0;
> + blocking_notifier_call_chain(&vmap_notify_list, 0, &freed);
> + if (freed > 0) {
> + purged = 0;
> + goto retry;
> + }
> + }
> +
> if (printk_ratelimit())
> pr_warn("vmap allocation for size %lu failed: use vmalloc= to
> increase size\n",
> size);
> @@ -475,6 +490,18 @@ overflow:
> return ERR_PTR(-EBUSY);
> }
>
> +int register_vmap_purge_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&vmap_notify_list, nb);
> +}
> +EXPORT_SYMBOL_GPL(register_vmap_purge_notifier);
> +
> +int unregister_vmap_purge_notifier(struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_unregister(&vmap_notify_list, nb);
> +}
> +EXPORT_SYMBOL_GPL(unregister_vmap_purge_notifier);
> +
> static void __free_vmap_area(struct vmap_area *va)
> {
> BUG_ON(RB_EMPTY_NODE(&va->rb_node));
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/shrinker: Hook up vmap allocation failure notifier
On ma, 2016-04-04 at 14:46 +0100, Chris Wilson wrote:
> If the core runs out of vmap address space, it will call a notifier in
> case any driver can reap some of its vmaps. As i915.ko is possibily
> holding onto vmap address space that could be recovered, hook into the
> notifier chain and try and reap objects holding onto vmaps.
>
> Signed-off-by: Chris Wilson
> Cc: Andrew Morton
> Cc: David Rientjes
> Cc: Roman Pen
> Cc: Mel Gorman
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Cc: Joonas Lahtinen
A comment below. But regardless;
Reviewed-by: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Mika Kahola
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 39
>
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dd187727c813..6443745d4182 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1257,6 +1257,7 @@ struct i915_gem_mm {
> struct i915_hw_ppgtt *aliasing_ppgtt;
>
> struct notifier_block oom_notifier;
> + struct notifier_block vmap_notifier;
> struct shrinker shrinker;
> bool shrinker_no_lock_stealing;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index e391ee3ec486..be7501afb59e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -356,6 +357,40 @@ i915_gem_shrinker_oom(struct notifier_block *nb,
> unsigned long event, void *ptr)
> return NOTIFY_DONE;
> }
>
> +static int
> +i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned long event, void
> *ptr)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(nb, struct drm_i915_private, mm.vmap_notifier);
> + struct drm_device *dev = dev_priv->dev;
> + unsigned long timeout = msecs_to_jiffies(5000) + 1;
> + unsigned long freed_pages;
> + bool was_interruptible;
> + bool unlock;
> +
> + while (!i915_gem_shrinker_lock(dev, &unlock) && --timeout) {
> + schedule_timeout_killable(1);
> + if (fatal_signal_pending(current))
> + return NOTIFY_DONE;
> + }
> + if (timeout == 0) {
> + pr_err("Unable to purge GPU vmaps due to lock contention.\n");
> + return NOTIFY_DONE;
> + }
> +
> + was_interruptible = dev_priv->mm.interruptible;
> + dev_priv->mm.interruptible = false;
> +
> + freed_pages = i915_gem_shrink_all(dev_priv);
> +
> + dev_priv->mm.interruptible = was_interruptible;
Up until here this is same function as the oom shrinker, so I would
combine these two and here do "if (vmap) goto out;" sort of thing.
Would just need a way to distinct between two calling sites. I did not
come up with a quick solution as both are passing 0 as event.
Regards, Joonas
> + if (unlock)
> + mutex_unlock(&dev->struct_mutex);
> +
> + *(unsigned long *)ptr += freed_pages;
> + return NOTIFY_DONE;
> +}
> +
> /**
> * i915_gem_shrinker_init - Initialize i915 shrinker
> * @dev_priv: i915 device
> @@ -371,6 +406,9 @@ void i915_gem_shrinker_init(struct drm_i915_private
> *dev_priv)
>
> dev_priv->mm.oom_notifier.notifier_call = i915_gem_shrinker_oom;
> WARN_ON(register_oom_notifier(&dev_priv->mm.oom_notifier));
> +
> + dev_priv->mm.vmap_notifier.notifier_call = i915_gem_shrinker_vmap;
> + WARN_ON(register_vmap_purge_notifier(&dev_priv->mm.vmap_notifier));
> }
>
> /**
> @@ -381,6 +419,7 @@ void i915_gem_shrinker_init(struct drm_i915_private
> *dev_priv)
> */
> void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv)
> {
> + WARN_ON(unregister_vmap_purge_notifier(&dev_priv->mm.vmap_notifier));
> WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
> unregister_shrinker(&dev_priv->mm.shrinker);
> }
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] test/gem_mocs_settings: Testing MOCS register settings
Others should be preserved across suspend. BUT they are not context saved (I Know!) so any sort of dirty test won't work. The current test will check the other engines values as they are programmed on start-up (with the new patches) and should be preserved (or be reprogrammed) when coming out of *C6/Suspend/Hibernate. So context save/resume only needs to be tested for the RCS engine. For Now. Peter. On Mon, 4 Apr 2016, Chris Wilson wrote: On Mon, Apr 04, 2016 at 06:30:21PM +0100, Peter Antoine wrote: As well as checking for creating new contexts after resume, we also need to check that the register values are preserved across suspend (i.e. that the register state is being saved back into the context image and then restored). Ok, I'll add another test case that does this for the render engine (the only one that is effected (at the moment) by context save and resume. We do expect that the mocs values for other rings to be preserved across suspend. Or did I misunderstand you? i.e create-context; bcs; suspend; bcs should^W must work. -Chris -- Peter Antoine (Android Graphics Driver Software Engineer) - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/16] drm/i915/gen9: Make power well disabling synchronous
On Mon, Apr 04, 2016 at 12:34:30PM +0200, Patrik Jakobsson wrote:
> On Fri, Apr 01, 2016 at 04:02:36PM +0300, Imre Deak wrote:
> > So far we only power well enabling was synchronous not disabling. Since
> > we don't exactly know how the firmware (both DMC and PCU) synchronizes
> > against the actual power well state during DC transitions, make the
> > disabling also synchronous.
> >
> > CC: Mika Kuoppala
> > CC: Patrik Jakobsson
> > Signed-off-by: Imre Deak
>
> Reviewed-by: Patrik Jakobsson
Perhaps I was too quick with the review. I'm getting timeouts when trying to
disable MISC IO and PW1 on SKL. Need to have a closer look at what's going on
here.
-Patrik
>
> > ---
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index d20fd8f..f5f6e89 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -720,10 +720,6 @@ static void skl_set_power_well(struct drm_i915_private
> > *dev_priv,
> >
> > if (!is_enabled) {
> > DRM_DEBUG_KMS("Enabling %s\n", power_well->name);
> > - if (wait_for((I915_READ(HSW_PWR_WELL_DRIVER) &
> > - state_mask), 1))
> > - DRM_ERROR("%s enable timeout\n",
> > - power_well->name);
> > check_fuse_status = true;
> > }
> > } else {
> > @@ -737,6 +733,11 @@ static void skl_set_power_well(struct drm_i915_private
> > *dev_priv,
> > bxt_sanitize_power_well_requests(dev_priv, power_well);
> > }
> >
> > + if (wait_for(!!(I915_READ(HSW_PWR_WELL_DRIVER) & state_mask) == enable,
> > +1))
> > + DRM_ERROR("%s %s timeout\n",
> > + power_well->name, enable ? "enable" : "disable");
> > +
> > if (check_fuse_status) {
> > if (power_well->data == SKL_DISP_PW_1) {
> > if (wait_for((I915_READ(SKL_FUSE_STATUS) &
> > --
> > 2.5.0
> >
>
> --
> ---
> Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista,
> Stockholm, Sweden Registration Number: 556189-6027
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
---
Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm,
Sweden Registration Number: 556189-6027
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison
On Mon, 04 Apr 2016, Ramalingam C wrote: > On Thursday 31 March 2016 12:34 AM, Daniel Vetter wrote: >> On Wed, Mar 30, 2016 at 07:49:40PM +0530, Ramalingam C wrote: >>> On Wednesday 30 March 2016 05:02 PM, Daniel Vetter wrote: On Tue, Mar 29, 2016 at 11:04:51PM +0530, Ramalingam C wrote: > At BXT DSI, PIPE registers are inactive. So we can't get the > PIPE's mode parameters from them. The possible option is > retriving them from the PORT registers. But mode timing > parameters are progammed to port registers interms of byteclocks. > > The formula used to convert the pixels interms of byteclk is > DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio, > 8 * 100), lane_count); > > So we retrieve them, interms of pixels as > DIV_ROUND_UP((clk_hs * lane_count * 8 * 100), > (bpp * burst_mode_ratio)); > > Due to the multiple DIV_ROUND_UP in both formulas we get the worst > case delta in the retrieved PIPE's timing parameter as below > DIV_ROUND_UP((8 * intel_dsi->lane_count * 100), > (dsi_pixel_format_bpp(intel_dsi->pixel_format) * > intel_dsi->burst_mode_ratio))) > > This converson of byteclk to pixel is required for hsync, hfp and hbp. > Which intern impacts horrizontal timing parameters. At worst case to > get htotal all there parameters are added with hactive. > Hence delta will be 3 times of above formula. Hence this value is > considered as tolerance for pipe_config comparison, in case of BXT DSI. > > Signed-off-by: Ramalingam C This is the wrong way round imo, better would be to adjust the adjusted mode in the bxt dsi compute_config function to match the hw granularity. Stuff _really_ should match exactly, the fuzzy clock matching is mostly because our clock cod is a mess, and we can't/don't properly forward-compuate the actual clock timings we program into the hardware. -Daniel >>> Daniel, I got your point. But the problem will be that difficulty(even if >>> possible) in adjusting the adjusted mode parameters. >>> Reason is we are not programing the mode parameter as such. We will derive >>> the hfp, hsync and hbp from >>> hsync_start, hsync_end, hdisplay and htotal. These will be adjusted(divided >>> by 2) for dual link scenario. >>> And then resultant will go into the conversion as mentioned in the commit >>> message (two DIV_ROUND_UP onwards >>> and one DIV_ROUND_UP backwards). For this we have to make the parameter >>> divisible by three different factors. >>> So IMHO, even if this is possible, it will look more messy. >>> >>> Predicting the max error and tolerating it in pipe_config_compare will be >>> the straight forward and more reasonable. >>> Please let me know if i can go ahead in this approach. >> Yeah I discussed this some more with Jani on irc. I'd say we should store >> this adjusted horizontal timings (the ones fudged with burst_mode_ratio, >> lane_count, dual-link and all these things applied) into >> crtc_state->base.adjusted_mode. And then ofc also read those values out. >> >> The overall idea of the state verify/compare logic is that we start out >> with requested state from userspace, then derive the real hw state. And >> then compare that computed hw state with what's there already. Except for >> clocks, where there's special reasons, we never go back, since going back >> requires us to apply a range. This is the only way to guarnatee that "hw >> has the same exact mode programmed in both cases" iff "intel_crtc_state >> matches per intel_crtc_config_compare". >> >> state->adjusted_mode is never exposed to userspace, so there's no problem >> if it's has "strange" values. And we already have pipe_src_h/w to express >> the logical input rectangle. >> >> The idea is similar to how we set adjusted_mode.flags to what we actually >> program, instead of trying to make something up that's not perfectly >> accurate. >> -Daniel > Daniel, > > I have tested by adjusting the adjusted_mode in set_dsi_timings() > instead of intel_dsi_compute_config(). > Reason is if we modify the adjusted mode at intel_dsi_compute_config() > itself, then modified value will > be taken as input for set_dsi_timings. Hence the get_config will deviate > further. I hope this should be fine with you and Jani. > > This will work out, if set_dsi_timings() is called after the > dsi_compute_config() on every suspend and resume or modeset. > I will verify this on Android once and update. > > Please share your view on this, so that can update the patch with > corresponding changes. I can't speak for Daniel, but I think his point was to update adjusted mode in ->compute_config() in a way that can be used directly in set_dsi_timings(). Then, it should be possible to read the timings from the hardware, and compare. BR, Jani. >> > --- > Reviewed at >
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.
Op 04-04-16 om 17:47 schreef Marius Vlad:
> igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
> set-up.
>
> Signed-off-by: Marius Vlad
> ---
> lib/igt_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 82257a6..30c5b7e 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1585,7 +1585,7 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
> igt_output_t *output,
> igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID,
> fb_id);
> }
>
> - if (plane->position_changed || plane->size_changed) {
> + if ((plane->position_changed || plane->size_changed) && fb_id != 0) {
> uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
> uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
> uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
Why is this needed?
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
On 04/04/16 19:58, Chris Wilson wrote: On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Current implementation releases the forcewake at any time between straight away, and one jiffie from the last put, or first automatic grab. That isn't the problem though. The problem is that we set the timer on first use rather than last use. All you are stating here is that by lengthening the timeout on your system you reduce the number of times it times out. It is true the reduction I see is due lengthening of the average timeout. But with regards to re-arming approach, I thought so initially myself, but then, if we expect bursty access then it shouldn't matter and the simplicity of doing it like it currently is better. Even in practice, I noticed the effect of lengthening the timeout is much greater than moving the arming to the last access. And to get to very few to none auto releases on busy workloads we need in the regions of 5ms, which would be a big change. Or maybe not if you consider HZ=100 kernels. It is very difficult to know what is actually better considering power between the CPU and GPU and performance. So I though the best would be to keep it similar to the current timings, just fix the dependency on HZ and also slack with hrtimers might help with something. As a final data point, explicit puts and auto releases seems to be relatively balanced in my testing. With this patch T-Rex for example auto-releases in the region of 3-4 times in 10ms, with around 5-10 explicit gets, and 5-10 implicit gets in 10ms. A different, interrupt heavy workload (~20k irqs/sec) manages similarly 2-4 auto-releases per 10ms, and has ~250 explicit gets and ~380 implicit per 10ms. Looking at the two I think the fact they manage to auto-release relatively similarly, compared to a huge different in fw gets, suggest burstyness. So I am not sure that any smarts with the release period would be interesting. At least not without serious power/perf measurements. Having said that, the conversion to hrtimer seems sensible but to add tracking of the last access as opposed to first we either fallback to jiffie (in which case hrtimer is moot) or rely on ktime_get_raw() being fast enough for every register write. Hmm, my usual response to that has been if it matters we avoid the heavyweight macros and use the _FW interface - or even raw readl/writel. Could you try storing ktime_get_raw() on every access and rearming the timer if it expires before last-access + min-period? That would be similar to your patch from before my holiday, right? As I said above, I did not notice much change with that approach. Just extending the timeout has a much greater effect, but as I wrote above, I am not sure we want to change it. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
On Tue, Apr 05, 2016 at 09:54:58AM +0100, Tvrtko Ursulin wrote: > > On 04/04/16 19:58, Chris Wilson wrote: > >On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Current implementation releases the forcewake at any time between > >>straight away, and one jiffie from the last put, or first automatic > >>grab. > > > >That isn't the problem though. The problem is that we set the timer on > >first use rather than last use. All you are stating here is that by > >lengthening the timeout on your system you reduce the number of times it > >times out. > > It is true the reduction I see is due lengthening of the average timeout. > > But with regards to re-arming approach, I thought so initially > myself, but then, if we expect bursty access then it shouldn't > matter and the simplicity of doing it like it currently is better. > > Even in practice, I noticed the effect of lengthening the timeout is > much greater than moving the arming to the last access. And to get > to very few to none auto releases on busy workloads we need in the > regions of 5ms, which would be a big change. Or maybe not if you > consider HZ=100 kernels. > > It is very difficult to know what is actually better considering > power between the CPU and GPU and performance. So I though the best > would be to keep it similar to the current timings, just fix the > dependency on HZ and also slack with hrtimers might help with > something. > > As a final data point, explicit puts and auto releases seems to be > relatively balanced in my testing. With this patch T-Rex for example > auto-releases in the region of 3-4 times in 10ms, with around 5-10 > explicit gets, and 5-10 implicit gets in 10ms. > > A different, interrupt heavy workload (~20k irqs/sec) manages > similarly 2-4 auto-releases per 10ms, and has ~250 explicit gets and > ~380 implicit per 10ms. > > Looking at the two I think the fact they manage to auto-release > relatively similarly, compared to a huge different in fw gets, > suggest burstyness. So I am not sure that any smarts with the > release period would be interesting. At least not without serious > power/perf measurements. > > >Having said that, the conversion to hrtimer seems sensible but to add > >tracking of the last access as opposed to first we either fallback to > >jiffie (in which case hrtimer is moot) or rely on ktime_get_raw() being > >fast enough for every register write. Hmm, my usual response to that has > >been if it matters we avoid the heavyweight macros and use the _FW > >interface - or even raw readl/writel. > > > >Could you try storing ktime_get_raw() on every access and rearming the > >timer if it expires before last-access + min-period? > > That would be similar to your patch from before my holiday, right? > As I said above, I did not notice much change with that approach. > Just extending the timeout has a much greater effect, but as I wrote > above, I am not sure we want to change it. There was just one bug in that patch in checking the expiration that makes a huge difference, but if you please add the discussion above to the commit log that would be invaluable. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Do not serialize forcewake acquire across domains
On 04/04/16 20:07, Chris Wilson wrote: On Mon, Apr 04, 2016 at 05:51:11PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin On platforms with multiple forcewake domains it seems more efficient to request all desired ones and then to wait for acks to avoid needlessly serializing on each domain. Not convinced since we have more machines with one domain than two. What I did was to compact the domains array so that we only iterated over the known set - but that feels overkill when we only have two domains today. For the same reason (only one machine with two domains), I didn't think seperate functions to iterate over one domain and another to iterate over all was worth it. What you can do though is remove an excess posting read from fw_domains_put. Compared to the cost of a register access (the spinlock irq mostly) the iterator doesn't strike me as being that worthwhile an optimisation target. Correct, I thought we agreed that the majority of the CPU time attributed to fw_domains_get is from the busy spinning while waiting on the ack from the GPU. This patch is not optimising the iterator, but requests all domains to be woken up and then waits for acks. It changes the time spent busy spinning from Td1 + ... + Td2 to max(Td1...Tdn). Yes it is only interesting for platforms with more than one fw domain. But since we agreed iterator is not significant, the fact that it adds two loops* over the array should not be noticeable vs. the gain for multi-fw domain machines (which will be more and more of as time goes by). Regards, Tvrtko * Also because 2/3 from this serious has shrunk the iterator considerably, even with two iterations fw_domains_get remains pretty much the same size now with two loops, vs one loop before it. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/shrinker: Hook up vmap allocation failure notifier
On Tue, Apr 05, 2016 at 11:19:38AM +0300, Joonas Lahtinen wrote:
> On ma, 2016-04-04 at 14:46 +0100, Chris Wilson wrote:
> > If the core runs out of vmap address space, it will call a notifier in
> > case any driver can reap some of its vmaps. As i915.ko is possibily
> > holding onto vmap address space that could be recovered, hook into the
> > notifier chain and try and reap objects holding onto vmaps.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Andrew Morton
> > Cc: David Rientjes
> > Cc: Roman Pen
> > Cc: Mel Gorman
> > Cc: linux...@kvack.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: Joonas Lahtinen
>
> A comment below. But regardless;
>
> Reviewed-by: Joonas Lahtinen
>
> > Cc: Tvrtko Ursulin
> > Cc: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem_shrinker.c | 39
> >
> > 2 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index dd187727c813..6443745d4182 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1257,6 +1257,7 @@ struct i915_gem_mm {
> > struct i915_hw_ppgtt *aliasing_ppgtt;
> >
> > struct notifier_block oom_notifier;
> > + struct notifier_block vmap_notifier;
> > struct shrinker shrinker;
> > bool shrinker_no_lock_stealing;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > index e391ee3ec486..be7501afb59e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -356,6 +357,40 @@ i915_gem_shrinker_oom(struct notifier_block *nb,
> > unsigned long event, void *ptr)
> > return NOTIFY_DONE;
> > }
> >
> > +static int
> > +i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned long event,
> > void *ptr)
> > +{
> > + struct drm_i915_private *dev_priv =
> > + container_of(nb, struct drm_i915_private, mm.vmap_notifier);
> > + struct drm_device *dev = dev_priv->dev;
> > + unsigned long timeout = msecs_to_jiffies(5000) + 1;
> > + unsigned long freed_pages;
> > + bool was_interruptible;
> > + bool unlock;
> > +
> > + while (!i915_gem_shrinker_lock(dev, &unlock) && --timeout) {
> > + schedule_timeout_killable(1);
> > + if (fatal_signal_pending(current))
> > + return NOTIFY_DONE;
> > + }
> > + if (timeout == 0) {
> > + pr_err("Unable to purge GPU vmaps due to lock contention.\n");
> > + return NOTIFY_DONE;
> > + }
> > +
> > + was_interruptible = dev_priv->mm.interruptible;
> > + dev_priv->mm.interruptible = false;
> > +
> > + freed_pages = i915_gem_shrink_all(dev_priv);
> > +
> > + dev_priv->mm.interruptible = was_interruptible;
>
> Up until here this is same function as the oom shrinker, so I would
> combine these two and here do "if (vmap) goto out;" sort of thing.
>
> Would just need a way to distinct between two calling sites. I did not
> come up with a quick solution as both are passing 0 as event.
Less thrilled about merging the two notifier callbacks, but we could
wrap i915_gem_shrinker_lock_killable().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators
On 04/04/16 20:14, Dave Gordon wrote:
On 04/04/16 17:51, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the vast majority of users does not use the domain id variable,
"do not use"
Yep.
we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.
For a couple of callers which do need the domain id, or the domain
mask, store the later in the domain itself at init time and use
both through it.
"For a couple of callers which do need the domain mask, store it
in the domain array (which already has the domain id), then both
can be retrieved thence." ?
Better yes.
Result is clearer code and smaller generated binary, especially
in the tight fw get/put loops. Also, relationship between domain
id and mask is no longer assumed in the macro.
"in the macro or elsewhere" ?
Just in the macro, it is still hardcoded in fw_domain_init.
Signed-off-by: Tvrtko Ursulin
A few typos & clarifications above, plus a minor quibble about a macro
name (which you haven't actually changed, but might as well fix).
Otherwise LGTM, so
Reviewed-by: Dave Gordon
(even if you don't change the macro name)
Thanks, consistency sounds good so I will change it.
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h | 17 +++---
drivers/gpu/drm/i915/intel_uncore.c | 45
+
3 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af02c292..06fce014d0b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1464,12 +1464,11 @@ static int i915_forcewake_domains(struct
seq_file *m, void *data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_uncore_forcewake_domain *fw_domain;
-int i;
spin_lock_irq(&dev_priv->uncore.lock);
-for_each_fw_domain(fw_domain, dev_priv, i) {
+for_each_fw_domain(fw_domain, dev_priv) {
seq_printf(m, "%s.wake_count = %u\n",
- intel_uncore_forcewake_domain_to_str(i),
+ intel_uncore_forcewake_domain_to_str(fw_domain->id),
fw_domain->wake_count);
}
spin_unlock_irq(&dev_priv->uncore.lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 7d4c704d7d75..160f980f0368 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -665,6 +665,7 @@ struct intel_uncore {
struct intel_uncore_forcewake_domain {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
+enum forcewake_domains mask;
At present this mask will always have only one bit set, but I suppose
there might be some utility in allowing multiple bits (virtual domains?)
I did not like the name mask myself but couldn't think of anything
better. Do you have a suggestion?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation
Hi,
On 25/03/16 13:18, Kukanova, Svetlana wrote:
Hi everyone,
Yes, this breaks userspace ABI and in particular it broke VTune work.
Ring ids are seen via i915 tracepoints, and VTune Amplifier uses them.
We were relying on the old ring ids, and assuming that the new rings would be
added to the end of the enum.
I'm objecting just now because now this driver change reached our internal
users and they complained that VTune is reporting DMA packets on wrong engines.
I would request this change (the enum intel_ring_id change) to be rolled back.
Hope, it's still possible.
This one will be the one for Daniel. Personally I didn't think
tracepoints count as ABI, if you consider they can start and stop making
sense just by the virtue of internal driver refactoring.
But as a quick Google search shows, there is some controversy on the
topic, even if it is still questionable for device drivers.
Also, could you not detect the i915 version somehow from VTune and adapt?
Regards,
Tvrtko
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Chris Wilson
Sent: Friday, January 15, 2016 1:09 AM
To: Tvrtko Ursulin
Cc: Daniel Vetter ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal
implementation
On Thu, Jan 14, 2016 at 03:02:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
At the moment execbuf ring selection is fully coupled to internal ring
ids which is not a good thing on its own.
This dependency is also spread between two source files and not
spelled out at either side which makes it hidden and fragile.
This patch decouples this dependency by introducing an explicit
translation table of execbuf uAPI to ring id close to the only call
site (i915_gem_do_execbuffer).
This way we are free to change driver internal implementation details
without breaking userspace. All state relating to the uAPI is now
contained in, or next to, i915_gem_do_execbuffer.
I was hesistant at first, since "why?" isn't fully developed, but the code won
me over.
+#define I915_USER_RINGS (4)
+
+static const enum intel_ring_id user_ring_map[I915_USER_RINGS + 1] = {
+ [I915_EXEC_DEFAULT] = RCS,
+ [I915_EXEC_RENDER] = RCS,
+ [I915_EXEC_BLT] = BCS,
+ [I915_EXEC_BSD] = VCS,
+ [I915_EXEC_VEBOX] = VECS
+};
I was wondering whether packing here mattered at all, but we're under a
cacheline so highly unlikely.
static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
@@ -1393,6 +1393,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_execbuffer_params params_master; /* XXX: will be removed
later */
struct i915_execbuffer_params *params = ¶ms_master;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
+ unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
u32 dispatch_flags;
int ret;
bool need_relocs;
@@ -1414,49 +1415,39 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
if (args->flags & I915_EXEC_IS_PINNED)
dispatch_flags |= I915_DISPATCH_PINNED;
- if ((args->flags & I915_EXEC_RING_MASK) > LAST_USER_RING) {
- DRM_DEBUG("execbuf with unknown ring: %d\n",
- (int)(args->flags & I915_EXEC_RING_MASK));
+ if (user_ring_id > I915_USER_RINGS) {
+ DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
return -EINVAL;
}
- if (((args->flags & I915_EXEC_RING_MASK) != I915_EXEC_BSD) &&
+ if ((user_ring_id != I915_EXEC_BSD) &&
((args->flags & I915_EXEC_BSD_MASK) != 0)) {
DRM_DEBUG("execbuf with non bsd ring but with invalid "
"bsd dispatch flags: %d\n", (int)(args->flags));
return -EINVAL;
- }
-
- if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_DEFAULT)
- ring = &dev_priv->ring[RCS];
- else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
- if (HAS_BSD2(dev)) {
- int ring_id;
-
- switch (args->flags & I915_EXEC_BSD_MASK) {
- case I915_EXEC_BSD_DEFAULT:
- ring_id = gen8_dispatch_bsd_ring(dev, file);
- ring = &dev_priv->ring[ring_id];
- break;
- case I915_EXEC_BSD_RING1:
- ring = &dev_priv->ring[VCS];
- break;
- case I915_EXEC_BSD_RING2:
- ring = &dev_priv->ring[VCS2];
- break;
- default:
- DRM_DEBUG("execbuf with unknown bsd ring: %d\n",
-
[Intel-gfx] [PATCH] drm/i915/shrinker: Refactor common uninterruptible locking
Both the oom and vmap notifier callbacks have a loop to acquire the
struct_mutex and set the device as uninterruptible, within a certain
time. Refactor the common code into a pair of functions.
Suggested-by: Joonas Lahtinen
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 79 +---
1 file changed, 42 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index be7501afb59e..39943793edcc 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -289,35 +289,56 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct
shrink_control *sc)
return freed;
}
+struct shrinker_lock_uninterruptible {
+ bool was_interruptible;
+ bool unlock;
+};
+
+static bool
+i915_gem_shrinker_lock_uninterruptible(struct drm_i915_private *dev_priv,
+ struct shrinker_lock_uninterruptible
*slu,
+ int timeout_ms)
+{
+ unsigned long timeout = msecs_to_jiffies(timeout_ms) + 1;
+
+ while (!i915_gem_shrinker_lock(dev_priv->dev, &slu->unlock)) {
+ schedule_timeout_killable(1);
+ if (fatal_signal_pending(current))
+ return false;
+ if (--timeout == 0) {
+ pr_err("Unable to lock GPU to purge memory.\n");
+ return false;
+ }
+ }
+
+ slu->was_interruptible = dev_priv->mm.interruptible;
+ dev_priv->mm.interruptible = false;
+ return true;
+}
+
+static void
+i915_gem_shrinker_unlock_uninterruptible(struct drm_i915_private *dev_priv,
+struct shrinker_lock_uninterruptible
*slu)
+{
+ dev_priv->mm.interruptible = slu->was_interruptible;
+ if (slu->unlock)
+ mutex_unlock(&dev_priv->dev->struct_mutex);
+}
+
static int
i915_gem_shrinker_oom(struct notifier_block *nb, unsigned long event, void
*ptr)
{
struct drm_i915_private *dev_priv =
container_of(nb, struct drm_i915_private, mm.oom_notifier);
- struct drm_device *dev = dev_priv->dev;
+ struct shrinker_lock_uninterruptible slu;
struct drm_i915_gem_object *obj;
- unsigned long timeout = msecs_to_jiffies(5000) + 1;
unsigned long pinned, bound, unbound, freed_pages;
- bool was_interruptible;
- bool unlock;
- while (!i915_gem_shrinker_lock(dev, &unlock) && --timeout) {
- schedule_timeout_killable(1);
- if (fatal_signal_pending(current))
- return NOTIFY_DONE;
- }
- if (timeout == 0) {
- pr_err("Unable to purge GPU memory due lock contention.\n");
+ if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, &slu, 5000))
return NOTIFY_DONE;
- }
-
- was_interruptible = dev_priv->mm.interruptible;
- dev_priv->mm.interruptible = false;
freed_pages = i915_gem_shrink_all(dev_priv);
- dev_priv->mm.interruptible = was_interruptible;
-
/* Because we may be allocating inside our own driver, we cannot
* assert that there are no objects with pinned pages that are not
* being pointed to by hardware.
@@ -342,8 +363,7 @@ i915_gem_shrinker_oom(struct notifier_block *nb, unsigned
long event, void *ptr)
bound += obj->base.size;
}
- if (unlock)
- mutex_unlock(&dev->struct_mutex);
+ i915_gem_shrinker_unlock_uninterruptible(dev_priv, &slu);
if (freed_pages || unbound || bound)
pr_info("Purging GPU memory, %lu bytes freed, %lu bytes still
pinned.\n",
@@ -362,30 +382,15 @@ i915_gem_shrinker_vmap(struct notifier_block *nb,
unsigned long event, void *ptr
{
struct drm_i915_private *dev_priv =
container_of(nb, struct drm_i915_private, mm.vmap_notifier);
- struct drm_device *dev = dev_priv->dev;
- unsigned long timeout = msecs_to_jiffies(5000) + 1;
+ struct shrinker_lock_uninterruptible slu;
unsigned long freed_pages;
- bool was_interruptible;
- bool unlock;
- while (!i915_gem_shrinker_lock(dev, &unlock) && --timeout) {
- schedule_timeout_killable(1);
- if (fatal_signal_pending(current))
- return NOTIFY_DONE;
- }
- if (timeout == 0) {
- pr_err("Unable to purge GPU vmaps due to lock contention.\n");
+ if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, &slu, 5000))
return NOTIFY_DONE;
- }
-
- was_interruptible = dev_priv->mm.interruptible;
- dev_priv->mm.interruptible = false;
freed_pages = i915_gem_shrink_all(dev_priv);
- dev_priv->mm.interruptible = was_interruptible;
-
Re: [Intel-gfx] [PATCH 06/16] drm/i915: Ensure intel_state->active_crtcs is always set
Op 01-04-16 om 03:46 schreef Matt Roper: > We currently only setup intel_state->active_crtcs if we plan to modify > it and write the modification back to dev_priv. Let's ensure that > this value is always valid, even when it isn't changing as part of an > atomic transaction. It should be noted that make a note that active_crtcs is not completely reliable when connection_mutex is not taken. A parallel modeset may change this value. That said, looks like patch 9/16 fixes this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/16] drm/i915/gen9: Make power well disabling synchronous
On ti, 2016-04-05 at 10:26 +0200, Patrik Jakobsson wrote:
> On Mon, Apr 04, 2016 at 12:34:30PM +0200, Patrik Jakobsson wrote:
> > On Fri, Apr 01, 2016 at 04:02:36PM +0300, Imre Deak wrote:
> > > So far we only power well enabling was synchronous not disabling.
> > > Since
> > > we don't exactly know how the firmware (both DMC and PCU)
> > > synchronizes
> > > against the actual power well state during DC transitions, make
> > > the
> > > disabling also synchronous.
> > >
> > > CC: Mika Kuoppala
> > > CC: Patrik Jakobsson
> > > Signed-off-by: Imre Deak
> >
> > Reviewed-by: Patrik Jakobsson
>
> Perhaps I was too quick with the review. I'm getting timeouts when
> trying to
> disable MISC IO and PW1 on SKL. Need to have a closer look at what's
> going on
> here.
The problem is the same that I fixed already on BXT in 04/16. The
firmware doesn't properly save/restore the request bits for these power
wells. It's an existing issue, so good that we found it. I'll follow up
with an updated version of patch 4 that addresses this on SKL as well.
--Imre
>
> -Patrik
>
> >
> > > ---
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
> > > 1 file changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index d20fd8f..f5f6e89 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -720,10 +720,6 @@ static void skl_set_power_well(struct
> > > drm_i915_private *dev_priv,
> > >
> > > if (!is_enabled) {
> > > DRM_DEBUG_KMS("Enabling %s\n",
> > > power_well->name);
> > > - if
> > > (wait_for((I915_READ(HSW_PWR_WELL_DRIVER) &
> > > - state_mask), 1))
> > > - DRM_ERROR("%s enable timeout\n",
> > > - power_well->name);
> > > check_fuse_status = true;
> > > }
> > > } else {
> > > @@ -737,6 +733,11 @@ static void skl_set_power_well(struct
> > > drm_i915_private *dev_priv,
> > > bxt_sanitize_power_well_requests(dev_pri
> > > v, power_well);
> > > }
> > >
> > > + if (wait_for(!!(I915_READ(HSW_PWR_WELL_DRIVER) &
> > > state_mask) == enable,
> > > + 1))
> > > + DRM_ERROR("%s %s timeout\n",
> > > + power_well->name, enable ? "enable" :
> > > "disable");
> > > +
> > > if (check_fuse_status) {
> > > if (power_well->data == SKL_DISP_PW_1) {
> > > if (wait_for((I915_READ(SKL_FUSE_STATUS)
> > > &
> > > --
> > > 2.5.0
> > >
> >
> > --
> > ---
> > Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40
> > Kista, Stockholm, Sweden Registration Number: 556189-6027
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/16] drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight state
Op 01-04-16 om 03:46 schreef Matt Roper:
> We eventually want to calculate watermark values at atomic 'check' time
> instead of atomic 'commit' time so that any requested configurations
> that result in impossible watermark requirements are properly rejected.
> The first step along this path is to allocate the DDB at atomic 'check'
> time. As we perform this transition, allow the main allocation function
> to operate successfully on either an in-flight state or an
> already-commited state. Once we complete the transition in a future
> patch, we'll come back and remove the unnecessary logic for the
> already-committed case.
>
> Note one other minor change here...when working with the
> already-committed state, we pull the active CRTC's from
> hweight(dev_priv->active_crtcs) instead of
> dev_priv->wm.config.num_pipes_active. The values should be equivalent,
> but dev_priv->wm.config is pretty much unused at this point and it would
> be nice to eventually remove it entirely.
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 +++
> drivers/gpu/drm/i915/intel_pm.c | 99
> ++---
> 2 files changed, 78 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d3ebb2f..79f1974 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -318,6 +318,12 @@ struct i915_hotplug {
> &dev->mode_config.plane_list, \
> base.head)
>
> +#define for_each_intel_plane_mask(dev, intel_plane, plane_mask)
> \
> + list_for_each_entry(intel_plane, &dev->mode_config.plane_list, \
> + base.head) \
> + for_each_if ((plane_mask) & \
> + (1 << drm_plane_index(&intel_plane->base)))
> +
> #define for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) \
> list_for_each_entry(intel_plane,\
> &(dev)->mode_config.plane_list, \
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index e92513e..e0ca2b9 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2849,15 +2849,15 @@ skl_wm_plane_id(const struct intel_plane *plane)
> static void
> skl_ddb_get_pipe_allocation_limits(struct drm_device *dev,
> const struct intel_crtc_state *cstate,
> -const struct intel_wm_config *config,
> +const unsigned active_crtcs,
> struct skl_ddb_entry *alloc /* out */)
> {
> - struct drm_crtc *for_crtc = cstate->base.crtc;
> - struct drm_crtc *crtc;
> + struct drm_crtc *crtc = cstate->base.crtc;
> unsigned int pipe_size, ddb_size;
> + unsigned int num_active = hweight32(active_crtcs);
> int nth_active_pipe;
>
> - if (!cstate->base.active) {
> + if (!cstate->base.active || WARN_ON(num_active == 0)) {
> alloc->start = 0;
> alloc->end = 0;
> return;
> @@ -2870,25 +2870,16 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> *dev,
>
> ddb_size -= 4; /* 4 blocks for bypass path allocation */
>
> - nth_active_pipe = 0;
> - for_each_crtc(dev, crtc) {
> - if (!to_intel_crtc(crtc)->active)
> - continue;
> + nth_active_pipe = hweight32(active_crtcs & (drm_crtc_mask(crtc) - 1));
>
> - if (crtc == for_crtc)
> - break;
> -
> - nth_active_pipe++;
> - }
> -
> - pipe_size = ddb_size / config->num_pipes_active;
> - alloc->start = nth_active_pipe * ddb_size / config->num_pipes_active;
> + pipe_size = ddb_size / num_active;
> + alloc->start = nth_active_pipe * ddb_size / num_active;
> alloc->end = alloc->start + pipe_size;
> }
>
> -static unsigned int skl_cursor_allocation(const struct intel_wm_config
> *config)
> +static unsigned int skl_cursor_allocation(const unsigned active_crtcs)
> {
> - if (config->num_pipes_active == 1)
> + if (hweight32(active_crtcs) == 1)
> return 32;
>
> return 8;
> @@ -3018,14 +3009,13 @@ skl_get_total_relative_data_rate(const struct
> intel_crtc_state *cstate)
> return total_data_rate;
> }
>
> -static void
> +static int
> skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
> struct skl_ddb_allocation *ddb /* out */)
> {
> struct drm_crtc *crtc = cstate->base.crtc;
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_wm_config *config = &dev_priv->wm.config;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> struct intel_plane *intel_plane;
> enum pipe pipe = intel_crtc->pipe;
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Simplify for_each_fw_domain iterators
On Tue, Apr 05, 2016 at 10:05:24AM +0100, Tvrtko Ursulin wrote:
> On 04/04/16 20:14, Dave Gordon wrote:
> >On 04/04/16 17:51, Tvrtko Ursulin wrote:
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index 7d4c704d7d75..160f980f0368 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>@@ -665,6 +665,7 @@ struct intel_uncore {
> >> struct intel_uncore_forcewake_domain {
> >> struct drm_i915_private *i915;
> >> enum forcewake_domain_id id;
> >>+enum forcewake_domains mask;
> >
> >At present this mask will always have only one bit set, but I suppose
> >there might be some utility in allowing multiple bits (virtual domains?)
>
> I did not like the name mask myself but couldn't think of anything
> better. Do you have a suggestion?
mask is fine as we use it as a mask. We've called it intel_engine_flag()
which is worse imo. If there is a much better name for this, we should
also fixup that name as well.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/16] drm/i915/gen9: Compute DDB allocation at atomic check time
Op 01-04-16 om 03:46 schreef Matt Roper:
> Calculate the DDB blocks needed to satisfy the current atomic
> transaction at atomic check time. This is a prerequisite to calculating
> SKL watermarks during the 'check' phase and rejecting any configurations
> that we can't find valid watermarks for.
>
> Due to the nature of DDB allocation, it's possible for the addition of a
> new CRTC to make the watermark configuration already in use on another,
> unchanged CRTC become invalid. A change in which CRTC's are active
> triggers a recompute of the entire DDB, which unfortunately means we
> need to disallow any other atomic commits from racing with such an
> update. If the active CRTC's change, we need to grab the lock on all
> CRTC's and run all CRTC's through their 'check' handler to recompute and
> re-check their per-CRTC DDB allocations.
>
> Note that with this patch we only compute the DDB allocation but we
> don't actually use the computed values during watermark programming yet.
> For ease of review/testing/bisecting, we still recompute the DDB at
> watermark programming time and just WARN() if it doesn't match the
> precomputed values. A future patch will switch over to using the
> precomputed values once we're sure they're being properly computed.
>
> Another clarifying note: DDB allocation itself shouldn't ever fail with
> the algorithm we use today (i.e., we have enough DDB blocks on BXT to
> support the minimum needs of the worst-case scenario of every pipe/plane
> enabled at full size). However the watermarks calculations based on the
> DDB may fail and we'll be moving those to the atomic check as well in
> future patches.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5
> drivers/gpu/drm/i915/intel_display.c | 18
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> drivers/gpu/drm/i915/intel_pm.c | 53
>
> 4 files changed, 79 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 79f1974..35cebd4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -333,6 +333,10 @@ struct i915_hotplug {
> #define for_each_intel_crtc(dev, intel_crtc) \
> list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
>
> +#define for_each_intel_crtc_mask(dev, intel_crtc, crtc_mask) \
> + list_for_each_entry(intel_crtc, &dev->mode_config.crtc_list, base.head)
> \
> + for_each_if ((crtc_mask) & (1 <<
> drm_crtc_index(&intel_crtc->base)))
> +
> #define for_each_intel_encoder(dev, intel_encoder) \
> list_for_each_entry(intel_encoder, \
> &(dev)->mode_config.encoder_list, \
> @@ -587,6 +591,7 @@ struct drm_i915_display_funcs {
> struct intel_crtc_state *newstate);
> void (*initial_watermarks)(struct intel_crtc_state *cstate);
> void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> + int (*compute_global_watermarks)(struct drm_atomic_state *state);
> void (*update_wm)(struct drm_crtc *crtc);
> int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index ab1fc3d..6bf2ede 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13230,6 +13230,7 @@ static int intel_modeset_checks(struct
> drm_atomic_state *state)
> static void calc_watermark_data(struct drm_atomic_state *state)
> {
> struct drm_device *dev = state->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> struct drm_crtc *crtc;
> struct drm_crtc_state *cstate;
> @@ -13259,6 +13260,10 @@ static void calc_watermark_data(struct
> drm_atomic_state *state)
> pstate->crtc_h != pstate->src_h >> 16)
> intel_state->wm_config.sprites_scaled = true;
> }
> +
> + /* Is there platform-specific watermark information to calculate? */
> + if (dev_priv->display.compute_global_watermarks)
> + dev_priv->display.compute_global_watermarks(state);
> }
>
> /**
> @@ -13631,6 +13636,19 @@ static int intel_atomic_commit(struct drm_device
> *dev,
> modeset_put_power_domains(dev_priv, put_domains[i]);
> }
>
> + /*
> + * Temporary sanity check: make sure our pre-computed DDB matches the
> + * one we actually wind up programming.
> + *
> + * Not a great place to put this, but the easiest place we have access
> + * to both the pre-computed and final DDB's; we'll be removing this
> + * check in the next patch anyway.
> + */
> + WARN(IS_GEN9(dev) &&
> + memcmp(&intel_
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Do not serialize forcewake acquire across domains
On Tue, Apr 05, 2016 at 10:02:28AM +0100, Tvrtko Ursulin wrote: > > On 04/04/16 20:07, Chris Wilson wrote: > >On Mon, Apr 04, 2016 at 05:51:11PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>On platforms with multiple forcewake domains it seems more efficient > >>to request all desired ones and then to wait for acks to avoid > >>needlessly serializing on each domain. > > > >Not convinced since we have more machines with one domain than two. What > >I did was to compact the domains array so that we only iterated over the > >known set - but that feels overkill when we only have two domains today. > > > >For the same reason (only one machine with two domains), I didn't think > >seperate functions to iterate over one domain and another to iterate > >over all was worth it. > > > >What you can do though is remove an excess posting read from > >fw_domains_put. > > > >Compared to the cost of a register access (the spinlock irq mostly) the > >iterator doesn't strike me as being that worthwhile an optimisation > >target. > > Correct, I thought we agreed that the majority of the CPU time > attributed to fw_domains_get is from the busy spinning while waiting > on the ack from the GPU. > > This patch is not optimising the iterator, but requests all domains > to be woken up and then waits for acks. It changes the time spent > busy spinning from Td1 + ... + Td2 to max(Td1...Tdn). > > Yes it is only interesting for platforms with more than one fw > domain. But since we agreed iterator is not significant, the fact > that it adds two loops* over the array should not be noticeable vs. > the gain for multi-fw domain machines (which will be more and more > of as time goes by). Then we should be first looking at the cases where we are requesting multiple domains to be woken where we only need one. Anyway you've changed my mind, Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Tolerance at BXT DSI pipe_config comparison
On Tuesday 05 April 2016 02:00 PM, Jani Nikula wrote: On Mon, 04 Apr 2016, Ramalingam C wrote: On Thursday 31 March 2016 12:34 AM, Daniel Vetter wrote: On Wed, Mar 30, 2016 at 07:49:40PM +0530, Ramalingam C wrote: On Wednesday 30 March 2016 05:02 PM, Daniel Vetter wrote: On Tue, Mar 29, 2016 at 11:04:51PM +0530, Ramalingam C wrote: At BXT DSI, PIPE registers are inactive. So we can't get the PIPE's mode parameters from them. The possible option is retriving them from the PORT registers. But mode timing parameters are progammed to port registers interms of byteclocks. The formula used to convert the pixels interms of byteclk is DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio, 8 * 100), lane_count); So we retrieve them, interms of pixels as DIV_ROUND_UP((clk_hs * lane_count * 8 * 100), (bpp * burst_mode_ratio)); Due to the multiple DIV_ROUND_UP in both formulas we get the worst case delta in the retrieved PIPE's timing parameter as below DIV_ROUND_UP((8 * intel_dsi->lane_count * 100), (dsi_pixel_format_bpp(intel_dsi->pixel_format) * intel_dsi->burst_mode_ratio))) This converson of byteclk to pixel is required for hsync, hfp and hbp. Which intern impacts horrizontal timing parameters. At worst case to get htotal all there parameters are added with hactive. Hence delta will be 3 times of above formula. Hence this value is considered as tolerance for pipe_config comparison, in case of BXT DSI. Signed-off-by: Ramalingam C This is the wrong way round imo, better would be to adjust the adjusted mode in the bxt dsi compute_config function to match the hw granularity. Stuff _really_ should match exactly, the fuzzy clock matching is mostly because our clock cod is a mess, and we can't/don't properly forward-compuate the actual clock timings we program into the hardware. -Daniel Daniel, I got your point. But the problem will be that difficulty(even if possible) in adjusting the adjusted mode parameters. Reason is we are not programing the mode parameter as such. We will derive the hfp, hsync and hbp from hsync_start, hsync_end, hdisplay and htotal. These will be adjusted(divided by 2) for dual link scenario. And then resultant will go into the conversion as mentioned in the commit message (two DIV_ROUND_UP onwards and one DIV_ROUND_UP backwards). For this we have to make the parameter divisible by three different factors. So IMHO, even if this is possible, it will look more messy. Predicting the max error and tolerating it in pipe_config_compare will be the straight forward and more reasonable. Please let me know if i can go ahead in this approach. Yeah I discussed this some more with Jani on irc. I'd say we should store this adjusted horizontal timings (the ones fudged with burst_mode_ratio, lane_count, dual-link and all these things applied) into crtc_state->base.adjusted_mode. And then ofc also read those values out. The overall idea of the state verify/compare logic is that we start out with requested state from userspace, then derive the real hw state. And then compare that computed hw state with what's there already. Except for clocks, where there's special reasons, we never go back, since going back requires us to apply a range. This is the only way to guarnatee that "hw has the same exact mode programmed in both cases" iff "intel_crtc_state matches per intel_crtc_config_compare". state->adjusted_mode is never exposed to userspace, so there's no problem if it's has "strange" values. And we already have pipe_src_h/w to express the logical input rectangle. The idea is similar to how we set adjusted_mode.flags to what we actually program, instead of trying to make something up that's not perfectly accurate. -Daniel Daniel, I have tested by adjusting the adjusted_mode in set_dsi_timings() instead of intel_dsi_compute_config(). Reason is if we modify the adjusted mode at intel_dsi_compute_config() itself, then modified value will be taken as input for set_dsi_timings. Hence the get_config will deviate further. I hope this should be fine with you and Jani. This will work out, if set_dsi_timings() is called after the dsi_compute_config() on every suspend and resume or modeset. I will verify this on Android once and update. Please share your view on this, so that can update the patch with corresponding changes. I can't speak for Daniel, but I think his point was to update adjusted mode in ->compute_config() in a way that can be used directly in set_dsi_timings(). Then, it should be possible to read the timings from the hardware, and compare. No, thats not possible jani. I think i didn't elaborate the problem statement enough. If you can read the programmed value from the hardware without any error, then there is no need for this patch itself. Even if we program the modified adjusted mode, timing parameters read from get_config
Re: [Intel-gfx] [PATCH 11/16] drm/i915/gen9: Allow watermark calculation on in-flight atomic state
Op 01-04-16 om 03:46 schreef Matt Roper:
> In an upcoming patch we'll move this calculation to the atomic 'check'
> phase so that the display update can be rejected early if no valid
> watermark programming is possible.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_drv.h | 21 +
> drivers/gpu/drm/i915/intel_pm.c | 31 +++
> 2 files changed, 40 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 483261c..6471f69 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1667,6 +1667,27 @@ intel_atomic_get_existing_plane_state(struct
> drm_atomic_state *state,
> return to_intel_plane_state(plane_state);
> }
>
> +/*
> + * If cstate is in-flight, return in-flight plane state, otherwise
> + * return committed plane state.
> + */
> +static inline struct intel_plane_state *
> +intel_pstate_for_cstate_plane(struct intel_crtc_state *cstate,
> + struct intel_plane *plane)
> +{
> + struct drm_atomic_state *state = cstate->base.state;
> + struct drm_plane_state *pstate;
> +
> + if (state == NULL)
> + return to_intel_plane_state(plane->base.state);
> +
> + pstate = drm_atomic_get_plane_state(state, &plane->base);
> +
> + return to_intel_plane_state(pstate);
> +}
> +
Don't create a helper please, this should only be done when transitioning code
situations.
plane->base.state might not be the right state when we support more than 1
pending atomic commit.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/skl: Disable underrun reporting on MST unplug
== Series Details == Series: drm/i915/skl: Disable underrun reporting on MST unplug URL : https://patchwork.freedesktop.org/series/5297/ State : success == Summary == Series 5297v1 drm/i915/skl: Disable underrun reporting on MST unplug http://patchwork.freedesktop.org/api/1.0/series/5297/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: incomplete -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Test kms_force_connector_basic: Subgroup force-connector-state: skip -> PASS (ilk-hp8440p) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: incomplete -> PASS (hsw-gt2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:131 dwarn:1 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1797/ 21c92ab3a682f958555fefb8da8657286ee62346 drm-intel-nightly: 2016y-04m-05d-08h-41m-28s UTC integration manifest a0d1b0d56d657111af53aeca5604240fef05af28 drm/i915/skl: Disable underrun reporting on MST unplug ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/shrinker: Refactor common uninterruptible locking
On ti, 2016-04-05 at 10:22 +0100, Chris Wilson wrote:
> Both the oom and vmap notifier callbacks have a loop to acquire the
> struct_mutex and set the device as uninterruptible, within a certain
> time. Refactor the common code into a pair of functions.
>
> Suggested-by: Joonas Lahtinen
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Looks good.
Reviewed-by: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 79
> +---
> 1 file changed, 42 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index be7501afb59e..39943793edcc 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -289,35 +289,56 @@ i915_gem_shrinker_scan(struct shrinker *shrinker,
> struct shrink_control *sc)
> return freed;
> }
>
> +struct shrinker_lock_uninterruptible {
> + bool was_interruptible;
> + bool unlock;
> +};
> +
> +static bool
> +i915_gem_shrinker_lock_uninterruptible(struct drm_i915_private *dev_priv,
> + struct shrinker_lock_uninterruptible
> *slu,
> + int timeout_ms)
> +{
> + unsigned long timeout = msecs_to_jiffies(timeout_ms) + 1;
> +
> + while (!i915_gem_shrinker_lock(dev_priv->dev, &slu->unlock)) {
> + schedule_timeout_killable(1);
> + if (fatal_signal_pending(current))
> + return false;
> + if (--timeout == 0) {
> + pr_err("Unable to lock GPU to purge memory.\n");
> + return false;
> + }
> + }
> +
> + slu->was_interruptible = dev_priv->mm.interruptible;
> + dev_priv->mm.interruptible = false;
> + return true;
> +}
> +
> +static void
> +i915_gem_shrinker_unlock_uninterruptible(struct drm_i915_private *dev_priv,
> + struct shrinker_lock_uninterruptible
> *slu)
> +{
> + dev_priv->mm.interruptible = slu->was_interruptible;
> + if (slu->unlock)
> + mutex_unlock(&dev_priv->dev->struct_mutex);
> +}
> +
> static int
> i915_gem_shrinker_oom(struct notifier_block *nb, unsigned long event, void
> *ptr)
> {
> struct drm_i915_private *dev_priv =
> container_of(nb, struct drm_i915_private, mm.oom_notifier);
> - struct drm_device *dev = dev_priv->dev;
> + struct shrinker_lock_uninterruptible slu;
> struct drm_i915_gem_object *obj;
> - unsigned long timeout = msecs_to_jiffies(5000) + 1;
> unsigned long pinned, bound, unbound, freed_pages;
> - bool was_interruptible;
> - bool unlock;
>
> - while (!i915_gem_shrinker_lock(dev, &unlock) && --timeout) {
> - schedule_timeout_killable(1);
> - if (fatal_signal_pending(current))
> - return NOTIFY_DONE;
> - }
> - if (timeout == 0) {
> - pr_err("Unable to purge GPU memory due lock contention.\n");
> + if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, &slu, 5000))
> return NOTIFY_DONE;
> - }
> -
> - was_interruptible = dev_priv->mm.interruptible;
> - dev_priv->mm.interruptible = false;
>
> freed_pages = i915_gem_shrink_all(dev_priv);
>
> - dev_priv->mm.interruptible = was_interruptible;
> -
> /* Because we may be allocating inside our own driver, we cannot
> * assert that there are no objects with pinned pages that are not
> * being pointed to by hardware.
> @@ -342,8 +363,7 @@ i915_gem_shrinker_oom(struct notifier_block *nb, unsigned
> long event, void *ptr)
> bound += obj->base.size;
> }
>
> - if (unlock)
> - mutex_unlock(&dev->struct_mutex);
> + i915_gem_shrinker_unlock_uninterruptible(dev_priv, &slu);
>
> if (freed_pages || unbound || bound)
> pr_info("Purging GPU memory, %lu bytes freed, %lu bytes still
> pinned.\n",
> @@ -362,30 +382,15 @@ i915_gem_shrinker_vmap(struct notifier_block *nb,
> unsigned long event, void *ptr
> {
> struct drm_i915_private *dev_priv =
> container_of(nb, struct drm_i915_private, mm.vmap_notifier);
> - struct drm_device *dev = dev_priv->dev;
> - unsigned long timeout = msecs_to_jiffies(5000) + 1;
> + struct shrinker_lock_uninterruptible slu;
> unsigned long freed_pages;
> - bool was_interruptible;
> - bool unlock;
>
> - while (!i915_gem_shrinker_lock(dev, &unlock) && --timeout) {
> - schedule_timeout_killable(1);
> - if (fatal_signal_pending(current))
> - return NOTIFY_DONE;
> - }
> - if (timeout == 0) {
> - pr_err("Unable to purge GPU vmaps due to lock contention.\n");
> + if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, &slu, 5000))
> return NOTIFY_DONE;
> - }
> -
> -
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
On 05/04/16 09:59, Chris Wilson wrote: On Tue, Apr 05, 2016 at 09:54:58AM +0100, Tvrtko Ursulin wrote: On 04/04/16 19:58, Chris Wilson wrote: On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Current implementation releases the forcewake at any time between straight away, and one jiffie from the last put, or first automatic grab. That isn't the problem though. The problem is that we set the timer on first use rather than last use. All you are stating here is that by lengthening the timeout on your system you reduce the number of times it times out. It is true the reduction I see is due lengthening of the average timeout. But with regards to re-arming approach, I thought so initially myself, but then, if we expect bursty access then it shouldn't matter and the simplicity of doing it like it currently is better. Even in practice, I noticed the effect of lengthening the timeout is much greater than moving the arming to the last access. And to get to very few to none auto releases on busy workloads we need in the regions of 5ms, which would be a big change. Or maybe not if you consider HZ=100 kernels. It is very difficult to know what is actually better considering power between the CPU and GPU and performance. So I though the best would be to keep it similar to the current timings, just fix the dependency on HZ and also slack with hrtimers might help with something. As a final data point, explicit puts and auto releases seems to be relatively balanced in my testing. With this patch T-Rex for example auto-releases in the region of 3-4 times in 10ms, with around 5-10 explicit gets, and 5-10 implicit gets in 10ms. A different, interrupt heavy workload (~20k irqs/sec) manages similarly 2-4 auto-releases per 10ms, and has ~250 explicit gets and ~380 implicit per 10ms. Looking at the two I think the fact they manage to auto-release relatively similarly, compared to a huge different in fw gets, suggest burstyness. So I am not sure that any smarts with the release period would be interesting. At least not without serious power/perf measurements. Having said that, the conversion to hrtimer seems sensible but to add tracking of the last access as opposed to first we either fallback to jiffie (in which case hrtimer is moot) or rely on ktime_get_raw() being fast enough for every register write. Hmm, my usual response to that has been if it matters we avoid the heavyweight macros and use the _FW interface - or even raw readl/writel. Could you try storing ktime_get_raw() on every access and rearming the timer if it expires before last-access + min-period? That would be similar to your patch from before my holiday, right? As I said above, I did not notice much change with that approach. Just extending the timeout has a much greater effect, but as I wrote above, I am not sure we want to change it. There was just one bug in that patch in checking the expiration that makes a huge difference, but if you please add the discussion above to the commit log that would be invaluable. I think I had a fixed version, would have to dig in branches now. I will add more text to the commit. Most importantly, do you think this would affect HZ=10 or HZ=250 kernels at all? Presumably if it could, someone would know today that there is a difference between the kernels based on HZ already? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/3] drm/i915/shrinker: Account for unshrinkable unbound pages (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915/shrinker: Account for unshrinkable unbound pages (rev2) URL : https://patchwork.freedesktop.org/series/5276/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igbvf/mbx.o LD drivers/net/ethernet/synopsys/built-in.o CC [M] drivers/net/ethernet/intel/igbvf/ethtool.o CC [M] drivers/net/ethernet/intel/igbvf/netdev.o CC drivers/video/fbdev/vesafb.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o CC [M] drivers/net/ethernet/intel/igb/e1000_82575.o CC [M] drivers/net/ethernet/intel/igb/e1000_mac.o CC drivers/video/fbdev/efifb.o CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M] drivers/net/ethernet/intel/igb/e1000_mbx.o CC [M] drivers/net/ethernet/intel/igb/e1000_phy.o LD drivers/video/fbdev/core/built-in.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o LD drivers/usb/host/xhci-hcd.o LD drivers/usb/host/built-in.o CC [M] drivers/net/ethernet/intel/igb/igb_ptp.o CC [M] drivers/net/ethernet/intel/igb/igb_hwmon.o LD drivers/usb/storage/usb-storage.o LD drivers/usb/storage/built-in.o LD drivers/usb/built-in.o LD drivers/video/fbdev/built-in.o LD drivers/video/built-in.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o Makefile:962: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/gen3_mixed_blits: Fix misleading indentation
gcc-6 provides a neat new warning that can spot some cases
of misleading indentation.
One such case was flagged in gen3_mixed_blits; this patch fixes it.
Signed-off-by: David Weinehall
---
tests/gen3_mixed_blits.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/gen3_mixed_blits.c b/tests/gen3_mixed_blits.c
index dce92b05a319..1159b4eb2e83 100644
--- a/tests/gen3_mixed_blits.c
+++ b/tests/gen3_mixed_blits.c
@@ -520,7 +520,7 @@ int main(int argc, char **argv)
while (src == dst)
dst = random() % count;
- copy(fd, handle[dst], tiling[dst], handle[src],
tiling[src]);
+ copy(fd, handle[dst], tiling[dst], handle[src], tiling[src]);
start_val[dst] = start_val[src];
}
igt_info("verifying..."); fflush(stdout);
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/16] drm/i915: Remove wm_config from dev_priv/intel_atomic_state
Op 01-04-16 om 03:46 schreef Matt Roper: > We calculate the watermark config into intel_atomic_state and then save > it into dev_priv, but never actually use it from there. This is > left-over from some early ILK-style watermark programming designs that > got changed over time. For patch 1-5, 7, and 12-16: Reviewed-by: Maarten Lankhorst Rest just needs to be reworked to zap pstate_for_cstate_plane and mentions of active_crtcs. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/16] drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR
DMC forces on power well 1 and the misc IO power well by setting the
corresponding request bits both in the BIOS and the DEBUG power well
request registers. This is somewhat unexpected since the firmware should
really just save and restore state but not alter it. We also depend on
being able to disable power well 1, and the misc IO power well before
entering S3/S4 on BXT and SKL or entering DC9 on BXT. To fix this make
sure these request bits are cleared whenever we want to disable the
given power wells.
On SKL there is another twist where the firmware also clears the power
well 1 request bit in HSW_POWER_WELL_DRIVER (but not that of the misc IO
power well). This happens to not cause a problem due to the forced-on
request bits in the other request registers.
I've filed a bug about all this, but fixing that may take a while and
having this sanity check in place makes sense even for future firmware
versions.
At the same time also check the KVMR request bits. I haven't seen this
being altered, but we don't expect any request bits in here either, so
sanitize this register as well.
v2:
- apply the workaround on SKL as well
CC: Patrik Jakobsson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index d189a00..6ffa6ad 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -630,6 +630,44 @@ void skl_disable_dc6(struct drm_i915_private *dev_priv)
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
}
+static void
+gen9_sanitize_power_well_requests(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ enum skl_disp_power_wells power_well_id = power_well->data;
+ u32 val;
+ u32 mask;
+
+ mask = SKL_POWER_WELL_REQ(power_well_id);
+
+ val = I915_READ(HSW_PWR_WELL_KVMR);
+ if (WARN_ONCE(val & mask, "Clearing unexpected KVMR request for %s\n",
+ power_well->name))
+ I915_WRITE(HSW_PWR_WELL_KVMR, val & ~mask);
+
+ val = I915_READ(HSW_PWR_WELL_BIOS);
+ val |= I915_READ(HSW_PWR_WELL_DEBUG);
+
+ if (!(val & mask))
+ return;
+
+ /*
+* DMC is known to force on the request bits for power well 1 on SKL
+* and BXT and the misc IO power well on SKL but we don't expect any
+* other request bits to be set, so WARN for those.
+*/
+ if (power_well_id == SKL_DISP_PW_1 ||
+ (IS_SKYLAKE(dev_priv) && power_well_id == SKL_DISP_PW_MISC_IO))
+ DRM_DEBUG_DRIVER("Clearing auxiliary requests for %s forced on "
+"by DMC\n", power_well->name);
+ else
+ WARN_ONCE(1, "Clearing unexpected auxiliary requests for %s\n",
+ power_well->name);
+
+ I915_WRITE(HSW_PWR_WELL_BIOS, val & ~mask);
+ I915_WRITE(HSW_PWR_WELL_DEBUG, val & ~mask);
+}
+
static void skl_set_power_well(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well, bool enable)
{
@@ -696,6 +734,9 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
POSTING_READ(HSW_PWR_WELL_DRIVER);
DRM_DEBUG_KMS("Disabling %s\n", power_well->name);
}
+
+ if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
+ gen9_sanitize_power_well_requests(dev_priv, power_well);
}
if (check_fuse_status) {
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.
On Tue, Apr 05, 2016 at 10:46:37AM +0200, Maarten Lankhorst wrote:
> Op 04-04-16 om 17:47 schreef Marius Vlad:
> > igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
> > set-up.
> >
> > Signed-off-by: Marius Vlad
> > ---
> > lib/igt_kms.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > index 82257a6..30c5b7e 100644
> > --- a/lib/igt_kms.c
> > +++ b/lib/igt_kms.c
> > @@ -1585,7 +1585,7 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
> > igt_output_t *output,
> > igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID,
> > fb_id);
> > }
> >
> > - if (plane->position_changed || plane->size_changed) {
> > + if ((plane->position_changed || plane->size_changed) && fb_id != 0) {
> > uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
> > uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
> > uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
> Why is this needed?
Because plane->fb is NULL when fb_id == 0. Maybe Ville had a point, not having
src_* in plane->fb.
>
> ~Maarten
signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
On Tue, Apr 05, 2016 at 11:02:15AM +0100, Tvrtko Ursulin wrote: > > On 05/04/16 09:59, Chris Wilson wrote: > >On Tue, Apr 05, 2016 at 09:54:58AM +0100, Tvrtko Ursulin wrote: > >> > >>On 04/04/16 19:58, Chris Wilson wrote: > >>>On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Current implementation releases the forcewake at any time between > straight away, and one jiffie from the last put, or first automatic > grab. > >>> > >>>That isn't the problem though. The problem is that we set the timer on > >>>first use rather than last use. All you are stating here is that by > >>>lengthening the timeout on your system you reduce the number of times it > >>>times out. > >> > >>It is true the reduction I see is due lengthening of the average timeout. > >> > >>But with regards to re-arming approach, I thought so initially > >>myself, but then, if we expect bursty access then it shouldn't > >>matter and the simplicity of doing it like it currently is better. > >> > >>Even in practice, I noticed the effect of lengthening the timeout is > >>much greater than moving the arming to the last access. And to get > >>to very few to none auto releases on busy workloads we need in the > >>regions of 5ms, which would be a big change. Or maybe not if you > >>consider HZ=100 kernels. > >> > >>It is very difficult to know what is actually better considering > >>power between the CPU and GPU and performance. So I though the best > >>would be to keep it similar to the current timings, just fix the > >>dependency on HZ and also slack with hrtimers might help with > >>something. > >> > >>As a final data point, explicit puts and auto releases seems to be > >>relatively balanced in my testing. With this patch T-Rex for example > >>auto-releases in the region of 3-4 times in 10ms, with around 5-10 > >>explicit gets, and 5-10 implicit gets in 10ms. > >> > >>A different, interrupt heavy workload (~20k irqs/sec) manages > >>similarly 2-4 auto-releases per 10ms, and has ~250 explicit gets and > >>~380 implicit per 10ms. > >> > >>Looking at the two I think the fact they manage to auto-release > >>relatively similarly, compared to a huge different in fw gets, > >>suggest burstyness. So I am not sure that any smarts with the > >>release period would be interesting. At least not without serious > >>power/perf measurements. > >> > >>>Having said that, the conversion to hrtimer seems sensible but to add > >>>tracking of the last access as opposed to first we either fallback to > >>>jiffie (in which case hrtimer is moot) or rely on ktime_get_raw() being > >>>fast enough for every register write. Hmm, my usual response to that has > >>>been if it matters we avoid the heavyweight macros and use the _FW > >>>interface - or even raw readl/writel. > >>> > >>>Could you try storing ktime_get_raw() on every access and rearming the > >>>timer if it expires before last-access + min-period? > >> > >>That would be similar to your patch from before my holiday, right? > >>As I said above, I did not notice much change with that approach. > >>Just extending the timeout has a much greater effect, but as I wrote > >>above, I am not sure we want to change it. > > > >There was just one bug in that patch in checking the expiration that > >makes a huge difference, but if you please add the discussion above to > >the commit log that would be invaluable. > > I think I had a fixed version, would have to dig in branches now. > > I will add more text to the commit. > > Most importantly, do you think this would affect HZ=10 or HZ=250 > kernels at all? Presumably if it could, someone would know today > that there is a difference between the kernels based on HZ already? Hmm, I switch quite regularly - that may explain why sometimes I see fw_domains_get quite heavy in the profiles and other. But I have never correlated that with changing .configs. And I don't keep stats for rc6 during stress tests - especially more notable is the lack of light desktop load testing. One interesting side-effect of htrimer is that iirc it is installed on the local cpu and isn't run until we hit a preemption point (i.e. the scheduler in my case) so for those who are running high latency low HZ are likely unaffected at all! As far as hrtimer is concerned, my only real worry is that if it is too expensive - but since it is being increasingly widely used I shouldn't worry myself too much about that (if it were to be a problem, it will get fixed!). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Reviving the LPSS PWM patches
On Tue, Apr 05, 2016 at 12:03:44PM +0530, Kumar, Shobhit wrote: > On Thursday 31 March 2016 03:57 PM, Lluís Batlle i Rossell wrote: > >Hello, > > > >I saw that you did some work for LPSS PWM: > >https://lists.freedesktop.org/archives/intel-gfx/2016-January/085006.html > > > > Apart from above apply the following as well - > https://patchwork.freedesktop.org/patch/70965/ > > This is just a Hack for quick testing. Try increasing the retry count if you > get pwm device not found error. Will have to work on a proper patch as > suggested by Daniel earlier. Had a working version which I need to send. > Definitely I was quite blind in my initial attempts at applying the patches, and gave me the idea that they did not apply in any recent tree. I've checked that they apply and build over the released 4.5, so I will go testing that, maybe today. I will report. I just did not use drm-intel-next because I also need another set of patches for a device unrelated to Intel, and these did not apply cleanly to drm-intel-next; I guess that released 4.5 will do. Thank you. -- (Escriu-me xifrat si saps PGP / Write ciphered if you know PGP) PGP key D4831A8A - https://emailselfdefense.fsf.org/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add a way to test the modeset done during gpu reset.
Add force_reset_modeset_test as a parameter to force the modeset path during
gpu reset.
This allows a IGT test to set the knob and trigger a hang to force the gpu
reset.
Signed-off-by: Maarten Lankhorst
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: drm-intel-fi...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_params.c | 6 ++
drivers/gpu/drm/i915/i915_params.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 161 ---
3 files changed, 116 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02e6df8..80ce581793dc 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -45,6 +45,7 @@ struct i915_params i915 __read_mostly = {
.fastboot = 0,
.prefault_disable = 0,
.load_detect_test = 0,
+ .force_reset_modeset_test = 0,
.reset = true,
.invert_brightness = 0,
.disable_display = 0,
@@ -158,6 +159,11 @@ MODULE_PARM_DESC(load_detect_test,
"Force-enable the VGA load detect code for testing (default:false). "
"For developers only.");
+module_param_named_unsafe(force_reset_modeset_test,
i915.force_reset_modeset_test, bool, 0600);
+MODULE_PARM_DESC(force_reset_modeset_test,
+ "Force a modeset during gpu reset for testing (default:false). "
+ "For developers only.");
+
module_param_named_unsafe(invert_brightness, i915.invert_brightness, int,
0600);
MODULE_PARM_DESC(invert_brightness,
"Invert backlight brightness "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 02bc27804291..3934c4300427 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -55,6 +55,7 @@ struct i915_params {
bool fastboot;
bool prefault_disable;
bool load_detect_test;
+ bool force_reset_modeset_test;
bool reset;
bool disable_display;
bool enable_guc_submission;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af74cdba7081..acca08797123 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3119,27 +3119,94 @@ static void intel_update_primary_planes(struct
drm_device *dev)
}
}
+static int
+__intel_display_resume(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ bool *setup)
+{
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc *crtc;
+ int i;
+
+ if (!setup || !*setup) {
+ if (setup)
+ *setup = true;
+
+ intel_modeset_setup_hw_state(dev);
+ i915_redisable_vga(dev);
+ }
+
+ if (!state)
+ return 0;
+
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
+ /*
+* Force recalculation even if we restore
+* current state. With fast modeset this may not result
+* in a modeset when the state is compatible.
+*/
+ crtc_state->mode_changed = true;
+ }
+
+ return drm_atomic_commit(state);
+}
+
void intel_prepare_reset(struct drm_device *dev)
{
+ bool requires_display_reset = true;
+ struct drm_atomic_state *state;
+ struct drm_modeset_acquire_ctx *pctx;
+ int ret;
+
/* no reset support for gen2 */
if (IS_GEN2(dev))
return;
/* reset doesn't touch the display */
- if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
- return;
+ if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev)) {
+ if (!i915.force_reset_modeset_test)
+ return;
+
+ requires_display_reset = false;
+ }
drm_modeset_lock_all(dev);
+ pctx = dev->mode_config.acquire_ctx;
+
/*
* Disabling the crtcs gracefully seems nicer. Also the
* g33 docs say we should at least disable all the planes.
*/
- intel_display_suspend(dev);
+
+ state = drm_atomic_helper_duplicate_state(dev, pctx);
+ if (IS_ERR(state)) {
+ ret = PTR_ERR(state);
+ state = NULL;
+ DRM_ERROR("Duplicating state failed with %i\n", ret);
+ goto err;
+ }
+
+ ret = drm_atomic_helper_disable_all(dev, pctx);
+ if (ret) {
+ DRM_ERROR("Suspending crtc's failed with %i\n", ret);
+ goto err;
+ }
+
+ to_i915(dev)->modeset_restore_state = state;
+ return;
+
+err:
+ drm_atomic_state_free(state);
+ if (!requires_display_reset)
+ drm_modeset_unlock_all(dev);
}
void intel_finish_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_atomic_state *state = dev_priv->modeset_resto
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix atomic plane commit when fb_id is 0.
Op 05-04-16 om 12:29 schreef Marius Vlad:
> On Tue, Apr 05, 2016 at 10:46:37AM +0200, Maarten Lankhorst wrote:
>> Op 04-04-16 om 17:47 schreef Marius Vlad:
>>> igt_atomic_prepare_plane_commit() assumes that the framebuffer is always
>>> set-up.
>>>
>>> Signed-off-by: Marius Vlad
>>> ---
>>> lib/igt_kms.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
>>> index 82257a6..30c5b7e 100644
>>> --- a/lib/igt_kms.c
>>> +++ b/lib/igt_kms.c
>>> @@ -1585,7 +1585,7 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
>>> igt_output_t *output,
>>> igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID,
>>> fb_id);
>>> }
>>>
>>> - if (plane->position_changed || plane->size_changed) {
>>> + if ((plane->position_changed || plane->size_changed) && fb_id != 0) {
>>> uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
>>> uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
>>> uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
>> Why is this needed?
> Because plane->fb is NULL when fb_id == 0. Maybe Ville had a point, not having
> src_* in plane->fb.
>
Indeed, it's a property of the plane, not the fb.
You could put the same fb on multiple planes with different src parameters. :)
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/shrinker: Refactor common uninterruptible locking
On Tue, Apr 05, 2016 at 01:02:14PM +0300, Joonas Lahtinen wrote: > On ti, 2016-04-05 at 10:22 +0100, Chris Wilson wrote: > > Both the oom and vmap notifier callbacks have a loop to acquire the > > struct_mutex and set the device as uninterruptible, within a certain > > time. Refactor the common code into a pair of functions. > > > > Suggested-by: Joonas Lahtinen > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Looks good. > > Reviewed-by: Joonas Lahtinen Thanks for all the review, pushed. Now on to stage 2. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] drv_hangman: Add test for modeset during gpu reset.
This adds a test that forces a modeset during gpu reset, which has broken a few times in the past during the atomic rework. Signed-off-by: Maarten Lankhorst https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: Do not serialize forcewake acquire across domains
From: Tvrtko Ursulin
On platforms with multiple forcewake domains it seems more efficient
to request all desired ones and then to wait for acks to avoid
needlessly serializing on each domain.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 5b9c307c5222..899cb71914c7 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -115,8 +115,10 @@ fw_domains_get(struct drm_i915_private *dev_priv, enum
forcewake_domains fw_doma
for_each_fw_domain_masked(d, fw_domains, dev_priv) {
fw_domain_wait_ack_clear(d);
fw_domain_get(d);
- fw_domain_wait_ack(d);
}
+
+ for_each_fw_domain_masked(d, fw_domains, dev_priv)
+ fw_domain_wait_ack(d);
}
static void
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Simplify for_each_fw_domain iterators
From: Tvrtko Ursulin
As the vast majority of users do not use the domain id variable,
we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.
For a couple of callers which do need the domain mask, store it
in the domain array (which already has the domain id), then both
can be retrieved thence.
Result is clearer code and smaller generated binary, especially
in the tight fw get/put loops. Also, relationship between domain
id and mask is no longer assumed in the macro.
v2: Improve grammar in the commit message and rename the
iterator to for_each_fw_domain_masked for consistency.
(Dave Gordon)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h | 17 +++---
drivers/gpu/drm/i915/intel_uncore.c | 45 +
3 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af02c292..06fce014d0b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1464,12 +1464,11 @@ static int i915_forcewake_domains(struct seq_file *m,
void *data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_uncore_forcewake_domain *fw_domain;
- int i;
spin_lock_irq(&dev_priv->uncore.lock);
- for_each_fw_domain(fw_domain, dev_priv, i) {
+ for_each_fw_domain(fw_domain, dev_priv) {
seq_printf(m, "%s.wake_count = %u\n",
- intel_uncore_forcewake_domain_to_str(i),
+ intel_uncore_forcewake_domain_to_str(fw_domain->id),
fw_domain->wake_count);
}
spin_unlock_irq(&dev_priv->uncore.lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d4c704d7d75..fff025071a0f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -665,6 +665,7 @@ struct intel_uncore {
struct intel_uncore_forcewake_domain {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
+ enum forcewake_domains mask;
unsigned wake_count;
struct hrtimer timer;
i915_reg_t reg_set;
@@ -679,14 +680,14 @@ struct intel_uncore {
};
/* Iterate over initialised fw domains */
-#define for_each_fw_domain_mask(domain__, mask__, dev_priv__, i__) \
- for ((i__) = 0, (domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
-(i__) < FW_DOMAIN_ID_COUNT; \
-(i__)++, (domain__) = &(dev_priv__)->uncore.fw_domain[i__]) \
- for_each_if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1
<< (i__)))
-
-#define for_each_fw_domain(domain__, dev_priv__, i__) \
- for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
+#define for_each_fw_domain_masked(domain__, mask__, dev_priv__) \
+ for ((domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
+(domain__) < &(dev_priv__)->uncore.fw_domain[FW_DOMAIN_ID_COUNT]; \
+(domain__)++) \
+ for_each_if ((mask__) & (domain__)->mask)
+
+#define for_each_fw_domain(domain__, dev_priv__) \
+ for_each_fw_domain_masked(domain__, FORCEWAKE_ALL, dev_priv__)
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
#define CSR_VERSION_MAJOR(version) ((version) >> 16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 76ac990de354..5b9c307c5222 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -111,9 +111,8 @@ static void
fw_domains_get(struct drm_i915_private *dev_priv, enum forcewake_domains
fw_domains)
{
struct intel_uncore_forcewake_domain *d;
- enum forcewake_domain_id id;
- for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
+ for_each_fw_domain_masked(d, fw_domains, dev_priv) {
fw_domain_wait_ack_clear(d);
fw_domain_get(d);
fw_domain_wait_ack(d);
@@ -124,9 +123,8 @@ static void
fw_domains_put(struct drm_i915_private *dev_priv, enum forcewake_domains
fw_domains)
{
struct intel_uncore_forcewake_domain *d;
- enum forcewake_domain_id id;
- for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
+ for_each_fw_domain_masked(d, fw_domains, dev_priv) {
fw_domain_put(d);
fw_domain_posting_read(d);
}
@@ -136,10 +134,9 @@ static void
fw_domains_posting_read(struct drm_i915_private *dev_priv)
{
struct intel_uncore_forcewake_domain *d;
- enum forcewake_domain_id id;
/* No need to do for all, just do for first found */
- for_each_fw_domain(d, dev_priv, i
[Intel-gfx] [PATCH v2 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
From: Tvrtko Ursulin
Because it is based on jiffies, current implementation releases the
forcewake at any time between straight away and between 1ms and 10ms,
depending on the kernel configuration (CONFIG_HZ).
This is probably not what has been desired, since the dynamics of keeping
parts of the GPU awake should not be correlated with this kernel
configuration parameter.
Change the auto-release mechanism to use hrtimers and set the timeout to
1ms with a 1ms of slack. This should make the GPU power consistent
across kernel configs, and timer slack should enable some timer coalescing
where multiple force-wake domains exist, or with unrelated timers.
For GlBench/T-Rex this decreases the number of forcewake releases from
~480 to ~300 per second, and for a heavy combined OGL/OCL test from
~670 to ~360 (HZ=1000 kernel).
Even though this reduction can be attributed to the average release period
extending from 0-1ms to 1-2ms, as discussed above, it will make the
forcewake timeout consistent for different CONFIG_HZ values.
Real life measurements with the above workload has shown that, with this
patch, both manage to auto-release the forcewake between 2-4 times per
10ms, even though the number of forcewake gets is dramatically different.
T-Rex requests between 5-10 explicit gets and 5-10 implict gets in each
10ms period, while the OGL/OCL test requests 250 and 380 times in the same
period.
The two data points together suggest that the nature of the forwake
accesses is bursty and that further changes and potential timeout
extensions, or moving the start of timeout from the first to the last
automatic forcewake grab, should be carefully measured for power and
performance effects.
v2:
* Commit spelling. (Dave Gordon)
* More discussion on numbers in the commit. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 25 -
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd187727c813..7d4c704d7d75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -666,7 +666,7 @@ struct intel_uncore {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
unsigned wake_count;
- struct timer_list timer;
+ struct hrtimer timer;
i915_reg_t reg_set;
u32 val_set;
u32 val_clear;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index ac1c545436af..76ac990de354 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,7 +60,11 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain
*d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
- mod_timer_pinned(&d->timer, jiffies + 1);
+ d->wake_count++;
+ hrtimer_start_range_ns(&d->timer,
+ ktime_set(0, NSEC_PER_MSEC),
+ NSEC_PER_MSEC,
+ HRTIMER_MODE_REL);
}
static inline void
@@ -224,9 +228,11 @@ static int __gen6_gt_wait_for_fifo(struct drm_i915_private
*dev_priv)
return ret;
}
-static void intel_uncore_fw_release_timer(unsigned long arg)
+static enum hrtimer_restart
+intel_uncore_fw_release_timer(struct hrtimer *timer)
{
- struct intel_uncore_forcewake_domain *domain = (void *)arg;
+ struct intel_uncore_forcewake_domain *domain =
+ container_of(timer, struct intel_uncore_forcewake_domain, timer);
unsigned long irqflags;
assert_rpm_device_not_suspended(domain->i915);
@@ -240,6 +246,8 @@ static void intel_uncore_fw_release_timer(unsigned long arg)
1 << domain->id);
spin_unlock_irqrestore(&domain->i915->uncore.lock, irqflags);
+
+ return HRTIMER_NORESTART;
}
void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore)
@@ -259,16 +267,16 @@ void intel_uncore_forcewake_reset(struct drm_device *dev,
bool restore)
active_domains = 0;
for_each_fw_domain(domain, dev_priv, id) {
- if (del_timer_sync(&domain->timer) == 0)
+ if (hrtimer_cancel(&domain->timer) == 0)
continue;
- intel_uncore_fw_release_timer((unsigned long)domain);
+ intel_uncore_fw_release_timer(&domain->timer);
}
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
for_each_fw_domain(domain, dev_priv, id) {
- if (timer_pending(&domain->timer))
+ if (hrtimer_active(&domain->timer))
active_dom
[Intel-gfx] [PATCH i-g-t] lib: kms: move framebuffer scanout offset/size to plane
This fixes potential crashes when the framebuffer is unset from a
given plane.
Signed-off-by: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Marius Vlad
Cc: Ville Syrjälä
---
lib/igt_fb.h | 4
lib/igt_kms.c | 32
lib/igt_kms.h | 8
3 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index e8fe3ac..0a06899 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -55,10 +55,6 @@ struct igt_fb {
unsigned size;
cairo_surface_t *cairo_surface;
unsigned domain;
- uint32_t src_x;
- uint32_t src_y;
- uint32_t src_w;
- uint32_t src_h;
};
enum igt_text_align {
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..b63a59d 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
igt_output_t *output,
}
if (plane->position_changed || plane->size_changed) {
- uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
- uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
- uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
- uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
+ uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
+ uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
+ uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
+ uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
int32_t crtc_x = plane->crtc_x;
int32_t crtc_y = plane->crtc_y;
uint32_t crtc_w = plane->crtc_w;
@@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
CHECK_RETURN(ret, fail_on_error);
} else if (plane->fb_changed || plane->position_changed ||
plane->size_changed) {
- src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
- src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
- src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
- src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
+ src_x = IGT_FIXED(plane->src_x,0); /* src_x */
+ src_y = IGT_FIXED(plane->src_y,0); /* src_y */
+ src_w = IGT_FIXED(plane->src_w,0); /* src_w */
+ src_h = IGT_FIXED(plane->src_h,0); /* src_h */
crtc_x = plane->crtc_x;
crtc_y = plane->crtc_y;
crtc_w = plane->crtc_w;
@@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb
*fb)
plane->crtc_h = fb->height;
/* set default src pos/size as fb size */
- fb->src_x = 0;
- fb->src_y = 0;
- fb->src_w = fb->width;
- fb->src_h = fb->height;
+ plane->src_x = 0;
+ plane->src_y = 0;
+ plane->src_w = fb->width;
+ plane->src_h = fb->height;
} else {
plane->crtc_w = 0;
plane->crtc_h = 0;
@@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb, igt_plane_t
*plane,
LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, x, y);
- fb->src_x = x;
- fb->src_y = y;
+ plane->src_x = x;
+ plane->src_y = y;
plane->fb_changed = true;
}
@@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t
*plane,
LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, w, h);
- fb->src_w = w;
- fb->src_h = h;
+ plane->src_w = w;
+ plane->src_h = h;
plane->fb_changed = true;
}
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8ae1192..aabe244 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -243,6 +243,14 @@ typedef struct {
int crtc_x, crtc_y;
/* size within pipe_src_w x pipe_src_h */
int crtc_w, crtc_h;
+
+ /* position with the framebuffer */
+ uint32_t src_x;
+ uint32_t src_y;
+ /* size within the framebuffer*/
+ uint32_t src_w;
+ uint32_t src_h;
+
/* panning offset within the fb */
unsigned int pan_x, pan_y;
igt_rotation_t rotation;
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
On Tue, Apr 05, 2016 at 12:01:10PM +0100, Tvrtko Ursulin wrote:
> for_each_fw_domain(domain, dev_priv, id) {
> - if (del_timer_sync(&domain->timer) == 0)
> + if (hrtimer_cancel(&domain->timer) == 0)
> continue;
Had to double check that this was consistent, 0 => not running, => 1
pending and so we need to manually release the timer.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: kms: move framebuffer scanout offset/size to plane
On Tue, Apr 05, 2016 at 12:11:19PM +0100, Lionel Landwerlin wrote:
> This fixes potential crashes when the framebuffer is unset from a
> given plane.
>
> Signed-off-by: Lionel Landwerlin
> Cc: Maarten Lankhorst
> Cc: Marius Vlad
> Cc: Ville Syrjälä
> ---
> lib/igt_fb.h | 4
> lib/igt_kms.c | 32
> lib/igt_kms.h | 8
> 3 files changed, 24 insertions(+), 20 deletions(-)
>
> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> index e8fe3ac..0a06899 100644
> --- a/lib/igt_fb.h
> +++ b/lib/igt_fb.h
> @@ -55,10 +55,6 @@ struct igt_fb {
> unsigned size;
> cairo_surface_t *cairo_surface;
> unsigned domain;
> - uint32_t src_x;
> - uint32_t src_y;
> - uint32_t src_w;
> - uint32_t src_h;
> };
>
> enum igt_text_align {
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 82257a6..b63a59d 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
> igt_output_t *output,
> }
>
> if (plane->position_changed || plane->size_changed) {
> - uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
> - uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
> - uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
> - uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
> + uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
> + uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
> + uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
> + uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
> int32_t crtc_x = plane->crtc_x;
> int32_t crtc_y = plane->crtc_y;
> uint32_t crtc_w = plane->crtc_w;
> @@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
> CHECK_RETURN(ret, fail_on_error);
> } else if (plane->fb_changed || plane->position_changed ||
> plane->size_changed) {
> - src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
> - src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
> - src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
> - src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
> + src_x = IGT_FIXED(plane->src_x,0); /* src_x */
> + src_y = IGT_FIXED(plane->src_y,0); /* src_y */
> + src_w = IGT_FIXED(plane->src_w,0); /* src_w */
> + src_h = IGT_FIXED(plane->src_h,0); /* src_h */
> crtc_x = plane->crtc_x;
> crtc_y = plane->crtc_y;
> crtc_w = plane->crtc_w;
> @@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct
> igt_fb *fb)
> plane->crtc_h = fb->height;
>
> /* set default src pos/size as fb size */
> - fb->src_x = 0;
> - fb->src_y = 0;
> - fb->src_w = fb->width;
> - fb->src_h = fb->height;
> + plane->src_x = 0;
> + plane->src_y = 0;
> + plane->src_w = fb->width;
> + plane->src_h = fb->height;
> } else {
> plane->crtc_w = 0;
> plane->crtc_h = 0;
> @@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb, igt_plane_t
> *plane,
> LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
> kmstest_pipe_name(pipe->pipe), plane->index, x, y);
>
> - fb->src_x = x;
> - fb->src_y = y;
> + plane->src_x = x;
> + plane->src_y = y;
>
> plane->fb_changed = true;
> }
> @@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t
> *plane,
> LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
> kmstest_pipe_name(pipe->pipe), plane->index, w, h);
>
> - fb->src_w = w;
> - fb->src_h = h;
> + plane->src_w = w;
> + plane->src_h = h;
>
> plane->fb_changed = true;
> }
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 8ae1192..aabe244 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -243,6 +243,14 @@ typedef struct {
> int crtc_x, crtc_y;
> /* size within pipe_src_w x pipe_src_h */
> int crtc_w, crtc_h;
> +
> + /* position with the framebuffer */
> + uint32_t src_x;
> + uint32_t src_y;
> + /* size within the framebuffer*/
> + uint32_t src_w;
> + uint32_t src_h;
Perhaps add a small note that these are 16.16
Patch looks good to me otherwise.
> +
> /* panning offset within the fb */
> unsigned int pan_x, pan_y;
> igt_rotation_t rotation;
> --
> 2.8.0.rc3
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GuC reset-and-retry patches (resend)
On 05/04/16 07:56, Patchwork wrote: == Series Details == Series: GuC reset-and-retry patches (resend) URL : https://patchwork.freedesktop.org/series/5287/ State : failure == Summary == Series 5287v1 GuC reset-and-retry patches (resend) http://patchwork.freedesktop.org/api/1.0/series/5287/revisions/1/mbox/ Test gem_ctx_switch: Subgroup basic-default: pass -> DMESG-WARN (skl-i7k-2) https://bugs.freedesktop.org/show_bug.cgi?id=93847 GuC is calling a sleeping function in atomic context Fix in progress (unrelated to the reset-and-retry patches) Test gem_sync: Subgroup basic-bsd: pass -> DMESG-FAIL (ilk-hp8440p) https://bugs.freedesktop.org/show_bug.cgi?id=94307 [BAT ILK] gem_sync/basic-bsd fails / hangcheck timer elapsed Unrelated; being investigated by Gabriel Feceoru Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE https://bugs.freedesktop.org/show_bug.cgi?id=93787 [BAT ILK] sporadic fifo underruns in igt@kms_flip@basic-flip-vs-* on ilk-hp8440p (edit) Unrelated Test kms_force_connector_basic: Subgroup prune-stale-modes: skip -> PASS (ilk-hp8440p) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) https://bugs.freedesktop.org/show_bug.cgi?id=94164 [BAT BYT/BSW] Runtime PM: *ERROR* Unclaimed access detected prior to suspending Unrelated bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:130 dwarn:1 dfail:1 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:172 dwarn:1 dfail:0 fail:0 skip:23 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1794/ aedfaaef290af9c8df7d9f4adf22cbe21704d091 drm-intel-nightly: 2016y-04m-04d-13h-09m-54s UTC integration manifest c7e3e58bc5509154a98e7c2fa1e433538f67c97a DO NOT MERGE: add enable_guc_loading parameter 87ce739817a1d65a3770c67d27560ea7377ad05e drm/i915/guc: always reset GuC before loading firmware 4f0836e699a720d8429de99f8d374e3a732a16f5 drm/i915/guc: reset GuC and retry on firmware load failure ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns
On 03/04/16 18:14, Chris Wilson wrote:
In order to ensure that all invalidations are completed before the
operation returns to userspace (i.e. before the mmap() syscall returns)
we need to flush the outstanding operations. To this end, we submit all
the per-object invalidation work to a private workqueue and then flush
the workqueue at the end of the function. We are allowed to block inside
invalidate_range_start, and struct_mutex is the inner lock so the worker
is not hiding any lock inversions. The advantage of using the workqueue
over direct calling of cancel_userptr() is that it allows us to
parallelise the potential waits and unpinning of large objects.
There was no direct calling, but running it from a shared wq which is
now private, per task->mm.
But it sounds so obvious now that the mmu notifier needs to wait for
cancel_userptr workers to complete that I wonder how we missed that
until now.
I would also spell out the two new bits explicitly in the commit:
waiting for workers and waiting on rendering.
With some more description for the latter - why it is needed?
i915_vma_unbind would be doing a flavour of waiting already.
Otherwise I did not find any issues with the code itself, just these
high level questions.
Regards,
Tvrtko
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699
Testcase: igt/gem_userptr_blits/sync-unmap-cycles
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 48 -
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 291a9393493d..92b39186b05a 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -49,6 +49,7 @@ struct i915_mmu_notifier {
struct hlist_node node;
struct mmu_notifier mn;
struct rb_root objects;
+ struct workqueue_struct *wq;
};
struct i915_mmu_object {
@@ -60,6 +61,40 @@ struct i915_mmu_object {
bool attached;
};
+static void wait_rendering(struct drm_i915_gem_object *obj)
+{
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
+ unsigned reset_counter;
+ int i, n;
+
+ if (!obj->active)
+ return;
+
+ n = 0;
+ for (i = 0; i < I915_NUM_ENGINES; i++) {
+ struct drm_i915_gem_request *req;
+
+ req = obj->last_read_req[i];
+ if (req == NULL)
+ continue;
+
+ requests[n++] = i915_gem_request_reference(req);
+ }
+
+ reset_counter = atomic_read(&to_i915(dev)->gpu_error.reset_counter);
+ mutex_unlock(&dev->struct_mutex);
+
+ for (i = 0; i < n; i++)
+ __i915_wait_request(requests[i], reset_counter, false,
+ NULL, NULL);
+
+ mutex_lock(&dev->struct_mutex);
+
+ for (i = 0; i < n; i++)
+ i915_gem_request_unreference(requests[i]);
+}
+
static void cancel_userptr(struct work_struct *work)
{
struct i915_mmu_object *mo = container_of(work, typeof(*mo), work);
@@ -75,6 +110,8 @@ static void cancel_userptr(struct work_struct *work)
struct i915_vma *vma, *tmp;
bool was_interruptible;
+ wait_rendering(obj);
+
was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;
@@ -140,7 +177,7 @@ static void
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
*/
mo = container_of(it, struct i915_mmu_object, it);
if (kref_get_unless_zero(&mo->obj->base.refcount))
- schedule_work(&mo->work);
+ queue_work(mn->wq, &mo->work);
list_add(&mo->link, &cancelled);
it = interval_tree_iter_next(it, start, end);
@@ -148,6 +185,8 @@ static void
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
list_for_each_entry(mo, &cancelled, link)
del_object(mo);
spin_unlock(&mn->lock);
+
+ flush_workqueue(mn->wq);
}
static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
@@ -167,10 +206,16 @@ i915_mmu_notifier_create(struct mm_struct *mm)
spin_lock_init(&mn->lock);
mn->mn.ops = &i915_gem_userptr_notifier;
mn->objects = RB_ROOT;
+ mn->wq = alloc_workqueue("i915-userptr-release", WQ_UNBOUND, 0);
+ if (mn->wq == NULL) {
+ kfree(mn);
+ return ERR_PTR(-ENOMEM);
+ }
/* Protected by mmap_sem (write-lock) */
ret = __mmu_notifier_register(&mn->mn, mm);
if (ret) {
+ destroy_workqueue(mn->wq);
kfree(mn);
return ERR_PTR(ret);
}
@@ -256,6 +301,7 @@ i915_mmu_notifier_fr
[Intel-gfx] [PATCH i-g-t] tools/intel_reg: Fix builtin register spec for gen4
From: Ville Syrjälä
Actually use the builtin register spec on gen4. Makes intel_reg dump
actually do something on gen4.
Signed-off-by: Ville Syrjälä
---
tools/intel_reg_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/intel_reg_decode.c b/tools/intel_reg_decode.c
index bb8f5b30311f..470fecc165c6 100644
--- a/tools/intel_reg_decode.c
+++ b/tools/intel_reg_decode.c
@@ -2580,7 +2580,7 @@ static bool is_945gm(uint32_t devid, uint32_t pch)
static bool is_gen234(uint32_t devid, uint32_t pch)
{
- return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN3(devid);
+ return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN4(devid);
}
#define DECLARE_REGS(d,r,m)\
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tools/intel_reg: Fix builtin register spec for gen4
Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: Fix/enable display power well support/runtime PM (rev5)
== Series Details == Series: drm/i915/bxt: Fix/enable display power well support/runtime PM (rev5) URL : https://patchwork.freedesktop.org/series/5177/ State : success == Summary == Series 5177v5 drm/i915/bxt: Fix/enable display power well support/runtime PM http://patchwork.freedesktop.org/api/1.0/series/5177/revisions/5/mbox/ Test core_auth: Subgroup basic-auth: incomplete -> PASS (bdw-nuci7) Test drv_getparams_basic: Subgroup basic-eu-total: incomplete -> PASS (bdw-nuci7) Test drv_module_reload_basic: fail -> PASS (snb-dellxps) skip -> PASS (skl-nuci5) Test gem_basic: Subgroup create-close: incomplete -> PASS (bdw-nuci7) Test gem_ctx_create: Subgroup basic: incomplete -> PASS (bdw-nuci7) Test gem_ctx_param_basic: Subgroup basic-default: incomplete -> PASS (bdw-nuci7) Subgroup invalid-ctx-get: incomplete -> PASS (bdw-nuci7) Subgroup invalid-ctx-set: incomplete -> PASS (bdw-nuci7) Test gem_exec_basic: Subgroup basic-blt: incomplete -> PASS (bdw-nuci7) Subgroup gtt-bsd1: incomplete -> PASS (bdw-nuci7) Subgroup readonly-bsd: incomplete -> PASS (bdw-nuci7) Test gem_exec_parse: Subgroup basic-rejected: incomplete -> SKIP (bdw-nuci7) Test gem_exec_store: Subgroup basic-render: incomplete -> PASS (bdw-nuci7) Test gem_exec_suspend: Subgroup basic-s4: fail -> SKIP (snb-dellxps) Test gem_mmap_gtt: Subgroup basic-read-no-prefault: incomplete -> PASS (bdw-nuci7) Subgroup basic-small-bo: incomplete -> PASS (bdw-nuci7) Subgroup basic-small-copy-xy: incomplete -> PASS (bdw-nuci7) Subgroup basic-write-gtt: incomplete -> PASS (bdw-nuci7) Test gem_render_linear_blits: Subgroup basic: incomplete -> PASS (bdw-nuci7) Test gem_ringfill: Subgroup basic-default-forked: incomplete -> PASS (bdw-nuci7) Test gem_storedw_loop: Subgroup basic-blt: incomplete -> PASS (bdw-nuci7) Subgroup basic-bsd2: incomplete -> PASS (bdw-nuci7) Subgroup basic-render: incomplete -> PASS (bdw-nuci7) UNSTABLE Test gem_sync: Subgroup basic-bsd1: incomplete -> PASS (bdw-nuci7) Subgroup basic-render: incomplete -> PASS (bdw-nuci7) UNSTABLE Subgroup basic-vebox: incomplete -> PASS (bdw-nuci7) Test kms_addfb_basic: Subgroup addfb25-x-tiled: incomplete -> PASS (bdw-nuci7) Subgroup addfb25-x-tiled-mismatch: incomplete -> PASS (bdw-nuci7) Subgroup bad-pitch-0: incomplete -> PASS (bdw-nuci7) Subgroup bo-too-small-due-to-tiling: incomplete -> PASS (bdw-nuci7) Subgroup unused-handle: incomplete -> PASS (bdw-nuci7) Subgroup unused-modifier: incomplete -> PASS (bdw-nuci7) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-wf_vblank: fail -> PASS (byt-nuc) Test kms_force_connector_basic: Subgroup force-edid: incomplete -> SKIP (bdw-nuci7) Subgroup force-load-detect: incomplete -> SKIP (bdw-nuci7) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: incomplete -> PASS (bdw-nuci7) Subgroup nonblocking-crc-pipe-b: incomplete -> PASS (bdw-nuci7) Subgroup read-crc-pipe-c-frame-sequence: incomplete -> PASS (bdw-nuci7) Test kms_setmode: Subgroup basic-clone-single-crtc: incomplete -> PASS (bdw-nuci7) Test kms_sink_crc_basic: incomplete -> SKIP (bdw-nuci7) Test pm_rpm: Subgroup basic-rte: incomplete -> PASS (bdw-nuci7) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 ilk-hp8440p total:196 pass:131 dwarn:1 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25
Re: [Intel-gfx] [PATCH 2/3] drm/i915/userptr: Hold mmref whilst calling get-user-pages
On 03/04/16 18:14, Chris Wilson wrote:
Holding a reference to the containing task_struct is not sufficient to
prevent the mm_struct from being reaped under memory pressure. If this
happens whilst we are calling get_user_pages(), explosions errupt -
sometimes an immediate GPF, sometimes page flag corruption. To prevent
the target mm from being reaped as we are reading from it, acquire a
reference before we begin.
Testcase: igt/gem_shrink/*userptr
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 92b39186b05a..960bb37f458f 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -547,19 +547,24 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
- down_read(&mm->mmap_sem);
- while (pinned < npages) {
- ret = get_user_pages_remote(work->task, mm,
- obj->userptr.ptr + pinned * PAGE_SIZE,
- npages - pinned,
- !obj->userptr.read_only, 0,
- pvec + pinned, NULL);
- if (ret < 0)
- break;
-
- pinned += ret;
+ ret = -EFAULT;
+ if (atomic_inc_not_zero(&mm->mm_users)) {
+ down_read(&mm->mmap_sem);
+ while (pinned < npages) {
+ ret = get_user_pages_remote
+ (work->task, mm,
+obj->userptr.ptr + pinned * PAGE_SIZE,
+npages - pinned,
+!obj->userptr.read_only, 0,
+pvec + pinned, NULL);
+ if (ret < 0)
+ break;
+
+ pinned += ret;
+ }
+ up_read(&mm->mmap_sem);
+ mmput(mm);
}
- up_read(&mm->mmap_sem);
}
mutex_lock(&dev->struct_mutex);
Strange, doesn't this mean that the atomic_inc(¤t->mm->mm_count)
is not doing what we thought it would?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for GuC reset-and-retry patches (resend)
On 05/04/16 13:03, Dave Gordon wrote: On 05/04/16 07:56, Patchwork wrote: == Series Details == Series: GuC reset-and-retry patches (resend) URL : https://patchwork.freedesktop.org/series/5287/ State : failure == Summary == Series 5287v1 GuC reset-and-retry patches (resend) http://patchwork.freedesktop.org/api/1.0/series/5287/revisions/1/mbox/ Test gem_ctx_switch: Subgroup basic-default: pass -> DMESG-WARN (skl-i7k-2) https://bugs.freedesktop.org/show_bug.cgi?id=93847 GuC is calling a sleeping function in atomic context Fix in progress (unrelated to the reset-and-retry patches) Test gem_sync: Subgroup basic-bsd: pass -> DMESG-FAIL (ilk-hp8440p) https://bugs.freedesktop.org/show_bug.cgi?id=94307 [BAT ILK] gem_sync/basic-bsd fails / hangcheck timer elapsed Unrelated; being investigated by Gabriel Feceoru Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE https://bugs.freedesktop.org/show_bug.cgi?id=93787 [BAT ILK] sporadic fifo underruns in igt@kms_flip@basic-flip-vs-* on ilk-hp8440p (edit) Unrelated Test kms_force_connector_basic: Subgroup prune-stale-modes: skip -> PASS (ilk-hp8440p) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) https://bugs.freedesktop.org/show_bug.cgi?id=94164 [BAT BYT/BSW] Runtime PM: *ERROR* Unclaimed access detected prior to suspending Unrelated bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:130 dwarn:1 dfail:1 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:172 dwarn:1 dfail:0 fail:0 skip:23 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1794/ aedfaaef290af9c8df7d9f4adf22cbe21704d091 drm-intel-nightly: 2016y-04m-04d-13h-09m-54s UTC integration manifest c7e3e58bc5509154a98e7c2fa1e433538f67c97a DO NOT MERGE: add enable_guc_loading parameter 87ce739817a1d65a3770c67d27560ea7377ad05e drm/i915/guc: always reset GuC before loading firmware 4f0836e699a720d8429de99f8d374e3a732a16f5 drm/i915/guc: reset GuC and retry on firmware load failure 1 and 2 merged, thanks for the patches and review! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns
On Tue, Apr 05, 2016 at 01:05:05PM +0100, Tvrtko Ursulin wrote: > > On 03/04/16 18:14, Chris Wilson wrote: > >In order to ensure that all invalidations are completed before the > >operation returns to userspace (i.e. before the mmap() syscall returns) > >we need to flush the outstanding operations. To this end, we submit all > >the per-object invalidation work to a private workqueue and then flush > >the workqueue at the end of the function. We are allowed to block inside > >invalidate_range_start, and struct_mutex is the inner lock so the worker > >is not hiding any lock inversions. The advantage of using the workqueue > >over direct calling of cancel_userptr() is that it allows us to > >parallelise the potential waits and unpinning of large objects. > > There was no direct calling, but running it from a shared wq which > is now private, per task->mm. I meant keep using a wq as opposed to changing the invalidate_range_begin to call cancel_userptr() directly. > But it sounds so obvious now that the mmu notifier needs to wait for > cancel_userptr workers to complete that I wonder how we missed that > until now. > > I would also spell out the two new bits explicitly in the commit: > waiting for workers and waiting on rendering. Ok, deleted a couple of attempts already. Will get a cup of tea and try and write something eloquent. > With some more description for the latter - why it is needed? > i915_vma_unbind would be doing a flavour of waiting already. It allows us to drop the lock whilst waiting for outstanding rendering, to try and prevent contention between munmap in one process and execbuf in another. Later on we can reduce the lock here further. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915/bxt: Added _DSM call to set HPD_CTL.
_DSM is added to program HPD_CTL(0x1094) register
of PMC from i915 driver which will be called
based on driver feature flag. PMC hpd control register
programming will enable PMC to get hpd interrupt
during dc9.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_acpi.c | 45 +--
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
index eb638a1..8f3d672 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -10,6 +10,8 @@
#define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
#define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
+#define INTEL_DSM_SET_HPD_WAKEUP 17
+#define HPD_WAKEUP_EN_VAL 0xFCF0
static struct intel_dsm_priv {
acpi_handle dhandle;
@@ -110,23 +112,52 @@ static void intel_dsm_platform_mux_info(void)
ACPI_FREE(pkg);
}
+static void intel_dsm_set_hpd_wakeup(void)
+{
+ union acpi_object *obj;
+ union acpi_object argv4 = {
+ .integer.type = ACPI_TYPE_INTEGER,
+ .integer.value = HPD_WAKEUP_EN_VAL,
+ };
+
+ obj = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, intel_dsm_guid,
+ INTEL_DSM_REVISION_ID, INTEL_DSM_SET_HPD_WAKEUP,
+ &argv4, ACPI_TYPE_INTEGER);
+
+ if (!obj)
+ DRM_DEBUG_DRIVER("failed to evaluate _DSM\n");
+
+ ACPI_FREE(obj);
+}
+
static bool intel_dsm_pci_probe(struct pci_dev *pdev)
{
acpi_handle dhandle;
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct drm_i915_private *dev_priv = dev->dev_private;
dhandle = ACPI_HANDLE(&pdev->dev);
- if (!dhandle)
- return false;
- if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
- 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
- DRM_DEBUG_KMS("no _DSM method for intel device\n");
+ if (!dhandle)
return false;
- }
intel_dsm_priv.dhandle = dhandle;
- intel_dsm_platform_mux_info();
+ if (acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
+ 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
+ intel_dsm_platform_mux_info();
+ else
+ DRM_DEBUG_KMS("no _DSM method for mux-info\n");
+
+ /* Need to ensure vbt parsing is completed. */
+ if (dev_priv->vbt.hpd_wakeup_enabled &&
+ acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
+ 1 << INTEL_DSM_SET_HPD_WAKEUP))
+ intel_dsm_set_hpd_wakeup();
+ else {
+ dev_priv->vbt.hpd_wakeup_enabled = false;
+ DRM_DEBUG_KMS("no _DSM method for hpd-enabling\n");
+ }
return true;
}
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: Enable HPD interrupts with master ctl interrupt
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get hotplug
interrupt as pcu_hpd_interrupt which will come via pmc. So
added the interrupt handling for pcu hpd interrupt.
Signed-off-by: Animesh Manna
Signed-off-by: A.Sunil Kamath
---
drivers/gpu/drm/i915/i915_irq.c | 56 ++---
drivers/gpu/drm/i915/i915_reg.h | 12 +
2 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c85eb8d..35d7423 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -110,9 +110,9 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
/* BXT hpd list */
static const u32 hpd_bxt[HPD_NUM_PINS] = {
- [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
- [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
- [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
+ [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
+ [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
+ [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)
};
/* IIR can theoretically queue up two events. Be paranoid. */
@@ -2337,6 +2337,22 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
DRM_ERROR("The master control interrupt lied (DE
PORT)!\n");
}
+ if (master_ctl & GEN8_PCU_IRQ) {
+ iir = I915_READ(GEN8_PCU_IIR);
+ if (iir) {
+ u32 tmp_mask;
+ I915_WRITE(GEN8_PCU_IIR, iir);
+ ret = IRQ_HANDLED;
+ if (IS_BROXTON(dev)) {
+ tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
+ if (tmp_mask)
+ bxt_hpd_irq_handler(dev, tmp_mask,
hpd_bxt);
+ } else
+ DRM_ERROR("Unexpected PCU interrupt\n");
+ } else
+ DRM_ERROR("The master control interrupt lied (PCU)!\n");
+ }
+
for_each_pipe(dev_priv, pipe) {
u32 flip_done, fault_errors;
@@ -4681,6 +4697,19 @@ void intel_irq_uninstall(struct drm_i915_private
*dev_priv)
dev_priv->pm.irqs_enabled = false;
}
+static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
+{
+ u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
+
+ de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
+ GEN9_DE_PCU_PORTB_HOTPLUG |
+ GEN9_DE_PCU_PORTC_HOTPLUG;
+
+ de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
+ de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);
+ GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
+}
+
/**
* intel_runtime_pm_disable_interrupts - runtime interrupt disabling
* @dev_priv: i915 device instance
@@ -4690,8 +4719,29 @@ void intel_irq_uninstall(struct drm_i915_private
*dev_priv)
*/
void intel_runtime_pm_disable_interrupts(struct drm_i915_private *dev_priv)
{
+ struct drm_device *dev = dev_priv->dev;
+ unsigned long flags = 0;
+
dev_priv->dev->driver->irq_uninstall(dev_priv->dev);
dev_priv->pm.irqs_enabled = false;
+
+ if (IS_BROXTON(dev) && dev_priv->vbt.hpd_wakeup_enabled) {
+
+ /* Enable HPD related interrupts during DC9 for HPD wakeup */
+
+ I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
+ POSTING_READ(GEN8_MASTER_IRQ);
+
+ spin_lock_irqsave(&dev_priv->irq_lock, flags);
+ if (dev_priv->display.hpd_irq_setup)
+ dev_priv->display.hpd_irq_setup(dev_priv->dev);
+ spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
+
+ bxt_enable_pcu_interrupt(dev_priv);
+
+ dev_priv->pm.irqs_enabled = true;
+ }
+
synchronize_irq(dev_priv->dev->irq);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cc42bd9..15f9021 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5954,6 +5954,18 @@ enum skl_disp_power_wells {
#define GEN8_PCU_IIR _MMIO(0x444e8)
#define GEN8_PCU_IER _MMIO(0x444ec)
+/* BXT PCU DC9 hotplug control */
+#define BXT_PCU_DC9_HP_DDIA(1<<31)
+#define BXT_PCU_DC9_HP_DDIB(1<<30)
+#define BXT_PCU_DC9_HP_DDIC(1<<29)
+#define BXT_PCU_DC9_HOTPLUG_MASK (BXT_PCU_DC9_HP_DDIA | \
+BXT_PCU_DC9_HP_DDIB | \
+BXT_PCU_DC9_HP_DDIC)
+
+#define GEN9_DE_PCU_PORTA_HOTPLUG (1 << 31)
+#define GEN9_DE_PCU_PORTB_HOTPLUG (1 << 30)
+#define GEN9_DE_
[Intel-gfx] [PATCH 1/6] drm/i915/bxt: VBT changes for hpd as wakeup feature
To support hpd during sleep a new feature flag is
added in vbt and also in dev_priv for enabling/disabling
inside deiver. By default this feature will be
diabled and based on oem request this feature can
be enabled by changing vbt feature flag.
Signed-off-by: Animesh Manna
Signed-off-by: A.Sunil Kamath
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd18772..445b80b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1429,6 +1429,11 @@ enum psr_lines_to_wait {
PSR_8_LINES_TO_WAIT
};
+enum hpd_wakeup_state {
+ DISABLE_HOT_PLUG_AS_WAKE_EVENT = 0,
+ ENABLE_HOT_PLUG_AS_WAKE_EVENT
+};
+
struct intel_vbt_data {
struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
@@ -1485,6 +1490,9 @@ struct intel_vbt_data {
const u8 *sequence[MIPI_SEQ_MAX];
} dsi;
+ /* HPD as wakesoure for DC9 BXT */
+ enum hpd_wakeup_state hpd_wakeup_enabled;
+
int crt_ddc_pin;
int child_dev_num;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 12f5103..cc42bd9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6119,6 +6119,7 @@ enum skl_disp_power_wells {
SDE_PORTB_HOTPLUG |\
SDE_PORTC_HOTPLUG |\
SDE_PORTD_HOTPLUG)
+
#define SDE_TRANSB_CRC_DONE(1 << 5)
#define SDE_TRANSB_CRC_ERR (1 << 4)
#define SDE_TRANSB_FIFO_UNDER (1 << 3)
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..8e2b765 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -547,7 +547,8 @@ struct bdb_driver_features {
u16 tbt_enabled:1;
u16 psr_enabled:1;
u16 ips_enabled:1;
- u16 reserved3:4;
+ u16 reserved3:3;
+ u16 hpd_wakeup_source:1;
u16 pc_feature_valid:1;
} __packed;
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915/bxt: Block D3 during suspend.
For BXT, display engine can not generate interrupt when in D3.
On the othen hand S0ix can be achieved without display in D3. So,
Display should not put into D3 for HPD to work and will not
have any power impact.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 020a31c..6b8c906 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1547,6 +1547,9 @@ static int intel_runtime_suspend(struct device *device)
assert_forcewakes_inactive(dev_priv);
+ if (dev_priv->vbt.hpd_wakeup_enabled)
+ pci_save_state(pdev);
+
DRM_DEBUG_KMS("Device suspended\n");
return 0;
}
@@ -1563,6 +1566,9 @@ static int intel_runtime_resume(struct device *device)
DRM_DEBUG_KMS("Resuming device\n");
+ if (dev_priv->vbt.hpd_wakeup_enabled)
+ pci_restore_state(pdev);
+
WARN_ON_ONCE(atomic_read(&dev_priv->pm.wakeref_count));
disable_rpm_wakeref_asserts(dev_priv);
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] HPD support during suspend.
Along with below patches sharing some background details/design. - On BXT, Display cannot generate an interrupt when in D3. - Without display in D3, S0ix can be achieved, Power impact will be zero if d3 is blocked. PMCSR for Graphics/Display is irrelevant, as the power management for them is taken care by the PUNIT using RC6/DC9 hints and *not* through PMCSR write trigger. So solution is based on below principles: - Display should not be put into D3 for HPD to work. - With D0+DC9 we can achieve S0ix and at the same time helps to get the interrupt. - Using pci_save_state() during suspend to take control from OSPM and blocking D3, while resuming, giving back to OSPM by pci_restore_state(). - _DSM method is used to program pmc hpd control register to enable hpd during suspend. Please have a look and send your comments/suggestions. Animesh Manna (6): drm/i915/bxt: VBT changes for hpd as wakeup feature drm/i915/bxt: Added _DSM call to set HPD_CTL. drm/i915/bxt: Corrected the guid for bxt. drm/i915/bxt: Block D3 during suspend. drm/i915: Enable HPD interrupts with master ctl interrupt drm/i915/bxt: Enable HPD during suspend. drivers/gpu/drm/i915/i915_drv.c | 6 drivers/gpu/drm/i915/i915_drv.h | 8 + drivers/gpu/drm/i915/i915_irq.c | 56 +-- drivers/gpu/drm/i915/i915_reg.h | 13 drivers/gpu/drm/i915/intel_acpi.c | 53 - drivers/gpu/drm/i915/intel_bios.c | 7 + drivers/gpu/drm/i915/intel_vbt_defs.h | 3 +- 7 files changed, 134 insertions(+), 12 deletions(-) -- 2.0.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Is Skylake graphics completely broken with multiple monitors?
2016-04-02 15:08 GMT+01:00 Oskar Berggren : > Hi, > > After trying two different machines I'm beginning to feel like Skylake is > completely unusable with multiple monitors connected. Is this a known > limitation? Am I the only one experiencing this? > > First I tested on laptop Dell XPS 15 9550 with QHD display. Seems to work > fine with internal panel, though I haven't used it extensively. Immediately > or sometimes within a minute or two when I connect an external monitor > using HDMI the system freezes completely (ping reply stops). This is with > updated Fedora 23 with kernel from drm-intel-nigthly tested several times > during the last two months. I've reported this here: > https://bugs.freedesktop.org/show_bug.cgi?id=94625 with more details. > > > Now I've also got access to a Dell Precision Tower 3620. Being a tower, > this of course has no internal panel. Connecting one external monitor seems > to work, but again I've not used it extensively. The second I connect a > second monitor it freezes completely. Booting with two monitors connected > also doesn't work. This is with updated Fedora 23 and distribution kernel > 4.4.6-300 (waiting for download/build of drm-intel-nigthly to finish). CPU > is i7-6700 stepping 3 microcode 0x74. > More testing: It turns out both systems are reasonably stable using Fedora's 4.4.6-300 kernel - on HDMI and DP _without _ MST. This is what caused the problem - my DELL U2415 monitor with DP 1.2 enabled causes stability issues, system freeezes, or is not detected at all, on 4.4.6 and drm-intel-nightly. HDMI or DP 1.1 seems to work. However, drm-intel-nightly from last night is still very unstable with HDMI on the laptop, and also with DP 1.1 for external monitors on the tower system. /Oskar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915/bxt: Enable HPD during suspend.
Based on vbt entry enabling i915 driver to act on
hpd support during suspend.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_bios.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 9c406b0..8ed084a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -529,6 +529,13 @@ parse_driver_features(struct drm_i915_private *dev_priv,
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->vbt.edp.support = 1;
+ if (driver->hpd_wakeup_source) {
+ dev_priv->vbt.hpd_wakeup_enabled =
+ ENABLE_HOT_PLUG_AS_WAKE_EVENT;
+ DRM_DEBUG_KMS("HPD as wakeup feature is enabled\n");
+ } else
+ DRM_DEBUG_KMS("HPD wakeup source feature is disabled in VBT\n");
+
DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
/*
* If DRRS is not supported, drrs_type has to be set to 0.
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/bxt: Corrected the guid for bxt.
Guid is changed for bxt platform, so corrected the guid for bxt.
Signed-off-by: Ananth Krishna R
Signed-off-by: Bharath K Veera
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_acpi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
index 8f3d672..79b774b 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -17,7 +17,7 @@ static struct intel_dsm_priv {
acpi_handle dhandle;
} intel_dsm_priv;
-static const u8 intel_dsm_guid[] = {
+static u8 intel_dsm_guid[] = {
0xd3, 0x73, 0xd8, 0x7e,
0xd0, 0xc2,
0x4f, 0x4e,
@@ -25,6 +25,9 @@ static const u8 intel_dsm_guid[] = {
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
};
+static u8 intel_bxt_dsm_guid[] __initdata =
+ "3E5B41C6-EB1D-4260-9D15-C71FBADAE414";
+
static char *intel_dsm_port_name(u8 id)
{
switch (id) {
@@ -143,6 +146,9 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
intel_dsm_priv.dhandle = dhandle;
+ if (IS_BROXTON(dev))
+ acpi_str_to_uuid(intel_bxt_dsm_guid, intel_dsm_guid);
+
if (acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
intel_dsm_platform_mux_info();
--
2.0.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] DPCD Backlight Control
These patches add support for Backlight Control using DPCD registers on eDP displays. - Patch 1 Reads the eDP DPCD Display Control capability registers. - Patch 2 Implements functionaly for DPCD Backlight Control Yetunde Adebisi (2): drm/i915: Add edp_dpcd variable drm/i915: Add Backlight Control using DPCD for eDP connectors (v9) drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_params.c| 4 + drivers/gpu/drm/i915/i915_params.h| 1 + drivers/gpu/drm/i915/intel_dp.c | 15 ++- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++ drivers/gpu/drm/i915/intel_drv.h | 4 + drivers/gpu/drm/i915/intel_panel.c| 4 + 7 files changed, 197 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Read eDP Display control capability registers
Add new edp_dpcd variable to intel_dp.
Read and save eDP Display control capability registers to edp_dpcd.
Signed-off-by: Yetunde Adebisi
---
drivers/gpu/drm/i915/intel_dp.c | 15 ++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..ad2c7d6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3777,7 +3777,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- uint8_t rev;
if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3834,6 +3833,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
}
+
+ /* Read the eDP Display control capabilities registers */
+ memset(intel_dp->edp_dpcd, 0, sizeof(intel_dp->edp_dpcd));
+ if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
+ (intel_dp_dpcd_read_wake(&intel_dp->aux,
DP_EDP_DPCD_REV,
+ intel_dp->edp_dpcd,
sizeof(intel_dp->edp_dpcd)) ==
+
sizeof(intel_dp->edp_dpcd)))
+ DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int)
sizeof(intel_dp->edp_dpcd),
+ intel_dp->edp_dpcd);
}
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
@@ -3841,10 +3849,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
/* Intermediate frequency support */
- if (is_edp(intel_dp) &&
- (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
- (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_EDP_DPCD_REV, &rev, 1)
== 1) &&
- (rev >= 0x03)) { /* eDp v1.4 or higher */
+ if (is_edp(intel_dp) && (intel_dp->edp_dpcd[0] >= 0x03)) { /* eDp v1.4
or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9255b56..b14e515 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -805,6 +805,7 @@ struct intel_dp {
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
+ uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
/* sink rates as reported by DP_SUPPORTED_LINK_RATES */
uint8_t num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd
v3: Correct some formatting mistakes
v4: Updated to use AUX backlight control if PWM control is not possible
(Jani)
v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
v7: Add enable_dpcd_backlight module parameter.
v8: Rebase onto latest drm-intel-nightly branch
v9: Remove changes to intel_dp_dpcd_read_wake
Split addition edp_dpcd variable into a separate patch
Cc: Bob Paauwe
Cc: Jani Nikula
Signed-off-by: Yetunde Adebisi
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_params.c| 4 +
drivers/gpu/drm/i915/i915_params.h| 1 +
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_panel.c| 4 +
6 files changed, 186 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..11cc3e6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ i915-y += dvo_ch7017.o \
dvo_tfp410.o \
intel_crt.o \
intel_ddi.o \
+ intel_dp_aux_backlight.o \
intel_dp_link_training.o \
intel_dp_mst.o \
intel_dp.o \
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..383c076 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -58,6 +58,7 @@ struct i915_params i915 __read_mostly = {
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
+ .enable_dpcd_backlight = false,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -210,3 +211,6 @@ MODULE_PARM_DESC(enable_dp_mst,
module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint,
0400);
MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
0600);
+MODULE_PARM_DESC(enable_dpcd_backlight,
+ "Enable support for DPCD backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..65e73dd 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -61,6 +61,7 @@ struct i915_params {
bool verbose_state_checks;
bool nuclear_pageflip;
bool enable_dp_mst;
+ bool enable_dpcd_backlight;
};
extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
new file mode 100644
index 000..984fb0d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -0,0 +1,173 @@
+/*
+ * 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 "intel_drv.h"
+
+static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+{
+ uint8_t reg_val = 0;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ ®_val) < 0) {
+ DRM_DEBUG
[Intel-gfx] [PATCH 1/2] drm/i915/skl: Fix rc6 based gpu/system hang
For all gt3 and gt4 skylake variants, extend the usage of
WaRsDisableCoarsePowerGating for all revisions. Without this
gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or
system hang.
Cc: Abdiel Janulgue
Cc: Ben Widawsky
Cc: Timo Aaltonen
Cc:
Reported-by: Mikael Djurfeldt
References: https://bugs.freedesktop.org/show_bug.cgi?id=94161
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 10480939159c..daba7ebb9699 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2634,8 +2634,9 @@ struct drm_i915_cmd_table {
/* WaRsDisableCoarsePowerGating:skl,bxt */
#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0,
BXT_REVID_A1) || \
-((IS_SKL_GT3(dev) ||
IS_SKL_GT4(dev)) && \
- IS_SKL_REVID(dev, 0,
SKL_REVID_F0)))
+IS_SKL_GT3(dev) || \
+IS_SKL_GT4(dev))
+
/*
* dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
* even when in MSI mode. This results in spurious interrupt warnings if the
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs
Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa)
suggest that WaForceContextSaveRestoreNonCoherent is needed for all
revs. Extending this to all revs cures a gpu hang with rev 0xa when
running heaven4.0 gpu benchmark.
We have been here before, with problems enabling gt4e and extending
up to revision F0 instead of false claims of bspec of E0 only. See
commit ("drm/i915/skl: Default to noncoherent access
up to F0"). In retrospect we should have covered this with this big
blanket back then already, as E0 vs F0 discrepancy was suspicious
enough.
Previously the WaForceEnableNonCoherent has been tied to
context non-coherence, atleast in relevant hsds. So keep this tie
and extended this alongside.
Cc: Abdiel Janulgue
Cc: Ben Widawsky
Cc: Timo Aaltonen
Cc: sta...@vger.kernel.org
Reported-by: Mike Lothian
References: https://bugs.freedesktop.org/show_bug.cgi?id=93491
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 45ce45a5e122..7fce1e6afcbc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -968,7 +968,7 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
/* WaForceContextSaveRestoreNonCoherent:skl,bxt */
tmp = HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT;
- if (IS_SKL_REVID(dev, SKL_REVID_F0, SKL_REVID_F0) ||
+ if (IS_SKL_REVID(dev, SKL_REVID_F0, REVID_FOREVER) ||
IS_BXT_REVID(dev, BXT_REVID_B0, REVID_FOREVER))
tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
@@ -1085,7 +1085,8 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
WA_SET_BIT_MASKED(HIZ_CHICKEN,
BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
- if (IS_SKL_REVID(dev, 0, SKL_REVID_F0)) {
+ /* This is tied to WaForceContextSaveRestoreNonCoherent */
+ if (IS_SKL_REVID(dev, 0, REVID_FOREVER)) {
/*
*Use Force Non-Coherent whenever executing a 3D context. This
* is a workaround for a possible hang in the unlikely event
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf
We only need the struct_mutex to manipulate the pages_pin_count on the
object, we do not need to hold our BKL when freeing the exported
scatterlist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 0506016e18e0..b7d46800c49f 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -95,14 +95,12 @@ static void i915_gem_unmap_dma_buf(struct
dma_buf_attachment *attachment,
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
- mutex_lock(&obj->base.dev->struct_mutex);
-
dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir);
sg_free_table(sg);
kfree(sg);
+ mutex_lock(&obj->base.dev->struct_mutex);
i915_gem_object_unpin_pages(obj);
-
mutex_unlock(&obj->base.dev->struct_mutex);
}
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_obj
After we pin the ringbuffer into the GGTT, all error paths need to unpin
it again. Move this common step into one block, and make the unable to
iomap error code consistent (i.e. treat it as out of memory to avoid
confusing it with a invalid argument).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2e864b7a528b..c6ae92529fdc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2121,15 +2121,13 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
return ret;
ret = i915_gem_object_set_to_cpu_domain(obj, true);
- if (ret) {
- i915_gem_object_ggtt_unpin(obj);
- return ret;
- }
+ if (ret)
+ goto err_unpin;
ringbuf->virtual_start = vmap_obj(obj);
if (ringbuf->virtual_start == NULL) {
- i915_gem_object_ggtt_unpin(obj);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_unpin;
}
} else {
ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
@@ -2137,10 +2135,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
return ret;
ret = i915_gem_object_set_to_gtt_domain(obj, true);
- if (ret) {
- i915_gem_object_ggtt_unpin(obj);
- return ret;
- }
+ if (ret)
+ goto err_unpin;
/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
@@ -2148,14 +2144,17 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
ringbuf->virtual_start = ioremap_wc(ggtt->mappable_base +
i915_gem_obj_ggtt_offset(obj), ringbuf->size);
if (ringbuf->virtual_start == NULL) {
- i915_gem_object_ggtt_unpin(obj);
- return -EINVAL;
+ ret = -ENOMEM;
+ goto err_unpin;
}
}
ringbuf->vma = i915_gem_obj_to_ggtt(obj);
-
return 0;
+
+err_unpin:
+ i915_gem_object_ggtt_unpin(obj);
+ return ret;
}
static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps
When called because we have run out of vmap address space, we only need to recover objects that have vmappings and not all. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 5fedb1b7d8d3..99e2cd3bb290 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3311,6 +3311,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv, #define I915_SHRINK_UNBOUND 0x2 #define I915_SHRINK_BOUND 0x4 #define I915_SHRINK_ACTIVE 0x8 +#define I915_SHRINK_VMAPS 0x10 unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv); void i915_gem_shrinker_init(struct drm_i915_private *dev_priv); void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c index 39943793edcc..56b4ec31d798 100644 --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c @@ -167,6 +167,10 @@ i915_gem_shrink(struct drm_i915_private *dev_priv, obj->madv != I915_MADV_DONTNEED) continue; + if (flags & I915_SHRINK_VMAPS && + obj->vmapping == NULL) + continue; + if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active) continue; @@ -388,7 +392,11 @@ i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned long event, void *ptr if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, &slu, 5000)) return NOTIFY_DONE; - freed_pages = i915_gem_shrink_all(dev_priv); + freed_pages = i915_gem_shrink(dev_priv, -1UL, + I915_SHRINK_BOUND | + I915_SHRINK_UNBOUND | + I915_SHRINK_ACTIVE | + I915_SHRINK_VMAPS); i915_gem_shrinker_unlock_uninterruptible(dev_priv, &slu); -- 2.8.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page
If we want a contiguous mapping of a single page sized object, we can
forgo using vmap() and just use a regular kmap(). Note that this is only
suitable if the desired pgprot_t is comptabitible.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 985f067c1f0e..dc8e1b76c896 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
list_del(&obj->global_list);
if (obj->vmapping) {
- vunmap(obj->vmapping);
+ if (obj->base.size == PAGE_SIZE)
+ kunmap(kmap_to_page(obj->vmapping));
+ else
+ vunmap(obj->vmapping);
obj->vmapping = NULL;
}
@@ -2416,15 +2419,22 @@ void *i915_gem_object_pin_vmap(struct
drm_i915_gem_object *obj)
i915_gem_object_pin_pages(obj);
if (obj->vmapping == NULL) {
- struct sg_page_iter sg_iter;
struct page **pages;
- int n;
- n = obj->base.size >> PAGE_SHIFT;
- pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
+ pages = NULL;
+ if (obj->base.size == PAGE_SIZE)
+ obj->vmapping = kmap(sg_page(obj->pages->sgl));
+ else
+ pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
+ sizeof(*pages),
+ GFP_TEMPORARY);
if (pages != NULL) {
+ struct sg_page_iter sg_iter;
+ int n;
+
n = 0;
- for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
+ for_each_sg_page(obj->pages->sgl, &sg_iter,
+obj->pages->nents, 0)
pages[n++] = sg_page_iter_page(&sg_iter);
obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Acked-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_gem.c| 4 +---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++--
drivers/gpu/drm/i915/i915_gem_userptr.c| 15 ---
include/drm/drm_mem_util.h | 19 +++
5 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index be4cf13343d5..985f067c1f0e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2421,9 +2421,7 @@ void *i915_gem_object_pin_vmap(struct drm_i915_gem_object
*obj)
int n;
n = obj->base.size >> PAGE_SHIFT;
- pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
- if (pages == NULL)
- pages = drm_malloc_ab(n, sizeof(*pages));
+ pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
if (pages != NULL) {
n = 0;
for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ee61fd014df..6ee4f00f620c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1783,11 +1783,9 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
}
- exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
-GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
- if (exec2_list == NULL)
- exec2_list = drm_malloc_ab(sizeof(*exec2_list),
- args->buffer_count);
+ exec2_list = drm_malloc_gfp(args->buffer_count,
+ sizeof(*exec2_list),
+ GFP_TEMPORARY);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
args->buffer_count);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ae9cb2735767..18f2bd7caad5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3413,8 +3413,9 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
int ret = -ENOMEM;
/* Allocate a temporary list of source pages for random access. */
- page_addr_list = drm_malloc_ab(obj->base.size / PAGE_SIZE,
- sizeof(dma_addr_t));
+ page_addr_list = drm_malloc_gfp(obj->base.size / PAGE_SIZE,
+ sizeof(dma_addr_t),
+ GFP_TEMPORARY);
if (!page_addr_list)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 291a9393493d..67883ebf9504 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -494,10 +494,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
ret = -ENOMEM;
pinned = 0;
- pvec = kmalloc(npages*sizeof(struct page *),
- GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
- if (pvec == NULL)
- pvec = drm_malloc_ab(npages, sizeof(struct page *));
+ pvec = drm_malloc_gfp(npages, sizeof(struct page *), GFP_TEMPORARY);
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
@@ -634,14 +631,10 @@ i915_gem_userptr_get_pages(struct drm_i915_gem_object
*obj)
pvec = NULL;
pinned = 0;
if (obj->userptr.mm->mm == current->mm) {
- pvec = kmalloc(num_pages*sizeof(struct page *),
- GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
+ pvec = drm_malloc_gfp(num_pages, sizeof(struct page *),
GFP_TEMPORARY);
if (pvec == NULL) {
- pvec = drm_malloc_ab(num_pages, sizeof(struct page *));
- if (pvec == NULL) {
- __i915_gem_userptr_set_active(obj, false);
- return -ENOMEM;
- }
+ __i915_gem_userptr_set_active(obj, false);
+ return -ENOMEM;
}
pinned = __get_user_pages_fast(obj->userptr.ptr, num_pages,
diff --git a/include/drm/drm_mem_util.h b/include/drm/drm_m
[Intel-gfx] vmap consolidation
We have a couple of pieces of code that wish to take further advantange of prolonged vmappings: execlists (ringbuffers), the cmdparser and the GuC (workqueues). This series refactors the whole-object vmapping code and caches it on the drm_i915_gem_object until it is released along with the object's pages (i.e. under memory pressure or at the end of the object's lifetime). This was stalled until we had a notifier in place from the mm/vmalloc for when we ran out of vmalloc arena (quite possible on 32bit machines which only reserve ~128MiB globally). This should unblock a couple of perf.orientated series, but doesn't offer any new features for itself. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: Refactor duplicate object vmap functions
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the vmapping into the
obj->pages lifetime, then we can reuse an obj->vmapping for both and at
the same time couple it into the shrinker.
v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala)
v3: Call unpin_vmap from the right dmabuf unmapper
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 12 +---
drivers/gpu/drm/i915/i915_gem.c | 45 ++
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 49 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 ++---
4 files changed, 60 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6443745d4182..5fedb1b7d8d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2167,10 +2167,7 @@ struct drm_i915_gem_object {
struct scatterlist *sg;
int last;
} get_page;
-
- /* prime dma-buf support */
- void *dma_buf_vmapping;
- int vmapping_count;
+ void *vmapping;
/** Breadcrumb of last rendering to the buffer.
* There can only be one writer, but we allow for multiple readers.
@@ -2985,12 +2982,19 @@ static inline void i915_gem_object_pin_pages(struct
drm_i915_gem_object *obj)
BUG_ON(obj->pages == NULL);
obj->pages_pin_count++;
}
+
static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
{
BUG_ON(obj->pages_pin_count == 0);
obj->pages_pin_count--;
}
+void *__must_check i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj);
+static inline void i915_gem_object_unpin_vmap(struct drm_i915_gem_object *obj)
+{
+ i915_gem_object_unpin_pages(obj);
+}
+
int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
int i915_gem_object_sync(struct drm_i915_gem_object *obj,
struct intel_engine_cs *to,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 40f90c7e718a..be4cf13343d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
* lists early. */
list_del(&obj->global_list);
+ if (obj->vmapping) {
+ vunmap(obj->vmapping);
+ obj->vmapping = NULL;
+ }
+
ops->put_pages(obj);
obj->pages = NULL;
@@ -2400,6 +2405,46 @@ i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
return 0;
}
+void *i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj)
+{
+ int ret;
+
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ return ERR_PTR(ret);
+
+ i915_gem_object_pin_pages(obj);
+
+ if (obj->vmapping == NULL) {
+ struct sg_page_iter sg_iter;
+ struct page **pages;
+ int n;
+
+ n = obj->base.size >> PAGE_SHIFT;
+ pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
+ if (pages == NULL)
+ pages = drm_malloc_ab(n, sizeof(*pages));
+ if (pages != NULL) {
+ n = 0;
+ for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
+ pages[n++] = sg_page_iter_page(&sg_iter);
+
+ obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
+ if (obj->vmapping == NULL) {
+ i915_gem_shrink_all(to_i915(obj->base.dev));
+ obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
+ }
+ drm_free_large(pages);
+ }
+ if (obj->vmapping == NULL) {
+ i915_gem_object_unpin_pages(obj);
+ return ERR_PTR(-ENOMEM);
+ }
+ }
+
+ return obj->vmapping;
+}
+
void i915_vma_move_to_active(struct i915_vma *vma,
struct drm_i915_gem_request *req)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index b7d46800c49f..8d8feadee18c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -108,51 +108,17 @@ static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
- struct sg_page_iter sg_iter;
- struct page **pages;
- int ret, i;
+ void *addr;
+ int ret;
ret = i915_mutex_lock_interruptible(dev);
if (ret)
return ERR_PTR(ret);
- if (obj->dma_buf_vmapping) {
- obj->vmapping_count++;
- goto out_unlock;
-
Re: [Intel-gfx] [PATCH 14/16] drm/i915/gen9: Calculate watermarks during atomic 'check'
On Thu, Mar 31, 2016 at 06:46:36PM -0700, Matt Roper wrote:
> Moving watermark calculation into the check phase will allow us to to
> reject display configurations for which there are no valid watermark
> values before we start trying to program the hardware (although those
> tests will come in a subsequent patch).
>
> Another advantage of moving this calculation to the check phase is that
> we can calculate the watermarks in a single shot as part of the atomic
> transaction. The watermark interfaces we inherited from our legacy
> modesetting days are a bit broken in the atomic design because they use
> per-crtc entry points but actually re-calculate and re-program something
> that is really more of a global state. That worked okay in the legacy
> modesetting world because operations only ever updated a single CRTC at
> a time. However in the atomic world, a transaction can involve multiple
> CRTC's, which means we wind up computing and programming the watermarks
> NxN times (where N is the number of CRTC's involved). With this patch
> we eliminate the redundant re-calculation of watermark data for atomic
> states (which was the cause of the WARN_ON(!wm_changed) problems that
> have plagued us for a while).
This one also fixes: https://bugs.freedesktop.org/show_bug.cgi?id=92181
>
> We still need to work on the 'commit' side of watermark handling so that
> we aren't doing redundant NxN programming of watermarks, but that's
> content for future patches.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 141
> +--
> 3 files changed, 55 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c514549..f1bea9f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13523,7 +13523,7 @@ static int intel_atomic_commit(struct drm_device *dev,
>
> drm_atomic_helper_swap_state(dev, state);
> dev_priv->wm.config = intel_state->wm_config;
> - dev_priv->wm.skl_results.ddb = intel_state->ddb;
> + dev_priv->wm.skl_results = intel_state->wm_results;
> intel_shared_dpll_commit(state);
>
> if (intel_state->modeset) {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 6471f69..3abd394 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -303,7 +303,7 @@ struct intel_atomic_state {
> bool skip_intermediate_wm;
>
> /* Gen9+ only */
> - struct skl_ddb_allocation ddb;
> + struct skl_wm_values wm_results;
> };
>
> struct intel_plane_state {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1bef89a..e4de5aa 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3187,23 +3187,6 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
> uint32_t pipe_htotal,
> return ret;
> }
>
> -static bool skl_ddb_allocation_changed(const struct skl_ddb_allocation
> *new_ddb,
> -const struct intel_crtc *intel_crtc)
> -{
> - struct drm_device *dev = intel_crtc->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - const struct skl_ddb_allocation *cur_ddb = &dev_priv->wm.skl_hw.ddb;
> -
> - /*
> - * If ddb allocation of pipes changed, it may require recalculation of
> - * watermarks
> - */
> - if (memcmp(new_ddb->pipe, cur_ddb->pipe, sizeof(new_ddb->pipe)))
> - return true;
> -
> - return false;
> -}
> -
> static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
> struct intel_crtc_state *cstate,
> struct intel_plane_state *intel_pstate,
> @@ -3654,72 +3637,16 @@ static int skl_update_pipe_wm(struct drm_crtc_state
> *cstate,
> else
> *changed = true;
>
> - intel_crtc->wm.active.skl = *pipe_wm;
> -
> return 0;
> }
>
> -static void skl_update_other_pipe_wm(struct drm_device *dev,
> - struct drm_crtc *crtc,
> - struct skl_wm_values *r)
> -{
> - struct intel_crtc *intel_crtc;
> - struct intel_crtc *this_crtc = to_intel_crtc(crtc);
> -
> - /*
> - * If the WM update hasn't changed the allocation for this_crtc (the
> - * crtc we are currently computing the new WM values for), other
> - * enabled crtcs will keep the same allocation and we don't need to
> - * recompute anything for them.
> - */
> - if (!skl_ddb_allocation_changed(&r->ddb, this_crtc))
> - return;
> -
> - /*
> - * Otherwise, because of this_crtc being freshly enabled/disabled, the
> - * other active pipes need new DDB allocation and
Re: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Fix rc6 based gpu/system hang
05.04.2016, 15:56, Mika Kuoppala kirjoitti: > For all gt3 and gt4 skylake variants, extend the usage of > WaRsDisableCoarsePowerGating for all revisions. Without this > gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or > system hang. > > Cc: Abdiel Janulgue > Cc: Ben Widawsky > Cc: Timo Aaltonen > Cc: > Reported-by: Mikael Djurfeldt > References: https://bugs.freedesktop.org/show_bug.cgi?id=94161 > Signed-off-by: Mika Kuoppala > --- thanks, with a big-n-loud Tested-by: Timo Aaltonen to both -- t ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page
On Tue, Apr 05, 2016 at 01:57:37PM +0100, Chris Wilson wrote: > If we want a contiguous mapping of a single page sized object, we can > forgo using vmap() and just use a regular kmap(). Note that this is only > suitable if the desired pgprot_t is comptabitible. One day, I will enable :set spell. Does anyone know if there is a .vim rule to detect git? Or something to stuff in git config core.editor ? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add a way to test the modeset done during gpu reset.
On Tue, Apr 05, 2016 at 12:56:37PM +0200, Maarten Lankhorst wrote:
> Add force_reset_modeset_test as a parameter to force the modeset path during
> gpu reset.
> This allows a IGT test to set the knob and trigger a hang to force the gpu
> reset.
>
> Signed-off-by: Maarten Lankhorst
> Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
> Cc: drm-intel-fi...@lists.freedesktop.org
Seems like this should be two patches; One to fix the locking and
another to add the debug knob.
> ---
> drivers/gpu/drm/i915/i915_params.c | 6 ++
> drivers/gpu/drm/i915/i915_params.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 161
> ---
> 3 files changed, 116 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 1779f02e6df8..80ce581793dc 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -45,6 +45,7 @@ struct i915_params i915 __read_mostly = {
> .fastboot = 0,
> .prefault_disable = 0,
> .load_detect_test = 0,
> + .force_reset_modeset_test = 0,
> .reset = true,
> .invert_brightness = 0,
> .disable_display = 0,
> @@ -158,6 +159,11 @@ MODULE_PARM_DESC(load_detect_test,
> "Force-enable the VGA load detect code for testing (default:false). "
> "For developers only.");
>
> +module_param_named_unsafe(force_reset_modeset_test,
> i915.force_reset_modeset_test, bool, 0600);
> +MODULE_PARM_DESC(force_reset_modeset_test,
> + "Force a modeset during gpu reset for testing (default:false). "
> + "For developers only.");
> +
> module_param_named_unsafe(invert_brightness, i915.invert_brightness, int,
> 0600);
> MODULE_PARM_DESC(invert_brightness,
> "Invert backlight brightness "
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 02bc27804291..3934c4300427 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -55,6 +55,7 @@ struct i915_params {
> bool fastboot;
> bool prefault_disable;
> bool load_detect_test;
> + bool force_reset_modeset_test;
> bool reset;
> bool disable_display;
> bool enable_guc_submission;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index af74cdba7081..acca08797123 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3119,27 +3119,94 @@ static void intel_update_primary_planes(struct
> drm_device *dev)
> }
> }
>
> +static int
> +__intel_display_resume(struct drm_device *dev,
> +struct drm_atomic_state *state,
> +bool *setup)
> +{
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
> +
> + if (!setup || !*setup) {
> + if (setup)
> + *setup = true;
> +
> + intel_modeset_setup_hw_state(dev);
> + i915_redisable_vga(dev);
> + }
> +
> + if (!state)
> + return 0;
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + /*
> + * Force recalculation even if we restore
> + * current state. With fast modeset this may not result
> + * in a modeset when the state is compatible.
> + */
> + crtc_state->mode_changed = true;
> + }
> +
> + return drm_atomic_commit(state);
> +}
> +
> void intel_prepare_reset(struct drm_device *dev)
> {
> + bool requires_display_reset = true;
> + struct drm_atomic_state *state;
> + struct drm_modeset_acquire_ctx *pctx;
> + int ret;
> +
> /* no reset support for gen2 */
> if (IS_GEN2(dev))
> return;
>
> /* reset doesn't touch the display */
> - if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
> - return;
> + if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev)) {
> + if (!i915.force_reset_modeset_test)
> + return;
> +
> + requires_display_reset = false;
Can't we just run the full code on g4x+ anyway? Would leave the code
much simpler.
> + }
>
> drm_modeset_lock_all(dev);
> + pctx = dev->mode_config.acquire_ctx;
pctx makes me think of power context.
> +
> /*
>* Disabling the crtcs gracefully seems nicer. Also the
>* g33 docs say we should at least disable all the planes.
>*/
> - intel_display_suspend(dev);
> +
> + state = drm_atomic_helper_duplicate_state(dev, pctx);
> + if (IS_ERR(state)) {
> + ret = PTR_ERR(state);
> + state = NULL;
> + DRM_ERROR("Duplicating state failed with %i\n", ret);
> + goto err;
> + }
> +
> + ret = drm_atomic_helper_disable_all(dev, pctx);
> + if (ret) {
> + DRM_ERROR("Suspending crtc's failed with %i\n",
Re: [Intel-gfx] [PATCH i-g-t] kms_atomic: Skip rather than fail on non-atomic drivers
Hi, On 4 April 2016 at 22:17, Matt Roper wrote: > i915 does not yet support the atomic modesetting interface by default; > at the moment it must be turned on explicitly via an > 'i915.nuclear_pageflip' kernel command line option. We should skip > (rather than fail) this IGT test when running on kernels that don't > advertise support for atomic modesetting. That was certainly the intention. Reviewed-by: Daniel Stone Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()
On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote:
> I have instances where I want to use drm_malloc_ab() but with a custom
> gfp mask. And with those, where I want a temporary allocation, I want to
> try a high-order kmalloc() before using a vmalloc().
>
> So refactor my usage into drm_malloc_gfp().
>
> Signed-off-by: Chris Wilson
> Cc: dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä
> Reviewed-by: Ville Syrjälä
> Acked-by: Dave Airlie
> +static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
> +{
> + if (size != 0 && nmemb > SIZE_MAX / size)
> + return NULL;
I know Dave G. has some fancy code to detect when the size parameter is
not constant, but one thing I noticed was that gcc would uninline this
function and we would lose the constant folding. Is there anything we
can do to convince gcc to avoid a div here (other than pure macro)?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: kms: move framebuffer scanout offset/size to plane
On 05/04/16 12:48, Ville Syrjälä wrote:
On Tue, Apr 05, 2016 at 12:11:19PM +0100, Lionel Landwerlin wrote:
This fixes potential crashes when the framebuffer is unset from a
given plane.
Signed-off-by: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Marius Vlad
Cc: Ville Syrjälä
---
lib/igt_fb.h | 4
lib/igt_kms.c | 32
lib/igt_kms.h | 8
3 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index e8fe3ac..0a06899 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -55,10 +55,6 @@ struct igt_fb {
unsigned size;
cairo_surface_t *cairo_surface;
unsigned domain;
- uint32_t src_x;
- uint32_t src_y;
- uint32_t src_w;
- uint32_t src_h;
};
enum igt_text_align {
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..b63a59d 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
igt_output_t *output,
}
if (plane->position_changed || plane->size_changed) {
- uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
- uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
- uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
- uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
+ uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
+ uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
+ uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
+ uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
int32_t crtc_x = plane->crtc_x;
int32_t crtc_y = plane->crtc_y;
uint32_t crtc_w = plane->crtc_w;
@@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
CHECK_RETURN(ret, fail_on_error);
} else if (plane->fb_changed || plane->position_changed ||
plane->size_changed) {
- src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
- src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
- src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
- src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
+ src_x = IGT_FIXED(plane->src_x,0); /* src_x */
+ src_y = IGT_FIXED(plane->src_y,0); /* src_y */
+ src_w = IGT_FIXED(plane->src_w,0); /* src_w */
+ src_h = IGT_FIXED(plane->src_h,0); /* src_h */
crtc_x = plane->crtc_x;
crtc_y = plane->crtc_y;
crtc_w = plane->crtc_w;
@@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb
*fb)
plane->crtc_h = fb->height;
/* set default src pos/size as fb size */
- fb->src_x = 0;
- fb->src_y = 0;
- fb->src_w = fb->width;
- fb->src_h = fb->height;
+ plane->src_x = 0;
+ plane->src_y = 0;
+ plane->src_w = fb->width;
+ plane->src_h = fb->height;
} else {
plane->crtc_w = 0;
plane->crtc_h = 0;
@@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb, igt_plane_t
*plane,
LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, x, y);
- fb->src_x = x;
- fb->src_y = y;
+ plane->src_x = x;
+ plane->src_y = y;
plane->fb_changed = true;
}
@@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t
*plane,
LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, w, h);
- fb->src_w = w;
- fb->src_h = h;
+ plane->src_w = w;
+ plane->src_h = h;
plane->fb_changed = true;
}
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8ae1192..aabe244 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -243,6 +243,14 @@ typedef struct {
int crtc_x, crtc_y;
/* size within pipe_src_w x pipe_src_h */
int crtc_w, crtc_h;
+
+ /* position with the framebuffer */
+ uint32_t src_x;
+ uint32_t src_y;
+ /* size within the framebuffer*/
+ uint32_t src_w;
+ uint32_t src_h;
Perhaps add a small note that these are 16.16
Patch looks good to me otherwise.
I think we convert them to 16.16 at commit time.
The values stored there should be normal integers.
+
/* panning offset within the fb */
unsigned int pan_x, pan_y;
igt_rotation_t rotation;
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page
I use :autocmd FileType gitcommit setlocal spell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: kms: move framebuffer scanout offset/size to plane
This fixes potential crashes when the framebuffer is unset from a
given plane.
v2: s/with/within/ typo in header
Signed-off-by: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Marius Vlad
Cc: Ville Syrjälä
---
lib/igt_fb.h | 4
lib/igt_kms.c | 32
lib/igt_kms.h | 8
3 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index e8fe3ac..0a06899 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -55,10 +55,6 @@ struct igt_fb {
unsigned size;
cairo_surface_t *cairo_surface;
unsigned domain;
- uint32_t src_x;
- uint32_t src_y;
- uint32_t src_w;
- uint32_t src_h;
};
enum igt_text_align {
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 82257a6..b63a59d 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
igt_output_t *output,
}
if (plane->position_changed || plane->size_changed) {
- uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
- uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
- uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
- uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
+ uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
+ uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
+ uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
+ uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
int32_t crtc_x = plane->crtc_x;
int32_t crtc_y = plane->crtc_y;
uint32_t crtc_w = plane->crtc_w;
@@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
CHECK_RETURN(ret, fail_on_error);
} else if (plane->fb_changed || plane->position_changed ||
plane->size_changed) {
- src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
- src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
- src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
- src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
+ src_x = IGT_FIXED(plane->src_x,0); /* src_x */
+ src_y = IGT_FIXED(plane->src_y,0); /* src_y */
+ src_w = IGT_FIXED(plane->src_w,0); /* src_w */
+ src_h = IGT_FIXED(plane->src_h,0); /* src_h */
crtc_x = plane->crtc_x;
crtc_y = plane->crtc_y;
crtc_w = plane->crtc_w;
@@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb
*fb)
plane->crtc_h = fb->height;
/* set default src pos/size as fb size */
- fb->src_x = 0;
- fb->src_y = 0;
- fb->src_w = fb->width;
- fb->src_h = fb->height;
+ plane->src_x = 0;
+ plane->src_y = 0;
+ plane->src_w = fb->width;
+ plane->src_h = fb->height;
} else {
plane->crtc_w = 0;
plane->crtc_h = 0;
@@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb, igt_plane_t
*plane,
LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, x, y);
- fb->src_x = x;
- fb->src_y = y;
+ plane->src_x = x;
+ plane->src_y = y;
plane->fb_changed = true;
}
@@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t
*plane,
LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
kmstest_pipe_name(pipe->pipe), plane->index, w, h);
- fb->src_w = w;
- fb->src_h = h;
+ plane->src_w = w;
+ plane->src_h = h;
plane->fb_changed = true;
}
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 8ae1192..b763120 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -243,6 +243,14 @@ typedef struct {
int crtc_x, crtc_y;
/* size within pipe_src_w x pipe_src_h */
int crtc_w, crtc_h;
+
+ /* position within the framebuffer */
+ uint32_t src_x;
+ uint32_t src_y;
+ /* size within the framebuffer*/
+ uint32_t src_w;
+ uint32_t src_h;
+
/* panning offset within the fb */
unsigned int pan_x, pan_y;
igt_rotation_t rotation;
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Read eDP Display control capability registers
Hi Yetunde, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.6-rc2 next-20160405] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Yetunde-Adebisi/DPCD-Backlight-Control/20160405-204039 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x010-201614 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/i915_trace.h:10:0, from drivers/gpu/drm/i915/i915_drv.h:2719, from drivers/gpu/drm/i915/i915_drv.c:34: >> drivers/gpu/drm/i915/intel_drv.h:808:19: error: 'EDP_DISPLAY_CTL_CAP_SIZE' >> undeclared here (not in a function) uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; ^ vim +/EDP_DISPLAY_CTL_CAP_SIZE +808 drivers/gpu/drm/i915/intel_drv.h 802 enum hdmi_force_audio force_audio; 803 bool limited_color_range; 804 bool color_range_auto; 805 uint8_t dpcd[DP_RECEIVER_CAP_SIZE]; 806 uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE]; 807 uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS]; > 808 uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; 809 /* sink rates as reported by DP_SUPPORTED_LINK_RATES */ 810 uint8_t num_sink_rates; 811 int sink_rates[DP_MAX_SUPPORTED_RATES]; --- 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 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib: kms: move framebuffer scanout offset/size to plane
On Tue, Apr 05, 2016 at 02:12:43PM +0100, Lionel Landwerlin wrote:
> On 05/04/16 12:48, Ville Syrjälä wrote:
> > On Tue, Apr 05, 2016 at 12:11:19PM +0100, Lionel Landwerlin wrote:
> >> This fixes potential crashes when the framebuffer is unset from a
> >> given plane.
> >>
> >> Signed-off-by: Lionel Landwerlin
> >> Cc: Maarten Lankhorst
> >> Cc: Marius Vlad
> >> Cc: Ville Syrjälä
> >> ---
> >> lib/igt_fb.h | 4
> >> lib/igt_kms.c | 32
> >> lib/igt_kms.h | 8
> >> 3 files changed, 24 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/lib/igt_fb.h b/lib/igt_fb.h
> >> index e8fe3ac..0a06899 100644
> >> --- a/lib/igt_fb.h
> >> +++ b/lib/igt_fb.h
> >> @@ -55,10 +55,6 @@ struct igt_fb {
> >>unsigned size;
> >>cairo_surface_t *cairo_surface;
> >>unsigned domain;
> >> - uint32_t src_x;
> >> - uint32_t src_y;
> >> - uint32_t src_w;
> >> - uint32_t src_h;
> >> };
> >>
> >> enum igt_text_align {
> >> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> >> index 82257a6..b63a59d 100644
> >> --- a/lib/igt_kms.c
> >> +++ b/lib/igt_kms.c
> >> @@ -1586,10 +1586,10 @@ igt_atomic_prepare_plane_commit(igt_plane_t
> >> *plane, igt_output_t *output,
> >>}
> >>
> >>if (plane->position_changed || plane->size_changed) {
> >> - uint32_t src_x = IGT_FIXED(plane->fb->src_x, 0); /* src_x */
> >> - uint32_t src_y = IGT_FIXED(plane->fb->src_y, 0); /* src_y */
> >> - uint32_t src_w = IGT_FIXED(plane->fb->src_w, 0); /* src_w */
> >> - uint32_t src_h = IGT_FIXED(plane->fb->src_h, 0); /* src_h */
> >> + uint32_t src_x = IGT_FIXED(plane->src_x, 0); /* src_x */
> >> + uint32_t src_y = IGT_FIXED(plane->src_y, 0); /* src_y */
> >> + uint32_t src_w = IGT_FIXED(plane->src_w, 0); /* src_w */
> >> + uint32_t src_h = IGT_FIXED(plane->src_h, 0); /* src_h */
> >>int32_t crtc_x = plane->crtc_x;
> >>int32_t crtc_y = plane->crtc_y;
> >>uint32_t crtc_w = plane->crtc_w;
> >> @@ -1677,10 +1677,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
> >>CHECK_RETURN(ret, fail_on_error);
> >>} else if (plane->fb_changed || plane->position_changed ||
> >>plane->size_changed) {
> >> - src_x = IGT_FIXED(plane->fb->src_x,0); /* src_x */
> >> - src_y = IGT_FIXED(plane->fb->src_y,0); /* src_y */
> >> - src_w = IGT_FIXED(plane->fb->src_w,0); /* src_w */
> >> - src_h = IGT_FIXED(plane->fb->src_h,0); /* src_h */
> >> + src_x = IGT_FIXED(plane->src_x,0); /* src_x */
> >> + src_y = IGT_FIXED(plane->src_y,0); /* src_y */
> >> + src_w = IGT_FIXED(plane->src_w,0); /* src_w */
> >> + src_h = IGT_FIXED(plane->src_h,0); /* src_h */
> >>crtc_x = plane->crtc_x;
> >>crtc_y = plane->crtc_y;
> >>crtc_w = plane->crtc_w;
> >> @@ -2201,10 +2201,10 @@ void igt_plane_set_fb(igt_plane_t *plane, struct
> >> igt_fb *fb)
> >>plane->crtc_h = fb->height;
> >>
> >>/* set default src pos/size as fb size */
> >> - fb->src_x = 0;
> >> - fb->src_y = 0;
> >> - fb->src_w = fb->width;
> >> - fb->src_h = fb->height;
> >> + plane->src_x = 0;
> >> + plane->src_y = 0;
> >> + plane->src_w = fb->width;
> >> + plane->src_h = fb->height;
> >>} else {
> >>plane->crtc_w = 0;
> >>plane->crtc_h = 0;
> >> @@ -2271,8 +2271,8 @@ void igt_fb_set_position(struct igt_fb *fb,
> >> igt_plane_t *plane,
> >>LOG(display, "%s.%d: fb_set_position(%d,%d)\n",
> >>kmstest_pipe_name(pipe->pipe), plane->index, x, y);
> >>
> >> - fb->src_x = x;
> >> - fb->src_y = y;
> >> + plane->src_x = x;
> >> + plane->src_y = y;
> >>
> >>plane->fb_changed = true;
> >> }
> >> @@ -2297,8 +2297,8 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t
> >> *plane,
> >>LOG(display, "%s.%d: fb_set_size(%dx%d)\n",
> >>kmstest_pipe_name(pipe->pipe), plane->index, w, h);
> >>
> >> - fb->src_w = w;
> >> - fb->src_h = h;
> >> + plane->src_w = w;
> >> + plane->src_h = h;
> >>
> >>plane->fb_changed = true;
> >> }
> >> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> >> index 8ae1192..aabe244 100644
> >> --- a/lib/igt_kms.h
> >> +++ b/lib/igt_kms.h
> >> @@ -243,6 +243,14 @@ typedef struct {
> >>int crtc_x, crtc_y;
> >>/* size within pipe_src_w x pipe_src_h */
> >>int crtc_w, crtc_h;
> >> +
> >> + /* position with the framebuffer */
> >> + uint32_t src_x;
> >> + uint32_t src_y;
> >> + /* size within the framebuffer*/
> >> + uint32_t src_w;
> >> + uint32_t src_h;
> >
> > Perhaps add a small note that these are 16.16
> >
> > Patch looks good to me otherwise.
>
> I think we convert them to 16.16 at commit time.
> The values stored there should be normal integers.
Oh indeed. That's rather surprising. Maybe send a patch to change that
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add a way to test the modeset done during gpu reset.
== Series Details == Series: drm/i915: Add a way to test the modeset done during gpu reset. URL : https://patchwork.freedesktop.org/series/5314/ State : failure == Summary == Series 5314v1 drm/i915: Add a way to test the modeset done during gpu reset. http://patchwork.freedesktop.org/api/1.0/series/5314/revisions/1/mbox/ Test drv_getparams_basic: Subgroup basic-subslice-total: pass -> DMESG-WARN (bsw-nuc-2) Test drv_hangman: Subgroup error-state-basic: pass -> SKIP (bsw-nuc-2) Test gem_cs_tlb: Subgroup basic-default: pass -> SKIP (bsw-nuc-2) Test gem_ctx_basic: pass -> DMESG-WARN (bsw-nuc-2) Test gem_exec_basic: Subgroup gtt-bsd: pass -> SKIP (bsw-nuc-2) Subgroup readonly-default: pass -> SKIP (bsw-nuc-2) Subgroup readonly-vebox: pass -> SKIP (bsw-nuc-2) Test gem_exec_nop: Subgroup basic: pass -> SKIP (bsw-nuc-2) Test gem_exec_store: Subgroup basic-default: pass -> SKIP (bsw-nuc-2) Test gem_exec_suspend: Subgroup basic-s3: pass -> SKIP (bsw-nuc-2) Test gem_exec_whisper: Subgroup basic: pass -> INCOMPLETE (bsw-nuc-2) Test gem_mmap_gtt: Subgroup basic-read-write-distinct: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-write-gtt: pass -> DMESG-WARN (bsw-nuc-2) Test gem_ringfill: Subgroup basic-default: pass -> SKIP (bsw-nuc-2) Test gem_storedw_loop: Subgroup basic-blt: pass -> DMESG-FAIL (bsw-nuc-2) Subgroup basic-render: pass -> SKIP (bsw-nuc-2) Test kms_addfb_basic: Subgroup addfb25-framebuffer-vs-set-tiling: pass -> DMESG-WARN (bsw-nuc-2) Subgroup addfb25-x-tiled-mismatch: pass -> DMESG-WARN (bsw-nuc-2) Subgroup addfb25-y-tiled: pass -> DMESG-WARN (bsw-nuc-2) Subgroup bad-pitch-1024: pass -> DMESG-WARN (bsw-nuc-2) Subgroup bad-pitch-63: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-x-tiled: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-y-tiled: pass -> DMESG-WARN (bsw-nuc-2) Subgroup bo-too-small-due-to-tiling: pass -> DMESG-WARN (bsw-nuc-2) Subgroup clobberred-modifier: pass -> DMESG-WARN (bsw-nuc-2) Subgroup no-handle: pass -> DMESG-WARN (bsw-nuc-2) Subgroup unused-modifier: pass -> DMESG-WARN (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-wf_vblank: fail -> PASS (snb-x220t) pass -> FAIL (bsw-nuc-2) Test kms_force_connector_basic: Subgroup prune-stale-modes: pass -> SKIP (ilk-hp8440p) Test kms_frontbuffer_tracking: Subgroup basic: pass -> DMESG-FAIL (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-c: pass -> SKIP (bsw-nuc-2) Subgroup nonblocking-crc-pipe-c-frame-sequence: pass -> DMESG-FAIL (bsw-nuc-2) Subgroup read-crc-pipe-c-frame-sequence: pass -> DMESG-FAIL (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) Test prime_self_import: Subgroup basic-llseek-bad: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-llseek-size: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-with_fd_dup: pass -> DMESG-WARN (bsw-nuc-2) bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:153 pass:88 dwarn:20 dfail:4 fail:1 skip:39 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:130 dwarn:1 dfail:0 fail:0 skip:65 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pa
Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel
On 08/03/16 13:15, Tvrtko Ursulin wrote:
On 11/01/16 09:16, Chris Wilson wrote:
If we move the release of the GEM request (i.e. decoupling it from the
various lists used for client and context tracking) after it is complete
(either by the GPU retiring the request, or by the caller cancelling the
request), we can remove the requirement that the final unreference of
the GEM request need to be under the struct_mutex.
v2: Execlists as always is badly asymetric and year old patches still
haven't landed to fix it up.
Looks good and pretty standalone to me (depends on i915_gem_request code
movement only I think). Just one question below.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4 +--
drivers/gpu/drm/i915/i915_gem_request.c | 50
++--
drivers/gpu/drm/i915/i915_gem_request.h | 14 -
drivers/gpu/drm/i915/intel_breadcrumbs.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c | 6 ++--
drivers/gpu/drm/i915/intel_pm.c | 2 +-
7 files changed, 30 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 68a25617ca7a..6d8d65304abf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2502,7 +2502,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void
*data, struct drm_file *file)
ret = __i915_wait_request(req[i], true,
args->timeout_ns > 0 ? &args->timeout_ns :
NULL,
to_rps_client(file));
-i915_gem_request_unreference__unlocked(req[i]);
+i915_gem_request_unreference(req[i]);
}
return ret;
@@ -3505,7 +3505,7 @@ i915_gem_ring_throttle(struct drm_device *dev,
struct drm_file *file)
return 0;
ret = __i915_wait_request(target, true, NULL, NULL);
-i915_gem_request_unreference__unlocked(target);
+i915_gem_request_unreference(target);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index b4ede6dd7b20..1c4f4d83a3c2 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -184,13 +184,6 @@ err:
return ret;
}
-void i915_gem_request_cancel(struct drm_i915_gem_request *req)
-{
-intel_ring_reserved_space_cancel(req->ringbuf);
-
-i915_gem_request_unreference(req);
-}
-
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
struct drm_file *file)
{
@@ -235,9 +228,28 @@ i915_gem_request_remove_from_client(struct
drm_i915_gem_request *request)
request->pid = NULL;
}
+static void __i915_gem_request_release(struct drm_i915_gem_request
*request)
+{
+i915_gem_request_remove_from_client(request);
+
+i915_gem_context_unreference(request->ctx);
+i915_gem_request_unreference(request);
+}
+
+void i915_gem_request_cancel(struct drm_i915_gem_request *req)
+{
+intel_ring_reserved_space_cancel(req->ringbuf);
+if (i915.enable_execlists) {
+if (req->ctx != req->ring->default_context)
+intel_lr_context_unpin(req);
+}
+__i915_gem_request_release(req);
+}
+
static void i915_gem_request_retire(struct drm_i915_gem_request
*request)
{
trace_i915_gem_request_retire(request);
+list_del_init(&request->list);
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
@@ -248,11 +260,7 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
* completion order.
*/
request->ringbuf->last_retired_head = request->postfix;
-
-list_del_init(&request->list);
-i915_gem_request_remove_from_client(request);
-
-i915_gem_request_unreference(request);
+__i915_gem_request_release(request);
}
void
@@ -639,21 +647,7 @@ i915_wait_request(struct drm_i915_gem_request *req)
void i915_gem_request_free(struct kref *req_ref)
{
-struct drm_i915_gem_request *req = container_of(req_ref,
- typeof(*req), ref);
-struct intel_context *ctx = req->ctx;
-
-if (req->file_priv)
-i915_gem_request_remove_from_client(req);
-
-if (ctx) {
-if (i915.enable_execlists) {
-if (ctx != req->ring->default_context)
-intel_lr_context_unpin(req);
-}
-
-i915_gem_context_unreference(ctx);
-}
-
+struct drm_i915_gem_request *req =
+container_of(req_ref, typeof(*req), ref);
kmem_cache_free(req->i915->requests, req);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h
b/drivers/gpu/drm/i915/i915_gem_request.h
index d46f22f30b0a..af1b825fce50 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -154,23 +154,9 @@ i915_gem_request_reference(struct
drm_i915_gem_request *req)
static inline void
i915_gem_request_unreferenc
[Intel-gfx] [PATCH 0/3] DPCD Backlight Control
These patches add support for Backlight Control using DPCD registers on eDP displays. - Patch 1 Adds macro for DPCD registers capability size to drm_dp_helper.h - Patch 2 Reads the eDP DPCD Display Control capability registers. - Patch 2 Implements functionaly for DPCD Backlight Control Yetunde Adebisi (3): drm/dp: Add definition for Display Control DPCD Registers capability size drm/i915: Read eDP Display control capability registers drm/i915: Add Backlight Control using DPCD for eDP connectors (v9) drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_params.c| 4 + drivers/gpu/drm/i915/i915_params.h| 1 + drivers/gpu/drm/i915/intel_dp.c | 15 ++- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++ drivers/gpu/drm/i915/intel_drv.h | 4 + drivers/gpu/drm/i915/intel_panel.c| 4 + include/drm/drm_dp_helper.h | 1 + 8 files changed, 198 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd
v3: Correct some formatting mistakes
v4: Updated to use AUX backlight control if PWM control is not possible
(Jani)
v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
v7: Add enable_dpcd_backlight module parameter.
v8: Rebase onto latest drm-intel-nightly branch
v9: Remove changes to intel_dp_dpcd_read_wake
Split addition edp_dpcd variable into a separate patch
Cc: Bob Paauwe
Cc: Jani Nikula
Signed-off-by: Yetunde Adebisi
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_params.c| 4 +
drivers/gpu/drm/i915/i915_params.h| 1 +
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_panel.c| 4 +
6 files changed, 186 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..11cc3e6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ i915-y += dvo_ch7017.o \
dvo_tfp410.o \
intel_crt.o \
intel_ddi.o \
+ intel_dp_aux_backlight.o \
intel_dp_link_training.o \
intel_dp_mst.o \
intel_dp.o \
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..383c076 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -58,6 +58,7 @@ struct i915_params i915 __read_mostly = {
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
+ .enable_dpcd_backlight = false,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -210,3 +211,6 @@ MODULE_PARM_DESC(enable_dp_mst,
module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint,
0400);
MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
0600);
+MODULE_PARM_DESC(enable_dpcd_backlight,
+ "Enable support for DPCD backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..65e73dd 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -61,6 +61,7 @@ struct i915_params {
bool verbose_state_checks;
bool nuclear_pageflip;
bool enable_dp_mst;
+ bool enable_dpcd_backlight;
};
extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
new file mode 100644
index 000..984fb0d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -0,0 +1,173 @@
+/*
+ * 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 "intel_drv.h"
+
+static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+{
+ uint8_t reg_val = 0;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ ®_val) < 0) {
+ DRM_DEBUG
[Intel-gfx] [PATCH 1/3] drm/dp: Add definition for Display Control DPCD Registers capability size
This is used when reading Display Control capability Registers on the sink device. cc: Jani Nikula cc: dri-de...@lists.freedesktop.org Signed-off-by: Yetunde Adebisi --- include/drm/drm_dp_helper.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1252108..92d9a52 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -621,6 +621,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 link_status[DP_LINK_STATUS_SI #define DP_BRANCH_OUI_HEADER_SIZE 0xc #define DP_RECEIVER_CAP_SIZE 0xf #define EDP_PSR_RECEIVER_CAP_SIZE 2 +#define EDP_DISPLAY_CTL_CAP_SIZE 3 void drm_dp_link_train_clock_recovery_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]); void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Read eDP Display control capability registers
Add new edp_dpcd variable to intel_dp.
Read and save eDP Display control capability registers to edp_dpcd.
Signed-off-by: Yetunde Adebisi
---
drivers/gpu/drm/i915/intel_dp.c | 15 ++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..ad2c7d6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3777,7 +3777,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- uint8_t rev;
if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
sizeof(intel_dp->dpcd)) < 0)
@@ -3834,6 +3833,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
}
+
+ /* Read the eDP Display control capabilities registers */
+ memset(intel_dp->edp_dpcd, 0, sizeof(intel_dp->edp_dpcd));
+ if ((intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
+ (intel_dp_dpcd_read_wake(&intel_dp->aux,
DP_EDP_DPCD_REV,
+ intel_dp->edp_dpcd,
sizeof(intel_dp->edp_dpcd)) ==
+
sizeof(intel_dp->edp_dpcd)))
+ DRM_DEBUG_KMS("EDP DPCD : %*ph\n", (int)
sizeof(intel_dp->edp_dpcd),
+ intel_dp->edp_dpcd);
}
DRM_DEBUG_KMS("Display Port TPS3 support: source %s, sink %s\n",
@@ -3841,10 +3849,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
/* Intermediate frequency support */
- if (is_edp(intel_dp) &&
- (intel_dp->dpcd[DP_EDP_CONFIGURATION_CAP] &
DP_DPCD_DISPLAY_CONTROL_CAPABLE) &&
- (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_EDP_DPCD_REV, &rev, 1)
== 1) &&
- (rev >= 0x03)) { /* eDp v1.4 or higher */
+ if (is_edp(intel_dp) && (intel_dp->edp_dpcd[0] >= 0x03)) { /* eDp v1.4
or higher */
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9255b56..b14e515 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -805,6 +805,7 @@ struct intel_dp {
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
+ uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
/* sink rates as reported by DP_SUPPORTED_LINK_RATES */
uint8_t num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tools/intel_reg: Fix builtin register spec for gen4
On Tue, 05 Apr 2016, ville.syrj...@linux.intel.com wrote:
> [ text/plain ]
> From: Ville Syrjälä
>
> Actually use the builtin register spec on gen4. Makes intel_reg dump
> actually do something on gen4.
>
> Signed-off-by: Ville Syrjälä
> ---
> tools/intel_reg_decode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/intel_reg_decode.c b/tools/intel_reg_decode.c
> index bb8f5b30311f..470fecc165c6 100644
> --- a/tools/intel_reg_decode.c
> +++ b/tools/intel_reg_decode.c
> @@ -2580,7 +2580,7 @@ static bool is_945gm(uint32_t devid, uint32_t pch)
>
> static bool is_gen234(uint32_t devid, uint32_t pch)
> {
> - return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN3(devid);
> + return IS_GEN2(devid) || IS_GEN3(devid) || IS_GEN4(devid);
Facepalm-by: Jani Nikula
> }
>
> #define DECLARE_REGS(d,r,m) \
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915/userptr: Store i915 backpointer for i915_mm_struct
Since we only ever use the drm_i915_private from the stored
i915_mm_struct->dev, save some electrons by storing the right
backpointer.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
Reviewed-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 960bb37f458f..cb41919063d2 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -34,7 +34,7 @@
struct i915_mm_struct {
struct mm_struct *mm;
- struct drm_device *dev;
+ struct drm_i915_private *i915;
struct i915_mmu_notifier *mn;
struct hlist_node node;
struct kref kref;
@@ -250,13 +250,13 @@ i915_mmu_notifier_find(struct i915_mm_struct *mm)
return mn;
down_write(&mm->mm->mmap_sem);
- mutex_lock(&to_i915(mm->dev)->mm_lock);
+ mutex_lock(&mm->i915->mm_lock);
if ((mn = mm->mn) == NULL) {
mn = i915_mmu_notifier_create(mm->mm);
if (!IS_ERR(mn))
mm->mn = mn;
}
- mutex_unlock(&to_i915(mm->dev)->mm_lock);
+ mutex_unlock(&mm->i915->mm_lock);
up_write(&mm->mm->mmap_sem);
return mn;
@@ -373,7 +373,7 @@ i915_gem_userptr_init__mm_struct(struct drm_i915_gem_object
*obj)
}
kref_init(&mm->kref);
- mm->dev = obj->base.dev;
+ mm->i915 = to_i915(obj->base.dev);
mm->mm = current->mm;
atomic_inc(¤t->mm->mm_count);
@@ -408,7 +408,7 @@ __i915_mm_struct_free(struct kref *kref)
/* Protected by dev_priv->mm_lock */
hash_del(&mm->node);
- mutex_unlock(&to_i915(mm->dev)->mm_lock);
+ mutex_unlock(&mm->i915->mm_lock);
INIT_WORK(&mm->work, __i915_mm_struct_free__worker);
schedule_work(&mm->work);
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915/userptr: Hold mmref whilst calling get-user-pages
Holding a reference to the containing task_struct is not sufficient to
prevent the mm_struct from being reaped under memory pressure. If this
happens whilst we are calling get_user_pages(), explosions erupt -
sometimes an immediate GPF, sometimes page flag corruption. To prevent
the target mm from being reaped as we are reading from it, acquire a
reference before we begin.
Testcase: igt/gem_shrink/*userptr
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
Cc: sta...@vger.kernel.org
Reviewed-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 92b39186b05a..960bb37f458f 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -547,19 +547,24 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
- down_read(&mm->mmap_sem);
- while (pinned < npages) {
- ret = get_user_pages_remote(work->task, mm,
- obj->userptr.ptr + pinned * PAGE_SIZE,
- npages - pinned,
- !obj->userptr.read_only, 0,
- pvec + pinned, NULL);
- if (ret < 0)
- break;
-
- pinned += ret;
+ ret = -EFAULT;
+ if (atomic_inc_not_zero(&mm->mm_users)) {
+ down_read(&mm->mmap_sem);
+ while (pinned < npages) {
+ ret = get_user_pages_remote
+ (work->task, mm,
+obj->userptr.ptr + pinned * PAGE_SIZE,
+npages - pinned,
+!obj->userptr.read_only, 0,
+pvec + pinned, NULL);
+ if (ret < 0)
+ break;
+
+ pinned += ret;
+ }
+ up_read(&mm->mmap_sem);
+ mmput(mm);
}
- up_read(&mm->mmap_sem);
}
mutex_lock(&dev->struct_mutex);
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/bxt: VBT changes for hpd as wakeup feature
On Tue, 05 Apr 2016, Animesh Manna wrote:
> To support hpd during sleep a new feature flag is
> added in vbt and also in dev_priv for enabling/disabling
> inside deiver. By default this feature will be
> diabled and based on oem request this feature can
> be enabled by changing vbt feature flag.
>
> Signed-off-by: Animesh Manna
> Signed-off-by: A.Sunil Kamath
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dd18772..445b80b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1429,6 +1429,11 @@ enum psr_lines_to_wait {
> PSR_8_LINES_TO_WAIT
> };
>
> +enum hpd_wakeup_state {
> + DISABLE_HOT_PLUG_AS_WAKE_EVENT = 0,
> + ENABLE_HOT_PLUG_AS_WAKE_EVENT
> +};
Any reason to use an enum when a bool will do? In fact, you use it as a
bool in the following patches.
> +
> struct intel_vbt_data {
> struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -1485,6 +1490,9 @@ struct intel_vbt_data {
> const u8 *sequence[MIPI_SEQ_MAX];
> } dsi;
>
> + /* HPD as wakesoure for DC9 BXT */
> + enum hpd_wakeup_state hpd_wakeup_enabled;
> +
Why don't you initialize the field in this patch? Patch 6/6 should be
part of this patch.
> int crt_ddc_pin;
>
> int child_dev_num;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 12f5103..cc42bd9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6119,6 +6119,7 @@ enum skl_disp_power_wells {
>SDE_PORTB_HOTPLUG |\
>SDE_PORTC_HOTPLUG |\
>SDE_PORTD_HOTPLUG)
> +
Superfluous whitespace change.
> #define SDE_TRANSB_CRC_DONE (1 << 5)
> #define SDE_TRANSB_CRC_ERR (1 << 4)
> #define SDE_TRANSB_FIFO_UNDER(1 << 3)
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 749dcea..8e2b765 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -547,7 +547,8 @@ struct bdb_driver_features {
> u16 tbt_enabled:1;
> u16 psr_enabled:1;
> u16 ips_enabled:1;
> - u16 reserved3:4;
> + u16 reserved3:3;
> + u16 hpd_wakeup_source:1;
> u16 pc_feature_valid:1;
> } __packed;
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns
In order to ensure that all invalidations are completed before the
operation returns to userspace (i.e. before the munmap() syscall returns)
we need to wait upon the outstanding operations.
We are allowed to block inside the invalidate_range_start callback, and
as struct_mutex is the inner lock with mmap_sem we can wait upon the
struct_mutex without provoking lockdep into warning about a deadlock.
However, we don't actually want to wait upon outstanding rendering
whilst holding the struct_mutex if we can help it otherwise we also
block other processes from submitting work to the GPU. So first we do a
wait without the lock and then when we reacquire the lock, we double
check that everything is ready for removing the invalidated pages.
Finally to wait upon the outstanding unpinning tasks, we create a
private workqueue as a means to conveniently wait upon all at once. The
drawback is that this workqueue is per-mm, so any threads concurrently
invalidating objects will wait upon each other. The advantage of using
the workqueue is that we can wait in parallel for completion of
rendering and unpinning of several objects (of particular importance if
the process terminates with a whole mm full of objects).
v2: Apply a cup of tea to the changelog.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699
Testcase: igt/gem_userptr_blits/sync-unmap-cycles
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 48 -
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 291a9393493d..92b39186b05a 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -49,6 +49,7 @@ struct i915_mmu_notifier {
struct hlist_node node;
struct mmu_notifier mn;
struct rb_root objects;
+ struct workqueue_struct *wq;
};
struct i915_mmu_object {
@@ -60,6 +61,40 @@ struct i915_mmu_object {
bool attached;
};
+static void wait_rendering(struct drm_i915_gem_object *obj)
+{
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
+ unsigned reset_counter;
+ int i, n;
+
+ if (!obj->active)
+ return;
+
+ n = 0;
+ for (i = 0; i < I915_NUM_ENGINES; i++) {
+ struct drm_i915_gem_request *req;
+
+ req = obj->last_read_req[i];
+ if (req == NULL)
+ continue;
+
+ requests[n++] = i915_gem_request_reference(req);
+ }
+
+ reset_counter = atomic_read(&to_i915(dev)->gpu_error.reset_counter);
+ mutex_unlock(&dev->struct_mutex);
+
+ for (i = 0; i < n; i++)
+ __i915_wait_request(requests[i], reset_counter, false,
+ NULL, NULL);
+
+ mutex_lock(&dev->struct_mutex);
+
+ for (i = 0; i < n; i++)
+ i915_gem_request_unreference(requests[i]);
+}
+
static void cancel_userptr(struct work_struct *work)
{
struct i915_mmu_object *mo = container_of(work, typeof(*mo), work);
@@ -75,6 +110,8 @@ static void cancel_userptr(struct work_struct *work)
struct i915_vma *vma, *tmp;
bool was_interruptible;
+ wait_rendering(obj);
+
was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;
@@ -140,7 +177,7 @@ static void
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
*/
mo = container_of(it, struct i915_mmu_object, it);
if (kref_get_unless_zero(&mo->obj->base.refcount))
- schedule_work(&mo->work);
+ queue_work(mn->wq, &mo->work);
list_add(&mo->link, &cancelled);
it = interval_tree_iter_next(it, start, end);
@@ -148,6 +185,8 @@ static void
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
list_for_each_entry(mo, &cancelled, link)
del_object(mo);
spin_unlock(&mn->lock);
+
+ flush_workqueue(mn->wq);
}
static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
@@ -167,10 +206,16 @@ i915_mmu_notifier_create(struct mm_struct *mm)
spin_lock_init(&mn->lock);
mn->mn.ops = &i915_gem_userptr_notifier;
mn->objects = RB_ROOT;
+ mn->wq = alloc_workqueue("i915-userptr-release", WQ_UNBOUND, 0);
+ if (mn->wq == NULL) {
+ kfree(mn);
+ return ERR_PTR(-ENOMEM);
+ }
/* Protected by mmap_sem (write-lock) */
ret = __mmu_notifier_register(&mn->mn, mm);
if (ret) {
+ destroy_workqueue(mn->wq);
kfree(mn);
return ERR_PTR(ret);
}
@@ -256,6 +301,7 @@ i915_mmu_notifier_free(struct i915_mmu
Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel
On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote: > I felt was so close in getting rid of execlist_retired_req_queue, > using this patch as a starting point, when I realised this patch > does not play nicely with the GuC. Back to the drawing board. :( I will also say that we need to rid requests of struct_mutex far more than we need the GuC. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)
This patch adds support for eDP backlight control using DPCD registers to
backlight hooks in intel_panel.
It checks for backlight control over AUX channel capability and sets up
function pointers to get and set the backlight brightness level if
supported.
v2: Moved backlight functions from intel_dp.c into a new file
intel_dp_aux_backlight.c. Also moved reading of eDP display control
registers to intel_dp_get_dpcd
v3: Correct some formatting mistakes
v4: Updated to use AUX backlight control if PWM control is not possible
(Jani)
v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
v7: Add enable_dpcd_backlight module parameter.
v8: Rebase onto latest drm-intel-nightly branch
v9: Remove changes to intel_dp_dpcd_read_wake
Split addition edp_dpcd variable into a separate patch
Cc: Bob Paauwe
Cc: Jani Nikula
Signed-off-by: Yetunde Adebisi
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_params.c| 4 +
drivers/gpu/drm/i915/i915_params.h| 1 +
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/gpu/drm/i915/intel_panel.c| 4 +
6 files changed, 186 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..11cc3e6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -79,6 +79,7 @@ i915-y += dvo_ch7017.o \
dvo_tfp410.o \
intel_crt.o \
intel_ddi.o \
+ intel_dp_aux_backlight.o \
intel_dp_link_training.o \
intel_dp_mst.o \
intel_dp.o \
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..383c076 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -58,6 +58,7 @@ struct i915_params i915 __read_mostly = {
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
+ .enable_dpcd_backlight = false,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -210,3 +211,6 @@ MODULE_PARM_DESC(enable_dp_mst,
module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint,
0400);
MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
0600);
+MODULE_PARM_DESC(enable_dpcd_backlight,
+ "Enable support for DPCD backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..65e73dd 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -61,6 +61,7 @@ struct i915_params {
bool verbose_state_checks;
bool nuclear_pageflip;
bool enable_dp_mst;
+ bool enable_dpcd_backlight;
};
extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
new file mode 100644
index 000..984fb0d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -0,0 +1,173 @@
+/*
+ * 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 "intel_drv.h"
+
+static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool enable)
+{
+ uint8_t reg_val = 0;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ ®_val) < 0) {
+ DRM_DEBUG
[Intel-gfx] [PATCH 0/3] DPCD Backlight Control
These patches add support for Backlight Control using DPCD registers on eDP displays. - Patch 1 Adds macro for DPCD registers capability size to drm_dp_helper.h - Patch 2 Reads the eDP DPCD Display Control capability registers. - Patch 2 Implements functionaly for DPCD Backlight Control Yetunde Adebisi (3): drm/dp: Add definition for Display Control DPCD Registers capability size drm/i915: Read eDP Display control capability registers drm/i915: Add Backlight Control using DPCD for eDP connectors (v9) drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_params.c| 4 + drivers/gpu/drm/i915/i915_params.h| 1 + drivers/gpu/drm/i915/intel_dp.c | 15 ++- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173 ++ drivers/gpu/drm/i915/intel_drv.h | 4 + drivers/gpu/drm/i915/intel_panel.c| 4 + include/drm/drm_dp_helper.h | 1 + 8 files changed, 198 insertions(+), 5 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 045/190] drm/i915: Move releasing of the GEM request from free to retire/cancel
On 05/04/16 15:09, Chris Wilson wrote: On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote: @@ -587,9 +587,6 @@ static int execlists_context_queue(struct drm_i915_gem_request *request) struct drm_i915_gem_request *cursor; int num_elements = 0; -if (request->ctx != ring->default_context) -intel_lr_context_pin(request); - Since you remove LRC pin from queue, the lifetime is now either: 1. From request create to cancel. 2. From request create to execlist retirement. Would it be more logical to leave the LRC pin in queue, but remove it >from request creation instead? That would make the LRC pin lifetime only a single possibility, from queue to execlist retire. Well what we actually need in request allocation is pinning the ringbuffer. At the moment we do that by pinning the request. We also need to pin the VM in order to manipulate it. We could leave pinning the logical context object til actual submission. Hmmm, yes. Have to think how complicated or not would that be. I felt was so close in getting rid of execlist_retired_req_queue, using this patch as a starting point, when I realised this patch does not play nicely with the GuC. Back to the drawing board. :( If you mean what happens if the GuC executes requests out-of-order - it can't in the current model since we only have a single timeline and that would break it badly - then nothing changes. We are only moving the release in time, not decoupling it from any serialisation. No, there is no LRC unpin, it is unbalanced in the GuC mode with this patch. Unless I am missing something... ? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/dp: Add definition for Display Control DPCD Registers capability size
This is used when reading Display Control capability Registers on the sink device. cc: dri-de...@lists.freedesktop.org Signed-off-by: Yetunde Adebisi Reviewed-by: Jani Nikula --- include/drm/drm_dp_helper.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1252108..92d9a52 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -621,6 +621,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 link_status[DP_LINK_STATUS_SI #define DP_BRANCH_OUI_HEADER_SIZE 0xc #define DP_RECEIVER_CAP_SIZE 0xf #define EDP_PSR_RECEIVER_CAP_SIZE 2 +#define EDP_DISPLAY_CTL_CAP_SIZE 3 void drm_dp_link_train_clock_recovery_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]); void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
