Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
This is now a conflict between the drm tree and Linus' tree.
On Fri, 22 Mar 2019 10:57:28 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/mmio_context.c
>
> between commit:
>
> 1e8b15a1988e ("drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list")
>
> from the drm-intel-fixes tree and commit:
>
> 8a68d464366e ("drm/i915: Store the BIT(engine->id) as the engine's mask")
>
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/gpu/drm/i915/gvt/mmio_context.c
> index 7902fb162d09,a00a807a1d55..
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@@ -73,71 -73,70 +73,71 @@@ static struct engine_mmio gen8_engine_m
> };
>
> static struct engine_mmio gen9_engine_mmio_list[] __cacheline_aligned = {
> - {RCS, GFX_MODE_GEN7, 0x, false}, /* 0x229c */
> - {RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - {RCS, HWSTAM, 0x0, false}, /* 0x2098 */
> - {RCS, INSTPM, 0x, true}, /* 0x20c0 */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 0), 0, false}, /* 0x24d0
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 1), 0, false}, /* 0x24d4
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 2), 0, false}, /* 0x24d8
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 3), 0, false}, /* 0x24dc
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 4), 0, false}, /* 0x24e0
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 5), 0, false}, /* 0x24e4
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 6), 0, false}, /* 0x24e8
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 7), 0, false}, /* 0x24ec
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 8), 0, false}, /* 0x24f0
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 9), 0, false}, /* 0x24f4
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 10), 0, false}, /* 0x24f8
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 11), 0, false}, /* 0x24fc
> */
> - {RCS, CACHE_MODE_1, 0x, true}, /* 0x7004 */
> - {RCS, GEN7_GT_MODE, 0x, true}, /* 0x7008 */
> - {RCS, CACHE_MODE_0_GEN7, 0x, true}, /* 0x7000 */
> - {RCS, GEN7_COMMON_SLICE_CHICKEN1, 0x, true}, /* 0x7010 */
> - {RCS, HDC_CHICKEN0, 0x, true}, /* 0x7300 */
> - {RCS, VF_GUARDBAND, 0x, true}, /* 0x83a4 */
> -
> - {RCS, GEN8_PRIVATE_PAT_LO, 0, false}, /* 0x40e0 */
> - {RCS, GEN8_PRIVATE_PAT_HI, 0, false}, /* 0x40e4 */
> - {RCS, GEN8_CS_CHICKEN1, 0x, true}, /* 0x2580 */
> - {RCS, COMMON_SLICE_CHICKEN2, 0x, true}, /* 0x7014 */
> - {RCS, GEN9_CS_DEBUG_MODE1, 0x, false}, /* 0x20ec */
> - {RCS, GEN8_L3SQCREG4, 0, false}, /* 0xb118 */
> - {RCS, GEN7_HALF_SLICE_CHICKEN1, 0x, true}, /* 0xe100 */
> - {RCS, HALF_SLICE_CHICKEN2, 0x, true}, /* 0xe180 */
> - {RCS, HALF_SLICE_CHICKEN3, 0x, true}, /* 0xe184 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN5, 0x, true}, /* 0xe188 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN7, 0x, true}, /* 0xe194 */
> - {RCS, GEN8_ROW_CHICKEN, 0x, true}, /* 0xe4f0 */
> - {RCS, TRVATTL3PTRDW(0), 0, false}, /* 0x4de0 */
> - {RCS, TRVATTL3PTRDW(1), 0, false}, /* 0x4de4 */
> - {RCS, TRNULLDETCT, 0, false}, /* 0x4de8 */
> - {RCS, TRINVTILEDETCT, 0, false}, /* 0x4dec */
> - {RCS, TRVADR, 0, false}, /* 0x4df0 */
> - {RCS, TRTTE, 0, false}, /* 0x4df4 */
> -
> - {BCS, RING_GFX_MODE(BLT_RING_BASE), 0x, false}, /* 0x2229c */
> - {BCS, RING_MI_MODE(BLT_RING_BASE), 0x, false}, /* 0x2209c */
> - {BCS, RING_INSTPM(BLT_RING_BASE), 0x, false}, /* 0x220c0 */
> - {BCS, RING_HWSTAM(BLT_RING_BASE), 0x0, false}, /* 0x22098 */
> - {BCS, RING_EXCC(BLT_RING_BASE), 0x0, false}, /* 0x22028 */
> -
> - {VCS2, RING_EXCC(GEN8_BSD2_RING_BASE), 0x, false}, /* 0x1c028 */
> -
> - {VECS, RING_EXCC(VEBOX_RING_BASE), 0x, false}, /* 0x1a028 */
> -
> - {RCS, GEN8_HDC_CHICKEN1, 0x, true}, /* 0x7304 */
> - {RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - {RCS, GEN7_UCGCTL4, 0x0, false}, /* 0x940c */
> - {RCS, GAMT_CHKN_BIT_REG, 0x0, false}, /* 0x4ab8 */
> -
> - {RCS, GEN9_GAMT_ECO_REG_RW_IA, 0x0, false}, /* 0x4ab0 */
> - {RCS, GEN9_CSFE_CHICKEN1_RCS, 0x, false}, /* 0x20d4 */
> - {RCS, _MMIO(0x20D8), 0x, true}, /* 0x20d8 */
> -
> - {RCS, GEN8_GARBCNTL, 0x0, false}, /* 0xb004 */
> - {RCS, GEN7_FF_THREAD_MODE, 0x0, false}, /* 0x20a0 */
> -
Re: [Intel-gfx] [PATCH 00/16] drm/fb-helper: Move modesetting code to drm_client
Den 28.03.2019 10.31, skrev Daniel Vetter: > On Tue, Mar 26, 2019 at 06:55:30PM +0100, Noralf Trønnes wrote: >> This moves the modesetting code from drm_fb_helper to drm_client so it >> can be shared by all internal clients. >> >> I have also added a client display abstraction and a bootsplash example >> client to show where this might be heading. Hopefully Max Staudt will be >> able to pick up his bootsplash work now. > > First a fairly unrelated thing that I noticed while reading stuff: > > In drm_fbdev_generic_setup() we register the drm_client to the world (with > drm_client_add) before it's fully set up. And the checks in the setup code > aren't safe against a concurrent hotplug call from another thread. Which > can happen, because usually by that point, and definitely by the time the > driver called drm_dev_register() the hotplug handler is running. > Ah, this hasn't crossed my mind. I'll move drm_client_add() after setup. > Maybe good idea to rename drm_client_add to drm_client_register (to stay > consistent with our naming scheme of _register() = others can start > calling us from any thread). > Makes sense, I'll change the name. > We need to do the basic setup code _before_ we call drm_client_register. > The kerneldoc for the various fbdev setup functions have explanations for > when exactly it's ok to handle hotplug events. > > The other bit is kinda the high-level review on the drm_client modeset > api: > - Allowing multiple different modeset clients per drm_client feels like > overkill. I think we can just require a 1:1 mapping between drm_client > and modeset config. If a client wants to have multiple different modeset > configs per drm_device they can create more drm_clients. > The reason I ended up doing this is that there can be more than one display connected. So for me the natural choice was to have each display represented individually with its own modeset(s). I did consider having the modeset array attached to drm_client and use a modesets mask to tell the displays apart. It would have been easier if we didn't have those tiled monitors driven by multiple outputs, because that would have given us one modeset per display. drm_fb_helper uses the same framebuffer for all displays, sizing it to match the smallest. Ofc the easy way out is to only support one display per drm_device. I don't see how multiple drm_clients per drm_device should work. Should the client keep an array of drm_client for as many displays as it supports? The bootsplash client example I made, puts a splash on all displays it can find. But maybe it should do it on only one display? If so we need some heuristics to determine which is the primary display. Not sure how kmscon is supposed to work, but I believe it is meant to be a developer console. So I guess it will also just use the primary display. > - That also fixes your "do we need embedding" question, since drm_client > supports that already. > > - That means we could clean up the api considerably by embedding all the > modeset stuff into drm_client, and e.g. allocating the modeset arrays at > drm_client_init() time. > > - Except that wouldn't work with the current fbdev emulation code, because > that one isn't always using drm_client. > > Hence my question/suggestion: Could we rework the fbdev emulation to > always allocate a drm_client, but only use drm_client for buffer > allocation for generic_setup(). That could also provide us with a smoother > upgrade path for other drivers to generic_setup, e.g. we could ditch all > the hotplug handling already. > > I'm thinking of embedding a drm_client into drm_fb_helper, and calling > drm_client_init() on it at the right time. But only call drm_client_add() > for generic_setup(). At least as a first step. > Yeah, this certainly makes sense if we have the modesets attached to drm_client_dev. > Related question: What's the plan for drivers which don't support > generic_setup()? If we eventually have stuff like kmscon running on top of > drm_client, we'd have to somehow port them all ... > It should just work as long the driver supports ->dumb_create and ->gem_prime_vmap. rockchip and mediatek (I think) don't provide a virtual address on its buffers because of limited virtual address space. We could add a ->dumb_create_internal hook so these drivers could provide an address to internal clients. This way they could use the generic fbdev emualtion as well. Unless Rob finds a way to vmap a dma buffer after allocation. He has looked at converting rockchip to generic fbdev. > And finally the bikeshed: I thik drm_client_modeset would be a good prefix > for all this (maybe even in a separate file): I have used prefix drm_client_modesets_ for all functions that operates on the modeset array. Emmanuel Vadot alerted me to the fact that dm_fb_helper is MIT licensed. I was now planning to change drm_client to MIT as well, so I can legally move over code. If we add drm_client_modeset.c with a
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Idle before measuring idle
Before trying to measure the busyness reporting for the idle state, make sure the gpu is actually idle and not still running any backgound system task. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- tests/perf_pmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c index 1a08f564b..ef61c4d40 100644 --- a/tests/perf_pmu.c +++ b/tests/perf_pmu.c @@ -264,6 +264,7 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags) uint64_t val; int fd; + gem_quiescent_gpu(gem_fd); fd = open_pmu(I915_PMU_ENGINE_BUSY(e->class, e->instance)); if (flags & TEST_BUSY) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit Deep color correctly
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit
Deep color correctly
URL : https://patchwork.freedesktop.org/series/58784/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5845_full -> Patchwork_12644_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12644_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- shard-skl: NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_12644_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_blits@normal:
- shard-iclb: PASS -> TIMEOUT [fdo#109673]
* igt@gem_userptr_blits@process-exit-gtt:
- shard-glk: NOTRUN -> SKIP [fdo#109271] +60
* igt@i915_pm_rpm@system-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107807]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#110222]
* igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7
* igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-glk: NOTRUN -> DMESG-WARN [fdo#110222] +1
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-f:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-glk: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-iclb: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-512x170-offscreen:
- shard-iclb: NOTRUN -> SKIP [fdo#109279]
* igt@kms_flip@2x-flip-vs-wf_vblank-interruptible:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +32
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +4
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
- shard-iclb: PASS -> FAIL [fdo#103167] +9
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-pwrite:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] +22
* igt@kms_plane@plane-position-hole-pipe-b-planes:
- shard-iclb: PASS -> DMESG-WARN [fdo#106107]
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-glk: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815]
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]
* igt@kms_vblank@pipe-c-query-idle-hang:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4
* igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-apl: PASS -> FAIL [fdo#104894]
* igt@perf@sysctl-defaults:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@perf_pmu@render-node-busy-vcs1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276]
* igt@prime_busy@wait-after-bsd:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +38
Possible fixes
* igt@gem_tiled_fence_blits@normal:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS +1
* igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-skl: DMESG-WARN [fdo#110222] -> PASS
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-iclb: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-iclb: FAIL [fdo#103355] -> PASS
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: FAIL [fdo#105363] -> PASS
* igt@kms_flip@flip-vs-suspend:
- shard-skl: INCOMPLETE [fdo#109507] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt:
- shard-iclb: FAIL [fdo#103167] -> PASS +14
* {igt@kms_plane@pixel-format-pipe-c-planes}:
- shard-glk: SKIP [fdo#109271] -> PASS
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: FAIL [fdo#108145] -> PASS
* igt@kms_plane_scaling@pipe-c-scaler-with-clipping-clamping:
- shard-iclb: INCOMPLETE [fdo#110041] -> PASS
* igt@kms_psr@no_drrs:
- shard-iclb: FAIL [fdo#108341] -> PASS
* igt@kms_psr@psr2_primary_mmap_gtt:
- shard-iclb: SKIP [fdo#109441] -> PASS +2
*
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Check domains for userptr on release
== Series Details ==
Series: drm/i915: Check domains for userptr on release
URL : https://patchwork.freedesktop.org/series/58783/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5845_full -> Patchwork_12643_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12643_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane@pixel-format-pipe-b-planes-source-clamping}:
- shard-skl: NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_12643_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] +1
* igt@gem_tiled_swapping@non-threaded:
- shard-iclb: PASS -> DMESG-WARN [fdo#108686]
* igt@gem_userptr_blits@process-exit-gtt:
- shard-glk: NOTRUN -> SKIP [fdo#109271] +60
* igt@i915_pm_rpm@sysfs-read:
- shard-skl: PASS -> INCOMPLETE [fdo#107807]
* igt@kms_atomic_transition@plane-all-modeset-transition-fencing:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#110222]
* igt@kms_busy@extended-modeset-hang-oldfb-render-d:
- shard-glk: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +7
* igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-glk: NOTRUN -> DMESG-WARN [fdo#110222] +1
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-f:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-glk: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-512x170-offscreen:
- shard-iclb: NOTRUN -> SKIP [fdo#109279]
* igt@kms_flip@2x-flip-vs-wf_vblank-interruptible:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +15
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-iclb: PASS -> FAIL [fdo#103167] +6
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +6
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-spr-indfb-draw-pwrite:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] +22
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-glk: NOTRUN -> FAIL [fdo#108145]
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: NOTRUN -> SKIP [fdo#109441]
* igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: PASS -> SKIP [fdo#109441]
* igt@kms_vblank@pipe-c-query-idle-hang:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +4
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-apl: PASS -> FAIL [fdo#104894]
* igt@perf_pmu@render-node-busy-vcs1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276]
* igt@prime_busy@wait-after-bsd:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +38
Possible fixes
* igt@gem_mmap_gtt@hang:
- shard-iclb: FAIL [fdo#109677] -> PASS
* igt@gem_tiled_fence_blits@normal:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS +1
* igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-snb: SKIP [fdo#109271] -> PASS
* igt@i915_selftest@live_workarounds:
- shard-iclb: DMESG-FAIL [fdo#108954] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-iclb: DMESG-WARN [fdo#110222] -> PASS
* igt@kms_flip@flip-vs-suspend:
- shard-skl: INCOMPLETE [fdo#109507] -> PASS
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite:
- shard-iclb: FAIL [fdo#103167] -> PASS +11
* {igt@kms_plane@pixel-format-pipe-c-planes}:
- shard-glk: SKIP [fdo#109271] -> PASS
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: FAIL [fdo#107815] -> PASS
* igt@kms_plane_scaling@pipe-c-scaler-with-clipping-clamping:
- shard-iclb: INCOMPLETE [fdo#110041] -> PASS
* igt@kms_psr@no_drrs:
- shard-iclb: FAIL [fdo#108341] -> PASS
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: SKIP [fdo#109441] -> PASS +4
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-iclb: FAIL [fdo#104894] -> PASS
Warnings
* igt@i915_pm_rpm@i2c:
- shard-iclb: DMESG-WARN [fdo#109982] -> FAIL [fdo#104097]
{name}: This element is suppressed. This means it
Re: [Intel-gfx] [PATCH] drm/i915: Check domains for userptr on release
On Sun, 31 Mar 2019 at 10:47, Chris Wilson wrote:
>
> When we return pages to the system, we release control over them and
> should defensively return them to the CPU write domain so that we catch
> any external writes on reacquiring them (e.g. to transparently
> swapout/swapin). While we did this defensive clflushing for ordinary
> shmem pages, it was forgotten for userptr. Fortunately, userptr objects
> are normally cache coherent and so oblivious to the forgotten domain
> tracking.
>
> References: a679f58d0510 ("drm/i915: Flush pages on acquisition")
> References: 754a25442705 ("drm/i915: Skip object locking around a no-op
> set-domain ioctl")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Tvrtko Ursulin
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit Deep color correctly
== Series Details == Series: series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit Deep color correctly URL : https://patchwork.freedesktop.org/series/58784/ State : success == Summary == CI Bug Log - changes from CI_DRM_5845 -> Patchwork_12644 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/58784/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12644 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: PASS -> DMESG-FAIL [fdo#110235 ] * igt@i915_selftest@live_execlists: - fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720] * igt@kms_psr@primary_page_flip: - fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50 * igt@runner@aborted: - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] Warnings * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: DMESG-FAIL [fdo#105079] -> DMESG-WARN [fdo#103558] / [fdo#105079] / [fdo#105602] [fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#105079]: https://bugs.freedesktop.org/show_bug.cgi?id=105079 [fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (47 -> 32) -- Additional (1): fi-apl-guc Missing(16): fi-kbl-soraka fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-n2820 fi-byt-squawks fi-bsw-cyan fi-snb-2520m fi-kbl-x1275 fi-icl-u3 fi-skl-lmem fi-bdw-samus fi-icl-guc fi-byt-clapper fi-skl-6700k2 fi-kbl-r Build changes - * Linux: CI_DRM_5845 -> Patchwork_12644 CI_DRM_5845: 19b80f537228354a34ff532c9a765e19ebc7cafe @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4914: b93309b7823dcbbd2c52adb4ebb98e3cb060f910 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12644: ee3932b8f93f6f51fa9e7b50d509af6e8cc74140 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ee3932b8f93f drm/i915: Add N & CTS values for 10/12 bit deep color 8f7ec76513b3 drm/i915/icl: Fix for setting HDMI 10/12 bit Deep color correctly == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12644/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
On 2019-03-31 03:02:21, Chris Wilson wrote:
> Quoting Jordan Justen (2019-03-31 10:57:09)
> > On 2019-03-25 03:58:59, Chris Wilson wrote:
> > > iris currently uses two distinct GEM contexts to have distinct logical
> > > HW contexts for the compute and render pipelines. However, using two
> > > distinct GEM contexts implies that they are distinct timelines, yet as
> > > they are a single GL context that implies they belong to a single
> > > timeline from the client perspective. Currently, fences are occasionally
> > > inserted to order the two timelines. Using 2 GEM contexts, also implies
> > > that we keep 2 ppGTT for identical buffer state. If we can create a
> > > single GEM context, with the right capabilities, we can have a single
> > > VM, a single timeline, but 2 logical HW contexts for the 2 pipelines.
> > >
> > > This is allowed through the new context interface that allows VM to be
> > > shared, timelines to be specified, and for the logical contexts to be
> > > constructed as the user desires.
> > >
> > > Cc: Joonas Lahtinen
> > > Cc: Kenneth Graunke
> > > ---
> > > src/gallium/drivers/iris/iris_batch.c | 16 ++-
> > > src/gallium/drivers/iris/iris_batch.h | 5 +--
> > > src/gallium/drivers/iris/iris_context.c | 56 -
> > > 3 files changed, 60 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/src/gallium/drivers/iris/iris_batch.c
> > > b/src/gallium/drivers/iris/iris_batch.c
> > > index 556422c38bc..40bcd939795 100644
> > > --- a/src/gallium/drivers/iris/iris_batch.c
> > > +++ b/src/gallium/drivers/iris/iris_batch.c
> > > @@ -164,24 +164,16 @@ iris_init_batch(struct iris_batch *batch,
> > > struct iris_vtable *vtbl,
> > > struct pipe_debug_callback *dbg,
> > > struct iris_batch *all_batches,
> > > -enum iris_batch_name name,
> > > -uint8_t engine,
> > > -int priority)
> > > +uint32_t hw_id,
> > > +enum iris_batch_name name)
> > > {
> > > batch->screen = screen;
> > > batch->vtbl = vtbl;
> > > batch->dbg = dbg;
> > > batch->name = name;
> > >
> > > - /* engine should be one of I915_EXEC_RENDER, I915_EXEC_BLT, etc. */
> > > - assert((engine & ~I915_EXEC_RING_MASK) == 0);
> > > - assert(util_bitcount(engine) == 1);
> > > - batch->engine = engine;
> > > -
> > > - batch->hw_ctx_id = iris_create_hw_context(screen->bufmgr);
> > > - assert(batch->hw_ctx_id);
> > > -
> > > - iris_hw_context_set_priority(screen->bufmgr, batch->hw_ctx_id,
> > > priority);
> > > + batch->hw_ctx_id = hw_id;
> > > + batch->engine = name;
> >
> > I think this should fall-back to I915_EXEC_RENDER if the old style
> > contexts are created.
>
> It uses the legacy uABI to map both name=COMPUTE to the render ring
> and name=RENDER to the render ring.
Oh, what legacy uABI sets that? I thought if engines weren't set then
I915_EXEC_RENDER would be needed for the two contexts to execute on
the rcs. But, after this patch, isn't name 0 and 1?
I guess I915_EXEC_DEFAULT is 0 and I915_EXEC_RENDER is 1. So, will
I915_EXEC_DEFAULT execute on rcs too? If so, I'm not sure I agree with
taking advantage of this coincidence without even a comment.
-Jordan
> Should we have more or either, or
> start using the many video engines, ctx->engines[] will be the only way
> to define the execbuf mapping. So name == engine, as used today, can
> remain invariant across the legacy I915_EXEC_RING API and future
> ctx->engines[] for the remaining forseeable future of GEM_EXECBUFFER2.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit Deep color correctly
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit
Deep color correctly
URL : https://patchwork.freedesktop.org/series/58784/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8f7ec76513b3 drm/i915/icl: Fix for setting HDMI 10/12 bit Deep color correctly
-:35: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'crtc_state->pipe_bpp > 24'
#35: FILE: drivers/gpu/drm/i915/intel_hdmi.c:967:
+ if (hdmi_sink_is_deep_color(conn_state) &&
+ (crtc_state->pipe_bpp > 24))
-:74: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#74: FILE: drivers/gpu/drm/i915/intel_hdmi.c:2327:
+ DRM_DEBUG_KMS("picking bpc to %d for HDMI output\n",
+pipe_config->pipe_bpp / 3);
total: 0 errors, 0 warnings, 2 checks, 50 lines checked
ee3932b8f93f drm/i915: Add N & CTS values for 10/12 bit deep color
___
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: Check domains for userptr on release
== Series Details ==
Series: drm/i915: Check domains for userptr on release
URL : https://patchwork.freedesktop.org/series/58783/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5845 -> Patchwork_12643
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/58783/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12643:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_gttfill@basic:
- {fi-icl-guc}: NOTRUN -> SKIP
Known issues
Here are the changes found in Patchwork_12643 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106
* igt@i915_selftest@live_execlists:
- fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720]
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: NOTRUN -> FAIL [fdo#103182] +1
* igt@kms_busy@basic-flip-c:
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_psr@primary_page_flip:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50
* igt@runner@aborted:
- fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720]
Possible fixes
* igt@gem_basic@create-fd-close:
- {fi-icl-guc}: INCOMPLETE -> PASS
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108743]: https://bugs.freedesktop.org/show_bug.cgi?id=108743
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720
Participating hosts (47 -> 42)
--
Additional (2): fi-gdg-551 fi-apl-guc
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy
fi-byt-squawks fi-bsw-cyan fi-bdw-samus
Build changes
-
* Linux: CI_DRM_5845 -> Patchwork_12643
CI_DRM_5845: 19b80f537228354a34ff532c9a765e19ebc7cafe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4914: b93309b7823dcbbd2c52adb4ebb98e3cb060f910 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12643: d4c23a28662bf269bf813e729af655089ffd1948 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d4c23a28662b drm/i915: Check domains for userptr on release
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12643/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
Quoting Jordan Justen (2019-03-31 10:57:09)
> On 2019-03-25 03:58:59, Chris Wilson wrote:
> > iris currently uses two distinct GEM contexts to have distinct logical
> > HW contexts for the compute and render pipelines. However, using two
> > distinct GEM contexts implies that they are distinct timelines, yet as
> > they are a single GL context that implies they belong to a single
> > timeline from the client perspective. Currently, fences are occasionally
> > inserted to order the two timelines. Using 2 GEM contexts, also implies
> > that we keep 2 ppGTT for identical buffer state. If we can create a
> > single GEM context, with the right capabilities, we can have a single
> > VM, a single timeline, but 2 logical HW contexts for the 2 pipelines.
> >
> > This is allowed through the new context interface that allows VM to be
> > shared, timelines to be specified, and for the logical contexts to be
> > constructed as the user desires.
> >
> > Cc: Joonas Lahtinen
> > Cc: Kenneth Graunke
> > ---
> > src/gallium/drivers/iris/iris_batch.c | 16 ++-
> > src/gallium/drivers/iris/iris_batch.h | 5 +--
> > src/gallium/drivers/iris/iris_context.c | 56 -
> > 3 files changed, 60 insertions(+), 17 deletions(-)
> >
> > diff --git a/src/gallium/drivers/iris/iris_batch.c
> > b/src/gallium/drivers/iris/iris_batch.c
> > index 556422c38bc..40bcd939795 100644
> > --- a/src/gallium/drivers/iris/iris_batch.c
> > +++ b/src/gallium/drivers/iris/iris_batch.c
> > @@ -164,24 +164,16 @@ iris_init_batch(struct iris_batch *batch,
> > struct iris_vtable *vtbl,
> > struct pipe_debug_callback *dbg,
> > struct iris_batch *all_batches,
> > -enum iris_batch_name name,
> > -uint8_t engine,
> > -int priority)
> > +uint32_t hw_id,
> > +enum iris_batch_name name)
> > {
> > batch->screen = screen;
> > batch->vtbl = vtbl;
> > batch->dbg = dbg;
> > batch->name = name;
> >
> > - /* engine should be one of I915_EXEC_RENDER, I915_EXEC_BLT, etc. */
> > - assert((engine & ~I915_EXEC_RING_MASK) == 0);
> > - assert(util_bitcount(engine) == 1);
> > - batch->engine = engine;
> > -
> > - batch->hw_ctx_id = iris_create_hw_context(screen->bufmgr);
> > - assert(batch->hw_ctx_id);
> > -
> > - iris_hw_context_set_priority(screen->bufmgr, batch->hw_ctx_id,
> > priority);
> > + batch->hw_ctx_id = hw_id;
> > + batch->engine = name;
>
> I think this should fall-back to I915_EXEC_RENDER if the old style
> contexts are created.
It uses the legacy uABI to map both name=COMPUTE to the render ring
and name=RENDER to the render ring. Should we have more or either, or
start using the many video engines, ctx->engines[] will be the only way
to define the execbuf mapping. So name == engine, as used today, can
remain invariant across the legacy I915_EXEC_RING API and future
ctx->engines[] for the remaining forseeable future of GEM_EXECBUFFER2.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] iris: Create a composite context for both compute and render pipelines
On 2019-03-25 03:58:59, Chris Wilson wrote:
> iris currently uses two distinct GEM contexts to have distinct logical
> HW contexts for the compute and render pipelines. However, using two
> distinct GEM contexts implies that they are distinct timelines, yet as
> they are a single GL context that implies they belong to a single
> timeline from the client perspective. Currently, fences are occasionally
> inserted to order the two timelines. Using 2 GEM contexts, also implies
> that we keep 2 ppGTT for identical buffer state. If we can create a
> single GEM context, with the right capabilities, we can have a single
> VM, a single timeline, but 2 logical HW contexts for the 2 pipelines.
>
> This is allowed through the new context interface that allows VM to be
> shared, timelines to be specified, and for the logical contexts to be
> constructed as the user desires.
>
> Cc: Joonas Lahtinen
> Cc: Kenneth Graunke
> ---
> src/gallium/drivers/iris/iris_batch.c | 16 ++-
> src/gallium/drivers/iris/iris_batch.h | 5 +--
> src/gallium/drivers/iris/iris_context.c | 56 -
> 3 files changed, 60 insertions(+), 17 deletions(-)
>
> diff --git a/src/gallium/drivers/iris/iris_batch.c
> b/src/gallium/drivers/iris/iris_batch.c
> index 556422c38bc..40bcd939795 100644
> --- a/src/gallium/drivers/iris/iris_batch.c
> +++ b/src/gallium/drivers/iris/iris_batch.c
> @@ -164,24 +164,16 @@ iris_init_batch(struct iris_batch *batch,
> struct iris_vtable *vtbl,
> struct pipe_debug_callback *dbg,
> struct iris_batch *all_batches,
> -enum iris_batch_name name,
> -uint8_t engine,
> -int priority)
> +uint32_t hw_id,
> +enum iris_batch_name name)
> {
> batch->screen = screen;
> batch->vtbl = vtbl;
> batch->dbg = dbg;
> batch->name = name;
>
> - /* engine should be one of I915_EXEC_RENDER, I915_EXEC_BLT, etc. */
> - assert((engine & ~I915_EXEC_RING_MASK) == 0);
> - assert(util_bitcount(engine) == 1);
> - batch->engine = engine;
> -
> - batch->hw_ctx_id = iris_create_hw_context(screen->bufmgr);
> - assert(batch->hw_ctx_id);
> -
> - iris_hw_context_set_priority(screen->bufmgr, batch->hw_ctx_id, priority);
> + batch->hw_ctx_id = hw_id;
> + batch->engine = name;
I think this should fall-back to I915_EXEC_RENDER if the old style
contexts are created.
-Jordan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Check domains for userptr on release
== Series Details ==
Series: drm/i915: Check domains for userptr on release
URL : https://patchwork.freedesktop.org/series/58783/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d4c23a28662b drm/i915: Check domains for userptr on release
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a679f58d0510 ("drm/i915: Flush
pages on acquisition")'
#14:
References: a679f58d0510 ("drm/i915: Flush pages on acquisition")
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
References: 754a25442705 ("drm/i915: Skip object locking around a no-op
set-domain ioctl")
-:15: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 754a25442705 ("drm/i915: Skip
object locking around a no-op set-domain ioctl")'
#15:
References: 754a25442705 ("drm/i915: Skip object locking around a no-op
set-domain ioctl")
total: 2 errors, 1 warnings, 0 checks, 33 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 1/3] drm-uapi: Pull i915_drm.h changes for context cloning
Quoting Jordan Justen (2019-03-31 10:53:06) > Where are these changes from (repo/commit)? It could be good to > reference in the commit message. They don't exist in drm-next yet, so they don't have a reference. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 1/3] drm-uapi: Pull i915_drm.h changes for context cloning
Where are these changes from (repo/commit)? It could be good to
reference in the commit message.
I suspect that the answer might mean that these patches should be
labeled RFC.
-Jordan
On 2019-03-25 03:58:58, Chris Wilson wrote:
> For use in GPU recovery and pipeline construction.
> ---
> include/drm-uapi/i915_drm.h | 389 +---
> 1 file changed, 317 insertions(+), 72 deletions(-)
>
> diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
> index d2792ab3640..59baacd265d 100644
> --- a/include/drm-uapi/i915_drm.h
> +++ b/include/drm-uapi/i915_drm.h
> @@ -62,6 +62,28 @@ extern "C" {
> #define I915_ERROR_UEVENT "ERROR"
> #define I915_RESET_UEVENT "RESET"
>
> +/*
> + * i915_user_extension: Base class for defining a chain of extensions
> + *
> + * Many interfaces need to grow over time. In most cases we can simply
> + * extend the struct and have userspace pass in more data. Another option,
> + * as demonstrated by Vulkan's approach to providing extensions for forward
> + * and backward compatibility, is to use a list of optional structs to
> + * provide those extra details.
> + *
> + * The key advantage to using an extension chain is that it allows us to
> + * redefine the interface more easily than an ever growing struct of
> + * increasing complexity, and for large parts of that interface to be
> + * entirely optional. The downside is more pointer chasing; chasing across
> + * the boundary with pointers encapsulated inside u64.
> + */
> +struct i915_user_extension {
> + __u64 next_extension;
> + __u32 name;
> + __u32 flags; /* All undefined bits must be zero. */
> + __u32 rsvd[4]; /* Reserved for future use; must be zero. */
> +};
> +
> /*
> * MOCS indexes used for GPU surfaces, defining the cacheability of the
> * surface data and the coherency for this data wrt. CPU vs. GPU accesses.
> @@ -99,9 +121,14 @@ enum drm_i915_gem_engine_class {
> I915_ENGINE_CLASS_VIDEO = 2,
> I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
>
> + /* should be kept compact */
> +
> I915_ENGINE_CLASS_INVALID = -1
> };
>
> +#define I915_ENGINE_CLASS_INVALID_NONE -1
> +#define I915_ENGINE_CLASS_INVALID_VIRTUAL 0
> +
> /**
> * DOC: perf_events exposed by i915 through
> /sys/bus/event_sources/drivers/i915
> *
> @@ -319,6 +346,9 @@ typedef struct _drm_i915_sarea {
> #define DRM_I915_PERF_ADD_CONFIG 0x37
> #define DRM_I915_PERF_REMOVE_CONFIG0x38
> #define DRM_I915_QUERY 0x39
> +#define DRM_I915_GEM_VM_CREATE 0x3a
> +#define DRM_I915_GEM_VM_DESTROY0x3b
> +/* Must be kept compact -- no holes */
>
> #define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
> DRM_I915_INIT, drm_i915_init_t)
> #define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
> DRM_I915_FLUSH)
> @@ -367,6 +397,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
> #define DRM_IOCTL_I915_GEM_WAITDRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
> #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
> DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
> +#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE_EXT DRM_IOWR (DRM_COMMAND_BASE +
> DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create_ext)
> #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
> DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
> #define DRM_IOCTL_I915_REG_READDRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
> #define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR (DRM_COMMAND_BASE +
> DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
> @@ -377,6 +408,8 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOW(DRM_COMMAND_BASE +
> DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
> #define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOW(DRM_COMMAND_BASE +
> DRM_I915_PERF_REMOVE_CONFIG, __u64)
> #define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_QUERY, struct drm_i915_query)
> +#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
> +#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
> DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
>
> /* Allow drivers to submit batchbuffers directly to hardware, relying
> * on the security mechanisms provided by hardware.
> @@ -476,6 +509,7 @@ typedef struct drm_i915_irq_wait {
> #define I915_SCHEDULER_CAP_ENABLED (1ul << 0)
> #define I915_SCHEDULER_CAP_PRIORITY (1ul << 1)
> #define I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
> +#define
[Intel-gfx] [PATCH 2/2] drm/i915: Add N & CTS values for 10/12 bit deep color
Adding N & CTS values for 10/12 bit deep color from Appendix C
table in HDMI 2.0 spec. The correct values for N is not chosen
automatically by hardware for deep color modes.
Signed-off-by: Aditya Swarup
Cc: Clint Taylor
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Manasi Navare
---
drivers/gpu/drm/i915/intel_audio.c | 80 +++---
1 file changed, 74 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 502b57ce72ab..285c65da2e4e 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -182,6 +182,59 @@ static const struct {
{ 192000, TMDS_594M, 24576, 594000 },
};
+/* Appendix C - N & CTS values for deep color from HDMI 2.0 spec*/
+/* HDMI N/CTS table for 10 bit deep color(30 bpp)*/
+#define TMDS_371M 371250
+#define TMDS_370M 370878
+
+static const struct {
+ int sample_rate;
+ int clock;
+ int n;
+ int cts;
+} hdmi_aud_ncts_30bpp[] = {
+ { 32000, TMDS_370M, 5824, 527344 },
+ { 32000, TMDS_371M, 6144, 556875 },
+ { 44100, TMDS_370M, 8918, 585938 },
+ { 44100, TMDS_371M, 4704, 309375 },
+ { 88200, TMDS_370M, 17836, 585938 },
+ { 88200, TMDS_371M, 9408, 309375 },
+ { 176400, TMDS_370M, 35672, 585938 },
+ { 176400, TMDS_371M, 18816, 309375 },
+ { 48000, TMDS_370M, 11648, 703125 },
+ { 48000, TMDS_371M, 5120, 309375 },
+ { 96000, TMDS_370M, 23296, 703125 },
+ { 96000, TMDS_371M, 10240, 309375 },
+ { 192000, TMDS_370M, 46592, 703125 },
+ { 192000, TMDS_371M, 20480, 309375 },
+};
+
+/* HDMI N/CTS table for 12 bit deep color(36 bpp)*/
+#define TMDS_445_5M 445500
+#define TMDS_445M 445054
+
+static const struct {
+ int sample_rate;
+ int clock;
+ int n;
+ int cts;
+} hdmi_aud_ncts_36bpp[] = {
+ { 32000, TMDS_445M, 5824, 632813 },
+ { 32000, TMDS_445_5M, 4096, 445500 },
+ { 44100, TMDS_445M, 8918, 703125 },
+ { 44100, TMDS_445_5M, 4704, 371250 },
+ { 88200, TMDS_445M, 17836, 703125 },
+ { 88200, TMDS_445_5M, 9408, 371250 },
+ { 176400, TMDS_445M, 35672, 703125 },
+ { 176400, TMDS_445_5M, 18816, 371250 },
+ { 48000, TMDS_445M, 5824, 421875 },
+ { 48000, TMDS_445_5M, 5120, 371250 },
+ { 96000, TMDS_445M, 11648, 421875 },
+ { 96000, TMDS_445_5M, 10240, 371250 },
+ { 192000, TMDS_445M, 23296, 421875 },
+ { 192000, TMDS_445_5M, 20480, 371250 },
+};
+
/* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
static u32 audio_config_hdmi_pixel_clock(const struct intel_crtc_state
*crtc_state)
{
@@ -210,16 +263,31 @@ static u32 audio_config_hdmi_pixel_clock(const struct
intel_crtc_state *crtc_sta
static int audio_config_hdmi_get_n(const struct intel_crtc_state *crtc_state,
int rate)
{
- const struct drm_display_mode *adjusted_mode =
- _state->base.adjusted_mode;
int i;
- for (i = 0; i < ARRAY_SIZE(hdmi_aud_ncts); i++) {
- if (rate == hdmi_aud_ncts[i].sample_rate &&
- adjusted_mode->crtc_clock == hdmi_aud_ncts[i].clock) {
- return hdmi_aud_ncts[i].n;
+ if (crtc_state->pipe_bpp == 36) {
+ for (i = 0; i < ARRAY_SIZE(hdmi_aud_ncts_36bpp); i++) {
+ if (rate == hdmi_aud_ncts_36bpp[i].sample_rate &&
+ crtc_state->port_clock ==
hdmi_aud_ncts_36bpp[i].clock) {
+ return hdmi_aud_ncts_36bpp[i].n;
+ }
+ }
+ } else if (crtc_state->pipe_bpp == 30) {
+ for (i = 0; i < ARRAY_SIZE(hdmi_aud_ncts_30bpp); i++) {
+ if (rate == hdmi_aud_ncts_30bpp[i].sample_rate &&
+ crtc_state->port_clock ==
hdmi_aud_ncts_30bpp[i].clock) {
+ return hdmi_aud_ncts_30bpp[i].n;
+ }
+ }
+ } else {
+ for (i = 0; i < ARRAY_SIZE(hdmi_aud_ncts); i++) {
+ if (rate == hdmi_aud_ncts[i].sample_rate &&
+ crtc_state->port_clock == hdmi_aud_ncts[i].clock) {
+ return hdmi_aud_ncts[i].n;
+ }
}
}
+
return 0;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/icl: Fix for setting HDMI 10/12 bit Deep color correctly
From: Clinton Taylor
Changing settings from 8 bit to 10/12 bit deep color(& vice versa)
doesn't work correctly using xrandr max bpc property. Fix the
driver for applying correct settings.
Test:
xrandr --output HDMI-2 --mode 3840x2160 --rate 30 --set "max bpc" 10
and then
xrandr --output HDMI-2 --mode 3840x2160 --rate 30 --set "max bpc" 8
Signed-off-by: Clinton Taylor
Signed-off-by: Aditya Swarup
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Manasi Navare
---
Fixes changing modes from 8 bit to 10/12 bit deep color.
drivers/gpu/drm/i915/intel_hdmi.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 5ccb305a6e1c..4760462f84ca 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -963,7 +963,9 @@ static void intel_hdmi_compute_gcp_infoframe(struct
intel_encoder *encoder,
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GENERAL_CONTROL);
/* Indicate color depth whenever the sink supports deep color */
- if (hdmi_sink_is_deep_color(conn_state))
+
+ if (hdmi_sink_is_deep_color(conn_state) &&
+ (crtc_state->pipe_bpp > 24))
crtc_state->infoframes.gcp |= GCP_COLOR_INDICATION;
/* Enable default_phase whenever the display mode is suitably aligned */
@@ -2260,6 +2262,7 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
int clock_10bpc = clock_8bpc * 5 / 4;
int clock_12bpc = clock_8bpc * 3 / 2;
+ int dc_clock = clock_12bpc;
int desired_bpp;
bool force_dvi = intel_conn_state->force_audio == HDMI_AUDIO_OFF_DVI;
@@ -2314,22 +2317,18 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
* Note that g4x/vlv don't support 12bpc hdmi outputs. We also need
* to check that the higher clock still fits within limits.
*/
- if (hdmi_deep_color_possible(pipe_config, 12) &&
- hdmi_port_clock_valid(intel_hdmi, clock_12bpc,
+ if (pipe_config->pipe_bpp == 30)
+ dc_clock = clock_10bpc;
+
+ if (hdmi_deep_color_possible(pipe_config, pipe_config->pipe_bpp / 3) &&
+ hdmi_port_clock_valid(intel_hdmi, dc_clock,
true, force_dvi) == MODE_OK) {
- DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
- desired_bpp = 12*3;
-
- /* Need to adjust the port link by 1.5x for 12bpc. */
- pipe_config->port_clock = clock_12bpc;
- } else if (hdmi_deep_color_possible(pipe_config, 10) &&
- hdmi_port_clock_valid(intel_hdmi, clock_10bpc,
-true, force_dvi) == MODE_OK) {
- DRM_DEBUG_KMS("picking bpc to 10 for HDMI output\n");
- desired_bpp = 10 * 3;
-
- /* Need to adjust the port link by 1.25x for 10bpc. */
- pipe_config->port_clock = clock_10bpc;
+ DRM_DEBUG_KMS("picking bpc to %d for HDMI output\n",
+pipe_config->pipe_bpp / 3);
+ desired_bpp = pipe_config->pipe_bpp;
+
+ /* Need to adjust the port link dc modes. */
+ pipe_config->port_clock = dc_clock;
} else {
DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
desired_bpp = 8*3;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check domains for userptr on release
When we return pages to the system, we release control over them and
should defensively return them to the CPU write domain so that we catch
any external writes on reacquiring them (e.g. to transparently
swapout/swapin). While we did this defensive clflushing for ordinary
shmem pages, it was forgotten for userptr. Fortunately, userptr objects
are normally cache coherent and so oblivious to the forgotten domain
tracking.
References: a679f58d0510 ("drm/i915: Flush pages on acquisition")
References: 754a25442705 ("drm/i915: Skip object locking around a no-op
set-domain ioctl")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 3 +--
drivers/gpu/drm/i915/i915_gem_object.h | 4
drivers/gpu/drm/i915/i915_gem_userptr.c | 4 +---
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e506e43cfade..c3b4ec52e1b7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -308,7 +308,7 @@ static void __start_cpu_write(struct drm_i915_gem_object
*obj)
obj->cache_dirty = true;
}
-static void
+void
__i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
struct sg_table *pages,
bool needs_clflush)
@@ -2202,7 +2202,6 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj,
struct page *page;
__i915_gem_object_release_shmem(obj, pages, true);
-
i915_gem_gtt_finish_pages(obj, pages);
if (i915_gem_object_needs_bit17_swizzle(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h
b/drivers/gpu/drm/i915/i915_gem_object.h
index 1a24dc97e4fd..ca93a40c0c87 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -502,4 +502,8 @@ void i915_gem_object_set_cache_coherency(struct
drm_i915_gem_object *obj,
unsigned int cache_level);
void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj);
+void __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
+struct sg_table *pages,
+bool needs_clflush);
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index ad0087127144..215bf3fef10c 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -673,9 +673,7 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object *obj,
if (!pages)
return;
- if (obj->mm.madv != I915_MADV_WILLNEED)
- obj->mm.dirty = false;
-
+ __i915_gem_object_release_shmem(obj, pages, true);
i915_gem_gtt_finish_pages(obj, pages);
for_each_sgt_page(page, sgt_iter, pages) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using ctx->file_priv during construction
Quoting Michal Wajdeczko (2019-03-31 10:12:52) > On Sat, 30 Mar 2019 11:03:49 +0100, Chris Wilson > wrote: > > > As we only set ctx->file_priv on registering the GEM context after > > construction, it is invalid to try and use it in the middle for setting > > Other option would be to set ctx->file_priv ahead of gem_context_register > and use gem_context_register only for registering (per function name) I thought it might be useful for us to distinguish between unregistered protocontexts and unregistered kernel contexts with registered GEM contexts. > Extra bonus would be that changed here static ctx functions will continue > to take ctx as first parameter (same as other existing ctx functions) The only real use for ctx->file is for identifying the right lut in i915_gem_close_object() (the other is for charging a hang against a file, which is going to be more complicated in future, so expect changes). Ideas for avoiding the search along the linked list in close are most welcome. https://patchwork.freedesktop.org/patch/291947/?series=57942=2 -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using ctx->file_priv during construction
On 2019-03-31 00:32:52, Chris Wilson wrote: > Quoting Jordan Justen (2019-03-31 04:03:44) > > I think the change is focused mainly around setting the vm param, so > > perhaps the subject should mention that. Maybe something like: > > It's not just about that, it's the design in how create_ext is run > before registration which caters for more than just vm. The problem > already exists for the other extensions posted, I caught the bug in > create_ext_clone and overlooked that I had been exclusively using normal > ctx_setparam to manipulate the ppgtt. I guess I disagree for two reasons. 1. I think this patch only addresses the symptom with the vm param 2. It doesn't really prevent someone from adding a new param and accidentally doing the same thing. But, feel free to keep the r-b and t-b even if you don't want to change the subject line. -Jordan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using ctx->file_priv during construction
On Sat, 30 Mar 2019 11:03:49 +0100, Chris Wilson wrote: As we only set ctx->file_priv on registering the GEM context after construction, it is invalid to try and use it in the middle for setting Other option would be to set ctx->file_priv ahead of gem_context_register and use gem_context_register only for registering (per function name) Extra bonus would be that changed here static ctx functions will continue to take ctx as first parameter (same as other existing ctx functions) Michal various parameters. Indeed, we put the file_priv into struct create_ext so that we have the right file_private available without having to look at ctx->file_priv. However, it helps to use it! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid using ctx->file_priv during construction
Quoting Jordan Justen (2019-03-31 04:03:44) > I think the change is focused mainly around setting the vm param, so > perhaps the subject should mention that. Maybe something like: It's not just about that, it's the design in how create_ext is run before registration which caters for more than just vm. The problem already exists for the other extensions posted, I caught the bug in create_ext_clone and overlooked that I had been exclusively using normal ctx_setparam to manipulate the ppgtt. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
