[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Document code of conduct
== Series Details == Series: drm: Document code of conduct URL : https://patchwork.freedesktop.org/series/22830/ State : warning == Summary == Series 22830v1 drm: Document code of conduct https://patchwork.freedesktop.org/api/1.0/series/22830/revisions/1/mbox/ Test gem_exec_basic: Subgroup basic-render: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-bsd: pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-snb-2600) Subgroup gtt-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup gtt-render: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-blt: pass -> DMESG-WARN (fi-snb-2520m) Subgroup readonly-bsd: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-render: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_fence: Subgroup basic-busy-default: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-wait-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_reloc: Subgroup basic-cpu-active: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-gtt-active: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-gtt-read-active: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-write-cpu-active: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-write-read-active: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_store: Subgroup basic-all: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_suspend: Subgroup basic: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test gem_mmap_gtt: Subgroup basic-copy: pass -> DMESG-WARN (fi-snb-2520m) fdo#100643 Subgroup basic-read: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-read-no-prefault: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-read-write: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-short: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-small-bo: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ringfill: Subgroup basic-default-fd: pass -> DMESG-WARN (fi-snb-2520m) Test kms_addfb_basic: Subgroup basic: pass -> DMESG-WARN (fi-snb-2600) Subgroup basic-x-tiled: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup framebuffer-vs-set-tiling: pass -> DMESG-WARN (fi-snb-2600) Subgroup invalid-get-prop: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup size-max: pass -> DMESG-WARN (fi-snb-2600) Subgroup small-bo: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup unused-modifier: pass -> DMESG-WARN (fi-snb-2600) Subgroup unused-offsets: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> DMESG-WARN (fi-kbl-7560u) Test kms_force_connector_basic: Subgroup force-edid: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup prune-stale-modes: pass -> DMESG-WARN (fi-snb-2600) fdo#100643 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100445 Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (fi-snb-2600) Test prime_vgem: Subgroup basic-read: pass -> DMESG-WARN (fi-snb-2520m) Subgroup basic-sync-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 WARNING: Long output truncated e461ecfd413fb930d00f44f3de0019e528b4731f drm-tip: 2017y-04m-10d-14h-25m-24s UTC integration manifest f254fbc drm: Document code of conduct == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4468/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
Hi, On 11 April 2017 at 07:48, Daniel Vetter wrote: > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. All true. Reviewed-by: Daniel Stone Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On 11 April 2017 at 12:38, Daniel Stone wrote: > Hi, > > On 11 April 2017 at 07:48, Daniel Vetter wrote: >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> started chatting with the communities their hosting, which includs the >> X.org foundation board, to figure out how to fan out enforcement and >> allow projects to run things on their own (with fd.o still as the >> fallback). So the details of enforcement (and appealing decisions) >> might still change, but since this involves the board and lots more >> people it'll take a while to get there. For now this is good enough I >> think. > > All true. > > Reviewed-by: Daniel Stone > Thanks for this, Daniel! Reviewed-by: Sumit Semwal Best, Sumit. > Cheers, > Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_concurrent: Concurrent and interruptible subtests for atomic
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Monday, April 10, 2017 3:39 PM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH i-g-t v2] tests/kms_concurrent: Concurrent and
> interruptible
> subtests for atomic
>
> Op 10-04-17 om 14:11 schreef Mika Kahola:
> > On Wed, 2017-03-29 at 11:53 +0200, Maarten Lankhorst wrote:
> >> Op 15-03-17 om 09:43 schreef Mika Kahola:
> >>> This test case introduces concurrently running test cases for atomic
> >>> modesetting.
> >>>
> >>> The first test or thread draws blue backround with black holes on
> >>> it.
> >>> These holes are covered by rectangular, blue planes that are placed
> >>> randomly like in test case 'kms_plane_multiple'.
> >>>
> >>> The second thread changes resolution from higher to lower one and
> >>> back.
> >>> The delay between resolution changes is randomly selected between
> >>> 20 and
> >>> 50 milliseconds.
> >>>
> >>> The test runs by default 32 iterations to increase the coverage.
> >>>
> >>> v2: use igt_fork instead of pthreads to create concurrent test runs
> >>> (Maarten)
> >>>
> >>> Signed-off-by: Mika Kahola
> >>> ---
> >>> tests/Makefile.sources | 1 +
> >>> tests/kms_concurrent.c | 630
> >>> +
> >>> 2 files changed, 631 insertions(+)
> >>> create mode 100644 tests/kms_concurrent.c
> >>>
> >>>
> >>> +static int
> >>> +display_commit_mode(data_t *data, igt_crc_t *crc) {
> >>> + char buf[256];
> >>> + struct drm_event *e = (void *)buf;
> >>> + int n, ret;
> >>> + int flags = DRM_MODE_PAGE_FLIP_EVENT |
> >>> DRM_MODE_ATOMIC_ALLOW_MODESET |
> DRM_MODE_ATOMIC_NONBLOCK;
> >>> +
> >>> + ret = igt_display_try_commit_atomic(&data->display,
> >>> + flags,
> >>> + NULL);
> >>> + igt_skip_on(ret != 0);
> >>> +
> >>> + igt_set_timeout(1, "Stuck on page flip");
> >>> + ret = read(data->display.drm_fd, buf, sizeof(buf));
> >>> + igt_assert(ret >= 0);
> >>> +
> >>> + igt_assert_eq(e->type, DRM_EVENT_FLIP_COMPLETE);
> >>> + igt_reset_timeout();
> >>> +
> >>> + return n;
> >>> +}
> >>> +
> >>> +static void
> >>> +test_grab_crc(data_t *data, color_t *color, igt_crc_t *crc /* out
> >>> */)
> >>> +{
> >>> + drmModeModeInfo *mode;
> >>> + igt_plane_t *primary;
> >>> + int ret;
> >>> +
> >>> + igt_output_set_pipe(data->output, data->pipe);
> >>> +
> >>> + primary = igt_output_get_plane_type(data->output,
> >>> DRM_PLANE_TYPE_PRIMARY);
> >>> + data->plane[primary->index] = primary;
> >>> +
> >>> + mode = igt_output_get_mode(data->output);
> >>> +
> >>> + igt_create_color_fb(data->drm_fd, mode->hdisplay, mode-
> vdisplay,
> >>> + DRM_FORMAT_XRGB,
> >>> + LOCAL_I915_FORMAT_MOD_X_TILED,
> >>> + color->red, color->green, color->blue,
> >>> + &data->fb[primary->index]);
> >>> +
> >>> + igt_plane_set_fb(data->plane[primary->index], &data-
> fb[primary->index]);
> >>> +
> >>> + ret = igt_display_try_commit2(&data->display,
> >>> COMMIT_ATOMIC);
> >>> + igt_skip_on(ret != 0);
> >>> +}
> >>> +
> >>> +/*
> >>> + * Multiple plane position test.
> >>> + * - We start by grabbing a reference CRC of a full blue fb
> >>> being scanned
> >>> + * out on the primary plane
> >>> + * - Then we scannout number of planes:
> >>> + * * the primary plane uses a blue fb with a black rectangle
> >>> hole
> >>> + * * planes, on top of the primary plane, with a blue fb that
> >>> is set-up
> >>> + *to cover the black rectangles of the primary plane fb
> >>> + * The resulting CRC should be identical to the reference CRC
> >>> + */
> >>> +
> >>> +static void
> >>> +create_fb_for_mode_position(data_t *data, drmModeModeInfo *mode,
> >>> + color_t *color, int *rect_x, int
> >>> *rect_y,
> >>> + int *rect_w, int *rect_h, uint64_t
> >>> tiling,
> >>> + int max_planes)
> >>> +{
> >>> + unsigned int fb_id;
> >>> + cairo_t *cr;
> >>> + igt_plane_t *primary;
> >>> +
> >>> + primary = igt_output_get_plane_type(data->output,
> >>> DRM_PLANE_TYPE_PRIMARY);
> >>> +
> >>> + fb_id = igt_create_fb(data->drm_fd,
> >>> + mode->hdisplay, mode->vdisplay,
> >>> + DRM_FORMAT_XRGB,
> >>> + tiling,
> >>> + &data->fb[primary->index]);
> >>> + igt_assert(fb_id);
> >>> +
> >>> + cr = igt_get_cairo_ctx(data->drm_fd, &data->fb[primary-
> index]);
> >>> + igt_paint_color(cr, rect_x[0], rect_y[0],
> >>> + mode->hdisplay, mode->vdisplay,
> >>> + color->red, color->green, color->blue);
> >>> +
> >>> + for (int i = 0; i < max_planes; i++) {
> >>> + if (data->plane[i]->type ==
> >>> DRM_PLANE_TYPE_PRIMARY)
> >>> + continue;
> >>> + igt_paint_color(cr, rect_x[i], rect_y[i],
> >>>
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On 04/11/2017 01:03 PM, Sumit Semwal wrote: On 11 April 2017 at 12:38, Daniel Stone wrote: Hi, On 11 April 2017 at 07:48, Daniel Vetter wrote: Note: As Daniel Stone mentioned in the announcement fd.o admins started chatting with the communities their hosting, which includs the X.org foundation board, to figure out how to fan out enforcement and allow projects to run things on their own (with fd.o still as the fallback). So the details of enforcement (and appealing decisions) might still change, but since this involves the board and lots more people it'll take a while to get there. For now this is good enough I think. All true. Reviewed-by: Daniel Stone Thanks for this, Daniel! Reviewed-by: Sumit Semwal Acked-by: Archit Taneja Thanks, Archit Best, Sumit. Cheers, Daniel ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_concurrent: Concurrent and interruptible subtests for atomic
Op 11-04-17 om 09:42 schreef Kahola, Mika:
>
>> -Original Message-
>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>> Sent: Monday, April 10, 2017 3:39 PM
>> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH i-g-t v2] tests/kms_concurrent: Concurrent and
>> interruptible
>> subtests for atomic
>>
>> Op 10-04-17 om 14:11 schreef Mika Kahola:
>>> On Wed, 2017-03-29 at 11:53 +0200, Maarten Lankhorst wrote:
Op 15-03-17 om 09:43 schreef Mika Kahola:
> This test case introduces concurrently running test cases for atomic
> modesetting.
>
> The first test or thread draws blue backround with black holes on
> it.
> These holes are covered by rectangular, blue planes that are placed
> randomly like in test case 'kms_plane_multiple'.
>
> The second thread changes resolution from higher to lower one and
> back.
> The delay between resolution changes is randomly selected between
> 20 and
> 50 milliseconds.
>
> The test runs by default 32 iterations to increase the coverage.
>
> v2: use igt_fork instead of pthreads to create concurrent test runs
> (Maarten)
>
> Signed-off-by: Mika Kahola
> ---
> tests/Makefile.sources | 1 +
> tests/kms_concurrent.c | 630
> +
> 2 files changed, 631 insertions(+)
> create mode 100644 tests/kms_concurrent.c
>
>
> +static int
> +display_commit_mode(data_t *data, igt_crc_t *crc) {
> + char buf[256];
> + struct drm_event *e = (void *)buf;
> + int n, ret;
> + int flags = DRM_MODE_PAGE_FLIP_EVENT |
> DRM_MODE_ATOMIC_ALLOW_MODESET |
>> DRM_MODE_ATOMIC_NONBLOCK;
> +
> + ret = igt_display_try_commit_atomic(&data->display,
> + flags,
> + NULL);
> + igt_skip_on(ret != 0);
> +
> + igt_set_timeout(1, "Stuck on page flip");
> + ret = read(data->display.drm_fd, buf, sizeof(buf));
> + igt_assert(ret >= 0);
> +
> + igt_assert_eq(e->type, DRM_EVENT_FLIP_COMPLETE);
> + igt_reset_timeout();
> +
> + return n;
> +}
> +
> +static void
> +test_grab_crc(data_t *data, color_t *color, igt_crc_t *crc /* out
> */)
> +{
> + drmModeModeInfo *mode;
> + igt_plane_t *primary;
> + int ret;
> +
> + igt_output_set_pipe(data->output, data->pipe);
> +
> + primary = igt_output_get_plane_type(data->output,
> DRM_PLANE_TYPE_PRIMARY);
> + data->plane[primary->index] = primary;
> +
> + mode = igt_output_get_mode(data->output);
> +
> + igt_create_color_fb(data->drm_fd, mode->hdisplay, mode-
>> vdisplay,
> + DRM_FORMAT_XRGB,
> + LOCAL_I915_FORMAT_MOD_X_TILED,
> + color->red, color->green, color->blue,
> + &data->fb[primary->index]);
> +
> + igt_plane_set_fb(data->plane[primary->index], &data-
>> fb[primary->index]);
> +
> + ret = igt_display_try_commit2(&data->display,
> COMMIT_ATOMIC);
> + igt_skip_on(ret != 0);
> +}
> +
> +/*
> + * Multiple plane position test.
> + * - We start by grabbing a reference CRC of a full blue fb
> being scanned
> + * out on the primary plane
> + * - Then we scannout number of planes:
> + * * the primary plane uses a blue fb with a black rectangle
> hole
> + * * planes, on top of the primary plane, with a blue fb that
> is set-up
> + *to cover the black rectangles of the primary plane fb
> + * The resulting CRC should be identical to the reference CRC
> + */
> +
> +static void
> +create_fb_for_mode_position(data_t *data, drmModeModeInfo *mode,
> + color_t *color, int *rect_x, int
> *rect_y,
> + int *rect_w, int *rect_h, uint64_t
> tiling,
> + int max_planes)
> +{
> + unsigned int fb_id;
> + cairo_t *cr;
> + igt_plane_t *primary;
> +
> + primary = igt_output_get_plane_type(data->output,
> DRM_PLANE_TYPE_PRIMARY);
> +
> + fb_id = igt_create_fb(data->drm_fd,
> + mode->hdisplay, mode->vdisplay,
> + DRM_FORMAT_XRGB,
> + tiling,
> + &data->fb[primary->index]);
> + igt_assert(fb_id);
> +
> + cr = igt_get_cairo_ctx(data->drm_fd, &data->fb[primary-
>> index]);
> + igt_paint_color(cr, rect_x[0], rect_y[0],
> + mode->hdisplay, mode->vdisplay,
> + color->red, color->green, color->blue);
> +
> + for (int i = 0; i < max_planes; i++) {
> + if (data->plane[i]->type ==
> DRM_PLANE_TYPE_PRIMARY)
> + continue;
> +
Re: [Intel-gfx] [PATCH] drm/i915: Lie and treat all engines as idle if wedged
On ma, 2017-04-10 at 17:24 +0100, Chris Wilson wrote:
> Similar to commit 8490ae207f1d ("drm/i915: Suppress busy status for
> engines if wedged") we also want to report intel_engine_is_idle() as
> true as well as the main intel_engines_are_idle(), as we now check that
> the engines are idle when overwriting the HWS page. This is not true
> whilst we are setting the device as wedged, at least according to our
> bookkeeping, so we have to lie to ourselves!
>
> [ 383.588601] [drm:i915_reset [i915]] *ERROR* Failed to reset chip: -110
> [ 383.588685] [ cut here ]
> [ 383.588755] WARNING: CPU: 0 PID: 12 at
> drivers/gpu/drm/i915/intel_engine_cs.c:226
> intel_engine_init_global_seqno+0x222/0x290 [i915]
> [ 383.588757] WARN_ON(!intel_engine_is_idle(engine))
> [ 383.588759] Modules linked in: ctr ccm snd_hda_codec_hdmi
> snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec
> snd_hda_core arc4 iwldvm mac80211 snd_pcm snd_hwdep snd_seq_midi
> snd_seq_midi_event rfcomm bnep snd_rawmidi intel_powerclamp coretemp
> dm_multipath iwlwifi crct10dif_pclmul snd_seq crc32_pclmul
> ghash_clmulni_intel btusb aesni_intel btrtl btbcm aes_x86_64 crypto_simd
> cryptd btintel snd_timer glue_helper bluetooth intel_ips snd_seq_device
> cfg80211 snd soundcore binfmt_misc mei_me mei dm_mirror dm_region_hash dm_log
> i915 intel_gtt i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt
> sysfillrect sysimgblt fb_sys_fops cfbcopyarea prime_numbers ahci libahci drm
> e1000e
> [ 383.588851] CPU: 0 PID: 12 Comm: migration/0 Not tainted 4.11.0-rc5+ #207
> [ 383.588853] Hardware name: LENOVO 514328U/514328U, BIOS 6QET44WW (1.14 )
> 04/20/2010
> [ 383.588855] Call Trace:
> [ 383.588866] dump_stack+0x63/0x90
> [ 383.588871] __warn+0xc7/0xf0
> [ 383.588876] warn_slowpath_fmt+0x4a/0x50
> [ 383.53] ? set_next_entity+0x821/0x910
> [ 383.588943] intel_engine_init_global_seqno+0x222/0x290 [i915]
> [ 383.588998] __i915_gem_set_wedged_BKL+0xa4/0x190 [i915]
> [ 383.589003] ? __switch_to+0x215/0x390
> [ 383.589008] multi_cpu_stop+0xbb/0xe0
> [ 383.589012] ? cpu_stop_queue_work+0x90/0x90
> [ 383.589016] cpu_stopper_thread+0x82/0x110
> [ 383.589021] smpboot_thread_fn+0x137/0x190
> [ 383.589026] kthread+0xf7/0x130
> [ 383.589030] ? sort_range+0x20/0x20
> [ 383.589034] ? kthread_park+0x90/0x90
> [ 383.589040] ret_from_fork+0x2c/0x40
>
> Fixes: 2ca9faa551c4 ("drm/i915: Assert the engine is idle before overwiting
> the HWS")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Makes sense if hoisting the check would spread it all over.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On 11/04/17 10:51, Archit Taneja wrote: On 04/11/2017 01:03 PM, Sumit Semwal wrote: On 11 April 2017 at 12:38, Daniel Stone wrote: Hi, On 11 April 2017 at 07:48, Daniel Vetter wrote: Note: As Daniel Stone mentioned in the announcement fd.o admins started chatting with the communities their hosting, which includs the X.org foundation board, to figure out how to fan out enforcement and allow projects to run things on their own (with fd.o still as the fallback). So the details of enforcement (and appealing decisions) might still change, but since this involves the board and lots more people it'll take a while to get there. For now this is good enough I think. All true. Reviewed-by: Daniel Stone Thanks for this, Daniel! Reviewed-by: Sumit Semwal Acked-by: Archit Taneja Thanks for doing this, this was long overdue! Reviewed-by: Martin Peres ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/67] drm/i915/cnp: Add Backlight support to CNP PCH.
On Fri, 07 Apr 2017, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 12:15:00PM -0700, Rodrigo Vivi wrote:
>> Backlight support on Cannonpoint is a lot
>> likely Broxton, but with only one controller (0).
>
> This being the PCH backlight obviously. I guess we still don't have any
> use for the CPU backlight?
>
> Oh, since the utility pin is on the CPU I think we should perhaps add
> HAS_PCH_SPLIT checks around the useage of the utility pin in the BXT
> backlight functions, or some comments. Or perhaps even split out CNP+
> vs. BXT entirely? Otherwise I think people might get confused by the
> utility pin references.
Please split out. This is what I've been doing and promoting in
intel_panel.c.
BR,
Jani.
>
>>
>> Also other main changes/differences:
>>
>> - PWM clock frequency = Raw clock frequency = 19.2 MHz or
>> 24 MHz. Value is found in SFUSE_STRAP.
>> - PWM increment = 1
>>
>> v2: Reuse BXT functions with controller 0 instead of
>> redefining it. (Jani).
>> Use dev_priv->rawclk_freq instead of getting the value
>> from SFUSE_STRAP.
>> v3: Avoid setup backligh controller along with hooks and
>> fully reuse hooks setup as suggested by Jani.
>> v4: Clean up commit message.
>> v5: Implement per PCH instead per platform.
>>
>> Cc: Jani Nikula
>> Signed-off-by: Rodrigo Vivi
>> ---
>> drivers/gpu/drm/i915/intel_panel.c | 19 +--
>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_panel.c
>> b/drivers/gpu/drm/i915/intel_panel.c
>> index cb50c52..1978bec 100644
>> --- a/drivers/gpu/drm/i915/intel_panel.c
>> +++ b/drivers/gpu/drm/i915/intel_panel.c
>> @@ -1247,6 +1247,18 @@ static u32 bxt_hz_to_pwm(struct intel_connector
>> *connector, u32 pwm_freq_hz)
>> }
>>
>> /*
>> + * CNP: PWM clock frequency is 19.2 MHz or 24 MHz.
>> + * Value is found in SFUSE_STRAP.
>> + * PWM increment = 1
>> + */
>> +static u32 cnp_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>> +
>> +return DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), pwm_freq_hz);
>> +}
>> +
>> +/*
>> * SPT: This value represents the period of the PWM stream in clock periods
>> * multiplied by 16 (default increment) or 128 (alternate increment
>> selected in
>> * SCHICKEN_1 bit 0). PWM clock is 24 MHz.
>> @@ -1742,13 +1754,16 @@ void intel_panel_destroy_backlight(struct
>> drm_connector *connector)
>> intel_dsi_dcs_init_backlight_funcs(connector) == 0)
>> return;
>>
>> -if (IS_GEN9_LP(dev_priv)) {
>> +if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
>> panel->backlight.setup = bxt_setup_backlight;
>> panel->backlight.enable = bxt_enable_backlight;
>> panel->backlight.disable = bxt_disable_backlight;
>> panel->backlight.set = bxt_set_backlight;
>> panel->backlight.get = bxt_get_backlight;
>> -panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
>> +if (IS_GEN9_LP(dev_priv))
>> +panel->backlight.hz_to_pwm = bxt_hz_to_pwm;
>> +else
>> +panel->backlight.hz_to_pwm = cnp_hz_to_pwm;
>> } else if (HAS_PCH_LPT(dev_priv) || HAS_PCH_SPT(dev_priv) ||
>> HAS_PCH_KBP(dev_priv)) {
>> panel->backlight.setup = lpt_setup_backlight;
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() (rev2)
On Mon, Apr 10, 2017 at 04:23:15PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915: Stop second guessing the caller > for intel_uncore_wait_for_register() (rev2) > URL : https://patchwork.freedesktop.org/series/22786/ > State : warning > > == Summary == > > Series 22786v2 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/22786/revisions/2/mbox/ > > Test core_auth: > Subgroup basic-auth: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test drv_getparams_basic: > Subgroup basic-subslice-total: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test drv_module_reload: > Subgroup basic-no-display: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-reload: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-reload-final: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_basic: > Subgroup create-close: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_busy: > Subgroup basic-hang-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_close_race: > Subgroup basic-threads: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_cs_tlb: > Subgroup basic-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_ctx_basic: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_ctx_create: > Subgroup basic-files: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_ctx_param: > Subgroup basic-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_ctx_switch: > Subgroup basic-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-default-heavy: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_exec_basic: > Subgroup gtt-render: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup readonly-bsd: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup readonly-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup readonly-render: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_exec_create: > Subgroup basic: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_exec_fence: > Subgroup await-hang-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-await-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-wait-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup nb-await-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > dmesg-warn -> FAIL (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-batch-kernel-default-wb: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-uc-pro-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-uc-prw-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup basic-uc-ro-default: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > S
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct Chris pointed out on irc that the grammar went a bit wrong here. I'll fix this to "As a freedesktop.org project, dri-devel, and the DRM community, follows the Contributor Covenant, ..." when applying. -Daniel > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. > -- > 2.11.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the s/follows/follow/ (I think at least) > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. Self-englightened Acked-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't mark an execlists context-switch when idle
If we *know* that the engine is idle, i.e. we have not more contexts in
lift, we can skip any spurious CSB idle interrupts. These spurious
interrupts seem to arrive long after we assert that the engines are
completely idle, triggering later assertions:
[ 178.896646] intel_engine_is_idle(bcs): interrupt not handled, irq_posted=2
[ 178.896655] [ cut here ]
[ 178.896658] kernel BUG at drivers/gpu/drm/i915/intel_engine_cs.c:226!
[ 178.896661] invalid opcode: [#1] SMP
[ 178.896663] Modules linked in: i915(E) x86_pkg_temp_thermal(E)
crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E)
nls_ascii(E) nls_cp437(E) vfat(E) fat(E) intel_gtt(E) i2c_algo_bit(E)
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E)
aesni_intel(E) prime_numbers(E) evdev(E) aes_x86_64(E) drm(E) crypto_simd(E)
cryptd(E) glue_helper(E) mei_me(E) mei(E) lpc_ich(E) efivars(E) mfd_core(E)
battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) tpm_tis_core(E) tpm(E)
autofs4(E) i2c_i801(E) fan(E) thermal(E) i2c_designware_platform(E)
i2c_designware_core(E)
[ 178.896694] CPU: 1 PID: 522 Comm: gem_exec_whispe Tainted: GE
4.11.0-rc5+ #14
[ 178.896702] task: 88040aba8d40 task.stack: c93f
[ 178.896722] RIP: 0010:intel_engine_init_global_seqno+0x1db/0x1f0 [i915]
[ 178.896725] RSP: 0018:c93f3ab0 EFLAGS: 00010246
[ 178.896728] RAX: RBX: 88040af54000 RCX:
[ 178.896731] RDX: 88041ec933e0 RSI: 88041ec8cc48 RDI: 88041ec8cc48
[ 178.896734] RBP: c93f3ac8 R08: R09: 047d
[ 178.896736] R10: 0040 R11: 88040b344f80 R12:
[ 178.896739] R13: 88040bce R14: 88040bce52d8 R15: 88040bce
[ 178.896742] FS: 7f22d8c0() GS:88041ec8()
knlGS:
[ 178.896746] CS: 0010 DS: ES: CR0: 80050033
[ 178.896749] CR2: 7f41ddd8f000 CR3: 00040bb03000 CR4: 001406e0
[ 178.896752] Call Trace:
[ 178.896768] reset_all_global_seqno.part.33+0x4e/0xd0 [i915]
[ 178.896782] i915_gem_request_alloc+0x304/0x330 [i915]
[ 178.896795] i915_gem_do_execbuffer+0x8a1/0x17d0 [i915]
[ 178.896799] ? remove_wait_queue+0x48/0x50
[ 178.896812] ? i915_wait_request+0x300/0x590 [i915]
[ 178.896816] ? wake_up_q+0x70/0x70
[ 178.896819] ? refcount_dec_and_test+0x11/0x20
[ 178.896823] ? reservation_object_add_excl_fence+0xa5/0x100
[ 178.896835] i915_gem_execbuffer2+0xab/0x1f0 [i915]
[ 178.896844] drm_ioctl+0x1e6/0x460 [drm]
[ 178.896858] ? i915_gem_execbuffer+0x260/0x260 [i915]
[ 178.896862] ? dput+0xcf/0x250
[ 178.896866] ? full_proxy_release+0x66/0x80
[ 178.896869] ? mntput+0x1f/0x30
[ 178.896872] do_vfs_ioctl+0x8f/0x5b0
[ 178.896875] ? fput+0x9/0x10
[ 178.896878] ? task_work_run+0x80/0xa0
[ 178.896881] SyS_ioctl+0x3c/0x70
[ 178.896885] entry_SYSCALL_64_fastpath+0x17/0x98
[ 178.896888] RIP: 0033:0x7f2ccb455ca7
[ 178.896890] RSP: 002b:7ffcabec72d8 EFLAGS: 0246 ORIG_RAX:
0010
[ 178.896894] RAX: ffda RBX: 55f897a44b90 RCX: 7f2ccb455ca7
[ 178.896897] RDX: 7ffcabec74a0 RSI: 40406469 RDI: 0003
[ 178.896900] RBP: 7f2ccb70a440 R08: 7f2ccb70d0a4 R09:
[ 178.896903] R10: R11: 0246 R12:
[ 178.896905] R13: 55f89782d71a R14: 7ffcabecf838 R15: 0003
[ 178.896908] Code: 00 31 d2 4c 89 ef 8d 70 48 41 ff 95 f8 06 00 00 e9 68 fe
ff ff be 0f 00 00 00 48 c7 c7 48 dc 37 a0 e8 fa 33 d6 e0 e9 0b ff ff ff <0f> 0b
0f 0b 0f 0b 0f 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00
On the other hand, by ignoring the interrupt do we risk running out of
space in CSB ring? Testing for a few hours suggests not, i.e. that we
only seem to get the odd delayed CSB idle notification.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1da5b85a4295..e3ea6c008425 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1363,8 +1363,10 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32
iir, int test_shift)
bool tasklet = false;
if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
- set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
- tasklet = true;
+ if (port_count(&engine->execlist_port[0])) {
+ set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+ tasklet = true;
+ }
}
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mai
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ 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: Don't mark an execlists context-switch when idle
== Series Details ==
Series: drm/i915: Don't mark an execlists context-switch when idle
URL : https://patchwork.freedesktop.org/series/22841/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/gvt/firmware.o
CC [M] drivers/gpu/drm/i915/gvt/interrupt.o
CC [M] drivers/gpu/drm/i915/gvt/gtt.o
CC [M] drivers/gpu/drm/i915/gvt/cfg_space.o
LD drivers/thermal/thermal_sys.o
CC [M] drivers/gpu/drm/i915/gvt/opregion.o
CC [M] drivers/gpu/drm/i915/gvt/mmio.o
CC [M] drivers/gpu/drm/i915/gvt/display.o
CC [M] drivers/gpu/drm/i915/gvt/edid.o
CC [M] drivers/gpu/drm/i915/gvt/execlist.o
LD drivers/thermal/built-in.o
CC [M] drivers/gpu/drm/i915/gvt/scheduler.o
CC [M] drivers/gpu/drm/i915/gvt/sched_policy.o
CC [M] drivers/gpu/drm/i915/gvt/render.o
CC [M] drivers/gpu/drm/i915/intel_lpe_audio.o
CC [M] drivers/gpu/drm/i915/gvt/cmd_parser.o
LD drivers/video/fbdev/built-in.o
LD drivers/mmc/core/mmc_block.o
LD drivers/mmc/core/built-in.o
LD drivers/mmc/built-in.o
LD kernel/sched/built-in.o
LD [M] drivers/gpu/drm/vgem/vgem.o
LD lib/lz4/built-in.o
LD drivers/pci/pcie/aer/aerdriver.o
LD kernel/built-in.o
LD drivers/usb/storage/usb-storage.o
LD drivers/pci/pcie/aer/built-in.o
LD drivers/usb/storage/built-in.o
LD drivers/pci/pcie/built-in.o
LD [M] drivers/misc/mei/mei-me.o
drivers/gpu/drm/i915/i915_irq.c: In function ‘gen8_cs_irq_handler’:
drivers/gpu/drm/i915/i915_irq.c:1362:7: error: implicit declaration of function
‘port_count’ [-Werror=implicit-function-declaration]
if (port_count(&engine->execlist_port[0])) {
^
LD drivers/misc/built-in.o
LD drivers/usb/gadget/libcomposite.o
LD drivers/tty/serial/8250/8250.o
LD drivers/iommu/built-in.o
LD drivers/spi/built-in.o
LD net/xfrm/built-in.o
LD drivers/video/console/built-in.o
LD drivers/video/built-in.o
LD drivers/usb/gadget/udc/udc-core.o
LD drivers/gpu/drm/drm.o
LD drivers/usb/gadget/udc/built-in.o
LD drivers/usb/gadget/built-in.o
LD drivers/tty/serial/8250/8250_base.o
LD drivers/tty/serial/8250/built-in.o
LD net/ipv6/ipv6.o
LD [M] drivers/net/ethernet/intel/e1000/e1000.o
LD drivers/tty/serial/built-in.o
AR lib/lib.a
EXPORTS lib/lib-ksyms.o
LD net/ipv6/built-in.o
LD drivers/scsi/scsi_mod.o
LD drivers/pci/built-in.o
LD lib/built-in.o
LD [M] sound/pci/hda/snd-hda-codec-generic.o
LD sound/pci/built-in.o
LD drivers/tty/vt/built-in.o
LD drivers/tty/built-in.o
LD sound/built-in.o
LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o
LD fs/btrfs/btrfs.o
LD fs/btrfs/built-in.o
LD drivers/scsi/sd_mod.o
LD drivers/scsi/built-in.o
CC arch/x86/kernel/cpu/capflags.o
LD arch/x86/kernel/cpu/built-in.o
LD net/ipv4/built-in.o
LD arch/x86/kernel/built-in.o
LD drivers/usb/core/usbcore.o
LD drivers/usb/core/built-in.o
LD arch/x86/built-in.o
LD drivers/usb/host/xhci-hcd.o
LD drivers/md/md-mod.o
LD drivers/md/built-in.o
LD net/core/built-in.o
cc1: all warnings being treated as errors
LD net/built-in.o
scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/i915_irq.o'
failed
make[4]: *** [drivers/gpu/drm/i915/i915_irq.o] Error 1
make[4]: *** Waiting for unfinished jobs
LD fs/ext4/ext4.o
LD fs/ext4/built-in.o
LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o
LD fs/built-in.o
LD [M] drivers/net/ethernet/intel/igb/igb.o
LD drivers/usb/host/built-in.o
LD drivers/usb/built-in.o
LD drivers/net/ethernet/built-in.o
LD drivers/net/built-in.o
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1002: recipe for target 'drivers' failed
make: *** [drivers] Error 2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] tests/kms_concurrent: Concurrent and interruptible subtests for atomic
This test case introduces concurrently running test cases for atomic
modesetting.
The first test or thread draws blue backround with black holes on it.
These holes are covered by rectangular, blue planes that are placed
randomly like in test case 'kms_plane_multiple'.
The second thread changes resolution from higher to lower one and back.
For: VIZ-7022
v2: use igt_fork instead of pthreads to create concurrent test runs (Maarten)
v3: use igt_display calls instead of raw drm calls for display updates (Maarten)
Various cleanups on accessing drm connector (Maarten)
Signed-off-by: Mika Kahola
---
tests/Makefile.sources | 1 +
tests/kms_concurrent.c | 429 +
2 files changed, 430 insertions(+)
create mode 100644 tests/kms_concurrent.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 45c21a0..65ffbf9 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -115,6 +115,7 @@ TESTS_progs_M = \
kms_plane \
kms_plane_multiple \
kms_plane_lowres \
+ kms_concurrent \
kms_properties \
kms_psr_sink_crc \
kms_render \
diff --git a/tests/kms_concurrent.c b/tests/kms_concurrent.c
new file mode 100644
index 000..b34540b
--- /dev/null
+++ b/tests/kms_concurrent.c
@@ -0,0 +1,429 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "drmtest.h"
+
+IGT_TEST_DESCRIPTION("Test atomic mode setting concurrently with multiple
planes and screen resolution");
+
+#define SIZE_PLANE 256
+#define SIZE_CURSOR 128
+#define LOOP_FOREVER -1
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+ igt_plane_t **plane;
+ struct igt_fb *fb;
+} data_t;
+
+/* Command line parameters. */
+struct {
+ int iterations;
+ bool user_seed;
+ int seed;
+ bool run;
+} opt = {
+ .iterations = 1,
+ .user_seed = false,
+ .seed = 1,
+ .run = true,
+};
+
+/*
+ * Common code across all tests, acting on data_t
+ */
+static void test_init(data_t *data, enum pipe pipe, int n_planes,
+ igt_output_t *output)
+{
+ drmModeModeInfo *mode;
+ igt_plane_t *primary;
+ int ret;
+
+ data->plane = calloc(n_planes, sizeof(data->plane));
+ igt_assert_f(data->plane != NULL, "Failed to allocate memory for
planes\n");
+
+ data->fb = calloc(n_planes, sizeof(struct igt_fb));
+ igt_assert_f(data->fb != NULL, "Failed to allocate memory for FBs\n");
+
+ igt_output_set_pipe(output, pipe);
+
+ primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
+ data->plane[primary->index] = primary;
+
+ mode = igt_output_get_mode(output);
+
+ igt_create_color_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB,
+ LOCAL_I915_FORMAT_MOD_X_TILED,
+ 0.0f, 0.0f, 1.0f,
+ &data->fb[primary->index]);
+
+ igt_plane_set_fb(data->plane[primary->index],
&data->fb[primary->index]);
+
+ ret = igt_display_try_commit2(&data->display, COMMIT_ATOMIC);
+ igt_skip_on(ret != 0);
+}
+
+static void test_fini(data_t *data, enum pipe pipe, int n_planes,
+ igt_output_t *output)
+{
+ int i;
+
+ data->display.pipes[pipe].mode_blob = 0;
+
+ for (i = 0; i < n_planes; i++) {
+ igt_plane_t *plane = data->plane[i];
+
+ if (!plane)
+ continue;
+
+ if (plane->type == DRM_PLANE_TYPE_PRIMARY)
+ continue;
+
+ igt_plane_set_fb(plane, NULL);
+
+ data->plane[i] = NULL;
+ }
+
+ /* reset the constraint on the pipe */
+ igt_output_set_pipe(output, PIPE_ANY);
+
+
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, 11 Apr 2017, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter Acked-by: Jani Nikula > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. -- 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: Document code of conduct
On 04/11/2017 08:48 AM, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. > Acked-by: Vincent Abriou ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On 04/11/2017 11:03 AM, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: >> freedesktop.org has adopted a formal&enforced code of conduct: >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> Besides formalizing things a bit more I don't think this changes >> anything for us, we've already peer-enforced respectful and >> constructive interactions since a long time. But it's good to document >> things properly. >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> started chatting with the communities their hosting, which includs the >> X.org foundation board, to figure out how to fan out enforcement and >> allow projects to run things on their own (with fd.o still as the >> fallback). So the details of enforcement (and appealing decisions) >> might still change, but since this involves the board and lots more >> people it'll take a while to get there. For now this is good enough I >> think. >> >> For the text itself I went with the same blurb as the Wayland project, >> didn't feel creative yet this early in the morning: >> >> https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c >> >> Cc: Daniel Stone >> Cc: Keith Packard >> Cc: tfh...@err.no >> Signed-off-by: Daniel Vetter >> --- >> Documentation/gpu/introduction.rst | 11 +++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/Documentation/gpu/introduction.rst >> b/Documentation/gpu/introduction.rst >> index 05a82bdfbca4..0f5173e29bdc 100644 >> --- a/Documentation/gpu/introduction.rst >> +++ b/Documentation/gpu/introduction.rst >> @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one >> month where feature work >> can't be merged. The recommended way to deal with that is having a -next >> tree >> that's always open, but making sure to not feed it into linux-next during >> the >> blackout period. As an example, drm-misc works like that. >> + >> +Code of Conduct >> +--- >> + >> +As a freedesktop.org project, dri-devel and the DRM community follows the >> +Contributor Covenant, found at: >> https://www.freedesktop.org/wiki/CodeOfConduct > > Chris pointed out on irc that the grammar went a bit wrong here. I'll fix > this to > > "As a freedesktop.org project, dri-devel, and the DRM community, follows > the Contributor Covenant, ..." > > when applying. > -Daniel > >> + >> +Please conduct yourself in a respectful and civilised manner when >> +interacting with community members on mailing lists, IRC, or bug >> +trackers. The community represents the project as a whole, and abusive >> +or bullying behaviour is not tolerated by the project. >> -- >> 2.11.0 Acked-by: Neil Armstrong ___ 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/scheduler: add gvt notification for guc
> -Original Message-
> From: Dong, Chuanxiao
> Sent: Monday, April 10, 2017 10:40 AM
> To: Dong, Chuanxiao ; Chris Wilson
>
> Cc: Tian, Kevin ; intel-gvt-...@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org; joonas.lahti...@linux.intel.com; Zheng,
> Xiao ; Wang, Zhi A
> Subject: RE: [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc
>
> > -Original Message-
> > From: intel-gvt-dev
> > [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On Behalf Of
> > Dong, Chuanxiao
> > Sent: Thursday, April 6, 2017 11:19 PM
> > To: Chris Wilson
> > Cc: Tian, Kevin ;
> > intel-gvt-...@lists.freedesktop.org;
> > intel-gfx@lists.freedesktop.org; joonas.lahti...@linux.intel.com;
> > Zheng, Xiao ; Wang, Zhi A
> > Subject: RE: [PATCH v2 2/2] drm/i915/scheduler: add gvt notification
> > for guc
> >
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Thursday, April 6, 2017 11:07 PM
> > > To: Dong, Chuanxiao
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > intel-gvt-...@lists.freedesktop.org;
> > > Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com; Wang, Zhi
> > > A
> > > Subject: Re: [PATCH v2 2/2] drm/i915/scheduler: add gvt notification
> > > for guc
> > >
> > > On Thu, Apr 06, 2017 at 02:49:54PM +, Dong, Chuanxiao wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > Sent: Thursday, April 6, 2017 10:19 PM
> > > > > To: Dong, Chuanxiao
> > > > > Cc: intel-gfx@lists.freedesktop.org;
> > > > > intel-gvt-...@lists.freedesktop.org;
> > > > > Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com
> > > > > Subject: Re: [PATCH v2 2/2] drm/i915/scheduler: add gvt
> > > > > notification for guc
> > > > >
> > > > > On Thu, Apr 06, 2017 at 02:05:15PM +, Dong, Chuanxiao wrote:
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > > > Sent: Thursday, April 6, 2017 9:32 PM
> > > > > > > To: Dong, Chuanxiao
> > > > > > > Cc: intel-gfx@lists.freedesktop.org;
> > > > > > > intel-gvt-...@lists.freedesktop.org;
> > > > > > > Zheng, Xiao; Tian, Kevin; joonas.lahti...@linux.intel.com
> > > > > > > Subject: Re: [PATCH v2 2/2] drm/i915/scheduler: add gvt
> > > > > > > notification for guc
> > > > > > >
> > > > > > > On Tue, Mar 28, 2017 at 05:38:41PM +0800, Chuanxiao Dong
> wrote:
> > > > > > > > GVT request needs a manual mmio load/restore. Before GuC
> > > > > > > > submit a request, send notification to gvt for mmio loading.
> > > > > > > > And after the GuC finished this GVT request, notify gvt
> > > > > > > > again for
> > > mmio restore.
> > > > > > > > This follows the usage when using execlists submission.
> > > > > > > >
> > > > > > > > Cc: xiao.zh...@intel.com
> > > > > > > > Cc: kevin.t...@intel.com
> > > > > > > > Cc: joonas.lahti...@linux.intel.com
> > > > > > > > Cc: ch...@chris-wilson.co.uk
> > > > > > > > Signed-off-by: Chuanxiao Dong
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/i915/i915_guc_submission.c | 4
> > > > > > > > drivers/gpu/drm/i915/intel_gvt.h | 12
> > > > > > > > drivers/gpu/drm/i915/intel_lrc.c | 21
> > > > > > > > +++--
> > > > > > > > 3 files changed, 19 insertions(+), 18 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> > > > > > > > b/drivers/gpu/drm/i915/i915_guc_submission.c
> > > > > > > > index 58087630..d8a5942 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> > > > > > > > @@ -606,6 +606,8 @@ static void __i915_guc_submit(struct
> > > > > > > drm_i915_gem_request *rq)
> > > > > > > > unsigned long flags;
> > > > > > > > int b_ret;
> > > > > > > >
> > > > > > > > + intel_gvt_notify_context_status(rq,
> > > > > > > > +INTEL_CONTEXT_SCHEDULE_IN);
> > > > > > > > +
> > > > > > > > /* WA to flush out the pending GMADR writes to ring
> > > > > > > > buffer.
> > > */
> > > > > > > > if (i915_vma_is_map_and_fenceable(rq->ring->vma))
> > > > > > > > POSTING_READ_FW(GUC_STATUS); @@ -725,6
> > > +727,8 @@ static
> > > > > > > > void i915_guc_irq_handler(unsigned long
> > > > > data)
> > > > > > > > rq = port[0].request;
> > > > > > > > while (rq && i915_gem_request_completed(rq)) {
> > > > > > > > trace_i915_gem_request_out(rq);
> > > > > > > > + intel_gvt_notify_context_status(rq,
> > > > > > > > +
> > > INTEL_CONTEXT_SCHEDULE_OUT);
> > > > > > >
> > > > > > > This is incorrect though. This is no better than just
> > > > > > > waiting for the request, which is not enough since the idea
> > > > > > > is that you need to wait for the context image to be
> > > > > > > completely written to memo
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
Op 11-04-17 om 08:48 schreef Daniel Vetter: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. Reviewed-by: Maarten Lankhorst ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: freedesktop.org has adopted a formal&enforced code of conduct: https://www.fooishbar.org/blog/fdo-contributor-covenant/ https://www.freedesktop.org/wiki/CodeOfConduct/ Besides formalizing things a bit more I don't think this changes anything for us, we've already peer-enforced respectful and constructive interactions since a long time. But it's good to document things properly. Note: As Daniel Stone mentioned in the announcement fd.o admins started chatting with the communities their hosting, which includs the X.org foundation board, to figure out how to fan out enforcement and allow projects to run things on their own (with fd.o still as the fallback). So the details of enforcement (and appealing decisions) might still change, but since this involves the board and lots more people it'll take a while to get there. For now this is good enough I think. For the text itself I went with the same blurb as the Wayland project, didn't feel creative yet this early in the morning: https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c Cc: Daniel Stone Cc: Keith Packard Cc: tfh...@err.no Signed-off-by: Daniel Vetter --- Documentation/gpu/introduction.rst | 11 +++ 1 file changed, 11 insertions(+) LGTM, thanks. Acked-by: Brian Starkey ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, so lets add it back.
v2: Wrap __intel_wait_for_register_fw() to re-use its atomic wait_for
loop and spare adding another for ourselves.
v3: Add might_sleep() annotation
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uncore.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 53c8457869f6..f43121700f83 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1661,14 +1661,22 @@ int intel_wait_for_register(struct drm_i915_private
*dev_priv,
u32 value,
unsigned int timeout_ms)
{
-
unsigned fw =
intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
int ret;
- intel_uncore_forcewake_get(dev_priv, fw);
- ret = wait_for_us((I915_READ_FW(reg) & mask) == value, 2);
- intel_uncore_forcewake_put(dev_priv, fw);
+ might_sleep();
+
+ spin_lock_irq(&dev_priv->uncore.lock);
+ intel_uncore_forcewake_get__locked(dev_priv, fw);
+
+ ret = __intel_wait_for_register_fw(dev_priv,
+ reg, mask, value,
+ 2, 0, NULL);
+
+ intel_uncore_forcewake_put__locked(dev_priv, fw);
+ spin_unlock_irq(&dev_priv->uncore.lock);
+
if (ret)
ret = wait_for((I915_READ_NOTRACE(reg) & mask) == value,
timeout_ms);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Use __intel_uncore_wait_for_register_fw for sandybride_pcode_read
Since the sandybridge_pcode_read() may be called from
skl_pcode_request() inside an atomic context (with preempt disabled), we
should avoid hitting any sleeping paths.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 55e1e88cd361..cacb65fa2dd5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8135,9 +8135,9 @@ int sandybridge_pcode_read(struct drm_i915_private
*dev_priv, u32 mbox, u32 *val
I915_WRITE_FW(GEN6_PCODE_DATA1, 0);
I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0,
- 500)) {
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_PCODE_MAILBOX, GEN6_PCODE_READY,
0,
+500, 0, NULL)) {
DRM_ERROR("timeout waiting for pcode read (%d) to finish\n",
mbox);
return -ETIMEDOUT;
}
@@ -8180,9 +8180,9 @@ int sandybridge_pcode_write(struct drm_i915_private
*dev_priv,
I915_WRITE_FW(GEN6_PCODE_DATA1, 0);
I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0,
- 500)) {
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_PCODE_MAILBOX, GEN6_PCODE_READY,
0,
+500, 0, NULL)) {
DRM_ERROR("timeout waiting for pcode write (%d) to finish\n",
mbox);
return -ETIMEDOUT;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Use safer intel_uncore_wait_for_register in ring-init
While we do hold the forcewake for legacy ringbuffer initialisation, we
don't guard our access with the uncore.lock spinlock. In theory, we only
initialise when no others should be accessing the same mmio cachelines,
but in practice be safe as this is an infrequently used path and not
worth risky micro-optimisations.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 331da59a1eb5..97d5fcca8805 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -538,9 +538,9 @@ static int init_ring_common(struct intel_engine_cs *engine)
I915_WRITE_CTL(engine, RING_CTL_SIZE(ring->size) | RING_VALID);
/* If the head is still not zero, the ring is dead */
- if (intel_wait_for_register_fw(dev_priv, RING_CTL(engine->mmio_base),
- RING_VALID, RING_VALID,
- 50)) {
+ if (intel_wait_for_register(dev_priv, RING_CTL(engine->mmio_base),
+ RING_VALID, RING_VALID,
+ 50)) {
DRM_ERROR("%s initialization failed "
"ctl %08x (valid? %d) head %08x [%08x] tail %08x
[%08x] start %08x [expected %08x]\n",
engine->name,
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uncore.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index eb38392a2435..53c8457869f6 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us - * must be not larger than 10 microseconds. + * must be not larger than 20, microseconds. * * Note that this routine assumes the caller holds forcewake asserted, it is * not suitable for very long waits. See intel_wait_for_register() if you @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, int ret; /* Catch any overuse of this function */ - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + might_sleep_if(slow_timeout_ms); - if (fast_timeout_us > 10) - ret = _wait_for(done, fast_timeout_us, 10); - else + ret = -ETIMEDOUT; + if (fast_timeout_us && fast_timeout_us < 2) ret = _wait_for_atomic(done, fast_timeout_us, 0); if (ret) ret = wait_for(done, slow_timeout_ms); + if (out_value) *out_value = reg_value; + return ret; #undef done } -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
__intel_wait_for_register_fw()")
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
Link:
http://patchwork.freedesktop.org/patch/msgid/20170410143807.22725-1-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c98acc27279a..331da59a1eb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
drm_i915_gem_request *request)
I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
/* Wait for the ring not to be idle, i.e. for it to wake up. */
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_BSD_SLEEP_PSMI_CONTROL,
- GEN6_BSD_SLEEP_INDICATOR,
- 0,
- 50))
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_BSD_SLEEP_PSMI_CONTROL,
+GEN6_BSD_SLEEP_INDICATOR,
+0,
+1000, 0, NULL))
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
/* Now that the ring is fully powered up, update the tail */
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use the engine class to get the context size
On Mon, Apr 10, 2017 at 07:34:33AM -0700, Oscar Mateo wrote:
> From: Daniele Ceraolo Spurio
>
> Technically speaking, the context size is per engine class, not per
> instance.
>
> v2: Add MISSING_CASE (Tvrtko)
>
> v3: Rebased
>
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Signed-off-by: Daniele Ceraolo Spurio
> Reviewed-by: Tvrtko Ursulin
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 33 +
> drivers/gpu/drm/i915/intel_lrc.h | 6 +-
> 2 files changed, 26 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0dc1cc4..1c6672c 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1908,8 +1908,10 @@ static void execlists_init_reg_state(u32 *regs,
> }
>
> /**
> - * intel_lr_context_size() - return the size of the context for an engine
> - * @engine: which engine to find the context size for
> + * intel_lr_class_context_size() - return the size of the context for a given
> + * engine class
> + * @dev_priv: i915 device private
> + * @class: which engine class to find the context size for
> *
> * Each engine may require a different amount of space for a context image,
> * so when allocating (or copying) an image, this function can be used to
> @@ -1921,25 +1923,32 @@ static void execlists_init_reg_state(u32 *regs,
> * in LRC mode, but does not include the "shared data page" used with
> * GuC submission. The caller should account for this if using the GuC.
> */
> -uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
> +uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv, u8
> class)
> {
> int ret = 0;
>
> - WARN_ON(INTEL_GEN(engine->i915) < 8);
> + WARN_ON(INTEL_GEN(dev_priv) < 8);
>
> - switch (engine->id) {
> - case RCS:
> - if (INTEL_GEN(engine->i915) >= 9)
> + switch (class) {
> + case RENDER_CLASS:
> + switch (INTEL_GEN(dev_priv)) {
> + default:
> + MISSING_CASE(INTEL_GEN(dev_priv));
> + case 9:
> ret = GEN9_LR_CONTEXT_RENDER_SIZE;
> - else
> + break;
> + case 8:
> ret = GEN8_LR_CONTEXT_RENDER_SIZE;
> + break;
> + }
> break;
> - case VCS:
> - case BCS:
> - case VECS:
> - case VCS2:
> + case VIDEO_DECODE_CLASS:
> + case VIDEO_ENHANCEMENT_CLASS:
> + case COPY_ENGINE_CLASS:
> ret = GEN8_LR_CONTEXT_OTHER_SIZE;
> break;
> + default:
> + MISSING_CASE(class);
> }
>
> return ret;
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index e8015e7..bde2b6e 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -78,7 +78,11 @@ enum {
> struct drm_i915_private;
> struct i915_gem_context;
>
> -uint32_t intel_lr_context_size(struct intel_engine_cs *engine);
> +uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv, u8
> class);
> +static inline uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
> +{
> + return intel_lr_class_context_size(engine->i915, engine->class);
> +}
I'm not understanding why you want to push this to the caller.
Patches 1-4 are r-b me, and I'll apply once we have put out the fire.
-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 1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On Tue, Apr 11, 2017 at 11:13:36AM +0100, Chris Wilson wrote: > Allow the caller to use the fast_timeout_us to specify how long to wait > within the atomic section, rather than transparently switching to a > sleeping loop for larger values. This is required as some callsites may > need a long wait and are in an atomic section. > > Signed-off-by: Chris Wilson > Cc: Michal Wajdeczko > Cc: Joonas Lahtinen > --- > drivers/gpu/drm/i915/intel_uncore.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index eb38392a2435..53c8457869f6 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private > *dev_priv, > * > * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. > * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us > - * must be not larger than 10 microseconds. > + * must be not larger than 20, microseconds. > * > * Note that this routine assumes the caller holds forcewake asserted, it is > * not suitable for very long waits. See intel_wait_for_register() if you > @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct > drm_i915_private *dev_priv, > int ret; > > /* Catch any overuse of this function */ > - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); > + might_sleep_if(slow_timeout_ms); > > - if (fast_timeout_us > 10) > - ret = _wait_for(done, fast_timeout_us, 10); > - else > + ret = -ETIMEDOUT; > + if (fast_timeout_us && fast_timeout_us < 2) I still think that we should not try to silently drop fast timeouts longer than 20ms. Maybe at least -EINVAL or GEM_WARN or something ? -Michal > ret = _wait_for_atomic(done, fast_timeout_us, 0); > if (ret) > ret = wait_for(done, slow_timeout_ms); > + > if (out_value) > *out_value = reg_value; > + > return ret; > #undef done > } > -- > 2.11.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
== Series Details == Series: series starting with [1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() URL : https://patchwork.freedesktop.org/series/22845/ State : success == Summary == Series 22845v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22845/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test drv_getparams_basic: Subgroup basic-subslice-total: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-reload: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-reload-final: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_basic: Subgroup create-close: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_busy: Subgroup basic-hang-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_close_race: Subgroup basic-threads: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_cs_tlb: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_basic: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_ctx_create: Subgroup basic-files: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_ctx_param: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_switch: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-default-heavy: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_basic: Subgroup gtt-render: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-bsd: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-render: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_create: Subgroup basic: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_fence: Subgroup await-hang-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-await-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-wait-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup nb-await-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-batch-kernel-default-wb: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-pro-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-prw-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-ro-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-rw-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 dmesg-warn -> PASS (fi-snb-2600) fdo#100643 Subgroup basic-uc-set-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
On Tue, Apr 11, 2017 at 11:13:37AM +0100, Chris Wilson wrote:
> submit_request() is called from an atomic context, it's not allowed to
> sleep. We have to be careful in our parameters to
> intel_uncore_wait_for_register() to limit ourselves to the atomic wait
> loop and not incur the wrath of our warnings.
>
> Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
> __intel_wait_for_register_fw()")
> Signed-off-by: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Joonas Lahtinen
> Link:
> http://patchwork.freedesktop.org/patch/msgid/20170410143807.22725-1-ch...@chris-wilson.co.uk
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index c98acc27279a..331da59a1eb5 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
> drm_i915_gem_request *request)
> I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
>
> /* Wait for the ring not to be idle, i.e. for it to wake up. */
> - if (intel_wait_for_register_fw(dev_priv,
> -GEN6_BSD_SLEEP_PSMI_CONTROL,
> -GEN6_BSD_SLEEP_INDICATOR,
> -0,
> -50))
> + if (__intel_wait_for_register_fw(dev_priv,
> + GEN6_BSD_SLEEP_PSMI_CONTROL,
> + GEN6_BSD_SLEEP_INDICATOR,
> + 0,
> + 1000, 0, NULL))
Reviewed-by: Michal Wajdeczko
-Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't mark an execlists context-switch when idle
Hi Chris,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20170410]
[cannot apply to v4.11-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Don-t-mark-an-execlists-context-switch-when-idle/20170411-183510
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x070-201715 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_irq.c: In function 'gen8_cs_irq_handler':
>> drivers/gpu/drm/i915/i915_irq.c:1362:7: error: implicit declaration of
>> function 'port_count' [-Werror=implicit-function-declaration]
if (port_count(&engine->execlist_port[0])) {
^~
cc1: some warnings being treated as errors
vim +/port_count +1362 drivers/gpu/drm/i915/i915_irq.c
1356 static __always_inline void
1357 gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int
test_shift)
1358 {
1359 bool tasklet = false;
1360
1361 if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
> 1362 if (port_count(&engine->execlist_port[0])) {
1363 set_bit(ENGINE_IRQ_EXECLIST,
&engine->irq_posted);
1364 tasklet = true;
1365 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't mark an execlists context-switch when idle
Hi Chris,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20170411]
[cannot apply to v4.11-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Don-t-mark-an-execlists-context-switch-when-idle/20170411-183510
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x003-201715 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/sysrq.h:18,
from drivers/gpu/drm/i915/i915_irq.c:31:
drivers/gpu/drm/i915/i915_irq.c: In function 'gen8_cs_irq_handler':
drivers/gpu/drm/i915/i915_irq.c:1362:7: error: implicit declaration of
function 'port_count' [-Werror=implicit-function-declaration]
if (port_count(&engine->execlist_port[0])) {
^
include/linux/compiler.h:160:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu/drm/i915/i915_irq.c:1362:3: note: in expansion of macro 'if'
if (port_count(&engine->execlist_port[0])) {
^~
cc1: some warnings being treated as errors
vim +/if +1362 drivers/gpu/drm/i915/i915_irq.c
1346
1347 if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
1348GT_BSD_CS_ERROR_INTERRUPT |
1349GT_RENDER_CS_MASTER_ERROR_INTERRUPT))
1350 DRM_DEBUG("Command parser error, gt_iir 0x%08x\n",
gt_iir);
1351
1352 if (gt_iir & GT_PARITY_ERROR(dev_priv))
1353 ivybridge_parity_error_irq_handler(dev_priv, gt_iir);
1354 }
1355
1356 static __always_inline void
1357 gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 iir, int
test_shift)
1358 {
1359 bool tasklet = false;
1360
1361 if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
> 1362 if (port_count(&engine->execlist_port[0])) {
1363 set_bit(ENGINE_IRQ_EXECLIST,
&engine->irq_posted);
1364 tasklet = true;
1365 }
1366 }
1367
1368 if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
1369 notify_ring(engine);
1370 tasklet |= i915.enable_guc_submission;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On 11/04/2017 11:13, Chris Wilson wrote: Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uncore.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index eb38392a2435..53c8457869f6 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us - * must be not larger than 10 microseconds. + * must be not larger than 20, microseconds. * * Note that this routine assumes the caller holds forcewake asserted, it is * not suitable for very long waits. See intel_wait_for_register() if you @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, int ret; /* Catch any overuse of this function */ - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + might_sleep_if(slow_timeout_ms); - if (fast_timeout_us > 10) - ret = _wait_for(done, fast_timeout_us, 10); - else + ret = -ETIMEDOUT; + if (fast_timeout_us && fast_timeout_us < 2) I agree with Michal here. Kerneldoc even says "must not be larger than 20ms" so it would be better and completely fine in my opinion to: if (GEM_WARN_ON(fast_timeout_us > 2)) return -EINVAL; Hm but it would break the bisectability of the series and break the sandybridge pcode. So patch 4/5 looks broken since it changes the timeout from 500ms to 500us. I don't see how to fix that without splitting the _fw and atomic concepts. Regards, Tvrtko ret = _wait_for_atomic(done, fast_timeout_us, 0); if (ret) ret = wait_for(done, slow_timeout_ms); + if (out_value) *out_value = reg_value; + return ret; #undef done } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] kms_cursor_crc: Force the test to run in full RGB range
In at least SKL and GLK (possibly other devices too), using a cursor
plane to scan out an fb might result in a different pipe crc than when
using a regular plane at the same position with the same fb while using
the CSC logic to limit the color range. The differences could be caused
by the cursor plane being limited to 8 bpc while the regular planes
support higher bit depths, leading to slightly different values to be
used internally. This is evidenced by the failures happening with
specific color values, 0.5 for example, but that's mostly speculation.
v2: Add more details to the commit message.
Signed-off-by: Ander Conselvan de Oliveira
---
tests/kms_cursor_crc.c | 8
1 file changed, 8 insertions(+)
diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index 206f852..1208d90 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -372,6 +372,14 @@ static void run_test(data_t *data, void (*testfunc)(data_t
*), int cursor_w, int
kmstest_pipe_name(data->pipe),
igt_output_name(output));
+ /*
+* Force test to use full range RGB. Limited range causes CRC
+* mismatches in SKL and GLK.
+*/
+ kmstest_set_connector_broadcast_rgb(data->drm_fd,
+
data->output->config.connector,
+ BROADCAST_RGB_FULL);
+
testfunc(data);
igt_info("\n%s on pipe %s, connector %s: PASSED\n\n",
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On Tue, Apr 11, 2017 at 11:13:36AM +0100, Chris Wilson wrote: > Allow the caller to use the fast_timeout_us to specify how long to wait > within the atomic section, rather than transparently switching to a > sleeping loop for larger values. This is required as some callsites may > need a long wait and are in an atomic section. > > Signed-off-by: Chris Wilson > Cc: Michal Wajdeczko > Cc: Joonas Lahtinen > --- > drivers/gpu/drm/i915/intel_uncore.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index eb38392a2435..53c8457869f6 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private > *dev_priv, > * > * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. > * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us > - * must be not larger than 10 microseconds. > + * must be not larger than 20, microseconds. > * > * Note that this routine assumes the caller holds forcewake asserted, it is > * not suitable for very long waits. See intel_wait_for_register() if you > @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct > drm_i915_private *dev_priv, > int ret; > > /* Catch any overuse of this function */ > - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); > + might_sleep_if(slow_timeout_ms); For whatever reason, replies are not in my mbox, so Tvrtko,Michal wrote: > I agree with Michal here. Kerneldoc even says "must not be larger than > 20ms" so it would be better and completely fine in my opinion to: > > if (GEM_WARN_ON(fast_timeout_us > 2)) > return -EINVAL; Not EINVAL, ENODEV if we must. So GEM_BUG_ON(fast_timeout_us > 2) as documentation? We need to keep the fast_timeout_us < X check for gcc. > Hm but it would break the bisectability of the series and break the > sandybridge pcode. No it doesn't, nobody is passing in such a large *fast_timeout_us*. What have I missed? > So patch 4/5 looks broken since it changes the timeout from 500ms to > 500us. I don't see how to fix that without splitting the _fw and atomic > concepts. That's not being broken, thats part of the fix. 500ms timeout inside an atomic section is insane. 500ms timeout outside of that is unwise and deserves an error of its own. I am quite happy to add that error and fight that battle later (as BAT is happy, EXT might not be, and users never). -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 1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On 11/04/2017 12:21, Chris Wilson wrote: On Tue, Apr 11, 2017 at 11:13:36AM +0100, Chris Wilson wrote: Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uncore.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index eb38392a2435..53c8457869f6 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us - * must be not larger than 10 microseconds. + * must be not larger than 20, microseconds. * * Note that this routine assumes the caller holds forcewake asserted, it is * not suitable for very long waits. See intel_wait_for_register() if you @@ -1623,16 +1623,17 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, int ret; /* Catch any overuse of this function */ - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + might_sleep_if(slow_timeout_ms); For whatever reason, replies are not in my mbox, so Tvrtko,Michal wrote: I agree with Michal here. Kerneldoc even says "must not be larger than 20ms" so it would be better and completely fine in my opinion to: if (GEM_WARN_ON(fast_timeout_us > 2)) return -EINVAL; Not EINVAL, ENODEV if we must. So GEM_BUG_ON(fast_timeout_us > 2) as documentation? Yeah thats fine. We need to keep the fast_timeout_us < X check for gcc. Hm but it would break the bisectability of the series and break the sandybridge pcode. No it doesn't, nobody is passing in such a large *fast_timeout_us*. What have I missed? Sounds like I got confused, sorry. So patch 4/5 looks broken since it changes the timeout from 500ms to 500us. I don't see how to fix that without splitting the _fw and atomic concepts. That's not being broken, thats part of the fix. 500ms timeout inside an atomic section is insane. 500ms timeout outside of that is unwise and deserves an error of its own. I am quite happy to add that error and fight that battle later (as BAT is happy, EXT might not be, and users never). I see. Ok, then, with the GEM_BUG_ON: 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 2/5] drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
On 11/04/2017 11:13, Chris Wilson wrote:
submit_request() is called from an atomic context, it's not allowed to
sleep. We have to be careful in our parameters to
intel_uncore_wait_for_register() to limit ourselves to the atomic wait
loop and not incur the wrath of our warnings.
Fixes: 6976e74b5fa1 ("drm/i915: Don't allow overuse of
__intel_wait_for_register_fw()")
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
Link:
http://patchwork.freedesktop.org/patch/msgid/20170410143807.22725-1-ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c98acc27279a..331da59a1eb5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1729,11 +1729,11 @@ static void gen6_bsd_submit_request(struct
drm_i915_gem_request *request)
I915_WRITE64_FW(GEN6_BSD_RNCID, 0x0);
/* Wait for the ring not to be idle, i.e. for it to wake up. */
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_BSD_SLEEP_PSMI_CONTROL,
- GEN6_BSD_SLEEP_INDICATOR,
- 0,
- 50))
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_BSD_SLEEP_PSMI_CONTROL,
+GEN6_BSD_SLEEP_INDICATOR,
+0,
+1000, 0, NULL))
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
/* Now that the ring is fully powered up, update the tail */
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 3/5] drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
On 11/04/2017 11:13, Chris Wilson wrote:
We acquire the forcewake and use I915_READ_FW instead for the atomic
wait within intel_uncore_wait_for_register. However, this still leaves
us vulnerable to concurrent mmio access to the register, which can cause
system hangs on gen7. The protection is to acquire uncore.lock around
each register, so lets add it back.
v2: Wrap __intel_wait_for_register_fw() to re-use its atomic wait_for
loop and spare adding another for ourselves.
v3: Add might_sleep() annotation
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uncore.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 53c8457869f6..f43121700f83 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1661,14 +1661,22 @@ int intel_wait_for_register(struct drm_i915_private
*dev_priv,
u32 value,
unsigned int timeout_ms)
{
-
unsigned fw =
intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
int ret;
- intel_uncore_forcewake_get(dev_priv, fw);
- ret = wait_for_us((I915_READ_FW(reg) & mask) == value, 2);
- intel_uncore_forcewake_put(dev_priv, fw);
+ might_sleep();
+
+ spin_lock_irq(&dev_priv->uncore.lock);
+ intel_uncore_forcewake_get__locked(dev_priv, fw);
+
+ ret = __intel_wait_for_register_fw(dev_priv,
+ reg, mask, value,
+ 2, 0, NULL);
+
+ intel_uncore_forcewake_put__locked(dev_priv, fw);
+ spin_unlock_irq(&dev_priv->uncore.lock);
+
if (ret)
ret = wait_for((I915_READ_NOTRACE(reg) & mask) == value,
timeout_ms);
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] [PATCH v2] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. v2: Reinforce kerneldoc fast_timeout_us limit with a GEM_BUG_ON Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_uncore.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index eb38392a2435..dded42db880b 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us - * must be not larger than 10 microseconds. + * must be not larger than 20, microseconds. * * Note that this routine assumes the caller holds forcewake asserted, it is * not suitable for very long waits. See intel_wait_for_register() if you @@ -1623,16 +1623,18 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, int ret; /* Catch any overuse of this function */ - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + might_sleep_if(slow_timeout_ms); + GEM_BUG_ON(fast_timeout_us > 2); - if (fast_timeout_us > 10) - ret = _wait_for(done, fast_timeout_us, 10); - else + ret = -ETIMEDOUT; + if (fast_timeout_us && fast_timeout_us <= 2) ret = _wait_for_atomic(done, fast_timeout_us, 0); if (ret) ret = wait_for(done, slow_timeout_ms); + if (out_value) *out_value = reg_value; + return ret; #undef done } -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use __intel_uncore_wait_for_register_fw for sandybride_pcode_read
On 11/04/2017 11:13, Chris Wilson wrote:
Since the sandybridge_pcode_read() may be called from
skl_pcode_request() inside an atomic context (with preempt disabled), we
should avoid hitting any sleeping paths.
Please update the commit to mention the timeout decrease and with that:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 55e1e88cd361..cacb65fa2dd5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8135,9 +8135,9 @@ int sandybridge_pcode_read(struct drm_i915_private
*dev_priv, u32 mbox, u32 *val
I915_WRITE_FW(GEN6_PCODE_DATA1, 0);
I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0,
- 500)) {
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_PCODE_MAILBOX, GEN6_PCODE_READY,
0,
+500, 0, NULL)) {
DRM_ERROR("timeout waiting for pcode read (%d) to finish\n",
mbox);
return -ETIMEDOUT;
}
@@ -8180,9 +8180,9 @@ int sandybridge_pcode_write(struct drm_i915_private
*dev_priv,
I915_WRITE_FW(GEN6_PCODE_DATA1, 0);
I915_WRITE_FW(GEN6_PCODE_MAILBOX, GEN6_PCODE_READY | mbox);
- if (intel_wait_for_register_fw(dev_priv,
- GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0,
- 500)) {
+ if (__intel_wait_for_register_fw(dev_priv,
+GEN6_PCODE_MAILBOX, GEN6_PCODE_READY,
0,
+500, 0, NULL)) {
DRM_ERROR("timeout waiting for pcode write (%d) to finish\n",
mbox);
return -ETIMEDOUT;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use safer intel_uncore_wait_for_register in ring-init
On 11/04/2017 11:13, Chris Wilson wrote:
While we do hold the forcewake for legacy ringbuffer initialisation, we
don't guard our access with the uncore.lock spinlock. In theory, we only
initialise when no others should be accessing the same mmio cachelines,
but in practice be safe as this is an infrequently used path and not
worth risky micro-optimisations.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 331da59a1eb5..97d5fcca8805 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -538,9 +538,9 @@ static int init_ring_common(struct intel_engine_cs *engine)
I915_WRITE_CTL(engine, RING_CTL_SIZE(ring->size) | RING_VALID);
/* If the head is still not zero, the ring is dead */
- if (intel_wait_for_register_fw(dev_priv, RING_CTL(engine->mmio_base),
- RING_VALID, RING_VALID,
- 50)) {
+ if (intel_wait_for_register(dev_priv, RING_CTL(engine->mmio_base),
+ RING_VALID, RING_VALID,
+ 50)) {
DRM_ERROR("%s initialization failed "
"ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x]
start %08x [expected %08x]\n",
engine->name,
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] drm/i915: Don't mark an execlists context-switch when idle
On Tue, Apr 11, 2017 at 10:18:56AM +0100, Chris Wilson wrote: > If we *know* that the engine is idle, i.e. we have not more contexts in > lift, we can skip any spurious CSB idle interrupts. These spurious > interrupts seem to arrive long after we assert that the engines are > completely idle, triggering later assertions: > > [ 178.896646] intel_engine_is_idle(bcs): interrupt not handled, irq_posted=2 > [ 178.896655] [ cut here ] > [ 178.896658] kernel BUG at drivers/gpu/drm/i915/intel_engine_cs.c:226! > [ 178.896661] invalid opcode: [#1] SMP > [ 178.896663] Modules linked in: i915(E) x86_pkg_temp_thermal(E) > crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) > nls_ascii(E) nls_cp437(E) vfat(E) fat(E) intel_gtt(E) i2c_algo_bit(E) > drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) > aesni_intel(E) prime_numbers(E) evdev(E) aes_x86_64(E) drm(E) crypto_simd(E) > cryptd(E) glue_helper(E) mei_me(E) mei(E) lpc_ich(E) efivars(E) mfd_core(E) > battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) tpm_tis_core(E) tpm(E) > autofs4(E) i2c_i801(E) fan(E) thermal(E) i2c_designware_platform(E) > i2c_designware_core(E) > [ 178.896694] CPU: 1 PID: 522 Comm: gem_exec_whispe Tainted: GE > 4.11.0-rc5+ #14 > [ 178.896702] task: 88040aba8d40 task.stack: c93f > [ 178.896722] RIP: 0010:intel_engine_init_global_seqno+0x1db/0x1f0 [i915] > [ 178.896725] RSP: 0018:c93f3ab0 EFLAGS: 00010246 > [ 178.896728] RAX: RBX: 88040af54000 RCX: > > [ 178.896731] RDX: 88041ec933e0 RSI: 88041ec8cc48 RDI: > 88041ec8cc48 > [ 178.896734] RBP: c93f3ac8 R08: R09: > 047d > [ 178.896736] R10: 0040 R11: 88040b344f80 R12: > > [ 178.896739] R13: 88040bce R14: 88040bce52d8 R15: > 88040bce > [ 178.896742] FS: 7f22d8c0() GS:88041ec8() > knlGS: > [ 178.896746] CS: 0010 DS: ES: CR0: 80050033 > [ 178.896749] CR2: 7f41ddd8f000 CR3: 00040bb03000 CR4: > 001406e0 > [ 178.896752] Call Trace: > [ 178.896768] reset_all_global_seqno.part.33+0x4e/0xd0 [i915] > [ 178.896782] i915_gem_request_alloc+0x304/0x330 [i915] > [ 178.896795] i915_gem_do_execbuffer+0x8a1/0x17d0 [i915] > [ 178.896799] ? remove_wait_queue+0x48/0x50 > [ 178.896812] ? i915_wait_request+0x300/0x590 [i915] > [ 178.896816] ? wake_up_q+0x70/0x70 > [ 178.896819] ? refcount_dec_and_test+0x11/0x20 > [ 178.896823] ? reservation_object_add_excl_fence+0xa5/0x100 > [ 178.896835] i915_gem_execbuffer2+0xab/0x1f0 [i915] > [ 178.896844] drm_ioctl+0x1e6/0x460 [drm] > [ 178.896858] ? i915_gem_execbuffer+0x260/0x260 [i915] > [ 178.896862] ? dput+0xcf/0x250 > [ 178.896866] ? full_proxy_release+0x66/0x80 > [ 178.896869] ? mntput+0x1f/0x30 > [ 178.896872] do_vfs_ioctl+0x8f/0x5b0 > [ 178.896875] ? fput+0x9/0x10 > [ 178.896878] ? task_work_run+0x80/0xa0 > [ 178.896881] SyS_ioctl+0x3c/0x70 > [ 178.896885] entry_SYSCALL_64_fastpath+0x17/0x98 > [ 178.896888] RIP: 0033:0x7f2ccb455ca7 > [ 178.896890] RSP: 002b:7ffcabec72d8 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 178.896894] RAX: ffda RBX: 55f897a44b90 RCX: > 7f2ccb455ca7 > [ 178.896897] RDX: 7ffcabec74a0 RSI: 40406469 RDI: > 0003 > [ 178.896900] RBP: 7f2ccb70a440 R08: 7f2ccb70d0a4 R09: > > [ 178.896903] R10: R11: 0246 R12: > > [ 178.896905] R13: 55f89782d71a R14: 7ffcabecf838 R15: > 0003 > [ 178.896908] Code: 00 31 d2 4c 89 ef 8d 70 48 41 ff 95 f8 06 00 00 e9 68 fe > ff ff be 0f 00 00 00 48 c7 c7 48 dc 37 a0 e8 fa 33 d6 e0 e9 0b ff ff ff <0f> > 0b 0f 0b 0f 0b 0f 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 > > On the other hand, by ignoring the interrupt do we risk running out of > space in CSB ring? Testing for a few hours suggests not, i.e. that we > only seem to get the odd delayed CSB idle notification. The alternative is not to report upon engine->irq_posted from within intel_engine_is_idle() but that loses us an important safety check for e.g. suspend. -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] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On 11/04/2017 12:27, Chris Wilson wrote: Allow the caller to use the fast_timeout_us to specify how long to wait within the atomic section, rather than transparently switching to a sleeping loop for larger values. This is required as some callsites may need a long wait and are in an atomic section. v2: Reinforce kerneldoc fast_timeout_us limit with a GEM_BUG_ON Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_uncore.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index eb38392a2435..dded42db880b 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1601,7 +1601,7 @@ static int gen6_reset_engines(struct drm_i915_private *dev_priv, * * Otherwise, the wait will timeout after @slow_timeout_ms milliseconds. * For atomic context @slow_timeout_ms must be zero and @fast_timeout_us - * must be not larger than 10 microseconds. + * must be not larger than 20, microseconds. * * Note that this routine assumes the caller holds forcewake asserted, it is * not suitable for very long waits. See intel_wait_for_register() if you @@ -1623,16 +1623,18 @@ int __intel_wait_for_register_fw(struct drm_i915_private *dev_priv, int ret; /* Catch any overuse of this function */ - might_sleep_if(fast_timeout_us > 10 || slow_timeout_ms); + might_sleep_if(slow_timeout_ms); + GEM_BUG_ON(fast_timeout_us > 2); - if (fast_timeout_us > 10) - ret = _wait_for(done, fast_timeout_us, 10); - else + ret = -ETIMEDOUT; + if (fast_timeout_us && fast_timeout_us <= 2) ret = _wait_for_atomic(done, fast_timeout_us, 0); if (ret) ret = wait_for(done, slow_timeout_ms); + if (out_value) *out_value = reg_value; + return ret; #undef done } 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 5/5] drm/i915: Use the engine class to get the context size
On 11/04/2017 11:25, Chris Wilson wrote:
On Mon, Apr 10, 2017 at 07:34:33AM -0700, Oscar Mateo wrote:
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 33 +
drivers/gpu/drm/i915/intel_lrc.h | 6 +-
2 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0dc1cc4..1c6672c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1908,8 +1908,10 @@ static void execlists_init_reg_state(u32 *regs,
}
/**
- * intel_lr_context_size() - return the size of the context for an engine
- * @engine: which engine to find the context size for
+ * intel_lr_class_context_size() - return the size of the context for a given
+ * engine class
+ * @dev_priv: i915 device private
+ * @class: which engine class to find the context size for
*
* Each engine may require a different amount of space for a context image,
* so when allocating (or copying) an image, this function can be used to
@@ -1921,25 +1923,32 @@ static void execlists_init_reg_state(u32 *regs,
* in LRC mode, but does not include the "shared data page" used with
* GuC submission. The caller should account for this if using the GuC.
*/
-uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
+uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv, u8
class)
{
int ret = 0;
- WARN_ON(INTEL_GEN(engine->i915) < 8);
+ WARN_ON(INTEL_GEN(dev_priv) < 8);
- switch (engine->id) {
- case RCS:
- if (INTEL_GEN(engine->i915) >= 9)
+ switch (class) {
+ case RENDER_CLASS:
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ case 9:
ret = GEN9_LR_CONTEXT_RENDER_SIZE;
- else
+ break;
+ case 8:
ret = GEN8_LR_CONTEXT_RENDER_SIZE;
+ break;
+ }
break;
- case VCS:
- case BCS:
- case VECS:
- case VCS2:
+ case VIDEO_DECODE_CLASS:
+ case VIDEO_ENHANCEMENT_CLASS:
+ case COPY_ENGINE_CLASS:
ret = GEN8_LR_CONTEXT_OTHER_SIZE;
break;
+ default:
+ MISSING_CASE(class);
}
return ret;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index e8015e7..bde2b6e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -78,7 +78,11 @@ enum {
struct drm_i915_private;
struct i915_gem_context;
-uint32_t intel_lr_context_size(struct intel_engine_cs *engine);
+uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv, u8
class);
+static inline uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
+{
+ return intel_lr_class_context_size(engine->i915, engine->class);
+}
I'm not understanding why you want to push this to the caller.
Patches 1-4 are r-b me, and I'll apply once we have put out the fire.
Just to say you can keep my r-b if you change this detail. I wondered
the same myself but didn't consider it too critical.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Split the engine info table in two levels, using class + instance
On 10/04/2017 15:34, Oscar Mateo wrote:
There are some properties that logically belong to the engine class, and some
that belong to the engine instance. Make it explicit.
v2: Commit message (Tvrtko)
v3:
- Rebased
- Exec/uabi id should be per instance (Chris)
v4:
- Rebased
- Avoid re-ordering fields for smaller diff (Tvrtko)
- Bug on oob access to the class array (Michal)
v5: Bug on the right thing (Michal)
v6: Rebased
Cc: Tvrtko Ursulin
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Michal Wajdeczko
Signed-off-by: Oscar Mateo
Conflicts:
drivers/gpu/drm/i915/intel_engine_cs.c
Snip this next time unless it sneaked in by accident.
---
drivers/gpu/drm/i915/intel_engine_cs.c | 65 ++
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 5e5cda0..80cb0ff 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -26,71 +26,84 @@
#include "intel_ringbuffer.h"
#include "intel_lrc.h"
-static const struct engine_info {
+struct engine_class_info {
const char *name;
- unsigned int exec_id;
+ int (*init_legacy)(struct intel_engine_cs *engine);
+ int (*init_execlists)(struct intel_engine_cs *engine);
+};
+
+static const struct engine_class_info intel_engine_classes[] = {
+ [RENDER_CLASS] = {
+ .name = "rcs",
+ .init_execlists = logical_render_ring_init,
+ .init_legacy = intel_init_render_ring_buffer,
+ },
+ [COPY_ENGINE_CLASS] = {
+ .name = "bcs",
+ .init_execlists = logical_xcs_ring_init,
+ .init_legacy = intel_init_blt_ring_buffer,
+ },
+ [VIDEO_DECODE_CLASS] = {
+ .name = "vcs",
+ .init_execlists = logical_xcs_ring_init,
+ .init_legacy = intel_init_bsd_ring_buffer,
+ },
+ [VIDEO_ENHANCEMENT_CLASS] = {
+ .name = "vecs",
+ .init_execlists = logical_xcs_ring_init,
+ .init_legacy = intel_init_vebox_ring_buffer,
+ },
+};
+
+struct engine_info {
unsigned int hw_id;
+ unsigned int exec_id;
u8 class;
u8 instance;
u32 mmio_base;
unsigned irq_shift;
- int (*init_legacy)(struct intel_engine_cs *engine);
- int (*init_execlists)(struct intel_engine_cs *engine);
-} intel_engines[] = {
+};
+
+static const struct engine_info intel_engines[] = {
[RCS] = {
- .name = "rcs",
.hw_id = RCS_HW,
.exec_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
.instance = 0,
.mmio_base = RENDER_RING_BASE,
.irq_shift = GEN8_RCS_IRQ_SHIFT,
- .init_execlists = logical_render_ring_init,
- .init_legacy = intel_init_render_ring_buffer,
},
[BCS] = {
- .name = "bcs",
.hw_id = BCS_HW,
.exec_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
.instance = 0,
.mmio_base = BLT_RING_BASE,
.irq_shift = GEN8_BCS_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_blt_ring_buffer,
},
[VCS] = {
- .name = "vcs",
.hw_id = VCS_HW,
.exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 0,
.mmio_base = GEN6_BSD_RING_BASE,
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_bsd_ring_buffer,
},
[VCS2] = {
- .name = "vcs",
.hw_id = VCS2_HW,
.exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 1,
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_bsd_ring_buffer,
},
[VECS] = {
- .name = "vecs",
.hw_id = VECS_HW,
.exec_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
.instance = 0,
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
- .init_execlists = logical_xcs_ring_init,
- .init_legacy = intel_init_vebox_ring_buffer,
},
};
@@ -99,8 +112,12 @@
enum intel_engine_id id)
{
const struct engine_info *info = &intel_engines[id];
+ const struct engine_class_info *class_info;
struct intel_engine_cs *engine;
+ GEM_BUG_ON(info->c
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() (rev2)
== Series Details == Series: series starting with [v2] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() (rev2) URL : https://patchwork.freedesktop.org/series/22845/ State : failure == Summary == Series 22845v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22845/revisions/2/mbox/ Test core_auth: Subgroup basic-auth: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test drv_getparams_basic: Subgroup basic-subslice-total: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test drv_module_reload: Subgroup basic-no-display: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-reload: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-reload-final: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_basic: Subgroup create-close: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_busy: Subgroup basic-hang-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_close_race: Subgroup basic-threads: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_cs_tlb: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_basic: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_create: Subgroup basic-files: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_param: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_ctx_switch: Subgroup basic-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-default-heavy: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_basic: Subgroup basic-render: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup gtt-bsd: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup gtt-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup readonly-blt: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_create: Subgroup basic: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_fence: Subgroup await-hang-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-await-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-busy-default: dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup nb-await-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-batch-kernel-default-wb: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-pro-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-prw-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-ro-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-rw-default: dmesg-warn -> PASS (fi-snb-2600) fdo#100643 dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 Subgroup basic-uc-set-default:
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register()
On Tue, Apr 11, 2017 at 10:30:00AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/5] drm/i915: Stop second guessing the caller > for intel_uncore_wait_for_register() > URL : https://patchwork.freedesktop.org/series/22845/ > State : success > > == Summary == > > Series 22845v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/22845/revisions/1/mbox/ > > Test core_auth: > Subgroup basic-auth: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test drv_getparams_basic: > Subgroup basic-subslice-total: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test drv_module_reload: > Subgroup basic-no-display: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-reload: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-reload-final: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_basic: > Subgroup create-close: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_busy: > Subgroup basic-hang-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_close_race: > Subgroup basic-threads: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_cs_tlb: > Subgroup basic-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_ctx_basic: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_ctx_create: > Subgroup basic-files: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_ctx_param: > Subgroup basic-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Test gem_ctx_switch: > Subgroup basic-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-default-heavy: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_exec_basic: > Subgroup gtt-render: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup readonly-bsd: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup readonly-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup readonly-render: > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_exec_create: > Subgroup basic: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_exec_fence: > Subgroup await-hang-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-await-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-wait-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > Subgroup nb-await-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-batch-kernel-default-wb: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-uc-pro-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-uc-prw-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup basic-uc-ro-default: > dmesg-warn -> PASS (fi-snb-2520m) fdo#100643 > dmesg-warn -> PASS (fi-snb-2600) fdo#100643 > Subgroup
Re: [Intel-gfx] Fixes that failed to backport to v4.11-rc1
On Wed, 29 Mar 2017, Jani Nikula wrote:
> On Tue, 21 Mar 2017, Jani Nikula wrote:
>> On Mon, 13 Mar 2017, Jani Nikula wrote:
>>> I'm already scripting my fixes backports quite a bit, and frankly don't
>>> really manually backport anything that doesn't apply cleanly. I'm
>>> thinking of automating some "failed to backport" reporting to authors,
>>> not unlike the failed stable backport reports.
>>>
>>> This is a manual report that the following commits have been marked as
>>> Cc: stable or fixing something in v4.11-rc1, but failed to cherry-pick
>>> to drm-intel-fixes. Please see if they are worth backporting, and please
>>> do so if they are.
>>>
>>> Feedback about the idea of this reporting is also appreciated.
>>
>> Refreshed list as of today:
>>
>> bd784b7cc41a ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")
>> 3fc03069bc6e ("drm/i915: make context status notifier head be per engine")
>> 2e8f9d322948 ("drm/i915: Restore engine->submit_request before unwedging")
>
> Update:
>
> e2a2aa36a509 ("drm/i915: Check we have an wake device before flushing GTT
> writes")
> 450362d3fe86 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")
Update:
a7980a640cbd ("drm/i915: Apply a cond_resched() to the saturated signaler")
BR,
Jani.
--
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 5/5] drm/i915: Use the engine class to get the context size
On Tue, Apr 11, 2017 at 12:32:14PM +0100, Tvrtko Ursulin wrote:
>
> On 11/04/2017 11:25, Chris Wilson wrote:
> >On Mon, Apr 10, 2017 at 07:34:33AM -0700, Oscar Mateo wrote:
> >>From: Daniele Ceraolo Spurio
> >>
> >>Technically speaking, the context size is per engine class, not per
> >>instance.
> >>
> >>---
> >>diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> >>b/drivers/gpu/drm/i915/intel_lrc.h
> >>index e8015e7..bde2b6e 100644
> >>--- a/drivers/gpu/drm/i915/intel_lrc.h
> >>+++ b/drivers/gpu/drm/i915/intel_lrc.h
> >>@@ -78,7 +78,11 @@ enum {
> >> struct drm_i915_private;
> >> struct i915_gem_context;
> >>
> >>-uint32_t intel_lr_context_size(struct intel_engine_cs *engine);
> >>+uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv, u8
> >>class);
> >>+static inline uint32_t intel_lr_context_size(struct intel_engine_cs
> >>*engine)
> >>+{
> >>+ return intel_lr_class_context_size(engine->i915, engine->class);
> >>+}
> >
> >I'm not understanding why you want to push this to the caller.
> >
> >Patches 1-4 are r-b me, and I'll apply once we have put out the fire.
>
> Just to say you can keep my r-b if you change this detail. I
> wondered the same myself but didn't consider it too critical.
I've pushed the first 4 patches. Patch 5 is good to go once we have
clarification why you want to expose the per-class lookup to
context_size (or restore the interface back to hiding the class lookup).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. s/includs/includes/ But spelling aside, Acked-by: Rob Clark > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. > -- > 2.11.0 > > ___ > 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
[Intel-gfx] [CI] drm/i915: Rename intel_engine_cs.exec_id to uabi_id
We want to refer to the index of the engine consistently throughout the
userspace ABI. We already have such an index through the execbuffer
engine specifier, that needs to be able to refer to each engine
specifically, so rename it the index to uabi_id to reflect its
generality beyond execbuf.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 8
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7af100f84410..2a1a3347495a 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1166,8 +1166,8 @@ static bool check_cmd(const struct intel_engine_cs
*engine,
find_reg(engine, is_master, reg_addr);
if (!reg) {
- DRM_DEBUG_DRIVER("CMD: Rejected register 0x%08X
in command: 0x%08X (exec_id=%d)\n",
-reg_addr, *cmd,
engine->exec_id);
+ DRM_DEBUG_DRIVER("CMD: Rejected register 0x%08X
in command: 0x%08X (%s)\n",
+reg_addr, *cmd, engine->name);
return false;
}
@@ -1222,11 +1222,11 @@ static bool check_cmd(const struct intel_engine_cs
*engine,
desc->bits[i].mask;
if (dword != desc->bits[i].expected) {
- DRM_DEBUG_DRIVER("CMD: Rejected command 0x%08X
for bitmask 0x%08X (exp=0x%08X act=0x%08X) (exec_id=%d)\n",
+ DRM_DEBUG_DRIVER("CMD: Rejected command 0x%08X
for bitmask 0x%08X (exp=0x%08X act=0x%08X) (%s)\n",
*cmd,
desc->bits[i].mask,
desc->bits[i].expected,
-dword, engine->exec_id);
+dword, engine->name);
return false;
}
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b210acc3d0b4..cb8c6a94ba4e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3996,7 +3996,7 @@ __busy_set_if_active(const struct dma_fence *fence,
if (i915_gem_request_completed(rq))
return 0;
- return flag(rq->engine->exec_id);
+ return flag(rq->engine->uabi_id);
}
static __always_inline unsigned int
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 058ecc020b28..71e89a93fe18 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -57,7 +57,7 @@ static const struct engine_class_info intel_engine_classes[]
= {
struct engine_info {
unsigned int hw_id;
- unsigned int exec_id;
+ unsigned int uabi_id;
u8 class;
u8 instance;
u32 mmio_base;
@@ -67,7 +67,7 @@ struct engine_info {
static const struct engine_info intel_engines[] = {
[RCS] = {
.hw_id = RCS_HW,
- .exec_id = I915_EXEC_RENDER,
+ .uabi_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
.instance = 0,
.mmio_base = RENDER_RING_BASE,
@@ -75,7 +75,7 @@ static const struct engine_info intel_engines[] = {
},
[BCS] = {
.hw_id = BCS_HW,
- .exec_id = I915_EXEC_BLT,
+ .uabi_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
.instance = 0,
.mmio_base = BLT_RING_BASE,
@@ -83,7 +83,7 @@ static const struct engine_info intel_engines[] = {
},
[VCS] = {
.hw_id = VCS_HW,
- .exec_id = I915_EXEC_BSD,
+ .uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 0,
.mmio_base = GEN6_BSD_RING_BASE,
@@ -91,7 +91,7 @@ static const struct engine_info intel_engines[] = {
},
[VCS2] = {
.hw_id = VCS2_HW,
- .exec_id = I915_EXEC_BSD,
+ .uabi_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 1,
.mmio_base = GEN8_BSD2_RING_BASE,
@@ -99,7 +99,7 @@ static const struct engine_info intel_engines[] = {
},
[VECS] = {
.hw_id = VECS_HW,
- .exec_id = I915_EXEC_VEBOX,
+ .uabi_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLAS
Re: [Intel-gfx] [GIT PULL] one more GVT-g fix for 4.11
On Fri, 07 Apr 2017, Zhenyu Wang wrote: > Hi, > > Still need this one from Min for correct execlist csb initial > read ptr fix, which could possibly cause guest hang. Pulled to drm-intel-fixes, thanks. BR, Jani. > > Thanks. > --- > > The following changes since commit aa4ce4493c88dc324911152d1ccd25469366dba3: > > drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state > (2017-04-01 13:13:27 +0800) > > are available in the git repository at: > > https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-04-07 > > for you to fetch changes up to a34f83639490a5cc11a9d5c1b3773d4b6eb69a9e: > > drm/i915/gvt: set the correct default value of CTX STATUS PTR (2017-04-06 > 11:08:04 +0800) > > > gvt-fixes-2017-04-07 > > - execlist csb initial read ptr fix (Min) > > > Min He (1): > drm/i915/gvt: set the correct default value of CTX STATUS PTR > > drivers/gpu/drm/i915/gvt/execlist.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) -- 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: Document code of conduct
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the "started" and "chatting"? That is very weakly formulated. > X.org foundation board, to figure out how to fan out enforcement and This was not voted upon or even mentioned during the last board meeting. And i think the next board meeting is only in 2 days time. As such, this seems like it is not something that's officially sanctioned by the X.org foundation board, but you sure do try to make it sound like such. Luc Verhaegen. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: >> freedesktop.org has adopted a formal&enforced code of conduct: >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> Besides formalizing things a bit more I don't think this changes >> anything for us, we've already peer-enforced respectful and >> constructive interactions since a long time. But it's good to document >> things properly. >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> started chatting with the communities their hosting, which includs the > > "started" and "chatting"? That is very weakly formulated. Intentionally so ... >> X.org foundation board, to figure out how to fan out enforcement and > > This was not voted upon or even mentioned during the last board meeting. > And i think the next board meeting is only in 2 days time. As such, this > seems like it is not something that's officially sanctioned by the X.org > foundation board, but you sure do try to make it sound like such. ... because it is not yet sanctioned by the board in any way. So not exactly sure where you're reading this into my commit message, because it wasn't my intention to make it sounds like this is sanctioned by the xorg board officially, nor did I state that anywhere. I just said that discussions already started to happen, that's really all there is. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Rename intel_engine_cs.exec_id to uabi_id
== Series Details == Series: drm/i915: Rename intel_engine_cs.exec_id to uabi_id URL : https://patchwork.freedesktop.org/series/22849/ State : warning == Summary == Series 22849v1 drm/i915: Rename intel_engine_cs.exec_id to uabi_id https://patchwork.freedesktop.org/api/1.0/series/22849/revisions/1/mbox/ Test gem_exec_reloc: Subgroup basic-cpu-read-active: incomplete -> PASS (fi-hsw-4770) Test kms_force_connector_basic: Subgroup prune-stale-modes: pass -> SKIP (fi-snb-2600) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-bsw-n3050) fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:439s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:427s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:575s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:504s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:490s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:427s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:453s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:655s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:464s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:571s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:461s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:495s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:429s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:533s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:0 skip:30 time:412s 20c20ad1f78a8a23c2b96845bfc332e477e602a3 drm-tip: 2017y-04m-11d-12h-34m-10s UTC integration manifest f44a74c drm/i915: Rename intel_engine_cs.exec_id to uabi_id == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4472/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: > > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > >> freedesktop.org has adopted a formal&enforced code of conduct: > >> > >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ > >> https://www.freedesktop.org/wiki/CodeOfConduct/ > >> > >> Besides formalizing things a bit more I don't think this changes > >> anything for us, we've already peer-enforced respectful and > >> constructive interactions since a long time. But it's good to document > >> things properly. > >> > >> Note: As Daniel Stone mentioned in the announcement fd.o admins > >> started chatting with the communities their hosting, which includs the > > > > "started" and "chatting"? That is very weakly formulated. > > Intentionally so ... > > >> X.org foundation board, to figure out how to fan out enforcement and > > > > This was not voted upon or even mentioned during the last board meeting. > > And i think the next board meeting is only in 2 days time. As such, this > > seems like it is not something that's officially sanctioned by the X.org > > foundation board, but you sure do try to make it sound like such. > > ... because it is not yet sanctioned by the board in any way. So not > exactly sure where you're reading this into my commit message, because > it wasn't my intention to make it sounds like this is sanctioned by > the xorg board officially, nor did I state that anywhere. I just said > that discussions already started to happen, that's really all there > is. Thanks for making that clear. Luc Verhaegen. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
Hey On Tue, Apr 11, 2017 at 8:48 AM, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter Reviewed-by: David Herrmann Thanks David > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote: > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: >> >> freedesktop.org has adopted a formal&enforced code of conduct: >> >> >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> >> >> Besides formalizing things a bit more I don't think this changes >> >> anything for us, we've already peer-enforced respectful and >> >> constructive interactions since a long time. But it's good to document >> >> things properly. >> >> >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> >> started chatting with the communities their hosting, which includs the >> > >> > "started" and "chatting"? That is very weakly formulated. >> >> Intentionally so ... >> >> >> X.org foundation board, to figure out how to fan out enforcement and >> > >> > This was not voted upon or even mentioned during the last board meeting. >> > And i think the next board meeting is only in 2 days time. As such, this >> > seems like it is not something that's officially sanctioned by the X.org >> > foundation board, but you sure do try to make it sound like such. >> >> ... because it is not yet sanctioned by the board in any way. So not >> exactly sure where you're reading this into my commit message, because >> it wasn't my intention to make it sounds like this is sanctioned by >> the xorg board officially, nor did I state that anywhere. I just said >> that discussions already started to happen, that's really all there >> is. > > Thanks for making that clear. Yeah I understand the confusion, since it wasn't clear that this mail was written by me with my drm maintainer hat on, not me in my role as xorg bod secretary. Nor me as an intel employee. I should have made that clearer. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Rename intel_engine_cs.exec_id to uabi_id
On Tue, Apr 11, 2017 at 01:26:51PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Rename intel_engine_cs.exec_id to uabi_id > URL : https://patchwork.freedesktop.org/series/22849/ > State : warning > > == Summary == > > Series 22849v1 drm/i915: Rename intel_engine_cs.exec_id to uabi_id > https://patchwork.freedesktop.org/api/1.0/series/22849/revisions/1/mbox/ > > Test gem_exec_reloc: > Subgroup basic-cpu-read-active: > incomplete -> PASS (fi-hsw-4770) > Test kms_force_connector_basic: > Subgroup prune-stale-modes: > pass -> SKIP (fi-snb-2600) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > dmesg-warn -> PASS (fi-bsw-n3050) Unrelated, so pushed the simple rename of this field. Now to find seconds for my grand plan... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Combine write_domain flushes to a single function
In the next patch, we will introduce a new cache domain for
differentiating between GTT access and direct WC access. This will
require us to include WC in our write_domain flushes. Rather than
duplicate a third function, combine the existing two into one and
flushing WC writes will then be automatically handled as well.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 123 ++---
.../gpu/drm/i915/selftests/i915_gem_coherency.c| 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
3 files changed, 63 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cb8c6a94ba4e..354082df10c4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -46,8 +46,6 @@
#include
static void i915_gem_flush_free_objects(struct drm_i915_private *i915);
-static void i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object
*obj);
-static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object
*obj);
static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
{
@@ -705,6 +703,62 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
args->size, &args->handle);
}
+static inline enum fb_op_origin
+write_origin(struct drm_i915_gem_object *obj, unsigned int domain)
+{
+ return (domain == I915_GEM_DOMAIN_GTT ?
+ obj->frontbuffer_ggtt_origin : ORIGIN_CPU);
+}
+
+static void
+flush_write_domain(struct drm_i915_gem_object *obj,
+ unsigned int exclude_write_domain)
+{
+ struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+
+ if (!obj->base.write_domain ||
+ obj->base.write_domain == exclude_write_domain)
+ return;
+
+ /* No actual flushing is required for the GTT write domain. Writes
+* to it "immediately" go to main memory as far as we know, so there's
+* no chipset flush. It also doesn't land in render cache.
+*
+* However, we do have to enforce the order so that all writes through
+* the GTT land before any writes to the device, such as updates to
+* the GATT itself.
+*
+* We also have to wait a bit for the writes to land from the GTT.
+* An uncached read (i.e. mmio) seems to be ideal for the round-trip
+* timing. This issue has only been observed when switching quickly
+* between GTT writes and CPU reads from inside the kernel on recent hw,
+* and it appears to only affect discrete GTT blocks (i.e. on LLC
+* system agents we cannot reproduce this behaviour).
+*/
+ wmb();
+
+ switch (obj->base.write_domain) {
+ case I915_GEM_DOMAIN_GTT:
+ if (INTEL_GEN(dev_priv) >= 6 && !HAS_LLC(dev_priv)) {
+ if (intel_runtime_pm_get_if_in_use(dev_priv)) {
+ spin_lock_irq(&dev_priv->uncore.lock);
+
POSTING_READ_FW(RING_ACTHD(dev_priv->engine[RCS]->mmio_base));
+ spin_unlock_irq(&dev_priv->uncore.lock);
+ intel_runtime_pm_put(dev_priv);
+ }
+ }
+
+ intel_fb_obj_flush(obj, write_origin(obj, I915_GEM_DOMAIN_GTT));
+ break;
+
+ case I915_GEM_DOMAIN_CPU:
+ i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
+ break;
+ }
+
+ obj->base.write_domain = 0;
+}
+
static inline int
__copy_to_user_swizzled(char __user *cpu_vaddr,
const char *gpu_vaddr, int gpu_offset,
@@ -794,7 +848,7 @@ int i915_gem_obj_prepare_shmem_read(struct
drm_i915_gem_object *obj,
goto out;
}
- i915_gem_object_flush_gtt_write_domain(obj);
+ flush_write_domain(obj, I915_GEM_DOMAIN_CPU);
/* If we're not in the cpu read domain, set ourself into the gtt
* read domain and manually flush cachelines (if required). This
@@ -846,7 +900,7 @@ int i915_gem_obj_prepare_shmem_write(struct
drm_i915_gem_object *obj,
goto out;
}
- i915_gem_object_flush_gtt_write_domain(obj);
+ flush_write_domain(obj, I915_GEM_DOMAIN_CPU);
/* If we're not in the cpu write domain, set ourself into the
* gtt write domain and manually flush cachelines (as required).
@@ -1501,13 +1555,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
return ret;
}
-static inline enum fb_op_origin
-write_origin(struct drm_i915_gem_object *obj, unsigned domain)
-{
- return (domain == I915_GEM_DOMAIN_GTT ?
- obj->frontbuffer_ggtt_origin : ORIGIN_CPU);
-}
-
static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915;
@@ -3320,56 +3367,6 @@ int i915_gem_wait_for_idle(struct d
[Intel-gfx] [PATCH 2/2] drm/i915: Treat WC a separate cache domain
When discussing a new WC mmap, we based the interface upon the
assumption that GTT was fully coherent. How naive! Commits 3b5724d702ef
("drm/i915: Wait for writes through the GTT to land before reading
back") and ed4596ea992d ("drm/i915/guc: WA to address the Ringbuffer
coherency issue") demonstrate that writes through the GTT are indeed
delayed and may be overtaken by direct WC access. To be safe, if
userspace is mixing WC mmaps with other potential GTT access (pwrite,
GTT mmaps) it should use set_domain(WC).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96563
Testcase: igt/gem_pwrite/small-gtt*
Testcase: igt/drv_selftest/coherency
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h| 5 +-
drivers/gpu/drm/i915/i915_gem.c| 76 --
drivers/gpu/drm/i915/intel_guc_log.c | 6 +-
.../gpu/drm/i915/selftests/i915_gem_coherency.c| 10 +--
drivers/gpu/drm/i915/selftests/i915_gem_request.c | 2 +-
include/uapi/drm/i915_drm.h| 2 +
6 files changed, 85 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ed079c244b5d..1af4e6f5410c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3453,8 +3453,9 @@ int i915_gem_object_wait_priority(struct
drm_i915_gem_object *obj,
#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
int __must_check
-i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
- bool write);
+i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
+int __must_check
+i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write);
int __must_check
i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write);
struct i915_vma * __must_check
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 354082df10c4..aed1ce18e661 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1638,10 +1638,12 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
*data,
if (err)
goto out_unpin;
- if (read_domains & I915_GEM_DOMAIN_GTT)
- err = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
+ if (read_domains & I915_GEM_DOMAIN_WC)
+ err = i915_gem_object_set_to_wc_domain(obj, write_domain);
+ else if (read_domains & I915_GEM_DOMAIN_GTT)
+ err = i915_gem_object_set_to_gtt_domain(obj, write_domain);
else
- err = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
+ err = i915_gem_object_set_to_cpu_domain(obj, write_domain);
/* And bump the LRU for this access */
i915_gem_object_bump_inactive_ggtt(obj);
@@ -1784,6 +1786,9 @@ static unsigned int tile_row_pages(struct
drm_i915_gem_object *obj)
* into userspace. (This view is aligned and sized appropriately for
* fenced access.)
*
+ * 2 - Recognise WC as a separate cache domain so that we can flush the
+ * delayed writes via GTT before performing direct access via WC.
+ *
* Restrictions:
*
* * snoopable objects cannot be accessed via the GTT. It can cause machine
@@ -1811,7 +1816,7 @@ static unsigned int tile_row_pages(struct
drm_i915_gem_object *obj)
*/
int i915_gem_mmap_gtt_version(void)
{
- return 1;
+ return 2;
}
static inline struct i915_ggtt_view
@@ -3387,6 +3392,69 @@ void i915_gem_object_flush_if_display(struct
drm_i915_gem_object *obj)
}
/**
+ * Moves a single object to the WC read, and possibly write domain.
+ * @obj: object to act on
+ * @write: ask for write access or read only
+ *
+ * This function returns when the move is complete, including waiting on
+ * flushes to occur.
+ */
+int
+i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write)
+{
+ int ret;
+
+ lockdep_assert_held(&obj->base.dev->struct_mutex);
+
+ ret = i915_gem_object_wait(obj,
+ I915_WAIT_INTERRUPTIBLE |
+ I915_WAIT_LOCKED |
+ (write ? I915_WAIT_ALL : 0),
+ MAX_SCHEDULE_TIMEOUT,
+ NULL);
+ if (ret)
+ return ret;
+
+ if (obj->base.write_domain == I915_GEM_DOMAIN_WC)
+ return 0;
+
+ /* Flush and acquire obj->pages so that we are coherent through
+* direct access in memory with previous cached writes through
+* shmemfs and that our cache domain tracking remains valid.
+* For example, if the obj->filp was moved to swap without us
+* being notified and releasing the pages, we would mistakenly
+* continue to assume that the obj remained out of the CPU cached
+* domain.
+*/
+ r
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter Acked-by: Sean Paul > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote: > > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: > >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: > >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > >> >> freedesktop.org has adopted a formal&enforced code of conduct: > >> >> > >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ > >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ > >> >> > >> >> Besides formalizing things a bit more I don't think this changes > >> >> anything for us, we've already peer-enforced respectful and > >> >> constructive interactions since a long time. But it's good to document > >> >> things properly. > >> >> > >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins > >> >> started chatting with the communities their hosting, which includs the > >> > > >> > "started" and "chatting"? That is very weakly formulated. > >> > >> Intentionally so ... > >> > >> >> X.org foundation board, to figure out how to fan out enforcement and > >> > > >> > This was not voted upon or even mentioned during the last board meeting. > >> > And i think the next board meeting is only in 2 days time. As such, this > >> > seems like it is not something that's officially sanctioned by the X.org > >> > foundation board, but you sure do try to make it sound like such. > >> > >> ... because it is not yet sanctioned by the board in any way. So not > >> exactly sure where you're reading this into my commit message, because > >> it wasn't my intention to make it sounds like this is sanctioned by > >> the xorg board officially, nor did I state that anywhere. I just said > >> that discussions already started to happen, that's really all there > >> is. > > > > Thanks for making that clear. > > Yeah I understand the confusion, since it wasn't clear that this mail > was written by me with my drm maintainer hat on, not me in my role as > xorg bod secretary. Nor me as an intel employee. I should have made > that clearer. I was not confused about that, especially since you mentioned the board. But this clearly was not something already approved by the X.org foundation board. Luc Verhaegen. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, 11 Apr 2017, Luc Verhaegen wrote: > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote: >> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: >> >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: >> >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: >> >> >> freedesktop.org has adopted a formal&enforced code of conduct: >> >> >> >> >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> >> >> >> >> Besides formalizing things a bit more I don't think this changes >> >> >> anything for us, we've already peer-enforced respectful and >> >> >> constructive interactions since a long time. But it's good to document >> >> >> things properly. >> >> >> >> >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> >> >> started chatting with the communities their hosting, which includs the >> >> > >> >> > "started" and "chatting"? That is very weakly formulated. >> >> >> >> Intentionally so ... >> >> >> >> >> X.org foundation board, to figure out how to fan out enforcement and >> >> > >> >> > This was not voted upon or even mentioned during the last board meeting. >> >> > And i think the next board meeting is only in 2 days time. As such, this >> >> > seems like it is not something that's officially sanctioned by the X.org >> >> > foundation board, but you sure do try to make it sound like such. >> >> >> >> ... because it is not yet sanctioned by the board in any way. So not >> >> exactly sure where you're reading this into my commit message, because >> >> it wasn't my intention to make it sounds like this is sanctioned by >> >> the xorg board officially, nor did I state that anywhere. I just said >> >> that discussions already started to happen, that's really all there >> >> is. >> > >> > Thanks for making that clear. >> >> Yeah I understand the confusion, since it wasn't clear that this mail >> was written by me with my drm maintainer hat on, not me in my role as >> xorg bod secretary. Nor me as an intel employee. I should have made >> that clearer. > > I was not confused about that, especially since you mentioned the board. > But this clearly was not something already approved by the X.org > foundation board. Since there is a lot of "it" and "this" in both your and Daniel's messages, without clarifying what you're both actually talking about, I think for clarity it should be noted that, AFAIU, the decision to adopt the CoC is up to the freedesktop.org admins, not the X.org board, and the discussion about enforcing is to take place between the two. BR, Jani. -- 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] [RFC] drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON
This is slightly weaker version of MAYBE_BUILD_BUG_ON that allows
us to avoid adding implicit BUG but still detect as much as possible
during the build. With this new macro we can fix the problem with
GCC 4.4.7 that wrongly triggers build break in wait_for_atomic()
when invoked with non-const parameter.
Fixes: 1d1a9774 ("drm/i915: Extend intel_wait_for_register_fw() with fast
timeout")
Signed-off-by: Michal Wajdeczko
Suggested-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.h | 9 +
drivers/gpu/drm/i915/intel_drv.h | 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 5a49487..ce23cf1 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -42,6 +42,15 @@
#define GEM_DEBUG_BUG_ON(expr)
#endif
+#define GEM_MAYBE_BUILD_BUG_ON(expr) \
+ do { \
+ if (__builtin_constant_p((expr))) \
+ BUILD_BUG_ON(expr); \
+ else \
+ GEM_BUG_ON(expr); \
+ } while (0)
+
+
#define I915_NUM_ENGINES 5
#endif /* __I915_GEM_H__ */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7bc0c25..ce50ec4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -88,7 +88,7 @@
int cpu, ret, timeout = (US) * 1000; \
u64 base; \
_WAIT_FOR_ATOMIC_CHECK(ATOMIC); \
- BUILD_BUG_ON((US) > 5); \
+ GEM_MAYBE_BUILD_BUG_ON((US) > 5); \
if (!(ATOMIC)) { \
preempt_disable(); \
cpu = smp_processor_id(); \
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Old Laptop Linux Driver
On Mon, 10 Apr 2017, "Stangle, Steven P." wrote: > Hi all, I am looking for the best driver to use on an old computer > running RHEL 7.2. The computer is a Gateway m465-g which has an Intel > 945gm Chipset with integrated graphics - intel graphics media > accelerator (GMA) 950. > > What driver am I looking for, and how would I install it. The computer > does not connect to the internet. Any advice? Is there something wrong with the drivers shipping with RHEL 7.2? The drm/i915 shipping with upstream kernels at the time should work just fine. > This message and/or attachments may include information subject to GD > Corporate Policies 07-103 and 07-105 and is intended to be accessed > only by authorized recipients. Use, storage and transmission are > governed by General Dynamics and its policies. Contractual > restrictions apply to third parties. Recipients should refer to the > policies or contract to determine proper handling. Unauthorized > review, use, disclosure or distribution is prohibited. If you are not > an intended recipient, please contact the sender and destroy all > copies of the original message. Please ensure your messages to the intel-gfx list (or public open source mailing lists in general) do not include this kind of disclaimers. BR, Jani. -- 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 v4 09/11] drm/i915/dp: read sink count to a temporary variable first
On Thu, 06 Apr 2017, Ville Syrjälä wrote: > On Thu, Apr 06, 2017 at 04:44:17PM +0300, Jani Nikula wrote: >> Don't clobber intel_dp->sink_count with the raw value. >> >> Suggested-by: Ville Syrjälä >> Signed-off-by: Jani Nikula > > Reviewed-by: Ville Syrjälä Thanks for the reviews, pushed patches 1-9 to drm-intel-next-queued. BR, Jani. -- 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: success for series starting with [1/2] drm/i915: Combine write_domain flushes to a single function
== Series Details == Series: series starting with [1/2] drm/i915: Combine write_domain flushes to a single function URL : https://patchwork.freedesktop.org/series/22855/ State : success == Summary == Series 22855v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22855/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:428s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:424s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:574s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:481s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:480s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:410s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:404s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:455s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:571s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:467s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:573s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:454s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:492s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:428s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:533s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:414s 1a8653e657e1154a337956033af17740ef5f9dda drm-tip: 2017y-04m-11d-14h-18m-13s UTC integration manifest 324a61c drm/i915: Treat WC a separate cache domain f7cccb5 drm/i915: Combine write_domain flushes to a single function == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4473/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote: > On Tue, 11 Apr 2017, Luc Verhaegen wrote: > > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: > >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote: > >> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: > >> >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: > >> >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > >> >> >> freedesktop.org has adopted a formal&enforced code of conduct: > >> >> >> > >> >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ > >> >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ > >> >> >> > >> >> >> Besides formalizing things a bit more I don't think this changes > >> >> >> anything for us, we've already peer-enforced respectful and > >> >> >> constructive interactions since a long time. But it's good to > >> >> >> document > >> >> >> things properly. > >> >> >> > >> >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins > >> >> >> started chatting with the communities their hosting, which includs > >> >> >> the > >> >> > > >> >> > "started" and "chatting"? That is very weakly formulated. > >> >> > >> >> Intentionally so ... > >> >> > >> >> >> X.org foundation board, to figure out how to fan out enforcement and > >> >> > > >> >> > This was not voted upon or even mentioned during the last board > >> >> > meeting. > >> >> > And i think the next board meeting is only in 2 days time. As such, > >> >> > this > >> >> > seems like it is not something that's officially sanctioned by the > >> >> > X.org > >> >> > foundation board, but you sure do try to make it sound like such. > >> >> > >> >> ... because it is not yet sanctioned by the board in any way. So not > >> >> exactly sure where you're reading this into my commit message, because > >> >> it wasn't my intention to make it sounds like this is sanctioned by > >> >> the xorg board officially, nor did I state that anywhere. I just said > >> >> that discussions already started to happen, that's really all there > >> >> is. > >> > > >> > Thanks for making that clear. > >> > >> Yeah I understand the confusion, since it wasn't clear that this mail > >> was written by me with my drm maintainer hat on, not me in my role as > >> xorg bod secretary. Nor me as an intel employee. I should have made > >> that clearer. > > > > I was not confused about that, especially since you mentioned the board. > > But this clearly was not something already approved by the X.org > > foundation board. > > Since there is a lot of "it" and "this" in both your and Daniel's > messages, without clarifying what you're both actually talking about, I > think for clarity it should be noted that, AFAIU, the decision to adopt > the CoC is up to the freedesktop.org admins, not the X.org board, and > the discussion about enforcing is to take place between the two. It's the way in which this is being done that makes me very weary of this code of conduct. It seems like a very unilateral move, quite likely by just a single person. There is no record of any prior discussion, not with the affected projects, not on any mailing list, not on the irc channels where i am on (and i doubt it is logged publicly anywhere). This commit Daniel Vetter just posted comes the closest to any discussion, wayland never was so lucky. This feels like the typical freedesktop.org move, and i am quite allergic to those as i and the projects i have been involved in have been the target of such unilateral decisions several times. I see the mentioning of the X.org foundation board here as an attempt to give this surprise Code of Conduct some gravitas which it didn't deserve, as it was far too easily debunked. The board of directors never voted on this, and i would like to see the emails of the discussion prior to this mentioning here. If there were any, they were not before the surprise wayland commit. I would welcome such a code of conduct though, if it had been the result of an honest, open and transparent community discussion. But that's not something i have often seen at freedesktop.org. And i have a feeling as to how it will be applied and who or what projects it will be applied to, and how transparent that process will be. If people would be interested in seeing this Code of Conduct retro-actively, i might have a few cases that i would want to bring up, though. Luc Verhaegen. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON
== Series Details == Series: drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON URL : https://patchwork.freedesktop.org/series/22857/ State : success == Summary == Series 22857v1 drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON https://patchwork.freedesktop.org/api/1.0/series/22857/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:433s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:574s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:480s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:407s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:422s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:490s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:452s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:564s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:461s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:576s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:460s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:492s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:430s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:526s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:403s fi-bxt-j4205 failed to collect. IGT log at Patchwork_4474/fi-bxt-j4205/igt.log 1a8653e657e1154a337956033af17740ef5f9dda drm-tip: 2017y-04m-11d-14h-18m-13s UTC integration manifest 205ac62 drm/i915: Introduce GEM_MAYBE_BUILD_BUG_ON == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4474/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Bail if we do not setup the RCS engine
In places, we assume that RCS exists. This has been true forever, but
let us catch this failure during bringup by adding an explicit check
that we do have an RCS engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 71e89a93fe18..3595209d86cf 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -154,9 +154,9 @@ int intel_engines_init_early(struct drm_i915_private
*dev_priv)
{
struct intel_device_info *device_info = mkwrite_device_info(dev_priv);
unsigned int ring_mask = INTEL_INFO(dev_priv)->ring_mask;
- unsigned int mask = 0;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ unsigned int mask = 0;
unsigned int i;
int err;
@@ -183,6 +183,12 @@ int intel_engines_init_early(struct drm_i915_private
*dev_priv)
if (WARN_ON(mask != ring_mask))
device_info->ring_mask = mask;
+ /* We always presume we have at least RCS available for probing */
+ if (WARN_ON(!(mask & ENGINE_MASK(RCS {
+ err = -ENODEV;
+ goto cleanup;
+ }
+
device_info->num_rings = hweight32(mask);
return 0;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 5:14 PM, Luc Verhaegen wrote: > On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote: >> On Tue, 11 Apr 2017, Luc Verhaegen wrote: >> > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: >> >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote: >> >> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: >> >> >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: >> >> >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: >> >> >> >> freedesktop.org has adopted a formal&enforced code of conduct: >> >> >> >> >> >> >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> >> >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> >> >> >> >> >> >> Besides formalizing things a bit more I don't think this changes >> >> >> >> anything for us, we've already peer-enforced respectful and >> >> >> >> constructive interactions since a long time. But it's good to >> >> >> >> document >> >> >> >> things properly. >> >> >> >> >> >> >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> >> >> >> started chatting with the communities their hosting, which includs >> >> >> >> the >> >> >> > >> >> >> > "started" and "chatting"? That is very weakly formulated. >> >> >> >> >> >> Intentionally so ... >> >> >> >> >> >> >> X.org foundation board, to figure out how to fan out enforcement and >> >> >> > >> >> >> > This was not voted upon or even mentioned during the last board >> >> >> > meeting. >> >> >> > And i think the next board meeting is only in 2 days time. As such, >> >> >> > this >> >> >> > seems like it is not something that's officially sanctioned by the >> >> >> > X.org >> >> >> > foundation board, but you sure do try to make it sound like such. >> >> >> >> >> >> ... because it is not yet sanctioned by the board in any way. So not >> >> >> exactly sure where you're reading this into my commit message, because >> >> >> it wasn't my intention to make it sounds like this is sanctioned by >> >> >> the xorg board officially, nor did I state that anywhere. I just said >> >> >> that discussions already started to happen, that's really all there >> >> >> is. >> >> > >> >> > Thanks for making that clear. >> >> >> >> Yeah I understand the confusion, since it wasn't clear that this mail >> >> was written by me with my drm maintainer hat on, not me in my role as >> >> xorg bod secretary. Nor me as an intel employee. I should have made >> >> that clearer. >> > >> > I was not confused about that, especially since you mentioned the board. >> > But this clearly was not something already approved by the X.org >> > foundation board. >> >> Since there is a lot of "it" and "this" in both your and Daniel's >> messages, without clarifying what you're both actually talking about, I >> think for clarity it should be noted that, AFAIU, the decision to adopt >> the CoC is up to the freedesktop.org admins, not the X.org board, and >> the discussion about enforcing is to take place between the two. > > It's the way in which this is being done that makes me very weary of > this code of conduct. > > It seems like a very unilateral move, quite likely by just a single > person. There is no record of any prior discussion, not with the > affected projects, not on any mailing list, not on the irc channels > where i am on (and i doubt it is logged publicly anywhere). This commit > Daniel Vetter just posted comes the closest to any discussion, wayland > never was so lucky. This feels like the typical freedesktop.org move, > and i am quite allergic to those as i and the projects i have been > involved in have been the target of such unilateral decisions several > times. > > I see the mentioning of the X.org foundation board here as an attempt to > give this surprise Code of Conduct some gravitas which it didn't > deserve, as it was far too easily debunked. The board of directors never > voted on this, and i would like to see the emails of the discussion > prior to this mentioning here. If there were any, they were not before > the surprise wayland commit. > > I would welcome such a code of conduct though, if it had been the result > of an honest, open and transparent community discussion. But that's not > something i have often seen at freedesktop.org. And i have a feeling as > to how it will be applied and who or what projects it will be applied > to, and how transparent that process will be. If people would be > interested in seeing this Code of Conduct retro-actively, i might have a > few cases that i would want to bring up, though. At least for the dri-devel community I have chatted with 20+ of the regular contributors about this (in a specific case, which for obvious reasons I don't want to discuss in the court of public opinion before it's necessary), and only 2 went "meh, I don't care". Everyone else seemed to support rolling out a formal&enforced code of conduct, so at least for the dri-devel community I do believe that this has the full
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On 2017-04-11 02:48 AM, Daniel Vetter wrote: freedesktop.org has adopted a formal&enforced code of conduct: https://www.fooishbar.org/blog/fdo-contributor-covenant/ https://www.freedesktop.org/wiki/CodeOfConduct/ Besides formalizing things a bit more I don't think this changes anything for us, we've already peer-enforced respectful and constructive interactions since a long time. But it's good to document things properly. Note: As Daniel Stone mentioned in the announcement fd.o admins started chatting with the communities their hosting, which includs the X.org foundation board, to figure out how to fan out enforcement and allow projects to run things on their own (with fd.o still as the fallback). So the details of enforcement (and appealing decisions) might still change, but since this involves the board and lots more people it'll take a while to get there. For now this is good enough I think. For the text itself I went with the same blurb as the Wayland project, didn't feel creative yet this early in the morning: https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c Cc: Daniel Stone Cc: Keith Packard Cc: tfh...@err.no Signed-off-by: Daniel Vetter Reviewed-by: Harry Wentland Harry --- Documentation/gpu/introduction.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 05a82bdfbca4..0f5173e29bdc 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one month where feature work can't be merged. The recommended way to deal with that is having a -next tree that's always open, but making sure to not feed it into linux-next during the blackout period. As an example, drm-misc works like that. + +Code of Conduct +--- + +As a freedesktop.org project, dri-devel and the DRM community follows the +Contributor Covenant, found at: https://www.freedesktop.org/wiki/CodeOfConduct + +Please conduct yourself in a respectful and civilised manner when +interacting with community members on mailing lists, IRC, or bug +trackers. The community represents the project as a whole, and abusive +or bullying behaviour is not tolerated by the project. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Bail if we do not setup the RCS engine
On Tue, Apr 11, 2017 at 04:30:22PM +0100, Chris Wilson wrote:
> In places, we assume that RCS exists. This has been true forever, but
> let us catch this failure during bringup by adding an explicit check
> that we do have an RCS engine.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 71e89a93fe18..3595209d86cf 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -154,9 +154,9 @@ int intel_engines_init_early(struct drm_i915_private
> *dev_priv)
> {
> struct intel_device_info *device_info = mkwrite_device_info(dev_priv);
> unsigned int ring_mask = INTEL_INFO(dev_priv)->ring_mask;
If there's buy in for this check, can I make this const ring_mask?
-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 v4 09/11] drm/i915/dp: read sink count to a temporary variable first
Thanks Jani for pushing patches 1-9. Now we just need review on Patch 10 (Validate cached link rate and lane count), may Be Ville can review that. I have submitted new revision based on his comments already. And Patch 11 already has your R-b. Regards Manasi On Thu, 06 Apr 2017, Ville Syrjälä wrote: > On Thu, Apr 06, 2017 at 04:44:17PM +0300, Jani Nikula wrote: >> Don't clobber intel_dp->sink_count with the raw value. >> >> Suggested-by: Ville Syrjälä >> Signed-off-by: Jani Nikula > > Reviewed-by: Ville Syrjälä Thanks for the reviews, pushed patches 1-9 to drm-intel-next-queued. BR, Jani. -- 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: Document code of conduct
On Tue, Apr 11, 2017 at 11:14 AM, Luc Verhaegen wrote: > On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote: >> On Tue, 11 Apr 2017, Luc Verhaegen wrote: >> > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: >> >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen wrote: >> >> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: >> >> >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen wrote: >> >> >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: >> >> >> >> freedesktop.org has adopted a formal&enforced code of conduct: >> >> >> >> >> >> >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> >> >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> >> >> >> >> >> >> Besides formalizing things a bit more I don't think this changes >> >> >> >> anything for us, we've already peer-enforced respectful and >> >> >> >> constructive interactions since a long time. But it's good to >> >> >> >> document >> >> >> >> things properly. >> >> >> >> >> >> >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> >> >> >> started chatting with the communities their hosting, which includs >> >> >> >> the >> >> >> > >> >> >> > "started" and "chatting"? That is very weakly formulated. >> >> >> >> >> >> Intentionally so ... >> >> >> >> >> >> >> X.org foundation board, to figure out how to fan out enforcement and >> >> >> > >> >> >> > This was not voted upon or even mentioned during the last board >> >> >> > meeting. >> >> >> > And i think the next board meeting is only in 2 days time. As such, >> >> >> > this >> >> >> > seems like it is not something that's officially sanctioned by the >> >> >> > X.org >> >> >> > foundation board, but you sure do try to make it sound like such. >> >> >> >> >> >> ... because it is not yet sanctioned by the board in any way. So not >> >> >> exactly sure where you're reading this into my commit message, because >> >> >> it wasn't my intention to make it sounds like this is sanctioned by >> >> >> the xorg board officially, nor did I state that anywhere. I just said >> >> >> that discussions already started to happen, that's really all there >> >> >> is. >> >> > >> >> > Thanks for making that clear. >> >> >> >> Yeah I understand the confusion, since it wasn't clear that this mail >> >> was written by me with my drm maintainer hat on, not me in my role as >> >> xorg bod secretary. Nor me as an intel employee. I should have made >> >> that clearer. >> > >> > I was not confused about that, especially since you mentioned the board. >> > But this clearly was not something already approved by the X.org >> > foundation board. >> >> Since there is a lot of "it" and "this" in both your and Daniel's >> messages, without clarifying what you're both actually talking about, I >> think for clarity it should be noted that, AFAIU, the decision to adopt >> the CoC is up to the freedesktop.org admins, not the X.org board, and >> the discussion about enforcing is to take place between the two. > > It's the way in which this is being done that makes me very weary of > this code of conduct. > > It seems like a very unilateral move, quite likely by just a single > person. There is no record of any prior discussion, not with the > affected projects, not on any mailing list, not on the irc channels > where i am on (and i doubt it is logged publicly anywhere). This commit > Daniel Vetter just posted comes the closest to any discussion, wayland > never was so lucky. This feels like the typical freedesktop.org move, > and i am quite allergic to those as i and the projects i have been > involved in have been the target of such unilateral decisions several > times. Isn't this thread the discussion? Daniel proposed a code of conduct for drm. Let's discuss. AFAIK, the previous discussion was mostly just reaching out to various contributors to see if they were interested in the first place. I agree that the commit message wording is confusing. Alex > > I see the mentioning of the X.org foundation board here as an attempt to > give this surprise Code of Conduct some gravitas which it didn't > deserve, as it was far too easily debunked. The board of directors never > voted on this, and i would like to see the emails of the discussion > prior to this mentioning here. If there were any, they were not before > the surprise wayland commit. > > I would welcome such a code of conduct though, if it had been the result > of an honest, open and transparent community discussion. But that's not > something i have often seen at freedesktop.org. And i have a feeling as > to how it will be applied and who or what projects it will be applied > to, and how transparent that process will be. If people would be > interested in seeing this Code of Conduct retro-actively, i might have a > few cases that i would want to bring up, though. > > Luc Verhaegen. > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.
Re: [Intel-gfx] [PATCH] drm/i915: Bail if we do not setup the RCS engine
On Tue, Apr 11, 2017 at 04:30:22PM +0100, Chris Wilson wrote: > In places, we assume that RCS exists. This has been true forever, but > let us catch this failure during bringup by adding an explicit check > that we do have an RCS engine. Note that some might argue that I'm using the RCS engine as a proxy for a missing dev_priv->gt function table... You know who you are! -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the typos: "they're" and "includes" > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. Might want to clarify this paragraph. This is a bit confusing for those not following the discussions closely. I think there is too much mixing of projects and hosting and foundations and all three should be distinct. This patch proposes a CoC for the drm subsystem of the kernel, not freedesktop, or Xorg or some other project and that should be made clear. Alex > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Bail if we do not setup the RCS engine
== Series Details == Series: drm/i915: Bail if we do not setup the RCS engine URL : https://patchwork.freedesktop.org/series/22860/ State : success == Summary == Series 22860v1 drm/i915: Bail if we do not setup the RCS engine https://patchwork.freedesktop.org/api/1.0/series/22860/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:431s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:427s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:506s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:480s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:407s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:428s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:479s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:454s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:452s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:570s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:457s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:484s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:403s 1a8653e657e1154a337956033af17740ef5f9dda drm-tip: 2017y-04m-11d-14h-18m-13s UTC integration manifest 5c2b73d drm/i915: Bail if we do not setup the RCS engine == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4475/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Bail if we do not setup the RCS engine
On 11/04/2017 16:30, Chris Wilson wrote:
In places, we assume that RCS exists. This has been true forever, but
let us catch this failure during bringup by adding an explicit check
that we do have an RCS engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 71e89a93fe18..3595209d86cf 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -154,9 +154,9 @@ int intel_engines_init_early(struct drm_i915_private
*dev_priv)
{
struct intel_device_info *device_info = mkwrite_device_info(dev_priv);
unsigned int ring_mask = INTEL_INFO(dev_priv)->ring_mask;
- unsigned int mask = 0;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ unsigned int mask = 0;
+/- 0 :)
unsigned int i;
int err;
@@ -183,6 +183,12 @@ int intel_engines_init_early(struct drm_i915_private
*dev_priv)
if (WARN_ON(mask != ring_mask))
device_info->ring_mask = mask;
+ /* We always presume we have at least RCS available for probing */
+ if (WARN_ON(!(mask & ENGINE_MASK(RCS {
No idea why would you want this. You could also just use HAS_ENGINE
since info->ring_mask is up to date by this point. And you can make
ring_mask const if it makes any difference. :)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
+ err = -ENODEV;
+ goto cleanup;
+ }
+
device_info->num_rings = hweight32(mask);
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote: > On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote: >> freedesktop.org has adopted a formal&enforced code of conduct: >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >> https://www.freedesktop.org/wiki/CodeOfConduct/ >> >> Besides formalizing things a bit more I don't think this changes >> anything for us, we've already peer-enforced respectful and >> constructive interactions since a long time. But it's good to document >> things properly. >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins >> started chatting with the communities their hosting, which includs the > > typos: > "they're" and "includes" > >> X.org foundation board, to figure out how to fan out enforcement and >> allow projects to run things on their own (with fd.o still as the >> fallback). So the details of enforcement (and appealing decisions) >> might still change, but since this involves the board and lots more >> people it'll take a while to get there. For now this is good enough I >> think. > > Might want to clarify this paragraph. This is a bit confusing for > those not following the discussions closely. I think there is too > much mixing of projects and hosting and foundations and all three > should be distinct. This patch proposes a CoC for the drm subsystem > of the kernel, not freedesktop, or Xorg or some other project and that > should be made clear. Yeah, looks like I mostly made a mess by trying to add a bit more context. I'd say this note here really should have been below the "---" to just make it part of the mail, not part of the commit message. I think I'll just drop it when applying, I think that'd be much better. Would also fix the typos in it :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Prevent the system suspend complete optimization
Since
commit bac2a909a096c9110525c18cbb8ce73c660d5f71
Author: Rafael J. Wysocki
Date: Wed Jan 21 02:17:42 2015 +0100
PCI / PM: Avoid resuming PCI devices during system suspend
PCI devices will default to allowing the system suspend complete
optimization where devices are not woken up during system suspend if
they were already runtime suspended. This however breaks the i915/HDA
drivers for two reasons:
- The i915 driver has system suspend specific steps that it needs to
run, that bring the device to a different state than its runtime
suspended state.
- The HDA driver's suspend handler requires power that it will request
from the i915 driver's power domain handler. This in turn requires the
i915 driver to runtime resume itself, but this won't be possible if the
suspend complete optimization is in effect: in this case the i915
runtime PM is disabled and trying to get an RPM reference returns
-EACCESS.
Solve this by getting/putting an RPM reference in the i915's
prepare/complete hooks, which in effect disables the suspend complete
optimization.
One possibility for this bug staying hidden for so long is that the
optimization for a device is disabled if it's disabled for any of its
children devices. i915 may have a backlight device as its children which
doesn't support runtime PM and so doesn't allow the optimization either.
So if this backlight device got registered the bug stayed hidden.
Credits to Marta, Tomi and David who enabled pstore logging,
that caught one instance of this issue across a suspend/
resume-to-ram and Ville who rememberd that the optimization was enabled
for some devices at one point.
The first WARN triggered by the problem:
[ 6250.746445] WARNING: CPU: 2 PID: 17384 at
drivers/gpu/drm/i915/intel_runtime_pm.c:2846 intel_runtime_pm_get+0x6b/0xd0
[i915]
[ 6250.746448] pm_runtime_get_sync() failed: -13
[ 6250.746451] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_hdmi
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul
snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel e1000e
snd_hda_codec snd_hwdep snd_hda_core ptp mei_me pps_core snd_pcm lpc_ich mei
prime_
numbers i2c_hid i2c_designware_platform i2c_designware_core [last unloaded:
i915]
[ 6250.746512] CPU: 2 PID: 17384 Comm: kworker/u8:0 Tainted: G U W
4.11.0-rc5-CI-CI_DRM_334+ #1
[ 6250.746515] Hardware name: /NUC5i5RYB, BIOS
RYBDWi35.86A.0362.2017.0118.0940 01/18/2017
[ 6250.746521] Workqueue: events_unbound async_run_entry_fn
[ 6250.746525] Call Trace:
[ 6250.746530] dump_stack+0x67/0x92
[ 6250.746536] __warn+0xc6/0xe0
[ 6250.746542] ? pci_restore_standard_config+0x40/0x40
[ 6250.746546] warn_slowpath_fmt+0x46/0x50
[ 6250.746553] ? __pm_runtime_resume+0x56/0x80
[ 6250.746584] intel_runtime_pm_get+0x6b/0xd0 [i915]
[ 6250.746610] intel_display_power_get+0x1b/0x40 [i915]
[ 6250.746646] i915_audio_component_get_power+0x15/0x20 [i915]
[ 6250.746654] snd_hdac_display_power+0xc8/0x110 [snd_hda_core]
[ 6250.746661] azx_runtime_resume+0x218/0x280 [snd_hda_intel]
[ 6250.746667] pci_pm_runtime_resume+0x76/0xa0
[ 6250.746672] __rpm_callback+0xb4/0x1f0
[ 6250.746677] ? pci_restore_standard_config+0x40/0x40
[ 6250.746682] rpm_callback+0x1f/0x80
[ 6250.746686] ? pci_restore_standard_config+0x40/0x40
[ 6250.746690] rpm_resume+0x4ba/0x740
[ 6250.746698] __pm_runtime_resume+0x49/0x80
[ 6250.746703] pci_pm_suspend+0x57/0x140
[ 6250.746709] dpm_run_callback+0x6f/0x330
[ 6250.746713] ? pci_pm_freeze+0xe0/0xe0
[ 6250.746718] __device_suspend+0xf9/0x370
[ 6250.746724] ? dpm_watchdog_set+0x60/0x60
[ 6250.746730] async_suspend+0x1a/0x90
[ 6250.746735] async_run_entry_fn+0x34/0x160
[ 6250.746741] process_one_work+0x1f2/0x6d0
[ 6250.746749] worker_thread+0x49/0x4a0
[ 6250.746755] kthread+0x107/0x140
[ 6250.746759] ? process_one_work+0x6d0/0x6d0
[ 6250.746763] ? kthread_create_on_node+0x40/0x40
[ 6250.746768] ret_from_fork+0x2e/0x40
[ 6250.746778] ---[ end trace 102a62fd2160f5e6 ]---
Fixes: bac2a909a096 ("PCI / PM: Avoid resuming PCI devices during system
suspend")
References: https://bugs.freedesktop.org/show_bug.cgi?id=100378
Cc: Rafael J. Wysocki
Cc: Marta Lofstedt
Cc: David Weinehall
Cc: Tomi Sarvela
Cc: Ville Syrjälä
Cc: Mika Kuoppala
Cc: Chris Wilson
Cc: Takashi Iwai
Cc: sta...@vger.kernel.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bd85e38..6185e28 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1862,6 +1862,31 @@ void i915_reset(struct drm_i915_private *dev_priv)
goto finish;
}
+static int i915_pm_prepare(struct device *kdev)
+{
+ /*
+* Get a reference to disable the direct complete optimization. This
+* is needed, since we have a suspend sequence specific to
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
Daniel Vetter writes: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c With the other wording nitpicks fixed, Reviewed-by: Eric Anholt I'm pleased to be part of a community that's working on building an inclusive, welcoming, productive environment. signature.asc Description: PGP signature ___ 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: Prevent the system suspend complete optimization
== Series Details == Series: drm/i915: Prevent the system suspend complete optimization URL : https://patchwork.freedesktop.org/series/22863/ State : failure == Summary == Series 22863v1 drm/i915: Prevent the system suspend complete optimization https://patchwork.freedesktop.org/api/1.0/series/22863/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (fi-bsw-n3050) fdo#100651 Test kms_sink_crc_basic: skip -> INCOMPLETE (fi-bsw-n3050) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100651 https://bugs.freedesktop.org/show_bug.cgi?id=100651 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:432s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:423s fi-bsw-n3050 total:239 pass:205 dwarn:1 dfail:0 fail:0 skip:32 fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:506s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:478s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:418s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:403s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:422s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:485s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:448s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:569s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:570s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:455s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:493s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:400s 1a8653e657e1154a337956033af17740ef5f9dda drm-tip: 2017y-04m-11d-14h-18m-13s UTC integration manifest 1b7c5b4 drm/i915: Prevent the system suspend complete optimization == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4476/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent the system suspend complete optimization
On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote:
> +static int i915_pm_prepare(struct device *kdev)
> +{
> + /*
> + * Get a reference to disable the direct complete optimization. This
> + * is needed, since we have a suspend sequence specific to system
> + * suspend (that is different from runtime suspend) and because we
> + * need to provide power to the sound driver while its system suspend
> + * handler is running. This is not possible with the optimization in
> + * effect, when the i915 runtime PM is disabled for the whole duration
> + * of the suspend sequence if the device was already runtime
> + * suspended at the beginning of the sequence. In this case the i915
> + * suspend/resume hooks would be also skipped (besides its prepare and
> + * complete hooks).
> + */
> + intel_runtime_pm_get(kdev_to_i915(kdev));
> +
> + return 0;
> +}
> +
> +static void i915_pm_complete(struct device *kdev)
> +{
> + /* Put the ref taken in the prepare step. */
> + intel_runtime_pm_put(kdev_to_i915(kdev));
Do we always call i915_pm_complete() if any of the post-prepare suspend
steps fail? Otherwise, it looks very sensible from our pov.
-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] [CI] drm/i915: Bail if we do not setup the RCS engine
In places, we assume that RCS exists. This has been true forever, but
let us catch this failure during bringup by adding an explicit check
that we do have an RCS engine.
v2: Make use of HAS_ENGINE (Tvrtko)
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 71e89a93fe18..15970f1b09d2 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -153,10 +153,10 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
int intel_engines_init_early(struct drm_i915_private *dev_priv)
{
struct intel_device_info *device_info = mkwrite_device_info(dev_priv);
- unsigned int ring_mask = INTEL_INFO(dev_priv)->ring_mask;
- unsigned int mask = 0;
+ const unsigned int ring_mask = INTEL_INFO(dev_priv)->ring_mask;
struct intel_engine_cs *engine;
enum intel_engine_id id;
+ unsigned int mask = 0;
unsigned int i;
int err;
@@ -183,6 +183,12 @@ int intel_engines_init_early(struct drm_i915_private
*dev_priv)
if (WARN_ON(mask != ring_mask))
device_info->ring_mask = mask;
+ /* We always presume we have at least RCS available for later probing */
+ if (WARN_ON(!HAS_ENGINE(dev_priv, RCS))) {
+ err = -ENODEV;
+ goto cleanup;
+ }
+
device_info->num_rings = hweight32(mask);
return 0;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Prevent the system suspend complete optimization
On Tue, Apr 11, 2017 at 05:54:07PM +0100, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 07:12:35PM +0300, Imre Deak wrote:
> > +static int i915_pm_prepare(struct device *kdev)
> > +{
> > + /*
> > +* Get a reference to disable the direct complete optimization. This
> > +* is needed, since we have a suspend sequence specific to system
> > +* suspend (that is different from runtime suspend) and because we
> > +* need to provide power to the sound driver while its system suspend
> > +* handler is running. This is not possible with the optimization in
> > +* effect, when the i915 runtime PM is disabled for the whole duration
> > +* of the suspend sequence if the device was already runtime
> > +* suspended at the beginning of the sequence. In this case the i915
> > +* suspend/resume hooks would be also skipped (besides its prepare and
> > +* complete hooks).
> > +*/
> > + intel_runtime_pm_get(kdev_to_i915(kdev));
> > +
> > + return 0;
> > +}
> > +
> > +static void i915_pm_complete(struct device *kdev)
> > +{
> > + /* Put the ref taken in the prepare step. */
> > + intel_runtime_pm_put(kdev_to_i915(kdev));
>
> Do we always call i915_pm_complete() if any of the post-prepare suspend
> steps fail? Otherwise, it looks very sensible from our pov.
Yes, it's called even in the failure case (for S3 for example
suspend_devices_and_enter()->Recover_platform:->Resume_devices:->
dpm_resume_end()->dpm_complete()).
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Use the engine class to get the context size
From: Daniele Ceraolo Spurio
Technically speaking, the context size is per engine class, not per
instance.
v2: Add MISSING_CASE (Tvrtko)
v3: Rebased
v4: Restore the interface back to hiding the class lookup (Chris)
Cc: Paulo Zanoni
Cc: Rodrigo Vivi
Cc: Chris Wilson
Signed-off-by: Daniele Ceraolo Spurio
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0dc1cc4..3921566 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1923,23 +1923,31 @@ static void execlists_init_reg_state(u32 *regs,
*/
uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
{
+ struct drm_i915_private *dev_priv = engine->i915;
int ret = 0;
- WARN_ON(INTEL_GEN(engine->i915) < 8);
+ WARN_ON(INTEL_GEN(dev_priv) < 8);
- switch (engine->id) {
- case RCS:
- if (INTEL_GEN(engine->i915) >= 9)
+ switch (engine->class) {
+ case RENDER_CLASS:
+ switch (INTEL_GEN(dev_priv)) {
+ default:
+ MISSING_CASE(INTEL_GEN(dev_priv));
+ case 9:
ret = GEN9_LR_CONTEXT_RENDER_SIZE;
- else
+ break;
+ case 8:
ret = GEN8_LR_CONTEXT_RENDER_SIZE;
+ break;
+ }
break;
- case VCS:
- case BCS:
- case VECS:
- case VCS2:
+ case VIDEO_DECODE_CLASS:
+ case VIDEO_ENHANCEMENT_CLASS:
+ case COPY_ENGINE_CLASS:
ret = GEN8_LR_CONTEXT_OTHER_SIZE;
break;
+ default:
+ MISSING_CASE(engine->class);
}
return ret;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Bail if we do not setup the RCS engine (rev2)
== Series Details == Series: drm/i915: Bail if we do not setup the RCS engine (rev2) URL : https://patchwork.freedesktop.org/series/22860/ State : success == Summary == Series 22860v2 drm/i915: Bail if we do not setup the RCS engine https://patchwork.freedesktop.org/api/1.0/series/22860/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:430s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:425s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:574s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:488s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:484s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:401s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:494s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:445s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:559s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:447s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:570s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:462s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:487s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:428s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:530s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:408s 1a8653e657e1154a337956033af17740ef5f9dda drm-tip: 2017y-04m-11d-14h-18m-13s UTC integration manifest 44b5988 drm/i915: Bail if we do not setup the RCS engine == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4477/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 12:09 PM, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote: >> On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter >> wrote: >>> freedesktop.org has adopted a formal&enforced code of conduct: >>> >>> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >>> https://www.freedesktop.org/wiki/CodeOfConduct/ >>> >>> Besides formalizing things a bit more I don't think this changes >>> anything for us, we've already peer-enforced respectful and >>> constructive interactions since a long time. But it's good to document >>> things properly. >>> >>> Note: As Daniel Stone mentioned in the announcement fd.o admins >>> started chatting with the communities their hosting, which includs the >> >> typos: >> "they're" and "includes" >> >>> X.org foundation board, to figure out how to fan out enforcement and >>> allow projects to run things on their own (with fd.o still as the >>> fallback). So the details of enforcement (and appealing decisions) >>> might still change, but since this involves the board and lots more >>> people it'll take a while to get there. For now this is good enough I >>> think. >> >> Might want to clarify this paragraph. This is a bit confusing for >> those not following the discussions closely. I think there is too >> much mixing of projects and hosting and foundations and all three >> should be distinct. This patch proposes a CoC for the drm subsystem >> of the kernel, not freedesktop, or Xorg or some other project and that >> should be made clear. > > Yeah, looks like I mostly made a mess by trying to add a bit more > context. I'd say this note here really should have been below the > "---" to just make it part of the mail, not part of the commit > message. I think I'll just drop it when applying, I think that'd be > much better. Would also fix the typos in it :-) With that fixed up: Acked-by: Alex Deucher > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
2017-04-11 Daniel Vetter : > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. > > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) That is a great step forward! Acked-by: Gustavo Padovan Gustavo ___ 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: Prevent the system suspend complete optimization
On Tue, Apr 11, 2017 at 04:32:59PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Prevent the system suspend complete optimization > URL : https://patchwork.freedesktop.org/series/22863/ > State : failure > > == Summary == > > Series 22863v1 drm/i915: Prevent the system suspend complete optimization > https://patchwork.freedesktop.org/api/1.0/series/22863/revisions/1/mbox/ > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > pass -> FAIL (fi-snb-2600) fdo#17 Unrelated, matches the fdo bug. > Test gem_exec_suspend: > Subgroup basic-s4-devices: > dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Unrelated, USB network device flip-flop as in the fdo bug. > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > pass -> DMESG-WARN (fi-bsw-n3050) fdo#100651 > Test kms_sink_crc_basic: > skip -> INCOMPLETE (fi-bsw-n3050) Looks unrelated, but this is more like https://bugs.freedesktop.org/show_bug.cgi?id=100417 as opposed the cited fdo bug. > > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 > fdo#100651 https://bugs.freedesktop.org/show_bug.cgi?id=100651 > > fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 > time:432s > fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 > time:423s > fi-bsw-n3050 total:239 pass:205 dwarn:1 dfail:0 fail:0 skip:32 > fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 > time:506s > fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 > time:485s > fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > time:478s > fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > time:418s > fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 > time:403s > fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 > time:422s > fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > time:485s > fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > time:469s > fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 > time:448s > fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > time:569s > fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > time:458s > fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 > time:570s > fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 > time:455s > fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 > time:493s > fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 > time:435s > fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 > time:534s > fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 > time:400s > > 1a8653e657e1154a337956033af17740ef5f9dda drm-tip: 2017y-04m-11d-14h-18m-13s > UTC integration manifest > 1b7c5b4 drm/i915: Prevent the system suspend complete optimization > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4476/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler()
We indirectly hold the runtime-pm for the intel_lrc_irq_handler() by virtue of dev_priv->gt.awake keeping a wakeref whilst the requests are busy. As this is not obvious from the code, add a comment. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 0dc1cc4ad6e7..e16cc28dc783 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -515,6 +515,15 @@ static void intel_lrc_irq_handler(unsigned long data) struct execlist_port *port = engine->execlist_port; struct drm_i915_private *dev_priv = engine->i915; + /* We can skip acquiring intel_runtime_pm_get() here as it was taken +* on our behalf by the request (see i915_gem_mark_busy ()) and it will +* not be relinquished until the device is idle (see +* i915_gem_idle_work_handler()). As a precaution, we make sure +* that all ELSP are drained i.e. we have processed the CSB, +* before allowing ourselves to idle and calling intel_runtime_pm_put(). +*/ + GEM_BUG_ON(!dev_priv->gt.awake); + intel_uncore_forcewake_get(dev_priv, engine->fw_domains); /* Prefer doing test_and_clear_bit() as a two stage operation to avoid -- 2.11.0 ___ 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 drm/i915: Bail if we do not setup the RCS engine (rev2)
On Tue, Apr 11, 2017 at 05:15:51PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Bail if we do not setup the RCS engine (rev2) > URL : https://patchwork.freedesktop.org/series/22860/ > State : success > > == Summary == > > Series 22860v2 drm/i915: Bail if we do not setup the RCS engine > https://patchwork.freedesktop.org/api/1.0/series/22860/revisions/2/mbox/ > > Test gem_exec_suspend: > Subgroup basic-s4-devices: > dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 > > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 Pushed this little patch to allow me to be lazy when checking for device support for certain features like user scheduling. Thanks for the review, -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 v4] drm/i915: Use the engine class to get the context size
On Tue, Apr 11, 2017 at 03:11:12AM -0700, Oscar Mateo wrote:
> From: Daniele Ceraolo Spurio
>
> Technically speaking, the context size is per engine class, not per
> instance.
>
> v2: Add MISSING_CASE (Tvrtko)
>
> v3: Rebased
>
> v4: Restore the interface back to hiding the class lookup (Chris)
>
> Cc: Paulo Zanoni
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Signed-off-by: Daniele Ceraolo Spurio
> Reviewed-by: Tvrtko Ursulin
> Signed-off-by: Oscar Mateo
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0dc1cc4..3921566 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1923,23 +1923,31 @@ static void execlists_init_reg_state(u32 *regs,
> */
> uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
> {
> + struct drm_i915_private *dev_priv = engine->i915;
> int ret = 0;
>
> - WARN_ON(INTEL_GEN(engine->i915) < 8);
> + WARN_ON(INTEL_GEN(dev_priv) < 8);
>
> - switch (engine->id) {
> - case RCS:
> - if (INTEL_GEN(engine->i915) >= 9)
> + switch (engine->class) {
> + case RENDER_CLASS:
> + switch (INTEL_GEN(dev_priv)) {
> + default:
> + MISSING_CASE(INTEL_GEN(dev_priv));
> + case 9:
> ret = GEN9_LR_CONTEXT_RENDER_SIZE;
> - else
> + break;
> + case 8:
> ret = GEN8_LR_CONTEXT_RENDER_SIZE;
> + break;
> + }
> break;
> - case VCS:
> - case BCS:
> - case VECS:
> - case VCS2:
> + case VIDEO_DECODE_CLASS:
> + case VIDEO_ENHANCEMENT_CLASS:
> + case COPY_ENGINE_CLASS:
> ret = GEN8_LR_CONTEXT_OTHER_SIZE;
> break;
> + default:
> + MISSING_CASE(engine->class);
Sorry, couldn't resist moving this MISSING_CASE so that both switches
were consistent in style.
Thanks for the patch, pushed. Better update the igt names 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] [PATCH] drm/i915: Lie and treat all engines as idle if wedged
Similar to commit 8490ae207f1d ("drm/i915: Suppress busy status for
engines if wedged") we also want to report intel_engine_is_idle() as
true as well as the main intel_engines_are_idle(), as we now check that
the engines are idle when overwriting the HWS page. This is not true
whilst we are setting the device as wedged, at least according to our
bookkeeping, so we have to lie to ourselves!
[ 383.588601] [drm:i915_reset [i915]] *ERROR* Failed to reset chip: -110
[ 383.588685] [ cut here ]
[ 383.588755] WARNING: CPU: 0 PID: 12 at
drivers/gpu/drm/i915/intel_engine_cs.c:226
intel_engine_init_global_seqno+0x222/0x290 [i915]
[ 383.588757] WARN_ON(!intel_engine_is_idle(engine))
[ 383.588759] Modules linked in: ctr ccm snd_hda_codec_hdmi
snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_codec
snd_hda_core arc4 iwldvm mac80211 snd_pcm snd_hwdep snd_seq_midi
snd_seq_midi_event rfcomm bnep snd_rawmidi intel_powerclamp coretemp
dm_multipath iwlwifi crct10dif_pclmul snd_seq crc32_pclmul ghash_clmulni_intel
btusb aesni_intel btrtl btbcm aes_x86_64 crypto_simd cryptd btintel snd_timer
glue_helper bluetooth intel_ips snd_seq_device cfg80211 snd soundcore
binfmt_misc mei_me mei dm_mirror dm_region_hash dm_log i915 intel_gtt
i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect
sysimgblt fb_sys_fops cfbcopyarea prime_numbers ahci libahci drm e1000e
[ 383.588851] CPU: 0 PID: 12 Comm: migration/0 Not tainted 4.11.0-rc5+ #207
[ 383.588853] Hardware name: LENOVO 514328U/514328U, BIOS 6QET44WW (1.14 )
04/20/2010
[ 383.588855] Call Trace:
[ 383.588866] dump_stack+0x63/0x90
[ 383.588871] __warn+0xc7/0xf0
[ 383.588876] warn_slowpath_fmt+0x4a/0x50
[ 383.53] ? set_next_entity+0x821/0x910
[ 383.588943] intel_engine_init_global_seqno+0x222/0x290 [i915]
[ 383.588998] __i915_gem_set_wedged_BKL+0xa4/0x190 [i915]
[ 383.589003] ? __switch_to+0x215/0x390
[ 383.589008] multi_cpu_stop+0xbb/0xe0
[ 383.589012] ? cpu_stop_queue_work+0x90/0x90
[ 383.589016] cpu_stopper_thread+0x82/0x110
[ 383.589021] smpboot_thread_fn+0x137/0x190
[ 383.589026] kthread+0xf7/0x130
[ 383.589030] ? sort_range+0x20/0x20
[ 383.589034] ? kthread_park+0x90/0x90
[ 383.589040] ret_from_fork+0x2c/0x40
Fixes: 2ca9faa551c4 ("drm/i915: Assert the engine is idle before overwiting the
HWS")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_engine_cs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 15970f1b09d2..ee87ca7420de 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1131,6 +1131,10 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+ /* More white lies, if wedged, hw state is inconsistent */
+ if (i915_terminally_wedged(&dev_priv->gpu_error))
+ return true;
+
/* Any inflight/incomplete requests? */
if (!i915_seqno_passed(intel_engine_get_seqno(engine),
intel_engine_last_submit(engine)))
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler() (rev2)
== Series Details == Series: drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler() (rev2) URL : https://patchwork.freedesktop.org/series/22790/ State : success == Summary == Series 22790v2 drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler() https://patchwork.freedesktop.org/api/1.0/series/22790/revisions/2/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:431s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:426s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:575s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:478s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:401s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:425s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:487s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:463s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:452s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:566s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:453s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:569s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:473s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:431s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:533s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:404s fi-byt-j1900 failed to collect. IGT log at Patchwork_4479/fi-byt-j1900/igt.log c77055e7cbbc6f925498f386c498bd0f2d7c6bdb drm-tip: 2017y-04m-11d-18h-46m-29s UTC integration manifest 9c6c070 drm/i915/execlists: Document runtime pm for intel_lrc_irq_handler() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4479/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Lie and treat all engines as idle if wedged (rev2)
== Series Details == Series: drm/i915: Lie and treat all engines as idle if wedged (rev2) URL : https://patchwork.freedesktop.org/series/22793/ State : success == Summary == Series 22793v2 drm/i915: Lie and treat all engines as idle if wedged https://patchwork.freedesktop.org/api/1.0/series/22793/revisions/2/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:430s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:430s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:575s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:478s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:406s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:492s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:453s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:457s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time:572s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:459s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:486s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:401s c77055e7cbbc6f925498f386c498bd0f2d7c6bdb drm-tip: 2017y-04m-11d-18h-46m-29s UTC integration manifest 2f720db drm/i915: Lie and treat all engines as idle if wedged == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4480/ ___ 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 drm/i915: Lie and treat all engines as idle if wedged (rev2)
On Tue, Apr 11, 2017 at 07:40:58PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Lie and treat all engines as idle if wedged (rev2) > URL : https://patchwork.freedesktop.org/series/22793/ > State : success > > == Summary == > > Series 22793v2 drm/i915: Lie and treat all engines as idle if wedged > https://patchwork.freedesktop.org/api/1.0/series/22793/revisions/2/mbox/ Another invisible bug (hopefully) bites the dust. Thanks for the review, -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
