[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dsi: improved gpio element support for vlv/chv/bxt (rev2)
== Series Details == Series: drm/i915/dsi: improved gpio element support for vlv/chv/bxt (rev2) URL : https://patchwork.freedesktop.org/series/4625/ State : failure == Summary == Series 4625v2 drm/i915/dsi: improved gpio element support for vlv/chv/bxt http://patchwork.freedesktop.org/api/1.0/series/4625/revisions/2/mbox/ Test gem_exec_whisper: Subgroup basic: pass -> DMESG-FAIL (bsw-nuc-2) Test gem_sync: Subgroup basic-all: dmesg-fail -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (bsw-nuc-2) dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Test kms_force_connector_basic: Subgroup prune-stale-modes: skip -> PASS (ivb-t430s) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:155 dwarn:3 dfail:1 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1809/ 12899f13b8ee9a4944f167a08e4db0526a3f3855 drm-intel-nightly: 2016y-04m-05d-19h-09m-25s UTC integration manifest 000b41e33a0f329c23cb7543e5a8b93301f0b8fd drm/i915/bxt: add bxt dsi gpio element support ab02443f11a74ea5f61f0a98915324d71d86c013 drm/i915/dsi: add support for gpio elements on CHV 80894abb0bcd98551d93a7e747f0b025329c1103 drm/i915/dsi: add support for sequence block v3 gpio for VLV cbff872b8dc0f99bd05763ed3b7f3693f4f0470d drm/i915/dsi: use a temp variable for referencing the gpio table 637fef0ccf65d7fb3a70b9c46e8044e868e275b6 drm/i915/dsi: abstract VLV gpio element execution to a separate function 5c33abcd97bd2185e1b9e3f49411fdda93562456 drm/i915/dsi: clean up vlv gpio table and definitions ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Minor i915_dp_mst_info output enhancements
== Series Details == Series: Minor i915_dp_mst_info output enhancements URL : https://patchwork.freedesktop.org/series/5346/ State : failure == Summary == Series 5346v1 Minor i915_dp_mst_info output enhancements http://patchwork.freedesktop.org/api/1.0/series/5346/revisions/1/mbox/ Test gem_exec_whisper: Subgroup basic: pass -> DMESG-FAIL (bsw-nuc-2) Test gem_sync: Subgroup basic-all: dmesg-fail -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Test kms_force_connector_basic: Subgroup prune-stale-modes: skip -> PASS (ivb-t430s) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:157 dwarn:1 dfail:1 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1810/ 12899f13b8ee9a4944f167a08e4db0526a3f3855 drm-intel-nightly: 2016y-04m-05d-19h-09m-25s UTC integration manifest a5435ff1460a2481b2823c0100e3e000586cfec7 drm/i915/dp/mst: Add source port info to debugfs output 6fb45c2516d4b14be82a00421e2b37c2061f0ee0 drm/dp/mst: Enhance DP MST debugfs output d632f7a2a3e20fc4751cb245ea934ba40e8ddbb1 drm/edid: Add drm_edid_get_monitor_name() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Set max cdclk frequency properly
== Series Details == Series: drm/i915/bxt: Set max cdclk frequency properly URL : https://patchwork.freedesktop.org/series/5348/ State : failure == Summary == Series 5348v1 drm/i915/bxt: Set max cdclk frequency properly http://patchwork.freedesktop.org/api/1.0/series/5348/revisions/1/mbox/ Test gem_sync: Subgroup basic-all: dmesg-fail -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (bsw-nuc-2) Test kms_force_connector_basic: Subgroup prune-stale-modes: skip -> PASS (ivb-t430s) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:158 dwarn:0 dfail:0 fail:1 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1811/ 12899f13b8ee9a4944f167a08e4db0526a3f3855 drm-intel-nightly: 2016y-04m-05d-19h-09m-25s UTC integration manifest 65c53e538f64d2242ed44e62134c4f73d6737590 drm/i915/bxt: Set max cdclk frequency properly ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: resize the GuC WOPCM for rc6
Ok, The value written to GUC_WOPCM_SIZE is done on i915-gem.c@6474: /* init WOPCM */ if (IS_BROXTON(dev)) I915_WRITE(GUC_WOPCM_SIZE, BXT_GUC_WOPCM_SIZE_VALUE); else I915_WRITE(GUC_WOPCM_SIZE, GUC_WOPCM_SIZE_VALUE); So I think it is correct on BXT. The definition is confusing as the space on BXT is smaller so that the RC6 data can be written to the WOPCM. I don't think there is anything to do. Peter. On Tue, 5 Apr 2016, Rodrigo Vivi wrote: Hi Peter, This patch is required for the BXT firmware loading. (Maybe/Probably something similar for KBL is also required) Do you have plans to fix this interpretation as Dave pointed and send a new version? Thanks, Rodrigo. On Wed, Feb 3, 2016 at 7:39 AM, Dave Gordon wrote: On 21/01/16 21:41, Jeff McGee wrote: On Thu, Jan 21, 2016 at 06:11:01PM +, Peter Antoine wrote: This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory spaces do not overlap. Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter Antoine --- drivers/gpu/drm/i915/i915_guc_reg.h | 3 ++- drivers/gpu/drm/i915/intel_guc_loader.c | 6 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h b/drivers/gpu/drm/i915/i915_guc_reg.h index 685c799..cb938b0 100644 --- a/drivers/gpu/drm/i915/i915_guc_reg.h +++ b/drivers/gpu/drm/i915/i915_guc_reg.h @@ -58,7 +58,8 @@ #define GUC_MAX_IDLE_COUNT_MMIO(0xC3E4) #define GUC_WOPCM_SIZE_MMIO(0xc050) -#define GUC_WOPCM_SIZE_VALUE (0x80 << 12) /* 512KB */ +#define GUC_WOPCM_SIZE_VALUE (0x80 << 12)/* 512KB */ +#define BXT_GUC_WOPCM_SIZE_VALUE (0x70 << 12)/* 448KB */ /* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */ #define GUC_WOPCM_TOP (GUC_WOPCM_SIZE_VALUE) Should GUC_WOPCM_TOP be dynamically assigned the proper value, or is it sufficient to leave at the max possible WOPCM size? If the later, might be worth a comment. -Jeff This isn't the right interpretation of these values. GUC_WOPCM_TOP is the value defining the top of the GTT address range NOT available to the GuC and hence where GuC-accessible objects must NOT be placed. GUC_WOPCM_SIZE_VALUE is the value written to the GUC_WOPCM_SIZE register, defining how much WOPCM space CAN be used. The former is an architectural constant (512K); the latter is a software-defined boundary between areas of memory within that range that are used for different purposes. Therefore, GUC_WOPCM_TOP must NOT be defined in terms of GUC_WOPCM_SIZE_VALUE, but GUC_WOPCM_SIZE_VALUE could be defined in terms of GUC_WOPCM_TOP, in particular as (GUC_WOPCM_TOP-reserved). .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Peter Antoine (Android Graphics Driver Software Engineer) - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/edid: Add drm_edid_get_monitor_name()
On Tue, 05 Apr 2016, Jim Bride wrote:
> In order to include monitor name information in debugfs
> output we needed to add a function that would extract the
> monitor name from the EDID, and that function needed to
> reside in the file where the rest of the EDID helper
> functions are implemented.
>
> cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jim Bride
> ---
> drivers/gpu/drm/drm_edid.c | 28
> include/drm/drm_crtc.h | 1 +
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 558ef9f..fc69a46 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3569,6 +3569,34 @@ struct drm_connector *drm_select_eld(struct
> drm_encoder *encoder)
> EXPORT_SYMBOL(drm_select_eld);
>
> /**
> + * drm_edid_get_monitor_name - fetch the monitor name from the edid
> + * @edid: monitor EDID information
> + * @name: pointer to a character array of at least 13 chars to hold the name
Mixed feelings about "at least 13 chars". It might be simpler for this
one thing, but I hate to see this assumption of "at least 13 chars" get
spread around in patch 2 to where it's no longer obvious where this
requirement comes from.
Seeing that this is mostly copy-paste from drm_edid_to_eld(), I think
this patch should be an abstraction of that code to a separate function.
> + *
> + * Return: True if the name could be extracted, false otherwise
> + */
> +bool drm_edid_get_monitor_name(struct edid *edid, char *name)
> +{
> + char *edid_name = NULL;
> + int mnl;
> +
> + if (!edid || !name)
> + return false;
> +
> + drm_for_each_detailed_block((u8 *)edid, monitor_name, &edid_name);
> + for (mnl = 0; edid_name && mnl < 13; mnl++) {
> + if (edid_name[mnl] == 0x0a) {
> + name[mnl] = '\0';
Depending on edid_name you might not terminate the string. And, in fact,
if you make this an abstraction for drm_edid_to_eld(), you might be
better off *not* terminating, which OTOH is not nice for your other use
in patch 2.
So how about first adding an internal abstraction:
static int get_monitor_name(struct edid *edid, char name[13])
which does *not* terminate the string, and returns length, 0 for
edid_name == NULL. Works nicely for drm_edid_to_eld().
Then you could add the external interface on top of that:
static void drm_edid_get_monitor_name(struct edid *edid, char *buf, int bufsize)
which would always terminate the string (assuming bufsize > 0), even on
errors so you can get rid of the return value. This simplifies your
follow up code, and if we later on need more robust error handling, it's
easy to add the return value.
BR,
Jani.
> + break;
> + }
> + name[mnl] = edid_name[mnl];
> + }
> +
> + return mnl ? true : false;
> +}
> +EXPORT_SYMBOL(drm_edid_get_monitor_name);
> +
> +/**
> * drm_detect_hdmi_monitor - detect whether monitor is HDMI
> * @edid: monitor EDID information
> *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8cb377c..2590168 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2500,6 +2500,7 @@ extern int drm_edid_header_is_valid(const u8 *raw_edid);
> extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> print_bad_edid,
>bool *edid_corrupt);
> extern bool drm_edid_is_valid(struct edid *edid);
> +extern bool drm_edid_get_monitor_name(struct edid *edid, char *name);
>
> extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device
> *dev,
>char topology[8]);
--
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 1/7] drm/i915: Include engine->last_submitted_seqno in GPU error state
On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote:
> It's useful to look at the last seqno submitted on a particular engine
> and compare it against the HWS value to check for irregularities.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 6 --
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 ++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a2e3af02c292..906e5424e488 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1363,8 +1363,10 @@ static int i915_hangcheck_info(struct seq_file *m,
> void *unused)
>
> for_each_engine_id(engine, dev_priv, id) {
> seq_printf(m, "%s:\n", engine->name);
> - seq_printf(m, "\tseqno = %x [current %x]\n",
> - engine->hangcheck.seqno, seqno[id]);
> + seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
> + engine->hangcheck.seqno,
> + seqno[id],
> + engine->last_submitted_seqno);
> seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
> (long long)engine->hangcheck.acthd,
> (long long)acthd[id]);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 313bc3576d87..fad8e0d5a216 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -495,6 +495,7 @@ struct drm_i915_error_state {
> u32 cpu_ring_head;
> u32 cpu_ring_tail;
>
> + u32 last_seqno;
> u32 semaphore_seqno[I915_NUM_ENGINES - 1];
>
> /* Register state */
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 9b55409d91b3..9463cb4e9323 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -296,6 +296,7 @@ static void i915_ring_error_state(struct
> drm_i915_error_state_buf *m,
> }
> }
> err_printf(m, " seqno: 0x%08x\n", ring->seqno);
> + err_printf(m, " last_seqno: 0x%08x\n", ring->last_seqno);
> err_printf(m, " waiting: %s\n", yesno(ring->waiting));
> err_printf(m, " ring->head: 0x%08x\n", ring->cpu_ring_head);
> err_printf(m, " ring->tail: 0x%08x\n", ring->cpu_ring_tail);
> @@ -931,6 +932,7 @@ static void i915_record_ring_state(struct drm_device *dev,
> ering->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
> ering->seqno = engine->get_seqno(engine, false);
> ering->acthd = intel_ring_get_active_head(engine);
> + ering->last_seqno = engine->last_submitted_seqno;
> ering->start = I915_READ_START(engine);
> ering->head = I915_READ_HEAD(engine);
> ering->tail = I915_READ_TAIL(engine);
--
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 1/6] drm/i915/dmabuf: Tighten struct_mutex for unmap_dma_buf
On 05/04/16 13:57, Chris Wilson wrote:
We only need the struct_mutex to manipulate the pages_pin_count on the
object, we do not need to hold our BKL when freeing the exported
scatterlist.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 0506016e18e0..b7d46800c49f 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -95,14 +95,12 @@ static void i915_gem_unmap_dma_buf(struct
dma_buf_attachment *attachment,
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
- mutex_lock(&obj->base.dev->struct_mutex);
-
dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir);
sg_free_table(sg);
kfree(sg);
+ mutex_lock(&obj->base.dev->struct_mutex);
i915_gem_object_unpin_pages(obj);
-
mutex_unlock(&obj->base.dev->struct_mutex);
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Include engine->last_submitted_seqno in GPU error state
== Series Details == Series: series starting with [1/7] drm/i915: Include engine->last_submitted_seqno in GPU error state URL : https://patchwork.freedesktop.org/series/5351/ State : failure == Summary == Series 5351v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5351/revisions/1/mbox/ Test gem_basic: Subgroup create-fd-close: pass -> DMESG-WARN (bsw-nuc-2) Test gem_exec_basic: Subgroup basic-default: pass -> SKIP (bsw-nuc-2) Subgroup readonly-blt: pass -> SKIP (bsw-nuc-2) Test gem_mmap_gtt: Subgroup basic-read-write-distinct: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-write-read: pass -> DMESG-WARN (bsw-nuc-2) Test gem_pwrite: Subgroup basic: pass -> DMESG-WARN (bsw-nuc-2) Test gem_ringfill: Subgroup basic-default: pass -> INCOMPLETE (bsw-nuc-2) Subgroup basic-default-hang: pass -> DMESG-WARN (bsw-nuc-2) Test gem_sync: Subgroup basic-all: dmesg-fail -> PASS (bsw-nuc-2) Subgroup basic-vebox: pass -> DMESG-FAIL (bsw-nuc-2) Test kms_addfb_basic: Subgroup basic: pass -> DMESG-WARN (bsw-nuc-2) Subgroup unused-pitches: pass -> DMESG-WARN (bsw-nuc-2) Test kms_force_connector_basic: Subgroup force-connector-state: pass -> SKIP (ivb-t430s) Subgroup force-load-detect: pass -> SKIP (ilk-hp8440p) Subgroup prune-stale-modes: skip -> PASS (ivb-t430s) Test kms_pipe_crc_basic: Subgroup bad-nb-words-3: pass -> DMESG-WARN (bsw-nuc-2) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (bsw-nuc-2) Test pm_rps: Subgroup basic-api: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:148 pass:110 dwarn:10 dfail:1 fail:0 skip:26 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:130 dwarn:1 dfail:0 fail:0 skip:65 ivb-t430stotal:196 pass:170 dwarn:0 dfail:0 fail:0 skip:26 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1812/ 12899f13b8ee9a4944f167a08e4db0526a3f3855 drm-intel-nightly: 2016y-04m-05d-19h-09m-25s UTC integration manifest dce9e0d57ba434cde841ecc3b9ae58cb46e3e4b9 drm/i915: Simplify check for idleness in hangcheck 5edecb0b29f511367669f38d38399042ce2252ab drm/i915: Reset engine->last_submitted_seqno 0647a579d81612c2181a8331f47466819274e6a8 drm/i915: Reset semaphore page for gen8 69965ead9fa84032d63a63428234b8136a5b2f36 drm/i915: Move the hw semaphore initialisation from GEM to the engine 267eef5a3224d69f17e0f7b905e135698ab91b0a drm/i915: Remove unneeded drm_device pointer from intel_ring_init_seqno() 43d1f675567938739ef4712566d67b3e222e1f5d drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno da9bf3b735ccaf0405d318fc4d5d778693f0dfec drm/i915: Include engine->last_submitted_seqno in GPU error state ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Consolidate common error handling in intel_pin_and_map_ringbuffer_obj
On 05/04/16 13:57, Chris Wilson wrote:
After we pin the ringbuffer into the GGTT, all error paths need to unpin
it again. Move this common step into one block, and make the unable to
iomap error code consistent (i.e. treat it as out of memory to avoid
confusing it with a invalid argument).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2e864b7a528b..c6ae92529fdc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2121,15 +2121,13 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
return ret;
ret = i915_gem_object_set_to_cpu_domain(obj, true);
- if (ret) {
- i915_gem_object_ggtt_unpin(obj);
- return ret;
- }
+ if (ret)
+ goto err_unpin;
ringbuf->virtual_start = vmap_obj(obj);
if (ringbuf->virtual_start == NULL) {
- i915_gem_object_ggtt_unpin(obj);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err_unpin;
}
} else {
ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
@@ -2137,10 +2135,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
return ret;
ret = i915_gem_object_set_to_gtt_domain(obj, true);
- if (ret) {
- i915_gem_object_ggtt_unpin(obj);
- return ret;
- }
+ if (ret)
+ goto err_unpin;
/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
@@ -2148,14 +2144,17 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
ringbuf->virtual_start = ioremap_wc(ggtt->mappable_base +
i915_gem_obj_ggtt_offset(obj),
ringbuf->size);
if (ringbuf->virtual_start == NULL) {
- i915_gem_object_ggtt_unpin(obj);
- return -EINVAL;
+ ret = -ENOMEM;
+ goto err_unpin;
}
}
ringbuf->vma = i915_gem_obj_to_ggtt(obj);
-
O_o :D
return 0;
+
+err_unpin:
+ i915_gem_object_ggtt_unpin(obj);
+ return ret;
}
static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Simplify check for idleness in hangcheck
On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote:
> Having fixed the tracking of the engine's last_submitted_seqno, we can
> now rely on it for detecting when the engine is idle (and not have to
> touch the requests pointer).
>
> Testcase: igt/gem_exec_whisper
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_irq.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index c85eb8dec2dc..a56be4f92264 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2805,8 +2805,7 @@ static void gen8_disable_vblank(struct drm_device *dev,
> unsigned int pipe)
> static bool
> ring_idle(struct intel_engine_cs *engine, u32 seqno)
> {
> - return (list_empty(&engine->request_list) ||
> - i915_seqno_passed(seqno, engine->last_submitted_seqno));
> + return i915_seqno_passed(seqno, engine->last_submitted_seqno);
> }
>
> static bool
--
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/7] drm/i915: Remove unneeded drm_device pointer from intel_ring_init_seqno()
On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote:
> We only use drm_i915_private within the function, so delete the unneeded
> drm_device local.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 2e864b7a528b..371f4c1fc33c 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2550,13 +2550,12 @@ int intel_ring_cacheline_align(struct
> drm_i915_gem_request *req)
>
> void intel_ring_init_seqno(struct intel_engine_cs *engine, u32 seqno)
> {
> - struct drm_device *dev = engine->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_i915_private *dev_priv = to_i915(engine->dev);
>
> - if (INTEL_INFO(dev)->gen == 6 || INTEL_INFO(dev)->gen == 7) {
> + if (INTEL_INFO(dev_priv)->gen == 6 || INTEL_INFO(dev_priv)->gen == 7) {
> I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
> I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
> - if (HAS_VEBOX(dev))
> + if (HAS_VEBOX(dev_priv))
> I915_WRITE(RING_SYNC_2(engine->mmio_base), 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
[Intel-gfx] [PATCH] drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport
From: Tim Gore
WaEnableSamplerGPGPUPreemptionSupport fixes a problem
related to mid thread pre-emption.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 30fea34..de83914 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7142,6 +7142,7 @@ enum skl_disp_power_wells {
#define GEN9_HALF_SLICE_CHICKEN7 _MMIO(0xe194)
#define GEN9_ENABLE_YV12_BUGFIX (1<<4)
+#define GEN9_ENABLE_GPGPU_PREEMPTION (1<<2)
/* Audio */
#define G4X_AUD_VID_DID
_MMIO(dev_priv->info.display_mmio_offset + 0x62020)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2e864b7..0b4f582 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -959,9 +959,10 @@ static int gen9_init_workarounds(struct intel_engine_cs
*engine)
}
/* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt */
- if (IS_SKL_REVID(dev, SKL_REVID_C0, REVID_FOREVER) || IS_BROXTON(dev))
- WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
- GEN9_ENABLE_YV12_BUGFIX);
+ /* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt */
+ WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
+ GEN9_ENABLE_YV12_BUGFIX |
+ GEN9_ENABLE_GPGPU_PREEMPTION);
/* Wa4x4STCOptimizationDisable:skl,bxt */
/* WaDisablePartialResolveInVc:skl,bxt */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Include engine->last_submitted_seqno in GPU error state
Chris Wilson writes:
> [ text/plain ]
> It's useful to look at the last seqno submitted on a particular engine
> and compare it against the HWS value to check for irregularities.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 6 --
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 ++
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a2e3af02c292..906e5424e488 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1363,8 +1363,10 @@ static int i915_hangcheck_info(struct seq_file *m,
> void *unused)
>
> for_each_engine_id(engine, dev_priv, id) {
> seq_printf(m, "%s:\n", engine->name);
> - seq_printf(m, "\tseqno = %x [current %x]\n",
> -engine->hangcheck.seqno, seqno[id]);
> + seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
> +engine->hangcheck.seqno,
> +seqno[id],
> +engine->last_submitted_seqno);
> seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
> (long long)engine->hangcheck.acthd,
> (long long)acthd[id]);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 313bc3576d87..fad8e0d5a216 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -495,6 +495,7 @@ struct drm_i915_error_state {
> u32 cpu_ring_head;
> u32 cpu_ring_tail;
>
> + u32 last_seqno;
> u32 semaphore_seqno[I915_NUM_ENGINES - 1];
>
> /* Register state */
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 9b55409d91b3..9463cb4e9323 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -296,6 +296,7 @@ static void i915_ring_error_state(struct
> drm_i915_error_state_buf *m,
> }
> }
> err_printf(m, " seqno: 0x%08x\n", ring->seqno);
> + err_printf(m, " last_seqno: 0x%08x\n", ring->last_seqno);
> err_printf(m, " waiting: %s\n", yesno(ring->waiting));
> err_printf(m, " ring->head: 0x%08x\n", ring->cpu_ring_head);
> err_printf(m, " ring->tail: 0x%08x\n", ring->cpu_ring_tail);
> @@ -931,6 +932,7 @@ static void i915_record_ring_state(struct drm_device *dev,
> ering->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
> ering->seqno = engine->get_seqno(engine, false);
> ering->acthd = intel_ring_get_active_head(engine);
> + ering->last_seqno = engine->last_submitted_seqno;
> ering->start = I915_READ_START(engine);
> ering->head = I915_READ_HEAD(engine);
> ering->tail = I915_READ_TAIL(engine);
> --
> 2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno
Chris Wilson writes: > [ text/plain ] > After the GPU reset and we discard all of the incomplete requests, mark > the GPU as having advanced to the last_submitted_seqno (as having > completed the requests and ready for fresh work). The impact of this is > negligible, as all the requests will be considered completed by this > point, it just brings the HWS into line with expectations for external > viewers. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Joonas Lahtinen Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 40f90c7e718a..3e9e6f9b66f5 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -2882,6 +2882,8 @@ static void i915_gem_reset_engine_cleanup(struct > drm_i915_private *dev_priv, > buffer->last_retired_head = buffer->tail; > intel_ring_update_space(buffer); > } > + > + intel_ring_init_seqno(engine, engine->last_submitted_seqno); > } > > void i915_gem_reset(struct drm_device *dev) > -- > 2.8.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move the hw semaphore initialisation from GEM to the engine
Chris Wilson writes:
> [ text/plain ]
> Since we are setting engine local values that are tied to the hardware,
> move it out of i915_gem_init_seqno() into the intel_ring_init_seqno()
> backend, next to where the other hw semaphore registers are written.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 8 ++--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3e9e6f9b66f5..65f18f583ae1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2468,7 +2468,7 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_engine_cs *engine;
> - int ret, j;
> + int ret;
>
> /* Carefully retire all requests without writing to the rings */
> for_each_engine(engine, dev_priv) {
> @@ -2479,13 +2479,9 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
> i915_gem_retire_requests(dev);
>
> /* Finally reset hw state */
> - for_each_engine(engine, dev_priv) {
> + for_each_engine(engine, dev_priv)
> intel_ring_init_seqno(engine, seqno);
>
> - for (j = 0; j < ARRAY_SIZE(engine->semaphore.sync_seqno); j++)
> - engine->semaphore.sync_seqno[j] = 0;
> - }
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 371f4c1fc33c..fb304df8085d 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2552,14 +2552,21 @@ void intel_ring_init_seqno(struct intel_engine_cs
> *engine, u32 seqno)
> {
> struct drm_i915_private *dev_priv = to_i915(engine->dev);
>
> + /* Semaphores are strictly monotonic, so whenever we reset the seqno,
> + * so long as we reset the tracking semaphore value to 0, it will
> + * always be before the next request's seqno.
> + */
> if (INTEL_INFO(dev_priv)->gen == 6 || INTEL_INFO(dev_priv)->gen == 7) {
> I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
> I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
> if (HAS_VEBOX(dev_priv))
> I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
> }
> + memset(engine->semaphore.sync_seqno, 0,
> +sizeof(engine->semaphore.sync_seqno));
>
> engine->set_seqno(engine, seqno);
> +
> engine->hangcheck.seqno = seqno;
> }
>
> --
> 2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Refactor duplicate object vmap functions
On 05/04/16 13:57, Chris Wilson wrote:
We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the vmapping into the
obj->pages lifetime, then we can reuse an obj->vmapping for both and at
the same time couple it into the shrinker.
I suppose Dave could respin the "vmap_range" helper on top of this
series to further consolidate cmd parser and i915_gem_object_pin_vmap.
v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala)
v3: Call unpin_vmap from the right dmabuf unmapper
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 12 +---
drivers/gpu/drm/i915/i915_gem.c | 45 ++
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 49 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 ++---
4 files changed, 60 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6443745d4182..5fedb1b7d8d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2167,10 +2167,7 @@ struct drm_i915_gem_object {
struct scatterlist *sg;
int last;
} get_page;
-
- /* prime dma-buf support */
- void *dma_buf_vmapping;
- int vmapping_count;
+ void *vmapping;
/** Breadcrumb of last rendering to the buffer.
* There can only be one writer, but we allow for multiple readers.
@@ -2985,12 +2982,19 @@ static inline void i915_gem_object_pin_pages(struct
drm_i915_gem_object *obj)
BUG_ON(obj->pages == NULL);
obj->pages_pin_count++;
}
+
static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
{
BUG_ON(obj->pages_pin_count == 0);
obj->pages_pin_count--;
}
+void *__must_check i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj);
+static inline void i915_gem_object_unpin_vmap(struct drm_i915_gem_object *obj)
+{
+ i915_gem_object_unpin_pages(obj);
+}
+
int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
int i915_gem_object_sync(struct drm_i915_gem_object *obj,
struct intel_engine_cs *to,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 40f90c7e718a..be4cf13343d5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
* lists early. */
list_del(&obj->global_list);
+ if (obj->vmapping) {
+ vunmap(obj->vmapping);
+ obj->vmapping = NULL;
+ }
+
ops->put_pages(obj);
obj->pages = NULL;
@@ -2400,6 +2405,46 @@ i915_gem_object_get_pages(struct drm_i915_gem_object
*obj)
return 0;
}
+void *i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj)
Kerneldoc would be cool, if for nothing then for the return value.
+{
+ int ret;
+
lockdep_assert_held maybe?
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ return ERR_PTR(ret);
+
+ i915_gem_object_pin_pages(obj);
+
+ if (obj->vmapping == NULL) {
+ struct sg_page_iter sg_iter;
+ struct page **pages;
+ int n;
+
+ n = obj->base.size >> PAGE_SHIFT;
+ pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
+ if (pages == NULL)
+ pages = drm_malloc_ab(n, sizeof(*pages));
+ if (pages != NULL) {
+ n = 0;
+ for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
+ pages[n++] = sg_page_iter_page(&sg_iter);
+
+ obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
+ if (obj->vmapping == NULL) {
+ i915_gem_shrink_all(to_i915(obj->base.dev));
Won't the shrinker already run via the new notifier? Why call it again
and for all objects this time?
Also, act on the return value before retrying vmap?
+ obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
+ }
+ drm_free_large(pages);
+ }
+ if (obj->vmapping == NULL) {
+ i915_gem_object_unpin_pages(obj);
+ return ERR_PTR(-ENOMEM);
+ }
+ }
+
+ return obj->vmapping;
+}
+
void i915_vma_move_to_active(struct i915_vma *vma,
struct drm_i915_gem_request *req)
{
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index b7d46800c49f..8d8feadee18c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -108,51 +108,17 @@ static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Reset engine->last_submitted_seqno
Chris Wilson writes: > [ text/plain ] > When we change the current seqno, we also need to remember to reset the > last_submitted_seqno for the engine. > > Testcase: igt/gem_exec_whisper > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Joonas Lahtinen Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index c7023d6ca0b7..be73c1b415e2 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -2574,6 +2574,7 @@ void intel_ring_init_seqno(struct intel_engine_cs > *engine, u32 seqno) > } > > engine->set_seqno(engine, seqno); > + engine->last_submitted_seqno = seqno; > > engine->hangcheck.seqno = seqno; > } > -- > 2.8.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH resend-for-CI 2/3] drm/i915: Simplify for_each_fw_domain iterators
From: Tvrtko Ursulin
As the vast majority of users do not use the domain id variable,
we can eliminate it from the iterator and also change the latter
using the same principle as was recently done for for_each_engine.
For a couple of callers which do need the domain mask, store it
in the domain array (which already has the domain id), then both
can be retrieved thence.
Result is clearer code and smaller generated binary, especially
in the tight fw get/put loops. Also, relationship between domain
id and mask is no longer assumed in the macro.
v2: Improve grammar in the commit message and rename the
iterator to for_each_fw_domain_masked for consistency.
(Dave Gordon)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h | 17 +++---
drivers/gpu/drm/i915/intel_uncore.c | 45 +
3 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af02c292..06fce014d0b4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1464,12 +1464,11 @@ static int i915_forcewake_domains(struct seq_file *m,
void *data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_uncore_forcewake_domain *fw_domain;
- int i;
spin_lock_irq(&dev_priv->uncore.lock);
- for_each_fw_domain(fw_domain, dev_priv, i) {
+ for_each_fw_domain(fw_domain, dev_priv) {
seq_printf(m, "%s.wake_count = %u\n",
- intel_uncore_forcewake_domain_to_str(i),
+ intel_uncore_forcewake_domain_to_str(fw_domain->id),
fw_domain->wake_count);
}
spin_unlock_irq(&dev_priv->uncore.lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8ee5f78d45bc..6decc9b058dc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -665,6 +665,7 @@ struct intel_uncore {
struct intel_uncore_forcewake_domain {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
+ enum forcewake_domains mask;
unsigned wake_count;
struct hrtimer timer;
i915_reg_t reg_set;
@@ -679,14 +680,14 @@ struct intel_uncore {
};
/* Iterate over initialised fw domains */
-#define for_each_fw_domain_mask(domain__, mask__, dev_priv__, i__) \
- for ((i__) = 0, (domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
-(i__) < FW_DOMAIN_ID_COUNT; \
-(i__)++, (domain__) = &(dev_priv__)->uncore.fw_domain[i__]) \
- for_each_if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1
<< (i__)))
-
-#define for_each_fw_domain(domain__, dev_priv__, i__) \
- for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
+#define for_each_fw_domain_masked(domain__, mask__, dev_priv__) \
+ for ((domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
+(domain__) < &(dev_priv__)->uncore.fw_domain[FW_DOMAIN_ID_COUNT]; \
+(domain__)++) \
+ for_each_if ((mask__) & (domain__)->mask)
+
+#define for_each_fw_domain(domain__, dev_priv__) \
+ for_each_fw_domain_masked(domain__, FORCEWAKE_ALL, dev_priv__)
#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
#define CSR_VERSION_MAJOR(version) ((version) >> 16)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 2e3e92469947..575c81e08ea6 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -111,9 +111,8 @@ static void
fw_domains_get(struct drm_i915_private *dev_priv, enum forcewake_domains
fw_domains)
{
struct intel_uncore_forcewake_domain *d;
- enum forcewake_domain_id id;
- for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
+ for_each_fw_domain_masked(d, fw_domains, dev_priv) {
fw_domain_wait_ack_clear(d);
fw_domain_get(d);
fw_domain_wait_ack(d);
@@ -124,9 +123,8 @@ static void
fw_domains_put(struct drm_i915_private *dev_priv, enum forcewake_domains
fw_domains)
{
struct intel_uncore_forcewake_domain *d;
- enum forcewake_domain_id id;
- for_each_fw_domain_mask(d, fw_domains, dev_priv, id) {
+ for_each_fw_domain_masked(d, fw_domains, dev_priv) {
fw_domain_put(d);
fw_domain_posting_read(d);
}
@@ -136,10 +134,9 @@ static void
fw_domains_posting_read(struct drm_i915_private *dev_priv)
{
struct intel_uncore_forcewake_domain *d;
- enum forcewake_domain_id id;
/* No need to do for all, just do for first found */
- for_each_fw_domain(d, dev_priv, i
[Intel-gfx] [PATCH resend-for-CI 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
From: Tvrtko Ursulin
Because it is based on jiffies, current implementation releases the
forcewake at any time between straight away and between 1ms and 10ms,
depending on the kernel configuration (CONFIG_HZ).
This is probably not what has been desired, since the dynamics of keeping
parts of the GPU awake should not be correlated with this kernel
configuration parameter.
Change the auto-release mechanism to use hrtimers and set the timeout to
1ms with a 1ms of slack. This should make the GPU power consistent
across kernel configs, and timer slack should enable some timer coalescing
where multiple force-wake domains exist, or with unrelated timers.
For GlBench/T-Rex this decreases the number of forcewake releases from
~480 to ~300 per second, and for a heavy combined OGL/OCL test from
~670 to ~360 (HZ=1000 kernel).
Even though this reduction can be attributed to the average release period
extending from 0-1ms to 1-2ms, as discussed above, it will make the
forcewake timeout consistent for different CONFIG_HZ values.
Real life measurements with the above workload has shown that, with this
patch, both manage to auto-release the forcewake between 2-4 times per
10ms, even though the number of forcewake gets is dramatically different.
T-Rex requests between 5-10 explicit gets and 5-10 implict gets in each
10ms period, while the OGL/OCL test requests 250 and 380 times in the same
period.
The two data points together suggest that the nature of the forwake
accesses is bursty and that further changes and potential timeout
extensions, or moving the start of timeout from the first to the last
automatic forcewake grab, should be carefully measured for power and
performance effects.
v2:
* Commit spelling. (Dave Gordon)
* More discussion on numbers in the commit. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Dave Gordon
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 25 -
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 313bc3576d87..8ee5f78d45bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -666,7 +666,7 @@ struct intel_uncore {
struct drm_i915_private *i915;
enum forcewake_domain_id id;
unsigned wake_count;
- struct timer_list timer;
+ struct hrtimer timer;
i915_reg_t reg_set;
u32 val_set;
u32 val_clear;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index fbc1d215ca67..2e3e92469947 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,7 +60,11 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain
*d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
- mod_timer_pinned(&d->timer, jiffies + 1);
+ d->wake_count++;
+ hrtimer_start_range_ns(&d->timer,
+ ktime_set(0, NSEC_PER_MSEC),
+ NSEC_PER_MSEC,
+ HRTIMER_MODE_REL);
}
static inline void
@@ -224,9 +228,11 @@ static int __gen6_gt_wait_for_fifo(struct drm_i915_private
*dev_priv)
return ret;
}
-static void intel_uncore_fw_release_timer(unsigned long arg)
+static enum hrtimer_restart
+intel_uncore_fw_release_timer(struct hrtimer *timer)
{
- struct intel_uncore_forcewake_domain *domain = (void *)arg;
+ struct intel_uncore_forcewake_domain *domain =
+ container_of(timer, struct intel_uncore_forcewake_domain, timer);
unsigned long irqflags;
assert_rpm_device_not_suspended(domain->i915);
@@ -240,6 +246,8 @@ static void intel_uncore_fw_release_timer(unsigned long arg)
1 << domain->id);
spin_unlock_irqrestore(&domain->i915->uncore.lock, irqflags);
+
+ return HRTIMER_NORESTART;
}
void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore)
@@ -259,16 +267,16 @@ void intel_uncore_forcewake_reset(struct drm_device *dev,
bool restore)
active_domains = 0;
for_each_fw_domain(domain, dev_priv, id) {
- if (del_timer_sync(&domain->timer) == 0)
+ if (hrtimer_cancel(&domain->timer) == 0)
continue;
- intel_uncore_fw_release_timer((unsigned long)domain);
+ intel_uncore_fw_release_timer(&domain->timer);
}
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
for_each_fw_domain(domain, dev_priv, id) {
- if (timer_pending(&domain->timer))
+ if (hrtimer_active(&domain->timer))
[Intel-gfx] [PATCH resend-for-CI 3/3] drm/i915: Do not serialize forcewake acquire across domains
From: Tvrtko Ursulin
On platforms with multiple forcewake domains it seems more efficient
to request all desired ones and then to wait for acks to avoid
needlessly serializing on each domain.
v2: Rebase.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 575c81e08ea6..205f1b76ef44 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -115,8 +115,10 @@ fw_domains_get(struct drm_i915_private *dev_priv, enum
forcewake_domains fw_doma
for_each_fw_domain_masked(d, fw_domains, dev_priv) {
fw_domain_wait_ack_clear(d);
fw_domain_get(d);
- fw_domain_wait_ack(d);
}
+
+ for_each_fw_domain_masked(d, fw_domains, dev_priv)
+ fw_domain_wait_ack(d);
}
static void
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Simplify check for idleness in hangcheck
Chris Wilson writes:
> [ text/plain ]
> Having fixed the tracking of the engine's last_submitted_seqno, we can
> now rely on it for detecting when the engine is idle (and not have to
> touch the requests pointer).
>
> Testcase: igt/gem_exec_whisper
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_irq.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index c85eb8dec2dc..a56be4f92264 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2805,8 +2805,7 @@ static void gen8_disable_vblank(struct drm_device *dev,
> unsigned int pipe)
> static bool
> ring_idle(struct intel_engine_cs *engine, u32 seqno)
> {
> - return (list_empty(&engine->request_list) ||
> - i915_seqno_passed(seqno, engine->last_submitted_seqno));
> + return i915_seqno_passed(seqno, engine->last_submitted_seqno);
My concern here is that we should move the write for the
last_submitted_seqno before we push the work into ring.
To guarantee that the driver never sees a seqno > last_submitted_seqno
on particular ring.
-Mika
> }
>
> static bool
> --
> 2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()
On 05/04/16 14:05, Chris Wilson wrote:
On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote:
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want to
try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dri-de...@lists.freedesktop.org
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Acked-by: Dave Airlie
+static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t gfp)
+{
+ if (size != 0 && nmemb > SIZE_MAX / size)
+ return NULL;
I know Dave G. has some fancy code to detect when the size parameter is
not constant, but one thing I noticed was that gcc would uninline this
function and we would lose the constant folding. Is there anything we
can do to convince gcc to avoid a div here (other than pure macro)?
Don't know, apart from maybe _always_inline if it is not considered too big.
But I wanted to ask, why it is interesting to allow size == 0 ? Why not:
if (size == 0 || nmemb > SIZE_MAX / size)
return NULL;
?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Simplify check for idleness in hangcheck
On Wed, Apr 06, 2016 at 12:32:29PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > [ text/plain ]
> > Having fixed the tracking of the engine's last_submitted_seqno, we can
> > now rely on it for detecting when the engine is idle (and not have to
> > touch the requests pointer).
> >
> > Testcase: igt/gem_exec_whisper
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index c85eb8dec2dc..a56be4f92264 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2805,8 +2805,7 @@ static void gen8_disable_vblank(struct drm_device
> > *dev, unsigned int pipe)
> > static bool
> > ring_idle(struct intel_engine_cs *engine, u32 seqno)
> > {
> > - return (list_empty(&engine->request_list) ||
> > - i915_seqno_passed(seqno, engine->last_submitted_seqno));
> > + return i915_seqno_passed(seqno, engine->last_submitted_seqno);
>
> My concern here is that we should move the write for the
> last_submitted_seqno before we push the work into ring.
>
> To guarantee that the driver never sees a seqno > last_submitted_seqno
> on particular ring.
Reasonable request. You'll want a smp_store_mb() on the
last_submitted_seqno as well with a comment
/* barrier for hangcheck */
In return what's up with the Braswell?
-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 5/6] drm,i915: Introduce drm_malloc_gfp()
On Wed, Apr 06, 2016 at 10:40:19AM +0100, Tvrtko Ursulin wrote:
>
> On 05/04/16 14:05, Chris Wilson wrote:
> >On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote:
> >>I have instances where I want to use drm_malloc_ab() but with a custom
> >>gfp mask. And with those, where I want a temporary allocation, I want to
> >>try a high-order kmalloc() before using a vmalloc().
> >>
> >>So refactor my usage into drm_malloc_gfp().
> >>
> >>Signed-off-by: Chris Wilson
> >>Cc: dri-de...@lists.freedesktop.org
> >>Cc: Ville Syrjälä
> >>Reviewed-by: Ville Syrjälä
> >>Acked-by: Dave Airlie
> >
> >>+static __inline__ void *drm_malloc_gfp(size_t nmemb, size_t size, gfp_t
> >>gfp)
> >>+{
> >>+ if (size != 0 && nmemb > SIZE_MAX / size)
> >>+ return NULL;
> >
> >I know Dave G. has some fancy code to detect when the size parameter is
> >not constant, but one thing I noticed was that gcc would uninline this
> >function and we would lose the constant folding. Is there anything we
> >can do to convince gcc to avoid a div here (other than pure macro)?
>
> Don't know, apart from maybe _always_inline if it is not considered too big.
>
> But I wanted to ask, why it is interesting to allow size == 0 ? Why not:
>
> if (size == 0 || nmemb > SIZE_MAX / size)
> return NULL;
>
> ?
Cargo-culting. I guess the only thought was to avoid the div-by-zero and
to fallthrough to returning kmalloc(0) for equivalent behaviour.
-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/6] drm/i915: Avoid allocating a vmap arena for a single page
On 05/04/16 13:57, Chris Wilson wrote:
If we want a contiguous mapping of a single page sized object, we can
forgo using vmap() and just use a regular kmap(). Note that this is only
suitable if the desired pgprot_t is comptabitible.
You noticed the spelling already. :)
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 985f067c1f0e..dc8e1b76c896 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
list_del(&obj->global_list);
if (obj->vmapping) {
- vunmap(obj->vmapping);
+ if (obj->base.size == PAGE_SIZE)
+ kunmap(kmap_to_page(obj->vmapping));
+ else
+ vunmap(obj->vmapping);
Can't think of a reason why it would be better but there is also
is_vmalloc_addr(addr) as used by kvfree.
obj->vmapping = NULL;
}
@@ -2416,15 +2419,22 @@ void *i915_gem_object_pin_vmap(struct
drm_i915_gem_object *obj)
i915_gem_object_pin_pages(obj);
if (obj->vmapping == NULL) {
- struct sg_page_iter sg_iter;
struct page **pages;
- int n;
- n = obj->base.size >> PAGE_SHIFT;
- pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
+ pages = NULL;
+ if (obj->base.size == PAGE_SIZE)
+ obj->vmapping = kmap(sg_page(obj->pages->sgl));
+ else
+ pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
+ sizeof(*pages),
+ GFP_TEMPORARY);
if (pages != NULL) {
+ struct sg_page_iter sg_iter;
+ int n;
+
n = 0;
- for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
+ for_each_sg_page(obj->pages->sgl, &sg_iter,
+obj->pages->nents, 0)
pages[n++] = sg_page_iter_page(&sg_iter);
obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
Two problems I can spot are:
1. Callers of pin_vmap now don't know which kind of address they are
getting. Maybe call it pin_kvmap or something? Just mention in kerneldoc
could be enough.
2. Shrinker will try to kick out kmapped objects because they have
obj->vmapping set.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Reset semaphore page for gen8
On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote:
> An oversight is that when we wrap the seqno, we need to reset the hw
> semaphore counters to 0. We did this for gen6 and gen7 and forgot to do
> so for the new implementation required for gen8 (legacy).
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index fb304df8085d..c7023d6ca0b7 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2564,6 +2564,14 @@ void intel_ring_init_seqno(struct intel_engine_cs
> *engine, u32 seqno)
> }
> memset(engine->semaphore.sync_seqno, 0,
> sizeof(engine->semaphore.sync_seqno));
> + if (dev_priv->semaphore_obj) {
> + struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
> + struct page *page = i915_gem_object_get_dirty_page(obj, 0);
> + uint64_t *semaphores = kmap(page);
> + memset(semaphores + engine->id * I915_NUM_ENGINES, 0,
> + sizeof(*semaphores) * I915_NUM_ENGINES);
There is i915_semaphore_seqno_size define which the GEN8_WAIT_OFFSET
and GEN8_SIGNAL_OFFSET use. So rather use that to stay consistent.
Other than that,
Reviewed-by: Joonas Lahtinen
PS. The existing semaphore code could use some cleanup, adding to
backlog.
> + kunmap(page);
> + }
>
> engine->set_seqno(engine, seqno);
>
--
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/6] drm/i915: Refactor duplicate object vmap functions
On Wed, Apr 06, 2016 at 10:30:15AM +0100, Tvrtko Ursulin wrote:
>
> On 05/04/16 13:57, Chris Wilson wrote:
> >We now have two implementations for vmapping a whole object, one for
> >dma-buf and one for the ringbuffer. If we couple the vmapping into the
> >obj->pages lifetime, then we can reuse an obj->vmapping for both and at
> >the same time couple it into the shrinker.
>
> I suppose Dave could respin the "vmap_range" helper on top of this
> series to further consolidate cmd parser and
> i915_gem_object_pin_vmap.
Why though? The plan (see the earlier patches) is to completely replace
the cmdparser's current pessimism with this.
> >@@ -2400,6 +2405,46 @@ i915_gem_object_get_pages(struct drm_i915_gem_object
> >*obj)
> > return 0;
> > }
> >
> >+void *i915_gem_object_pin_vmap(struct drm_i915_gem_object *obj)
>
> Kerneldoc would be cool, if for nothing then for the return value.
>
> >+{
> >+int ret;
> >+
>
> lockdep_assert_held maybe?
Urm, see long term plans ;)
Yes, it applies now. I have in mind going through adding the
lockdep_assert_held() precisely because I have some patches to remove
the locking requirements around some core functions.
> >+ret = i915_gem_object_get_pages(obj);
> >+if (ret)
> >+return ERR_PTR(ret);
> >+
> >+i915_gem_object_pin_pages(obj);
> >+
> >+if (obj->vmapping == NULL) {
> >+struct sg_page_iter sg_iter;
> >+struct page **pages;
> >+int n;
> >+
> >+n = obj->base.size >> PAGE_SHIFT;
> >+pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
> >+if (pages == NULL)
> >+pages = drm_malloc_ab(n, sizeof(*pages));
> >+if (pages != NULL) {
> >+n = 0;
> >+for_each_sg_page(obj->pages->sgl, &sg_iter,
> >obj->pages->nents, 0)
> >+pages[n++] = sg_page_iter_page(&sg_iter);
> >+
> >+obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
> >+if (obj->vmapping == NULL) {
> >+i915_gem_shrink_all(to_i915(obj->base.dev));
>
> Won't the shrinker already run via the new notifier? Why call it
> again and for all objects this time?
Left over, forgot to update this chunk. The shrinker will be run for
both any kmalloc failures inside vmap as well as the arena notifier. So
we can indeed remove this manual shrinking. If we wanted to we could do
something like get_pages_gtt where we shrink ourselves before we allow the
notifier to run. I'm going to say that is overkill here...
> Also, act on the return value before retrying vmap?
No. The return value doesn't give a good indication as to whether the
next attempt will succeed or not (and we care more about the failure to
allocate than the transistory failure to shrink).
-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/6] drm/i915: Avoid allocating a vmap arena for a single page
On Wed, Apr 06, 2016 at 10:49:36AM +0100, Tvrtko Ursulin wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 985f067c1f0e..dc8e1b76c896 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
> >*obj)
> > list_del(&obj->global_list);
> >
> > if (obj->vmapping) {
> >-vunmap(obj->vmapping);
> >+if (obj->base.size == PAGE_SIZE)
> >+kunmap(kmap_to_page(obj->vmapping));
> >+else
> >+vunmap(obj->vmapping);
>
> Can't think of a reason why it would be better but there is also
> is_vmalloc_addr(addr) as used by kvfree.
For consistency with the shrinker (see below).
> > obj->vmapping = NULL;
> > }
> >
> >@@ -2416,15 +2419,22 @@ void *i915_gem_object_pin_vmap(struct
> >drm_i915_gem_object *obj)
> > i915_gem_object_pin_pages(obj);
> >
> > if (obj->vmapping == NULL) {
> >-struct sg_page_iter sg_iter;
> > struct page **pages;
> >-int n;
> >
> >-n = obj->base.size >> PAGE_SHIFT;
> >-pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
> >+pages = NULL;
> >+if (obj->base.size == PAGE_SIZE)
> >+obj->vmapping = kmap(sg_page(obj->pages->sgl));
> >+else
> >+pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
> >+ sizeof(*pages),
> >+ GFP_TEMPORARY);
> > if (pages != NULL) {
> >+struct sg_page_iter sg_iter;
> >+int n;
> >+
> > n = 0;
> >-for_each_sg_page(obj->pages->sgl, &sg_iter,
> >obj->pages->nents, 0)
> >+for_each_sg_page(obj->pages->sgl, &sg_iter,
> >+ obj->pages->nents, 0)
> > pages[n++] = sg_page_iter_page(&sg_iter);
> >
> > obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
> >
>
> Two problems I can spot are:
>
> 1. Callers of pin_vmap now don't know which kind of address they are
> getting. Maybe call it pin_kvmap or something? Just mention in
> kerneldoc could be enough.
I think just mention, and we can rename this to i915_gem_object_pin_map().
Hmm. I liked the pin in the name since it ties to to pin_pages (later
I plan to change that to get_pages and get_vmap/get_map as the pin
becomes implicit).
> 2. Shrinker will try to kick out kmapped objects because they have
> obj->vmapping set.
Not caring that much since the vmap_purge is very heavy weight, but we
can apply is_vmalloc_addr() to the shrinker.
Ok, happy to call this obj->mapping and i915_gem_object_pin_map() ?
-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 5/7] drm/i915: Reset semaphore page for gen8
On Wed, Apr 06, 2016 at 12:58:43PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote:
> > An oversight is that when we wrap the seqno, we need to reset the hw
> > semaphore counters to 0. We did this for gen6 and gen7 and forgot to do
> > so for the new implementation required for gen8 (legacy).
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index fb304df8085d..c7023d6ca0b7 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -2564,6 +2564,14 @@ void intel_ring_init_seqno(struct intel_engine_cs
> > *engine, u32 seqno)
> > }
> > memset(engine->semaphore.sync_seqno, 0,
> > sizeof(engine->semaphore.sync_seqno));
> > + if (dev_priv->semaphore_obj) {
> > + struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
> > + struct page *page = i915_gem_object_get_dirty_page(obj, 0);
> > + uint64_t *semaphores = kmap(page);
> > + memset(semaphores + engine->id * I915_NUM_ENGINES, 0,
> > + sizeof(*semaphores) * I915_NUM_ENGINES);
>
> There is i915_semaphore_seqno_size define which the GEN8_WAIT_OFFSET
> and GEN8_SIGNAL_OFFSET use. So rather use that to stay consistent.
I didn't want the size, I wanted the type. What I really wanted were
sensible macros...
I can change this to i915_semaphore_seqno_size (even though that is not
the right name) and void *.
> Other than that,
>
> Reviewed-by: Joonas Lahtinen
>
> PS. The existing semaphore code could use some cleanup, adding to
> backlog.
The existing semaphore code is 3 patches from working...
1. fix hw-id
2. fix signaling
3. reset pd after wait
4. enable/profit
-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 4/7] drm/i915: Move the hw semaphore initialisation from GEM to the engine
On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote:
> Since we are setting engine local values that are tied to the hardware,
> move it out of i915_gem_init_seqno() into the intel_ring_init_seqno()
> backend, next to where the other hw semaphore registers are written.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Comment below, but anyway;
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem.c | 8 ++--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3e9e6f9b66f5..65f18f583ae1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2468,7 +2468,7 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_engine_cs *engine;
> - int ret, j;
> + int ret;
>
> /* Carefully retire all requests without writing to the rings */
> for_each_engine(engine, dev_priv) {
> @@ -2479,13 +2479,9 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
> i915_gem_retire_requests(dev);
>
> /* Finally reset hw state */
> - for_each_engine(engine, dev_priv) {
> + for_each_engine(engine, dev_priv)
> intel_ring_init_seqno(engine, seqno);
>
> - for (j = 0; j < ARRAY_SIZE(engine->semaphore.sync_seqno); j++)
> - engine->semaphore.sync_seqno[j] = 0;
> - }
> -
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 371f4c1fc33c..fb304df8085d 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2552,14 +2552,21 @@ void intel_ring_init_seqno(struct intel_engine_cs
> *engine, u32 seqno)
> {
> struct drm_i915_private *dev_priv = to_i915(engine->dev);
>
> + /* Semaphores are strictly monotonic, so whenever we reset the seqno,
> + * so long as we reset the tracking semaphore value to 0, it will
> + * always be before the next request's seqno.
> + */
I'd start the comment with; "Our semaphore implementation" to make it
clear it's deliberately engineered to be so, not by hardware.
Regards, Joonas
> if (INTEL_INFO(dev_priv)->gen == 6 || INTEL_INFO(dev_priv)->gen == 7) {
> I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
> I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
> if (HAS_VEBOX(dev_priv))
> I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
> }
> + memset(engine->semaphore.sync_seqno, 0,
> + sizeof(engine->semaphore.sync_seqno));
>
> engine->set_seqno(engine, seqno);
> +
> engine->hangcheck.seqno = seqno;
> }
>
--
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
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
== Series Details == Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs URL : https://patchwork.freedesktop.org/series/5368/ State : failure == Summary == Series 5368v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/5368/revisions/1/mbox/ Test drv_module_reload_basic: pass -> INCOMPLETE (snb-dellxps) Test gem_ctx_exec: Subgroup basic: pass -> DMESG-WARN (bsw-nuc-2) Test gem_exec_basic: Subgroup gtt-vebox: pass -> SKIP (bsw-nuc-2) Test gem_exec_whisper: Subgroup basic: pass -> DMESG-FAIL (bsw-nuc-2) Test gem_mmap_gtt: Subgroup basic-read-no-prefault: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-small-copy: pass -> DMESG-WARN (bsw-nuc-2) Test gem_ringfill: Subgroup basic-default-forked: pass -> SKIP (bsw-nuc-2) Test gem_sync: Subgroup basic-all: dmesg-fail -> PASS (bsw-nuc-2) Subgroup basic-bsd: pass -> SKIP (bsw-nuc-2) Test gem_tiled_blits: Subgroup basic: pass -> DMESG-FAIL (bsw-nuc-2) Test kms_addfb_basic: Subgroup addfb25-framebuffer-vs-set-tiling: pass -> DMESG-WARN (bsw-nuc-2) Subgroup no-handle: pass -> DMESG-WARN (bsw-nuc-2) Subgroup unused-modifier: pass -> DMESG-WARN (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Test kms_force_connector_basic: Subgroup force-load-detect: pass -> SKIP (ivb-t430s) Subgroup prune-stale-modes: skip -> PASS (ivb-t430s) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:146 dwarn:8 dfail:2 fail:0 skip:40 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:170 dwarn:0 dfail:0 fail:0 skip:26 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:8pass:4dwarn:0 dfail:0 fail:0 skip:3 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1815/ 12899f13b8ee9a4944f167a08e4db0526a3f3855 drm-intel-nightly: 2016y-04m-05d-19h-09m-25s UTC integration manifest e91948647b54ee1282623093074317be46bc5c0d drm/i915: Do not serialize forcewake acquire across domains 5e50e9501440b2aacd277d56bade02f6e021e9ae drm/i915: Simplify for_each_fw_domain iterators 9bde3882e7d88a2567f179a36a866387f9c382f2 drm/i915: Use consistent forcewake auto-release timeout across kernel configs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly
On Tue, Apr 05, 2016 at 02:55:51PM -0700, Matt Roper wrote:
> On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote:
> > intel_update_max_cdclk() doesn't have a switch case for Broxton, so
> > dev_priv->max_cdclk_freq gets set to whatever clock frequency we're
> > currently running at (e.g., 144 MHz) rather than the true maximum. This
> > causes our max dotclock to also be set too low and in turn leads mode
> > verification to reject perfectly valid modes while loading EDID firmware
> > blobs.
> >
> > Cc: Imre Deak
> > Signed-off-by: Matt Roper
> > ---
>
> One thing I should have mentioned is that it's unclear to me whether we
> should be looking at the cdclk limit bits in the DFSM register like we
> do on SKL/KBL. The bspec seems to indicate that the register in general
> applies to gen9, including BXT, but the actual meaning of the bits
> doesn't match up with the frequencies we have on BXT.
It also says
"This field is unused on BXT. Any CD clock frequency limitation must be
done in software."
Anyway the DFSM story is apparently a sad one. See the discussion eg. in
https://lists.freedesktop.org/archives/intel-gfx/2016-February/087510.html
would be nice if someone could pick that up and figure out what we really
want/need to do.
>
>
> Matt
>
> > drivers/gpu/drm/i915/intel_display.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index af74cdb..924d851 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5261,6 +5261,8 @@ static void intel_update_max_cdclk(struct drm_device
> > *dev)
> > dev_priv->max_cdclk_freq = 45;
> > else
> > dev_priv->max_cdclk_freq = 337500;
> > + } else if (IS_BROXTON(dev)) {
> > + dev_priv->max_cdclk_freq = 624000;
> > } else if (IS_BROADWELL(dev)) {
> > /*
> > * FIXME with extra cooling we can allow
> > --
> > 2.1.4
> >
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport
== Series Details == Series: drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport URL : https://patchwork.freedesktop.org/series/5367/ State : failure == Summary == Series 5367v1 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport http://patchwork.freedesktop.org/api/1.0/series/5367/revisions/1/mbox/ Test drv_hangman: Subgroup error-state-basic: pass -> DMESG-WARN (ilk-hp8440p) Test gem_exec_store: Subgroup basic-all: pass -> FAIL (ilk-hp8440p) Subgroup basic-default: pass -> FAIL (ilk-hp8440p) Test gem_exec_suspend: Subgroup basic-s3: pass -> SKIP (ilk-hp8440p) Test gem_sync: Subgroup basic-all: dmesg-fail -> PASS (bsw-nuc-2) Test kms_force_connector_basic: Subgroup force-load-detect: pass -> DMESG-WARN (ilk-hp8440p) Subgroup prune-stale-modes: skip -> PASS (ivb-t430s) Test kms_frontbuffer_tracking: Subgroup basic: skip -> DMESG-FAIL (ilk-hp8440p) Test kms_pipe_crc_basic: Subgroup bad-nb-words-1: pass -> DMESG-WARN (ilk-hp8440p) Subgroup nonblocking-crc-pipe-a-frame-sequence: pass -> DMESG-FAIL (ilk-hp8440p) Subgroup nonblocking-crc-pipe-b-frame-sequence: pass -> DMESG-FAIL (ilk-hp8440p) Subgroup read-crc-pipe-b-frame-sequence: pass -> DMESG-FAIL (ilk-hp8440p) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (byt-nuc) UNSTABLE bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:160 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:122 dwarn:4 dfail:4 fail:2 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1814/ 12899f13b8ee9a4944f167a08e4db0526a3f3855 drm-intel-nightly: 2016y-04m-05d-19h-09m-25s UTC integration manifest cdf6759e25b45b399c499b67d054ac48cb5d6774 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Reset engine->last_submitted_seqno
On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > When we change the current seqno, we also need to remember to reset the > last_submitted_seqno for the engine. > > Testcase: igt/gem_exec_whisper > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index c7023d6ca0b7..be73c1b415e2 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -2574,6 +2574,7 @@ void intel_ring_init_seqno(struct intel_engine_cs > *engine, u32 seqno) > } > > engine->set_seqno(engine, seqno); > + engine->last_submitted_seqno = seqno; > > engine->hangcheck.seqno = seqno; > } -- 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/7] drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno
On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > After the GPU reset and we discard all of the incomplete requests, mark > the GPU as having advanced to the last_submitted_seqno (as having > completed the requests and ready for fresh work). The impact of this is > negligible, as all the requests will be considered completed by this > point, it just brings the HWS into line with expectations for external > viewers. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Joonas Lahtinen Makes sense to me. Reviewed-by: Joonas Lahtinen > --- > drivers/gpu/drm/i915/i915_gem.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 40f90c7e718a..3e9e6f9b66f5 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -2882,6 +2882,8 @@ static void i915_gem_reset_engine_cleanup(struct > drm_i915_private *dev_priv, > buffer->last_retired_head = buffer->tail; > intel_ring_update_space(buffer); > } > + > + intel_ring_init_seqno(engine, engine->last_submitted_seqno); > } > > void i915_gem_reset(struct drm_device *dev) -- 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 5/7] drm/i915: Reset semaphore page for gen8
On ke, 2016-04-06 at 11:10 +0100, Chris Wilson wrote:
> On Wed, Apr 06, 2016 at 12:58:43PM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote:
> > >
> > > An oversight is that when we wrap the seqno, we need to reset the hw
> > > semaphore counters to 0. We did this for gen6 and gen7 and forgot to do
> > > so for the new implementation required for gen8 (legacy).
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Mika Kuoppala
> > > Cc: Joonas Lahtinen
> > > ---
> > > drivers/gpu/drm/i915/intel_ringbuffer.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > index fb304df8085d..c7023d6ca0b7 100644
> > > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > @@ -2564,6 +2564,14 @@ void intel_ring_init_seqno(struct intel_engine_cs
> > > *engine, u32 seqno)
> > > }
> > > memset(engine->semaphore.sync_seqno, 0,
> > > sizeof(engine->semaphore.sync_seqno));
> > > + if (dev_priv->semaphore_obj) {
> > > + struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
> > > + struct page *page = i915_gem_object_get_dirty_page(obj, 0);
> > > + uint64_t *semaphores = kmap(page);
> > > + memset(semaphores + engine->id * I915_NUM_ENGINES, 0,
> > > + sizeof(*semaphores) * I915_NUM_ENGINES);
> > There is i915_semaphore_seqno_size define which the GEN8_WAIT_OFFSET
> > and GEN8_SIGNAL_OFFSET use. So rather use that to stay consistent.
> I didn't want the size, I wanted the type. What I really wanted were
> sensible macros...
The macros could use some cleanup is what I meant.
>
> I can change this to i915_semaphore_seqno_size (even though that is not
> the right name) and void *.
>
> >
> > Other than that,
> >
> > Reviewed-by: Joonas Lahtinen
> >
> > PS. The existing semaphore code could use some cleanup, adding to
> > backlog.
> The existing semaphore code is 3 patches from working...
> 1. fix hw-id
> 2. fix signaling
> 3. reset pd after wait
> 4. enable/profit
> -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] Reviving the LPSS PWM patches
On Tue, Apr 05, 2016 at 09:06:25PM +0200, Lluís Batlle i Rossell wrote: > On Tue, Apr 05, 2016 at 12:39:30PM +0200, Lluís Batlle i Rossell wrote: > > On Tue, Apr 05, 2016 at 12:03:44PM +0530, Kumar, Shobhit wrote: > > > On Thursday 31 March 2016 03:57 PM, Lluís Batlle i Rossell wrote: > > > >Hello, > > > > > > > >I saw that you did some work for LPSS PWM: > > > >https://lists.freedesktop.org/archives/intel-gfx/2016-January/085006.html > > > > Definitely I was quite blind in my initial attempts at applying the > > patches, and gave me the idea that they did not apply in any recent tree. > > I've checked that they apply and build over the released 4.5, so I will go > > testing that, maybe today. I will report. > > The screen goes black, as before. > > I attach the dmesg after applying the four patches (3 + 1) to 4.5. > PWM_LPSS=y and PWM_LPSS_PLATFORM=y > > I also attach a dmesg of a panicked kernel that actually does run in that > board, so you can see that it is actually a lpss-pwm case. I don't see any trace of pwm/lpss in dmesg, so it's normal that i915 fails to find it. I wonder if there may be a problem in the ACPI table. I have the DSDT and it clearly reports the: Name (_CID, "80860F09") // _CID: Compatible ID Name (_DDN, "Intel(R) PWM Controller #2 - 80860F09") // _DDN: DOS Device Name Which should be the lpss pwm. But somehow it is not loaded, so I guess it fails the probing. Maybe the DSDT is broken, and I should fix and recompile a new one for the pwm controller to work? I don't really know how this things work, and whether the kernel should report anything special if it were the case of a broken DSDT. Regards, Lluḉis. -- (Escriu-me xifrat si saps PGP / Write ciphered if you know PGP) PGP key D4831A8A - https://emailselfdefense.fsf.org/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 04/16] drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR
On Tue, Apr 05, 2016 at 01:26:05PM +0300, Imre Deak wrote:
> DMC forces on power well 1 and the misc IO power well by setting the
> corresponding request bits both in the BIOS and the DEBUG power well
> request registers. This is somewhat unexpected since the firmware should
> really just save and restore state but not alter it. We also depend on
> being able to disable power well 1, and the misc IO power well before
> entering S3/S4 on BXT and SKL or entering DC9 on BXT. To fix this make
> sure these request bits are cleared whenever we want to disable the
> given power wells.
>
> On SKL there is another twist where the firmware also clears the power
> well 1 request bit in HSW_POWER_WELL_DRIVER (but not that of the misc IO
> power well). This happens to not cause a problem due to the forced-on
> request bits in the other request registers.
>
> I've filed a bug about all this, but fixing that may take a while and
> having this sanity check in place makes sense even for future firmware
> versions.
>
> At the same time also check the KVMR request bits. I haven't seen this
> being altered, but we don't expect any request bits in here either, so
> sanitize this register as well.
>
> v2:
> - apply the workaround on SKL as well
>
> CC: Patrik Jakobsson
> Signed-off-by: Imre Deak
Hmm, more DMC fun.
Reviewed-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 41
> +
> 1 file changed, 41 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index d189a00..6ffa6ad 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -630,6 +630,44 @@ void skl_disable_dc6(struct drm_i915_private *dev_priv)
> gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> }
>
> +static void
> +gen9_sanitize_power_well_requests(struct drm_i915_private *dev_priv,
> + struct i915_power_well *power_well)
> +{
> + enum skl_disp_power_wells power_well_id = power_well->data;
> + u32 val;
> + u32 mask;
> +
> + mask = SKL_POWER_WELL_REQ(power_well_id);
> +
> + val = I915_READ(HSW_PWR_WELL_KVMR);
> + if (WARN_ONCE(val & mask, "Clearing unexpected KVMR request for %s\n",
> +power_well->name))
> + I915_WRITE(HSW_PWR_WELL_KVMR, val & ~mask);
> +
> + val = I915_READ(HSW_PWR_WELL_BIOS);
> + val |= I915_READ(HSW_PWR_WELL_DEBUG);
> +
> + if (!(val & mask))
> + return;
> +
> + /*
> + * DMC is known to force on the request bits for power well 1 on SKL
> + * and BXT and the misc IO power well on SKL but we don't expect any
> + * other request bits to be set, so WARN for those.
> + */
> + if (power_well_id == SKL_DISP_PW_1 ||
> + (IS_SKYLAKE(dev_priv) && power_well_id == SKL_DISP_PW_MISC_IO))
> + DRM_DEBUG_DRIVER("Clearing auxiliary requests for %s forced on "
> + "by DMC\n", power_well->name);
> + else
> + WARN_ONCE(1, "Clearing unexpected auxiliary requests for %s\n",
> + power_well->name);
> +
> + I915_WRITE(HSW_PWR_WELL_BIOS, val & ~mask);
> + I915_WRITE(HSW_PWR_WELL_DEBUG, val & ~mask);
> +}
> +
> static void skl_set_power_well(struct drm_i915_private *dev_priv,
> struct i915_power_well *power_well, bool enable)
> {
> @@ -696,6 +734,9 @@ static void skl_set_power_well(struct drm_i915_private
> *dev_priv,
> POSTING_READ(HSW_PWR_WELL_DRIVER);
> DRM_DEBUG_KMS("Disabling %s\n", power_well->name);
> }
> +
> + if (IS_SKYLAKE(dev_priv) || IS_BROXTON(dev_priv))
> + gen9_sanitize_power_well_requests(dev_priv, power_well);
> }
>
> if (check_fuse_status) {
> --
> 2.5.0
>
--
---
Intel Sweden AB Registered Office: Knarrarnasgatan 15, 164 40 Kista, Stockholm,
Sweden Registration Number: 556189-6027
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs
On Wed, Apr 06, 2016 at 10:28:29AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent > forcewake auto-release timeout across kernel configs > URL : https://patchwork.freedesktop.org/series/5368/ > State : failure > > == Summary == > > Series 5368v1 Series without cover letter > http://patchwork.freedesktop.org/api/1.0/series/5368/revisions/1/mbox/ > > Test drv_module_reload_basic: > pass -> INCOMPLETE (snb-dellxps) > Test gem_ctx_exec: > Subgroup basic: > pass -> DMESG-WARN (bsw-nuc-2) > Test gem_exec_basic: > Subgroup gtt-vebox: > pass -> SKIP (bsw-nuc-2) > Test gem_exec_whisper: > Subgroup basic: > pass -> DMESG-FAIL (bsw-nuc-2) > Test gem_mmap_gtt: > Subgroup basic-read-no-prefault: > pass -> DMESG-WARN (bsw-nuc-2) > Subgroup basic-small-copy: > pass -> DMESG-WARN (bsw-nuc-2) > Test gem_ringfill: > Subgroup basic-default-forked: > pass -> SKIP (bsw-nuc-2) > Test gem_sync: > Subgroup basic-all: > dmesg-fail -> PASS (bsw-nuc-2) > Subgroup basic-bsd: > pass -> SKIP (bsw-nuc-2) > Test gem_tiled_blits: > Subgroup basic: > pass -> DMESG-FAIL (bsw-nuc-2) > Test kms_addfb_basic: > Subgroup addfb25-framebuffer-vs-set-tiling: > pass -> DMESG-WARN (bsw-nuc-2) > Subgroup no-handle: > pass -> DMESG-WARN (bsw-nuc-2) > Subgroup unused-modifier: > pass -> DMESG-WARN (bsw-nuc-2) > Test kms_flip: > Subgroup basic-flip-vs-dpms: > dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE > Test kms_force_connector_basic: > Subgroup force-load-detect: > pass -> SKIP (ivb-t430s) > Subgroup prune-stale-modes: > skip -> PASS (ivb-t430s) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > dmesg-warn -> PASS (bsw-nuc-2) > Test kms_setmode: > Subgroup basic-clone-single-crtc: > pass -> DMESG-WARN (bsw-nuc-2) > Test pm_rpm: > Subgroup basic-pci-d3-state: > pass -> DMESG-WARN (bsw-nuc-2) Braswell is snafu. However, Braswell is also one of the devices with the more interesting fw domains, so I guess we should wait for the all-clear? -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] [PATCHv3 0/4] Add USB typeC based DP support for BXT platform
This patch series adds upfront link training support to enable USB type C based DP on BXT platform. To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel can support more lanes. The goal is to find out the number of lanes which can be supported using a particular cable so that we can cap 'max_available_lanes' to that number during modeset. Patch 1/4 :Moves finding unused crtc to a common function Patch 2,3/4 :Update pll config's crtc_mask/dpll hw_state to use in upfront link train Patch 4/4 :Upfront implementation for DDI platforms (for now, tested on BXT B1). Changes from v2: * Rebased on top of intel_dpll_mgr.c code. * Use drm_atomic_commit instead of atomic_helper_dpms, since the later uses crtc->acquire_ctx used also in legacy paths. * Using a drm_atomic_state helps in using the shared_dpll APIs as is, thus keeping the upfront code away from changing pll internals directly. * Fixed locking/retry/backoff logic in upfront according to atomic implementation. Changes from v1: * Using atomic_helper_dpms() to do DPMS off for upfront link training, instead of using load detect functions. * Made intel_get_shared_dpll handle non-atomic paths by duplicating the required shared_dpll_config and then working on top of it. This helps in upfront link train code not directly touch the 'pll/pll->config' internals. * Fixed the link_bw update logic in intel_dp_get_link_retry_params() for non-HBR2 panels. * As per comments on earlier version, merged few patches (that added new functions) with the upfront link train patch, to facilitate easy review. Link for v2:https://patchwork.freedesktop.org/patch/72207/ Link for v1:https://patchwork.freedesktop.org/patch/67784/ Link for RFCv2: https://patchwork.freedesktop.org/patch/61776/ Link for RFCv1: https://patchwork.freedesktop.org/patch/59589/ Durgadoss R (4): drm/i915: Make finding unused crtc as a generic function drm/i915: Store the dpll config in crtc_state->shared_dpll drm/i915: Update dpll_hw_state if mask is same drm/i915/dp: Enable Upfront link training for typeC DP support on BXT drivers/gpu/drm/i915/intel_ddi.c | 46 + drivers/gpu/drm/i915/intel_display.c | 74 -- drivers/gpu/drm/i915/intel_dp.c | 180 +- drivers/gpu/drm/i915/intel_dpll_mgr.c | 8 +- drivers/gpu/drm/i915/intel_drv.h | 7 ++ 5 files changed, 279 insertions(+), 36 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv3 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes. To address these scenarios, the display driver will
start link training with max lanes, and if that fails, the driver
falls back to x2 lanes; and repeats this procedure for all
bandwidth/lane configurations.
* Since link training is done before modeset only the port
(and not pipe/planes) and its associated PLLs are enabled.
* On DP hotplug: Directly start link training on the crtc
associated with the DP encoder.
* On Connected boot scenarios: When booted with an LFP and a DP,
typically, BIOS brings up DP. In these cases, we disable the
crtc and then do upfront link training; and let the subsequent
modeset re-enable the crtc.
* All local changes made for upfront link training are reset
to their previous values once it is done; so that the
subsequent modeset is not aware of these changes.
Changes since v2:
* Rebased on top of latest dpll_mgr.c code and
latest HPD related clean ups.
* Corrected return values from upfront (Ander)
* Corrected atomic locking for upfront in intel_dp.c (Ville)
Changes since v1:
* all pll related functions inside ddi.c
Signed-off-by: Durgadoss R
---
drivers/gpu/drm/i915/intel_ddi.c | 46 ++
drivers/gpu/drm/i915/intel_dp.c | 180 ++-
drivers/gpu/drm/i915/intel_drv.h | 5 ++
3 files changed, 229 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1e08385..0add10a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2087,6 +2087,52 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port
*intel_dig_port)
return connector;
}
+int intel_ddi_upfront_link_train(struct intel_dp *intel_dp,
+ struct intel_crtc *crtc)
+{
+ struct intel_connector *connector = intel_dp->attached_connector;
+ struct intel_encoder *encoder = connector->encoder;
+ struct intel_shared_dpll *pll = NULL;
+ uint8_t link_bw, lane_count;
+
+ if (WARN_ON(!crtc))
+ return -EINVAL;
+
+ /* Initialize with Max Link rate & lane count supported by panel */
+ link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
+ lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+
+ do {
+ crtc->config->port_clock = drm_dp_bw_code_to_link_rate(link_bw);
+ crtc->config->lane_count = lane_count;
+
+ pll = intel_get_shared_dpll(crtc, crtc->config, encoder);
+ if (!pll) {
+ DRM_ERROR("Could not get shared DPLL\n");
+ return -EINVAL;
+ }
+
+ /* Enable PLL followed by port */
+ intel_enable_shared_dpll(crtc);
+ encoder->pre_enable(encoder);
+
+ /* Check if link training passed; if so update DPCD */
+ if (intel_dp->train_set_valid)
+ intel_dp_update_dpcd_params(intel_dp);
+
+ /* Disable port followed by PLL for next retry/clean up */
+ encoder->post_disable(encoder);
+ intel_disable_shared_dpll(crtc);
+
+ } while (!intel_dp->train_set_valid &&
+ intel_dp_get_link_retry_params(intel_dp, &lane_count,
&link_bw));
+
+ DRM_DEBUG_KMS("Upfront link train %s: lanes:%d bw:%d\n",
+ intel_dp->train_set_valid ? "Passed" : "Failed", lane_count, link_bw);
+
+ return intel_dp->train_set_valid ? 0 : -1;
+}
+
void intel_ddi_init(struct drm_device *dev, enum port port)
{
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..b8a42b8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1595,6 +1595,41 @@ void intel_dp_set_link_params(struct intel_dp *intel_dp,
intel_dp->lane_count = pipe_config->lane_count;
}
+void intel_dp_update_dpcd_params(struct intel_dp *intel_dp)
+{
+ intel_dp->dpcd[DP_MAX_LANE_COUNT] &= ~DP_MAX_LANE_COUNT_MASK;
+ intel_dp->dpcd[DP_MAX_LANE_COUNT] |=
+ intel_dp->lane_count & DP_MAX_LANE_COUNT_MASK;
+
+ intel_dp->dpcd[DP_MAX_LINK_RATE] =
+ drm_dp_link_rate_to_bw_code(intel_dp->link_rate);
+}
+
+bool intel_dp_get_link_retry_params(struct intel_dp *intel_dp,
+ uint8_t *lane_count, uint8_t *link_bw)
+{
+ /*
+* As per DP1.3 Spec, retry all link rates for a particular
+* lane count value, before reducing number of lanes.
+*/
+ if (*link_bw == DP_LINK_BW_5_4) {
+ *link_bw = DP_LINK_BW_2_7;
+ } else if (*link_bw == DP_LINK_BW_2_7) {
+
[Intel-gfx] [PATCHv3 3/4] drm/i915: Update dpll_hw_state if mask is same
Currently, the dpll_hw_state of a particular pll config
is not updated if the crtc_mask is non-zero, indicating
possibly shared dpll. But for things like upfront link
training, dpll_hw_state of a pll config needs to be
updated multiple times (for every new link_clock
calculation). This patch does that by letting the
update happen as long as the crtc_mask stays same.
Signed-off-by: Durgadoss R
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index cad10f2..f1ca753 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -235,13 +235,14 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll,
{
struct intel_shared_dpll_config *shared_dpll;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ unsigned int crtc_mask = 1 << drm_crtc_index(&crtc->base);
enum intel_dpll_id i = pll->id;
shared_dpll =
intel_atomic_get_shared_dpll_state(crtc_state->base.state);
- if (shared_dpll[i].crtc_mask == 0)
- shared_dpll[i].hw_state =
- crtc_state->dpll_hw_state;
+ if (shared_dpll[i].crtc_mask == 0 ||
+ shared_dpll[i].crtc_mask == crtc_mask)
+ shared_dpll[i].hw_state = crtc_state->dpll_hw_state;
crtc_state->shared_dpll = pll;
DRM_DEBUG_DRIVER("using %s for pipe %c\n", pll->name,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv3 2/4] drm/i915: Store the dpll config in crtc_state->shared_dpll
Currently, the required shared dpll is saved in the crtc_state. Similarly, this patch saves the dpll config values also, so that these values (through crtc_state->shared_dpll->config.hw_state) can be used for upfront link training. Signed-off-by: Durgadoss R --- drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c b/drivers/gpu/drm/i915/intel_dpll_mgr.c index 1175eeb..cad10f2 100644 --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c @@ -248,6 +248,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll, pipe_name(crtc->pipe)); intel_shared_dpll_config_get(shared_dpll, pll, crtc); + crtc_state->shared_dpll->config = shared_dpll[i]; } void intel_shared_dpll_commit(struct drm_atomic_state *state) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic function
Looping over the crtc list and finding an unused crtc
has other users like upfront link training. Hence move it to
a common function to re-use the logic.
v3:
* Added kernel Doc and removed an invalid comment (Ander)
* Rebased on top of latest code which includes locking
for state->enable usage.
v2:
* Made this as a separate function instead of having it
inside upfront link train code.
Signed-off-by: Durgadoss R
---
drivers/gpu/drm/i915/intel_display.c | 74 +---
drivers/gpu/drm/i915/intel_drv.h | 2 +
2 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e6b5ee5..3c1fbcd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10366,6 +10366,43 @@ static int intel_modeset_setup_plane_state(struct
drm_atomic_state *state,
return 0;
}
+/**
+ * intel_get_unused_crtc - Find an unused crtc for the given encoder
+ * @encoder: drm_encoder structure
+ * @ctx: ctx pointer to use with locking
+ *
+ * This function tries to find an unused crtc that can drive
+ * the given encoder. Returns NULL on failure.
+ */
+struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ struct drm_crtc *possible_crtc;
+ struct drm_crtc *crtc = NULL;
+ struct drm_device *dev = encoder->dev;
+ int ret, i = -1;
+
+ for_each_crtc(dev, possible_crtc) {
+ i++;
+ if (!(encoder->possible_crtcs & (1 << i)))
+ continue;
+
+ ret = drm_modeset_lock(&possible_crtc->mutex, ctx);
+ if (ret)
+ return ERR_PTR(ret);
+
+ if (possible_crtc->state->enable) {
+ drm_modeset_unlock(&possible_crtc->mutex);
+ continue;
+ }
+
+ crtc = possible_crtc;
+ break;
+ }
+
+ return crtc;
+}
+
bool intel_get_load_detect_pipe(struct drm_connector *connector,
struct drm_display_mode *mode,
struct intel_load_detect_pipe *old,
@@ -10374,7 +10411,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
struct intel_crtc *intel_crtc;
struct intel_encoder *intel_encoder =
intel_attached_encoder(connector);
- struct drm_crtc *possible_crtc;
struct drm_encoder *encoder = &intel_encoder->base;
struct drm_crtc *crtc = NULL;
struct drm_device *dev = encoder->dev;
@@ -10383,7 +10419,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
struct drm_atomic_state *state = NULL, *restore_state = NULL;
struct drm_connector_state *connector_state;
struct intel_crtc_state *crtc_state;
- int ret, i = -1;
+ int ret;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id, connector->name,
@@ -10413,39 +10449,15 @@ retry:
ret = drm_modeset_lock(&crtc->mutex, ctx);
if (ret)
goto fail;
-
- /* Make sure the crtc and connector are running */
- goto found;
- }
-
- /* Find an unused one (if possible) */
- for_each_crtc(dev, possible_crtc) {
- i++;
- if (!(encoder->possible_crtcs & (1 << i)))
- continue;
-
- ret = drm_modeset_lock(&possible_crtc->mutex, ctx);
- if (ret)
+ } else {
+ crtc = intel_get_unused_crtc(encoder, ctx);
+ if (IS_ERR_OR_NULL(crtc)) {
+ ret = PTR_ERR_OR_ZERO(crtc);
+ DRM_DEBUG_KMS("no pipe available for load-detect\n");
goto fail;
-
- if (possible_crtc->state->enable) {
- drm_modeset_unlock(&possible_crtc->mutex);
- continue;
}
-
- crtc = possible_crtc;
- break;
- }
-
- /*
-* If we didn't find an unused CRTC, don't use any.
-*/
- if (!crtc) {
- DRM_DEBUG_KMS("no pipe available for load-detect\n");
- goto fail;
}
-found:
intel_crtc = to_intel_crtc(crtc);
ret = drm_modeset_lock(&crtc->primary->mutex, ctx);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9255b56..3873af5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1152,6 +1152,8 @@ bool intel_get_load_detect_pipe(struct drm_connector
*connector,
void intel_release_load_detect_pipe(struct drm_connector *connector,
struct intel_load_detect_pipe *old,
struct drm_modeset_ac
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT
On Thu, 31 Mar 2016, Shubhangi Shrivastava
wrote:
> This patch sets the invert bit for hpd detection for each port
> based on VBT configuration. Since each AOB can be designed to
> depend on invert bit or not, it is expected if an AOB requires
> invert bit, the user will set respective bit in VBT.
>
> v2: Separated VBT parsing from the rest of the logic. (Jani)
>
> v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
> and changed its logic to avoid looping twice. (Ville)
>
> v4: Changed the logic to mask out the bits first and then
> set them to remove need of temporary variable. (Ville)
>
> v5: Moved defines to existing set of defines for the register
> and added required breaks. (Ville)
>
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Durgadoss R
> Signed-off-by: Shubhangi Shrivastava
> Reviewed-by: Ville Syrjälä
Both pushed to drm-intel-next-queued, thanks for the patch and review.
Although I got a bugzilla reference [1], I managed to not add it to the
commit message. :(
BR,
Jani.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=93915
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_irq.c | 20
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_bios.c | 38 ++
> 4 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 08b88c0..4e8d78a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3378,6 +3378,8 @@ bool intel_bios_is_tv_present(struct drm_i915_private
> *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
> bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
> *port);
> +bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
> + enum port port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a55a7cc..8fbec3e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3504,6 +3504,26 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
> hotplug = I915_READ(PCH_PORT_HOTPLUG);
> hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
> PORTA_HOTPLUG_ENABLE;
> +
> + DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
> + hotplug, enabled_irqs);
> + hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
> +
> + /*
> + * For BXT invert bit has to be set based on AOB design
> + * for HPD detection logic, update it based on VBT fields.
> + */
> +
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
> + intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
> + hotplug |= BXT_DDIA_HPD_INVERT;
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
> + intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
> + hotplug |= BXT_DDIB_HPD_INVERT;
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
> + intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
> + hotplug |= BXT_DDIC_HPD_INVERT;
> +
> I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f3ba43c..73a806c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6185,6 +6185,7 @@ enum skl_disp_power_wells {
> /* digital port hotplug */
> #define PCH_PORT_HOTPLUG _MMIO(0xc4030) /* SHOTPLUG_CTL */
> #define PORTA_HOTPLUG_ENABLE(1 << 28) /* LPT:LP+ & BXT */
> +#define BXT_DDIA_HPD_INVERT(1 << 27)
> #define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
> #define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
> #define PORTA_HOTPLUG_SHORT_DETECT (1 << 24) /* SPT+ & BXT */
> @@ -6200,6 +6201,7 @@ enum skl_disp_power_wells {
> #define PORTD_HOTPLUG_SHORT_DETECT (1 << 16)
> #define PORTD_HOTPLUG_LONG_DETECT (2 << 16)
> #define PORTC_HOTPLUG_ENABLE(1 << 12)
> +#define BXT_DDIC_HPD_INVERT(1 << 11)
> #define PORTC_PULSE_DURATION_2ms(0 << 10) /* pre-LPT */
> #define PORTC_PULSE_DURATION_4_5ms (1 << 10) /* pre-LPT */
> #define PORTC_PULSE_DURATION_6ms(2 << 10) /* pre-LPT */
> @@ -6210,6 +6212,7 @@ enum skl_disp_power_wells {
> #define PORTC_HOTPLUG_SHORT_DETECT (1 << 8)
> #define PORTC_HOTPLUG_LONG_DETECT (2 << 8)
> #define PORTB_HOTPLUG_ENABLE(1 << 4)
> +#define BXT_DDIB_HPD_INVERT(1 << 3)
> #define PORTB_PULSE_DURATION_2ms(0 << 2) /* pre-LPT */
> #define PORTB_PULSE_DURATION_4_5ms (1 << 2) /* pre-LPT */
> #define PORTB_PULSE_DURATION_6ms(2 << 2) /* pre-LPT */
> @@ -
Re: [Intel-gfx] Solving vlv hpd issues by holding power wells?
On Tue, Apr 05, 2016 at 06:01:54PM -0400, Lyude wrote: > Hi. Currently I'm working on a bug in the i915 driver where hotplugging seems > to > break if we power on the machine without any connectors attached: > > https://bugzilla.redhat.com/show_bug.cgi?id=1277863 > > So the main cause of the issue seems to be that we're not keeping the right > power wells on for HPD to work. Booting with say, HDMI, seems to result in the > POWER_DOMAIN_AUDIO domain getting ref'd (even when it's unplugged, which seems > to be another bug in the driver I've seen on a few systems at this point), > which > stops the entire display domain from being shut off and subsequently keeps hpd > working. Without anything plugged in nothing turns on any power wells and the > hpd is non-functional. > > Of course my first thought was to just keep the power wells required for HPD > on > for as long as we have HPD enabled in the driver. I'm not entirely sure of how > this can be done though, as disabling hotplugging interrupts is done in a > context where IRQs are disabled and as such it's impossible to grab a > reference > to the power domain we need since that requires us to grab a mutex. I don't > see > any pre/post uninstall hooks for this either, so just having the power well > turned on and off whenever hpd is toggled doesn't seem very easy. > > On top of this, after talking to a few coworkers I'm not sure if holding a > power > ref as long as hpd interrupts are enabled is the right solution either, since > it > could be costly in terms of power usage. He suggested that I enable polling > for > each connector in the situation where all the power domains are disabled, but > having hotplugging disabled doesn't sound right to me either. > > So I guess my questions are: >1. Should we be falling back to polling when the required power wells for > hotplug detection aren't enabled, instead of keeping them enabled to > make > hotplugging work? >2. If polling isn't the right way to go, what is the best way to go about > keeping a ref to the required power wells and dropping it whenever > hotplugging is disabled? See https://bugs.freedesktop.org/show_bug.cgi?id=89008 for the discussion on different options. -- 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 6/6] drm/i915: Avoid allocating a vmap arena for a single page
On 06/04/16 11:05, Chris Wilson wrote:
On Wed, Apr 06, 2016 at 10:49:36AM +0100, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 985f067c1f0e..dc8e1b76c896 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
list_del(&obj->global_list);
if (obj->vmapping) {
- vunmap(obj->vmapping);
+ if (obj->base.size == PAGE_SIZE)
+ kunmap(kmap_to_page(obj->vmapping));
+ else
+ vunmap(obj->vmapping);
Can't think of a reason why it would be better but there is also
is_vmalloc_addr(addr) as used by kvfree.
For consistency with the shrinker (see below).
obj->vmapping = NULL;
}
@@ -2416,15 +2419,22 @@ void *i915_gem_object_pin_vmap(struct
drm_i915_gem_object *obj)
i915_gem_object_pin_pages(obj);
if (obj->vmapping == NULL) {
- struct sg_page_iter sg_iter;
struct page **pages;
- int n;
- n = obj->base.size >> PAGE_SHIFT;
- pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
+ pages = NULL;
+ if (obj->base.size == PAGE_SIZE)
+ obj->vmapping = kmap(sg_page(obj->pages->sgl));
+ else
+ pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
+ sizeof(*pages),
+ GFP_TEMPORARY);
if (pages != NULL) {
+ struct sg_page_iter sg_iter;
+ int n;
+
n = 0;
- for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
+ for_each_sg_page(obj->pages->sgl, &sg_iter,
+obj->pages->nents, 0)
pages[n++] = sg_page_iter_page(&sg_iter);
obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
Two problems I can spot are:
1. Callers of pin_vmap now don't know which kind of address they are
getting. Maybe call it pin_kvmap or something? Just mention in
kerneldoc could be enough.
I think just mention, and we can rename this to i915_gem_object_pin_map().
Hmm. I liked the pin in the name since it ties to to pin_pages (later
I plan to change that to get_pages and get_vmap/get_map as the pin
becomes implicit).
2. Shrinker will try to kick out kmapped objects because they have
obj->vmapping set.
Not caring that much since the vmap_purge is very heavy weight, but we
can apply is_vmalloc_addr() to the shrinker.
Ok, happy to call this obj->mapping and i915_gem_object_pin_map() ?
Sounds good. (Including the is_vmalloc_addr() smartening in the shrinker.)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Sharing the pixel_format_from_vbt to whole i915
On Wed, 30 Mar 2016, Ramalingam C wrote:
> Shared the function pixel_format_from_vbt for whole display module.
> Function declaration is added to intel_dsi.h.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dsi.h |1 +
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index ec58ead..9612916 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -126,6 +126,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
> drm_encoder *encoder)
> return container_of(encoder, struct intel_dsi, base.base);
> }
>
> +enum mipi_dsi_pixel_format pixel_format_from_vbt(u32 fmt);
> bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
> extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
> extern void intel_disable_dsi_pll(struct intel_encoder *encoder);
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 8302a97..d78d59c 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -413,7 +413,7 @@ static const struct drm_panel_funcs vbt_panel_funcs = {
> };
>
> /* XXX: This should be done when parsing the VBT in intel_bios.c */
> -static enum mipi_dsi_pixel_format pixel_format_from_vbt(u32 fmt)
> +enum mipi_dsi_pixel_format pixel_format_from_vbt(u32 fmt)
I think this one ends up being nicer if you move the whole function to
intel_dsi.c and name it according to being a function to convert the
pixel format from the *register* data, not vbt.
BR,
Jani.
> {
> /* It just so happens the VBT matches register contents. */
> switch (fmt) {
--
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 2/2] drm/i915/BXT: Get pipe conf from the port registers
On Wed, 30 Mar 2016, Ramalingam C wrote:
> At BXT DSI, PIPE registers are inactive. So we can't get the
> PIPE's mode parameters from them. The possible option is
> retriving them from the PORT registers.
>
> The required changes are added for BXT in intel_dsi_get_config
> (encoder->get_config).
>
> v2: Addressed the Jani's comments
> -removed the redundant call to encoder->get_config
> -read bpp from port register
> -removed retrival of src_size from encoder->get_config
>
> Signed-off-by: Ramalingam C
> Signed-off-by: Uma Shankar
> ---
> Previously reviewed at https://patchwork.freedesktop.org/patch/75301/
>
> drivers/gpu/drm/i915/intel_dsi.c | 99
> ++
> 1 file changed, 99 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 0de74e1..2117187 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -46,6 +46,11 @@ static const struct {
> },
> };
>
> +enum mipi_dsi_pixel_format reg_to_pixel_format(u32 fmt)
> +{
> + return pixel_format_from_vbt(fmt);
> +}
> +
See reply to preceding patch.
> static void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port
> port)
> {
> struct drm_encoder *encoder = &intel_dsi->base.base;
> @@ -740,14 +745,108 @@ out_put_power:
> return active;
> }
>
> +/* return pixels equvalent to txbyteclkhs */
> +static u16 pixels_from_txbyteclkhs(u16 clk_hs, int bpp, int lane_count,
> +u16 burst_mode_ratio)
> +{
> + return DIV_ROUND_UP((clk_hs * lane_count * 8 * 100),
> + (bpp * burst_mode_ratio));
> +}
> +
> +static void bxt_dsi_get_pipe_config(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config)
> +{
> + struct drm_device *dev = encoder->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_display_mode *adjusted_mode =
> + &pipe_config->base.adjusted_mode;
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> + unsigned int lane_count = intel_dsi->lane_count;
> + unsigned int bpp, fmt;
> + enum port port;
> + u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
> +
> + /*
> + * Atleast one port is active as encoder->get_config called only if
> + * encoder->get_hw_state() returns true.
> + */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + if (!(I915_READ(BXT_MIPI_PORT_CTRL(port)) & DPI_ENABLE))
> + continue;
> + break;
In other words,
if (I915_READ(BXT_MIPI_PORT_CTRL(port)) & DPI_ENABLE)
break;
> + }
> +
> + fmt = I915_READ(MIPI_DSI_FUNC_PRG(port)) & VID_MODE_FORMAT_MASK;
> + pipe_config->pipe_bpp = reg_to_pixel_format(fmt);
> +
> + bpp = mipi_dsi_pixel_format_to_bpp(pipe_config->pipe_bpp);
> +
> + /* In terms of pixels */
> + adjusted_mode->crtc_hdisplay =
> + I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
> + adjusted_mode->crtc_vdisplay =
> + I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
> + adjusted_mode->crtc_vtotal =
> + I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
> +
> + hactive = adjusted_mode->crtc_hdisplay;
> + hfp = I915_READ(MIPI_HFP_COUNT(port));
> +
> + /*
> + * meaningful for video mode non-burst sync pulse mode only,
> + * can be zero for non-burst sync events and burst modes
> + */
> + hsync = I915_READ(MIPI_HSYNC_PADDING_COUNT(port));
> + hbp = I915_READ(MIPI_HBP_COUNT(port));
> +
> + /* horizontal values are in terms of high speed byte clock */
> + hfp = pixels_from_txbyteclkhs(hfp, bpp, lane_count,
> + intel_dsi->burst_mode_ratio);
> + hsync = pixels_from_txbyteclkhs(hsync, bpp, lane_count,
> + intel_dsi->burst_mode_ratio);
> + hbp = pixels_from_txbyteclkhs(hbp, bpp, lane_count,
> + intel_dsi->burst_mode_ratio);
> +
> + if (intel_dsi->dual_link) {
> + hfp *= 2;
> + hsync *= 2;
> + hbp *= 2;
> + }
> +
> + /* vertical values are in terms of lines */
> + vfp = I915_READ(MIPI_VFP_COUNT(port));
> + vsync = I915_READ(MIPI_VSYNC_PADDING_COUNT(port));
> + vbp = I915_READ(MIPI_VBP_COUNT(port));
> +
> + adjusted_mode->crtc_htotal = hactive + hfp + hsync + hbp;
> + adjusted_mode->crtc_hsync_start =
> + hfp + adjusted_mode->crtc_hdisplay;
> + adjusted_mode->crtc_hsync_end =
> + hsync + adjusted_mode->crtc_hsync_start;
> + adjusted_mode->crtc_hblank_start = adjusted_mode->crtc_hdisplay;
> + adjusted_mode->crtc_hblank_end = adjusted_mode->crtc_htotal;
> +
> + adjusted_mode->crtc_vs
Re: [Intel-gfx] [PATCH 12/12] DO_NOT_MERGE: drm/i915: Hack to enable lspcon initialization
On Mon, 04 Apr 2016, Shashank Sharma wrote:
> This patch adds a hack to enable lspcon on GEN9 devices.
> This should not be merged, and the hack must be replaced
> by proper VBT parsing logic.
>
> Expecting this patch to enable lspcon bits in VBT:
> https://lists.freedesktop.org/archives/intel-gfx/2016-March/089541.html
FYI, an updated version of that patch has been pushed now.
BR,
Jani.
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_ddi.c| 15 +++
> drivers/gpu/drm/i915/intel_drv.h| 4
> drivers/gpu/drm/i915/intel_lspcon.c | 10 ++
> 3 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 91654ff..f6c2869 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2169,6 +2169,21 @@ void intel_ddi_init(struct drm_device *dev, enum port
> port)
> intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
> intel_encoder->cloneable = 0;
>
> +
> + /* Check if LSPCON is configured on this port */
> + if (is_lspcon_present_on_port(dev_priv, intel_dig_port->port)) {
> + if (!intel_lspcon_init_connector(intel_dig_port)) {
> + DRM_DEBUG_KMS("LSPCON configured for port %c\n",
> + port_name(intel_dig_port->port));
> + return;
> + } else {
> + DRM_ERROR("Can't set LSPCON(port %c), falling to
> DP/HDMI\n",
> + port_name(intel_dig_port->port));
> + init_dp = true;
> + init_hdmi = true;
> + }
> + }
> +
> if (init_dp) {
> if (!intel_ddi_init_dp_connector(intel_dig_port))
> goto err;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index a6ec946..922852c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1345,6 +1345,10 @@ void intel_dsi_init(struct drm_device *dev);
> /* intel_dvo.c */
> void intel_dvo_init(struct drm_device *dev);
>
> +/* intel_lspcon.c */
> +int intel_lspcon_init_connector(struct intel_digital_port *intel_dig_port);
> +bool is_lspcon_present_on_port(struct drm_i915_private * dev_priv,
> + enum port port);
>
> /* legacy fbdev emulation in intel_fbdev.c */
> #ifdef CONFIG_DRM_FBDEV_EMULATION
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index 20f90e0..96e4c71 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -397,6 +397,16 @@ static const struct drm_connector_helper_funcs
> lspcon_connector_helper_funcs = {
> .best_encoder = intel_best_encoder,
> };
>
> +bool is_lspcon_present_on_port(struct drm_i915_private *dev_priv, enum port
> port)
> +{
> + /*
> + * TODO: HACK
> + * Replace this with proper VBT child dev config check
> + * logic once that patch is available in tree
> + */
> + return IS_GEN9(dev_priv->dev) && (port == PORT_B);
> +}
> +
> int intel_lspcon_init_connector(struct intel_digital_port *intel_dig_port)
> {
> int ret;
--
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] ✗ Fi.CI.BAT: failure for Add USB typeC based DP support for BXT platform (rev4)
== Series Details == Series: Add USB typeC based DP support for BXT platform (rev4) URL : https://patchwork.freedesktop.org/series/1731/ State : failure == Summary == Series 1731v4 Add USB typeC based DP support for BXT platform http://patchwork.freedesktop.org/api/1.0/series/1731/revisions/4/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (bsw-nuc-2) pass -> SKIP (skl-nuci5) Test gem_ctx_param_basic: Subgroup invalid-ctx-set: dmesg-warn -> PASS (bsw-nuc-2) Test gem_storedw_loop: Subgroup basic-blt: dmesg-fail -> PASS (bsw-nuc-2) Subgroup basic-bsd: skip -> PASS (bsw-nuc-2) Test kms_addfb_basic: Subgroup bad-pitch-128: dmesg-warn -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (bsw-nuc-2) Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:158 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:183 pass:165 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 BOOT FAILED for snb-dellxps Results at /archive/results/CI_IGT_test/Patchwork_1816/ ab13a48af1102b84bdb8dcdfbef1b5b44fab8d3d drm-intel-nightly: 2016y-04m-06d-11h-23m-30s UTC integration manifest 9436c4214ad89a10722251642efb2fd6927726de drm/i915/dp: Enable Upfront link training for typeC DP support on BXT ae288069e18a87dd684ef1e23a8211b857340061 drm/i915: Update dpll_hw_state if mask is same 236693fc96ba3ec44220ff42cde46469608fde08 drm/i915: Store the dpll config in crtc_state->shared_dpll 8ccb190aa0610ac5e4120b755e6f04d058329a2e drm/i915: Make finding unused crtc as a generic function ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/9] drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno
After the GPU reset and we discard all of the incomplete requests, mark the GPU as having advanced to the last_submitted_seqno (as having completed the requests and ready for fresh work). The impact of this is negligible, as all the requests will be considered completed by this point, it just brings the HWS into line with expectations for external viewers. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Joonas Lahtinen Reviewed-by: Mika Kuoppala Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index b342f672f391..05711e7f9fb8 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2882,6 +2882,8 @@ static void i915_gem_reset_engine_cleanup(struct drm_i915_private *dev_priv, buffer->last_retired_head = buffer->tail; intel_ring_update_space(buffer); } + + intel_ring_init_seqno(engine, engine->last_submitted_seqno); } void i915_gem_reset(struct drm_device *dev) -- 2.8.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 8/9] drm/i915: Apply a mb between emitting the request and hangcheck
Seal the request and mark it as pending execution before we submit it to
hardware. We assume that the actual submission cannot fail (that
guarantee is provided by preallocating space in the request for the
submission). As we may inspect this state without holding any locks
during hangcheck we should apply a barrier to ensure that we do
not see a more recent value in the HWS than we are tracking.
Based on a patch by Mika Kuoppala.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 39 ++-
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
2 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7506e850913e..5a65a7663b88 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2575,6 +2575,28 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
WARN(ret, "*_ring_flush_all_caches failed: %d!\n", ret);
}
+ trace_i915_gem_request_add(request);
+
+ request->head = request_start;
+
+ /* Whilst this request exists, batch_obj will be on the
+* active_list, and so will hold the active reference. Only when this
+* request is retired will the the batch_obj be moved onto the
+* inactive_list and lose its active reference. Hence we do not need
+* to explicitly hold another reference here.
+*/
+ request->batch_obj = obj;
+
+ /* Seal the request and mark it as pending execution. Note that
+* we may inspect this state, without holding any locks, during
+* hangcheck. Hence we apply the barrier to ensure that we do not
+* see a more recent value in the hws than we are tracking.
+*/
+ request->emitted_jiffies = jiffies;
+ request->previous_seqno = engine->last_submitted_seqno;
+ smp_store_mb(engine->last_submitted_seqno, request->seqno);
+ list_add_tail(&request->list, &engine->request_list);
+
/* Record the position of the start of the request so that
* should we detect the updated seqno part-way through the
* GPU processing the request, we never over-estimate the
@@ -2592,23 +2614,6 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
/* Not allowed to fail! */
WARN(ret, "emit|add_request failed: %d!\n", ret);
- request->head = request_start;
-
- /* Whilst this request exists, batch_obj will be on the
-* active_list, and so will hold the active reference. Only when this
-* request is retired will the the batch_obj be moved onto the
-* inactive_list and lose its active reference. Hence we do not need
-* to explicitly hold another reference here.
-*/
- request->batch_obj = obj;
-
- request->emitted_jiffies = jiffies;
- request->previous_seqno = engine->last_submitted_seqno;
- engine->last_submitted_seqno = request->seqno;
- list_add_tail(&request->list, &engine->request_list);
-
- trace_i915_gem_request_add(request);
-
i915_queue_hangcheck(engine->dev);
queue_delayed_work(dev_priv->wq,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5bec13844800..a5eb77d1f8cb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2806,7 +2806,8 @@ static bool
ring_idle(struct intel_engine_cs *engine, u32 seqno)
{
return (list_empty(&engine->request_list) ||
- i915_seqno_passed(seqno, engine->last_submitted_seqno));
+ i915_seqno_passed(seqno,
+ READ_ONCE(engine->last_submitted_seqno)));
}
static bool
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/9] drm/i915: Refactor gen8 semaphore offset calculation
We reuse the same calculation into two macros, and I want to add a third
user. Time to refactor.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 18074ab55f61..98eadfa79116 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -52,16 +52,15 @@ struct intel_hw_status_page {
/* seqno size is actually only a uint32, but since we plan to use MI_FLUSH_DW
to
* do the writes, and that must have qw aligned offsets, simply pretend it's
8b.
*/
-#define i915_semaphore_seqno_size sizeof(uint64_t)
+#define gen8_semaphore_seqno_size sizeof(uint64_t)
+#define GEN8_SEMAPHORE_OFFSET(__from, __to) \
+ (((__from) * I915_NUM_ENGINES + (__to)) * gen8_semaphore_seqno_size)
#define GEN8_SIGNAL_OFFSET(__ring, to) \
(i915_gem_obj_ggtt_offset(dev_priv->semaphore_obj) + \
- ((__ring)->id * I915_NUM_ENGINES * i915_semaphore_seqno_size) + \
- (i915_semaphore_seqno_size * (to)))
-
+GEN8_SEMAPHORE_OFFSET((__ring)->id, (to)))
#define GEN8_WAIT_OFFSET(__ring, from) \
(i915_gem_obj_ggtt_offset(dev_priv->semaphore_obj) + \
- ((from) * I915_NUM_ENGINES * i915_semaphore_seqno_size) + \
- (i915_semaphore_seqno_size * (__ring)->id))
+GEN8_SEMAPHORE_OFFSET(from, (__ring)->id))
#define GEN8_RING_SEMAPHORE_INIT(e) do { \
if (!dev_priv->semaphore_obj) { \
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/9] drm/i915: Reset engine->last_submitted_seqno
When we change the current seqno, we also need to remember to reset the last_submitted_seqno for the engine. Testcase: igt/gem_exec_whisper Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Joonas Lahtinen Reviewed-by: Mika Kuoppala Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 0e6490074011..6b4952031e30 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -2578,6 +2578,7 @@ void intel_ring_init_seqno(struct intel_engine_cs *engine, u32 seqno) sizeof(engine->semaphore.sync_seqno)); engine->set_seqno(engine, seqno); + engine->last_submitted_seqno = seqno; engine->hangcheck.seqno = seqno; } -- 2.8.0.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/9] drm/i915: Remove unneeded drm_device pointer from intel_ring_init_seqno()
We only use drm_i915_private within the function, so delete the unneeded
drm_device local.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2e864b7a528b..371f4c1fc33c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2550,13 +2550,12 @@ int intel_ring_cacheline_align(struct
drm_i915_gem_request *req)
void intel_ring_init_seqno(struct intel_engine_cs *engine, u32 seqno)
{
- struct drm_device *dev = engine->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = to_i915(engine->dev);
- if (INTEL_INFO(dev)->gen == 6 || INTEL_INFO(dev)->gen == 7) {
+ if (INTEL_INFO(dev_priv)->gen == 6 || INTEL_INFO(dev_priv)->gen == 7) {
I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
- if (HAS_VEBOX(dev))
+ if (HAS_VEBOX(dev_priv))
I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
}
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/9] drm/i915: Move the hw semaphore initialisation from GEM to the engine
Since we are setting engine local values that are tied to the hardware,
move it out of i915_gem_init_seqno() into the intel_ring_init_seqno()
backend, next to where the other hw semaphore registers are written.
v2: Make the explanatory comment about always resetting the semaphores to
0 irrespective of the value of the reset seqno.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 8 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 +++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 05711e7f9fb8..7506e850913e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2468,7 +2468,7 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
- int ret, j;
+ int ret;
/* Carefully retire all requests without writing to the rings */
for_each_engine(engine, dev_priv) {
@@ -2479,13 +2479,9 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
i915_gem_retire_requests(dev);
/* Finally reset hw state */
- for_each_engine(engine, dev_priv) {
+ for_each_engine(engine, dev_priv)
intel_ring_init_seqno(engine, seqno);
- for (j = 0; j < ARRAY_SIZE(engine->semaphore.sync_seqno); j++)
- engine->semaphore.sync_seqno[j] = 0;
- }
-
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 371f4c1fc33c..69852ac4018d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2552,14 +2552,25 @@ void intel_ring_init_seqno(struct intel_engine_cs
*engine, u32 seqno)
{
struct drm_i915_private *dev_priv = to_i915(engine->dev);
+ /* Our semaphore implementation is strictly monotonic (i.e. we proceed
+* so long as the semaphore value in the register/page is greater
+* than the sync value), so whenever we reset the seqno,
+* so long as we reset the tracking semaphore value to 0, it will
+* always be before the next request's seqno. If we don't reset
+* the semaphore value, then when the seqno moves backwards all
+* future waits will complete instantly (causing rendering corruption).
+*/
if (INTEL_INFO(dev_priv)->gen == 6 || INTEL_INFO(dev_priv)->gen == 7) {
I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
if (HAS_VEBOX(dev_priv))
I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
}
+ memset(engine->semaphore.sync_seqno, 0,
+ sizeof(engine->semaphore.sync_seqno));
engine->set_seqno(engine, seqno);
+
engine->hangcheck.seqno = seqno;
}
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/9] drm/i915: Include engine->last_submitted_seqno in GPU error state
It's useful to look at the last seqno submitted on a particular engine
and compare it against the HWS value to check for irregularities.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 --
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af02c292..906e5424e488 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1363,8 +1363,10 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
for_each_engine_id(engine, dev_priv, id) {
seq_printf(m, "%s:\n", engine->name);
- seq_printf(m, "\tseqno = %x [current %x]\n",
- engine->hangcheck.seqno, seqno[id]);
+ seq_printf(m, "\tseqno = %x [current %x, last %x]\n",
+ engine->hangcheck.seqno,
+ seqno[id],
+ engine->last_submitted_seqno);
seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
(long long)engine->hangcheck.acthd,
(long long)acthd[id]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1f78f275c55..c7ce452d35ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -495,6 +495,7 @@ struct drm_i915_error_state {
u32 cpu_ring_head;
u32 cpu_ring_tail;
+ u32 last_seqno;
u32 semaphore_seqno[I915_NUM_ENGINES - 1];
/* Register state */
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9b55409d91b3..9463cb4e9323 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -296,6 +296,7 @@ static void i915_ring_error_state(struct
drm_i915_error_state_buf *m,
}
}
err_printf(m, " seqno: 0x%08x\n", ring->seqno);
+ err_printf(m, " last_seqno: 0x%08x\n", ring->last_seqno);
err_printf(m, " waiting: %s\n", yesno(ring->waiting));
err_printf(m, " ring->head: 0x%08x\n", ring->cpu_ring_head);
err_printf(m, " ring->tail: 0x%08x\n", ring->cpu_ring_tail);
@@ -931,6 +932,7 @@ static void i915_record_ring_state(struct drm_device *dev,
ering->instpm = I915_READ(RING_INSTPM(engine->mmio_base));
ering->seqno = engine->get_seqno(engine, false);
ering->acthd = intel_ring_get_active_head(engine);
+ ering->last_seqno = engine->last_submitted_seqno;
ering->start = I915_READ_START(engine);
ering->head = I915_READ_HEAD(engine);
ering->tail = I915_READ_TAIL(engine);
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 9/9] drm/i915: Simplify check for idleness in hangcheck
Having fixed the tracking of the engine's last_submitted_seqno, we can
now rely on it for detecting when the engine is idle (and not have to
touch the requests pointer).
Testcase: igt/gem_exec_whisper
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_irq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a5eb77d1f8cb..5007cde8d4c3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2805,9 +2805,8 @@ static void gen8_disable_vblank(struct drm_device *dev,
unsigned int pipe)
static bool
ring_idle(struct intel_engine_cs *engine, u32 seqno)
{
- return (list_empty(&engine->request_list) ||
- i915_seqno_passed(seqno,
- READ_ONCE(engine->last_submitted_seqno)));
+ return i915_seqno_passed(seqno,
+READ_ONCE(engine->last_submitted_seqno));
}
static bool
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/9] drm/i915: Reset semaphore page for gen8
An oversight is that when we wrap the seqno, we need to reset the hw
semaphore counters to 0. We did this for gen6 and gen7 and forgot to do
so for the new implementation required for gen8 (legacy).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 69852ac4018d..0e6490074011 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2566,6 +2566,14 @@ void intel_ring_init_seqno(struct intel_engine_cs
*engine, u32 seqno)
if (HAS_VEBOX(dev_priv))
I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
}
+ if (dev_priv->semaphore_obj) {
+ struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
+ struct page *page = i915_gem_object_get_dirty_page(obj, 0);
+ void *semaphores = kmap(page);
+ memset(semaphores + GEN8_SEMAPHORE_OFFSET(engine->id, 0),
+ 0, I915_NUM_ENGINES * gen8_semaphore_seqno_size);
+ kunmap(page);
+ }
memset(engine->semaphore.sync_seqno, 0,
sizeof(engine->semaphore.sync_seqno));
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] DO_NOT_MERGE: drm/i915: Hack to enable lspcon initialization
Regards
Shashank
Expecting this patch to enable lspcon bits in VBT:
https://lists.freedesktop.org/archives/intel-gfx/2016-March/089541.html
FYI, an updated version of that patch has been pushed now.
BR,
Jani.
Thanks Jani, will have a look.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c| 15 +++
drivers/gpu/drm/i915/intel_drv.h| 4
drivers/gpu/drm/i915/intel_lspcon.c | 10 ++
3 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 91654ff..f6c2869 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2169,6 +2169,21 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
+
+ /* Check if LSPCON is configured on this port */
+ if (is_lspcon_present_on_port(dev_priv, intel_dig_port->port)) {
+ if (!intel_lspcon_init_connector(intel_dig_port)) {
+ DRM_DEBUG_KMS("LSPCON configured for port %c\n",
+ port_name(intel_dig_port->port));
+ return;
+ } else {
+ DRM_ERROR("Can't set LSPCON(port %c), falling to
DP/HDMI\n",
+ port_name(intel_dig_port->port));
+ init_dp = true;
+ init_hdmi = true;
+ }
+ }
+
if (init_dp) {
if (!intel_ddi_init_dp_connector(intel_dig_port))
goto err;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a6ec946..922852c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1345,6 +1345,10 @@ void intel_dsi_init(struct drm_device *dev);
/* intel_dvo.c */
void intel_dvo_init(struct drm_device *dev);
+/* intel_lspcon.c */
+int intel_lspcon_init_connector(struct intel_digital_port *intel_dig_port);
+bool is_lspcon_present_on_port(struct drm_i915_private * dev_priv,
+ enum port port);
/* legacy fbdev emulation in intel_fbdev.c */
#ifdef CONFIG_DRM_FBDEV_EMULATION
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
b/drivers/gpu/drm/i915/intel_lspcon.c
index 20f90e0..96e4c71 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -397,6 +397,16 @@ static const struct drm_connector_helper_funcs
lspcon_connector_helper_funcs = {
.best_encoder = intel_best_encoder,
};
+bool is_lspcon_present_on_port(struct drm_i915_private *dev_priv, enum port
port)
+{
+ /*
+ * TODO: HACK
+ * Replace this with proper VBT child dev config check
+ * logic once that patch is available in tree
+ */
+ return IS_GEN9(dev_priv->dev) && (port == PORT_B);
+}
+
int intel_lspcon_init_connector(struct intel_digital_port *intel_dig_port)
{
int ret;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page
On 06/04/16 11:05, Chris Wilson wrote:
On Wed, Apr 06, 2016 at 10:49:36AM +0100, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 985f067c1f0e..dc8e1b76c896 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
list_del(&obj->global_list);
if (obj->vmapping) {
- vunmap(obj->vmapping);
+ if (obj->base.size == PAGE_SIZE)
+ kunmap(kmap_to_page(obj->vmapping));
+ else
+ vunmap(obj->vmapping);
Can't think of a reason why it would be better but there is also
is_vmalloc_addr(addr) as used by kvfree.
For consistency with the shrinker (see below).
What I don't like here is the repetition (and correlation) of the
PAGE_SIZE test, which has to be kept in sync with the corresponding one
at the point where the mapping was set up. If we're going to overload
the same field to store two different types of mapping, there should be
an explicit flag to say which we chose. Or failing that, then actually
test the mapping itself (as in is_vmalloc_addr()).
obj->vmapping = NULL;
}
@@ -2416,15 +2419,22 @@ void *i915_gem_object_pin_vmap(struct
drm_i915_gem_object *obj)
i915_gem_object_pin_pages(obj);
if (obj->vmapping == NULL) {
- struct sg_page_iter sg_iter;
struct page **pages;
- int n;
- n = obj->base.size >> PAGE_SHIFT;
- pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
+ pages = NULL;
+ if (obj->base.size == PAGE_SIZE)
+ obj->vmapping = kmap(sg_page(obj->pages->sgl));
+ else
+ pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
+ sizeof(*pages),
+ GFP_TEMPORARY);
if (pages != NULL) {
+ struct sg_page_iter sg_iter;
+ int n;
+
n = 0;
- for_each_sg_page(obj->pages->sgl, &sg_iter,
obj->pages->nents, 0)
+ for_each_sg_page(obj->pages->sgl, &sg_iter,
+obj->pages->nents, 0)
pages[n++] = sg_page_iter_page(&sg_iter);
obj->vmapping = vmap(pages, n, 0, PAGE_KERNEL);
Two problems I can spot are:
1. Callers of pin_vmap now don't know which kind of address they are
getting. Maybe call it pin_kvmap or something? Just mention in
kerneldoc could be enough.
I think just mention, and we can rename this to i915_gem_object_pin_map().
Hmm. I liked the pin in the name since it ties to to pin_pages (later
I plan to change that to get_pages and get_vmap/get_map as the pin
becomes implicit).
2. Shrinker will try to kick out kmapped objects because they have
obj->vmapping set.
Not caring that much since the vmap_purge is very heavy weight, but we
can apply is_vmalloc_addr() to the shrinker.
Ok, happy to call this obj->mapping and i915_gem_object_pin_map() ?
-Chris
Quite happy with the rename, and returning either type (a (virtual)
address is just an address), but not with the implementation repeating
the decision code.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly
On Wed, Apr 06, 2016 at 01:28:25PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 05, 2016 at 02:55:51PM -0700, Matt Roper wrote:
> > On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote:
> > > intel_update_max_cdclk() doesn't have a switch case for Broxton, so
> > > dev_priv->max_cdclk_freq gets set to whatever clock frequency we're
> > > currently running at (e.g., 144 MHz) rather than the true maximum. This
> > > causes our max dotclock to also be set too low and in turn leads mode
> > > verification to reject perfectly valid modes while loading EDID firmware
> > > blobs.
> > >
> > > Cc: Imre Deak
> > > Signed-off-by: Matt Roper
> > > ---
> >
> > One thing I should have mentioned is that it's unclear to me whether we
> > should be looking at the cdclk limit bits in the DFSM register like we
> > do on SKL/KBL. The bspec seems to indicate that the register in general
> > applies to gen9, including BXT, but the actual meaning of the bits
> > doesn't match up with the frequencies we have on BXT.
>
> It also says
> "This field is unused on BXT. Any CD clock frequency limitation must be
> done in software."
>
> Anyway the DFSM story is apparently a sad one. See the discussion eg. in
> https://lists.freedesktop.org/archives/intel-gfx/2016-February/087510.html
> would be nice if someone could pick that up and figure out what we really
> want/need to do.
Oh strange; the note about being unused for BXT gets hidden if you're
filtering the bspec on BXT. I have to remove the filter to see it.
Seems a bit backwards...
Thanks for the confirmation and background.
Matt
>
> >
> >
> > Matt
> >
> > > drivers/gpu/drm/i915/intel_display.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index af74cdb..924d851 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -5261,6 +5261,8 @@ static void intel_update_max_cdclk(struct
> > > drm_device *dev)
> > > dev_priv->max_cdclk_freq = 45;
> > > else
> > > dev_priv->max_cdclk_freq = 337500;
> > > + } else if (IS_BROXTON(dev)) {
> > > + dev_priv->max_cdclk_freq = 624000;
> > > } else if (IS_BROADWELL(dev)) {
> > > /*
> > >* FIXME with extra cooling we can allow
> > > --
> > > 2.1.4
> > >
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > IoTG Platform Enabling & Development
> > Intel Corporation
> > (916) 356-2795
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/fbc: sanitize i915.enable_fbc during FBC init
On Mon, Apr 04, 2016 at 06:17:16PM -0300, Paulo Zanoni wrote:
> The DDX driver changes its behavior depending on the value it reads
> from i915.enable_fbc, so sanitize the value in order to allow it to
> know what's going on. It uses this in order to choose the defaults for
> the TearFree option. Before this patch, it will read -1 and always
> assume that FBC is disabled, so it won't force TearFree.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index fc3c094..3d84ce3 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -824,21 +824,14 @@ 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);
>
> if (intel_vgpu_active(dev_priv->dev)) {
> fbc->no_fbc_reason = "VGPU is active";
> return false;
> }
>
> - if (i915.enable_fbc < 0 && !enable_by_default) {
> - fbc->no_fbc_reason = "disabled per chip default";
> - return false;
> - }
> -
> if (!i915.enable_fbc) {
> - fbc->no_fbc_reason = "disabled per module param";
> + fbc->no_fbc_reason = "disabled per module param or by default";
> return false;
> }
>
> @@ -1240,6 +1233,16 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
> fbc->active = false;
> fbc->work.scheduled = false;
>
> + /* The DDX driver changes its behavior depending on the value it reads
> + * from i915.enable_fbc, so sanitize the value in order to allow it to
> + * know what's going on. */
> + if (i915.enable_fbc < 0) {
> + i915.enable_fbc = IS_HASWELL(dev_priv) ||
> + IS_BROADWELL(dev_priv);
> + DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n",
> + i915.enable_fbc);
> + }
Standard practice would be to call intel_sanitize_fbc().
i915.enable_fbc = intel_sanitize_fbc(dev_priv);
if (!i915.enable_fbc))
> fbc->no_fbc_reason = "unsupported by this chipset";
> return;
}
-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 v2 8/9] drm/i915: Apply a mb between emitting the request and hangcheck
Chris Wilson writes:
> [ text/plain ]
> Seal the request and mark it as pending execution before we submit it to
> hardware. We assume that the actual submission cannot fail (that
> guarantee is provided by preallocating space in the request for the
> submission). As we may inspect this state without holding any locks
> during hangcheck we should apply a barrier to ensure that we do
> not see a more recent value in the HWS than we are tracking.
>
> Based on a patch by Mika Kuoppala.
>
> Suggested-by: Mika Kuoppala
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.c | 39 ++-
> drivers/gpu/drm/i915/i915_irq.c | 3 ++-
> 2 files changed, 24 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7506e850913e..5a65a7663b88 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2575,6 +2575,28 @@ void __i915_add_request(struct drm_i915_gem_request
> *request,
> WARN(ret, "*_ring_flush_all_caches failed: %d!\n", ret);
> }
>
> + trace_i915_gem_request_add(request);
> +
> + request->head = request_start;
> +
> + /* Whilst this request exists, batch_obj will be on the
> + * active_list, and so will hold the active reference. Only when this
> + * request is retired will the the batch_obj be moved onto the
> + * inactive_list and lose its active reference. Hence we do not need
> + * to explicitly hold another reference here.
> + */
> + request->batch_obj = obj;
> +
> + /* Seal the request and mark it as pending execution. Note that
> + * we may inspect this state, without holding any locks, during
> + * hangcheck. Hence we apply the barrier to ensure that we do not
> + * see a more recent value in the hws than we are tracking.
> + */
> + request->emitted_jiffies = jiffies;
> + request->previous_seqno = engine->last_submitted_seqno;
> + smp_store_mb(engine->last_submitted_seqno, request->seqno);
> + list_add_tail(&request->list, &engine->request_list);
> +
> /* Record the position of the start of the request so that
>* should we detect the updated seqno part-way through the
>* GPU processing the request, we never over-estimate the
> @@ -2592,23 +2614,6 @@ void __i915_add_request(struct drm_i915_gem_request
> *request,
> /* Not allowed to fail! */
> WARN(ret, "emit|add_request failed: %d!\n", ret);
>
> - request->head = request_start;
> -
> - /* Whilst this request exists, batch_obj will be on the
> - * active_list, and so will hold the active reference. Only when this
> - * request is retired will the the batch_obj be moved onto the
> - * inactive_list and lose its active reference. Hence we do not need
> - * to explicitly hold another reference here.
> - */
> - request->batch_obj = obj;
> -
> - request->emitted_jiffies = jiffies;
> - request->previous_seqno = engine->last_submitted_seqno;
> - engine->last_submitted_seqno = request->seqno;
> - list_add_tail(&request->list, &engine->request_list);
> -
> - trace_i915_gem_request_add(request);
> -
> i915_queue_hangcheck(engine->dev);
>
> queue_delayed_work(dev_priv->wq,
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 5bec13844800..a5eb77d1f8cb 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2806,7 +2806,8 @@ static bool
> ring_idle(struct intel_engine_cs *engine, u32 seqno)
> {
> return (list_empty(&engine->request_list) ||
> - i915_seqno_passed(seqno, engine->last_submitted_seqno));
> + i915_seqno_passed(seqno,
> + READ_ONCE(engine->last_submitted_seqno)));
> }
>
> static bool
> --
> 2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Simplify check for idleness in hangcheck
Chris Wilson writes:
> [ text/plain ]
> Having fixed the tracking of the engine's last_submitted_seqno, we can
> now rely on it for detecting when the engine is idle (and not have to
> touch the requests pointer).
>
> Testcase: igt/gem_exec_whisper
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a5eb77d1f8cb..5007cde8d4c3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2805,9 +2805,8 @@ static void gen8_disable_vblank(struct drm_device *dev,
> unsigned int pipe)
> static bool
> ring_idle(struct intel_engine_cs *engine, u32 seqno)
> {
> - return (list_empty(&engine->request_list) ||
> - i915_seqno_passed(seqno,
> - READ_ONCE(engine->last_submitted_seqno)));
> + return i915_seqno_passed(seqno,
> + READ_ONCE(engine->last_submitted_seqno));
> }
>
> static bool
> --
> 2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Enable FBC on SKL, v3
Em Qua, 2016-04-06 às 10:36 +0530, Thulasimani, Sivakumar escreveu: > dont want to hijack thread but wanted to point out a possible > regression > in the > previous patches of this series. > > intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug) How? It will check for i915.enable_fbc, which will have been sanitized to zero on these platforms. Aren't you explicitly enabling FBC on these platforms by using i915.enable_fbc=1? > > so intel_crtc_state->enable_fbc = true; will be executed for first > crtc > everytime intel_fbc_choose_crtc is called. Although there is check to > handle fbc already enabled, it may fail when we fbc is disabled and > we are working on non supported panel. > > regards, > Sivakumar > > On 4/5/2016 2:47 AM, Paulo Zanoni wrote: > > > > Now with the suggestion from Chris instead of the old workaround. > > We don't need > > new DDX patches anymore, but now we need new IGT patches. > > > > Chris Wilson (1): > > drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC > > mmaps > > > > Paulo Zanoni (3): > > drm/i915/fbc: update busy_bits even for GTT and flip flushes > > drm/i915/fbc: sanitize i915.enable_fbc during FBC init > > drm/i915/fbc: enable FBC on gen 9+ too > > > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > drivers/gpu/drm/i915/i915_gem.c | 14 +++--- > > drivers/gpu/drm/i915/intel_fbc.c | 27 --- > > 3 files changed, 28 insertions(+), 14 deletions(-) > > > ___ > 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] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect
On 04/04/16 12:41, Tvrtko Ursulin wrote: On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect URL : https://patchwork.freedesktop.org/series/5044/ State : success I pushed those to dinq. This series seems to break eDP detection on BDW RVP. I presume this is due to the sink count check. Can you add debug logging to print intel_dp->sink_count after it's been read in intel_dp_get_dpcd() please? intel_dp->sink_count is zero here. (raw value, before the DP_GET_SINK_COUNT.) Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage with not overly confident wording for the workaround there. Then the question is, is this just because you have an RVP with who knows what panel, or do we have to take into account potentially broken panels too? Then I assume the fix would be to to ignore sink count for eDP. No idea. :) I could really use a solution for this. My only development platform is incapacitated unless I revert this series which, apart from the extra work when preparing and sending out patches this is taking, including lost time waiting on CI which I suspect dislikes patches from top of unknown bases, I think it won't be so easy to continue doing so when the conflicts start arriving. :( Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Only grab correct forcewake for the engine with execlists
From: Tvrtko Ursulin
Rather than blindly waking up all forcewake domains on command
submission, we can teach each engine what is (or are) the correct
one to take.
On platforms with multiple forcewake domains like VLV, CHV, SKL
and BXT, this has the potential of lowering the GPU and CPU power
use and submission latency.
To implement it, we extract the code which holds the built in
knowledge on which forcewake domains are applicable for each
registers from the MMIO accessors into separate macros, and
implement two new functions named intel_reg_read_fw_domains and
intel_reg_read_fw_domains.
These enables callers, in this case the execlists engine setup
code, to query which forcewake domains are relevant per engine
on the currently running platform.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 6 +
drivers/gpu/drm/i915/intel_lrc.c| 18 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 306 +---
4 files changed, 226 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1f78f275c55..311217e7f917 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -633,6 +633,12 @@ enum forcewake_domains {
FORCEWAKE_MEDIA)
};
+enum forcewake_domains
+intel_reg_read_fw_domains(struct drm_i915_private *dev_priv, i915_reg_t reg);
+
+enum forcewake_domains
+intel_reg_write_fw_domains(struct drm_i915_private *dev_priv, i915_reg_t reg);
+
struct intel_uncore_funcs {
void (*force_wake_get)(struct drm_i915_private *dev_priv,
enum forcewake_domains
domains);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a1db6a02cf23..cac387f38cf6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -418,6 +418,7 @@ static void execlists_submit_requests(struct
drm_i915_gem_request *rq0,
struct drm_i915_gem_request *rq1)
{
struct drm_i915_private *dev_priv = rq0->i915;
+ unsigned int fw_domains = rq0->engine->fw_domains_elsp;
execlists_update_context(rq0);
@@ -425,11 +426,11 @@ static void execlists_submit_requests(struct
drm_i915_gem_request *rq0,
execlists_update_context(rq1);
spin_lock_irq(&dev_priv->uncore.lock);
- intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
+ intel_uncore_forcewake_get__locked(dev_priv, fw_domains);
execlists_elsp_write(rq0, rq1);
- intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
+ intel_uncore_forcewake_put__locked(dev_priv, fw_domains);
spin_unlock_irq(&dev_priv->uncore.lock);
}
@@ -552,7 +553,7 @@ static void intel_lrc_irq_handler(unsigned long data)
unsigned int csb_read = 0, i;
unsigned int submit_contexts = 0;
- intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ intel_uncore_forcewake_get(dev_priv, engine->fw_domains_csb);
status_pointer = I915_READ_FW(RING_CONTEXT_STATUS_PTR(engine));
@@ -577,7 +578,7 @@ static void intel_lrc_irq_handler(unsigned long data)
_MASKED_FIELD(GEN8_CSB_READ_PTR_MASK,
engine->next_context_status_buffer << 8));
- intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ intel_uncore_forcewake_put(dev_priv, engine->fw_domains_csb);
spin_lock(&engine->execlist_lock);
@@ -2077,7 +2078,8 @@ logical_ring_default_irqs(struct intel_engine_cs *engine,
unsigned shift)
static int
logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine)
{
- struct intel_context *dctx = to_i915(dev)->kernel_context;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_context *dctx = dev_priv->kernel_context;
int ret;
/* Intentionally left blank. */
@@ -2099,6 +2101,12 @@ logical_ring_init(struct drm_device *dev, struct
intel_engine_cs *engine)
logical_ring_init_platform_invariants(engine);
+ engine->fw_domains_elsp =
+ intel_reg_write_fw_domains(dev_priv, RING_ELSP(engine));
+ engine->fw_domains_csb =
+ intel_reg_write_fw_domains(dev_priv,
+ RING_CONTEXT_STATUS_PTR(engine));
+
ret = i915_cmd_parser_init_ring(engine);
if (ret)
goto error;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 18074ab55f61..fd248cde7164 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -270,6 +270,7 @@ struct intel_engine_cs {
spinlock_t execlist_lock; /* used inside tasklet, use spin_lock_bh */
struct list_head execlist_queue;
struct list_he
Re: [Intel-gfx] [PATCH 04/16] drm/i915/skl+: Use plane size for relative data rate calculation
On to, 2016-03-31 at 18:46 -0700, Matt Roper wrote:
> From: "Kumar, Mahesh"
>
> Use plane size for relative data rate calculation. don't always use
> pipe source width & height.
> adjust height & width according to rotation.
> use plane size for watermark calculations also.
>
> v2: Address Matt's comments.
> Use intel_plane_state->visible to avoid divide-by-zero error.
> Where FB was present but not visible so causing total data rate
> to
> be zero, hence divide-by-zero.
>
> Cc: matthew.d.ro...@intel.com
> Signed-off-by: Kumar, Mahesh
> Reviewed-by: Matt Roper
> Signed-off-by: Matt Roper
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=93917
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=94044
This patch fixed a screen corruption problem for me with an eDP + DP
config. It somehow made worse by moving the cursor around and I can get
rid of it by switching of the cursor plane.
Matt any chance of getting this merged separately from the rest?
--Imre
> ---
> drivers/gpu/drm/i915/intel_pm.c | 41 ---
> --
> 1 file changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index c970c4e..1c3f772 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2937,24 +2937,28 @@ skl_plane_relative_data_rate(const struct
> intel_crtc_state *cstate,
> const struct drm_plane_state *pstate,
> int y)
> {
> - struct intel_crtc *intel_crtc = to_intel_crtc(cstate-
> >base.crtc);
> + struct intel_plane_state *intel_pstate =
> to_intel_plane_state(pstate);
> struct drm_framebuffer *fb = pstate->fb;
> + uint32_t width = 0, height = 0;
> +
> + width = drm_rect_width(&intel_pstate->src) >> 16;
> + height = drm_rect_height(&intel_pstate->src) >> 16;
> +
> + if (intel_rotation_90_or_270(pstate->rotation))
> + swap(width, height);
>
> /* for planar format */
> if (fb->pixel_format == DRM_FORMAT_NV12) {
> if (y) /* y-plane data rate */
> - return intel_crtc->config->pipe_src_w *
> - intel_crtc->config->pipe_src_h *
> + return width * height *
> drm_format_plane_cpp(fb-
> >pixel_format, 0);
> else/* uv-plane data rate */
> - return (intel_crtc->config->pipe_src_w/2) *
> - (intel_crtc->config->pipe_src_h/2) *
> + return (width / 2) * (height / 2) *
> drm_format_plane_cpp(fb-
> >pixel_format, 1);
> }
>
> /* for packed formats */
> - return cstate->pipe_src_w * cstate->pipe_src_h *
> - drm_format_plane_cpp(fb->pixel_format, 0);
> + return width * height * drm_format_plane_cpp(fb-
> >pixel_format, 0);
> }
>
> /*
> @@ -3033,8 +3037,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> *cstate,
> struct drm_framebuffer *fb = plane->state->fb;
> int id = skl_wm_plane_id(intel_plane);
>
> - if (fb == NULL)
> + if (!to_intel_plane_state(plane->state)->visible)
> continue;
> +
> if (plane->type == DRM_PLANE_TYPE_CURSOR)
> continue;
>
> @@ -3060,7 +3065,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> *cstate,
> uint16_t plane_blocks, y_plane_blocks = 0;
> int id = skl_wm_plane_id(intel_plane);
>
> - if (pstate->fb == NULL)
> + if (!to_intel_plane_state(pstate)->visible)
> continue;
> if (plane->type == DRM_PLANE_TYPE_CURSOR)
> continue;
> @@ -3183,26 +3188,36 @@ static bool skl_compute_plane_wm(const struct
> drm_i915_private *dev_priv,
> {
> struct drm_plane *plane = &intel_plane->base;
> struct drm_framebuffer *fb = plane->state->fb;
> + struct intel_plane_state *intel_pstate =
> + to_intel_plane_state(plane-
> >state);
> uint32_t latency = dev_priv->wm.skl_latency[level];
> uint32_t method1, method2;
> uint32_t plane_bytes_per_line, plane_blocks_per_line;
> uint32_t res_blocks, res_lines;
> uint32_t selected_result;
> uint8_t cpp;
> + uint32_t width = 0, height = 0;
>
> - if (latency == 0 || !cstate->base.active || !fb)
> + if (latency == 0 || !cstate->base.active || !intel_pstate-
> >visible)
> return false;
>
> + width = drm_rect_width(&intel_pstate->src) >> 16;
> + height = drm_rect_height(&intel_pstate->src) >> 16;
> +
> + if (intel_rotation_90_or_270(plane->state->rotation))
> + swap(width, height);
> +
> cpp = drm_format_plane_cpp(fb->pixel_format, 0);
> method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate),
>
Re: [Intel-gfx] [PATCH] drm/i915: Only grab correct forcewake for the engine with execlists
On Wed, Apr 06, 2016 at 03:49:55PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Rather than blindly waking up all forcewake domains on command
> submission, we can teach each engine what is (or are) the correct
> one to take.
>
> On platforms with multiple forcewake domains like VLV, CHV, SKL
> and BXT, this has the potential of lowering the GPU and CPU power
> use and submission latency.
>
> To implement it, we extract the code which holds the built in
> knowledge on which forcewake domains are applicable for each
> registers from the MMIO accessors into separate macros, and
> implement two new functions named intel_reg_read_fw_domains and
> intel_reg_read_fw_domains.
>
> These enables callers, in this case the execlists engine setup
> code, to query which forcewake domains are relevant per engine
> on the currently running platform.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 6 +
> drivers/gpu/drm/i915/intel_lrc.c| 18 +-
> drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
> drivers/gpu/drm/i915/intel_uncore.c | 306
> +---
> 4 files changed, 226 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a1f78f275c55..311217e7f917 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -633,6 +633,12 @@ enum forcewake_domains {
>FORCEWAKE_MEDIA)
> };
>
> +enum forcewake_domains
> +intel_reg_read_fw_domains(struct drm_i915_private *dev_priv, i915_reg_t reg);
> +
> +enum forcewake_domains
> +intel_reg_write_fw_domains(struct drm_i915_private *dev_priv, i915_reg_t
> reg);
> +
> struct intel_uncore_funcs {
> void (*force_wake_get)(struct drm_i915_private *dev_priv,
> enum forcewake_domains
> domains);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index a1db6a02cf23..cac387f38cf6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -418,6 +418,7 @@ static void execlists_submit_requests(struct
> drm_i915_gem_request *rq0,
> struct drm_i915_gem_request *rq1)
> {
> struct drm_i915_private *dev_priv = rq0->i915;
> + unsigned int fw_domains = rq0->engine->fw_domains_elsp;
So I was thinking this was overly specific and that no hw engineer would
ever split the block of ring registers into separate power domains, and
then I realised they already had with the shadow_regs.
The only other place where we could make semantic use of this is in
intel_ringbuffer.c:init_ring_common. We don't make use of the block fw
put/get anywhere else - the only other candidate I can think of right
now would be gen6 bsd legacy tail writes. That is a block of register
writes were marking the intent to stay awake through the entire sequence
would be worth it.
> +#define __gen6_reg_read_fw_domains(offset) \
> +({ \
> + enum forcewake_domains __fwd; \
> + if (NEEDS_FORCE_WAKE(offset)) \
> + __fwd = FORCEWAKE_RENDER; \
> + else \
> + __fwd = 0; \
> + __fwd; \
> +})
[snip]
This split out looks right, but it is probably worth doing as a seperate
step and checking for changes in objdump. Just to be paranoid that we
didn't make an unexpected modification.
> +enum forcewake_domains
> +intel_reg_read_fw_domains(struct drm_i915_private *dev_priv, i915_reg_t reg)
> +{
> + if (intel_vgpu_active(dev_priv->dev))
> + return 0;
> +
> + switch (INTEL_INFO(dev_priv)->gen) {
> + case 9:
> + return __gen9_reg_read_fw_domains(i915_mmio_reg_offset(reg));
> + case 8:
> + if (IS_CHERRYVIEW(dev_priv))
> + return
> __chv_reg_read_fw_domains(i915_mmio_reg_offset(reg));
> + else
> + return
> __gen6_reg_read_fw_domains(i915_mmio_reg_offset(reg));
> + case 7:
> + case 6:
> + if (IS_VALLEYVIEW(dev_priv))
> + return
> __vlv_reg_read_fw_domains(i915_mmio_reg_offset(reg));
> + else
> + return
> __gen6_reg_read_fw_domains(i915_mmio_reg_offset(reg));
> + default:
> + /* It is a bug to think about forcewake on older platforms. */
Yes, but we might as well report them correctly as 0 and not throw a
warning. You are calling this an intel_() function, and not gen6_()
after all (that is inviting everybody to use it).
default:
> + MISSING_CASE(INTEL_INFO(dev_priv)->gen);
case 5: /* forcewake was introduced with gen6 */
case 4:
case 3:
case 2:
> + return 0;
A nice touch here would be to
WARN_ON(fw_domains & ~dev_priv->uncore.forcewake_domains);
R-b on the engine->fw_domains_*, a-b on the split, but let's try to use
the compiler to our advantage on that step.
-Chris
--
Chris Wilso
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only grab correct forcewake for the engine with execlists
== Series Details == Series: drm/i915: Only grab correct forcewake for the engine with execlists URL : https://patchwork.freedesktop.org/series/5375/ State : success == Summary == Series 5375v1 drm/i915: Only grab correct forcewake for the engine with execlists http://patchwork.freedesktop.org/api/1.0/series/5375/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (bsw-nuc-2) Test gem_ctx_param_basic: Subgroup invalid-ctx-set: dmesg-warn -> PASS (bsw-nuc-2) Test gem_storedw_loop: Subgroup basic-blt: dmesg-fail -> PASS (bsw-nuc-2) Subgroup basic-bsd: skip -> PASS (bsw-nuc-2) Test kms_addfb_basic: Subgroup bad-pitch-128: dmesg-warn -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (bsw-nuc-2) Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (hsw-gt2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:159 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1817/ ab13a48af1102b84bdb8dcdfbef1b5b44fab8d3d drm-intel-nightly: 2016y-04m-06d-11h-23m-30s UTC integration manifest f9519b6967e2c9d16ea1413a735a4c33cc943b65 drm/i915: Only grab correct forcewake for the engine with execlists ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND FOR CI] drm/i915/skl+: Use plane size for relative data rate calculation
From: "Kumar, Mahesh"
Use plane size for relative data rate calculation. don't always use
pipe source width & height.
adjust height & width according to rotation.
use plane size for watermark calculations also.
v2: Address Matt's comments.
Use intel_plane_state->visible to avoid divide-by-zero error.
Where FB was present but not visible so causing total data rate to
be zero, hence divide-by-zero.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93917
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94044
Signed-off-by: Kumar, Mahesh
Reviewed-by: Matt Roper
Signed-off-by: Matt Roper
---
This patch is included as part of a couple pending watermark series that are
still under review, but it's an important fix on its own, so we'd like to merge
it early. I reviewed the original patch from Mahesh a while back and have been
keeping it rebased since that time.
drivers/gpu/drm/i915/intel_pm.c | 42 +++--
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7fccf3b..521eed4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2937,25 +2937,28 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
const struct drm_plane_state *pstate,
int y)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ uint32_t width = 0, height = 0;
+
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+
+ if (intel_rotation_90_or_270(pstate->rotation))
+ swap(width, height);
/* for planar format */
if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
+ return width * height *
drm_format_plane_cpp(fb->pixel_format, 0);
else/* uv-plane data rate */
- return (intel_crtc->config->pipe_src_w/2) *
- (intel_crtc->config->pipe_src_h/2) *
+ return (width / 2) * (height / 2) *
drm_format_plane_cpp(fb->pixel_format, 1);
}
/* for packed formats */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
- drm_format_plane_cpp(fb->pixel_format, 0);
+ return width * height * drm_format_plane_cpp(fb->pixel_format, 0);
}
/*
@@ -3034,8 +3037,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
struct drm_framebuffer *fb = plane->state->fb;
int id = skl_wm_plane_id(intel_plane);
- if (fb == NULL)
+ if (!to_intel_plane_state(plane->state)->visible)
continue;
+
if (plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
@@ -3061,7 +3065,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
uint16_t plane_blocks, y_plane_blocks = 0;
int id = skl_wm_plane_id(intel_plane);
- if (pstate->fb == NULL)
+ if (!to_intel_plane_state(pstate)->visible)
continue;
if (plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
@@ -3184,26 +3188,36 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
{
struct drm_plane *plane = &intel_plane->base;
struct drm_framebuffer *fb = plane->state->fb;
+ struct intel_plane_state *intel_pstate =
+ to_intel_plane_state(plane->state);
uint32_t latency = dev_priv->wm.skl_latency[level];
uint32_t method1, method2;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
uint32_t res_blocks, res_lines;
uint32_t selected_result;
uint8_t cpp;
+ uint32_t width = 0, height = 0;
- if (latency == 0 || !cstate->base.active || !fb)
+ if (latency == 0 || !cstate->base.active || !intel_pstate->visible)
return false;
+ width = drm_rect_width(&intel_pstate->src) >> 16;
+ height = drm_rect_height(&intel_pstate->src) >> 16;
+
+ if (intel_rotation_90_or_270(plane->state->rotation))
+ swap(width, height);
+
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
method1 = skl_wm_method1(skl_pipe_pixel_rate(cstate),
cpp, latency);
method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
cstate->base.ad
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only grab correct forcewake for the engine with execlists
On Wed, Apr 06, 2016 at 03:29:37PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Only grab correct forcewake for the engine with execlists > URL : https://patchwork.freedesktop.org/series/5375/ > State : success > > == Summary == > > Series 5375v1 drm/i915: Only grab correct forcewake for the engine with > execlists > http://patchwork.freedesktop.org/api/1.0/series/5375/revisions/1/mbox/ > > Test drv_module_reload_basic: > dmesg-warn -> PASS (bsw-nuc-2) > Test gem_ctx_param_basic: > Subgroup invalid-ctx-set: > dmesg-warn -> PASS (bsw-nuc-2) > Test gem_storedw_loop: > Subgroup basic-blt: > dmesg-fail -> PASS (bsw-nuc-2) > Subgroup basic-bsd: > skip -> PASS (bsw-nuc-2) > Test kms_addfb_basic: > Subgroup bad-pitch-128: > dmesg-warn -> PASS (bsw-nuc-2) > Test kms_flip: > Subgroup basic-flip-vs-dpms: > dmesg-warn -> PASS (bsw-nuc-2) > Subgroup basic-flip-vs-modeset: > dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-b: > incomplete -> PASS (hsw-gt2) Hmm, intriguing. I wonder if fortune holds if we send the patch again... -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] ✗ Fi.CI.BAT: failure for drm/i915/skl+: Use plane size for relative data rate calculation
== Series Details == Series: drm/i915/skl+: Use plane size for relative data rate calculation URL : https://patchwork.freedesktop.org/series/5376/ State : failure == Summary == Series 5376v1 drm/i915/skl+: Use plane size for relative data rate calculation http://patchwork.freedesktop.org/api/1.0/series/5376/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> PASS (bsw-nuc-2) Test gem_ctx_param_basic: Subgroup invalid-ctx-set: dmesg-warn -> PASS (bsw-nuc-2) Subgroup invalid-size-get: pass -> DMESG-WARN (bsw-nuc-2) Test gem_ctx_switch: Subgroup basic-default: pass -> DMESG-FAIL (bsw-nuc-2) Test gem_storedw_loop: Subgroup basic-blt: dmesg-fail -> PASS (bsw-nuc-2) Subgroup basic-bsd: skip -> PASS (bsw-nuc-2) Test kms_addfb_basic: Subgroup bad-pitch-128: dmesg-warn -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE Test kms_force_connector_basic: Subgroup force-edid: pass -> SKIP (ivb-t430s) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (hsw-gt2) bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:196 pass:157 dwarn:1 dfail:1 fail:0 skip:37 byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:196 pass:131 dwarn:1 dfail:0 fail:0 skip:64 ivb-t430stotal:196 pass:170 dwarn:0 dfail:0 fail:0 skip:26 skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1818/ ab13a48af1102b84bdb8dcdfbef1b5b44fab8d3d drm-intel-nightly: 2016y-04m-06d-11h-23m-30s UTC integration manifest 278a2dfb05bef0627573d0eb98e89f0cbef7d3b5 drm/i915/skl+: Use plane size for relative data rate calculation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Enable FBC on SKL, v3
On 4/6/2016 7:24 PM, Zanoni, Paulo R wrote: Em Qua, 2016-04-06 às 10:36 +0530, Thulasimani, Sivakumar escreveu: dont want to hijack thread but wanted to point out a possible regression in the previous patches of this series. intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug) How? It will check for i915.enable_fbc, which will have been sanitized to zero on these platforms. Aren't you explicitly enabling FBC on these platforms by using i915.enable_fbc=1? nope, found as part of code walkthrough hence mentioned above that it is "possible regression" :) . Two points > found that this is not a regression per say as it was there before your change too > Agree that FBC code wont reach intel_fbc_can_choose due to platform checks but without proper comments wont someone assume that the rest of code should work properly especially when we have checks for non haswell/bdw platforms in the code flow. Also found another possible bug in multiple_pipes_ok. i assume it is supposed to return true when we can enable FBC after considering multiple pipes are enabled or not. but it returns false in case of single display in gen3 thus ending up doing opposite of multiple pipe requirement. i understand all these are on very old platforms which dont have FBC enabled at all so fixing them should be lower priority. but sharing them here so that at-least it is documented somewhere. regards, Sivakumar so intel_crtc_state->enable_fbc = true; will be executed for first crtc everytime intel_fbc_choose_crtc is called. Although there is check to handle fbc already enabled, it may fail when we fbc is disabled and we are working on non supported panel. regards, Sivakumar On 4/5/2016 2:47 AM, Paulo Zanoni wrote: Now with the suggestion from Chris instead of the old workaround. We don't need new DDX patches anymore, but now we need new IGT patches. Chris Wilson (1): drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps Paulo Zanoni (3): drm/i915/fbc: update busy_bits even for GTT and flip flushes drm/i915/fbc: sanitize i915.enable_fbc during FBC init drm/i915/fbc: enable FBC on gen 9+ too drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 14 +++--- drivers/gpu/drm/i915/intel_fbc.c | 27 --- 3 files changed, 28 insertions(+), 14 deletions(-) ___ 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 1/3] drm/edid: Add drm_edid_get_monitor_name()
On Wed, Apr 06, 2016 at 11:35:44AM +0300, Jani Nikula wrote:
> On Tue, 05 Apr 2016, Jim Bride wrote:
> > In order to include monitor name information in debugfs
> > output we needed to add a function that would extract the
> > monitor name from the EDID, and that function needed to
> > reside in the file where the rest of the EDID helper
> > functions are implemented.
> >
> > cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Jim Bride
> > ---
> > drivers/gpu/drm/drm_edid.c | 28
> > include/drm/drm_crtc.h | 1 +
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 558ef9f..fc69a46 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3569,6 +3569,34 @@ struct drm_connector *drm_select_eld(struct
> > drm_encoder *encoder)
> > EXPORT_SYMBOL(drm_select_eld);
> >
> > /**
> > + * drm_edid_get_monitor_name - fetch the monitor name from the edid
> > + * @edid: monitor EDID information
> > + * @name: pointer to a character array of at least 13 chars to hold the
> > name
>
> Mixed feelings about "at least 13 chars". It might be simpler for this
> one thing, but I hate to see this assumption of "at least 13 chars" get
> spread around in patch 2 to where it's no longer obvious where this
> requirement comes from.
>
> Seeing that this is mostly copy-paste from drm_edid_to_eld(), I think
> this patch should be an abstraction of that code to a separate function.
Yeah, I see what you mean. Writing something that works with both this
use and drm_edid_to_eld() for the name parsing makes sense.
> > + *
> > + * Return: True if the name could be extracted, false otherwise
> > + */
> > +bool drm_edid_get_monitor_name(struct edid *edid, char *name)
> > +{
> > + char *edid_name = NULL;
> > + int mnl;
> > +
> > + if (!edid || !name)
> > + return false;
> > +
> > + drm_for_each_detailed_block((u8 *)edid, monitor_name, &edid_name);
> > + for (mnl = 0; edid_name && mnl < 13; mnl++) {
> > + if (edid_name[mnl] == 0x0a) {
> > + name[mnl] = '\0';
>
> Depending on edid_name you might not terminate the string. And, in fact,
> if you make this an abstraction for drm_edid_to_eld(), you might be
> better off *not* terminating, which OTOH is not nice for your other use
> in patch 2.
>
> So how about first adding an internal abstraction:
>
> static int get_monitor_name(struct edid *edid, char name[13])
>
> which does *not* terminate the string, and returns length, 0 for
> edid_name == NULL. Works nicely for drm_edid_to_eld().
>
> Then you could add the external interface on top of that:
>
> static void drm_edid_get_monitor_name(struct edid *edid, char *buf, int
> bufsize)
>
> which would always terminate the string (assuming bufsize > 0), even on
> errors so you can get rid of the return value. This simplifies your
> follow up code, and if we later on need more robust error handling, it's
> easy to add the return value.
Seems reasonable; I'll update the patch.
Jim
> BR,
> Jani.
>
>
> > + break;
> > + }
> > + name[mnl] = edid_name[mnl];
> > + }
> > +
> > + return mnl ? true : false;
> > +}
> > +EXPORT_SYMBOL(drm_edid_get_monitor_name);
> > +
> > +/**
> > * drm_detect_hdmi_monitor - detect whether monitor is HDMI
> > * @edid: monitor EDID information
> > *
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 8cb377c..2590168 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -2500,6 +2500,7 @@ extern int drm_edid_header_is_valid(const u8
> > *raw_edid);
> > extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool
> > print_bad_edid,
> > bool *edid_corrupt);
> > extern bool drm_edid_is_valid(struct edid *edid);
> > +extern bool drm_edid_get_monitor_name(struct edid *edid, char *name);
> >
> > extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device
> > *dev,
> > char topology[8]);
>
> --
> 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] drm/i915/bxt: Set max cdclk frequency properly
On ti, 2016-04-05 at 14:55 -0700, Matt Roper wrote:
> On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote:
> > intel_update_max_cdclk() doesn't have a switch case for Broxton, so
> > dev_priv->max_cdclk_freq gets set to whatever clock frequency we're
> > currently running at (e.g., 144 MHz) rather than the true
> > maximum. This
> > causes our max dotclock to also be set too low and in turn leads
> > mode
> > verification to reject perfectly valid modes while loading EDID
> > firmware
> > blobs.
> >
> > Cc: Imre Deak
> > Signed-off-by: Matt Roper
> > ---
>
> One thing I should have mentioned is that it's unclear to me whether we
> should be looking at the cdclk limit bits in the DFSM register like we
> do on SKL/KBL. The bspec seems to indicate that the register in general
> applies to gen9, including BXT, but the actual meaning of the bits
> doesn't match up with the frequencies we have on BXT.
Yes, vendors could restrict the max CDCLK frequency via some method,
but we don't have that mechanism in place anyway and we would use the
hard-coded 624MHz if BIOS didn't enable CDCLK. So this is a correct
fix for now:
Reviewed-by: Imre Deak
>
>
> Matt
>
> > drivers/gpu/drm/i915/intel_display.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index af74cdb..924d851 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5261,6 +5261,8 @@ static void intel_update_max_cdclk(struct
> > drm_device *dev)
> > dev_priv->max_cdclk_freq = 45;
> > else
> > dev_priv->max_cdclk_freq = 337500;
> > + } else if (IS_BROXTON(dev)) {
> > + dev_priv->max_cdclk_freq = 624000;
> > } else if (IS_BROADWELL(dev)) {
> > /*
> > * FIXME with extra cooling we can allow
> > --
> > 2.1.4
> >
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Set max cdclk frequency properly
On Wed, Apr 06, 2016 at 08:30:00AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/bxt: Set max cdclk frequency properly > URL : https://patchwork.freedesktop.org/series/5348/ > State : failure > > == Summary == > > Series 5348v1 drm/i915/bxt: Set max cdclk frequency properly > http://patchwork.freedesktop.org/api/1.0/series/5348/revisions/1/mbox/ > > Test gem_sync: > Subgroup basic-all: > dmesg-fail -> PASS (bsw-nuc-2) > Test kms_flip: > Subgroup basic-flip-vs-dpms: > dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE > Subgroup basic-flip-vs-wf_vblank: > pass -> FAIL (bsw-nuc-2) https://bugs.freedesktop.org/show_bug.cgi?id=94294 > Test kms_force_connector_basic: > Subgroup prune-stale-modes: > skip -> PASS (ivb-t430s) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > dmesg-warn -> PASS (bsw-nuc-2) > > bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 > bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 > bsw-nuc-2total:196 pass:158 dwarn:0 dfail:0 fail:1 skip:37 > byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 > hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 > hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 > ilk-hp8440p total:196 pass:132 dwarn:0 dfail:0 fail:0 skip:64 > ivb-t430stotal:196 pass:171 dwarn:0 dfail:0 fail:0 skip:25 > skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 > skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 > snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 > snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 > > Results at /archive/results/CI_IGT_test/Patchwork_1811/ > > 12899f13b8ee9a4944f167a08e4db0526a3f3855 drm-intel-nightly: > 2016y-04m-05d-19h-09m-25s UTC integration manifest > 65c53e538f64d2242ed44e62134c4f73d6737590 drm/i915/bxt: Set max cdclk > frequency properly > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl+: Use plane size for relative data rate calculation
On Wed, Apr 06, 2016 at 04:06:36PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/skl+: Use plane size for relative data rate calculation > URL : https://patchwork.freedesktop.org/series/5376/ > State : failure > > == Summary == > > Series 5376v1 drm/i915/skl+: Use plane size for relative data rate calculation > http://patchwork.freedesktop.org/api/1.0/series/5376/revisions/1/mbox/ > > Test drv_module_reload_basic: > dmesg-warn -> PASS (bsw-nuc-2) > Test gem_ctx_param_basic: > Subgroup invalid-ctx-set: > dmesg-warn -> PASS (bsw-nuc-2) > Subgroup invalid-size-get: > pass -> DMESG-WARN (bsw-nuc-2) > Test gem_ctx_switch: > Subgroup basic-default: > pass -> DMESG-FAIL (bsw-nuc-2) Both are https://bugs.freedesktop.org/show_bug.cgi?id=94584 > Test gem_storedw_loop: > Subgroup basic-blt: > dmesg-fail -> PASS (bsw-nuc-2) > Subgroup basic-bsd: > skip -> PASS (bsw-nuc-2) > Test kms_addfb_basic: > Subgroup bad-pitch-128: > dmesg-warn -> PASS (bsw-nuc-2) > Test kms_flip: > Subgroup basic-flip-vs-dpms: > dmesg-warn -> PASS (bsw-nuc-2) > pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE https://bugs.freedesktop.org/show_bug.cgi?id=93787 > Subgroup basic-flip-vs-modeset: > dmesg-warn -> PASS (ilk-hp8440p) UNSTABLE > Test kms_force_connector_basic: > Subgroup force-edid: > pass -> SKIP (ivb-t430s) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-b: > incomplete -> PASS (hsw-gt2) > > bdw-nuci7total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:12 > bdw-ultratotal:196 pass:175 dwarn:0 dfail:0 fail:0 skip:21 > bsw-nuc-2total:196 pass:157 dwarn:1 dfail:1 fail:0 skip:37 > byt-nuc total:196 pass:161 dwarn:0 dfail:0 fail:0 skip:35 > hsw-brixbox total:196 pass:174 dwarn:0 dfail:0 fail:0 skip:22 > hsw-gt2 total:196 pass:179 dwarn:0 dfail:0 fail:0 skip:17 > ilk-hp8440p total:196 pass:131 dwarn:1 dfail:0 fail:0 skip:64 > ivb-t430stotal:196 pass:170 dwarn:0 dfail:0 fail:0 skip:26 > skl-i7k-2total:196 pass:173 dwarn:0 dfail:0 fail:0 skip:23 > skl-nuci5total:196 pass:185 dwarn:0 dfail:0 fail:0 skip:11 > snb-dellxps total:196 pass:162 dwarn:0 dfail:0 fail:0 skip:34 > snb-x220ttotal:196 pass:162 dwarn:0 dfail:0 fail:1 skip:33 > > Results at /archive/results/CI_IGT_test/Patchwork_1818/ > > ab13a48af1102b84bdb8dcdfbef1b5b44fab8d3d drm-intel-nightly: > 2016y-04m-06d-11h-23m-30s UTC integration manifest > 278a2dfb05bef0627573d0eb98e89f0cbef7d3b5 drm/i915/skl+: Use plane size for > relative data rate calculation > -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/16] drm/i915/skl+: Use plane size for relative data rate calculation
On Wed, Apr 06, 2016 at 06:09:00PM +0300, Imre Deak wrote:
> On to, 2016-03-31 at 18:46 -0700, Matt Roper wrote:
> > From: "Kumar, Mahesh"
> >
> > Use plane size for relative data rate calculation. don't always use
> > pipe source width & height.
> > adjust height & width according to rotation.
> > use plane size for watermark calculations also.
> >
> > v2: Address Matt's comments.
> > Use intel_plane_state->visible to avoid divide-by-zero error.
> > Where FB was present but not visible so causing total data rate
> > to
> > be zero, hence divide-by-zero.
> >
> > Cc: matthew.d.ro...@intel.com
> > Signed-off-by: Kumar, Mahesh
> > Reviewed-by: Matt Roper
> > Signed-off-by: Matt Roper
>
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=93917
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=94044
>
> This patch fixed a screen corruption problem for me with an eDP + DP
> config. It somehow made worse by moving the cursor around and I can get
> rid of it by switching of the cursor plane.
>
> Matt any chance of getting this merged separately from the rest?
>
> --Imre
Yep, I'd already reviewed this when Mahesh wrote it a while back so I
just ran this through CI in isolation and it came up clean. Added
a Cc: -fixes and pushed to dinq.
Matt
>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 41 ---
> > --
> > 1 file changed, 28 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index c970c4e..1c3f772 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2937,24 +2937,28 @@ skl_plane_relative_data_rate(const struct
> > intel_crtc_state *cstate,
> > const struct drm_plane_state *pstate,
> > int y)
> > {
> > - struct intel_crtc *intel_crtc = to_intel_crtc(cstate-
> > >base.crtc);
> > + struct intel_plane_state *intel_pstate =
> > to_intel_plane_state(pstate);
> > struct drm_framebuffer *fb = pstate->fb;
> > + uint32_t width = 0, height = 0;
> > +
> > + width = drm_rect_width(&intel_pstate->src) >> 16;
> > + height = drm_rect_height(&intel_pstate->src) >> 16;
> > +
> > + if (intel_rotation_90_or_270(pstate->rotation))
> > + swap(width, height);
> >
> > /* for planar format */
> > if (fb->pixel_format == DRM_FORMAT_NV12) {
> > if (y) /* y-plane data rate */
> > - return intel_crtc->config->pipe_src_w *
> > - intel_crtc->config->pipe_src_h *
> > + return width * height *
> > drm_format_plane_cpp(fb-
> > >pixel_format, 0);
> > else/* uv-plane data rate */
> > - return (intel_crtc->config->pipe_src_w/2) *
> > - (intel_crtc->config->pipe_src_h/2) *
> > + return (width / 2) * (height / 2) *
> > drm_format_plane_cpp(fb-
> > >pixel_format, 1);
> > }
> >
> > /* for packed formats */
> > - return cstate->pipe_src_w * cstate->pipe_src_h *
> > - drm_format_plane_cpp(fb->pixel_format, 0);
> > + return width * height * drm_format_plane_cpp(fb-
> > >pixel_format, 0);
> > }
> >
> > /*
> > @@ -3033,8 +3037,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> > *cstate,
> > struct drm_framebuffer *fb = plane->state->fb;
> > int id = skl_wm_plane_id(intel_plane);
> >
> > - if (fb == NULL)
> > + if (!to_intel_plane_state(plane->state)->visible)
> > continue;
> > +
> > if (plane->type == DRM_PLANE_TYPE_CURSOR)
> > continue;
> >
> > @@ -3060,7 +3065,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> > *cstate,
> > uint16_t plane_blocks, y_plane_blocks = 0;
> > int id = skl_wm_plane_id(intel_plane);
> >
> > - if (pstate->fb == NULL)
> > + if (!to_intel_plane_state(pstate)->visible)
> > continue;
> > if (plane->type == DRM_PLANE_TYPE_CURSOR)
> > continue;
> > @@ -3183,26 +3188,36 @@ static bool skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> > {
> > struct drm_plane *plane = &intel_plane->base;
> > struct drm_framebuffer *fb = plane->state->fb;
> > + struct intel_plane_state *intel_pstate =
> > + to_intel_plane_state(plane-
> > >state);
> > uint32_t latency = dev_priv->wm.skl_latency[level];
> > uint32_t method1, method2;
> > uint32_t plane_bytes_per_line, plane_blocks_per_line;
> > uint32_t res_blocks, res_lines;
> > uint32_t selected_result;
> > uint8_t cpp;
> > + uint32_t width = 0, height = 0;
> >
> > - if (latency == 0 || !cstate->base.active || !fb)
> > + if (latency == 0 || !cstate->base.active || !intel_pstate-
> > >visible)
> >
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly
On Wed, Apr 06, 2016 at 08:22:56PM +0300, Imre Deak wrote:
> On ti, 2016-04-05 at 14:55 -0700, Matt Roper wrote:
> > On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote:
> > > intel_update_max_cdclk() doesn't have a switch case for Broxton, so
> > > dev_priv->max_cdclk_freq gets set to whatever clock frequency we're
> > > currently running at (e.g., 144 MHz) rather than the true
> > > maximum. This
> > > causes our max dotclock to also be set too low and in turn leads
> > > mode
> > > verification to reject perfectly valid modes while loading EDID
> > > firmware
> > > blobs.
> > >
> > > Cc: Imre Deak
> > > Signed-off-by: Matt Roper
> > > ---
> >
> > One thing I should have mentioned is that it's unclear to me whether we
> > should be looking at the cdclk limit bits in the DFSM register like we
> > do on SKL/KBL. The bspec seems to indicate that the register in general
> > applies to gen9, including BXT, but the actual meaning of the bits
> > doesn't match up with the frequencies we have on BXT.
>
> Yes, vendors could restrict the max CDCLK frequency via some method,
> but we don't have that mechanism in place anyway and we would use the
> hard-coded 624MHz if BIOS didn't enable CDCLK. So this is a correct
> fix for now:
>
> Reviewed-by: Imre Deak
Thanks for the review. Pushed to dinq.
Matt
>
> >
> >
> > Matt
> >
> > > drivers/gpu/drm/i915/intel_display.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index af74cdb..924d851 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -5261,6 +5261,8 @@ static void intel_update_max_cdclk(struct
> > > drm_device *dev)
> > > dev_priv->max_cdclk_freq = 45;
> > > else
> > > dev_priv->max_cdclk_freq = 337500;
> > > + } else if (IS_BROXTON(dev)) {
> > > + dev_priv->max_cdclk_freq = 624000;
> > > } else if (IS_BROADWELL(dev)) {
> > > /*
> > > * FIXME with extra cooling we can allow
> > > --
> > > 2.1.4
> > >
> >
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/25] drm/i915/slpc: Add slpc support for max/min freq
From: Tom O'Rourke
Update sysfs and debugfs functions to set SLPC
parameters when setting max/min frequency.
v2: Update for SLPC 2015.2.4 (params for both slice and unslice)
Replace HAS_SLPC with intel_slpc_active() (Paulo)
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_debugfs.c | 16
drivers/gpu/drm/i915/i915_sysfs.c | 18 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d844ac8..5f0d72b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4970,6 +4970,14 @@ i915_max_freq_set(void *data, u64 val)
}
dev_priv->rps.max_freq_softlimit = val;
+ if (intel_slpc_active(dev)) {
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ }
intel_set_rps(dev, val);
@@ -5037,6 +5045,14 @@ i915_min_freq_set(void *data, u64 val)
}
dev_priv->rps.min_freq_softlimit = val;
+ if (intel_slpc_active(dev)) {
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ }
intel_set_rps(dev, val);
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 923a63a..7b8e73e 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -392,6 +392,15 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
dev_priv->rps.max_freq_softlimit = val;
+ if (intel_slpc_active(dev)) {
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MAX_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ }
+
val = clamp_t(int, dev_priv->rps.cur_freq,
dev_priv->rps.min_freq_softlimit,
dev_priv->rps.max_freq_softlimit);
@@ -456,6 +465,15 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
dev_priv->rps.min_freq_softlimit = val;
+ if (intel_slpc_active(dev)) {
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ intel_slpc_set_param(dev,
+SLPC_PARAM_GLOBAL_MIN_GT_SLICE_FREQ_MHZ,
+(u32) intel_gpu_freq(dev_priv, val));
+ }
+
val = clamp_t(int, dev_priv->rps.cur_freq,
dev_priv->rps.min_freq_softlimit,
dev_priv->rps.max_freq_softlimit);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/25] drm/i915/slpc: Add broxton support
From: Tom O'Rourke
Adds has_slpc to broxton info and adds broxton to
version check. The SLPC interface version 2015.2.4
is found in Broxton Guc v5.
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/intel_guc_loader.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f2c7c72..871641f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -354,6 +354,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_ddi = 1,
.has_fpga_dbg = 1,
.has_fbc = 1,
+ .has_slpc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
BDW_COLORS,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 805b3db..3a61aac 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -136,7 +136,8 @@ static void slpc_version_check(struct drm_device *dev,
struct intel_guc_fw *guc_
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_device_info *info;
- if (IS_SKYLAKE(dev) && (guc_fw->guc_fw_major_found != 6)) {
+ if ((IS_SKYLAKE(dev) && (guc_fw->guc_fw_major_found != 6))
+|| (IS_BROXTON(dev) && (guc_fw->guc_fw_major_found != 5))) {
info = (struct intel_device_info *) &dev_priv->info;
info->has_slpc = 0;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/25] drm/i915/slpc: Update current requested frequency
From: Tom O'Rourke
When SLPC is controlling requested frequency, the rps.cur_freq
value is not used to make the frequency request.
Before using rps.cur_freq in sysfs or debugfs, read
requested frequency from register to get the value
most recently requested by SLPC firmware.
v2: replace HAS_SLPC with intel_slpc_active (Paulo)
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
drivers/gpu/drm/i915/i915_sysfs.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a2e3af0..d844ac8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1135,6 +1135,9 @@ static int i915_frequency_info(struct seq_file *m, void
*unused)
flush_delayed_work(&dev_priv->rps.delayed_resume_work);
+ if (intel_slpc_active(dev))
+ dev_priv->rps.cur_freq = (I915_READ(GEN6_RPNSWREQ) >> 23);
+
if (IS_GEN5(dev)) {
u16 rgvswctl = I915_READ16(MEMSWCTL);
u16 rgvstat = I915_READ16(MEMSTAT_ILK);
@@ -2360,6 +2363,9 @@ static int i915_rps_boost_info(struct seq_file *m, void
*data)
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_file *file;
+ if (intel_slpc_active(dev))
+ dev_priv->rps.cur_freq = (I915_READ(GEN6_RPNSWREQ) >> 23);
+
seq_printf(m, "RPS enabled? %d\n", dev_priv->rps.enabled);
seq_printf(m, "GPU busy? %d\n", dev_priv->mm.busy);
seq_printf(m, "CPU waiting? %d\n", count_irq_waiters(dev_priv));
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 2d576b7..923a63a 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -318,6 +318,8 @@ static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
intel_runtime_pm_get(dev_priv);
mutex_lock(&dev_priv->rps.hw_lock);
+ if (intel_slpc_active(dev))
+ dev_priv->rps.cur_freq = (I915_READ(GEN6_RPNSWREQ) >> 23);
ret = intel_gpu_freq(dev_priv, dev_priv->rps.cur_freq);
mutex_unlock(&dev_priv->rps.hw_lock);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/25] drm/i915/slpc: Notification of Display mode change
From: Sagar Arun Kamble
GuC SLPC need to be sent data related to Active pipes, refresh rates,
widi pipes, fullscreen pipes related via host to GuC display mode
change event. Based on this, SLPC will track FPS on active pipes.
This patch defines the event and implements trigger of the event.
v2: Addressed review comments from Paulo and Ville. Changed the way
display mode information is collected in intel_atomic_commit. Coupled
display mode change event with SLPC enable/reset event. Updated inactive
crtc state in display mode data. Updated refresh rate and vsync_ft_usec
calculations to get more accurate value. (Paulo)
v2(torourke): Updates suggested by Paulo: replace HAS_SLPC with
intel_slpc_active. return void instead of ignored error code.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_display.c | 2 +
drivers/gpu/drm/i915/intel_slpc.c| 142 ++-
drivers/gpu/drm/i915/intel_slpc.h| 3 +
3 files changed, 146 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cb2d6af..90f2809 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13639,6 +13639,8 @@ static int intel_atomic_commit(struct drm_device *dev,
if (hw_check)
intel_modeset_check_state(dev, state);
+ intel_slpc_update_atomic_commit_info(dev, state);
+
drm_atomic_state_free(state);
/* As one of the primary mmio accessors, KMS has a high likelihood
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index 97b2163..f476670 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -73,6 +73,21 @@ static void host2guc_slpc_shutdown(struct drm_device *dev)
host2guc_slpc(dev_priv, data, 4);
}
+static void host2guc_slpc_display_mode_change(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 data[7];
+ int i;
+
+ data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+ data[1] = SLPC_EVENT(SLPC_EVENT_DISPLAY_MODE_CHANGE,
SLPC_MAX_NUM_OF_PIPES + 1);
+ data[2] = dev_priv->guc.slpc.display_mode_params.global_data;
+ for(i = 0; i < SLPC_MAX_NUM_OF_PIPES; ++i)
+ data[3+i] =
dev_priv->guc.slpc.display_mode_params.per_pipe_info[i].data;
+
+ host2guc_slpc(dev_priv, data, 7);
+}
+
static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
{
struct drm_device *dev = obj->base.dev;
@@ -181,8 +196,10 @@ void intel_slpc_disable(struct drm_device *dev)
void intel_slpc_enable(struct drm_device *dev)
{
- if (intel_slpc_active(dev))
+ if (intel_slpc_active(dev)) {
host2guc_slpc_reset(dev);
+ intel_slpc_update_display_mode_info(dev);
+ }
}
void intel_slpc_reset(struct drm_device *dev)
@@ -192,3 +209,126 @@ void intel_slpc_reset(struct drm_device *dev)
host2guc_slpc_reset(dev);
}
}
+
+void intel_slpc_update_display_mode_info(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc;
+ struct intel_display_pipe_info *per_pipe_info;
+ struct intel_slpc_display_mode_event_params *cur_params, old_params;
+ bool notify = false;
+
+ if (!intel_slpc_active(dev))
+ return;
+
+ /* Copy display mode parameters for comparison */
+ cur_params = &dev_priv->guc.slpc.display_mode_params;
+ old_params.global_data = cur_params->global_data;
+ cur_params->global_data = 0;
+
+ intel_runtime_pm_get(dev_priv);
+ drm_modeset_lock_all(dev);
+
+ for_each_intel_crtc(dev, intel_crtc) {
+ per_pipe_info = &cur_params->per_pipe_info[intel_crtc->pipe];
+ old_params.per_pipe_info[intel_crtc->pipe].data =
per_pipe_info->data;
+ per_pipe_info->data = 0;
+
+ if (intel_crtc->active) {
+ struct drm_display_mode *mode = &intel_crtc->base.mode;
+ /* FIXME: Update is_widi based on encoder */
+ per_pipe_info->is_widi = 0;
+ per_pipe_info->refresh_rate =
+ (mode->clock * 1000)/
(mode->htotal * mode->vtotal);
+ if (!per_pipe_info->refresh_rate) {
+ DRM_ERROR("Invalid mode refresh rate\n");
+ drm_modeset_unlock_all(dev);
+ intel_runtime_pm_put(dev_priv);
+ return;
+ }
+ per_pipe_info->vsync_ft_usec =
+ (mode->htotal * mode->vtotal *
1000) / mode->clock;
+ cur_params->active_pipes_bitmask |= (1 <<
intel_crtc->pipe);
+
[Intel-gfx] [PATCH 06/25] drm/i915/slpc: Enable SLPC in guc if supported
From: Tom O'Rourke
If slpc enabled, then add enable SLPC flag to guc
control parameter during guc load.
v2: Use intel_slpc_enabled() (Paulo)
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_guc_loader.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 5dd2d9e..805b3db 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -187,6 +187,9 @@ static void set_guc_init_params(struct drm_i915_private
*dev_priv)
params[GUC_CTL_FEATURE] |= GUC_CTL_DISABLE_SCHEDULER |
GUC_CTL_VCS2_ENABLED;
+ if (intel_slpc_enabled())
+ params[GUC_CTL_FEATURE] |= GUC_CTL_ENABLE_SLPC;
+
if (i915.guc_log_level >= 0) {
params[GUC_CTL_LOG_PARAMS] = guc->log_flags;
params[GUC_CTL_DEBUG] =
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/25] drm/i915/slpc: Add Display mode event related data structures
From: Sagar Arun Kamble
v2: Cleaning up defines for number of pipes and other cosmetic changes.
Signed-off-by: Sagar Arun Kamble
Acked-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_slpc.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_slpc.h
b/drivers/gpu/drm/i915/intel_slpc.h
index 7f33a04..b963fe7 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -109,8 +109,37 @@ struct slpc_shared_data {
u32 override_parameters_values[SLPC_MAX_OVERRIDE_PARAMETERS];
} __packed;
+#define SLPC_MAX_NUM_OF_PIPES 4
+
+struct intel_display_pipe_info {
+ union {
+ u32 data;
+ struct {
+ u32 is_widi:1;
+ u32 refresh_rate:7;
+ u32 vsync_ft_usec:24;
+ };
+ };
+} __packed;
+
+struct intel_slpc_display_mode_event_params {
+ struct {
+ struct intel_display_pipe_info
per_pipe_info[SLPC_MAX_NUM_OF_PIPES];
+ union {
+ u32 global_data;
+ struct {
+ u32 active_pipes_bitmask:SLPC_MAX_NUM_OF_PIPES;
+ u32 fullscreen_pipes:SLPC_MAX_NUM_OF_PIPES;
+ u32 vbi_sync_on_pipes:SLPC_MAX_NUM_OF_PIPES;
+ u32 num_active_pipes:2;
+ };
+ };
+ };
+} __packed;
+
struct intel_slpc {
struct drm_i915_gem_object *shared_data_obj;
+ struct intel_slpc_display_mode_event_params display_mode_params;
};
/* intel_slpc.c */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/25] drm/i915/slpc: Add enable_slpc module parameter
From: Tom O'Rourke
i915.enable_slpc is used to override the default for slpc usage.
The expected values are -1=auto, 0=disabled [default], 1=enabled.
slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1.
Interpretation of default value is based on HAS_SLPC(), after
slpc_version_check(). This function also enforces the requirement
that guc_submission is required for slpc.
intel_slpc_enabled() returns 1 if SLPC should be used.
v2: Add early call to sanitize enable_slpc in intel_guc_ucode_init
Suggested-by: Paulo Zanoni
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_params.c | 6 ++
drivers/gpu/drm/i915/i915_params.h | 1 +
drivers/gpu/drm/i915/intel_guc.h| 6 ++
drivers/gpu/drm/i915/intel_guc_loader.c | 19 +++
4 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02..0f162a8 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -36,6 +36,7 @@ struct i915_params i915 __read_mostly = {
.enable_dc = -1,
.enable_fbc = -1,
.enable_execlists = -1,
+ .enable_slpc = 0,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = -1,
@@ -127,6 +128,11 @@ MODULE_PARM_DESC(enable_execlists,
"Override execlists usage. "
"(-1=auto [default], 0=disabled, 1=enabled)");
+module_param_named_unsafe(enable_slpc, i915.enable_slpc, int, 0400);
+MODULE_PARM_DESC(enable_slpc,
+ "Override single-loop-power-controller (slpc) usage. "
+ "(-1=auto, 0=disabled [default], 1=enabled)");
+
module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
MODULE_PARM_DESC(enable_psr, "Enable PSR "
"(0=disabled, 1=enabled - link mode chosen per-platform,
2=force link-standby mode, 3=force link-off mode) "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 02bc278..3f8eb82 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -39,6 +39,7 @@ struct i915_params {
int enable_fbc;
int enable_ppgtt;
int enable_execlists;
+ int enable_slpc;
int enable_psr;
unsigned int preliminary_hw_support;
int disable_power_well;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index b18f5c3..298e243 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -110,6 +110,12 @@ struct intel_guc {
uint32_t last_seqno[GUC_MAX_ENGINES_NUM];
};
+static inline int intel_slpc_enabled(void)
+{
+ WARN_ON(i915.enable_slpc < 0);
+ return i915.enable_slpc;
+}
+
/* intel_guc_loader.c */
extern void intel_guc_ucode_init(struct drm_device *dev);
extern int intel_guc_ucode_load(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 00a0ffe..5dd2d9e 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -116,6 +116,21 @@ static void direct_interrupts_to_guc(struct
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, ~irqs);
}
+static void slpc_enable_sanitize(struct drm_device *dev)
+{
+ /* handle default case */
+ if (i915.enable_slpc < 0)
+ i915.enable_slpc = HAS_SLPC(dev);
+
+ /* slpc requires hardware support and compatible firmware */
+ if (!HAS_SLPC(dev))
+ i915.enable_slpc = 0;
+
+ /* slpc requires guc submission */
+ if (!i915.enable_guc_submission)
+ i915.enable_slpc = 0;
+}
+
static void slpc_version_check(struct drm_device *dev, struct intel_guc_fw
*guc_fw)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -125,6 +140,8 @@ static void slpc_version_check(struct drm_device *dev,
struct intel_guc_fw *guc_
info = (struct intel_device_info *) &dev_priv->info;
info->has_slpc = 0;
}
+
+ slpc_enable_sanitize(dev);
}
static u32 get_gttype(struct drm_i915_private *dev_priv)
@@ -656,6 +673,8 @@ void intel_guc_ucode_init(struct drm_device *dev)
fw_path = ""; /* unknown device */
}
+ slpc_enable_sanitize(dev);
+
if (!i915.enable_guc_submission)
return;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/25] drm/i915/slpc: Add i915_slpc_info to debugfs
From: Tom O'Rourke
i915_slpc_info shows the contents of SLPC shared data
parsed into text format.
v2: reformat slpc info (Radek)
squashed query task state info
in slpc info, kunmap before seq_print (Paulo)
return void instead of ignored return value (Paulo)
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_debugfs.c | 184
drivers/gpu/drm/i915/intel_slpc.c | 23 +
drivers/gpu/drm/i915/intel_slpc.h | 1 +
3 files changed, 208 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0f147af..32658b9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1371,6 +1371,189 @@ static const struct file_operations i915_slpc_dcc_fops
= {
.llseek = seq_lseek
};
+static int i915_slpc_info(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj;
+ struct page *page;
+ void *pv = NULL;
+ struct slpc_shared_data data;
+ int i, value;
+ enum slpc_global_state global_state;
+ enum slpc_platform_sku platform_sku;
+ enum slpc_host_os host_os;
+ enum slpc_power_plan power_plan;
+ enum slpc_power_source power_source;
+
+ obj = dev_priv->guc.slpc.shared_data_obj;
+ if (obj) {
+ intel_slpc_query_task_state(dev);
+
+ page = i915_gem_object_get_page(obj, 0);
+ if (page)
+ pv = kmap_atomic(page);
+ }
+
+ if (pv) {
+ data = *(struct slpc_shared_data *) pv;
+ kunmap_atomic(pv);
+
+ seq_printf(m, "SLPC Version: %d.%d.%d (0x%8x)\n",
+ data.slpc_version >> 16,
+ (data.slpc_version >> 8) & 0xFF,
+ data.slpc_version & 0xFF,
+ data.slpc_version);
+ seq_printf(m, "shared data size: %d\n", data.shared_data_size);
+
+ seq_printf(m, "global state: %d (", data.global_state);
+ global_state = (enum slpc_global_state) data.global_state;
+ switch (global_state) {
+ case SLPC_GLOBAL_STATE_NOT_RUNNING:
+ seq_puts(m, "not running)\n");
+ break;
+ case SLPC_GLOBAL_STATE_INITIALIZING:
+ seq_puts(m, "initializing)\n");
+ break;
+ case SLPC_GLOBAL_STATE_RESETING:
+ seq_puts(m, "resetting)\n");
+ break;
+ case SLPC_GLOBAL_STATE_RUNNING:
+ seq_puts(m, "running)\n");
+ break;
+ case SLPC_GLOBAL_STATE_SHUTTING_DOWN:
+ seq_puts(m, "shutting down)\n");
+ break;
+ case SLPC_GLOBAL_STATE_ERROR:
+ seq_puts(m, "error)\n");
+ break;
+ default:
+ seq_puts(m, "unknown)\n");
+ break;
+ }
+
+ seq_printf(m, "sku: %d (", data.platform_info.platform_sku);
+ platform_sku = (enum slpc_platform_sku)
+ data.platform_info.platform_sku;
+ switch (platform_sku) {
+ case SLPC_PLATFORM_SKU_UNDEFINED:
+ seq_puts(m, "undefined)\n");
+ break;
+ case SLPC_PLATFORM_SKU_ULX:
+ seq_puts(m, "ULX)\n");
+ break;
+ case SLPC_PLATFORM_SKU_ULT:
+ seq_puts(m, "ULT)\n");
+ break;
+ case SLPC_PLATFORM_SKU_T:
+ seq_puts(m, "T)\n");
+ break;
+ case SLPC_PLATFORM_SKU_MOBL:
+ seq_puts(m, "Mobile)\n");
+ break;
+ case SLPC_PLATFORM_SKU_DT:
+ seq_puts(m, "DT)\n");
+ break;
+ case SLPC_PLATFORM_SKU_UNKNOWN:
+ default:
+ seq_puts(m, "unknown)\n");
+ break;
+ }
+ seq_printf(m, "slice count: %d\n",
+ data.platform_info.slice_count);
+
+ seq_printf(m, "host OS: %d (", data.platform_info.host_os);
+ host_os = (enum slpc_host_os) data.platform_info.host_os;
+ switch (host_os) {
+ case SLPC_HOST_OS_UNDEFINED:
+ seq_puts(m, "undefined)\n");
+ break;
+ case SLPC_HOST_OS_WINDOWS_8:
+ seq_puts(m, "Windows 8)\n");
+ break;
+
[Intel-gfx] [PATCH 11/25] drm/i915/slpc: Send reset event
From: Tom O'Rourke
Add host2guc SLPC reset event and send reset event
during enable.
v2: extract host2guc_slpc to handle slpc status code
coding style changes (Paulo)
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_slpc.c | 33 -
drivers/gpu/drm/i915/intel_slpc.h | 14 ++
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index 7450b3c..76e5ba9 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -26,6 +26,36 @@
#include "i915_drv.h"
#include "intel_guc.h"
+static void host2guc_slpc(struct drm_i915_private *dev_priv, u32 *data, u32
len)
+{
+ int ret = host2guc_action(&dev_priv->guc, data, len);
+
+ if (!ret) {
+ ret = I915_READ(SOFT_SCRATCH(1));
+ ret &= SLPC_EVENT_STATUS_MASK;
+ }
+
+ if (ret)
+ DRM_ERROR("event 0x%x status %d\n", (data[1] >> 8), ret);
+}
+
+static void host2guc_slpc_reset(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj = dev_priv->guc.slpc.shared_data_obj;
+ u32 data[4];
+ u64 shared_data_gtt_offset = i915_gem_obj_ggtt_offset(obj);
+
+ data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+ data[1] = SLPC_EVENT(SLPC_EVENT_RESET, 2);
+ data[2] = lower_32_bits(shared_data_gtt_offset);
+ data[3] = upper_32_bits(shared_data_gtt_offset);
+
+ WARN_ON(data[3] != 0);
+
+ host2guc_slpc(dev_priv, data, 4);
+}
+
static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
{
struct drm_device *dev = obj->base.dev;
@@ -132,7 +162,8 @@ void intel_slpc_disable(struct drm_device *dev)
void intel_slpc_enable(struct drm_device *dev)
{
- return;
+ if (intel_slpc_active(dev))
+ host2guc_slpc_reset(dev);
}
void intel_slpc_reset(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_slpc.h
b/drivers/gpu/drm/i915/intel_slpc.h
index 94cd2f4..7f33a04 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -28,6 +28,20 @@
#define SLPC_MINOR_VER 4
#define SLPC_VERSION ((2015 << 16) | (SLPC_MAJOR_VER << 8) | (SLPC_MINOR_VER))
+enum slpc_event_id {
+ SLPC_EVENT_RESET = 0,
+ SLPC_EVENT_SHUTDOWN = 1,
+ SLPC_EVENT_PLATFORM_INFO_CHANGE = 2,
+ SLPC_EVENT_DISPLAY_MODE_CHANGE = 3,
+ SLPC_EVENT_FLIP_COMPLETE = 4,
+ SLPC_EVENT_QUERY_TASK_STATE = 5,
+ SLPC_EVENT_PARAMETER_SET = 6,
+ SLPC_EVENT_PARAMETER_UNSET = 7,
+};
+
+#define SLPC_EVENT(id, argc) ((u32) (id) << 8 | (argc))
+#define SLPC_EVENT_STATUS_MASK 0xFF
+
enum slpc_global_state {
SLPC_GLOBAL_STATE_NOT_RUNNING = 0,
SLPC_GLOBAL_STATE_INITIALIZING = 1,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/25] drm/i915/slpc: Notification of Refresh Rate change
From: Sagar Arun Kamble
This patch will inform GuC SLPC about changes in the refresh rate
due to Seamless DRRS. Refresh rate changes due to Static DRRS will
be notified via commit path.
v2: Rebased on previous changed patch and printed error message if
H2G action fails.
v2(torourke): Updates suggested by Paulo: replace HAS_SLPC with
intel_slpc_active. return void instead of ignored error code.
Signed-off-by: Sagar Arun Kamble
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_slpc.c | 23 +++
drivers/gpu/drm/i915/intel_slpc.h | 1 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..c30390d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5433,6 +5433,8 @@ static void intel_dp_set_drrs_state(struct drm_device
*dev, int refresh_rate)
dev_priv->drrs.refresh_rate_type = index;
DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
+
+ intel_slpc_update_display_rr_info(dev, refresh_rate);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index f476670..88b4279 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -332,3 +332,26 @@ void intel_slpc_update_atomic_commit_info(struct
drm_device *dev,
host2guc_slpc_display_mode_change(dev);
}
}
+
+void intel_slpc_update_display_rr_info(struct drm_device *dev, u32
refresh_rate)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_crtc *crtc;
+ struct intel_display_pipe_info *per_pipe_info;
+ struct intel_slpc_display_mode_event_params *display_params;
+
+ if (!intel_slpc_active(dev))
+ return;
+
+ if (!refresh_rate)
+ return;
+
+ display_params = &dev_priv->guc.slpc.display_mode_params;
+ crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+
+ per_pipe_info =
&display_params->per_pipe_info[to_intel_crtc(crtc)->pipe];
+ per_pipe_info->refresh_rate = refresh_rate;
+ per_pipe_info->vsync_ft_usec = 100 / refresh_rate;
+
+ host2guc_slpc_display_mode_change(dev);
+}
diff --git a/drivers/gpu/drm/i915/intel_slpc.h
b/drivers/gpu/drm/i915/intel_slpc.h
index d560d86..06f1b28 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -152,5 +152,6 @@ void intel_slpc_reset(struct drm_device *dev);
void intel_slpc_update_display_mode_info(struct drm_device *dev);
void intel_slpc_update_atomic_commit_info(struct drm_device *dev,
struct drm_atomic_state *state);
+void intel_slpc_update_display_rr_info(struct drm_device *dev, u32
refresh_rate);
#endif
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/25] drm/i915/slpc: Add slpc_version_check
From: Tom O'Rourke
The SLPC interface has changed and could continue to
change. Only GuC versions known to be compatible are
supported here.
On Skylake, GuC firmware v6 is supported. Other
platforms and versions can be added here later.
This patch also adds has_slpc to skylake info.
v2: Move slpc_version_check to intel_guc_ucode_init
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/intel_guc_loader.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 020a31c..f2c7c72 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -334,6 +334,7 @@ static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
+ .has_slpc = 1,
};
static const struct intel_device_info intel_skylake_gt3_info = {
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 876e5da..00a0ffe 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -116,6 +116,17 @@ static void direct_interrupts_to_guc(struct
drm_i915_private *dev_priv)
I915_WRITE(GUC_WD_VECS_IER, ~irqs);
}
+static void slpc_version_check(struct drm_device *dev, struct intel_guc_fw
*guc_fw)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_device_info *info;
+
+ if (IS_SKYLAKE(dev) && (guc_fw->guc_fw_major_found != 6)) {
+ info = (struct intel_device_info *) &dev_priv->info;
+ info->has_slpc = 0;
+ }
+}
+
static u32 get_gttype(struct drm_i915_private *dev_priv)
{
/* XXX: GT type based on PCI device ID? field seems unused by fw */
@@ -666,6 +677,8 @@ void intel_guc_ucode_init(struct drm_device *dev)
DRM_DEBUG_DRIVER("GuC firmware pending, path %s\n", fw_path);
guc_fw_fetch(dev, guc_fw);
/* status must now be FAIL or SUCCESS */
+
+ slpc_version_check(dev, guc_fw);
}
/**
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 25/25] DO NOT MERGE: drm/i915: Enable SLPC, where supported
From: Tom O'Rourke
This patch makes SLPC enabled by default on
platforms with hardware/firmware support.
DO NOT MERGE: This patch is added for convenience in
reviewing SLPC patch series. This patch should be
merged after validation results show benefits of using SLPC.
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 1cf0637..525ffe6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -36,7 +36,7 @@ struct i915_params i915 __read_mostly = {
.enable_dc = -1,
.enable_fbc = -1,
.enable_execlists = -1,
- .enable_slpc = 0,
+ .enable_slpc = -1,
.enable_hangcheck = true,
.enable_ppgtt = -1,
.enable_psr = -1,
@@ -131,7 +131,7 @@ MODULE_PARM_DESC(enable_execlists,
module_param_named_unsafe(enable_slpc, i915.enable_slpc, int, 0400);
MODULE_PARM_DESC(enable_slpc,
"Override single-loop-power-controller (slpc) usage. "
- "(-1=auto, 0=disabled [default], 1=enabled)");
+ "(-1=auto [default], 0=disabled, 1=enabled)");
module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
MODULE_PARM_DESC(enable_psr, "Enable PSR "
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/25] drm/i915/slpc: Add parameter unset/set/get functions
From: Tom O'Rourke
Add slpc_param_id enum values.
Add events for setting/unsetting parameters.
v2: use host2guc_slpc
update slcp_param_id enum values for SLPC 2015.2.4
return void instead of ignored error code (Paulo)
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_slpc.c | 104 ++
drivers/gpu/drm/i915/intel_slpc.h | 26 +-
2 files changed, 129 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_slpc.c
b/drivers/gpu/drm/i915/intel_slpc.c
index 88b4279..601af07 100644
--- a/drivers/gpu/drm/i915/intel_slpc.c
+++ b/drivers/gpu/drm/i915/intel_slpc.c
@@ -88,6 +88,33 @@ static void host2guc_slpc_display_mode_change(struct
drm_device *dev)
host2guc_slpc(dev_priv, data, 7);
}
+static void host2guc_slpc_set_param(struct drm_device *dev,
+ enum slpc_param_id id, u32 value)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 data[4];
+
+ data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+ data[1] = SLPC_EVENT(SLPC_EVENT_PARAMETER_SET, 2);
+ data[2] = (u32) id;
+ data[3] = value;
+
+ host2guc_slpc(dev_priv, data, 4);
+}
+
+static void host2guc_slpc_unset_param(struct drm_device *dev,
+ enum slpc_param_id id)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 data[3];
+
+ data[0] = HOST2GUC_ACTION_SLPC_REQUEST;
+ data[1] = SLPC_EVENT(SLPC_EVENT_PARAMETER_UNSET, 1);
+ data[2] = (u32) id;
+
+ host2guc_slpc(dev_priv, data, 3);
+}
+
static u8 slpc_get_platform_sku(struct drm_i915_gem_object *obj)
{
struct drm_device *dev = obj->base.dev;
@@ -355,3 +382,80 @@ void intel_slpc_update_display_rr_info(struct drm_device
*dev, u32 refresh_rate)
host2guc_slpc_display_mode_change(dev);
}
+
+void intel_slpc_unset_param(struct drm_device *dev, enum slpc_param_id id)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj;
+ struct page *page;
+ struct slpc_shared_data *data = NULL;
+
+ obj = dev_priv->guc.slpc.shared_data_obj;
+ if (obj) {
+ page = i915_gem_object_get_page(obj, 0);
+ if (page)
+ data = kmap_atomic(page);
+ }
+
+ if (data) {
+ data->override_parameters_set_bits[id >> 5]
+ &= (~(1 << (id % 32)));
+ data->override_parameters_values[id] = 0;
+ kunmap_atomic(data);
+
+ host2guc_slpc_unset_param(dev, id);
+ }
+}
+
+void intel_slpc_set_param(struct drm_device *dev, enum slpc_param_id id,
+ u32 value)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj;
+ struct page *page;
+ struct slpc_shared_data *data = NULL;
+
+ obj = dev_priv->guc.slpc.shared_data_obj;
+ if (obj) {
+ page = i915_gem_object_get_page(obj, 0);
+ if (page)
+ data = kmap_atomic(page);
+ }
+
+ if (data) {
+ data->override_parameters_set_bits[id >> 5]
+ |= (1 << (id % 32));
+ data->override_parameters_values[id] = value;
+ kunmap_atomic(data);
+
+ host2guc_slpc_set_param(dev, id, value);
+ }
+}
+
+void intel_slpc_get_param(struct drm_device *dev, enum slpc_param_id id,
+ int *overriding, u32 *value)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj;
+ struct page *page;
+ struct slpc_shared_data *data = NULL;
+ u32 bits;
+
+ obj = dev_priv->guc.slpc.shared_data_obj;
+ if (obj) {
+ page = i915_gem_object_get_page(obj, 0);
+ if (page)
+ data = kmap_atomic(page);
+ }
+
+ if (data) {
+ if (overriding) {
+ bits = data->override_parameters_set_bits[id >> 5];
+ *overriding = (0 != (bits & (1 << (id % 32;
+ }
+ if (value)
+ *value = data->override_parameters_values[id];
+
+ kunmap_atomic(data);
+ }
+}
diff --git a/drivers/gpu/drm/i915/intel_slpc.h
b/drivers/gpu/drm/i915/intel_slpc.h
index de2df0c..b7ad440 100644
--- a/drivers/gpu/drm/i915/intel_slpc.h
+++ b/drivers/gpu/drm/i915/intel_slpc.h
@@ -69,6 +69,26 @@ enum slpc_event_id {
#define SLPC_EVENT(id, argc) ((u32) (id) << 8 | (argc))
#define SLPC_EVENT_STATUS_MASK 0xFF
+enum slpc_param_id {
+ SLPC_PARAM_TASK_ENABLE_GTPERF = 0,
+ SLPC_PARAM_TASK_DISABLE_GTPERF = 1,
+ SLPC_PARAM_TASK_ENABLE_BALANCER = 2,
+ SLPC_PARAM_TASK_DISABLE_BALANCER = 3,
+ SLPC_PARAM_TASK_ENABLE_DCC = 4,
+
[Intel-gfx] [PATCH v3 00/25] Add support for GuC-based SLPC
From: Tom O'Rourke SLPC (Single Loop Power Controller) is a replacement for some host-based power management features. The SLPC implemenation runs in firmware on GuC. This series has been tested with SKL guc firmware version 6.1 and BXT guc version 5.1. The graphics power management features in SLPC in those versions are called GTPERF, BALANCER, and DCC. GTPERF is a combination of DFPS (Dynamic FPS) and Turbo. DFPS adjusts requested graphics frequency to maintain target framerate. Turbo adjusts requested graphics frequency to maintain target GT busyness; this includes an adaptive boost turbo method. BALANCER adjusts balance between power budgets for IA and GT in power limited scenarios. BALANCER is only active when all display pipes are in "game" mode. DCC (Duty Cycle Control) adjusts requested graphics frequency and stalls guc-scheduler to maintain actual graphics frequency in efficient range. The v2 series was a followup to the request for comments "[Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC" https://lists.freedesktop.org/archives/intel-gfx/2016-January/085830.html The v2 series can be found in the archive at "[Intel-gfx] [PATCH v2 00/26] Add support for GuC-based SLPC" https://lists.freedesktop.org/archives/intel-gfx/2016-March/089259.html Thank you to Paulo for his valuable review of the RFC series. Thank you also to Ville, Daniel, Jesse, and Martin for their helpful comments. We (Tom and Sagar) have attempted to incorporate these suggestions in this series. We also adapted to a new SLPC interface version that reflects an internal reorganization within the firmware. The biggest change refactored the tasks. The DFPS and Turbo tasks were merged into the GTPERF task. The IBC (Intelligent Bias Control) feature that had been grouped with Turbo was split out into the BALANCER task. The requested frequency can be fixed by setting min and max to the same value. As before, the actual frequency is controlled by the punit. In addition to the debugfs files to enable/disable each task, there is a module parameter to completely disable SLPC. By default, SLPC will be disabled by module parameter. Benchmarks showing power/performance results are expected before enabling SLPC by default. We anticipate DFPS and BALANCER will not be effective on Linux systems due to difficulty determining frame rate with a compositor and display not in "game" mode. GTPERF (Turbo) and DCC should be effective. This v3 series is sent primarily to re-run CI tests now that SKL guc v6.1 has been published and the CI machines have been updated. The series has also been rebased on the latest drm-intel-nightly and there were minor updates to 3 patches (3/25, 4/25, 8/25). Patches 22/25 to 25/25 are included for convenience in testing this series and are not intended to be merged at this time. SLPC requires guc submission and should be disabled if guc submission is not enabled. VIZ-6773, VIZ-6889 Dave Gordon (1): DO NOT MERGE: drm/i915: Enable GuC submission, where supported Peter Antoine (1): DO NOT MERGE: drm/i915: resize the GuC WOPCM for rc6 Sagar Arun Kamble (3): drm/i915/slpc: Add Display mode event related data structures drm/i915/slpc: Notification of Display mode change drm/i915/slpc: Notification of Refresh Rate change Tom O'Rourke (20): drm/i915/slpc: Expose guc functions for use with SLPC drm/i915/slpc: Add has_slpc capability flag drm/i915/slpc: Add slpc_version_check drm/i915/slpc: Add enable_slpc module parameter drm/i915/slpc: Use intel_slpc_* functions if supported drm/i915/slpc: Enable SLPC in guc if supported drm/i915/slpc: If using SLPC, do not set frequency drm/i915/slpc: Allocate/Release/Initialize SLPC shared data drm/i915/slpc: Setup rps frequency values during SLPC init drm/i915/slpc: Update current requested frequency drm/i915/slpc: Send reset event drm/i915/slpc: Send shutdown event drm/i915/slpc: Add slpc_status enum values drm/i915/slpc: Add parameter unset/set/get functions drm/i915/slpc: Add slpc support for max/min freq drm/i915/slpc: Add enable/disable debugfs for slpc drm/i915/slpc: Add broxton support drm/i915/slpc: Add i915_slpc_info to debugfs DO NOT MERGE: drm/i915/bxt: Add Broxton to guc loader DO NOT MERGE: drm/i915: Enable SLPC, where supported drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/i915_debugfs.c| 456 +++ drivers/gpu/drm/i915/i915_drv.c| 2 + drivers/gpu/drm/i915/i915_drv.h| 2 + drivers/gpu/drm/i915/i915_guc_reg.h| 3 +- drivers/gpu/drm/i915/i915_guc_submission.c | 6 +- drivers/gpu/drm/i915/i915_params.c | 10 +- drivers/gpu/drm/i915/i915_params.h | 1 + drivers/gpu/drm/i915/i915_sysfs.c | 20 ++ drivers/gpu/drm/i915/intel_display.c | 2 + drivers/gpu/drm/i915/intel_dp.c| 2 + drivers/gpu/drm/i915/intel_drv.h | 12 + drivers/gpu/drm/i915
[Intel-gfx] [PATCH 07/25] drm/i915/slpc: If using SLPC, do not set frequency
From: Tom O'Rourke
When frequency requests are made by SLPC, host driver
should not attempt to make frequency requests due to
potential conflicts.
Host-based turbo operations are already avoided when
SLPC is used. This change covers other frequency
requests such as from sysfs or debugfs interfaces.
A later patch in this series updates sysfs/debugfs
interfaces for setting max/min frequencies with SLPC.
v2: Use intel_slpc_active instead of HAS_SLPC (Paulo)
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_pm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a6246bf..be314cf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4567,6 +4567,9 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv,
void intel_set_rps(struct drm_device *dev, u8 val)
{
+ if (intel_slpc_active(dev))
+ return;
+
if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
valleyview_set_rps(dev, val);
else
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/25] drm/i915/slpc: Add enable/disable debugfs for slpc
From: Tom O'Rourke
Adds debugfs hooks for each slpc task.
The enable/disable debugfs files are
i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc.
Each of these can take the values:
"default", "enabled", or "disabled"
v2: update for SLPC v2015.2.4
dfps and turbo merged and renamed "gtperf"
ibc split out and renamed "balancer"
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/i915_debugfs.c | 250
1 file changed, 250 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5f0d72b..0f147af 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1124,6 +1124,253 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
i915_next_seqno_get, i915_next_seqno_set,
"0x%llx\n");
+static int slpc_enable_disable_get(struct drm_device *dev, u64 *val,
+ enum slpc_param_id enable_id,
+ enum slpc_param_id disable_id)
+{
+ int override_enable, override_disable;
+ u32 value_enable, value_disable;
+ int ret = 0;
+
+ if (!intel_slpc_active(dev)) {
+ ret = -ENODEV;
+ } else if (val) {
+ intel_slpc_get_param(dev, enable_id, &override_enable,
+&value_enable);
+ intel_slpc_get_param(dev, disable_id, &override_disable,
+&value_disable);
+
+ /* set the output value:
+ * 0: default
+ * 1: enabled
+ * 2: disabled
+ * 3: unknown (should not happen)
+ */
+ if (override_disable && (1 == value_disable))
+ *val = 2;
+ else if (override_enable && (1 == value_enable))
+ *val = 1;
+ else if (!override_enable && !override_disable)
+ *val = 0;
+ else
+ *val = 3;
+
+ } else {
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static int slpc_enable_disable_set(struct drm_device *dev, u64 val,
+ enum slpc_param_id enable_id,
+ enum slpc_param_id disable_id)
+{
+ int ret = 0;
+
+ if (!intel_slpc_active(dev)) {
+ ret = -ENODEV;
+ } else if (0 == val) {
+ /* set default */
+ intel_slpc_unset_param(dev, enable_id);
+ intel_slpc_unset_param(dev, disable_id);
+ } else if (1 == val) {
+ /* set enable */
+ intel_slpc_set_param(dev, enable_id, 1);
+ intel_slpc_unset_param(dev, disable_id);
+ } else if (2 == val) {
+ /* set disable */
+ intel_slpc_set_param(dev, disable_id, 1);
+ intel_slpc_unset_param(dev, enable_id);
+ } else {
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+static void slpc_param_show(struct seq_file *m, enum slpc_param_id enable_id,
+ enum slpc_param_id disable_id)
+{
+ struct drm_device *dev = m->private;
+ const char *status;
+ u64 val;
+ int ret;
+
+ ret = slpc_enable_disable_get(dev, &val, enable_id, disable_id);
+
+ if (ret) {
+ seq_printf(m, "error %d\n", ret);
+ } else {
+ switch (val) {
+ case 0:
+ status = "default\n";
+ break;
+
+ case 1:
+ status = "enabled\n";
+ break;
+
+ case 2:
+ status = "disabled\n";
+ break;
+
+ default:
+ status = "unknown\n";
+ break;
+ }
+
+ seq_puts(m, status);
+ }
+}
+
+static int slpc_param_write(struct seq_file *m, const char __user *ubuf,
+ size_t len, enum slpc_param_id enable_id,
+ enum slpc_param_id disable_id)
+{
+ struct drm_device *dev = m->private;
+ u64 val;
+ int ret = 0;
+ char buf[10];
+
+ if (len >= sizeof(buf))
+ ret = -EINVAL;
+ else if (copy_from_user(buf, ubuf, len))
+ ret = -EFAULT;
+ else
+ buf[len] = '\0';
+
+ if (!ret) {
+ if (!strncmp(buf, "default", 7))
+ val = 0;
+ else if (!strncmp(buf, "enabled", 7))
+ val = 1;
+ else if (!strncmp(buf, "disabled", 8))
+ val = 2;
+ else
+ ret = -EINVAL;
+ }
+
+ if (!ret)
+ ret = slpc_enable_disable_set(dev, val, enable_id, disable_id);
+
+ return ret;
+}
+
+static in
[Intel-gfx] [PATCH 23/25] DO NOT MERGE: drm/i915: resize the GuC WOPCM for rc6
From: Peter Antoine This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory spaces do not overlap. DO NOT MERGE: This patch is expected as part of another series and is included for convenience in testing this series. Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter Antoine Signed-off-by: Jeff McGee Acked-by: Tom O'Rourke --- drivers/gpu/drm/i915/i915_guc_reg.h | 3 ++- drivers/gpu/drm/i915/intel_guc_loader.c | 6 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h b/drivers/gpu/drm/i915/i915_guc_reg.h index 80786d9..0a86599 100644 --- a/drivers/gpu/drm/i915/i915_guc_reg.h +++ b/drivers/gpu/drm/i915/i915_guc_reg.h @@ -68,7 +68,8 @@ #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4) #define GUC_WOPCM_SIZE _MMIO(0xc050) -#define GUC_WOPCM_SIZE_VALUE (0x80 << 12) /* 512KB */ +#define GUC_WOPCM_SIZE_VALUE (0x80 << 12)/* 512KB */ +#define BXT_GUC_WOPCM_SIZE_VALUE (0x70 << 12)/* 448KB */ /* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */ #defineGUC_WOPCM_TOP (GUC_WOPCM_SIZE_VALUE) diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c index a46dd93..a9429d9 100644 --- a/drivers/gpu/drm/i915/intel_guc_loader.c +++ b/drivers/gpu/drm/i915/intel_guc_loader.c @@ -343,7 +343,11 @@ static int guc_ucode_xfer(struct drm_i915_private *dev_priv) intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); /* init WOPCM */ - I915_WRITE(GUC_WOPCM_SIZE, GUC_WOPCM_SIZE_VALUE); + if (IS_BROXTON(dev)) + I915_WRITE(GUC_WOPCM_SIZE, BXT_GUC_WOPCM_SIZE_VALUE); + else + I915_WRITE(GUC_WOPCM_SIZE, GUC_WOPCM_SIZE_VALUE); + I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE); /* Enable MIA caching. GuC clock gating is disabled. */ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/25] DO NOT MERGE: drm/i915/bxt: Add Broxton to guc loader
From: Tom O'Rourke
This patch is expected as part of another series
and is included for convenience in testing this
series.
Do not merge unless Broxton guc v5 firmware is available.
Signed-off-by: Tom O'Rourke
---
drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 3a61aac..a46dd93 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -62,6 +62,9 @@
#define I915_SKL_GUC_UCODE "i915/skl_guc_ver6.bin"
MODULE_FIRMWARE(I915_SKL_GUC_UCODE);
+#define I915_BXT_GUC_UCODE "i915/bxt_guc_ver5.bin"
+MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
+
/* User-friendly representation of an enum */
const char *intel_guc_fw_status_repr(enum intel_guc_fw_status status)
{
@@ -672,6 +675,10 @@ void intel_guc_ucode_init(struct drm_device *dev)
fw_path = I915_SKL_GUC_UCODE;
guc_fw->guc_fw_major_wanted = 6;
guc_fw->guc_fw_minor_wanted = 1;
+ } else if (IS_BROXTON(dev)) {
+ fw_path = I915_BXT_GUC_UCODE;
+ guc_fw->guc_fw_major_wanted = 5;
+ guc_fw->guc_fw_minor_wanted = 0;
} else {
i915.enable_guc_submission = false;
fw_path = ""; /* unknown device */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
