Re: [Intel-gfx] [PATCH v2] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> Sent: Friday, June 10, 2016 7:30 AM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate
>
> On 09/06/2016 20:19, tim.g...@intel.com wrote:
> > From: Tim Gore
> >
> > This patch enables a workaround for a mid thread preemption issue
> > where a hardware timing problem can prevent the context restore from
> > happening, leading to a hang.
> >
> > v2: move to gen9_init_workarounds (Arun)
> >
> > Signed-off-by: Tim Gore
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 81d1896..2a6fc62 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
> > #define GEN9_IZ_HASHING_MASK(slice) (0x3 <<
> ((slice) * 2))
> > #define GEN9_IZ_HASHING(slice, val) ((val) <<
> ((slice) * 2))
> >
> > +/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
> > +#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
> > +#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
> > +
> > /* WaClearTdlStateAckDirtyBits */
> > #define GEN8_STATE_ACK_MMIO(0x20F0)
> > #define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index cf8d0bf..7c756ac 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -1022,6 +1022,9 @@ static int gen9_init_workarounds(struct
> intel_engine_cs *engine)
> > if (ret)
> > return ret;
> >
> > + /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
> > + I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> >
> +_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE)
> );
> > +
> WA_SET_BIT_MASKED(GEN9_CSFE_CHICKEN1_RCS,
> GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);
>
> Please correct the spelling.
> We should try to keep WA regs in some order although it is not true for some
> of the existing ones but we should try to follow this rule for the new ones;
> HW whitelist registers are normally kept at the end.
> I think the correct place for this one is at the beginning of this function to
> maintain increasing order.
>
> regards
> Arun
>
>
Which spelling do you want corrected?
Tim
> > return 0;
> > }
> >
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now
On Jun 09 Zanoni, Paulo R wrote: > Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu: > > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : > > > > This was kind of a difficult bug to track down. If you're using a > > Haswell system running GNOME and you have fbc completely enabled and > > working, playing videos can result in video artifacts. [...] > > For the time being, disable FBC for Haswell by default. > > In case we want to improve the commit message: > > We also got reports from Steven Honeyman on openbox+roxterm, and from > Stefan Richter. Perhaps also worth mentioning in the changelog: Stefan Richter reported kernel freezes (no video artifacts) when fbc is on. (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE applications, thread begins at https://lkml.org/lkml/2016/4/26/813) -- Stefan Richter -==- -==- -=-=- http://arcgraph.de/sr/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Introduce the implementation of GVT context (rev8)
The failed test case is related to the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=95372 > -Original Message- > From: Patchwork [mailto:patchw...@emeril.freedesktop.org] > Sent: Friday, June 10, 2016 8:32 AM > To: Wang, Zhi A > Cc: intel-gfx@lists.freedesktop.org > Subject: ✗ Ro.CI.BAT: failure for Introduce the implementation of GVT context > (rev8) > > == Series Details == > > Series: Introduce the implementation of GVT context (rev8) > URL : https://patchwork.freedesktop.org/series/7208/ > State : failure > > == Summary == > > Series 7208v8 Introduce the implementation of GVT context > http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/8/mbox > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-cmd: > pass -> FAIL (ro-byt-n2820) > Test kms_flip: > Subgroup basic-flip-vs-wf_vblank: > fail -> PASS (ro-bdw-i7-5600u) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-b: > dmesg-warn -> SKIP (ro-bdw-i5-5250u) > > ro-bdw-i5-5250u total:213 pass:197 dwarn:1 dfail:0 fail:0 > skip:15 > ro-bdw-i7-5557U total:213 pass:197 dwarn:1 dfail:0 fail:0 > skip:15 > ro-bdw-i7-5600u total:213 pass:185 dwarn:0 dfail:0 fail:0 > skip:28 > ro-bsw-n3050 total:213 pass:172 dwarn:0 dfail:0 fail:2 > skip:39 > ro-byt-n2820 total:213 pass:173 dwarn:0 dfail:0 fail:3 > skip:37 > ro-hsw-i3-4010u total:213 pass:190 dwarn:0 dfail:0 fail:0 > skip:23 > ro-hsw-i7-4770r total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 > ro-ilk-i7-620lm total:213 pass:150 dwarn:0 dfail:0 fail:1 skip:62 > ro-ilk1-i5-650 total:208 pass:150 dwarn:0 dfail:0 fail:1 skip:57 > ro-ivb-i7-3770 total:213 pass:181 dwarn:0 dfail:0 fail:0 skip:32 > ro-ivb2-i7-3770 total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 > ro-snb-i7-2620M total:213 pass:174 dwarn:0 dfail:0 fail:1 > skip:38 > fi-hsw-i7-4770k failed to connect after reboot > > Results at /archive/results/CI_IGT_test/RO_Patchwork_1152/ > > b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration > manifest > 49cc9a2 drm/i915: Introduce GVT context creation API > 60b7103 drm/i915: Support LRC context single submission 99bf9fe drm/i915: > Introduce execlist context status change notification 426bd8e drm/i915: Make > addressing mode bits in context descriptor configurable > 10f04f2 drm/i915: Make ring buffer size of a LRC context configurable > 82be702 drm/i915: Introduce host graphics memory partition for GVT-g > abfadd5 drm/i915: gvt: Introduce the basic architecture of GVT-g > ae7b792 drm/i915: Fold vGPU active check into inner functions 3fb8c7b > drm/i915: Use offsetof() to calculate the offset of members in PVINFO page > 7810fd7 drm/i915: Factor out i915_pvinfo.h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
On 09/06/2016 20:19, tim.g...@intel.com wrote:
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
v2: move to gen9_init_workarounds (Arun)
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
#define GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
#define GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))
+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
/* WaClearTdlStateAckDirtyBits */
#define GEN8_STATE_ACK_MMIO(0x20F0)
#define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cf8d0bf..7c756ac 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1022,6 +1022,9 @@ static int gen9_init_workarounds(struct intel_engine_cs
*engine)
if (ret)
return ret;
+ /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
+ I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+
WA_SET_BIT_MASKED(GEN9_CSFE_CHICKEN1_RCS,
GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);
Please correct the spelling.
We should try to keep WA regs in some order although it is not true for
some of the existing ones but we should try to follow this rule for the
new ones; HW whitelist registers are normally kept at the end.
I think the correct place for this one is at the beginning of this
function to maintain increasing order.
regards
Arun
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for SKL watermark fixes for !fbcon
== Series Details == Series: SKL watermark fixes for !fbcon URL : https://patchwork.freedesktop.org/series/8513/ State : failure == Summary == Series 8513v1 SKL watermark fixes for !fbcon http://patchwork.freedesktop.org/api/1.0/series/8513/revisions/1/mbox Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: pass -> FAIL (ro-byt-n2820) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-bdw-i7-5600u) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: skip -> DMESG-WARN (ro-bdw-i5-5250u) ro-bdw-i5-5250u total:213 pass:197 dwarn:3 dfail:0 fail:0 skip:13 ro-bdw-i7-5600u total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-bsw-n3050 total:213 pass:172 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:213 pass:173 dwarn:0 dfail:0 fail:3 skip:37 ro-hsw-i3-4010u total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk-i7-620lm total:177 pass:120 dwarn:2 dfail:2 fail:1 skip:51 ro-ilk1-i5-650 total:208 pass:150 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:213 pass:181 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-snb-i7-2620M total:213 pass:174 dwarn:0 dfail:0 fail:1 skip:38 fi-hsw-i7-4770k failed to connect after reboot ro-bdw-i7-5557U failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_1154/ b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest 7db1532 drm/i915/gen9: Drop invalid WARN() during data rate calculation 46946f4 drm/i915/gen9: Compute data rates for all planes on first commit c90f98f drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Ro.CI.BAT: success for Enable FBC on SKL (rev5)
== Series Details == Series: Enable FBC on SKL (rev5) URL : https://patchwork.freedesktop.org/series/4722/ State : success == Summary == Series 4722v5 Enable FBC on SKL http://patchwork.freedesktop.org/api/1.0/series/4722/revisions/5/mbox Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-bdw-i7-5600u) ro-bdw-i5-5250u total:213 pass:197 dwarn:2 dfail:0 fail:0 skip:14 ro-bdw-i7-5557U total:213 pass:197 dwarn:1 dfail:0 fail:0 skip:15 ro-bdw-i7-5600u total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-bsw-n3050 total:213 pass:172 dwarn:0 dfail:0 fail:2 skip:39 ro-hsw-i3-4010u total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk-i7-620lm total:213 pass:150 dwarn:0 dfail:0 fail:1 skip:62 ro-ilk1-i5-650 total:208 pass:150 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:213 pass:181 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-snb-i7-2620M total:213 pass:174 dwarn:0 dfail:0 fail:1 skip:38 fi-hsw-i7-4770k failed to connect after reboot ro-byt-n2820 failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_1153/ b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest a0a9e44 drm/i915/fbc: enable FBC on gen 9+ too 4fe03eb drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps 8670248 drm/i915/fbc: sanitize i915.enable_fbc during FBC init 9eb1895 drm/i915/fbc: update busy_bits even for GTT and flip flushes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for Introduce the implementation of GVT context (rev8)
== Series Details == Series: Introduce the implementation of GVT context (rev8) URL : https://patchwork.freedesktop.org/series/7208/ State : failure == Summary == Series 7208v8 Introduce the implementation of GVT context http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/8/mbox Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: pass -> FAIL (ro-byt-n2820) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-bdw-i7-5600u) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> SKIP (ro-bdw-i5-5250u) ro-bdw-i5-5250u total:213 pass:197 dwarn:1 dfail:0 fail:0 skip:15 ro-bdw-i7-5557U total:213 pass:197 dwarn:1 dfail:0 fail:0 skip:15 ro-bdw-i7-5600u total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-bsw-n3050 total:213 pass:172 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:213 pass:173 dwarn:0 dfail:0 fail:3 skip:37 ro-hsw-i3-4010u total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk-i7-620lm total:213 pass:150 dwarn:0 dfail:0 fail:1 skip:62 ro-ilk1-i5-650 total:208 pass:150 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:213 pass:181 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-snb-i7-2620M total:213 pass:174 dwarn:0 dfail:0 fail:1 skip:38 fi-hsw-i7-4770k failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_1152/ b373842 drm-intel-nightly: 2016y-06m-09d-16h-49m-09s UTC integration manifest 49cc9a2 drm/i915: Introduce GVT context creation API 60b7103 drm/i915: Support LRC context single submission 99bf9fe drm/i915: Introduce execlist context status change notification 426bd8e drm/i915: Make addressing mode bits in context descriptor configurable 10f04f2 drm/i915: Make ring buffer size of a LRC context configurable 82be702 drm/i915: Introduce host graphics memory partition for GVT-g abfadd5 drm/i915: gvt: Introduce the basic architecture of GVT-g ae7b792 drm/i915: Fold vGPU active check into inner functions 3fb8c7b drm/i915: Use offsetof() to calculate the offset of members in PVINFO page 7810fd7 drm/i915: Factor out i915_pvinfo.h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/9] drm/fb-helper: Push down modeset lock into FB helpers
Hi Thierry,
2016년 06월 08일 00:26에 Thierry Reding 이(가) 쓴 글:
> From: Thierry Reding
>
> Move the modeset locking from drivers into FB helpers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_fb_helper.c| 59
> +-
> drivers/gpu/drm/i915/intel_dp_mst.c| 4 ---
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 7
> 3 files changed, 44 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 9afd4208596f..252c7557bdb5 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -95,8 +95,8 @@ static LIST_HEAD(kernel_fb_helper_list);
> * mmap page writes.
> */
>
> -int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> - struct drm_connector *connector)
> +static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> + struct drm_connector *connector)
> {
> struct drm_fb_helper_connector **temp;
> struct drm_fb_helper_connector *conn;
> @@ -129,6 +129,20 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper
> *fb_helper,
> fb_helper->connector_info[fb_helper->connector_count++] = conn;
> return 0;
> }
> +
> +int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
> + struct drm_connector *connector)
> +{
> + int err;
> +
> + mutex_lock(&fb_helper->dev->mode_config.mutex);
> +
> + err = __drm_fb_helper_add_one_connector(fb_helper, connector);
I think you don't need to make __drm_fb_helper_add_on_connector function but
just you can implement the codes here instead. And the use of prefix '__' thing
would not good.
And my concern about this is that other drivers may need to call this function
after taking a same mutex lock. Can you assure anyone not to call this function
with mutex lock?
If there is such case then,
some_function()
{
mutex_lock();
...
mutex_unlock();
drm_fb_helper_add_one_connector();
...
}
So in this case, other users should consider to make sure to unlock before
calling this function. That would be now really what you want.
Thanks,
Inki Dae
> +
> + mutex_unlock(&fb_helper->dev->mode_config.mutex);
> +
> + return err;
> +}
> EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
>
> /**
> @@ -155,28 +169,28 @@ int drm_fb_helper_single_add_all_connectors(struct
> drm_fb_helper *fb_helper)
> return 0;
>
> mutex_lock(&dev->mode_config.mutex);
> +
> drm_for_each_connector(connector, dev) {
> - ret = drm_fb_helper_add_one_connector(fb_helper, connector);
> + ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
> + if (ret) {
> + for (i = 0; i < fb_helper->connector_count; i++) {
> + kfree(fb_helper->connector_info[i]);
> + fb_helper->connector_info[i] = NULL;
> + }
I think all resources should be released by someone who allocated the resources
in case of failure. I mean that if some routine of
__drm_fb_helper_add_on_connector function failed than the function make sure to
release the resources allocated. I know this is really not what you did but
original code did. So how about cleanning up this thing?
Thanks,
Inki Dae
>
> - if (ret)
> - goto fail;
> - }
> - mutex_unlock(&dev->mode_config.mutex);
> - return 0;
> -fail:
> - for (i = 0; i < fb_helper->connector_count; i++) {
> - kfree(fb_helper->connector_info[i]);
> - fb_helper->connector_info[i] = NULL;
> + fb_helper->connector_count = 0;
> + break;
> + }
> }
> - fb_helper->connector_count = 0;
> +
> mutex_unlock(&dev->mode_config.mutex);
>
> return ret;
> }
> EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
>
> -int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
> -struct drm_connector *connector)
> +static int __drm_fb_helper_remove_one_connector(struct drm_fb_helper
> *fb_helper,
> + struct drm_connector *connector)
> {
> struct drm_fb_helper_connector *fb_helper_connector;
> int i, j;
> @@ -193,6 +207,7 @@ int drm_fb_helper_remove_one_connector(struct
> drm_fb_helper *fb_helper,
>
> if (i == fb_helper->connector_count)
> return -EINVAL;
> +
> fb_helper_connector = fb_helper->connector_info[i];
> drm_connector_unreference(fb_helper_connector->connector);
>
> @@ -204,6 +219,20 @@ int drm_fb_helper_remove_one_connector(struct
> drm_fb_helper *fb_helper,
>
> return 0;
> }
> +
> +int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
>
[Intel-gfx] [PATCH 3/3] drm/i915/gen9: Drop invalid WARN() during data rate calculation
It's possible to have a non-zero plane mask and still wind up with a total data rate of zero. There are two cases where this can happen: * planes are active (from the KMS point of view), but are all fully clipped (positioned offscreen) * the only active plane on a CRTC is the cursor (which is handled independently and not counted into the general data rate computations These are both valid display setups (although unusual), so we need to drop the WARN(). Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_pm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ba08639..2bd089e 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3107,8 +3107,6 @@ skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate) total_data_rate += intel_cstate->wm.skl.plane_y_data_rate[id]; } - WARN_ON(cstate->plane_mask && total_data_rate == 0); - return total_data_rate; } -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization
intel_state->active_crtcs is usually only initialized when doing a
modeset. During our first atomic commit after boot, we're effectively
faking a modeset to sanitize the DDB/wm setup, so ensure that this field
gets initialized before use.
Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 658a756..0cd38ca 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3896,9 +3896,18 @@ skl_compute_ddb(struct drm_atomic_state *state)
* pretend that all pipes switched active status so that we'll
* ensure a full DDB recompute.
*/
- if (dev_priv->wm.distrust_bios_wm)
+ if (dev_priv->wm.distrust_bios_wm) {
intel_state->active_pipe_changes = ~0;
+ /*
+* We usually only initialize intel_state->active_crtcs if we
+* we're doing a modeset; make sure this field is always
+* initialized during the sanitization process that happens
+* on the first commit too.
+*/
+ intel_state->active_crtcs = dev_priv->active_crtcs;
+ }
+
/*
* If the modeset changes which CRTC's are active, we need to
* recompute the DDB allocation for *all* active pipes, even
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/gen9: Compute data rates for all planes on first commit
When we sanitize our DDB and watermark info during the first atomic
commit, we need to calculate the total data rate. Since we haven't
explicitly added the planes for each CRTC to our atomic state, the total
data rate calculation will try to use the cached values from a previous
commit (which are 0 since there was no previous commit); this result is
incorrect if we inherited any active planes from the BIOS.
During our very first atomic commit, we need to explicitly add all
active planes to the atomic state to ensure that valid data rate values
are calculated for them. Subsequent commits will then have valid cached
values to fall back on.
Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0cd38ca..ba08639 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3933,6 +3933,18 @@ skl_compute_ddb(struct drm_atomic_state *state)
if (IS_ERR(cstate))
return PTR_ERR(cstate);
+ /*
+* If this is our first commit after hw readout, we don't have
+* valid data rate values cached. Add all planes to ensure we
+* calculate a valid data rate.
+*/
+ if (dev_priv->wm.distrust_bios_wm) {
+ ret = drm_atomic_add_affected_planes(state,
+&intel_crtc->base);
+ if (ret)
+ return ret;
+ }
+
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] SKL watermark fixes for !fbcon
There are a handful of watermark bugs that are only triggered (or more easily triggered) when running without fbcon. Thanks Tvrtko for pointing these out. I do still see some WARN()'s from other parts of the display code when launching X in a non-fbcon setup, so there may be other bugfixes needed in other parts of the code as well. Cc: Tvrtko Ursulin Matt Roper (3): drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization drm/i915/gen9: Compute data rates for all planes on first commit drm/i915/gen9: Drop invalid WARN() during data rate calculation drivers/gpu/drm/i915/intel_pm.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 06/33] drm: Minimally initialise drm_dp_aux
On Fri, Jun 03, 2016 at 05:59:11PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 03, 2016 at 03:36:49PM +0100, Chris Wilson wrote:
> > When trying to split up the initialisation phase and the registration
> > phase, one immediate problem encountered is trying to use our own i2c
> > devices before registration with userspace (to read EDID during device
> > discovery). drm_dp_aux in particular only offers an interface for setting
> > up the device *after* we have exposed the connector via sysfs. In order
> > to break the chicken-and-egg problem, export drm_dp_aux_init() to
> > minimally prepare the i2c device for internal use before
> > drm_connector_register().
> >
> > Signed-off-by: Chris Wilson
> > Cc: Dave Airlie
> > Cc: Rafael Antognolli
> > Cc: Ville Syrjälä
> > Cc: dri-de...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 26 +-
> > include/drm/drm_dp_helper.h | 1 +
> > 2 files changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 4b088afa21b2..9b4ec65e1de6 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -791,15 +791,16 @@ static void unlock_bus(struct i2c_adapter *i2c,
> > unsigned int flags)
> > }
> >
> > /**
> > - * drm_dp_aux_register() - initialise and register aux channel
> > + * drm_dp_aux_init() - minimally initialise an aux channel
> > * @aux: DisplayPort AUX channel
> > *
> > - * Returns 0 on success or a negative error code on failure.
> > + * If you need to use the drm_dp_aux's i2c adapter prior to registering it
> > + * with the outside world, call drm_dp_aux_init() first. You must still
> > + * call drm_dp_aux_register() once the connector has been registered to
> > + * allow userspace access to the auxiliary DP channel.
> > */
> > -int drm_dp_aux_register(struct drm_dp_aux *aux)
> > +void drm_dp_aux_init(struct drm_dp_aux *aux)
> > {
> > - int ret;
> > -
> > mutex_init(&aux->hw_mutex);
> >
> > aux->ddc.algo = &drm_dp_i2c_algo;
> > @@ -809,6 +810,21 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
> > aux->ddc.lock_bus = lock_bus;
> > aux->ddc.trylock_bus = trylock_bus;
> > aux->ddc.unlock_bus = unlock_bus;
> > +}
> > +EXPORT_SYMBOL(drm_dp_aux_init);
>
> This doesn't feel very safe to me. To me it looks like the i2c core
> wasn't designed to have the adapter be used before i2c_add_adapter()
> is called. I guess it might work in this case since you provide your
> own lock vfuncs.
>
> I think someone should fix the i2c core to split i2c_add_adapter()
> & co. into init and register phases. Cc:ing i2c folks...
As you've seen, I sent the patches to split i2c_add_adapter() to allow for
us to call i2c_init_adapter() here instead. It still requires the same
basic review that this init (the same as above) is sufficient for using
i2c_transfer().
I would like to get the regression fix completed without much futher
ado - in particular, not depending upon landing an external patch.
-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] i915/fbc: Disable on HSW by default for now
Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
>
> This was kind of a difficult bug to track down. If you're using a
> Haswell system running GNOME and you have fbc completely enabled and
> working, playing videos can result in video artifacts. Steps to
> reproduce:
>
> - Run GNOME
> - Ensure FBC is enabled and active
> - Download a movie, I used the ogg version of Big Buck Bunny for this
> - Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin !
> glimagesink` in a terminal
> - Watch for about over a minute, you'll see small horizontal lines go
> down the screen.
If you "dmesg | grep -i underrun", do you see anything (even if it
doesn't happen during the moments of corruption)?
Does the problem still happen if you apply these patches?
- https://patchwork.freedesktop.org/patch/79567/
- https://patchwork.freedesktop.org/patch/80857/
- https://patchwork.freedesktop.org/patch/92634/
>
> For the time being, disable FBC for Haswell by default.
In case we want to improve the commit message:
We also got reports from Steven Honeyman on openbox+roxterm, and from
Stefan Richter.
Anyway, there's a regression that needs to be fixed, so:
Reviewed-by: Paulo Zanoni
We can always try again later.
>
> Signed-off-by: Lyude
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 0f0492f..28f4407 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -823,8 +823,7 @@ static bool intel_fbc_can_choose(struct
> intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = crtc->base.dev-
> >dev_private;
> struct intel_fbc *fbc = &dev_priv->fbc;
> - bool enable_by_default = IS_HASWELL(dev_priv) ||
> - IS_BROADWELL(dev_priv);
> + bool enable_by_default = IS_BROADWELL(dev_priv);
>
> if (intel_vgpu_active(dev_priv->dev)) {
> fbc->no_fbc_reason = "VGPU is active";
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps
From: Chris Wilson
... instead of the previous ORIGIN_GTT. This should actually
invalidate FBC once something is written on the frontbuffer using WC
mmaps. The problem with ORIGIN_GTT is that the automatic hardware
tracking is not able to detect the WC writes as it can detect the GTT
writes.
This should help fix the SKL bug where nothing happens when you type
your username/password on lightdm.
This patch was originally pasted on an email by Chris and converted to
an actual git patch by Paulo.
v2 (From Paulo):
- Make it a full variable instead of a bit-field (Daniel)
- Use WRITE_ONCE (Chris)
Cc: Chris Wilson
Reviewed-by: Daniel Vetter
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
2 files changed, 17 insertions(+), 3 deletions(-)
Chris, can you give your Signed-off-by on this patch, please?
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 53d9e3f..20a676d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2204,6 +2204,12 @@ struct drm_i915_gem_object {
unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+ /*
+* IMPORTANT: We have unlocked access to this, this must be a
+* stand-alone bool.
+*/
+ unsigned int has_wc_mmap;
+
unsigned int pin_display;
struct sg_table *pages;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eae8d7a..98389e4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1603,6 +1603,13 @@ static struct intel_rps_client *to_rps_client(struct
drm_file *file)
return &fpriv->rps;
}
+static enum fb_op_origin
+write_origin(struct drm_i915_gem_object *obj, unsigned domain)
+{
+ return domain == I915_GEM_DOMAIN_GTT && !obj->has_wc_mmap ?
+ ORIGIN_GTT : ORIGIN_CPU;
+}
+
/**
* Called when user space prepares to use an object with the CPU, either
* through the mmap ioctl's mapping or a GTT mapping.
@@ -1659,9 +1666,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
if (write_domain != 0)
- intel_fb_obj_invalidate(obj,
- write_domain == I915_GEM_DOMAIN_GTT ?
- ORIGIN_GTT : ORIGIN_CPU);
+ intel_fb_obj_invalidate(obj, write_origin(obj, write_domain));
unref:
drm_gem_object_unreference(&obj->base);
@@ -1768,6 +1773,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
else
addr = -ENOMEM;
up_write(&mm->mmap_sem);
+
+ /* This may race, but that's ok, it only gets set */
+ WRITE_ONCE(to_intel_bo(obj)->has_wc_mmap, true);
}
drm_gem_object_unreference_unlocked(obj);
if (IS_ERR((void *)addr))
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 08/10] drm/i915: Introduce execlist context status change notification
This patch introduces an approach to track the execlist context status
change.
GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.
This function is configurable when creating a new GEM context. Currently,
Only GVT-g will create the "status-change-notification" enabled GEM
context.
v10:
- Fix the identation. (Joonas)
v8:
- Remove the boolean flag in struct i915_gem_context. (Joonas)
v7:
- Remove per-engine ctx status notifiers. Use one status notifier for all
engines. (Joonas)
- Add prefix "INTEL_" for related definitions. (Joonas)
- Refine the comments in execlists_context_status_change(). (Joonas)
v6:
- When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler
could automatically eliminate them for us. (Chris)
- Always initialize the notifier header, so it could be switched on/off
at runtime. (Chris)
v5:
- Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko)
Reviewed-by: Joonas Lahtinen (v8)
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 22 ++
drivers/gpu/drm/i915/intel_lrc.h| 5 +
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9e22200..c14eb56 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -880,6 +880,7 @@ struct i915_gem_context {
} engine[I915_NUM_ENGINES];
u32 ring_size;
u32 desc_template;
+ struct atomic_notifier_head status_notifier;
struct list_head link;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index bd13602..d9e30e1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -298,6 +298,7 @@ __create_hw_context(struct drm_device *dev,
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
+ ATOMIC_INIT_NOTIFIER_HEAD(&ctx->status_notifier);
return ctx;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2116f86..4eed9247 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -404,6 +404,20 @@ static void execlists_submit_requests(struct
drm_i915_gem_request *rq0,
spin_unlock_irq(&dev_priv->uncore.lock);
}
+static inline void execlists_context_status_change(
+ struct drm_i915_gem_request *rq,
+ unsigned long status)
+{
+ /*
+* Only used when GVT-g is enabled now. When GVT-g is disabled,
+* The compiler should eliminate this function as dead-code.
+*/
+ if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
+ return;
+
+ atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq);
+}
+
static void execlists_context_unqueue(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
@@ -439,6 +453,12 @@ static void execlists_context_unqueue(struct
intel_engine_cs *engine)
if (unlikely(!req0))
return;
+ execlists_context_status_change(req0, INTEL_CONTEXT_SCHEDULE_IN);
+
+ if (req1)
+ execlists_context_status_change(req1,
+ INTEL_CONTEXT_SCHEDULE_IN);
+
if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
/*
* WaIdleLiteRestore: make sure we never cause a lite restore
@@ -477,6 +497,8 @@ execlists_check_remove_request(struct intel_engine_cs
*engine, u32 ctx_id)
if (--head_req->elsp_submitted > 0)
return 0;
+ execlists_context_status_change(head_req, INTEL_CONTEXT_SCHEDULE_OUT);
+
list_del(&head_req->execlist_link);
i915_gem_request_unreference(head_req);
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index a8db42a..2b8255c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -57,6 +57,11 @@
#define GEN8_CSB_READ_PTR(csb_status) \
(((csb_status) & GEN8_CSB_READ_PTR_MASK) >> 8)
+enum {
+ INTEL_CONTEXT_SCHEDULE_IN = 0,
+ INTEL_CONTEXT_SCHEDULE_OUT,
+};
+
/* Logical Rings */
int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request);
int intel_logical_ring_reserve_space(struct drm_i915_gem_request *request);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 03/10] drm/i915: Fold vGPU active check into inner functions
v5:
- Let functions take struct drm_i915_private *. (Tvrtko)
- Fold vGPU related active check into the inner functions. (Kevin)
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Suggested-by: Kevin Tian
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Kevin Tian
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ---
drivers/gpu/drm/i915/i915_vgpu.c| 13 +
drivers/gpu/drm/i915/i915_vgpu.h| 4 ++--
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4668477..6f203fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2732,11 +2732,9 @@ static int i915_gem_setup_global_gtt(struct drm_device
*dev,
i915_address_space_init(&ggtt->base, dev_priv);
ggtt->base.total += PAGE_SIZE;
- if (intel_vgpu_active(dev_priv)) {
- ret = intel_vgt_balloon(dev);
- if (ret)
- return ret;
- }
+ ret = intel_vgt_balloon(dev_priv);
+ if (ret)
+ return ret;
if (!HAS_LLC(dev))
ggtt->base.mm.color_adjust = i915_gtt_color_adjust;
@@ -2836,8 +2834,7 @@ void i915_ggtt_cleanup_hw(struct drm_device *dev)
i915_gem_cleanup_stolen(dev);
if (drm_mm_initialized(&ggtt->base.mm)) {
- if (intel_vgpu_active(dev_priv))
- intel_vgt_deballoon();
+ intel_vgt_deballoon(dev_priv);
drm_mm_takedown(&ggtt->base.mm);
list_del(&ggtt->base.global_link);
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index c3c6c64..f6acb5a 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -101,10 +101,13 @@ static struct _balloon_info_ bl_info;
* This function is called to deallocate the ballooned-out graphic memory, when
* driver is unloaded or when ballooning fails.
*/
-void intel_vgt_deballoon(void)
+void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
{
int i;
+ if (!intel_vgpu_active(dev_priv))
+ return;
+
DRM_DEBUG("VGT deballoon.\n");
for (i = 0; i < 4; i++) {
@@ -177,9 +180,8 @@ static int vgt_balloon_space(struct drm_mm *mm,
* Returns:
* zero on success, non-zero if configuration invalid or ballooning failed
*/
-int intel_vgt_balloon(struct drm_device *dev)
+int intel_vgt_balloon(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = &dev_priv->ggtt;
unsigned long ggtt_end = ggtt->base.start + ggtt->base.total;
@@ -187,6 +189,9 @@ int intel_vgt_balloon(struct drm_device *dev)
unsigned long unmappable_base, unmappable_size, unmappable_end;
int ret;
+ if (!intel_vgpu_active(dev_priv))
+ return 0;
+
mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
@@ -258,6 +263,6 @@ int intel_vgt_balloon(struct drm_device *dev)
err:
DRM_ERROR("VGT balloon fail\n");
- intel_vgt_deballoon();
+ intel_vgt_deballoon(dev_priv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_vgpu.h
index 07e67d5..f8917c6 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.h
+++ b/drivers/gpu/drm/i915/i915_vgpu.h
@@ -27,7 +27,7 @@
#include "i915_pvinfo.h"
extern void i915_check_vgpu(struct drm_i915_private *dev_priv);
-extern int intel_vgt_balloon(struct drm_device *dev);
-extern void intel_vgt_deballoon(void);
+extern int intel_vgt_balloon(struct drm_i915_private *dev_priv);
+extern void intel_vgt_deballoon(struct drm_i915_private *dev_priv);
#endif /* _I915_VGPU_H_ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 06/10] drm/i915: Make ring buffer size of a LRC context configurable
This patch introduces an option for configuring the ring buffer size
of a LRC context after the context creation.
v9:
- Fix an identation issue. (Chris)
v8:
- Rename the data member in i915_gem_context. (Chris)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a461486..c3b4009 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -878,6 +878,7 @@ struct i915_gem_context {
int pin_count;
bool initialised;
} engine[I915_NUM_ENGINES];
+ u32 ring_size;
struct list_head link;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index a3b11aa..b722fa1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -295,6 +295,7 @@ __create_hw_context(struct drm_device *dev,
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
+ ctx->ring_size = 4 * PAGE_SIZE;
return ctx;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4fad830..177b61d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2527,7 +2527,7 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
return PTR_ERR(ctx_obj);
}
- ringbuf = intel_engine_create_ringbuffer(engine, 4 * PAGE_SIZE);
+ ringbuf = intel_engine_create_ringbuffer(engine, ctx->ring_size);
if (IS_ERR(ringbuf)) {
ret = PTR_ERR(ringbuf);
goto error_deref_obj;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 09/10] drm/i915: Support LRC context single submission
This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.
Only GVT-g will create this kinds of GEM context currently.
v8:
- Rename the data member in struct i915_gem_context. (Chris)
v7:
- Fix typos in commit message. (Joonas)
v6:
- Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)
v5:
- Only compile this feature when CONFIG_DRM_I915_GVT=y. (Tvrtko)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c14eb56..3026489 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -881,6 +881,7 @@ struct i915_gem_context {
u32 ring_size;
u32 desc_template;
struct atomic_notifier_head status_notifier;
+ bool execlists_force_single_submission;
struct list_head link;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4eed9247..81d9caf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -444,6 +444,21 @@ static void execlists_context_unqueue(struct
intel_engine_cs *engine)
i915_gem_request_unreference(req0);
req0 = cursor;
} else {
+ /* Compiler will do the dead-code elimination */
+ if (IS_ENABLED(CONFIG_DRM_I915_GVT)) {
+ /*
+* req0 (after merged) ctx requires single
+* submission, stop picking
+*/
+ if
(req0->ctx->execlists_force_single_submission)
+ break;
+ /*
+* req0 ctx doesn't require single submission,
+* but next req ctx requires, stop picking
+*/
+ if
(cursor->ctx->execlists_force_single_submission)
+ break;
+ }
req1 = cursor;
WARN_ON(req1->elsp_submitted);
break;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 10/10] drm/i915: Introduce GVT context creation API
GVT workload scheduler needs special host LRC contexts, the so called
"shadow LRC context" to submit guest workload to host i915. During the
guest workload submission, workload scheduler fills the shadow LRC
context with the content of guest LRC context: engine context is copied
without changes, ring context is mostly owned by host i915.
v8:
- Remove the graph temporarily. (Chris)
- Use interruptible mutex_lock. (Chris)
- Rename the function name of creating a GVT context. (Chris)
- Add the missing declaration in i915_drv.h (Chris)
v7:
- Move chart to a better place. (Joonas)
v6:
- Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)
v5:
- Only compile this feature when CONFIG_DRM_I915_GVT is enabled. (Tvrtko)
- Rebase the code into new repo.
- Add a comment about the ring buffer size. (Joonas)
v2:
Mostly based on Daniel's idea. Call the refactored core logic of GEM
context creation service and LRC context creation service to create the GVT
context.
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 34 +
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3026489..0e9459f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3454,6 +3454,8 @@ int i915_switch_context(struct drm_i915_gem_request *req);
void i915_gem_context_free(struct kref *ctx_ref);
struct drm_i915_gem_object *
i915_gem_alloc_context_obj(struct drm_device *dev, size_t size);
+struct i915_gem_context *
+i915_gem_context_create_gvt(struct drm_device *dev);
static inline struct i915_gem_context *
i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index d9e30e1..30d9b4f 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -343,6 +343,40 @@ i915_gem_create_context(struct drm_device *dev,
return ctx;
}
+/**
+ * i915_gem_context_create_gvt - create a GVT GEM context
+ * @dev: drm device *
+ *
+ * This function is used to create a GVT specific GEM context.
+ *
+ * Returns:
+ * pointer to i915_gem_context on success, error pointer if failed
+ *
+ */
+struct i915_gem_context *
+i915_gem_context_create_gvt(struct drm_device *dev)
+{
+ struct i915_gem_context *ctx;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
+ return ERR_PTR(-ENODEV);
+
+ ret = i915_mutex_lock_interruptible(dev);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ctx = i915_gem_create_context(dev, NULL);
+ if (IS_ERR(ctx))
+ goto out;
+
+ ctx->execlists_force_single_submission = true;
+ ctx->ring_size = 512 * PAGE_SIZE; /* Max ring buffer size */
+out:
+ mutex_unlock(&dev->struct_mutex);
+ return ctx;
+}
+
static void i915_gem_context_unpin(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 05/10] drm/i915: Introduce host graphics memory partition for GVT-g
From: Bing Niu
This patch introduces host graphics memory partition when GVT-g
is enabled.
Under GVT-g, i915 host driver only owned limited graphics resources,
others are managed by GVT-g resource allocator and kept for other vGPUs.
v7:
- Add comments about low/high GM size for host. (Joonas)
v6:
- Remove kernel parameters used to configure GGTT owned by host. (Chris)
- Other coding style comments from Chris.
- Add more comments for reviewer.
v3:
- Remove fence partition, will use i915 fence stealing in future.(Kevin)
- Santinize GVT host gm kernel parameters. (Joonas)
v2:
- Address all coding-style comments from Joonas previously.
- Fix errors and warnning reported by checkpatch.pl. (Joonas)
- Move the graphs into the header files. (Daniel)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Kevin Tian
Cc: Daniel Vetter
Signed-off-by: Bing Niu
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_vgpu.c | 23 +--
drivers/gpu/drm/i915/intel_gvt.h | 36
2 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index f6acb5a..019db98 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -189,14 +189,25 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
unsigned long unmappable_base, unmappable_size, unmappable_end;
int ret;
- if (!intel_vgpu_active(dev_priv))
+ if (intel_gvt_active(dev_priv)) {
+ /* Retrieve GGTT partition information from macros */
+ mappable_base = 0;
+ mappable_size = INTEL_GVT_HOST_LOW_GM_SIZE;
+ unmappable_base = dev_priv->ggtt.mappable_end;
+ unmappable_size = INTEL_GVT_HOST_HIGH_GM_SIZE;
+ } else if (intel_vgpu_active(dev_priv)) {
+ /* Retrieve GGTT partition information from PVINFO */
+ mappable_base = I915_READ(
+ vgtif_reg(avail_rs.mappable_gmadr.base));
+ mappable_size = I915_READ(
+ vgtif_reg(avail_rs.mappable_gmadr.size));
+ unmappable_base = I915_READ(
+ vgtif_reg(avail_rs.nonmappable_gmadr.base));
+ unmappable_size = I915_READ(
+ vgtif_reg(avail_rs.nonmappable_gmadr.size));
+ } else
return 0;
- mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
- mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
- unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
- unmappable_size = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.size));
-
mappable_end = mappable_base + mappable_size;
unmappable_end = unmappable_base + unmappable_size;
diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h
index 91e129f..d0d71d1 100644
--- a/drivers/gpu/drm/i915/intel_gvt.h
+++ b/drivers/gpu/drm/i915/intel_gvt.h
@@ -26,6 +26,42 @@
#include "gvt/gvt.h"
+/*
+ * Under GVT-g, i915 host driver only owned limited graphics resources,
+ * others are managed by GVT-g resource allocator and kept for other vGPUs.
+ *
+ * For graphics memory space partition, a typical layout looks like:
+ *
+ * +---+---+--+---+
+ * |* Host | *GVT-g Resource |* Host| *GVT-g Resource |
+ * | Owned | Allocator Managed | Owned| Allocator Managed |
+ * | | | | |
+ * +---+---+--+---+---+
+ * | | | | | | | | |
+ * | i915 | vm 1 | vm 2 | vm 3 | i915 | vm 1 | vm 2 | vm 3 |
+ * | | | | | | | | |
+ * +---+---+---+--+---+---+---+
+ * | Aperture|Hidden|
+ * +---+--+
+ * | GGTT memory space |
+ * +--+
+ */
+
+/* GGTT memory space owned by host */
+/*
+ * This amount is heavily related to the max screen resolution / multiple
+ * display in *host*. If you are using a 4K monitor or multiple display
+ * monitor, probably you should enlarge the low gm size.
+ */
+#define INTEL_GVT_HOST_LOW_GM_SIZE (96 * 1024 * 1024)
+
+/*
+ * This amount is related to the GPU workload in host. If you wish to run
+ * heavy workload like 3D gaming, media transcoding *in host* and encounter
+ * performance drops, probably you should enlarge the high gm size.
+ */
+#define INTEL_GVT_HOST_HIGH_GM_SIZE (384 * 1024 * 1024)
+
#ifdef CONFIG_DRM_I915_GVT
extern int intel_gvt_init(struct drm_i915_private *dev_priv);
extern void intel_
[Intel-gfx] [PATCH v10 07/10] drm/i915: Make addressing mode bits in context descriptor configurable
Currently the addressing mode bit in context descriptor is statically
generated from the configuration of system-wide PPGTT usage model.
GVT-g will load the PPGTT shadow page table by itself and probably one
guest is using a different addressing mode with i915 host. The addressing
mode bits of a LRC context should be configurable under this case.
v10:
- Fix the identation. (Joonas)
v9:
- Rename the data member in struct i915_gem_context. (Chris)
v8:
- Rename the data member in struct i915_gem_context. (Chris)
v7:
- Move context addressing mode bit into i915_reg.h. (Joonas/Chris)
- Add prefix "INTEL_" for related definitions. (Joonas)
v6:
- Directly save the addressing mode bits inside i915_gem_context. (Chris)
- Move the LRC context addressing mode bits into intel_lrc.h. (Chris)
v5:
- Change USES_FULL_48BIT(dev) to USES_FULL_48BIT(dev_priv) (Tvrtko)
Reviewed-by: Joonas Lahtinen (v9)
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_lrc.c| 15 ++-
4 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c3b4009..a9e22200 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,7 @@ struct i915_gem_context {
bool initialised;
} engine[I915_NUM_ENGINES];
u32 ring_size;
+ u32 desc_template;
struct list_head link;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b722fa1..bd13602 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -296,6 +296,8 @@ __create_hw_context(struct drm_device *dev,
ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
ctx->ring_size = 4 * PAGE_SIZE;
+ ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
+GEN8_CTX_ADDRESSING_MODE_SHIFT;
return ctx;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..258c6f1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3033,6 +3033,18 @@ enum skl_disp_power_wells {
/* Same as Haswell, but 72064 bytes now. */
#define GEN8_CXT_TOTAL_SIZE(18 * PAGE_SIZE)
+enum {
+ INTEL_ADVANCED_CONTEXT = 0,
+ INTEL_LEGACY_32B_CONTEXT,
+ INTEL_ADVANCED_AD_CONTEXT,
+ INTEL_LEGACY_64B_CONTEXT
+};
+
+#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
+#define GEN8_CTX_ADDRESSING_MODE(dev_priv) (USES_FULL_48BIT_PPGTT(dev_priv) ?\
+ INTEL_LEGACY_64B_CONTEXT : \
+ INTEL_LEGACY_32B_CONTEXT)
+
#define CHV_CLK_CTL1 _MMIO(0x101100)
#define VLV_CLK_CTL2 _MMIO(0x101104)
#define CLK_CTL2_CZCOUNT_30NS_SHIFT 28
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 177b61d..2116f86 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -208,16 +208,6 @@
} while (0)
enum {
- ADVANCED_CONTEXT = 0,
- LEGACY_32B_CONTEXT,
- ADVANCED_AD_CONTEXT,
- LEGACY_64B_CONTEXT
-};
-#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
-#define GEN8_CTX_ADDRESSING_MODE(dev) (USES_FULL_48BIT_PPGTT(dev) ?\
- LEGACY_64B_CONTEXT :\
- LEGACY_32B_CONTEXT)
-enum {
FAULT_AND_HANG = 0,
FAULT_AND_HALT, /* Debug only */
FAULT_AND_STREAM,
@@ -281,8 +271,6 @@ logical_ring_init_platform_invariants(struct
intel_engine_cs *engine)
(engine->id == VCS || engine->id ==
VCS2);
engine->ctx_desc_template = GEN8_CTX_VALID;
- engine->ctx_desc_template |= GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
- GEN8_CTX_ADDRESSING_MODE_SHIFT;
if (IS_GEN8(dev_priv))
engine->ctx_desc_template |= GEN8_CTX_L3LLC_COHERENT;
engine->ctx_desc_template |= GEN8_CTX_PRIVILEGE;
@@ -325,7 +313,8 @@ intel_lr_context_descriptor_update(struct i915_gem_context
*ctx,
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1desc_template; /* bits 3-4 */
+ desc |= engine->ctx_desc_template; /* bits 0-11 */
desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
/* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT; /* bits 32-52 */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listin
[Intel-gfx] [PATCH v10 02/10] drm/i915: Use offsetof() to calculate the offset of members in PVINFO page
To get the offset of the members in PVINFO page, offsetof() looks much
better than the tricky approach in current code.
v7:
- Move "offsetof()" modification into a dedicated patch. (Joonas)
Suggested-by: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_pvinfo.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index 68bdf60..7b3cec4 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -104,7 +104,7 @@ struct vgt_if {
} __packed;
#define vgtif_reg(x) \
- _MMIO((VGT_PVINFO_PAGE + (long)&((struct vgt_if *)NULL)->x))
+ _MMIO((VGT_PVINFO_PAGE + offsetof(struct vgt_if, x)))
/* vGPU display status to be used by the host side */
#define VGT_DRV_DISPLAY_NOT_READY 0
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 04/10] drm/i915: gvt: Introduce the basic architecture of GVT-g
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
v7:
- Refine the URL link in Kconfig. (Joonas)
- Refine the introduction of GVT-g host support in Kconfig. (Joonas)
- Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas)
- Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas)
- Remove {alloc, free}_gvt_device()
- Rename intel_gvt_{create, destroy}_gvt_device()
- Expost intel_gvt_init_host()
- Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas)
v6:
- Refine introduction in Kconfig. (Chris)
- The exposed API functions will take struct intel_gvt * instead of
void *. (Chris/Tvrtko)
- Remove most memebers of strct intel_gvt_device_info. Will add them
in the device model patches.(Chris)
- Remove gvt_info() and gvt_err() in debug.h. (Chris)
- Move GVT kernel parameter into i915_params. (Chris)
- Remove include/drm/i915_gvt.h, as GVT-g will be built within i915.
- Remove the redundant struct i915_gvt *, as the functions in i915
will directly take struct intel_gvt *.
- Add more comments for reviewer.
v5:
Take Tvrtko's comments:
- Fix the misspelled words in Kconfig
- Let functions take drm_i915_private * instead of struct drm_device *
- Remove redundant prints/local varible initialization
v3:
Take Joonas' comments:
- Change file name i915_gvt.* to intel_gvt.*
- Move GVT kernel parameter into intel_gvt.c
- Remove redundant debug macros
- Change error handling style
- Add introductions for some stub functions
- Introduce drm/i915_gvt.h.
Take Kevin's comments:
- Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c
v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled, the
stubs here do nothing.
Take Joonas' comments:
- Replace boolean return value with int.
- Replace customized info/warn/debug macros with DRM macros.
- Document all non-static functions like i915.
- Remove empty and unused functions.
- Replace magic number with marcos.
- Set GVT-g in kernel config to "n" by default.
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Kevin Tian
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/Kconfig | 22 ++
drivers/gpu/drm/i915/Makefile| 5 ++
drivers/gpu/drm/i915/gvt/Makefile| 5 ++
drivers/gpu/drm/i915/gvt/debug.h | 34
drivers/gpu/drm/i915/gvt/gvt.c | 145 +++
drivers/gpu/drm/i915/gvt/gvt.h | 69 +
drivers/gpu/drm/i915/gvt/hypercall.h | 38 +
drivers/gpu/drm/i915/gvt/mpt.h | 49
drivers/gpu/drm/i915/i915_dma.c | 16 +++-
drivers/gpu/drm/i915/i915_drv.h | 10 +++
drivers/gpu/drm/i915/i915_params.c | 5 ++
drivers/gpu/drm/i915/i915_params.h | 1 +
drivers/gpu/drm/i915/intel_gvt.c | 100
drivers/gpu/drm/i915/intel_gvt.h | 45 +++
14 files changed, 540 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
create mode 100644 drivers/gpu/drm/i915/intel_gvt.c
create mode 100644 drivers/gpu/drm/i915/intel_gvt.h
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 29a32b1..7769e46 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -57,6 +57,28 @@ config DRM_I915_USERPTR
If in doubt, say "Y".
+config DRM_I915_GVT
+bool "Enable Intel GVT-g graphics virtualization host support"
+depends on DRM_I915
+default n
+help
+ Choose this option if you want to enable Intel GVT-g graphics
+ virtualization technology host support with integrated graphics.
+ With GVT-g, it's possible to have one integrated graphics
+ device shared by multiple VMs under different hypervisors.
+
+ Note that at least one hypervisor like Xen or KVM is required for
+ this driver to work, and it only supports newer device from
+ Broadwell+. For further information and setup guide, you can
+ visit: http://01.org/igvt-g.
+
+ Now it's just a stub to support the modifications of i915 for
+ GVT device model. It requires at least one MPT modules for Xen/KVM
+ and other components of GVT device model to work. Use it under
+ you own risk.
+
+ If in doubt, say "N".
+
menu "drm/i915 Debugging"
depends on DRM_I915
depends on EXPERT
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i9
[Intel-gfx] [PATCH v10 01/10] drm/i915: Factor out i915_pvinfo.h
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.
v7:
- Split the "offsetof" modification into a dedicated patch. (Joonas)
v3:
- Use offsetof to calculate the member offset of PVINFO structure (Joonas)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_pvinfo.h | 113 +
drivers/gpu/drm/i915/i915_vgpu.h | 86 +---
2 files changed, 114 insertions(+), 85 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_pvinfo.h
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
new file mode 100644
index 000..68bdf60
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -0,0 +1,113 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+#ifndef _I915_PVINFO_H_
+#define _I915_PVINFO_H_
+
+/* The MMIO offset of the shared info between guest and host emulator */
+#define VGT_PVINFO_PAGE0x78000
+#define VGT_PVINFO_SIZE0x1000
+
+/*
+ * The following structure pages are defined in GEN MMIO space
+ * for virtualization. (One page for now)
+ */
+#define VGT_MAGIC 0x4776544776544776ULL/* 'vGTvGTvG' */
+#define VGT_VERSION_MAJOR 1
+#define VGT_VERSION_MINOR 0
+
+#define INTEL_VGT_IF_VERSION_ENCODE(major, minor) ((major) << 16 | (minor))
+#define INTEL_VGT_IF_VERSION \
+ INTEL_VGT_IF_VERSION_ENCODE(VGT_VERSION_MAJOR, VGT_VERSION_MINOR)
+
+/*
+ * notifications from guest to vgpu device model
+ */
+enum vgt_g2v_type {
+ VGT_G2V_PPGTT_L3_PAGE_TABLE_CREATE = 2,
+ VGT_G2V_PPGTT_L3_PAGE_TABLE_DESTROY,
+ VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE,
+ VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,
+ VGT_G2V_EXECLIST_CONTEXT_CREATE,
+ VGT_G2V_EXECLIST_CONTEXT_DESTROY,
+ VGT_G2V_MAX,
+};
+
+struct vgt_if {
+ uint64_t magic; /* VGT_MAGIC */
+ uint16_t version_major;
+ uint16_t version_minor;
+ uint32_t vgt_id;/* ID of vGT instance */
+ uint32_t rsv1[12]; /* pad to offset 0x40 */
+ /*
+* Data structure to describe the balooning info of resources.
+* Each VM can only have one portion of continuous area for now.
+* (May support scattered resource in future)
+* (starting from offset 0x40)
+*/
+ struct {
+ /* Aperture register balooning */
+ struct {
+ uint32_t base;
+ uint32_t size;
+ } mappable_gmadr; /* aperture */
+ /* GMADR register balooning */
+ struct {
+ uint32_t base;
+ uint32_t size;
+ } nonmappable_gmadr;/* non aperture */
+ /* allowed fence registers */
+ uint32_t fence_num;
+ uint32_t rsv2[3];
+ } avail_rs; /* available/assigned resource */
+ uint32_t rsv3[0x200 - 24]; /* pad to half page */
+ /*
+* The bottom half page is for response from Gfx driver to hypervisor.
+*/
+ uint32_t rsv4;
+ uint32_t display_ready; /* ready for display owner switch */
+
+ uint32_t rsv5[4];
+
+ uint32_t g2v_notify;
+ uint32_t rsv6[7];
+
+ struct {
+ uint32_t lo;
+ uint32_t hi;
+ } pdp[4];
+
+ uint32_t execlist_context_descriptor_lo;
+ uint32_t execlist_context_descriptor_hi;
+
+ uint32_t rsv7[0x200 - 24];/* pad to one page */
+} __packed;
+
+#define vgtif_reg(x) \
+ _MMIO((VGT_PVINFO_PAGE + (long)&((struct vgt_if *)NULL)->x))
+
+/* vGPU display status to be used by the host side */
+#define VGT_DRV_DISPLAY_NOT_READY 0
+#de
[Intel-gfx] [PATCH v10 00/10] Introduce the implementation of GVT context
This patchset introduces the implementation of GVT context. GVT context is a special GEM context used by GVT-g. GVT-g uses it as the shadow context.It doesn't have a drm client nor a PPGTT. And it requires a larger ring buffer with several special features need by GVT-g workload scheduler like context status change notification, context single submission... ABAT results and link: Series: Introduce the implementation of GVT context URL : https://patchwork.freedesktop.org/series/8470/ State : success v10: - Take Joonas' comments. v9: - Take Chris' comments. v8: - Take Joonas/Chris's comments. v7: - Take Joonas comments. v6: - Take Chris comments. v5: - Drop PPGTT related patches. - Let most functions take struct drm_i915_private * - Fixed some misspelled words in Kconfig - Only complied some feature when CONFIG_DRM_I915_GVT=y - Drop the fecne related changes, will send it after this series. v4: - Based on the latest drm-intel-nightly branch. - Drop PPGTT refactor patches. (GVT-g will use LRI to load PDPs) - Drop i915_gem_context() refactor patches, reuse kernel context functions. (Dave Gordon) - Drop context allocation params and refactor as the lrc deferred allocation function has been refactored in another styles. - Re-wrtie GVT context creation function Difference from community release - This patchset is different from regular iGVT-g code release[4], which is still based on old host-mediated architecture. Furthermore, this patchset only supports BDW whereas code release supports HSW/BDW/SKL. We will add SKL support later based on this RFC code and HSW support will be dropped. Internally we tested this RFC patchset with both linux and windows VM and the architecture changes work fine. Acknowledgment --- iGVT-g implementation is several years effort and many people contributed to the code. There names are not here yet. In later formal patchset we will reflect individual's contribution. Meanwhile, in the previous iGVT-g related discussion, Daniel, Chris and Joonas ever gave very good inputs. We appreciate them and look forward to more comments/suggestions from community. We are trying to get more familiar with i915 but may still have gaps. We are willing to adopt suggestions to keep improving. We hope to work with community together to make iGVT-g a great component in i915 to support graphics virtualization. Thanks! Reference - [1] https://01.org/igvt-g [2] http://lists.freedesktop.org/archives/intel-gfx/2014-September/053098.html [3] http://lists.freedesktop.org/archives/intel-gfx/2015-September/075397.html Bing Niu (1): drm/i915: Introduce host graphics memory partition for GVT-g Zhi Wang (9): drm/i915: Factor out i915_pvinfo.h drm/i915: Use offsetof() to calculate the offset of members in PVINFO page drm/i915: Fold vGPU active check into inner functions drm/i915: gvt: Introduce the basic architecture of GVT-g drm/i915: Make ring buffer size of a LRC context configurable drm/i915: Make addressing mode bits in context descriptor configurable drm/i915: Introduce execlist context status change notification drm/i915: Support LRC context single submission drm/i915: Introduce GVT context creation API drivers/gpu/drm/i915/Kconfig| 22 + drivers/gpu/drm/i915/Makefile | 5 ++ drivers/gpu/drm/i915/gvt/Makefile | 5 ++ drivers/gpu/drm/i915/gvt/debug.h| 34 drivers/gpu/drm/i915/gvt/gvt.c | 145 drivers/gpu/drm/i915/gvt/gvt.h | 69 +++ drivers/gpu/drm/i915/gvt/hypercall.h| 38 + drivers/gpu/drm/i915/gvt/mpt.h | 49 +++ drivers/gpu/drm/i915/i915_dma.c | 16 +++- drivers/gpu/drm/i915/i915_drv.h | 16 drivers/gpu/drm/i915/i915_gem_context.c | 38 + drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +-- drivers/gpu/drm/i915/i915_params.c | 5 ++ drivers/gpu/drm/i915/i915_params.h | 1 + drivers/gpu/drm/i915/i915_pvinfo.h | 113 + drivers/gpu/drm/i915/i915_reg.h | 12 +++ drivers/gpu/drm/i915/i915_vgpu.c| 32 +-- drivers/gpu/drm/i915/i915_vgpu.h| 90 +--- drivers/gpu/drm/i915/intel_gvt.c| 100 ++ drivers/gpu/drm/i915/intel_gvt.h| 81 ++ drivers/gpu/drm/i915/intel_lrc.c| 54 +--- drivers/gpu/drm/i915/intel_lrc.h| 5 ++ 22 files changed, 821 insertions(+), 120 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/Makefile create mode 100644 drivers/gpu/drm/i915/gvt/debug.h create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h create mode 100644 drivers/gpu/drm/i915/i915_pvinfo.h create mode 100644 drivers/gpu/drm/
Re: [Intel-gfx] Screen update issue (drm/i915/fbc: enable FBC by default on HSW and BDW)
On 9 June 2016 at 15:49, Zanoni, Paulo R wrote: > Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu: >> Hi, > > Hi > > CC'ing the mailing list. > >> >> With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by >> default, I get a strange issue with screen update/refresh (sorry if >> my >> terminology is off - I'm not a graphics dev!). >> Here's how it went (all in the past few hours): >> >> Kernel 4.5.5 (before the patch) - everything OK. >> Kernel 4.6.2 - In a terminal window (openbox+roxterm or tilda, if >> that >> matters), the screen only updated approx 1 or 2 times per second when >> typing (e.g. hold a key and they appear in chunks of 15-20!). Holding >> a key and moving the mouse, appears fine. >> Kernel 4.6.1 - (same as 4.6.2, but I had to try) >> Kernel 4.7-rc2 - Same refresh/update problem, but this time moving >> the >> mouse had no effect. >> Spent 5 mins googling, found your patch, applied i915.enable_fbc=0 >> and >> 4.7-rc2 behaves as it should. >> >> So in response to your suggestions for debugging this made in the >> commit message, I swapped out the boot parameter for drm.debug=0xe, >> but apart from the stuff at startup I got nothing extra after >> reproducing the problem. >> Your suggestions make it sound like you might expect something >> 'major' >> to go wrong, infrequently... however this is always apparent, and >> (fairly) minor. >> >> Hardware is a Dell E6540, Haswell i5 with Intel graphics. FHD eDP >> panel + external FHD DVI screen. >> Please let me know if there's any other info you want. > > Please boot with i915.enable_fbc=1 drm.debug=0xe, reproduce the problem > and check if there is any dmesg line mentioning "FIFO underruns". > > Also, which distro version are you using? Are you using xf86-video- > intel? Maybe also grab /var/log/Xorg.0.log. > > Perhaps it would be better if you open a bug on bugs.freedesktop.org, > attach the relevant information, and provide me the link to the bug > report. It's better to track bugs there. Thanks - done: https://bugs.freedesktop.org/show_bug.cgi?id=96464 > > Anyway, I should submit a patch reverting FBC on stable Kernels. > > Thanks, > Paulo > >> >> >> Thanks, >> Steven ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 1/6] drm/i915: Add per context timelines for fence objects
On 07/06/2016 12:17, Maarten Lankhorst wrote:
Op 01-06-16 om 19:07 schreef john.c.harri...@intel.com:
From: John Harrison
The purpose of this patch series is to convert the requst structure to
use fence objects for the underlying completion tracking. The fence
object requires a sequence number. The ultimate aim is to use the same
sequence number as for the request itself (or rather, to remove the
request's seqno field and just use the fence's value throughout the
driver). However, this is not currently possible and so this patch
introduces a separate numbering scheme as an intermediate step.
A major advantage of using the fence object is that it can be passed
outside of the i915 driver and used externally. The fence API allows
for various operations such as combining multiple fences. This
requires that fence seqnos within a single fence context be guaranteed
in-order. The GPU scheduler that is coming can re-order request
execution but not within a single GPU context. Thus the fence context
must be tied to the i915 context (and the engine within the context as
each engine runs asynchronously).
On the other hand, the driver as a whole currently only works with
request seqnos that are allocated from a global in-order timeline. It
will require a fair chunk of re-work to allow multiple independent
seqno timelines to be used. Hence the introduction of a temporary,
fence specific timeline. Once the work to update the rest of the
driver has been completed then the request can use the fence seqno
instead.
v2: New patch in series.
v3: Renamed/retyped timeline structure fields after review comments by
Tvrtko Ursulin.
Added context information to the timeline's name string for better
identification in debugfs output.
v5: Line wrapping and other white space fixes to keep style checker
happy.
v7: Updated to newer nightly (lots of ring -> engine renaming).
v8: Moved to earlier in patch series so no longer needs to remove the
quick hack timeline that was being added before.
v9: Updated to another newer nightly (changes to context structure
naming). Also updated commit message to match previous changes.
For: VIZ-5190
Signed-off-by: John Harrison
Cc: Tvrtko Ursulin
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 14
drivers/gpu/drm/i915/i915_gem.c | 40 +
drivers/gpu/drm/i915/i915_gem_context.c | 16 +
drivers/gpu/drm/i915/intel_lrc.c| 8 +++
4 files changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2a88a46..a5f8ad8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -831,6 +831,19 @@ struct i915_ctx_hang_stats {
bool banned;
};
+struct i915_fence_timeline {
+ charname[32];
+ unsignedfence_context;
Should be a u64 now, since commit 76bf0db5543976ef50362db7071da367cb118532
Yeah, that's newer than the tree these patches are based on. Will update
and rebase...
+ unsignednext;
+
+ struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+};
+
+int i915_create_fence_timeline(struct drm_device *dev,
+ struct i915_gem_context *ctx,
+ struct intel_engine_cs *ring);
+
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
@@ -875,6 +888,7 @@ struct i915_gem_context {
u64 lrc_desc;
int pin_count;
bool initialised;
+ struct i915_fence_timeline fence_timeline;
} engine[I915_NUM_ENGINES];
struct list_head link;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5ffc6fa..57d3593 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2743,6 +2743,46 @@ void i915_gem_request_free(struct kref *req_ref)
kmem_cache_free(req->i915->requests, req);
}
+int i915_create_fence_timeline(struct drm_device *dev,
+ struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+ struct i915_fence_timeline *timeline;
+
+ timeline = &ctx->engine[engine->id].fence_timeline;
+
+ if (timeline->engine)
+ return 0;
Do you ever expect a reinit?
No. Will change to a WARN_ON as per Tvrtko's comment.
+ timeline->fence_context = fence_context_alloc(1);
+
+ /*
+* Start the timeline from seqno 0 as this is a special value
+* that is reserved for invalid sync points.
+*/
+ timeline->next = 1;
+ timeline->ctx= ctx;
+ timeline->engine = engine;
+
+ snprintf(timeline->name, sizeof(timeline->name), "%d>%s:%d",
+timeline->fence_context, engine->name, ctx->user_handle);
+
+ return 0;
+}
+
On top of the other comments, you
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue
On Wed, Jun 8, 2016 at 12:18 PM, Dave Gordon wrote: > On 08/06/16 09:40, Daniel Vetter wrote: >> >> On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote: >>> >>> CHV pipe C hits underrun when we get -ve X values of cursor. To avoid >>> this we crop the cursor image for by -ve X value and thus use '0' as >>> least X value. >> >> >> You're talking about "-ve" here and there's absolutely no "-ve" anywhere >> in your patch. That makes your commit message non-understandable. > > > That's shorthand for "negative", and some of the code below is indeed > testing for a negative X coordinate, e.g: Just type it out, thanks. Not everyone is a native speaker and knows all this stuff. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915/ilk: Don't disable SSC source if it's in use"
This reverts commit f165d2834ceb3d5c29bebadadc27629bebf402ac.
It breaks one of our CI systems. Quoting from Ville:
[ 13.100979] [drm:ironlake_init_pch_refclk] has_panel 1 has_lvds 1 has_ck505
0 using_ssc_source 1
[ 13.101413] [ cut here ]
[ 13.101429] kernel BUG at drivers/gpu/drm/i915/intel_display.c:8528!
"which is the 'BUG_ON(val != final)' at the end of ironlake_init_pch_refclk()."
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Lyude
Cc: marius.c.v...@intel.com
References: https://www.spinics.net/lists/dri-devel/msg109557.html
Acked-by: Lyude
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 49 ++--
1 file changed, 13 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 12ff79594bc1..473c8fdb38b9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8361,14 +8361,12 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *encoder;
- int i;
u32 val, final;
bool has_lvds = false;
bool has_cpu_edp = false;
bool has_panel = false;
bool has_ck505 = false;
bool can_ssc = false;
- bool using_ssc_source = false;
/* We need to take the global config into account */
for_each_intel_encoder(dev, encoder) {
@@ -8395,22 +8393,8 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
can_ssc = true;
}
- /* Check if any DPLLs are using the SSC source */
- for (i = 0; i < dev_priv->num_shared_dpll; i++) {
- u32 temp = I915_READ(PCH_DPLL(i));
-
- if (!(temp & DPLL_VCO_ENABLE))
- continue;
-
- if ((temp & PLL_REF_INPUT_MASK) ==
- PLLB_REF_INPUT_SPREADSPECTRUMIN) {
- using_ssc_source = true;
- break;
- }
- }
-
- DRM_DEBUG_KMS("has_panel %d has_lvds %d has_ck505 %d using_ssc_source
%d\n",
- has_panel, has_lvds, has_ck505, using_ssc_source);
+ DRM_DEBUG_KMS("has_panel %d has_lvds %d has_ck505 %d\n",
+ has_panel, has_lvds, has_ck505);
/* Ironlake: try to setup display ref clock before DPLL
* enabling. This is only under driver's control after
@@ -8430,12 +8414,9 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
else
final |= DREF_NONSPREAD_SOURCE_ENABLE;
+ final &= ~DREF_SSC_SOURCE_MASK;
final &= ~DREF_CPU_SOURCE_OUTPUT_MASK;
-
- if (!using_ssc_source) {
- final &= ~DREF_SSC_SOURCE_MASK;
- final &= ~DREF_SSC1_ENABLE;
- }
+ final &= ~DREF_SSC1_ENABLE;
if (has_panel) {
final |= DREF_SSC_SOURCE_ENABLE;
@@ -8498,7 +8479,7 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
POSTING_READ(PCH_DREF_CONTROL);
udelay(200);
} else {
- DRM_DEBUG_KMS("Disabling CPU source output\n");
+ DRM_DEBUG_KMS("Disabling SSC entirely\n");
val &= ~DREF_CPU_SOURCE_OUTPUT_MASK;
@@ -8509,20 +8490,16 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
POSTING_READ(PCH_DREF_CONTROL);
udelay(200);
- if (!using_ssc_source) {
- DRM_DEBUG_KMS("Disabling SSC source\n");
-
- /* Turn off the SSC source */
- val &= ~DREF_SSC_SOURCE_MASK;
- val |= DREF_SSC_SOURCE_DISABLE;
+ /* Turn off the SSC source */
+ val &= ~DREF_SSC_SOURCE_MASK;
+ val |= DREF_SSC_SOURCE_DISABLE;
- /* Turn off SSC1 */
- val &= ~DREF_SSC1_ENABLE;
+ /* Turn off SSC1 */
+ val &= ~DREF_SSC1_ENABLE;
- I915_WRITE(PCH_DREF_CONTROL, val);
- POSTING_READ(PCH_DREF_CONTROL);
- udelay(200);
- }
+ I915_WRITE(PCH_DREF_CONTROL, val);
+ POSTING_READ(PCH_DREF_CONTROL);
+ udelay(200);
}
BUG_ON(val != final);
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: warning for i915/fbc: Disable on HSW by default for now
== Series Details == Series: i915/fbc: Disable on HSW by default for now URL : https://patchwork.freedesktop.org/series/8503/ State : warning == Summary == Series 8503v1 i915/fbc: Disable on HSW by default for now http://patchwork.freedesktop.org/api/1.0/series/8503/revisions/1/mbox Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> SKIP (ro-bdw-i7-5557U) dmesg-warn -> SKIP (ro-bdw-i5-5250u) Subgroup suspend-read-crc-pipe-c: skip -> DMESG-WARN (ro-bdw-i5-5250u) fi-bdw-i7-5557u total:213 pass:201 dwarn:0 dfail:0 fail:0 skip:12 fi-skl-i5-6260u total:213 pass:202 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-i7-6700k total:213 pass:188 dwarn:0 dfail:0 fail:0 skip:25 fi-snb-i7-2600 total:213 pass:174 dwarn:0 dfail:0 fail:0 skip:39 ro-bdw-i5-5250u total:213 pass:197 dwarn:3 dfail:0 fail:0 skip:13 ro-bdw-i7-5557U total:213 pass:197 dwarn:2 dfail:0 fail:0 skip:14 ro-bdw-i7-5600u total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-bsw-n3050 total:213 pass:172 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:213 pass:173 dwarn:0 dfail:0 fail:3 skip:37 ro-hsw-i3-4010u total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk1-i5-650 total:208 pass:150 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:213 pass:181 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-snb-i7-2620M total:213 pass:174 dwarn:0 dfail:0 fail:1 skip:38 fi-hsw-i7-4770k failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_1150/ 487a126 drm-intel-nightly: 2016y-06m-09d-10h-05m-55s UTC integration manifest 432cf03 i915/fbc: Disable on HSW by default for now ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 1/6] drm/i915: Add per context timelines for fence objects
On 02/06/2016 11:28, Tvrtko Ursulin wrote:
On 01/06/16 18:07, john.c.harri...@intel.com wrote:
From: John Harrison
The purpose of this patch series is to convert the requst structure to
use fence objects for the underlying completion tracking. The fence
object requires a sequence number. The ultimate aim is to use the same
sequence number as for the request itself (or rather, to remove the
request's seqno field and just use the fence's value throughout the
driver). However, this is not currently possible and so this patch
introduces a separate numbering scheme as an intermediate step.
A major advantage of using the fence object is that it can be passed
outside of the i915 driver and used externally. The fence API allows
for various operations such as combining multiple fences. This
requires that fence seqnos within a single fence context be guaranteed
in-order. The GPU scheduler that is coming can re-order request
execution but not within a single GPU context. Thus the fence context
must be tied to the i915 context (and the engine within the context as
each engine runs asynchronously).
On the other hand, the driver as a whole currently only works with
request seqnos that are allocated from a global in-order timeline. It
will require a fair chunk of re-work to allow multiple independent
seqno timelines to be used. Hence the introduction of a temporary,
fence specific timeline. Once the work to update the rest of the
driver has been completed then the request can use the fence seqno
instead.
v2: New patch in series.
v3: Renamed/retyped timeline structure fields after review comments by
Tvrtko Ursulin.
Added context information to the timeline's name string for better
identification in debugfs output.
v5: Line wrapping and other white space fixes to keep style checker
happy.
v7: Updated to newer nightly (lots of ring -> engine renaming).
v8: Moved to earlier in patch series so no longer needs to remove the
quick hack timeline that was being added before.
v9: Updated to another newer nightly (changes to context structure
naming). Also updated commit message to match previous changes.
For: VIZ-5190
Signed-off-by: John Harrison
Cc: Tvrtko Ursulin
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_drv.h | 14
drivers/gpu/drm/i915/i915_gem.c | 40
+
drivers/gpu/drm/i915/i915_gem_context.c | 16 +
drivers/gpu/drm/i915/intel_lrc.c| 8 +++
4 files changed, 78 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 2a88a46..a5f8ad8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -831,6 +831,19 @@ struct i915_ctx_hang_stats {
bool banned;
};
+struct i915_fence_timeline {
+charname[32];
+unsignedfence_context;
+unsignednext;
+
+struct i915_gem_context *ctx;
+struct intel_engine_cs *engine;
Are these backpointers used in the patch series? I did a quick search
with the "timeline->" string and did not find anything.
Hmm, not any more it seems. Will remove them.
+};
+
+int i915_create_fence_timeline(struct drm_device *dev,
+ struct i915_gem_context *ctx,
+ struct intel_engine_cs *ring);
+
/* This must match up with the value previously used for
execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
@@ -875,6 +888,7 @@ struct i915_gem_context {
u64 lrc_desc;
int pin_count;
bool initialised;
+struct i915_fence_timeline fence_timeline;
} engine[I915_NUM_ENGINES];
struct list_head link;
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 5ffc6fa..57d3593 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2743,6 +2743,46 @@ void i915_gem_request_free(struct kref *req_ref)
kmem_cache_free(req->i915->requests, req);
}
+int i915_create_fence_timeline(struct drm_device *dev,
dev is not used in the function. Maybe it will be in later patches? In
which case I think dev_priv is the current bkm for i915
specific/internal code.
Again, it is left over from a previous implementation and could actually
be removed.
+ struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine)
+{
+struct i915_fence_timeline *timeline;
+
+timeline = &ctx->engine[engine->id].fence_timeline;
+
+if (timeline->engine)
+return 0;
Is this an expected case? Unless I am missing something it shouldn't
be so maybe a WARN_ON would be warranted?
No. Will make it a WARN instead.
+
+timeline->fence_context = fence_context_alloc(1);
+
+/*
+ * Start the timeline from seqno 0 as this is a special value
+ * that is reserved for invalid sync points.
+ */
Comment and init to 1 below look in disagreement. Maybe comment should
be something like "Start the timeline from
[Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now
From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
This was kind of a difficult bug to track down. If you're using a
Haswell system running GNOME and you have fbc completely enabled and
working, playing videos can result in video artifacts. Steps to
reproduce:
- Run GNOME
- Ensure FBC is enabled and active
- Download a movie, I used the ogg version of Big Buck Bunny for this
- Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin !
glimagesink` in a terminal
- Watch for about over a minute, you'll see small horizontal lines go
down the screen.
For the time being, disable FBC for Haswell by default.
Signed-off-by: Lyude
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_fbc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 0f0492f..28f4407 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -823,8 +823,7 @@ static bool intel_fbc_can_choose(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct intel_fbc *fbc = &dev_priv->fbc;
- bool enable_by_default = IS_HASWELL(dev_priv) ||
-IS_BROADWELL(dev_priv);
+ bool enable_by_default = IS_BROADWELL(dev_priv);
if (intel_vgpu_active(dev_priv->dev)) {
fbc->no_fbc_reason = "VGPU is active";
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_workarounds: reduce scope of intel_register_access_init
https://paste.fedoraproject.org/376691/ On 9 June 2016 at 16:22, Chris Wilson wrote: > On Thu, Jun 09, 2016 at 04:02:26PM +0100, Matthew Auld wrote: >> Well, at least for me having the global forcewake produces a kernel >> warning during the suspend-resume test case. > > If userspace can trigger a kernel warning, we fix the kernel... > > Except this is debugfs, and if necessary we can caveat by saying don't > do that if necessary. On resume, we take action to try and restore the > userspace forcewake count, so what's the exact warning? > -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] tests/gem_workarounds: reduce scope of intel_register_access_init
On Thu, Jun 09, 2016 at 04:02:26PM +0100, Matthew Auld wrote: > Well, at least for me having the global forcewake produces a kernel > warning during the suspend-resume test case. If userspace can trigger a kernel warning, we fix the kernel... Except this is debugfs, and if necessary we can caveat by saying don't do that if necessary. On resume, we take action to try and restore the userspace forcewake count, so what's the exact warning? -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] ✗ Ro.CI.BAT: warning for drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate (rev2)
== Series Details == Series: drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate (rev2) URL : https://patchwork.freedesktop.org/series/8487/ State : warning == Summary == Series 8487v2 drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate http://patchwork.freedesktop.org/api/1.0/series/8487/revisions/2/mbox Test gem_exec_flush: Subgroup basic-batch-kernel-default-cmd: fail -> PASS (ro-byt-n2820) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-snb-i7-2600) Subgroup suspend-read-crc-pipe-c: skip -> DMESG-WARN (ro-bdw-i5-5250u) fi-bdw-i7-5557u total:213 pass:201 dwarn:0 dfail:0 fail:0 skip:12 fi-skl-i5-6260u total:213 pass:202 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-i7-6700k total:213 pass:188 dwarn:0 dfail:0 fail:0 skip:25 fi-snb-i7-2600 total:213 pass:173 dwarn:1 dfail:0 fail:0 skip:39 ro-bdw-i5-5250u total:213 pass:197 dwarn:4 dfail:0 fail:0 skip:12 ro-bdw-i7-5600u total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-bsw-n3050 total:213 pass:172 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:213 pass:174 dwarn:0 dfail:0 fail:2 skip:37 ro-hsw-i7-4770r total:213 pass:190 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk1-i5-650 total:208 pass:150 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:213 pass:181 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:213 pass:185 dwarn:0 dfail:0 fail:0 skip:28 ro-snb-i7-2620M total:213 pass:174 dwarn:0 dfail:0 fail:1 skip:38 fi-hsw-i7-4770k failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_1149/ 487a126 drm-intel-nightly: 2016y-06m-09d-10h-05m-55s UTC integration manifest 6755d5e drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_workarounds: reduce scope of intel_register_access_init
Well, at least for me having the global forcewake produces a kernel warning during the suspend-resume test case. On 9 June 2016 at 15:53, Chris Wilson wrote: > On Thu, Jun 09, 2016 at 03:33:47PM +0100, Matthew Auld wrote: >> We shouldn't be holding the forcewake whilst going through suspend-resume >> cycle > > Why not? That's legal behaviour, the kernel should be restoring the user > forcewake setting and there should be igt for that already - otherwise > we have some rather scary code in intel_uncore.c that isn't being > exercised. > -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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_workarounds: reduce scope of intel_register_access_init
On Thu, Jun 09, 2016 at 03:33:47PM +0100, Matthew Auld wrote: > We shouldn't be holding the forcewake whilst going through suspend-resume > cycle Why not? That's legal behaviour, the kernel should be restoring the user forcewake setting and there should be igt for that already - otherwise we have some rather scary code in intel_uncore.c that isn't being exercised. -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 v2] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
v2: move to gen9_init_workarounds (Arun)
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
#define GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
#define GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))
+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
/* WaClearTdlStateAckDirtyBits */
#define GEN8_STATE_ACK _MMIO(0x20F0)
#define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cf8d0bf..7c756ac 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1022,6 +1022,9 @@ static int gen9_init_workarounds(struct intel_engine_cs
*engine)
if (ret)
return ret;
+ /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
+ I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+
return 0;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Screen update issue (drm/i915/fbc: enable FBC by default on HSW and BDW)
Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu: > Hi, Hi CC'ing the mailing list. > > With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by > default, I get a strange issue with screen update/refresh (sorry if > my > terminology is off - I'm not a graphics dev!). > Here's how it went (all in the past few hours): > > Kernel 4.5.5 (before the patch) - everything OK. > Kernel 4.6.2 - In a terminal window (openbox+roxterm or tilda, if > that > matters), the screen only updated approx 1 or 2 times per second when > typing (e.g. hold a key and they appear in chunks of 15-20!). Holding > a key and moving the mouse, appears fine. > Kernel 4.6.1 - (same as 4.6.2, but I had to try) > Kernel 4.7-rc2 - Same refresh/update problem, but this time moving > the > mouse had no effect. > Spent 5 mins googling, found your patch, applied i915.enable_fbc=0 > and > 4.7-rc2 behaves as it should. > > So in response to your suggestions for debugging this made in the > commit message, I swapped out the boot parameter for drm.debug=0xe, > but apart from the stuff at startup I got nothing extra after > reproducing the problem. > Your suggestions make it sound like you might expect something > 'major' > to go wrong, infrequently... however this is always apparent, and > (fairly) minor. > > Hardware is a Dell E6540, Haswell i5 with Intel graphics. FHD eDP > panel + external FHD DVI screen. > Please let me know if there's any other info you want. Please boot with i915.enable_fbc=1 drm.debug=0xe, reproduce the problem and check if there is any dmesg line mentioning "FIFO underruns". Also, which distro version are you using? Are you using xf86-video- intel? Maybe also grab /var/log/Xorg.0.log. Perhaps it would be better if you open a bug on bugs.freedesktop.org, attach the relevant information, and provide me the link to the bug report. It's better to track bugs there. Anyway, I should submit a patch reverting FBC on stable Kernels. Thanks, Paulo > > > Thanks, > Steven ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/gem_workarounds: reduce scope of intel_register_access_init
We shouldn't be holding the forcewake whilst going through suspend-resume
cycle, so instead of globally holding the forcewake we reduce this to
when we actually need to read the registers.
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
tests/gem_workarounds.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
index e419e8b..74799fd 100644
--- a/tests/gem_workarounds.c
+++ b/tests/gem_workarounds.c
@@ -67,6 +67,8 @@ static int workaround_fail_count(void)
{
int i, fail_count = 0;
+ intel_register_access_init(intel_get_pci_device(), 0);
+
/* There is a small delay after coming ot of rc6 to the correct
render context values will get loaded by hardware (bdw,chv).
This here ensures that we have the correct context loaded before
@@ -93,6 +95,8 @@ static int workaround_fail_count(void)
}
}
+ intel_register_access_fini();
+
return fail_count;
}
@@ -131,8 +135,6 @@ igt_main
pci_dev = intel_get_pci_device();
igt_require(pci_dev);
- intel_register_access_init(pci_dev, 0);
-
file = igt_debugfs_fopen("i915_wa_registers", "r");
igt_assert(getline(&line, &line_size, file) > 0);
igt_debug("i915_wa_registers: %s", line);
@@ -173,7 +175,6 @@ igt_main
igt_fixture {
free(wa_regs);
- intel_register_access_fini();
}
}
--
2.4.11
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Refactor execbuffer relocation writing
On Thu, Jun 09, 2016 at 04:31:25PM +0300, Joonas Lahtinen wrote:
> On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> > With in the introduction of the reloc page cache, we are just one step
> > away from refactoring the relocation write functions into one. Not only
> > does it tidy the code (slightly), but it greatly simplifies the control
> > logic much to gcc's satisfaction.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 289
> > +++--
> > 1 file changed, 150 insertions(+), 139 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 318c71b663f4..bda8ec8b02e6 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -34,6 +34,8 @@
> > #include
> > #include
> >
> > +#define DBG_USE_CPU_RELOC 0 /* force relocations to use the CPU write path
> > */
>
> Better connect to the new debug Kconfig menu you introduced?
I don't think so, it's not even intended as a general debug feature.
Just needed to force certain code paths for ease of testing.
That becomes more important later on when we have fewer reasons to use
the cpu relocation path on !llc.
> > -static int
> > -relocate_entry_cpu(struct drm_i915_gem_object *obj,
> > - struct drm_i915_gem_relocation_entry *reloc,
> > - struct reloc_cache *cache,
> > - uint64_t target_offset)
> > +static void *reloc_iomap(struct drm_i915_gem_object *obj,
> > + struct reloc_cache *cache,
> > + int page)
> > {
> > - struct drm_device *dev = obj->base.dev;
> > - uint32_t page_offset = offset_in_page(reloc->offset);
> > - uint64_t delta = relocation_target(reloc, target_offset);
> > - char *vaddr;
> > - int ret;
> > + void *vaddr;
> >
> > - ret = i915_gem_object_set_to_cpu_domain(obj, true);
> > - if (ret)
> > - return ret;
> > + if (cache->vaddr) {
> > + io_mapping_unmap_atomic(unmask_page(cache->vaddr));
> > + } else {
> > + struct i915_vma *vma;
> > + int ret;
> >
> > - vaddr = reloc_kmap(obj, cache, reloc->offset >> PAGE_SHIFT);
> > - *(uint32_t *)(vaddr + page_offset) = lower_32_bits(delta);
> > + if (use_cpu_reloc(obj))
> > + return NULL;
> >
> > - if (INTEL_GEN(dev) >= 8) {
> > - page_offset += sizeof(uint32_t);
> > - if (page_offset == PAGE_SIZE) {
> > - vaddr = reloc_kmap(obj, cache, cache->page + 1);
> > - page_offset = 0;
> > - }
> > - *(uint32_t *)(vaddr + page_offset) = upper_32_bits(delta);
> > - }
> > + vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
> > + PIN_MAPPABLE | PIN_NONBLOCK);
> > + if (IS_ERR(vma))
> > + return NULL;
> >
> > - return 0;
> > -}
>
> Ugh, did you simultaneously move and rename functions. This is rather
> hard to follow from this point on...
No, it's a bunch of function removals. I have a feeling it is going to
look ugly in diff no matter what, unless diff stops trying to relate
uncorresponding code.
-Chirs
--
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 6/8] drm/i915: Pin the pages first in shmem prepare read/write
On Thu, Jun 09, 2016 at 04:51:41PM +0300, Joonas Lahtinen wrote: > On to, 2016-06-09 at 14:35 +0100, Chris Wilson wrote: > > On Thu, Jun 09, 2016 at 04:06:59PM +0300, Joonas Lahtinen wrote: > > > > > > On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote: > > > > > > > > There is an improbable, but not impossible, case that if we leave the > > > > pages unpin as we operate on the object, then somebody may steal the > > > > lock and change the cache domains after we have already inspected them. > > > > > > > Which lock exactly? > > The shrinker steals struct_mutex from underneath us. The guard is > > pinning pages around operating on the object. > > Wouldn't the race scenario I described then apply (between get_pages > and pin_pages)? Apart from direct reclaim has no opportunity to run between them. I have sent patches in the path to change the api such that question cannot even be raised (the only issue is a bit of ugliness where we abuse the page pinning to workaround unknown memory layouts) but never pushed hard. In my recent patches for using pages outside of the struct_mutex, closing that window makes the api easier to hide the details of acquiring the pages + pinning them. -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 6/8] drm/i915: Pin the pages first in shmem prepare read/write
On to, 2016-06-09 at 14:35 +0100, Chris Wilson wrote: > On Thu, Jun 09, 2016 at 04:06:59PM +0300, Joonas Lahtinen wrote: > > > > On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote: > > > > > > There is an improbable, but not impossible, case that if we leave the > > > pages unpin as we operate on the object, then somebody may steal the > > > lock and change the cache domains after we have already inspected them. > > > > > Which lock exactly? > The shrinker steals struct_mutex from underneath us. The guard is > pinning pages around operating on the object. Wouldn't the race scenario I described then apply (between get_pages and pin_pages)? > -Chris > -- 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] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> Sent: Thursday, June 09, 2016 2:05 PM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate
>
> On 09/06/2016 13:48, tim.g...@intel.com wrote:
> > From: Tim Gore
> >
> > This patch enables a workaround for a mid thread preemption issue
> > where a hardware timing problem can prevent the context restore from
> > happening, leading to a hang.
> >
> > Signed-off-by: Tim Gore
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 4668477..e9046f6 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2156,6 +2156,12 @@ static void gtt_write_workarounds(struct
> drm_device *dev)
> > I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
> > else if (IS_BROXTON(dev))
> > I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> > GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
> > +
> > + /* WaConextSwitchWithConcurrentTLBInvalidate:gen9 */
> > + if (IS_GEN9(dev))
> > + {
> > + I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
> > + }
> This is not the correct place, it should be added in
> gen9_init_workarounds() in intel_ringbuffer.c as it applies to both skl and
> bxt.
>
> Please also correct the spelling and we usually mention both skl, bxt instead
> of gen9.
> WaContextSwitchWithConcurrentTLBInvalidate:skl,bxt
>
> regards
> Arun
>
The spelling is as per documentation and other code. Changing it will just add
confusion.
The w/a is for all gen 9 chips, kbl, bxt, skl etc., not sure why we need to
enumerate them,
anyway there is unlikely to be another gen9 chip so maybe a moot point, so I'll
list them.
Will move to gen9_init_workarounds, this seems to be called during reset and
resume so
Should also work. V2 patch to follow
Tim
> > }
> >
> > static int i915_ppgtt_init(struct drm_device *dev, struct
> > i915_hw_ppgtt *ppgtt) diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 81d1896..2a6fc62 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
> > #define GEN9_IZ_HASHING_MASK(slice) (0x3 <<
> ((slice) * 2))
> > #define GEN9_IZ_HASHING(slice, val) ((val) <<
> ((slice) * 2))
> >
> > +/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
> > +#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
> > +#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
> > +
> > /* WaClearTdlStateAckDirtyBits */
> > #define GEN8_STATE_ACK_MMIO(0x20F0)
> > #define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915: Pin the pages first in shmem prepare read/write
On Thu, Jun 09, 2016 at 04:06:59PM +0300, Joonas Lahtinen wrote: > On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote: > > There is an improbable, but not impossible, case that if we leave the > > pages unpin as we operate on the object, then somebody may steal the > > lock and change the cache domains after we have already inspected them. > > > > Which lock exactly? The shrinker steals struct_mutex from underneath us. The guard is pinning pages around operating on the object. -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 8/8] drm/i915: Refactor execbuffer relocation writing
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> With in the introduction of the reloc page cache, we are just one step
> away from refactoring the relocation write functions into one. Not only
> does it tidy the code (slightly), but it greatly simplifies the control
> logic much to gcc's satisfaction.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 289
> +++--
> 1 file changed, 150 insertions(+), 139 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 318c71b663f4..bda8ec8b02e6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -34,6 +34,8 @@
> #include
> #include
>
> +#define DBG_USE_CPU_RELOC 0 /* force relocations to use the CPU write path */
Better connect to the new debug Kconfig menu you introduced?
> +
> #define __EXEC_OBJECT_HAS_PIN (1U<<31)
> #define __EXEC_OBJECT_HAS_FENCE (1U<<30)
> #define __EXEC_OBJECT_NEEDS_MAP (1U<<29)
> @@ -53,6 +55,7 @@ struct i915_execbuffer_params {
> };
>
> struct eb_vmas {
> + struct drm_i915_private *i915;
> struct list_head vmas;
> int and;
> union {
> @@ -62,7 +65,8 @@ struct eb_vmas {
> };
>
> static struct eb_vmas *
> -eb_create(struct drm_i915_gem_execbuffer2 *args)
> +eb_create(struct drm_i915_private *i915,
> + struct drm_i915_gem_execbuffer2 *args)
> {
> struct eb_vmas *eb = NULL;
>
> @@ -89,6 +93,7 @@ eb_create(struct drm_i915_gem_execbuffer2 *args)
> } else
> eb->and = -args->buffer_count;
>
> + eb->i915 = i915;
> INIT_LIST_HEAD(&eb->vmas);
> return eb;
> }
> @@ -272,7 +277,8 @@ static void eb_destroy(struct eb_vmas *eb)
>
> static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
> {
> - return (HAS_LLC(obj->base.dev) ||
> + return (DBG_USE_CPU_RELOC ||
> + HAS_LLC(obj->base.dev) ||
> obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
> obj->cache_level != I915_CACHE_NONE);
> }
> @@ -296,32 +302,58 @@ static inline uint64_t gen8_noncanonical_addr(uint64_t
> address)
> }
>
> static inline uint64_t
> -relocation_target(struct drm_i915_gem_relocation_entry *reloc,
> +relocation_target(const struct drm_i915_gem_relocation_entry *reloc,
These const changes could be a bunch instead of sprinkled around.
Unless we want to smuggle them in through the resistance.
> uint64_t target_offset)
> {
> return gen8_canonical_addr((int)reloc->delta + target_offset);
> }
>
> struct reloc_cache {
> - void *vaddr;
> + struct drm_i915_private *i915;
> + unsigned long vaddr;
> unsigned page;
> - enum { KMAP, IOMAP } type;
> + struct drm_mm_node node;
> + bool use_64bit_reloc;
> };
>
> -static void reloc_cache_init(struct reloc_cache *cache)
> +static void reloc_cache_init(struct reloc_cache *cache,
> + struct drm_i915_private *i915)
> {
> cache->page = -1;
> - cache->vaddr = NULL;
> + cache->vaddr = 0;
> + cache->i915 = i915;
> + cache->use_64bit_reloc = INTEL_GEN(cache->i915) >= 8;
> +}
> +
> +static inline void *unmask_page(unsigned long p)
> +{
> + return (void *)(uintptr_t)(p & PAGE_MASK);
> }
>
> +static inline unsigned unmask_flags(unsigned long p)
> +{
> + return p & ~PAGE_MASK;
> +}
> +
> +#define KMAP 0x4
> +
> static void reloc_cache_fini(struct reloc_cache *cache)
> {
> - if (cache->vaddr == NULL)
> + void *vaddr;
> +
> + if (cache->vaddr == 0)
> return;
>
> - switch (cache->type) {
> - case KMAP: kunmap_atomic(cache->vaddr); break;
> - case IOMAP: io_mapping_unmap_atomic(cache->vaddr); break;
> + vaddr = unmask_page(cache->vaddr);
> + if (cache->vaddr & KMAP) {
> + if (cache->vaddr & CLFLUSH_AFTER)
> + mb();
> +
> + kunmap_atomic(vaddr);
> + i915_gem_object_unpin_pages((struct drm_i915_gem_object
> *)cache->node.mm);
Rather long line.
> + } else {
> + io_mapping_unmap_atomic(vaddr);
> + i915_vma_unpin((struct i915_vma *)cache->node.mm);
> }
> }
>
> @@ -329,148 +361,138 @@ static void *reloc_kmap(struct drm_i915_gem_object
> *obj,
> struct reloc_cache *cache,
> int page)
> {
> - if (cache->page == page)
> - return cache->vaddr;
> + void *vaddr;
>
> - if (cache->vaddr)
> - kunmap_atomic(cache->vaddr);
> + if (cache->vaddr) {
> + kunmap_atomic(unmask_page(cache->vaddr));
> + } else {
> + unsigned flushes;
> + int ret;
> +
> + ret = i915_gem_obj_prepare_shmem_write(obj, &flushes);
Yeah, needs_clflush is so bad name earlier in the series, that even you
don't use it. "need_clflushes" or anything is better.
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Tidy up flush cpu/gtt write domains
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> Since we know the write domain, we can drop the local variable and make
> the code look a tiny bit simpler.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8c90b6a12d45..45f878350d66 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2913,7 +2913,6 @@ static void
> i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj)
> {
> struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> - uint32_t old_write_domain;
>
> if (obj->base.write_domain != I915_GEM_DOMAIN_GTT)
> return;
> @@ -2937,36 +2936,30 @@ i915_gem_object_flush_gtt_write_domain(struct
> drm_i915_gem_object *obj)
> if (INTEL_INFO(dev_priv)->gen >= 6 && !HAS_LLC(dev_priv))
> POSTING_READ(RING_ACTHD(dev_priv->engine[RCS].mmio_base));
>
> - old_write_domain = obj->base.write_domain;
> - obj->base.write_domain = 0;
> -
> intel_fb_obj_flush(obj, false, ORIGIN_GTT);
>
> + obj->base.write_domain = 0;
> trace_i915_gem_object_change_domain(obj,
> obj->base.read_domains,
> - old_write_domain);
> + I915_GEM_DOMAIN_GTT);
> }
>
> /** Flushes the CPU write domain for the object if it's dirty. */
> static void
> i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj)
> {
> - uint32_t old_write_domain;
> -
> if (obj->base.write_domain != I915_GEM_DOMAIN_CPU)
> return;
>
> if (i915_gem_clflush_object(obj, obj->pin_display))
> i915_gem_chipset_flush(to_i915(obj->base.dev));
>
> - old_write_domain = obj->base.write_domain;
> - obj->base.write_domain = 0;
> -
> intel_fb_obj_flush(obj, false, ORIGIN_CPU);
>
> + obj->base.write_domain = 0;
> trace_i915_gem_object_change_domain(obj,
> obj->base.read_domains,
> - old_write_domain);
> + I915_GEM_DOMAIN_CPU);
> }
>
> /**
--
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 6/8] drm/i915: Pin the pages first in shmem prepare read/write
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> There is an improbable, but not impossible, case that if we leave the
> pages unpin as we operate on the object, then somebody may steal the
> lock and change the cache domains after we have already inspected them.
>
Which lock exactly?
> (Whilst here, avail ourselves of the opportunity to take a couple of
> steps to make the two functions look more similar.)
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 88
> -
> 1 file changed, 51 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ffe3d3e9d69d..8c90b6a12d45 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -571,13 +571,22 @@ int i915_gem_obj_prepare_shmem_read(struct
> drm_i915_gem_object *obj,
> if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> return -EINVAL;
>
> + ret = i915_gem_object_get_pages(obj);
> + if (ret)
> + return ret;
> +
There's still time for the pages to disappear at this point if somebody
is racing with us, and BUG_ON will be imminent. So I'm not sure which
lock you mean.
> + i915_gem_object_pin_pages(obj);
> +
> + if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> + goto out;
> +
> + ret = i915_gem_object_wait_rendering(obj, true);
> + if (ret)
> + goto err_unpin;
> +
> i915_gem_object_flush_gtt_write_domain(obj);
>
> if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
> - ret = i915_gem_object_wait_rendering(obj, true);
> - if (ret)
> - return ret;
> -
> /* If we're not in the cpu read domain, set ourself into the gtt
> * read domain and manually flush cachelines (if required). This
> * optimizes for the case when the gpu will dirty the data
> @@ -586,26 +595,25 @@ int i915_gem_obj_prepare_shmem_read(struct
> drm_i915_gem_object *obj,
> obj->cache_level);
> }
>
> - ret = i915_gem_object_get_pages(obj);
> - if (ret)
> - return ret;
> -
> - i915_gem_object_pin_pages(obj);
> -
> if (*needs_clflush && !boot_cpu_has(X86_FEATURE_CLFLUSH)) {
> ret = i915_gem_object_set_to_cpu_domain(obj, false);
> - if (ret) {
> - i915_gem_object_unpin_pages(obj);
> - return ret;
> - }
> + if (ret)
> + goto err_unpin;
> +
> *needs_clflush = 0;
> }
>
> +out:
> + /* return with the pages pinned */
> return 0;
> +
> +err_unpin:
> + i915_gem_object_unpin_pages(obj);
> + return ret;
> }
>
> int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
> - unsigned *needs_clflush)
> + unsigned *needs_clflush)
> {
> int ret;
>
> @@ -613,20 +621,27 @@ int i915_gem_obj_prepare_shmem_write(struct
> drm_i915_gem_object *obj,
> if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> return -EINVAL;
>
> - i915_gem_object_flush_gtt_write_domain(obj);
> + ret = i915_gem_object_get_pages(obj);
> + if (ret)
> + return ret;
>
> - if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
> - ret = i915_gem_object_wait_rendering(obj, false);
> - if (ret)
> - return ret;
> + i915_gem_object_pin_pages(obj);
>
> - /* If we're not in the cpu write domain, set ourself into the
> - * gtt write domain and manually flush cachelines (as required).
> - * This optimizes for the case when the gpu will use the data
> - * right away and we therefore have to clflush anyway.
> - */
> - *needs_clflush |= cpu_write_needs_clflush(obj) << 1;
> - }
> + if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> + goto out;
> +
> + ret = i915_gem_object_wait_rendering(obj, false);
> + if (ret)
> + goto err_unpin;
> +
> + i915_gem_object_flush_gtt_write_domain(obj);
> +
> + /* If we're not in the cpu write domain, set ourself into the
> + * gtt write domain and manually flush cachelines (as required).
> + * This optimizes for the case when the gpu will use the data
> + * right away and we therefore have to clflush anyway.
> + */
> + *needs_clflush |= cpu_write_needs_clflush(obj) << 1;
Use ?: to keep the code readable.
>
> /* Same trick applies to invalidate partially written cachelines read
> * before writing.
> @@ -635,27 +650,26 @@ int i915_gem_obj_prepare_shmem_write(struct
> drm_i915_gem_object *obj,
> *needs_clflush |= !cpu_cache_is_coherent(obj->base.dev,
Re: [Intel-gfx] [PATCH] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
On 09/06/2016 13:48, tim.g...@intel.com wrote:
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4668477..e9046f6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2156,6 +2156,12 @@ static void gtt_write_workarounds(struct drm_device *dev)
I915_WRITE(GEN8_L3_LRA_1_GPGPU,
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
else if (IS_BROXTON(dev))
I915_WRITE(GEN8_L3_LRA_1_GPGPU,
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
+
+ /* WaConextSwitchWithConcurrentTLBInvalidate:gen9 */
+ if (IS_GEN9(dev))
+ {
+ I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+ }
This is not the correct place, it should be added in
gen9_init_workarounds() in intel_ringbuffer.c as it applies to both skl
and bxt.
Please also correct the spelling and we usually mention both skl, bxt
instead of gen9.
WaContextSwitchWithConcurrentTLBInvalidate:skl,bxt
regards
Arun
}
static int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt
*ppgtt)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
#define GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
#define GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))
+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
/* WaClearTdlStateAckDirtyBits */
#define GEN8_STATE_ACK_MMIO(0x20F0)
#define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Wait for writes through the GTT to land before reading back
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> If we quickly switch from writing through the GTT to a read of the
> physical page directly with the CPU (e.g. performing relocations through
> the GTT and then running the command parser), we can observe that the
> writes are not visible to the CPU. It is not a coherency problem, as
> extensive investigations with clflush have demonstrated, but a mere
> timing issue - we have to wait for the GTT to complete it's write before
> we start our read from the CPU.
>
> The issue can be illustrated in userspace with:
>
> gtt = gem_mmap__gtt(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
> cpu = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
> gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
>
> for (i = 0; i < OBJECT_SIZE / 64; i++) {
> int x = 16*i + (i%16);
> gtt[x] = i;
> clflush(&cpu[x], sizeof(cpu[x]));
> assert(cpu[x] == i);
> }
>
> Experimenting with that shows that this behaviour is indeed limited to
> recent Atom-class hardware.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 18b4a684ddde..ffe3d3e9d69d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2898,20 +2898,30 @@ i915_gem_clflush_object(struct drm_i915_gem_object
> *obj,
> static void
> i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj)
> {
> + struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> uint32_t old_write_domain;
>
> if (obj->base.write_domain != I915_GEM_DOMAIN_GTT)
> return;
>
> /* No actual flushing is required for the GTT write domain. Writes
> - * to it immediately go to main memory as far as we know, so there's
> + * to it "immediately" go to main memory as far as we know, so there's
> * no chipset flush. It also doesn't land in render cache.
> *
> * However, we do have to enforce the order so that all writes through
> * the GTT land before any writes to the device, such as updates to
> * the GATT itself.
> + *
> + * We also have to wait a bit for the writes to land from the GTT.
> + * An uncached read (i.e. mmio) seems to be ideal for the round-trip
> + * timing. This issue has only been observed when switching quickly
> + * between GTT writes and CPU reads from inside the kernel on recent hw,
> + * and it appears to only affect discrete GTT blocks (i.e. on LLC
> + * system agents we cannot reproduce this behaviour).
This screams for a Tested-by: tag before merging...
> */
> wmb();
> + if (INTEL_INFO(dev_priv)->gen >= 6 && !HAS_LLC(dev_priv))
INTEL_GEN()
This fixed, and adding the Testcase: label
Reviewed-by: Joonas Lahtinen
> + POSTING_READ(RING_ACTHD(dev_priv->engine[RCS].mmio_base));
>
> old_write_domain = obj->base.write_domain;
> obj->base.write_domain = 0;
--
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 4/8] drm/i915: Before accessing an object via the cpu, flush GTT writes
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> If we want to read the pages directly via the CPU, we have to be sure
> that we have to flush the writes via the GTT (as the CPU can not see
> the address aliasing).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c6d06cb21191..18b4a684ddde 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -571,6 +571,8 @@ int i915_gem_obj_prepare_shmem_read(struct
> drm_i915_gem_object *obj,
> if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> return -EINVAL;
>
> + i915_gem_object_flush_gtt_write_domain(obj);
> +
> if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
> ret = i915_gem_object_wait_rendering(obj, true);
> if (ret)
> @@ -611,6 +613,8 @@ int i915_gem_obj_prepare_shmem_write(struct
> drm_i915_gem_object *obj,
> if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> return -EINVAL;
>
> + i915_gem_object_flush_gtt_write_domain(obj);
> +
> if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
> ret = i915_gem_object_wait_rendering(obj, false);
> if (ret)
--
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 3/8] drm/i915: Extract i915_gem_obj_prepare_shmem_write()
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> This is a companion to i915_gem_obj_prepare_shmem_read() that prepares
> the backing storage for direct writes. It first serialises with the GPU,
> pins the backing storage and then indicates what clfushes are required in
> order for the writes to be coherent.
>
> Whilst here, fix support for ancient CPUs without clflush for which we
> cannot do the GTT+clflush tricks.
>
Could add here that WARN is kicked
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 6 +-
> drivers/gpu/drm/i915/i915_gem.c| 119
> +
> 3 files changed, 83 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index b0fd6a7b0603..de038da6c01b 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -970,7 +970,7 @@ static u32 *copy_batch(struct drm_i915_gem_object
> *dest_obj,
> u32 batch_start_offset,
> u32 batch_len)
> {
> - int needs_clflush = 0;
> + unsigned needs_clflush;
Mildly irritated by innuendo to boolean. Not sure why not just "flags".
> void *src_base, *src;
> void *dst = NULL;
> int ret;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b333cf4923bc..ef321f84e5fc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3026,7 +3026,11 @@ void i915_gem_release_all_mmaps(struct
> drm_i915_private *dev_priv);
> void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
>
> int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
> - int *needs_clflush);
> + unsigned *needs_clflush);
> +int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
> + unsigned *needs_clflush);
> +#define CLFLUSH_BEFORE 0x1
> +#define CLFLUSH_AFTER 0x2
>
> int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a41fa01eb024..c6d06cb21191 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -563,34 +563,95 @@ __copy_from_user_swizzled(char *gpu_vaddr, int
> gpu_offset,
> * flush the object from the CPU cache.
> */
> int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
> - int *needs_clflush)
> + unsigned *needs_clflush)
> {
> int ret;
>
> *needs_clflush = 0;
> -
> - if (WARN_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0))
> + if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
Why no more WARN?
> return -EINVAL;
>
> if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
> + ret = i915_gem_object_wait_rendering(obj, true);
> + if (ret)
> + return ret;
> +
> /* If we're not in the cpu read domain, set ourself into the gtt
> * read domain and manually flush cachelines (if required). This
> * optimizes for the case when the gpu will dirty the data
> * anyway again before the next pread happens. */
> *needs_clflush = !cpu_cache_is_coherent(obj->base.dev,
> obj->cache_level);
Maybe add CLFLUSH_NONE and use ?:, this is deceiving now that it's not
boolean, and that's why the name should be changed too.
> - ret = i915_gem_object_wait_rendering(obj, true);
> + }
> +
> + ret = i915_gem_object_get_pages(obj);
> + if (ret)
> + return ret;
> +
> + i915_gem_object_pin_pages(obj);
> +
> + if (*needs_clflush && !boot_cpu_has(X86_FEATURE_CLFLUSH)) {
Your own comment applies here.
> + ret = i915_gem_object_set_to_cpu_domain(obj, false);
> + if (ret) {
> + i915_gem_object_unpin_pages(obj);
> + return ret;
> + }
> + *needs_clflush = 0;
> + }
> +
> + return 0;
> +}
> +
> +int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
> + unsigned *needs_clflush)
> +{
> + int ret;
> +
> + *needs_clflush = 0;
> + if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> + return -EINVAL;
> +
> + if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
> + ret = i915_gem_object_wait_rendering(obj, false);
> if (ret)
> return ret;
> +
> + /* If we're not in the cpu write domain, set ourself into the
> + * gtt write domain and manually flush cac
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Print the batchbuffer offset next to BBADDR in error state
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> It is useful when looking at captured error states to check the recorded
> BBADDR register (the address of the last batchbuffer instruction loaded)
> against the expected offset of the batch buffer, and so do a quick check
> that (a) the capture is true or (b) HEAD hasn't wandered off into the
> badlands.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 12 +++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 48cf9dfbe4ac..b333cf4923bc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -541,6 +541,7 @@ struct drm_i915_error_state {
> struct drm_i915_error_object {
> int page_count;
> u64 gtt_offset;
> + u64 gtt_size;
> u32 *pages[0];
> } *ringbuffer, *batchbuffer, *wa_batchbuffer, *ctx, *hws_page;
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 76d63e047fae..ab0824b1ce6d 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -249,6 +249,13 @@ static void i915_ring_error_state(struct
> drm_i915_error_state_buf *m,
> err_printf(m, " IPEIR: 0x%08x\n", ring->ipeir);
> err_printf(m, " IPEHR: 0x%08x\n", ring->ipehr);
> err_printf(m, " INSTDONE: 0x%08x\n", ring->instdone);
> + if (ring->batchbuffer) {
> + u64 start = ring->batchbuffer->gtt_offset;
> + u64 end = start + ring->batchbuffer->gtt_size;
> + err_printf(m, " batch: [0x%08x %08x, 0x%08x %08x]\n",
> + upper_32_bits(start), lower_32_bits(start),
> + upper_32_bits(end), lower_32_bits(end));
I'm not very fond of this 32/32 split done repeatedly and manually, but
it seems to be used already.
Reviewed-by: Joonas Lahtinen
> + }
> if (INTEL_INFO(dev)->gen >= 4) {
> err_printf(m, " BBADDR: 0x%08x %08x\n",
> (u32)(ring->bbaddr>>32), (u32)ring->bbaddr);
> err_printf(m, " BB_STATE: 0x%08x\n", ring->bbstate);
> @@ -655,7 +662,10 @@ i915_error_object_create(struct drm_i915_private
> *dev_priv,
> if (dst == NULL)
> return NULL;
>
> - reloc_offset = dst->gtt_offset = vma->node.start;
> + dst->gtt_offset = vma->node.start;
> + dst->gtt_size = vma->node.size;
> +
> + reloc_offset = dst->gtt_offset;
This is completely unrelated fixup. You could split it with my R-b in
both.
> use_ggtt = (src->cache_level == I915_CACHE_NONE &&
> (vma->bound & GLOBAL_BIND) &&
> reloc_offset + num_pages * PAGE_SIZE <= ggtt->mappable_end);
--
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 2/8] drm/i915: Cache kmap between relocations
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> When doing relocations, we have to obtain a mapping to the page
> containing the target address. This is either a kmap or iomap depending
> on GPU and its cache coherency. Neighbouring relocation entries are
> typically within the same page and so we can cache our kmapping between
> them and avoid those pesky TLB flushes.
>
> Note that there is some sleight-of-hand in how the slow relocate works
> as the reloc_entry_cache implies pagefaults disabled (as we are inside a
> kmap_atomic section). However, the slow relocate code is meant to be the
> fallback from the atomic fast path failing. Fortunately it works as we
> already have performed the copy_from_user for the relocation array (no
> more pagefaults there) and the kmap_atomic cache is enabled after we
> have waited upon an active buffer (so no more sleeping in atomic).
> Magic!
>
You could also mention that you mangle the relocation <-> page logic,
so this is not purely about caching. Or maybe even split it.
Below comments, those addressed;
Reviewed-by: Joonas Lahtinen
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 160
> +++--
> 1 file changed, 106 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index a29c4b6fea28..318c71b663f4 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -302,9 +302,50 @@ relocation_target(struct drm_i915_gem_relocation_entry
> *reloc,
> return gen8_canonical_addr((int)reloc->delta + target_offset);
> }
>
> +struct reloc_cache {
> + void *vaddr;
> + unsigned page;
> + enum { KMAP, IOMAP } type;
> +};
> +
> +static void reloc_cache_init(struct reloc_cache *cache)
> +{
> + cache->page = -1;
> + cache->vaddr = NULL;
> +}
> +
> +static void reloc_cache_fini(struct reloc_cache *cache)
> +{
> + if (cache->vaddr == NULL)
> + return;
> +
> + switch (cache->type) {
> + case KMAP: kunmap_atomic(cache->vaddr); break;
> + case IOMAP: io_mapping_unmap_atomic(cache->vaddr); break;
> + }
> +}
> +
> +static void *reloc_kmap(struct drm_i915_gem_object *obj,
> + struct reloc_cache *cache,
> + int page)
> +{
> + if (cache->page == page)
> + return cache->vaddr;
> +
> + if (cache->vaddr)
> + kunmap_atomic(cache->vaddr);
Maybe add some GEM_BUG_ON(cache->type != KMAP) here before running
kunmap_atomic? Because that assumption is made.
> +
> + cache->page = page;
> + cache->vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
> + cache->type = KMAP;
> +
> + return cache->vaddr;
> +}
> +
> static int
> relocate_entry_cpu(struct drm_i915_gem_object *obj,
> struct drm_i915_gem_relocation_entry *reloc,
> + struct reloc_cache *cache,
> uint64_t target_offset)
> {
> struct drm_device *dev = obj->base.dev;
> @@ -317,34 +358,47 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj,
> if (ret)
> return ret;
>
> - vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj,
> - reloc->offset >> PAGE_SHIFT));
> + vaddr = reloc_kmap(obj, cache, reloc->offset >> PAGE_SHIFT);
> *(uint32_t *)(vaddr + page_offset) = lower_32_bits(delta);
>
> - if (INTEL_INFO(dev)->gen >= 8) {
> - page_offset = offset_in_page(page_offset + sizeof(uint32_t));
> -
> - if (page_offset == 0) {
> - kunmap_atomic(vaddr);
> - vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj,
> - (reloc->offset + sizeof(uint32_t)) >> PAGE_SHIFT));
> + if (INTEL_GEN(dev) >= 8) {
> + page_offset += sizeof(uint32_t);
> + if (page_offset == PAGE_SIZE) {
> + vaddr = reloc_kmap(obj, cache, cache->page + 1);
> + page_offset = 0;
> }
> -
> *(uint32_t *)(vaddr + page_offset) = upper_32_bits(delta);
> }
>
> - kunmap_atomic(vaddr);
> -
> return 0;
> }
>
> +static void *reloc_iomap(struct drm_i915_private *i915,
> + struct reloc_cache *cache,
> + uint64_t offset)
> +{
> + if (cache->page == offset >> PAGE_SHIFT)
> + return cache->vaddr;
> +
> + if (cache->vaddr)
> + io_mapping_unmap_atomic(cache->vaddr);
> +
> + cache->page = offset >> PAGE_SHIFT;
> + cache->vaddr =
> + io_mapping_map_atomic_wc(i915->ggtt.mappable,
> + offset & PAGE_MASK);
> + cache->type = IOMAP;
> +
> + return cache->vaddr;
> +}
> +
> static int
> relocate_entry_gtt(struct drm_i915_gem_object *obj,
> struct drm_i915_gem_relocation_
[Intel-gfx] [PATCH] kernel/cpu: Distinct name for cpu_hotplug.dep_map
Use distinctive name for cpu_hotplug.dep_map to avoid the actual
cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Gautham R. Shenoy
Cc: intel-gfx@lists.freedesktop.org
Cc: triv...@kernel.org
Acked-by: Gautham R. Shenoy
Signed-off-by: Joonas Lahtinen
---
This time CC'ing triv...@kernel.org too in the hopes of finally getting this in.
---
kernel/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index d948e44..d74199d 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -155,7 +155,7 @@ static struct {
.wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
.lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
#ifdef CONFIG_DEBUG_LOCK_ALLOC
- .dep_map = {.name = "cpu_hotplug.lock" },
+ .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map",
&cpu_hotplug.dep_map),
#endif
};
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/8] drm/i915: Print the batchbuffer offset next to BBADDR in error state
== Series Details == Series: series starting with [1/8] drm/i915: Print the batchbuffer offset next to BBADDR in error state URL : https://patchwork.freedesktop.org/series/8491/ State : failure == Summary == Applying: drm/i915: Print the batchbuffer offset next to BBADDR in error state fatal: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_drv.h). error: could not build fake ancestor Patch failed at 0001 drm/i915: Print the batchbuffer offset next to BBADDR in error state The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Extract i915_gem_obj_prepare_shmem_write()
On Thu, Jun 09, 2016 at 12:29:34PM +0100, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a41fa01eb024..c6d06cb21191 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -563,34 +563,95 @@ __copy_from_user_swizzled(char *gpu_vaddr, int
> gpu_offset,
> * flush the object from the CPU cache.
> */
> int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
> - int *needs_clflush)
> + unsigned *needs_clflush)
> {
> int ret;
>
> *needs_clflush = 0;
> -
> - if (WARN_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0))
> + if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> return -EINVAL;
>
> if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
> + ret = i915_gem_object_wait_rendering(obj, true);
> + if (ret)
> + return ret;
> +
> /* If we're not in the cpu read domain, set ourself into the gtt
>* read domain and manually flush cachelines (if required). This
>* optimizes for the case when the gpu will dirty the data
>* anyway again before the next pread happens. */
> *needs_clflush = !cpu_cache_is_coherent(obj->base.dev,
> obj->cache_level);
> - ret = i915_gem_object_wait_rendering(obj, true);
> + }
> +
> + ret = i915_gem_object_get_pages(obj);
> + if (ret)
> + return ret;
> +
> + i915_gem_object_pin_pages(obj);
> +
> + if (*needs_clflush && !boot_cpu_has(X86_FEATURE_CLFLUSH)) {
This should now be static_cpu_has().
-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] drm/i915: Force vblanks around evasion when i915.watermark_test is set.
This will make it more likely that intermediary watermarks cause fifo
underruns, which is useful when writing watermark specific tests,
to make it more likely to trigger FIFO underruns in intermediary watermarks.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_params.c | 1 +
drivers/gpu/drm/i915/i915_params.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 6 ++
3 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 5e18cf9f754d..297d1cd53b15 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,
+ .watermark_test = 0,
.reset = true,
.invert_brightness = 0,
.disable_display = 0,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 1323261a0cdd..91f976c6bac6 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -57,6 +57,7 @@ struct i915_params {
bool fastboot;
bool prefault_disable;
bool load_detect_test;
+ bool watermark_test;
bool reset;
bool disable_display;
bool verbose_state_checks;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8bb8d36f5cb9..9dcf304c7b1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14184,6 +14184,9 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
to_intel_crtc_state(old_crtc_state);
bool modeset = needs_modeset(crtc->state);
+ if (i915.watermark_test)
+ intel_wait_for_vblank(dev, intel_crtc->pipe);
+
/* Perform vblank evasion around commit operation */
intel_pipe_update_start(intel_crtc);
@@ -14207,6 +14210,9 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
intel_pipe_update_end(intel_crtc, NULL);
+
+ if (i915.watermark_test)
+ intel_wait_for_vblank(crtc->dev, intel_crtc->pipe);
}
/**
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/8] drm/i915: Wait for writes through the GTT to land before reading back
On Thu, Jun 09, 2016 at 12:29:36PM +0100, Chris Wilson wrote:
> If we quickly switch from writing through the GTT to a read of the
> physical page directly with the CPU (e.g. performing relocations through
> the GTT and then running the command parser), we can observe that the
> writes are not visible to the CPU. It is not a coherency problem, as
> extensive investigations with clflush have demonstrated, but a mere
> timing issue - we have to wait for the GTT to complete it's write before
> we start our read from the CPU.
>
> The issue can be illustrated in userspace with:
>
> gtt = gem_mmap__gtt(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
> cpu = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
> gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
>
> for (i = 0; i < OBJECT_SIZE / 64; i++) {
> int x = 16*i + (i%16);
> gtt[x] = i;
> clflush(&cpu[x], sizeof(cpu[x]));
> assert(cpu[x] == i);
> }
>
> Experimenting with that shows that this behaviour is indeed limited to
> recent Atom-class hardware.
>
> Signed-off-by: Chris Wilson
Note this is associated with
Testcase: igt/gem_exec_flush/basic-batch-default-cmd #byt
I wrote the testcase based on this bug, but it may not be the only thing
that causes that test to fail (since byt has a major issue with
coherency).
Also note that the gem_mmap_gtt/coherency and gem_mmap_wc/coherency are
the userspace demonstrators (and that this only a GTT issue).
-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] [drm-intel:topic/drm-misc 11/11] DockBook: include/drm/drm_fourcc.h:1: warning: no structured comments found
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: ae4df11a0f538b83781cf120a78dde32b0070600 commit: ae4df11a0f538b83781cf120a78dde32b0070600 [11/11] drm: Move format-related helpers to drm_fourcc.c reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:594: warning: No description found for parameter 'dev_priv' drivers/gpu/drm/i915/i915_irq.c:594: warning: Excess function parameter 'dev' description in 'i915_enable_asle_pipestat' drivers/gpu/drm/i915/i915_irq.c:2526: warning: No description found for parameter 'dev_priv' drivers/gpu/drm/i915/i915_irq.c:2526: warning: Excess function parameter 'dev' description in 'i915_reset_and_wakeup' drivers/gpu/drm/i915/i915_irq.c:2688: warning: No description found for parameter 'dev_priv' drivers/gpu/drm/i915/i915_irq.c:2688: warning: No description found for parameter 'fmt' drivers/gpu/drm/i915/i915_irq.c:2688: warning: Excess function parameter 'dev' description in 'i915_handle_error' >> include/drm/drm_fourcc.h:1: warning: no structured comments found include/drm/drm_crtc.h:797: warning: No description found for parameter 'index' include/drm/drm_crtc.h:1119: warning: No description found for parameter 'index' include/drm/drm_crtc.h:1589: warning: No description found for parameter 'index' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'connector_ida' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'prop_mode_id' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_flicker_reduction_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_overscan_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_saturation_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'tv_hue_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'scaling_mode_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'aspect_ratio_property' include/drm/drm_crtc.h:2257: warning: No description found for parameter 'dirty_info_property' include/drm/drm_crtc.h:2257: warnin
[Intel-gfx] [PATCH 6/8] drm/i915: Pin the pages first in shmem prepare read/write
There is an improbable, but not impossible, case that if we leave the
pages unpin as we operate on the object, then somebody may steal the
lock and change the cache domains after we have already inspected them.
(Whilst here, avail ourselves of the opportunity to take a couple of
steps to make the two functions look more similar.)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 88 -
1 file changed, 51 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ffe3d3e9d69d..8c90b6a12d45 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -571,13 +571,22 @@ int i915_gem_obj_prepare_shmem_read(struct
drm_i915_gem_object *obj,
if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -EINVAL;
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ return ret;
+
+ i915_gem_object_pin_pages(obj);
+
+ if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+ goto out;
+
+ ret = i915_gem_object_wait_rendering(obj, true);
+ if (ret)
+ goto err_unpin;
+
i915_gem_object_flush_gtt_write_domain(obj);
if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
- ret = i915_gem_object_wait_rendering(obj, true);
- if (ret)
- return ret;
-
/* If we're not in the cpu read domain, set ourself into the gtt
* read domain and manually flush cachelines (if required). This
* optimizes for the case when the gpu will dirty the data
@@ -586,26 +595,25 @@ int i915_gem_obj_prepare_shmem_read(struct
drm_i915_gem_object *obj,
obj->cache_level);
}
- ret = i915_gem_object_get_pages(obj);
- if (ret)
- return ret;
-
- i915_gem_object_pin_pages(obj);
-
if (*needs_clflush && !boot_cpu_has(X86_FEATURE_CLFLUSH)) {
ret = i915_gem_object_set_to_cpu_domain(obj, false);
- if (ret) {
- i915_gem_object_unpin_pages(obj);
- return ret;
- }
+ if (ret)
+ goto err_unpin;
+
*needs_clflush = 0;
}
+out:
+ /* return with the pages pinned */
return 0;
+
+err_unpin:
+ i915_gem_object_unpin_pages(obj);
+ return ret;
}
int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
- unsigned *needs_clflush)
+unsigned *needs_clflush)
{
int ret;
@@ -613,20 +621,27 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -EINVAL;
- i915_gem_object_flush_gtt_write_domain(obj);
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ return ret;
- if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
- ret = i915_gem_object_wait_rendering(obj, false);
- if (ret)
- return ret;
+ i915_gem_object_pin_pages(obj);
- /* If we're not in the cpu write domain, set ourself into the
-* gtt write domain and manually flush cachelines (as required).
-* This optimizes for the case when the gpu will use the data
-* right away and we therefore have to clflush anyway.
-*/
- *needs_clflush |= cpu_write_needs_clflush(obj) << 1;
- }
+ if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+ goto out;
+
+ ret = i915_gem_object_wait_rendering(obj, false);
+ if (ret)
+ goto err_unpin;
+
+ i915_gem_object_flush_gtt_write_domain(obj);
+
+ /* If we're not in the cpu write domain, set ourself into the
+* gtt write domain and manually flush cachelines (as required).
+* This optimizes for the case when the gpu will use the data
+* right away and we therefore have to clflush anyway.
+*/
+ *needs_clflush |= cpu_write_needs_clflush(obj) << 1;
/* Same trick applies to invalidate partially written cachelines read
* before writing.
@@ -635,27 +650,26 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
*needs_clflush |= !cpu_cache_is_coherent(obj->base.dev,
obj->cache_level);
- ret = i915_gem_object_get_pages(obj);
- if (ret)
- return ret;
-
- i915_gem_object_pin_pages(obj);
-
if (*needs_clflush && !boot_cpu_has(X86_FEATURE_CLFLUSH)) {
ret = i915_gem_object_set_to_cpu_domain(obj, true);
- if (ret) {
[Intel-gfx] [PATCH 3/8] drm/i915: Extract i915_gem_obj_prepare_shmem_write()
This is a companion to i915_gem_obj_prepare_shmem_read() that prepares
the backing storage for direct writes. It first serialises with the GPU,
pins the backing storage and then indicates what clfushes are required in
order for the writes to be coherent.
Whilst here, fix support for ancient CPUs without clflush for which we
cannot do the GTT+clflush tricks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 6 +-
drivers/gpu/drm/i915/i915_gem.c| 119 +
3 files changed, 83 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index b0fd6a7b0603..de038da6c01b 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -970,7 +970,7 @@ static u32 *copy_batch(struct drm_i915_gem_object *dest_obj,
u32 batch_start_offset,
u32 batch_len)
{
- int needs_clflush = 0;
+ unsigned needs_clflush;
void *src_base, *src;
void *dst = NULL;
int ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b333cf4923bc..ef321f84e5fc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3026,7 +3026,11 @@ void i915_gem_release_all_mmaps(struct drm_i915_private
*dev_priv);
void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
- int *needs_clflush);
+ unsigned *needs_clflush);
+int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
+unsigned *needs_clflush);
+#define CLFLUSH_BEFORE 0x1
+#define CLFLUSH_AFTER 0x2
int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a41fa01eb024..c6d06cb21191 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -563,34 +563,95 @@ __copy_from_user_swizzled(char *gpu_vaddr, int gpu_offset,
* flush the object from the CPU cache.
*/
int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj,
- int *needs_clflush)
+ unsigned *needs_clflush)
{
int ret;
*needs_clflush = 0;
-
- if (WARN_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0))
+ if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -EINVAL;
if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
+ ret = i915_gem_object_wait_rendering(obj, true);
+ if (ret)
+ return ret;
+
/* If we're not in the cpu read domain, set ourself into the gtt
* read domain and manually flush cachelines (if required). This
* optimizes for the case when the gpu will dirty the data
* anyway again before the next pread happens. */
*needs_clflush = !cpu_cache_is_coherent(obj->base.dev,
obj->cache_level);
- ret = i915_gem_object_wait_rendering(obj, true);
+ }
+
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ return ret;
+
+ i915_gem_object_pin_pages(obj);
+
+ if (*needs_clflush && !boot_cpu_has(X86_FEATURE_CLFLUSH)) {
+ ret = i915_gem_object_set_to_cpu_domain(obj, false);
+ if (ret) {
+ i915_gem_object_unpin_pages(obj);
+ return ret;
+ }
+ *needs_clflush = 0;
+ }
+
+ return 0;
+}
+
+int i915_gem_obj_prepare_shmem_write(struct drm_i915_gem_object *obj,
+ unsigned *needs_clflush)
+{
+ int ret;
+
+ *needs_clflush = 0;
+ if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
+ return -EINVAL;
+
+ if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
+ ret = i915_gem_object_wait_rendering(obj, false);
if (ret)
return ret;
+
+ /* If we're not in the cpu write domain, set ourself into the
+* gtt write domain and manually flush cachelines (as required).
+* This optimizes for the case when the gpu will use the data
+* right away and we therefore have to clflush anyway.
+*/
+ *needs_clflush |= cpu_write_needs_clflush(obj) << 1;
}
+ /* Same trick applies to invalidate partially written cachelines read
+* before writing.
+*/
+ if ((obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0)
+ *needs_
[Intel-gfx] [PATCH 4/8] drm/i915: Before accessing an object via the cpu, flush GTT writes
If we want to read the pages directly via the CPU, we have to be sure
that we have to flush the writes via the GTT (as the CPU can not see
the address aliasing).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c6d06cb21191..18b4a684ddde 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -571,6 +571,8 @@ int i915_gem_obj_prepare_shmem_read(struct
drm_i915_gem_object *obj,
if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -EINVAL;
+ i915_gem_object_flush_gtt_write_domain(obj);
+
if (!(obj->base.read_domains & I915_GEM_DOMAIN_CPU)) {
ret = i915_gem_object_wait_rendering(obj, true);
if (ret)
@@ -611,6 +613,8 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -EINVAL;
+ i915_gem_object_flush_gtt_write_domain(obj);
+
if (obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
ret = i915_gem_object_wait_rendering(obj, false);
if (ret)
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Start tidying up execbuf relocations
Just a small set of changes after the last 100 or so that start preparing for an overhaul of execbuf relocation processing - though immediately after these in my queue are partial VMA handling... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: Wait for writes through the GTT to land before reading back
If we quickly switch from writing through the GTT to a read of the
physical page directly with the CPU (e.g. performing relocations through
the GTT and then running the command parser), we can observe that the
writes are not visible to the CPU. It is not a coherency problem, as
extensive investigations with clflush have demonstrated, but a mere
timing issue - we have to wait for the GTT to complete it's write before
we start our read from the CPU.
The issue can be illustrated in userspace with:
gtt = gem_mmap__gtt(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
cpu = gem_mmap__cpu(fd, handle, 0, OBJECT_SIZE, PROT_READ | PROT_WRITE);
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
for (i = 0; i < OBJECT_SIZE / 64; i++) {
int x = 16*i + (i%16);
gtt[x] = i;
clflush(&cpu[x], sizeof(cpu[x]));
assert(cpu[x] == i);
}
Experimenting with that shows that this behaviour is indeed limited to
recent Atom-class hardware.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 18b4a684ddde..ffe3d3e9d69d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2898,20 +2898,30 @@ i915_gem_clflush_object(struct drm_i915_gem_object *obj,
static void
i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
uint32_t old_write_domain;
if (obj->base.write_domain != I915_GEM_DOMAIN_GTT)
return;
/* No actual flushing is required for the GTT write domain. Writes
-* to it immediately go to main memory as far as we know, so there's
+* to it "immediately" go to main memory as far as we know, so there's
* no chipset flush. It also doesn't land in render cache.
*
* However, we do have to enforce the order so that all writes through
* the GTT land before any writes to the device, such as updates to
* the GATT itself.
+*
+* We also have to wait a bit for the writes to land from the GTT.
+* An uncached read (i.e. mmio) seems to be ideal for the round-trip
+* timing. This issue has only been observed when switching quickly
+* between GTT writes and CPU reads from inside the kernel on recent hw,
+* and it appears to only affect discrete GTT blocks (i.e. on LLC
+* system agents we cannot reproduce this behaviour).
*/
wmb();
+ if (INTEL_INFO(dev_priv)->gen >= 6 && !HAS_LLC(dev_priv))
+ POSTING_READ(RING_ACTHD(dev_priv->engine[RCS].mmio_base));
old_write_domain = obj->base.write_domain;
obj->base.write_domain = 0;
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Print the batchbuffer offset next to BBADDR in error state
It is useful when looking at captured error states to check the recorded
BBADDR register (the address of the last batchbuffer instruction loaded)
against the expected offset of the batch buffer, and so do a quick check
that (a) the capture is true or (b) HEAD hasn't wandered off into the
badlands.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 12 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48cf9dfbe4ac..b333cf4923bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -541,6 +541,7 @@ struct drm_i915_error_state {
struct drm_i915_error_object {
int page_count;
u64 gtt_offset;
+ u64 gtt_size;
u32 *pages[0];
} *ringbuffer, *batchbuffer, *wa_batchbuffer, *ctx, *hws_page;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 76d63e047fae..ab0824b1ce6d 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -249,6 +249,13 @@ static void i915_ring_error_state(struct
drm_i915_error_state_buf *m,
err_printf(m, " IPEIR: 0x%08x\n", ring->ipeir);
err_printf(m, " IPEHR: 0x%08x\n", ring->ipehr);
err_printf(m, " INSTDONE: 0x%08x\n", ring->instdone);
+ if (ring->batchbuffer) {
+ u64 start = ring->batchbuffer->gtt_offset;
+ u64 end = start + ring->batchbuffer->gtt_size;
+ err_printf(m, " batch: [0x%08x %08x, 0x%08x %08x]\n",
+ upper_32_bits(start), lower_32_bits(start),
+ upper_32_bits(end), lower_32_bits(end));
+ }
if (INTEL_INFO(dev)->gen >= 4) {
err_printf(m, " BBADDR: 0x%08x %08x\n",
(u32)(ring->bbaddr>>32), (u32)ring->bbaddr);
err_printf(m, " BB_STATE: 0x%08x\n", ring->bbstate);
@@ -655,7 +662,10 @@ i915_error_object_create(struct drm_i915_private *dev_priv,
if (dst == NULL)
return NULL;
- reloc_offset = dst->gtt_offset = vma->node.start;
+ dst->gtt_offset = vma->node.start;
+ dst->gtt_size = vma->node.size;
+
+ reloc_offset = dst->gtt_offset;
use_ggtt = (src->cache_level == I915_CACHE_NONE &&
(vma->bound & GLOBAL_BIND) &&
reloc_offset + num_pages * PAGE_SIZE <= ggtt->mappable_end);
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915: Tidy up flush cpu/gtt write domains
Since we know the write domain, we can drop the local variable and make
the code look a tiny bit simpler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8c90b6a12d45..45f878350d66 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2913,7 +2913,6 @@ static void
i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
- uint32_t old_write_domain;
if (obj->base.write_domain != I915_GEM_DOMAIN_GTT)
return;
@@ -2937,36 +2936,30 @@ i915_gem_object_flush_gtt_write_domain(struct
drm_i915_gem_object *obj)
if (INTEL_INFO(dev_priv)->gen >= 6 && !HAS_LLC(dev_priv))
POSTING_READ(RING_ACTHD(dev_priv->engine[RCS].mmio_base));
- old_write_domain = obj->base.write_domain;
- obj->base.write_domain = 0;
-
intel_fb_obj_flush(obj, false, ORIGIN_GTT);
+ obj->base.write_domain = 0;
trace_i915_gem_object_change_domain(obj,
obj->base.read_domains,
- old_write_domain);
+ I915_GEM_DOMAIN_GTT);
}
/** Flushes the CPU write domain for the object if it's dirty. */
static void
i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object *obj)
{
- uint32_t old_write_domain;
-
if (obj->base.write_domain != I915_GEM_DOMAIN_CPU)
return;
if (i915_gem_clflush_object(obj, obj->pin_display))
i915_gem_chipset_flush(to_i915(obj->base.dev));
- old_write_domain = obj->base.write_domain;
- obj->base.write_domain = 0;
-
intel_fb_obj_flush(obj, false, ORIGIN_CPU);
+ obj->base.write_domain = 0;
trace_i915_gem_object_change_domain(obj,
obj->base.read_domains,
- old_write_domain);
+ I915_GEM_DOMAIN_CPU);
}
/**
--
2.8.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915: Refactor execbuffer relocation writing
With in the introduction of the reloc page cache, we are just one step
away from refactoring the relocation write functions into one. Not only
does it tidy the code (slightly), but it greatly simplifies the control
logic much to gcc's satisfaction.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 289 +++--
1 file changed, 150 insertions(+), 139 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 318c71b663f4..bda8ec8b02e6 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -34,6 +34,8 @@
#include
#include
+#define DBG_USE_CPU_RELOC 0 /* force relocations to use the CPU write path */
+
#define __EXEC_OBJECT_HAS_PIN (1U<<31)
#define __EXEC_OBJECT_HAS_FENCE (1U<<30)
#define __EXEC_OBJECT_NEEDS_MAP (1U<<29)
@@ -53,6 +55,7 @@ struct i915_execbuffer_params {
};
struct eb_vmas {
+ struct drm_i915_private *i915;
struct list_head vmas;
int and;
union {
@@ -62,7 +65,8 @@ struct eb_vmas {
};
static struct eb_vmas *
-eb_create(struct drm_i915_gem_execbuffer2 *args)
+eb_create(struct drm_i915_private *i915,
+ struct drm_i915_gem_execbuffer2 *args)
{
struct eb_vmas *eb = NULL;
@@ -89,6 +93,7 @@ eb_create(struct drm_i915_gem_execbuffer2 *args)
} else
eb->and = -args->buffer_count;
+ eb->i915 = i915;
INIT_LIST_HEAD(&eb->vmas);
return eb;
}
@@ -272,7 +277,8 @@ static void eb_destroy(struct eb_vmas *eb)
static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
{
- return (HAS_LLC(obj->base.dev) ||
+ return (DBG_USE_CPU_RELOC ||
+ HAS_LLC(obj->base.dev) ||
obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
obj->cache_level != I915_CACHE_NONE);
}
@@ -296,32 +302,58 @@ static inline uint64_t gen8_noncanonical_addr(uint64_t
address)
}
static inline uint64_t
-relocation_target(struct drm_i915_gem_relocation_entry *reloc,
+relocation_target(const struct drm_i915_gem_relocation_entry *reloc,
uint64_t target_offset)
{
return gen8_canonical_addr((int)reloc->delta + target_offset);
}
struct reloc_cache {
- void *vaddr;
+ struct drm_i915_private *i915;
+ unsigned long vaddr;
unsigned page;
- enum { KMAP, IOMAP } type;
+ struct drm_mm_node node;
+ bool use_64bit_reloc;
};
-static void reloc_cache_init(struct reloc_cache *cache)
+static void reloc_cache_init(struct reloc_cache *cache,
+struct drm_i915_private *i915)
{
cache->page = -1;
- cache->vaddr = NULL;
+ cache->vaddr = 0;
+ cache->i915 = i915;
+ cache->use_64bit_reloc = INTEL_GEN(cache->i915) >= 8;
+}
+
+static inline void *unmask_page(unsigned long p)
+{
+ return (void *)(uintptr_t)(p & PAGE_MASK);
}
+static inline unsigned unmask_flags(unsigned long p)
+{
+ return p & ~PAGE_MASK;
+}
+
+#define KMAP 0x4
+
static void reloc_cache_fini(struct reloc_cache *cache)
{
- if (cache->vaddr == NULL)
+ void *vaddr;
+
+ if (cache->vaddr == 0)
return;
- switch (cache->type) {
- case KMAP: kunmap_atomic(cache->vaddr); break;
- case IOMAP: io_mapping_unmap_atomic(cache->vaddr); break;
+ vaddr = unmask_page(cache->vaddr);
+ if (cache->vaddr & KMAP) {
+ if (cache->vaddr & CLFLUSH_AFTER)
+ mb();
+
+ kunmap_atomic(vaddr);
+ i915_gem_object_unpin_pages((struct drm_i915_gem_object
*)cache->node.mm);
+ } else {
+ io_mapping_unmap_atomic(vaddr);
+ i915_vma_unpin((struct i915_vma *)cache->node.mm);
}
}
@@ -329,148 +361,138 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
struct reloc_cache *cache,
int page)
{
- if (cache->page == page)
- return cache->vaddr;
+ void *vaddr;
- if (cache->vaddr)
- kunmap_atomic(cache->vaddr);
+ if (cache->vaddr) {
+ kunmap_atomic(unmask_page(cache->vaddr));
+ } else {
+ unsigned flushes;
+ int ret;
+
+ ret = i915_gem_obj_prepare_shmem_write(obj, &flushes);
+ if (ret)
+ return ERR_PTR(ret);
+ cache->vaddr = flushes | KMAP;
+ cache->node.mm = (void *)obj;
+ if (flushes)
+ mb();
+ }
+
+ vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
+ cache->vaddr = unmask_flags(cache->vaddr) | (unsigned long)vaddr;
cache->page = page;
- cache->vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
- cache->type = KMAP;
- return cache->vaddr;
+ return
[Intel-gfx] [PATCH 2/8] drm/i915: Cache kmap between relocations
When doing relocations, we have to obtain a mapping to the page
containing the target address. This is either a kmap or iomap depending
on GPU and its cache coherency. Neighbouring relocation entries are
typically within the same page and so we can cache our kmapping between
them and avoid those pesky TLB flushes.
Note that there is some sleight-of-hand in how the slow relocate works
as the reloc_entry_cache implies pagefaults disabled (as we are inside a
kmap_atomic section). However, the slow relocate code is meant to be the
fallback from the atomic fast path failing. Fortunately it works as we
already have performed the copy_from_user for the relocation array (no
more pagefaults there) and the kmap_atomic cache is enabled after we
have waited upon an active buffer (so no more sleeping in atomic).
Magic!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 160 +++--
1 file changed, 106 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a29c4b6fea28..318c71b663f4 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -302,9 +302,50 @@ relocation_target(struct drm_i915_gem_relocation_entry
*reloc,
return gen8_canonical_addr((int)reloc->delta + target_offset);
}
+struct reloc_cache {
+ void *vaddr;
+ unsigned page;
+ enum { KMAP, IOMAP } type;
+};
+
+static void reloc_cache_init(struct reloc_cache *cache)
+{
+ cache->page = -1;
+ cache->vaddr = NULL;
+}
+
+static void reloc_cache_fini(struct reloc_cache *cache)
+{
+ if (cache->vaddr == NULL)
+ return;
+
+ switch (cache->type) {
+ case KMAP: kunmap_atomic(cache->vaddr); break;
+ case IOMAP: io_mapping_unmap_atomic(cache->vaddr); break;
+ }
+}
+
+static void *reloc_kmap(struct drm_i915_gem_object *obj,
+ struct reloc_cache *cache,
+ int page)
+{
+ if (cache->page == page)
+ return cache->vaddr;
+
+ if (cache->vaddr)
+ kunmap_atomic(cache->vaddr);
+
+ cache->page = page;
+ cache->vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
+ cache->type = KMAP;
+
+ return cache->vaddr;
+}
+
static int
relocate_entry_cpu(struct drm_i915_gem_object *obj,
struct drm_i915_gem_relocation_entry *reloc,
+ struct reloc_cache *cache,
uint64_t target_offset)
{
struct drm_device *dev = obj->base.dev;
@@ -317,34 +358,47 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj,
if (ret)
return ret;
- vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj,
- reloc->offset >> PAGE_SHIFT));
+ vaddr = reloc_kmap(obj, cache, reloc->offset >> PAGE_SHIFT);
*(uint32_t *)(vaddr + page_offset) = lower_32_bits(delta);
- if (INTEL_INFO(dev)->gen >= 8) {
- page_offset = offset_in_page(page_offset + sizeof(uint32_t));
-
- if (page_offset == 0) {
- kunmap_atomic(vaddr);
- vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj,
- (reloc->offset + sizeof(uint32_t)) >> PAGE_SHIFT));
+ if (INTEL_GEN(dev) >= 8) {
+ page_offset += sizeof(uint32_t);
+ if (page_offset == PAGE_SIZE) {
+ vaddr = reloc_kmap(obj, cache, cache->page + 1);
+ page_offset = 0;
}
-
*(uint32_t *)(vaddr + page_offset) = upper_32_bits(delta);
}
- kunmap_atomic(vaddr);
-
return 0;
}
+static void *reloc_iomap(struct drm_i915_private *i915,
+struct reloc_cache *cache,
+uint64_t offset)
+{
+ if (cache->page == offset >> PAGE_SHIFT)
+ return cache->vaddr;
+
+ if (cache->vaddr)
+ io_mapping_unmap_atomic(cache->vaddr);
+
+ cache->page = offset >> PAGE_SHIFT;
+ cache->vaddr =
+ io_mapping_map_atomic_wc(i915->ggtt.mappable,
+offset & PAGE_MASK);
+ cache->type = IOMAP;
+
+ return cache->vaddr;
+}
+
static int
relocate_entry_gtt(struct drm_i915_gem_object *obj,
struct drm_i915_gem_relocation_entry *reloc,
+ struct reloc_cache *cache,
uint64_t target_offset)
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
- struct i915_ggtt *ggtt = &dev_priv->ggtt;
struct i915_vma *vma;
uint64_t delta = relocation_target(reloc, target_offset);
uint64_t offset;
@@ -366,28 +420,19 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
/* Map the page containing the relocation we're going to perform. */
offse
Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: fix GuC loading/submission check
On 07/06/16 09:41, Tvrtko Ursulin wrote:
On 07/06/16 09:14, Dave Gordon wrote:
The last stage of the GuC loader also sanitises the GuC submission
settings, so should be called unconditionally (even on platforms
without a GuC) to ensure consistent settings; in particular, this
prevents any attempt to use GuC submission on GuCless platforms!
Also fix error path handling and clarify DRM_INFO fallback message.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 8 +++-
drivers/gpu/drm/i915/intel_guc_loader.c | 12
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 1bfc260..eae8d7a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4930,11 +4930,9 @@ int i915_gem_init_engines(struct drm_device *dev)
intel_mocs_init_l3cc_table(dev);
/* We can't enable contexts until all firmware is loaded */
-if (HAS_GUC(dev)) {
-ret = intel_guc_setup(dev);
-if (ret)
-goto out;
-}
+ret = intel_guc_setup(dev);
+if (ret)
+goto out;
/*
* Increment the next seqno by 0x100 so we have a visible break
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index f2b88c7..4e34c2e 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -425,9 +425,13 @@ int intel_guc_setup(struct drm_device *dev)
if (!i915.enable_guc_loading) {
err = 0;
goto fail;
-} else if (fw_path == NULL || *fw_path == '\0') {
-if (*fw_path == '\0')
Ops. I can only assume I meant !fw_path.
-DRM_INFO("No GuC firmware known for this platform\n");
+} else if (fw_path == NULL) {
+/* Device is known to have no uCode (e.g. no GuC) */
+err = -ENXIO;
+goto fail;
+} else if (*fw_path == '\0') {
+/* Device has a GuC but we don't know what f/w to load? */
+DRM_INFO("No GuC firmware known for this platform\n");
err = -ENODEV;
goto fail;
}
@@ -535,7 +539,7 @@ int intel_guc_setup(struct drm_device *dev)
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not
supported\n");
if (ret == 0)
-DRM_INFO("Falling back to execlist mode\n");
+DRM_INFO("Falling back from GuC submission to execlist
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
Reviewed-by: Tvrtko Ursulin
Bah now on BDW we get on boot:
[drm:gen8_init_common_ring] Execlists enabled for render ring
[drm:gen8_init_common_ring] Execlists enabled for blitter ring
[drm:gen8_init_common_ring] Execlists enabled for bsd ring
[drm:gen8_init_common_ring] Execlists enabled for video enhancement ring
[drm:intel_guc_setup] GuC fw status: path (null), fetch NONE, load NONE
[drm] GuC firmware load skipped
[drm] GuC submission without firmware not supported
[drm] Falling back from GuC submission to execlist mode
Which is a bit untidy. :(
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 7/11] drivers/gpu/drm/arc/arcpgu_crtc.c:149:16: warning: unused variable 'flags'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: ae4df11a0f538b83781cf120a78dde32b0070600
commit: ed4f885657fe7e9bfec3d86a2b426da1e0d0c5de [7/11] drm/arc: Nuke event_list
config: x86_64-randconfig-s5-06091636 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout ed4f885657fe7e9bfec3d86a2b426da1e0d0c5de
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/arc/arcpgu_crtc.c: In function 'arc_pgu_crtc_atomic_begin':
>> drivers/gpu/drm/arc/arcpgu_crtc.c:149:16: warning: unused variable 'flags'
>> [-Wunused-variable]
unsigned long flags;
^
>> drivers/gpu/drm/arc/arcpgu_crtc.c:148:29: warning: unused variable 'arcpgu'
>> [-Wunused-variable]
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
^~
vim +/flags +149 drivers/gpu/drm/arc/arcpgu_crtc.c
51dacf20 Carlos Palminha 2016-02-19 142return 0;
51dacf20 Carlos Palminha 2016-02-19 143 }
51dacf20 Carlos Palminha 2016-02-19 144
51dacf20 Carlos Palminha 2016-02-19 145 static void
arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
51dacf20 Carlos Palminha 2016-02-19 146
struct drm_crtc_state *state)
51dacf20 Carlos Palminha 2016-02-19 147 {
51dacf20 Carlos Palminha 2016-02-19 @148struct arcpgu_drm_private
*arcpgu = crtc_to_arcpgu_priv(crtc);
51dacf20 Carlos Palminha 2016-02-19 @149unsigned long flags;
51dacf20 Carlos Palminha 2016-02-19 150
51dacf20 Carlos Palminha 2016-02-19 151if (crtc->state->event) {
51dacf20 Carlos Palminha 2016-02-19 152struct
drm_pending_vblank_event *event = crtc->state->event;
:: The code at line 149 was first introduced by commit
:: 51dacf208988e5a2561d9b4b560cacc8a7f025e7 drm: Add support of ARC PGU
display controller
:: TO: Carlos Palminha
:: CC: Alexey Brodkin
---
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 v9 08/10] drm/i915: Introduce execlist context status change notification
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Thursday, June 09, 2016 1:45 PM
> To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org
> Cc: ch...@chris-wilson.co.uk; Lv, Zhiyuan ; Tian, Kevin
> ; tvrtko.ursu...@linux.intel.com
> Subject: Re: [PATCH v9 08/10] drm/i915: Introduce execlist context status
> change notification
>
> On to, 2016-06-09 at 03:34 -0400, Zhi Wang wrote:
> > This patch introduces an approach to track the execlist context status
> > change.
> >
> > GVT-g uses GVT context as the "shadow context". The content inside GVT
> > context will be copied back to guest after the context is idle. And
> > GVT-g has to know the status of the execlist context.
> >
> > This function is configurable when creating a new GEM context.
> > Currently, Only GVT-g will create the "status-change-notification"
> > enabled GEM context.
> >
> > v8:
> >
> > - Remove the boolean flag in struct i915_gem_context. (Joonas)
> >
> > v7:
> >
> > - Remove per-engine ctx status notifiers. Use one status notifier for
> > all engines. (Joonas)
> > - Add prefix "INTEL_" for related definitions. (Joonas)
> > - Refine the comments in execlists_context_status_change(). (Joonas)
> >
> > v6:
> >
> > - When !CONFIG_DRM_I915_GVT, make GVT code as dead code then
> compiler
> > could automatically eliminate them for us. (Chris)
> > - Always initialize the notifier header, so it could be switched
> > on/off at runtime. (Chris)
> >
> > v5:
> >
> > - Only compile this feature when CONFIG_DRM_I915_GVT is
> > enabled.(Tvrtko)
> >
> > Reviewed-by: Joonas Lahtinen
> > Cc: Joonas Lahtinen
> > Cc: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Signed-off-by: Zhi Wang
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem_context.c | 1 +
> > drivers/gpu/drm/i915/intel_lrc.c| 22 ++
> > drivers/gpu/drm/i915/intel_lrc.h| 5 +
> > 4 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index a9e22200..c14eb56 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -880,6 +880,7 @@ struct i915_gem_context {
> > } engine[I915_NUM_ENGINES];
> > u32 ring_size;
> > u32 desc_template;
> > + struct atomic_notifier_head status_notifier;
> >
> > struct list_head link;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index e636d85..3c1b83e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -298,6 +298,7 @@ __create_hw_context(struct drm_device *dev,
> > ctx->ring_size = 4 * PAGE_SIZE;
> > ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
> > GEN8_CTX_ADDRESSING_MODE_SHIFT;
> > + ATOMIC_INIT_NOTIFIER_HEAD(&ctx->status_notifier);
> >
> > return ctx;
> >
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 2116f86..7f42b15 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -404,6 +404,20 @@ static void execlists_submit_requests(struct
> drm_i915_gem_request *rq0,
> > spin_unlock_irq(&dev_priv->uncore.lock);
> > }
> >
> > +static inline void execlists_context_status_change(
> > + struct drm_i915_gem_request *rq,
> > + unsigned long status)
> > +{
> > + /*
> > + * Only used when GVT-g is enabled now. When GVT-g is disabled,
> > + * The compiler should eliminate this function as dead-code.
> > + */
> > + if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
> > + return;
> > +
> > + atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq); }
> > +
> > static void execlists_context_unqueue(struct intel_engine_cs *engine)
> > {
> > struct drm_i915_gem_request *req0 = NULL, *req1 = NULL; @@ -439,6
> > +453,12 @@ static void execlists_context_unqueue(struct intel_engine_cs
> *engine)
> > if (unlikely(!req0))
> > return;
> >
> > + execlists_context_status_change(req0, INTEL_CONTEXT_SCHEDULE_IN);
> > +
> > + if (req1)
> > + execlists_context_status_change(req1,
> > + INTEL_CONTEXT_SCHEDULE_IN);
>
No it would exceed 80 characters.
> Indentation is incorrect here. Would it also fit on one line?
>
> > +
> > if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
> > /*
> > * WaIdleLiteRestore: make sure we never cause a lite restore @@
> > -477,6 +497,8 @@ execlists_check_remove_request(struct intel_engine_cs
> *engine, u32 ctx_id)
> > if (--head_req->elsp_submitted > 0)
> > return 0;
> >
> > + execlists_context_status_change(head_req,
> > +INTEL_CONTEXT_SCHEDULE_OUT);
> > +
> > list_del(&head_req->execlist_link);
> > i915_gem_request_unreference(head_req);
> >
> > diff --git a/drivers/gpu/drm/i915
Re: [Intel-gfx] [PATCH v9 07/10] drm/i915: Make addressing mode bits in context descriptor configurable
On to, 2016-06-09 at 03:34 -0400, Zhi Wang wrote:
> Currently the addressing mode bit in context descriptor is statically
> generated from the configuration of system-wide PPGTT usage model.
>
> GVT-g will load the PPGTT shadow page table by itself and probably one
> guest is using a different addressing mode with i915 host. The addressing
> mode bits of a LRC context should be configurable under this case.
>
> v9:
> - Rename the data member in struct i915_gem_context. (Chris)
>
> v8:
> - Rename the data member in struct i915_gem_context. (Chris)
>
> v7:
> - Move context addressing mode bit into i915_reg.h. (Joonas/Chris)
> - Add prefix "INTEL_" for related definitions. (Joonas)
>
> v6:
> - Directly save the addressing mode bits inside i915_gem_context. (Chris)
> - Move the LRC context addressing mode bits into intel_lrc.h. (Chris)
>
> v5:
> - Change USES_FULL_48BIT(dev) to USES_FULL_48BIT(dev_priv) (Tvrtko)
>
> Reviewed-by: Joonas Lahtinen
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
> drivers/gpu/drm/i915/i915_reg.h | 12
> drivers/gpu/drm/i915/intel_lrc.c| 15 ++-
> 4 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c3b4009..a9e22200 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -879,6 +879,7 @@ struct i915_gem_context {
> bool initialised;
> } engine[I915_NUM_ENGINES];
> u32 ring_size;
> + u32 desc_template;
>
> struct list_head link;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index b722fa1..e636d85 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -296,6 +296,8 @@ __create_hw_context(struct drm_device *dev,
>
> ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
> ctx->ring_size = 4 * PAGE_SIZE;
> + ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
> + GEN8_CTX_ADDRESSING_MODE_SHIFT;
Indentation is off.
>
> return ctx;
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 81d1896..cf37bd7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3033,6 +3033,18 @@ enum skl_disp_power_wells {
> /* Same as Haswell, but 72064 bytes now. */
> #define GEN8_CXT_TOTAL_SIZE (18 * PAGE_SIZE)
>
> +enum {
> + INTEL_ADVANCED_CONTEXT = 0,
> + INTEL_LEGACY_32B_CONTEXT,
> + INTEL_ADVANCED_AD_CONTEXT,
> + INTEL_LEGACY_64B_CONTEXT
> +};
> +
> +#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
> +#define GEN8_CTX_ADDRESSING_MODE(dev_priv) (USES_FULL_48BIT_PPGTT(dev_priv)
> ?\
> + INTEL_LEGACY_64B_CONTEXT : \
> + INTEL_LEGACY_32B_CONTEXT)
> +
> #define CHV_CLK_CTL1 _MMIO(0x101100)
> #define VLV_CLK_CTL2 _MMIO(0x101104)
> #define CLK_CTL2_CZCOUNT_30NS_SHIFT28
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 177b61d..2116f86 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -208,16 +208,6 @@
> } while (0)
>
> enum {
> - ADVANCED_CONTEXT = 0,
> - LEGACY_32B_CONTEXT,
> - ADVANCED_AD_CONTEXT,
> - LEGACY_64B_CONTEXT
> -};
> -#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
> -#define GEN8_CTX_ADDRESSING_MODE(dev) (USES_FULL_48BIT_PPGTT(dev) ?\
> - LEGACY_64B_CONTEXT :\
> - LEGACY_32B_CONTEXT)
> -enum {
> FAULT_AND_HANG = 0,
> FAULT_AND_HALT, /* Debug only */
> FAULT_AND_STREAM,
> @@ -281,8 +271,6 @@ logical_ring_init_platform_invariants(struct
> intel_engine_cs *engine)
> (engine->id == VCS || engine->id ==
> VCS2);
>
> engine->ctx_desc_template = GEN8_CTX_VALID;
> - engine->ctx_desc_template |= GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
> - GEN8_CTX_ADDRESSING_MODE_SHIFT;
> if (IS_GEN8(dev_priv))
> engine->ctx_desc_template |= GEN8_CTX_L3LLC_COHERENT;
> engine->ctx_desc_template |= GEN8_CTX_PRIVILEGE;
> @@ -325,7 +313,8 @@ intel_lr_context_descriptor_update(struct
> i915_gem_context *ctx,
>
> BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1<
>
> - desc = engine->ctx_desc_template; /* bits 0-11 */
> + desc = ctx->desc_template; /* bits 3-4 */
> + desc |= engine->ctx_desc_template; /* bits 0-11 */
> desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
> /* bits 12-31 */
> desc |= (u64)ctx->hw_id << GEN8_CTX_I
Re: [Intel-gfx] [PATCH v9 08/10] drm/i915: Introduce execlist context status change notification
On to, 2016-06-09 at 03:34 -0400, Zhi Wang wrote:
> This patch introduces an approach to track the execlist context status
> change.
>
> GVT-g uses GVT context as the "shadow context". The content inside GVT
> context will be copied back to guest after the context is idle. And GVT-g
> has to know the status of the execlist context.
>
> This function is configurable when creating a new GEM context. Currently,
> Only GVT-g will create the "status-change-notification" enabled GEM
> context.
>
> v8:
>
> - Remove the boolean flag in struct i915_gem_context. (Joonas)
>
> v7:
>
> - Remove per-engine ctx status notifiers. Use one status notifier for all
> engines. (Joonas)
> - Add prefix "INTEL_" for related definitions. (Joonas)
> - Refine the comments in execlists_context_status_change(). (Joonas)
>
> v6:
>
> - When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler
> could automatically eliminate them for us. (Chris)
> - Always initialize the notifier header, so it could be switched on/off
> at runtime. (Chris)
>
> v5:
>
> - Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko)
>
> Reviewed-by: Joonas Lahtinen
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gem_context.c | 1 +
> drivers/gpu/drm/i915/intel_lrc.c| 22 ++
> drivers/gpu/drm/i915/intel_lrc.h| 5 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a9e22200..c14eb56 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -880,6 +880,7 @@ struct i915_gem_context {
> } engine[I915_NUM_ENGINES];
> u32 ring_size;
> u32 desc_template;
> + struct atomic_notifier_head status_notifier;
>
> struct list_head link;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index e636d85..3c1b83e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -298,6 +298,7 @@ __create_hw_context(struct drm_device *dev,
> ctx->ring_size = 4 * PAGE_SIZE;
> ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
> GEN8_CTX_ADDRESSING_MODE_SHIFT;
> + ATOMIC_INIT_NOTIFIER_HEAD(&ctx->status_notifier);
>
> return ctx;
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 2116f86..7f42b15 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -404,6 +404,20 @@ static void execlists_submit_requests(struct
> drm_i915_gem_request *rq0,
> spin_unlock_irq(&dev_priv->uncore.lock);
> }
>
> +static inline void execlists_context_status_change(
> + struct drm_i915_gem_request *rq,
> + unsigned long status)
> +{
> + /*
> + * Only used when GVT-g is enabled now. When GVT-g is disabled,
> + * The compiler should eliminate this function as dead-code.
> + */
> + if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
> + return;
> +
> + atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq);
> +}
> +
> static void execlists_context_unqueue(struct intel_engine_cs *engine)
> {
> struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
> @@ -439,6 +453,12 @@ static void execlists_context_unqueue(struct
> intel_engine_cs *engine)
> if (unlikely(!req0))
> return;
>
> + execlists_context_status_change(req0, INTEL_CONTEXT_SCHEDULE_IN);
> +
> + if (req1)
> + execlists_context_status_change(req1,
> + INTEL_CONTEXT_SCHEDULE_IN);
Indentation is incorrect here. Would it also fit on one line?
> +
> if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
> /*
> * WaIdleLiteRestore: make sure we never cause a lite restore
> @@ -477,6 +497,8 @@ execlists_check_remove_request(struct intel_engine_cs
> *engine, u32 ctx_id)
> if (--head_req->elsp_submitted > 0)
> return 0;
>
> + execlists_context_status_change(head_req, INTEL_CONTEXT_SCHEDULE_OUT);
> +
> list_del(&head_req->execlist_link);
> i915_gem_request_unreference(head_req);
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index a8db42a..2b8255c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -57,6 +57,11 @@
> #define GEN8_CSB_READ_PTR(csb_status) \
> (((csb_status) & GEN8_CSB_READ_PTR_MASK) >> 8)
>
> +enum {
> + INTEL_CONTEXT_SCHEDULE_IN = 0,
> + INTEL_CONTEXT_SCHEDULE_OUT,
> +};
> +
> /* Logical Rings */
> int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
> *request);
> int intel_logical_ring_reserve_space(struct drm_i915_gem_request *req
Re: [Intel-gfx] [PATCH v4 05/11] drm: Helper to read max bits per component
On Thu, 2016-06-09 at 11:02 +0300, Ville Syrjälä wrote:
> On Mon, Jun 06, 2016 at 04:29:07PM +0300, Mika Kahola wrote:
> > Helper routine to read out maximum supported bits per
> > component for DisplayPort legay converters.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 31 +++
> > include/drm/drm_dp_helper.h | 2 ++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 18b72eb..bac0ccc 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -507,6 +507,37 @@ int drm_dp_downstream_max_clock(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE],
> > }
> > EXPORT_SYMBOL(drm_dp_downstream_max_clock);
> >
> > +/**
> > + * drm_dp_downstream_max_bpc() - extract branch device max
> > + * bits per component
> > + * @dpcd: DisplayPort configuration data
> > + * @port_cap: port capabilities
> > + *
> > + * Returns max bpc on success or negative error code on failure
> > + */
> > +int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > + const u8 port_cap[4])
> > +{
> > + int type = drm_dp_downstream_type(dpcd, port_cap);
> > + bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > + DP_DETAILED_CAP_INFO_AVAILABLE;
> > +
> > + if (detailed_cap_info) {
>
> Early return again.
>
> > + if (type != DP_DS_PORT_TYPE_WIRELESS) {
>
> switch() again.
>
> > + int tmp;
> > + tmp = port_cap[2] & DP_DS_VGA_MAX_BPC_MASK;
>
> Should drop the "VGA" from that stuff since it applies to more than
> that.
Agreed. Maybe we could rename it as DP_DS_MAX_BPC_MASK instead.
>
> > +
> > + if (tmp == 0)
> > + return 8;
> > + else
> > + return 8 + (1<
> switch() with each case would be less magicy.
>
> > + }
> > + }
> > +
> > + return -EINVAL;
>
> Again I think I'd just use 0 here.
>
> > +}
> > +EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> > +
> > /*
> > * I2C-over-AUX implementation
> > */
> > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > index c3324d3..d4abc38 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -812,6 +812,8 @@ int drm_dp_downstream_port_cap(struct drm_dp_aux *aux,
> > int drm_dp_downstream_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE], const u8
> > port_cap[4]);
> > int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > const u8 port_cap[4]);
> > +int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > + const u8 port_cap[4]);
> >
> > int drm_dp_aux_register(struct drm_dp_aux *aux);
> > void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> > --
> > 1.9.1
>
--
Mika Kahola - Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for Introduce the implementation of GVT context (rev7)
Hi: As this series are not related to display subsystem, according to Joonas' suggestion, I opened a new bug: Bug 96448 - [BDW]igt@kms_pipe_crc_basic@suspend-read-crc-pipe-? cause dmesg warn https://bugs.freedesktop.org/show_bug.cgi?id=96448 Thanks, Zhi. > -Original Message- > From: Patchwork [mailto:patchw...@emeril.freedesktop.org] > Sent: Thursday, June 09, 2016 11:01 AM > To: Wang, Zhi A > Cc: intel-gfx@lists.freedesktop.org > Subject: ✗ Ro.CI.BAT: warning for Introduce the implementation of GVT context > (rev7) > > == Series Details == > > Series: Introduce the implementation of GVT context (rev7) > URL : https://patchwork.freedesktop.org/series/7208/ > State : warning > > == Summary == > > Series 7208v7 Introduce the implementation of GVT context > http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/7/mbox > > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-a: > skip -> DMESG-WARN (ro-bdw-i7-5557U) > Subgroup suspend-read-crc-pipe-b: > dmesg-warn -> SKIP (ro-bdw-i7-5557U) > > fi-bdw-i7-5557u total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 > fi-skl-i5-6260u total:209 pass:198 dwarn:0 dfail:0 fail:0 skip:11 > fi-skl-i7-6700k total:209 pass:184 dwarn:0 dfail:0 fail:0 skip:25 > fi-snb-i7-2600 total:209 pass:170 dwarn:0 dfail:0 fail:0 skip:39 > ro-bdw-i7-5557U total:209 pass:193 dwarn:2 dfail:0 fail:0 > skip:14 > ro-bdw-i7-5600u total:209 pass:180 dwarn:0 dfail:0 fail:1 > skip:28 > ro-bsw-n3050 total:209 pass:168 dwarn:0 dfail:0 fail:2 > skip:39 > ro-byt-n2820 total:209 pass:169 dwarn:0 dfail:0 fail:3 > skip:37 > ro-hsw-i3-4010u total:209 pass:186 dwarn:0 dfail:0 fail:0 > skip:23 > ro-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 > ro-ilk1-i5-650 total:204 pass:146 dwarn:0 dfail:0 fail:1 skip:57 > ro-ivb-i7-3770 total:209 pass:177 dwarn:0 dfail:0 fail:0 skip:32 > ro-ivb2-i7-3770 total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:28 > ro-snb-i7-2620M total:209 pass:170 dwarn:0 dfail:0 fail:1 > skip:38 > fi-hsw-i7-4770k failed to connect after reboot ro-bdw-i5-5250u failed to > connect > after reboot > > Results at /archive/results/CI_IGT_test/RO_Patchwork_1145/ > > d54fc9b drm-intel-nightly: 2016y-06m-09d-06h-54m-13s UTC integration > manifest e416bdc drm/i915: Introduce GVT context creation API > 28601f2 drm/i915: Support LRC context single submission > 63a1554 drm/i915: Introduce execlist context status change notification > f884812 drm/i915: Make addressing mode bits in context descriptor > configurable > 0cfb715 drm/i915: Make ring buffer size of a LRC context configurable 7ca788b > drm/i915: Introduce host graphics memory partition for GVT-g > 03fb327 drm/i915: gvt: Introduce the basic architecture of GVT-g e4d90fd > drm/i915: Fold vGPU active check into inner functions > db4e422 drm/i915: Use offsetof() to calculate the offset of members in PVINFO > page 69cfc5a drm/i915: Factor out i915_pvinfo.h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/bxt: Fix DDI PHY setup for low resolutions (rev4)
Somehow threading seems to be broken, v2 of 6/6 is applied out of order after 1/6. Also I can't see v2 of 2/6 and v2 of 4/6 at [1] which I sent along with v2 of 6/6. AFAICS the In-reply-to fields were correct in the v2 versions I sent. --Imre [1] https://patchwork.freedesktop.org/series/8414/ > == Series Details == > > Series: drm/i915/bxt: Fix DDI PHY setup for low resolutions (rev4) > URL : https://patchwork.freedesktop.org/series/8414/ > State : failure > > == Summary == > > Applying: drm/i915/bxt: Wait for PHY1 GRC calibration synchronously > Applying: drm/i915/bxt: Sanitiy check the PHY lane power down status > fatal: sha1 information is lacking or > useless(drivers/gpu/drm/i915/intel_ddi.c). > error: could not build fake ancestor > Patch failed at 0002 drm/i915/bxt: Sanitiy check the PHY lane power down > status > The copy of the patch that failed is found in: .git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Use insert_page for pwrite_fast
On 08/06/16 13:20, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
aperture. It also allows us to handle objects larger than the mappable
aperture (e.g. if we need to pwrite with vGPU restricting the aperture
to a measely 8MiB or something like that).
v2: Pin pages before starting pwrite, Combined duplicate loops (Chris)
v3: Combined loops based on local patch by Chris (Chris)
v4: Added i915 wrapper function for drm_mm_insert_node_in_range (Chris)
v5: Renamed wrapper function for drm_mm_insert_node_in_range (Chris)
v5: Added wrapper for drm_mm_remove_node() (Chris)
v6: Added get_pages call before pinning the pages (Tvrtko)
Added remove_mappable_node() wrapper for drm_mm_remove_node() (Chris)
v7: Added size argument for insert_mappable_node (Tvrtko)
v8: Do not put_pages after pwrite, do memset of node in the wrapper
function (insert_mappable_node) (Chris)
v9: Rebase (Ankit)
Signed-off-by: Ankitprasad Sharma
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 90 +++--
1 file changed, 68 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eae8d7a..452178c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -60,6 +60,24 @@ static bool cpu_write_needs_clflush(struct
drm_i915_gem_object *obj)
return obj->pin_display;
}
+static int
+insert_mappable_node(struct drm_i915_private *i915,
+ struct drm_mm_node *node, u32 size)
+{
+ memset(node, 0, sizeof(*node));
+ return drm_mm_insert_node_in_range_generic(&i915->ggtt.base.mm, node,
+ size, 0, 0, 0,
+ i915->ggtt.mappable_end,
+ DRM_MM_SEARCH_DEFAULT,
+ DRM_MM_CREATE_DEFAULT);
+}
+
+static void
+remove_mappable_node(struct drm_mm_node *node)
+{
+ drm_mm_remove_node(node);
+}
+
/* some bookkeeping */
static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
size_t size)
@@ -765,21 +783,34 @@ fast_user_write(struct io_mapping *mapping,
* @file: drm file pointer
*/
static int
-i915_gem_gtt_pwrite_fast(struct drm_device *dev,
+i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
Please follow-up with a patch fixing kernel doc for this function as
kbuild robot noticed yesterday.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
== Series Details == Series: drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate URL : https://patchwork.freedesktop.org/series/8487/ State : success == Summary == Series 8487v1 drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate http://patchwork.freedesktop.org/api/1.0/series/8487/revisions/1/mbox Test kms_flip: Subgroup basic-flip-vs-wf_vblank: fail -> PASS (ro-bdw-i7-5600u) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: dmesg-warn -> SKIP (ro-bdw-i5-5250u) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> SKIP (ro-bdw-i7-5557U) fi-bdw-i7-5557u total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 fi-skl-i5-6260u total:209 pass:198 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-i7-6700k total:209 pass:184 dwarn:0 dfail:0 fail:0 skip:25 fi-snb-i7-2600 total:209 pass:170 dwarn:0 dfail:0 fail:0 skip:39 ro-bdw-i5-5250u total:209 pass:193 dwarn:3 dfail:0 fail:0 skip:13 ro-bdw-i7-5557U total:209 pass:193 dwarn:1 dfail:0 fail:0 skip:15 ro-bdw-i7-5600u total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:28 ro-bsw-n3050 total:209 pass:168 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:209 pass:169 dwarn:0 dfail:0 fail:3 skip:37 ro-hsw-i3-4010u total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk1-i5-650 total:204 pass:146 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:209 pass:177 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:28 ro-snb-i7-2620M total:209 pass:170 dwarn:0 dfail:0 fail:1 skip:38 Results at /archive/results/CI_IGT_test/RO_Patchwork_1146/ d54fc9b drm-intel-nightly: 2016y-06m-09d-06h-54m-13s UTC integration manifest ce836e8 drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, June 09, 2016 9:34 AM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate
>
> On Thu, 09 Jun 2016, tim.g...@intel.com wrote:
> > From: Tim Gore
> >
> > This patch enables a workaround for a mid thread preemption issue
> > where a hardware timing problem can prevent the context restore from
> > happening, leading to a hang.
> >
> > Signed-off-by: Tim Gore
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
> > drivers/gpu/drm/i915/i915_reg.h | 4
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 4668477..e9046f6 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2156,6 +2156,12 @@ static void gtt_write_workarounds(struct
> drm_device *dev)
> > I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
> > else if (IS_BROXTON(dev))
> > I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> > GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
> > +
> > + /* WaConextSwitchWithConcurrentTLBInvalidate:gen9 */
> ^^
>
> Typo or sic?
>
> BR,
> Jani.
>
Sic !!
Tim
>
> > + if (IS_GEN9(dev))
> > + {
> > + I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
> > + }
> > }
> >
> > static int i915_ppgtt_init(struct drm_device *dev, struct
> > i915_hw_ppgtt *ppgtt) diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 81d1896..2a6fc62 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
> > #define GEN9_IZ_HASHING_MASK(slice) (0x3 <<
> ((slice) * 2))
> > #define GEN9_IZ_HASHING(slice, val) ((val) <<
> ((slice) * 2))
> >
> > +/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
> > +#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
> > +#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
> > +
> > /* WaClearTdlStateAckDirtyBits */
> > #define GEN8_STATE_ACK _MMIO(0x20F0)
> > #define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
>
> --
> 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 0/3] CHV vblank failures when PSR is active
On Thu, Jun 09, 2016 at 11:31:20AM +0300, Jani Nikula wrote: > On Thu, 09 Jun 2016, Dhinakaran Pandiyan > wrote: > > IGT vblank tests fail on CHV by timing out on VBIs if PSR is enabled. We > > do not get VBIs as the source timing generation is disabled when PSR is > > active. The first two patches written by Rodrigo add drm hooks. Patch 3 > > deactivates PSR when VBI are needed. > > The first thing to do would be to submit a patch that disables PSR by > default on CHV. We can enable it again if and when these patches land. I already reverted the "enable by default" patch some time ago. -- 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] [PATCH] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
On Thu, 09 Jun 2016, tim.g...@intel.com wrote:
> From: Tim Gore
>
> This patch enables a workaround for a mid thread preemption
> issue where a hardware timing problem can prevent the
> context restore from happening, leading to a hang.
>
> Signed-off-by: Tim Gore
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
> drivers/gpu/drm/i915/i915_reg.h | 4
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 4668477..e9046f6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2156,6 +2156,12 @@ static void gtt_write_workarounds(struct drm_device
> *dev)
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
> else if (IS_BROXTON(dev))
> I915_WRITE(GEN8_L3_LRA_1_GPGPU,
> GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
> +
> + /* WaConextSwitchWithConcurrentTLBInvalidate:gen9 */
^^
Typo or sic?
BR,
Jani.
> + if (IS_GEN9(dev))
> + {
> + I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
> _MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
> + }
> }
>
> static int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt
> *ppgtt)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 81d1896..2a6fc62 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
> #define GEN9_IZ_HASHING_MASK(slice)(0x3 <<
> ((slice) * 2))
> #define GEN9_IZ_HASHING(slice, val)((val) <<
> ((slice) * 2))
>
> +/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
> +#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
> +#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
> +
> /* WaClearTdlStateAckDirtyBits */
> #define GEN8_STATE_ACK _MMIO(0x20F0)
> #define GEN9_STATE_ACK_SLICE1_MMIO(0x20F8)
--
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 07/20] drm: mediatek: Rely on the default ->best_encoder() behavior
On 07/06/16 13:48, Boris Brezillon wrote:
We have a 1:1 relationship between connectors and encoders and the
driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementation and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezillon
Reviewed-by: Matthias Brugger
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 2d808e5..7343ffc 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -575,14 +575,6 @@ static int mtk_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static struct drm_encoder *mtk_dsi_connector_best_encoder(
- struct drm_connector *connector)
-{
- struct mtk_dsi *dsi = connector_to_dsi(connector);
-
- return &dsi->encoder;
-}
-
static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
.mode_fixup = mtk_dsi_encoder_mode_fixup,
.mode_set = mtk_dsi_encoder_mode_set,
@@ -603,7 +595,6 @@ static const struct drm_connector_funcs
mtk_dsi_connector_funcs = {
static const struct drm_connector_helper_funcs
mtk_dsi_connector_helper_funcs = {
.get_modes = mtk_dsi_connector_get_modes,
- .best_encoder = mtk_dsi_connector_best_encoder,
};
static int mtk_drm_attach_bridge(struct drm_bridge *bridge,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 09/11] drm/i915: Check pixel rate for DP to VGA dongle
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, June 9, 2016 11:14 AM
> To: Kahola, Mika
> Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> jim.br...@linux.intel.com; daniel.vet...@ffwll.ch
> Subject: Re: [PATCH v4 09/11] drm/i915: Check pixel rate for DP to VGA
> dongle
>
> On Mon, Jun 06, 2016 at 04:29:11PM +0300, Mika Kahola wrote:
> > Filter out a mode that exceeds the max pixel rate setting for DP to
> > VGA dongle. This is defined in DPCD register 0x81 if detailed cap info
> > i.e. info field is 4 bytes long and it is available for DP downstream
> > port.
> >
> > The register defines the pixel rate divided by 8 in MP/s.
> >
> > v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> > v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> > function (Daniel)
> > v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c index 096acbf0..1b94347 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -200,6 +200,23 @@ intel_dp_mode_valid(struct drm_connector
> *connector,
> > int target_clock = mode->clock;
> > int max_rate, mode_rate, max_lanes, max_link_clock;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > + bool is_branch_device;
> > + int max_dp_clk;
> > + int type;
> > + uint8_t port_cap[4];
> > +
> > + is_branch_device = intel_dp-
> >dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> > + DP_DWN_STRM_PORT_PRESENT;
> > +
> > + if (is_branch_device) {
> > + drm_dp_downstream_port_cap(&intel_dp->aux, intel_dp-
> >dpcd,
> > +port_cap);
>
> I'm pretty sure we already read out the downstream port caps in fact.
> Hmm, yeah ->downstream_ports. So no need for this, and I suppose no
> need for your helper for the readout either. Just always readoing out the full
> 16 bytes should be fine.
Right, I missed that one. We do read port caps with ->downstream_ports. I'll
skip the helper routines regarding reading out port cap info.
>
> > + type = drm_dp_downstream_type(intel_dp->dpcd,
> port_cap);
> > + max_dp_clk = drm_dp_downstream_max_clock(intel_dp-
> >dpcd, port_cap);
> > +
> > + if ((type == DP_DS_PORT_TYPE_VGA) && (max_dp_clk > 0))
> {
>
> Type check can be skipped if drm_dp_downstream_max_clock() just returns
> 0 for the "don't know" case.
>
> > + max_dotclk = min(max_dotclk, max_dp_clk);
> > + }
> > + }
> >
> > if (is_edp(intel_dp) && fixed_mode) {
> > if (mode->hdisplay > fixed_mode->hdisplay)
> > --
> > 1.9.1
>
> --
> 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] [PATCH 0/3] CHV vblank failures when PSR is active
On Thu, 09 Jun 2016, Dhinakaran Pandiyan wrote: > IGT vblank tests fail on CHV by timing out on VBIs if PSR is enabled. We > do not get VBIs as the source timing generation is disabled when PSR is > active. The first two patches written by Rodrigo add drm hooks. Patch 3 > deactivates PSR when VBI are needed. The first thing to do would be to submit a patch that disables PSR by default on CHV. We can enable it again if and when these patches land. BR, Jani. > > [PATCH 1/3] drm: Add vblank prepare and unprepare hooks. > [PATCH 2/3] drm/i915: Move drm_crtc_vblank_get out of disabled > [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4668477..e9046f6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2156,6 +2156,12 @@ static void gtt_write_workarounds(struct drm_device *dev)
I915_WRITE(GEN8_L3_LRA_1_GPGPU,
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_SKL);
else if (IS_BROXTON(dev))
I915_WRITE(GEN8_L3_LRA_1_GPGPU,
GEN9_L3_LRA_1_GPGPU_DEFAULT_VALUE_BXT);
+
+ /* WaConextSwitchWithConcurrentTLBInvalidate:gen9 */
+ if (IS_GEN9(dev))
+ {
+ I915_WRITE(GEN9_CSFE_CHICKEN1_RCS,
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+ }
}
static int i915_ppgtt_init(struct drm_device *dev, struct i915_hw_ppgtt *ppgtt)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
#define GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
#define GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))
+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
/* WaClearTdlStateAckDirtyBits */
#define GEN8_STATE_ACK _MMIO(0x20F0)
#define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 09/11] drm/i915: Check pixel rate for DP to VGA dongle
On Mon, Jun 06, 2016 at 04:29:11PM +0300, Mika Kahola wrote:
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
>
> The register defines the pixel rate divided by 8 in MP/s.
>
> v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> function (Daniel)
> v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_dp.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 096acbf0..1b94347 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -200,6 +200,23 @@ intel_dp_mode_valid(struct drm_connector *connector,
> int target_clock = mode->clock;
> int max_rate, mode_rate, max_lanes, max_link_clock;
> int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> + bool is_branch_device;
> + int max_dp_clk;
> + int type;
> + uint8_t port_cap[4];
> +
> + is_branch_device = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> + DP_DWN_STRM_PORT_PRESENT;
> +
> + if (is_branch_device) {
> + drm_dp_downstream_port_cap(&intel_dp->aux, intel_dp->dpcd,
> port_cap);
I'm pretty sure we already read out the downstream port caps in fact.
Hmm, yeah ->downstream_ports. So no need for this, and I suppose no need
for your helper for the readout either. Just always readoing out the
full 16 bytes should be fine.
> + type = drm_dp_downstream_type(intel_dp->dpcd, port_cap);
> + max_dp_clk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> port_cap);
> +
> + if ((type == DP_DS_PORT_TYPE_VGA) && (max_dp_clk > 0)) {
Type check can be skipped if drm_dp_downstream_max_clock() just returns
0 for the "don't know" case.
> + max_dotclk = min(max_dotclk, max_dp_clk);
> + }
> + }
>
> if (is_edp(intel_dp) && fixed_mode) {
> if (mode->hdisplay > fixed_mode->hdisplay)
> --
> 1.9.1
--
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] [PATCH v4 05/11] drm: Helper to read max bits per component
On Mon, Jun 06, 2016 at 04:29:07PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported bits per
> component for DisplayPort legay converters.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 31 +++
> include/drm/drm_dp_helper.h | 2 ++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 18b72eb..bac0ccc 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -507,6 +507,37 @@ int drm_dp_downstream_max_clock(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_downstream_max_clock);
>
> +/**
> + * drm_dp_downstream_max_bpc() - extract branch device max
> + * bits per component
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns max bpc on success or negative error code on failure
> + */
> +int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> + const u8 port_cap[4])
> +{
> + int type = drm_dp_downstream_type(dpcd, port_cap);
> + bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> + DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + if (detailed_cap_info) {
Early return again.
> + if (type != DP_DS_PORT_TYPE_WIRELESS) {
switch() again.
> + int tmp;
> + tmp = port_cap[2] & DP_DS_VGA_MAX_BPC_MASK;
Should drop the "VGA" from that stuff since it applies to more than
that.
> +
> + if (tmp == 0)
> + return 8;
> + else
> + return 8 + (1< + }
> + }
> +
> + return -EINVAL;
Again I think I'd just use 0 here.
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> +
> /*
> * I2C-over-AUX implementation
> */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c3324d3..d4abc38 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -812,6 +812,8 @@ int drm_dp_downstream_port_cap(struct drm_dp_aux *aux,
> int drm_dp_downstream_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE], const u8
> port_cap[4]);
> int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> const u8 port_cap[4]);
> +int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> + const u8 port_cap[4]);
>
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> --
> 1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Ro.CI.BAT: warning for Introduce the implementation of GVT context (rev7)
== Series Details == Series: Introduce the implementation of GVT context (rev7) URL : https://patchwork.freedesktop.org/series/7208/ State : warning == Summary == Series 7208v7 Introduce the implementation of GVT context http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/7/mbox Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: skip -> DMESG-WARN (ro-bdw-i7-5557U) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> SKIP (ro-bdw-i7-5557U) fi-bdw-i7-5557u total:209 pass:197 dwarn:0 dfail:0 fail:0 skip:12 fi-skl-i5-6260u total:209 pass:198 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-i7-6700k total:209 pass:184 dwarn:0 dfail:0 fail:0 skip:25 fi-snb-i7-2600 total:209 pass:170 dwarn:0 dfail:0 fail:0 skip:39 ro-bdw-i7-5557U total:209 pass:193 dwarn:2 dfail:0 fail:0 skip:14 ro-bdw-i7-5600u total:209 pass:180 dwarn:0 dfail:0 fail:1 skip:28 ro-bsw-n3050 total:209 pass:168 dwarn:0 dfail:0 fail:2 skip:39 ro-byt-n2820 total:209 pass:169 dwarn:0 dfail:0 fail:3 skip:37 ro-hsw-i3-4010u total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-hsw-i7-4770r total:209 pass:186 dwarn:0 dfail:0 fail:0 skip:23 ro-ilk1-i5-650 total:204 pass:146 dwarn:0 dfail:0 fail:1 skip:57 ro-ivb-i7-3770 total:209 pass:177 dwarn:0 dfail:0 fail:0 skip:32 ro-ivb2-i7-3770 total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:28 ro-snb-i7-2620M total:209 pass:170 dwarn:0 dfail:0 fail:1 skip:38 fi-hsw-i7-4770k failed to connect after reboot ro-bdw-i5-5250u failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_1145/ d54fc9b drm-intel-nightly: 2016y-06m-09d-06h-54m-13s UTC integration manifest e416bdc drm/i915: Introduce GVT context creation API 28601f2 drm/i915: Support LRC context single submission 63a1554 drm/i915: Introduce execlist context status change notification f884812 drm/i915: Make addressing mode bits in context descriptor configurable 0cfb715 drm/i915: Make ring buffer size of a LRC context configurable 7ca788b drm/i915: Introduce host graphics memory partition for GVT-g 03fb327 drm/i915: gvt: Introduce the basic architecture of GVT-g e4d90fd drm/i915: Fold vGPU active check into inner functions db4e422 drm/i915: Use offsetof() to calculate the offset of members in PVINFO page 69cfc5a drm/i915: Factor out i915_pvinfo.h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 04/11] drm: Helper to read max clock rate
On Mon, Jun 06, 2016 at 04:29:06PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported pixel rate
> for DisplayPort legay VGA converter or TMDS clock rate
> for other digital legacy converters. The helper returns
> clock rate in kHz.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 28
> include/drm/drm_dp_helper.h | 2 ++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 7d3b245..18b72eb 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -479,6 +479,34 @@ int drm_dp_downstream_type(const u8
> dpcd[DP_RECEIVER_CAP_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_downstream_type);
>
> +/**
> + * drm_dp_downstream_max_clock() - extract branch device max
> + * pixel rate for legacy VGA
> + * converter or max TMDS clock
> + * rate for others
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns max clock in kHz on success or negative error code on failure
> + */
> +int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> + const u8 port_cap[4])
> +{
> + int type = drm_dp_downstream_type(dpcd, port_cap);
> + bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> + DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + if (detailed_cap_info) {
Could swap this over to an early return and then we don't have to indent
the actual meat of the function.
> + if (type == DP_DS_PORT_TYPE_VGA)
> + return port_cap[1] * 8 * 1000;
> + else if (type != DP_DS_PORT_TYPE_WIRELESS)
> + return port_cap[1] * 2500;
That's not correct. I suggest a switch() and deal with each type
explicitly.
> + }
> +
> + return -EINVAL;
I think I'd return 0 for the "we don't know" case. That way we can use
this directly without worrying about negative values.
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_max_clock);
> +
> /*
> * I2C-over-AUX implementation
> */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index f290829..c3324d3 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -810,6 +810,8 @@ int drm_dp_downstream_port_cap(struct drm_dp_aux *aux,
> const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> u8 port_cap[4]);
> int drm_dp_downstream_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE], const u8
> port_cap[4]);
> +int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4]);
>
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> --
> 1.9.1
--
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] [PATCH v4 03/11] drm: Helper to read DP branch device type
On Mon, Jun 06, 2016 at 04:29:05PM +0300, Mika Kahola wrote:
> Helper routine to read out DisplayPort branch device type. The spec
> defines these type as following
>
> 0 DisplayPort
> 1 Analog VGA
> 2 DVI
> 3 HDMI
> 4 Others without EDID support
> 5 DP++
> 6 Wireless
> 7 Reserved
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 14 ++
> include/drm/drm_dp_helper.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index c4149fd..7d3b245 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -465,6 +465,20 @@ int drm_dp_downstream_port_cap(struct drm_dp_aux *aux,
> }
> EXPORT_SYMBOL(drm_dp_downstream_port_cap);
>
> +/**
> + * drm_dp_downstream_type() - extract downstream port type
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * Returns type in success or negative error code on failure
> + */
> +int drm_dp_downstream_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +const u8 port_cap[4])
> +{
> + return port_cap[0] & DP_DS_PORT_TYPE_MASK;
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_type);
Seems rather pointless to me.
> +
> /*
> * I2C-over-AUX implementation
> */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index db8d3d47..f290829 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -809,6 +809,7 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
> drm_dp_link *link);
> int drm_dp_downstream_port_cap(struct drm_dp_aux *aux,
> const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> u8 port_cap[4]);
> +int drm_dp_downstream_type(const u8 dpcd[DP_RECEIVER_CAP_SIZE], const u8
> port_cap[4]);
>
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> --
> 1.9.1
--
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] [PATCH v4 02/11] drm: Read DP downstream port capabilities
On Mon, Jun 06, 2016 at 04:29:04PM +0300, Mika Kahola wrote:
> Read DisplayPort downstream port capabilities. Depending on
> the DP port the capabilities are defined in length of 1 byte
> or 4 bytes depending if the detailed capability information is
> available.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 27 +++
> include/drm/drm_dp_helper.h | 3 +++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index eeaf5a7..c4149fd 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -438,6 +438,33 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
> drm_dp_link *link)
> }
> EXPORT_SYMBOL(drm_dp_link_configure);
>
> +/**
> + * drm_dp_downstream_port_cap() - read downstream port capabilities
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + *
> + * returns size of the port capabilites
> + */
> +int drm_dp_downstream_port_cap(struct drm_dp_aux *aux,
> +const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +u8 port_cap[4])
> +{
> + int size;
> + bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> + DP_DETAILED_CAP_INFO_AVAILABLE;
> +
> + if (detailed_cap_info) {
> + size = 4;
> + drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, port_cap, size);
> + } else {
> + size = 1;
> + drm_dp_dpcd_read(aux, DP_DOWNSTREAM_PORT_0, &port_cap[0], size);
> + }
Could avoid a bit of duplicatetion. Eg.:
if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
size = 4;
else
size = 1;
return drm_dp_dpcd_read(...);
Though perhaps we should just read out the entire 4/16 bytes to get the
caps for all the ports?
> +
> + return size;
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_port_cap);
> +
> /*
> * I2C-over-AUX implementation
> */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index e384c7f..db8d3d47 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -806,6 +806,9 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
> drm_dp_link *link);
> int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
> int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
> +int drm_dp_downstream_port_cap(struct drm_dp_aux *aux,
> +const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +u8 port_cap[4]);
>
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister(struct drm_dp_aux *aux);
> --
> 1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 01/10] drm/i915: Factor out i915_pvinfo.h
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.
v7:
- Split the "offsetof" modification into a dedicated patch. (Joonas)
v3:
- Use offsetof to calculate the member offset of PVINFO structure (Joonas)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_pvinfo.h | 113 +
drivers/gpu/drm/i915/i915_vgpu.h | 86 +---
2 files changed, 114 insertions(+), 85 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_pvinfo.h
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
new file mode 100644
index 000..68bdf60
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -0,0 +1,113 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+#ifndef _I915_PVINFO_H_
+#define _I915_PVINFO_H_
+
+/* The MMIO offset of the shared info between guest and host emulator */
+#define VGT_PVINFO_PAGE0x78000
+#define VGT_PVINFO_SIZE0x1000
+
+/*
+ * The following structure pages are defined in GEN MMIO space
+ * for virtualization. (One page for now)
+ */
+#define VGT_MAGIC 0x4776544776544776ULL/* 'vGTvGTvG' */
+#define VGT_VERSION_MAJOR 1
+#define VGT_VERSION_MINOR 0
+
+#define INTEL_VGT_IF_VERSION_ENCODE(major, minor) ((major) << 16 | (minor))
+#define INTEL_VGT_IF_VERSION \
+ INTEL_VGT_IF_VERSION_ENCODE(VGT_VERSION_MAJOR, VGT_VERSION_MINOR)
+
+/*
+ * notifications from guest to vgpu device model
+ */
+enum vgt_g2v_type {
+ VGT_G2V_PPGTT_L3_PAGE_TABLE_CREATE = 2,
+ VGT_G2V_PPGTT_L3_PAGE_TABLE_DESTROY,
+ VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE,
+ VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,
+ VGT_G2V_EXECLIST_CONTEXT_CREATE,
+ VGT_G2V_EXECLIST_CONTEXT_DESTROY,
+ VGT_G2V_MAX,
+};
+
+struct vgt_if {
+ uint64_t magic; /* VGT_MAGIC */
+ uint16_t version_major;
+ uint16_t version_minor;
+ uint32_t vgt_id;/* ID of vGT instance */
+ uint32_t rsv1[12]; /* pad to offset 0x40 */
+ /*
+* Data structure to describe the balooning info of resources.
+* Each VM can only have one portion of continuous area for now.
+* (May support scattered resource in future)
+* (starting from offset 0x40)
+*/
+ struct {
+ /* Aperture register balooning */
+ struct {
+ uint32_t base;
+ uint32_t size;
+ } mappable_gmadr; /* aperture */
+ /* GMADR register balooning */
+ struct {
+ uint32_t base;
+ uint32_t size;
+ } nonmappable_gmadr;/* non aperture */
+ /* allowed fence registers */
+ uint32_t fence_num;
+ uint32_t rsv2[3];
+ } avail_rs; /* available/assigned resource */
+ uint32_t rsv3[0x200 - 24]; /* pad to half page */
+ /*
+* The bottom half page is for response from Gfx driver to hypervisor.
+*/
+ uint32_t rsv4;
+ uint32_t display_ready; /* ready for display owner switch */
+
+ uint32_t rsv5[4];
+
+ uint32_t g2v_notify;
+ uint32_t rsv6[7];
+
+ struct {
+ uint32_t lo;
+ uint32_t hi;
+ } pdp[4];
+
+ uint32_t execlist_context_descriptor_lo;
+ uint32_t execlist_context_descriptor_hi;
+
+ uint32_t rsv7[0x200 - 24];/* pad to one page */
+} __packed;
+
+#define vgtif_reg(x) \
+ _MMIO((VGT_PVINFO_PAGE + (long)&((struct vgt_if *)NULL)->x))
+
+/* vGPU display status to be used by the host side */
+#define VGT_DRV_DISPLAY_NOT_READY 0
+#de
[Intel-gfx] [PATCH v9 08/10] drm/i915: Introduce execlist context status change notification
This patch introduces an approach to track the execlist context status
change.
GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.
This function is configurable when creating a new GEM context. Currently,
Only GVT-g will create the "status-change-notification" enabled GEM
context.
v8:
- Remove the boolean flag in struct i915_gem_context. (Joonas)
v7:
- Remove per-engine ctx status notifiers. Use one status notifier for all
engines. (Joonas)
- Add prefix "INTEL_" for related definitions. (Joonas)
- Refine the comments in execlists_context_status_change(). (Joonas)
v6:
- When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler
could automatically eliminate them for us. (Chris)
- Always initialize the notifier header, so it could be switched on/off
at runtime. (Chris)
v5:
- Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 22 ++
drivers/gpu/drm/i915/intel_lrc.h| 5 +
4 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9e22200..c14eb56 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -880,6 +880,7 @@ struct i915_gem_context {
} engine[I915_NUM_ENGINES];
u32 ring_size;
u32 desc_template;
+ struct atomic_notifier_head status_notifier;
struct list_head link;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index e636d85..3c1b83e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -298,6 +298,7 @@ __create_hw_context(struct drm_device *dev,
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
+ ATOMIC_INIT_NOTIFIER_HEAD(&ctx->status_notifier);
return ctx;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2116f86..7f42b15 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -404,6 +404,20 @@ static void execlists_submit_requests(struct
drm_i915_gem_request *rq0,
spin_unlock_irq(&dev_priv->uncore.lock);
}
+static inline void execlists_context_status_change(
+ struct drm_i915_gem_request *rq,
+ unsigned long status)
+{
+ /*
+* Only used when GVT-g is enabled now. When GVT-g is disabled,
+* The compiler should eliminate this function as dead-code.
+*/
+ if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
+ return;
+
+ atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq);
+}
+
static void execlists_context_unqueue(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
@@ -439,6 +453,12 @@ static void execlists_context_unqueue(struct
intel_engine_cs *engine)
if (unlikely(!req0))
return;
+ execlists_context_status_change(req0, INTEL_CONTEXT_SCHEDULE_IN);
+
+ if (req1)
+ execlists_context_status_change(req1,
+ INTEL_CONTEXT_SCHEDULE_IN);
+
if (req0->elsp_submitted & engine->idle_lite_restore_wa) {
/*
* WaIdleLiteRestore: make sure we never cause a lite restore
@@ -477,6 +497,8 @@ execlists_check_remove_request(struct intel_engine_cs
*engine, u32 ctx_id)
if (--head_req->elsp_submitted > 0)
return 0;
+ execlists_context_status_change(head_req, INTEL_CONTEXT_SCHEDULE_OUT);
+
list_del(&head_req->execlist_link);
i915_gem_request_unreference(head_req);
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index a8db42a..2b8255c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -57,6 +57,11 @@
#define GEN8_CSB_READ_PTR(csb_status) \
(((csb_status) & GEN8_CSB_READ_PTR_MASK) >> 8)
+enum {
+ INTEL_CONTEXT_SCHEDULE_IN = 0,
+ INTEL_CONTEXT_SCHEDULE_OUT,
+};
+
/* Logical Rings */
int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request);
int intel_logical_ring_reserve_space(struct drm_i915_gem_request *request);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 07/10] drm/i915: Make addressing mode bits in context descriptor configurable
Currently the addressing mode bit in context descriptor is statically
generated from the configuration of system-wide PPGTT usage model.
GVT-g will load the PPGTT shadow page table by itself and probably one
guest is using a different addressing mode with i915 host. The addressing
mode bits of a LRC context should be configurable under this case.
v9:
- Rename the data member in struct i915_gem_context. (Chris)
v8:
- Rename the data member in struct i915_gem_context. (Chris)
v7:
- Move context addressing mode bit into i915_reg.h. (Joonas/Chris)
- Add prefix "INTEL_" for related definitions. (Joonas)
v6:
- Directly save the addressing mode bits inside i915_gem_context. (Chris)
- Move the LRC context addressing mode bits into intel_lrc.h. (Chris)
v5:
- Change USES_FULL_48BIT(dev) to USES_FULL_48BIT(dev_priv) (Tvrtko)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 12
drivers/gpu/drm/i915/intel_lrc.c| 15 ++-
4 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c3b4009..a9e22200 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,7 @@ struct i915_gem_context {
bool initialised;
} engine[I915_NUM_ENGINES];
u32 ring_size;
+ u32 desc_template;
struct list_head link;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b722fa1..e636d85 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -296,6 +296,8 @@ __create_hw_context(struct drm_device *dev,
ctx->hang_stats.ban_period_seconds = DRM_I915_CTX_BAN_PERIOD;
ctx->ring_size = 4 * PAGE_SIZE;
+ ctx->desc_template = GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
+ GEN8_CTX_ADDRESSING_MODE_SHIFT;
return ctx;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..cf37bd7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3033,6 +3033,18 @@ enum skl_disp_power_wells {
/* Same as Haswell, but 72064 bytes now. */
#define GEN8_CXT_TOTAL_SIZE(18 * PAGE_SIZE)
+enum {
+ INTEL_ADVANCED_CONTEXT = 0,
+ INTEL_LEGACY_32B_CONTEXT,
+ INTEL_ADVANCED_AD_CONTEXT,
+ INTEL_LEGACY_64B_CONTEXT
+};
+
+#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
+#define GEN8_CTX_ADDRESSING_MODE(dev_priv) (USES_FULL_48BIT_PPGTT(dev_priv) ?\
+ INTEL_LEGACY_64B_CONTEXT : \
+ INTEL_LEGACY_32B_CONTEXT)
+
#define CHV_CLK_CTL1 _MMIO(0x101100)
#define VLV_CLK_CTL2 _MMIO(0x101104)
#define CLK_CTL2_CZCOUNT_30NS_SHIFT 28
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 177b61d..2116f86 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -208,16 +208,6 @@
} while (0)
enum {
- ADVANCED_CONTEXT = 0,
- LEGACY_32B_CONTEXT,
- ADVANCED_AD_CONTEXT,
- LEGACY_64B_CONTEXT
-};
-#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
-#define GEN8_CTX_ADDRESSING_MODE(dev) (USES_FULL_48BIT_PPGTT(dev) ?\
- LEGACY_64B_CONTEXT :\
- LEGACY_32B_CONTEXT)
-enum {
FAULT_AND_HANG = 0,
FAULT_AND_HALT, /* Debug only */
FAULT_AND_STREAM,
@@ -281,8 +271,6 @@ logical_ring_init_platform_invariants(struct
intel_engine_cs *engine)
(engine->id == VCS || engine->id ==
VCS2);
engine->ctx_desc_template = GEN8_CTX_VALID;
- engine->ctx_desc_template |= GEN8_CTX_ADDRESSING_MODE(dev_priv) <<
- GEN8_CTX_ADDRESSING_MODE_SHIFT;
if (IS_GEN8(dev_priv))
engine->ctx_desc_template |= GEN8_CTX_L3LLC_COHERENT;
engine->ctx_desc_template |= GEN8_CTX_PRIVILEGE;
@@ -325,7 +313,8 @@ intel_lr_context_descriptor_update(struct i915_gem_context
*ctx,
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > (1desc_template; /* bits 3-4 */
+ desc |= engine->ctx_desc_template; /* bits 0-11 */
desc |= ce->lrc_vma->node.start + LRC_PPHWSP_PN * PAGE_SIZE;
/* bits 12-31 */
desc |= (u64)ctx->hw_id << GEN8_CTX_ID_SHIFT; /* bits 32-52 */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 05/10] drm/i915: Introduce host graphics memory partition for GVT-g
From: Bing Niu
This patch introduces host graphics memory partition when GVT-g
is enabled.
Under GVT-g, i915 host driver only owned limited graphics resources,
others are managed by GVT-g resource allocator and kept for other vGPUs.
v7:
- Add comments about low/high GM size for host. (Joonas)
v6:
- Remove kernel parameters used to configure GGTT owned by host. (Chris)
- Other coding style comments from Chris.
- Add more comments for reviewer.
v3:
- Remove fence partition, will use i915 fence stealing in future.(Kevin)
- Santinize GVT host gm kernel parameters. (Joonas)
v2:
- Address all coding-style comments from Joonas previously.
- Fix errors and warnning reported by checkpatch.pl. (Joonas)
- Move the graphs into the header files. (Daniel)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Kevin Tian
Cc: Daniel Vetter
Signed-off-by: Bing Niu
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_vgpu.c | 23 +--
drivers/gpu/drm/i915/intel_gvt.h | 36
2 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index f6acb5a..019db98 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -189,14 +189,25 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
unsigned long unmappable_base, unmappable_size, unmappable_end;
int ret;
- if (!intel_vgpu_active(dev_priv))
+ if (intel_gvt_active(dev_priv)) {
+ /* Retrieve GGTT partition information from macros */
+ mappable_base = 0;
+ mappable_size = INTEL_GVT_HOST_LOW_GM_SIZE;
+ unmappable_base = dev_priv->ggtt.mappable_end;
+ unmappable_size = INTEL_GVT_HOST_HIGH_GM_SIZE;
+ } else if (intel_vgpu_active(dev_priv)) {
+ /* Retrieve GGTT partition information from PVINFO */
+ mappable_base = I915_READ(
+ vgtif_reg(avail_rs.mappable_gmadr.base));
+ mappable_size = I915_READ(
+ vgtif_reg(avail_rs.mappable_gmadr.size));
+ unmappable_base = I915_READ(
+ vgtif_reg(avail_rs.nonmappable_gmadr.base));
+ unmappable_size = I915_READ(
+ vgtif_reg(avail_rs.nonmappable_gmadr.size));
+ } else
return 0;
- mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
- mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
- unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
- unmappable_size = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.size));
-
mappable_end = mappable_base + mappable_size;
unmappable_end = unmappable_base + unmappable_size;
diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h
index 91e129f..d0d71d1 100644
--- a/drivers/gpu/drm/i915/intel_gvt.h
+++ b/drivers/gpu/drm/i915/intel_gvt.h
@@ -26,6 +26,42 @@
#include "gvt/gvt.h"
+/*
+ * Under GVT-g, i915 host driver only owned limited graphics resources,
+ * others are managed by GVT-g resource allocator and kept for other vGPUs.
+ *
+ * For graphics memory space partition, a typical layout looks like:
+ *
+ * +---+---+--+---+
+ * |* Host | *GVT-g Resource |* Host| *GVT-g Resource |
+ * | Owned | Allocator Managed | Owned| Allocator Managed |
+ * | | | | |
+ * +---+---+--+---+---+
+ * | | | | | | | | |
+ * | i915 | vm 1 | vm 2 | vm 3 | i915 | vm 1 | vm 2 | vm 3 |
+ * | | | | | | | | |
+ * +---+---+---+--+---+---+---+
+ * | Aperture|Hidden|
+ * +---+--+
+ * | GGTT memory space |
+ * +--+
+ */
+
+/* GGTT memory space owned by host */
+/*
+ * This amount is heavily related to the max screen resolution / multiple
+ * display in *host*. If you are using a 4K monitor or multiple display
+ * monitor, probably you should enlarge the low gm size.
+ */
+#define INTEL_GVT_HOST_LOW_GM_SIZE (96 * 1024 * 1024)
+
+/*
+ * This amount is related to the GPU workload in host. If you wish to run
+ * heavy workload like 3D gaming, media transcoding *in host* and encounter
+ * performance drops, probably you should enlarge the high gm size.
+ */
+#define INTEL_GVT_HOST_HIGH_GM_SIZE (384 * 1024 * 1024)
+
#ifdef CONFIG_DRM_I915_GVT
extern int intel_gvt_init(struct drm_i915_private *dev_priv);
extern void intel_
[Intel-gfx] [PATCH v9 04/10] drm/i915: gvt: Introduce the basic architecture of GVT-g
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
v7:
- Refine the URL link in Kconfig. (Joonas)
- Refine the introduction of GVT-g host support in Kconfig. (Joonas)
- Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas)
- Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas)
- Remove {alloc, free}_gvt_device()
- Rename intel_gvt_{create, destroy}_gvt_device()
- Expost intel_gvt_init_host()
- Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas)
v6:
- Refine introduction in Kconfig. (Chris)
- The exposed API functions will take struct intel_gvt * instead of
void *. (Chris/Tvrtko)
- Remove most memebers of strct intel_gvt_device_info. Will add them
in the device model patches.(Chris)
- Remove gvt_info() and gvt_err() in debug.h. (Chris)
- Move GVT kernel parameter into i915_params. (Chris)
- Remove include/drm/i915_gvt.h, as GVT-g will be built within i915.
- Remove the redundant struct i915_gvt *, as the functions in i915
will directly take struct intel_gvt *.
- Add more comments for reviewer.
v5:
Take Tvrtko's comments:
- Fix the misspelled words in Kconfig
- Let functions take drm_i915_private * instead of struct drm_device *
- Remove redundant prints/local varible initialization
v3:
Take Joonas' comments:
- Change file name i915_gvt.* to intel_gvt.*
- Move GVT kernel parameter into intel_gvt.c
- Remove redundant debug macros
- Change error handling style
- Add introductions for some stub functions
- Introduce drm/i915_gvt.h.
Take Kevin's comments:
- Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c
v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled, the
stubs here do nothing.
Take Joonas' comments:
- Replace boolean return value with int.
- Replace customized info/warn/debug macros with DRM macros.
- Document all non-static functions like i915.
- Remove empty and unused functions.
- Replace magic number with marcos.
- Set GVT-g in kernel config to "n" by default.
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Kevin Tian
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/Kconfig | 22 ++
drivers/gpu/drm/i915/Makefile| 5 ++
drivers/gpu/drm/i915/gvt/Makefile| 5 ++
drivers/gpu/drm/i915/gvt/debug.h | 34
drivers/gpu/drm/i915/gvt/gvt.c | 145 +++
drivers/gpu/drm/i915/gvt/gvt.h | 69 +
drivers/gpu/drm/i915/gvt/hypercall.h | 38 +
drivers/gpu/drm/i915/gvt/mpt.h | 49
drivers/gpu/drm/i915/i915_dma.c | 16 +++-
drivers/gpu/drm/i915/i915_drv.h | 10 +++
drivers/gpu/drm/i915/i915_params.c | 5 ++
drivers/gpu/drm/i915/i915_params.h | 1 +
drivers/gpu/drm/i915/intel_gvt.c | 100
drivers/gpu/drm/i915/intel_gvt.h | 45 +++
14 files changed, 540 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
create mode 100644 drivers/gpu/drm/i915/intel_gvt.c
create mode 100644 drivers/gpu/drm/i915/intel_gvt.h
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 29a32b1..7769e46 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -57,6 +57,28 @@ config DRM_I915_USERPTR
If in doubt, say "Y".
+config DRM_I915_GVT
+bool "Enable Intel GVT-g graphics virtualization host support"
+depends on DRM_I915
+default n
+help
+ Choose this option if you want to enable Intel GVT-g graphics
+ virtualization technology host support with integrated graphics.
+ With GVT-g, it's possible to have one integrated graphics
+ device shared by multiple VMs under different hypervisors.
+
+ Note that at least one hypervisor like Xen or KVM is required for
+ this driver to work, and it only supports newer device from
+ Broadwell+. For further information and setup guide, you can
+ visit: http://01.org/igvt-g.
+
+ Now it's just a stub to support the modifications of i915 for
+ GVT device model. It requires at least one MPT modules for Xen/KVM
+ and other components of GVT device model to work. Use it under
+ you own risk.
+
+ If in doubt, say "N".
+
menu "drm/i915 Debugging"
depends on DRM_I915
depends on EXPERT
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i9
[Intel-gfx] [PATCH v9 03/10] drm/i915: Fold vGPU active check into inner functions
v5:
- Let functions take struct drm_i915_private *. (Tvrtko)
- Fold vGPU related active check into the inner functions. (Kevin)
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Suggested-by: Kevin Tian
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Kevin Tian
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ---
drivers/gpu/drm/i915/i915_vgpu.c| 13 +
drivers/gpu/drm/i915/i915_vgpu.h| 4 ++--
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4668477..6f203fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2732,11 +2732,9 @@ static int i915_gem_setup_global_gtt(struct drm_device
*dev,
i915_address_space_init(&ggtt->base, dev_priv);
ggtt->base.total += PAGE_SIZE;
- if (intel_vgpu_active(dev_priv)) {
- ret = intel_vgt_balloon(dev);
- if (ret)
- return ret;
- }
+ ret = intel_vgt_balloon(dev_priv);
+ if (ret)
+ return ret;
if (!HAS_LLC(dev))
ggtt->base.mm.color_adjust = i915_gtt_color_adjust;
@@ -2836,8 +2834,7 @@ void i915_ggtt_cleanup_hw(struct drm_device *dev)
i915_gem_cleanup_stolen(dev);
if (drm_mm_initialized(&ggtt->base.mm)) {
- if (intel_vgpu_active(dev_priv))
- intel_vgt_deballoon();
+ intel_vgt_deballoon(dev_priv);
drm_mm_takedown(&ggtt->base.mm);
list_del(&ggtt->base.global_link);
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index c3c6c64..f6acb5a 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -101,10 +101,13 @@ static struct _balloon_info_ bl_info;
* This function is called to deallocate the ballooned-out graphic memory, when
* driver is unloaded or when ballooning fails.
*/
-void intel_vgt_deballoon(void)
+void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
{
int i;
+ if (!intel_vgpu_active(dev_priv))
+ return;
+
DRM_DEBUG("VGT deballoon.\n");
for (i = 0; i < 4; i++) {
@@ -177,9 +180,8 @@ static int vgt_balloon_space(struct drm_mm *mm,
* Returns:
* zero on success, non-zero if configuration invalid or ballooning failed
*/
-int intel_vgt_balloon(struct drm_device *dev)
+int intel_vgt_balloon(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct i915_ggtt *ggtt = &dev_priv->ggtt;
unsigned long ggtt_end = ggtt->base.start + ggtt->base.total;
@@ -187,6 +189,9 @@ int intel_vgt_balloon(struct drm_device *dev)
unsigned long unmappable_base, unmappable_size, unmappable_end;
int ret;
+ if (!intel_vgpu_active(dev_priv))
+ return 0;
+
mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
@@ -258,6 +263,6 @@ int intel_vgt_balloon(struct drm_device *dev)
err:
DRM_ERROR("VGT balloon fail\n");
- intel_vgt_deballoon();
+ intel_vgt_deballoon(dev_priv);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_vgpu.h b/drivers/gpu/drm/i915/i915_vgpu.h
index 07e67d5..f8917c6 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.h
+++ b/drivers/gpu/drm/i915/i915_vgpu.h
@@ -27,7 +27,7 @@
#include "i915_pvinfo.h"
extern void i915_check_vgpu(struct drm_i915_private *dev_priv);
-extern int intel_vgt_balloon(struct drm_device *dev);
-extern void intel_vgt_deballoon(void);
+extern int intel_vgt_balloon(struct drm_i915_private *dev_priv);
+extern void intel_vgt_deballoon(struct drm_i915_private *dev_priv);
#endif /* _I915_VGPU_H_ */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 09/10] drm/i915: Support LRC context single submission
This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.
Only GVT-g will create this kinds of GEM context currently.
v8:
- Rename the data member in struct i915_gem_context. (Chris)
v7:
- Fix typos in commit message. (Joonas)
v6:
- Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris)
v5:
- Only compile this feature when CONFIG_DRM_I915_GVT=y. (Tvrtko)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c14eb56..3026489 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -881,6 +881,7 @@ struct i915_gem_context {
u32 ring_size;
u32 desc_template;
struct atomic_notifier_head status_notifier;
+ bool execlists_force_single_submission;
struct list_head link;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7f42b15..a20d927 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -444,6 +444,21 @@ static void execlists_context_unqueue(struct
intel_engine_cs *engine)
i915_gem_request_unreference(req0);
req0 = cursor;
} else {
+ /* Compiler will do the dead-code elimination */
+ if (IS_ENABLED(CONFIG_DRM_I915_GVT)) {
+ /*
+* req0 (after merged) ctx requires single
+* submission, stop picking
+*/
+ if
(req0->ctx->execlists_force_single_submission)
+ break;
+ /*
+* req0 ctx doesn't require single submission,
+* but next req ctx requires, stop picking
+*/
+ if
(cursor->ctx->execlists_force_single_submission)
+ break;
+ }
req1 = cursor;
WARN_ON(req1->elsp_submitted);
break;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
