Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Fix CRC mismatch error for DP link layer compliance
The patch looks ok to me.
On Wed, 2019-03-06 at 18:14 -0800, Aditya Swarup wrote:
> Setting the pixel rounding bit to 1 in PIPE_CHICKEN register allows
> to passthrough FB pixels unmodified across pipe. This fixes the
> failures
> for DP link layer compliance tests 4.4.1.1, 4.4.1.2 & 4.4.1.3.
> (Lineage #1605353570)
>
> v2: This is also needed to fix failing IGT test case kms_cursor_crc
> on
> ICL.(Mika Kahola)
> Make macros consistent with i915_reg.h comments.(Jani Nikula)
>
> Cc: Clint Taylor
> Cc: Mika Kahola
> Cc: Jani Nikula
Reviewed-by: Mika Kahola
> Signed-off-by: Aditya Swarup
> ---
> drivers/gpu/drm/i915/i915_reg.h | 13 +++--
> drivers/gpu/drm/i915/intel_display.c | 8 +++-
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index c9b868347481..cf15a9a97d74 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7659,12 +7659,13 @@ enum {
> #define GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
>
> /*GEN11 chicken */
> -#define _PIPEA_CHICKEN 0x70038
> -#define _PIPEB_CHICKEN 0x71038
> -#define _PIPEC_CHICKEN 0x72038
> -#define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
> -#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe,
> _PIPEA_CHICKEN,\
> -_PIPEB_CHICKEN)
> +#define _PIPEA_CHICKEN 0x70038
> +#define _PIPEB_CHICKEN 0x71038
> +#define _PIPEC_CHICKEN 0x72038
> +#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe,
> _PIPEA_CHICKEN,\
> +_PIPEB_CHICK
> EN)
> +#define PIXEL_ROUNDING_TRUNC_FB_PASSTHRU (1 << 15)
> +#define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
>
> /* PCH */
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d852cb282060..92be3476fef1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3970,7 +3970,13 @@ static void icl_set_pipe_chicken(struct
> intel_crtc *crtc)
>* and rounding for per-pixel values 00 and 0xff
>*/
> tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
> -
> + /*
> + * Display WA # 1605353570: icl
> + * Set the pixel rounding bit to 1 for allowing
> + * passthrough of Frame buffer pixels unmodified
> + * across pipe
> + */
> + tmp |= PIXEL_ROUNDING_TRUNC_FB_PASSTHRU;
> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/5] drm/i915: Add engine reset count in get-reset-stats ioctl
On 06/03/2019 23:08, Carlos Santa wrote:
On Mon, 2019-02-25 at 13:34 +, Tvrtko Ursulin wrote:
On 21/02/2019 02:58, Carlos Santa wrote:
From: Michel Thierry
Users/tests relying on the total reset count will start seeing a
smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be
unaware
and unaffected.
To start the discussion, include just a total engine reset count.
If it
is deemed useful, it can be extended to report each engine
separately.
Our igt's gem_reset_stats test will need changes to ignore the pad
field,
since it can now return reset_engine_count.
v2: s/engine_reset/reset_engine/, use union in uapi to not break
compatibility.
v3: Keep rejecting attempts to use pad as input (Antonio)
v4: Rebased.
v5: Rebased.
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
Cc: Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
include/uapi/drm/i915_drm.h | 6 +-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 459f8eae1c39..cbfe8f2eb3f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1889,6 +1889,8 @@ int i915_gem_context_reset_stats_ioctl(struct
drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_i915_reset_stats *args = data;
struct i915_gem_context *ctx;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
int ret;
if (args->flags || args->pad)
@@ -1907,10 +1909,16 @@ int
i915_gem_context_reset_stats_ioctl(struct drm_device *dev,
* we should wrap the hangstats with a seqlock.
*/
- if (capable(CAP_SYS_ADMIN))
+ if (capable(CAP_SYS_ADMIN)) {
args->reset_count = i915_reset_count(_priv-
gpu_error);
- else
+ for_each_engine(engine, dev_priv, id)
+ args->reset_engine_count +=
+ i915_reset_engine_count(_priv-
gpu_error,
+ engine);
If access to global GPU reset count is privileged, why is access to
global engine reset count not? It seems to be fundamentally same
level
of data leakage.
But access to global engine reset count (i915_reset_engine_count) is
indeed priviledged. They both are inside if(CAP_SYS_ADMIN){...}, or
maybe I am missing something?
Looks like I misread the diff, sorry. Been processing a lot of patches
lately.
Regards,
Tvrtko
If we wanted to provide some numbers to unprivileged users I think
we
would need to store some counters per file_priv/context and return
those
when !CAP_SYS_ADMIN.
The question would be why access to global GPU reset count is
priviledged then? I can't think of a reason why it should be
priviledged. I think the new counter (per engine) should fall in the
same category as the global GPU reset one, right? So, can we make them
both unpriviledged?
+ } else {
args->reset_count = 0;
+ args->reset_engine_count = 0;
+ }
args->batch_active = atomic_read(>guilty_count);
args->batch_pending = atomic_read(>active_count);
diff --git a/include/uapi/drm/i915_drm.h
b/include/uapi/drm/i915_drm.h
index cc03ef9f885f..3f2c89740b0e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1642,7 +1642,11 @@ struct drm_i915_reset_stats {
/* Number of batches lost pending for execution, for this
context */
__u32 batch_pending;
- __u32 pad;
+ union {
+ __u32 pad;
+ /* Engine resets since boot/module reload, for all
contexts */
+ __u32 reset_engine_count;
+ };
Chris pointed out in some other review that anonymous unions are not
friendly towards C++ compilers.
Not sure what is the best option here. Renaming the field could
break
old userspace building against newer headers. Is that acceptable?
I dug up some old comments from Chris and he stated that recycling the
union like that would be a bad idea since that would make the pad field
an output only parameter thus invalidating gem_reset_stats...
Why can't we simply add a new field __u32 reset_engine_count; as part
of the drm_i915_reset_stats struct?
Regards,
Carlos
};
struct drm_i915_gem_userptr {
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] gvt-fixes for 5.1-rc1
Hi, Here's gvt-fixes for 5.1-rc1. This contains fixes for newer version of Windows driver, e.g fix parser for MI_FLUSH_DW and font render error. And with other stable fix in error path, fix unexpected workload submission when vGPU idle, etc. Details are below. Thanks -- The following changes since commit 0f75551216091223efe1f18295f655aff6415385: drm/i915/gvt: release shadow batch buffer and wa_ctx before destroy one workload (2019-01-23 13:58:46 +0800) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-fixes-2019-03-07 for you to fetch changes up to 72aabfb862e40ee83c136c4f87877c207e6859b7: drm/i915/gvt: Add mutual lock for ppgtt mm LRU list (2019-03-04 14:45:28 +0800) gvt-fixes-2019-03-07 - Fix MI_FLUSH_DW cmd parser on index check (Zhenyu) - Fix Windows guest font render error (Colin) - Fix unexpected workload submission for inactive vGPU (Weinan) - Fix incorrect workload submission in error path (Zhenyu) - Fix warning for shadow ppgtt mm reclaim list walk with locking (Zhenyu) Colin Xu (1): drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list Weinan Li (1): drm/i915/gvt: stop scheduling workload when vgpu is inactive Zhenyu Wang (4): drm/i915/gvt: Fix MI_FLUSH_DW parsing with correct index check drm/i915/gvt: Don't submit request for error workload dispatch drm/i915/gvt: Only assign ppgtt root at dispatch time drm/i915/gvt: Add mutual lock for ppgtt mm LRU list drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 14 +- drivers/gpu/drm/i915/gvt/gtt.h | 1 + drivers/gpu/drm/i915/gvt/mmio_context.c | 1 + drivers/gpu/drm/i915/gvt/scheduler.c| 28 5 files changed, 36 insertions(+), 10 deletions(-) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 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.IGT: success for drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2)
== Series Details == Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2) URL : https://patchwork.freedesktop.org/series/57619/ State : success == Summary == CI Bug Log - changes from CI_DRM_5713_full -> Patchwork_12400_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12400_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-none: - shard-hsw: NOTRUN -> SKIP [fdo#109271] +24 * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: - shard-skl: NOTRUN -> INCOMPLETE [fdo#107807] * igt@kms_busy@extended-modeset-hang-newfb-render-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-f: - shard-hsw: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_busy@extended-pageflip-hang-newfb-render-e: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-b-64x64-bottom-edge: - shard-skl: PASS -> FAIL [fdo#104671] * igt@kms_cursor_crc@cursor-256x256-onscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-256x256-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-64x21-random: - shard-skl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-64x64-dpms: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-alpha-opaque: - shard-skl: PASS -> FAIL [fdo#109350] * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: PASS -> FAIL [fdo#105767] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip_tiling@flip-to-yf-tiled: - shard-skl: NOTRUN -> FAIL [fdo#107931] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-fullscreen: - shard-skl: NOTRUN -> SKIP [fdo#109271] +60 * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-snb: NOTRUN -> SKIP [fdo#109271] +34 * igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: - shard-skl: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: - shard-apl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: PASS -> FAIL [fdo#107815] * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-none: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_setmode@basic: - shard-glk: PASS -> FAIL [fdo#99912] - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_vblank@pipe-c-wait-busy: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@prime_nv_pcopy@test3_5: - shard-apl: NOTRUN -> SKIP [fdo#109271] +41 Possible fixes * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a: - shard-kbl: DMESG-WARN [fdo#107956] -> PASS * igt@kms_color@pipe-b-degamma: - shard-skl: FAIL [fdo#104782] -> PASS * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: FAIL [fdo#103232] -> PASS +2 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: - shard-apl: FAIL [fdo#103167] -> PASS +2 * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-apl: FAIL [fdo#103166] -> PASS +5 * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: FAIL [fdo#107815] -> PASS * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: FAIL [fdo#109016] -> PASS * igt@kms_setmode@basic: - shard-apl: FAIL [fdo#99912] -> PASS * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-apl: FAIL [fdo#104894] -> PASS
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2)
== Series Details == Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2) URL : https://patchwork.freedesktop.org/series/57619/ State : success == Summary == CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12400 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57619/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12400 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-sdma: - fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +17 * igt@gem_ctx_create@basic-files: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106 * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +20 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718] * igt@prime_vgem@basic-fence-flip: - fi-gdg-551: NOTRUN -> FAIL [fdo#103182] Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_module_load@reload-with-fault-injection: - fi-kbl-7560u: INCOMPLETE -> PASS * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: SKIP [fdo#109271] -> PASS * igt@i915_pm_rpm@basic-rte: - fi-bsw-kefka: FAIL [fdo#108800] -> PASS * igt@i915_selftest@live_execlists: - fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#109720] -> PASS * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: WARN [fdo#109380] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - fi-kbl-7567u: SKIP [fdo#109271] -> PASS +33 * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: FAIL [fdo#104008] -> PASS [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#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008 [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380 [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 Participating hosts (44 -> 38) -- Additional (1): fi-gdg-551 Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-kbl-r Build changes - * Linux: CI_DRM_5713 -> Patchwork_12400 CI_DRM_5713: 29a41cf5dd10ee68873c16b67d6212b3bd470906 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4875: 91908d36d0d5c90eea86e29736d2748d5ec55335 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12400: ca509862fd1a7b8aa20890c38cb2ca76d9e0fbd8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ca509862fd1a drm/i915/icl: Fix CRC mismatch error for DP link layer compliance == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12400/ ___ 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/icl: Fix CRC mismatch error for DP link layer compliance (rev2)
== Series Details == Series: drm/i915/icl: Fix CRC mismatch error for DP link layer compliance (rev2) URL : https://patchwork.freedesktop.org/series/57619/ State : warning == Summary == $ dim checkpatch origin/drm-tip ca509862fd1a drm/i915/icl: Fix CRC mismatch error for DP link layer compliance -:40: WARNING:SPACE_BEFORE_TAB: please, no space before tabs #40: FILE: drivers/gpu/drm/i915/i915_reg.h:7667: +#define PIXEL_ROUNDING_TRUNC_FB_PASSTHRU ^I(1 << 15)$ total: 0 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] [PATCH 2/2] drm/i915/cml: Introduce Comet Lake PCH
On Wed, 2019-03-06 at 10:07 -0800, Rodrigo Vivi wrote:
> On Tue, Mar 05, 2019 at 01:46:56PM -0800, Anusha wrote:
> > From: Anusha Srivatsa
> >
> > Comet Lake PCH is based off of Cannon Point(CNP).
> > Add PCI ID for Comet Lake PCH.
> >
> > v2: Code cleanup (DK)
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 4
> > drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 1b2f5a6f8c25..e787c999b2c6 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -188,6 +188,10 @@ intel_pch_type(const struct drm_i915_private
> > *dev_priv, unsigned short id)
> > DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
> > WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > !IS_COFFEELAKE(dev_priv));
> > return PCH_CNP;
> > + case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> > + DRM_DEBUG_KMS("Found Comet Lake LP PCH (CMP)\n");
> > + WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> > !IS_COFFEELAKE(dev_priv));
>
> Please remove CNL from this list...
>
> also please add a comment here before the return
>
> /* CM has same south display engine from CNP */
>
> > + return PCH_CNP;
> > case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> > DRM_DEBUG_KMS("Found Ice Lake PCH\n");
> > WARN_ON(!IS_ICELAKE(dev_priv));
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 453af7438e67..55298e19e740 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -530,7 +530,7 @@ enum intel_pch {
> > PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
> > PCH_SPT,/* Sunrisepoint PCH */
> > PCH_KBP,/* Kaby Lake PCH */
> > - PCH_CNP,/* Cannon Lake PCH */
> > + PCH_CNP,/* Cannon/Comet Lake PCH */
> > PCH_ICP,/* Ice Lake PCH */
> > PCH_NOP,/* PCH without south display */
> > };
> > @@ -2552,6 +2552,7 @@ static inline unsigned int
> > i915_sg_segment_size(void)
> > #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
> > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > +#define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
The debug message calls the device "LP" but the device id macro
doesn't. This is not the case with CNP as both are consistent. So, the
question is this an LP PCH?
> > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> > #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
> > --
> > 2.21.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/icl: Fix CRC mismatch error for DP link layer compliance
Setting the pixel rounding bit to 1 in PIPE_CHICKEN register allows
to passthrough FB pixels unmodified across pipe. This fixes the failures
for DP link layer compliance tests 4.4.1.1, 4.4.1.2 & 4.4.1.3.
(Lineage #1605353570)
v2: This is also needed to fix failing IGT test case kms_cursor_crc on
ICL.(Mika Kahola)
Make macros consistent with i915_reg.h comments.(Jani Nikula)
Cc: Clint Taylor
Cc: Mika Kahola
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 13 +++--
drivers/gpu/drm/i915/intel_display.c | 8 +++-
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9b868347481..cf15a9a97d74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7659,12 +7659,13 @@ enum {
#define GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE (1 << 2)
/*GEN11 chicken */
-#define _PIPEA_CHICKEN 0x70038
-#define _PIPEB_CHICKEN 0x71038
-#define _PIPEC_CHICKEN 0x72038
-#define PER_PIXEL_ALPHA_BYPASS_EN (1 << 7)
-#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe, _PIPEA_CHICKEN,\
- _PIPEB_CHICKEN)
+#define _PIPEA_CHICKEN 0x70038
+#define _PIPEB_CHICKEN 0x71038
+#define _PIPEC_CHICKEN 0x72038
+#define PIPE_CHICKEN(pipe) _MMIO_PIPE(pipe,
_PIPEA_CHICKEN,\
+ _PIPEB_CHICKEN)
+#define PIXEL_ROUNDING_TRUNC_FB_PASSTHRU (1 << 15)
+#define PER_PIXEL_ALPHA_BYPASS_EN(1 << 7)
/* PCH */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d852cb282060..92be3476fef1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3970,7 +3970,13 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
* and rounding for per-pixel values 00 and 0xff
*/
tmp |= PER_PIXEL_ALPHA_BYPASS_EN;
-
+ /*
+* Display WA # 1605353570: icl
+* Set the pixel rounding bit to 1 for allowing
+* passthrough of Frame buffer pixels unmodified
+* across pipe
+*/
+ tmp |= PIXEL_ROUNDING_TRUNC_FB_PASSTHRU;
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
}
--
2.17.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 Polish DRAM information readout code (rev6)
== Series Details == Series: Polish DRAM information readout code (rev6) URL : https://patchwork.freedesktop.org/series/57213/ State : success == Summary == CI Bug Log - changes from CI_DRM_5713_full -> Patchwork_12398_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12398_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-none: - shard-hsw: NOTRUN -> SKIP [fdo#109271] +24 * igt@gem_ctx_isolation@vecs0-s3: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@i915_pm_rpm@basic-pci-d3-state: - shard-skl: PASS -> INCOMPLETE [fdo#107807] * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107807] * igt@i915_selftest@live_hangcheck: - shard-snb: PASS -> INCOMPLETE [fdo#105411] * igt@kms_busy@extended-modeset-hang-newfb-render-e: - shard-apl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-f: - shard-hsw: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_busy@extended-pageflip-hang-newfb-render-e: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145] * igt@kms_chamelium@dp-hpd-fast: - shard-skl: NOTRUN -> SKIP [fdo#109271] +64 * igt@kms_color@pipe-a-degamma: - shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_cursor_crc@cursor-128x42-sliding: - shard-apl: NOTRUN -> FAIL [fdo#103232] +2 * igt@kms_cursor_crc@cursor-256x256-onscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip_tiling@flip-to-yf-tiled: - shard-skl: NOTRUN -> FAIL [fdo#107931] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: - shard-glk: PASS -> FAIL [fdo#103167] +1 * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-skl: NOTRUN -> FAIL [fdo#105683] * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-wc: - shard-snb: NOTRUN -> SKIP [fdo#109271] +34 * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: PASS -> INCOMPLETE [fdo#104108] * igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb: - shard-apl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: NOTRUN -> FAIL [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-none: - shard-skl: NOTRUN -> FAIL [fdo#103166] / [fdo#107815] * igt@kms_plane_multiple@atomic-pipe-c-tiling-x: - shard-glk: PASS -> FAIL [fdo#103166] +1 - shard-apl: NOTRUN -> FAIL [fdo#103166] * igt@kms_rotation_crc@multiplane-rotation: - shard-glk: PASS -> DMESG-FAIL [fdo#105763] / [fdo#106538] - shard-kbl: PASS -> FAIL [fdo#109016] * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-kbl: PASS -> DMESG-FAIL [fdo#105763] * igt@kms_setmode@basic: - shard-glk: PASS -> FAIL [fdo#99912] - shard-kbl: PASS -> FAIL [fdo#99912] * igt@kms_universal_plane@universal-plane-pipe-b-functional: - shard-apl: PASS -> FAIL [fdo#103166] +1 * igt@kms_vblank@pipe-c-wait-busy: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@prime_nv_pcopy@test3_5: - shard-apl: NOTRUN -> SKIP [fdo#109271] +41 Possible fixes * igt@kms_chv_cursor_fail@pipe-a-128x128-right-edge: - shard-skl: FAIL [fdo#104671] -> PASS +1 * igt@kms_color@pipe-b-degamma: - shard-skl: FAIL [fdo#104782] -> PASS * igt@kms_color@pipe-b-legacy-gamma: - shard-apl: FAIL [fdo#104782] -> PASS * igt@kms_color@pipe-c-legacy-gamma: - shard-glk: FAIL [fdo#104782] -> PASS * igt@kms_cursor_crc@cursor-256x256-random: - shard-apl: FAIL [fdo#103232] -> PASS +2 * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: - shard-skl: FAIL [fdo#105682] -> PASS +1 *
Re: [Intel-gfx] [PATCH v4 1/5] drm/i915: Add engine reset count in get-reset-stats ioctl
On Mon, 2019-02-25 at 13:34 +, Tvrtko Ursulin wrote:
> On 21/02/2019 02:58, Carlos Santa wrote:
> > From: Michel Thierry
> >
> > Users/tests relying on the total reset count will start seeing a
> > smaller
> > number since most of the hangs can be handled by engine reset.
> > Note that if reset engine x, context a running on engine y will be
> > unaware
> > and unaffected.
> >
> > To start the discussion, include just a total engine reset count.
> > If it
> > is deemed useful, it can be extended to report each engine
> > separately.
> >
> > Our igt's gem_reset_stats test will need changes to ignore the pad
> > field,
> > since it can now return reset_engine_count.
> >
> > v2: s/engine_reset/reset_engine/, use union in uapi to not break
> > compatibility.
> > v3: Keep rejecting attempts to use pad as input (Antonio)
> > v4: Rebased.
> > v5: Rebased.
> >
> > Cc: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Antonio Argenziano
> > Cc: Cc: Tvrtko Ursulin
> > Signed-off-by: Michel Thierry
> > Signed-off-by: Carlos Santa
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
> > include/uapi/drm/i915_drm.h | 6 +-
> > 2 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 459f8eae1c39..cbfe8f2eb3f2 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -1889,6 +1889,8 @@ int i915_gem_context_reset_stats_ioctl(struct
> > drm_device *dev,
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct drm_i915_reset_stats *args = data;
> > struct i915_gem_context *ctx;
> > + struct intel_engine_cs *engine;
> > + enum intel_engine_id id;
> > int ret;
> >
> > if (args->flags || args->pad)
> > @@ -1907,10 +1909,16 @@ int
> > i915_gem_context_reset_stats_ioctl(struct drm_device *dev,
> > * we should wrap the hangstats with a seqlock.
> > */
> >
> > - if (capable(CAP_SYS_ADMIN))
> > + if (capable(CAP_SYS_ADMIN)) {
> > args->reset_count = i915_reset_count(_priv-
> > >gpu_error);
> > - else
> > + for_each_engine(engine, dev_priv, id)
> > + args->reset_engine_count +=
> > + i915_reset_engine_count(_priv-
> > >gpu_error,
> > + engine);
>
> If access to global GPU reset count is privileged, why is access to
> global engine reset count not? It seems to be fundamentally same
> level
> of data leakage.
But access to global engine reset count (i915_reset_engine_count) is
indeed priviledged. They both are inside if(CAP_SYS_ADMIN){...}, or
maybe I am missing something?
>
> If we wanted to provide some numbers to unprivileged users I think
> we
> would need to store some counters per file_priv/context and return
> those
> when !CAP_SYS_ADMIN.
The question would be why access to global GPU reset count is
priviledged then? I can't think of a reason why it should be
priviledged. I think the new counter (per engine) should fall in the
same category as the global GPU reset one, right? So, can we make them
both unpriviledged?
>
> > + } else {
> > args->reset_count = 0;
> > + args->reset_engine_count = 0;
> > + }
> >
> > args->batch_active = atomic_read(>guilty_count);
> > args->batch_pending = atomic_read(>active_count);
> > diff --git a/include/uapi/drm/i915_drm.h
> > b/include/uapi/drm/i915_drm.h
> > index cc03ef9f885f..3f2c89740b0e 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1642,7 +1642,11 @@ struct drm_i915_reset_stats {
> > /* Number of batches lost pending for execution, for this
> > context */
> > __u32 batch_pending;
> >
> > - __u32 pad;
> > + union {
> > + __u32 pad;
> > + /* Engine resets since boot/module reload, for all
> > contexts */
> > + __u32 reset_engine_count;
> > + };
>
> Chris pointed out in some other review that anonymous unions are not
> friendly towards C++ compilers.
>
> Not sure what is the best option here. Renaming the field could
> break
> old userspace building against newer headers. Is that acceptable?
>
I dug up some old comments from Chris and he stated that recycling the
union like that would be a bad idea since that would make the pad field
an output only parameter thus invalidating gem_reset_stats...
Why can't we simply add a new field __u32 reset_engine_count; as part
of the drm_i915_reset_stats struct?
Regards,
Carlos
> > };
> >
> > struct drm_i915_gem_userptr {
> >
>
> Regards,
>
> Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC i-g-t] lib/igt_kms: Set capabilities before get resource
Hi, I was working on adding the writeback support to VKMS; as a result,
I was using the Liviu’s patchset to validate my implementation [1].
However, I consistently failed to pass the requirements in
igt_display_require(); more specifically, I couldn't pass this test:
igt_skip("No KMS driver or no outputs, pipes: %d, outputs: %d\n",
display->n_pipes, display->n_outputs);
Next, I made a simple code that does the following three steps:
1. Open the device
2. Collect the resource information with drmModeGetResources()
3. Set writeback capability via drmSetClientCap()
4. Print the total of connectors
I noticed that I could not get any connector as well; after some time
debugging the issue and thanks to Anholt’s help in the dri-channel I
learned that I had to use drmSetClientCap() before
drmModeGetResources(). After move all drmSetClientCap() above
drmModeGetResources(), my simple coded displayed the connector
information. I did the same thing within igt_display_require(), and this
test started to pass for me (I did it, in the Liviu’s patch).
In this sense, I checked the igt_display_require() code in the master
branch; and again, I noticed that capabilities are set after getting the
resource information. Is that correct? Is it ok to call
drmModeGetResources() before drmSetClientCap() in this case?
P.s.: I sent it as a RFC because I’m not 100% sure about the change and
the impacts on the tests. If it make sense, I can make a real patch.
1. https://patchwork.freedesktop.org/series/39229/
Signed-off-by: Rodrigo Siqueira
---
lib/igt_kms.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 7ebab4ca..2de9ac41 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1886,6 +1886,10 @@ void igt_display_require(igt_display_t *display, int
drm_fd)
display->drm_fd = drm_fd;
+ drmSetClientCap(drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+ if (drmSetClientCap(drm_fd, DRM_CLIENT_CAP_ATOMIC, 1) == 0)
+ display->is_atomic = 1;
+
resources = drmModeGetResources(display->drm_fd);
if (!resources)
goto out;
@@ -1898,10 +1902,6 @@ void igt_display_require(igt_display_t *display, int
drm_fd)
display->pipes = calloc(sizeof(igt_pipe_t), display->n_pipes);
igt_assert_f(display->pipes, "Failed to allocate memory for %d
pipes\n", display->n_pipes);
- drmSetClientCap(drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
- if (drmSetClientCap(drm_fd, DRM_CLIENT_CAP_ATOMIC, 1) == 0)
- display->is_atomic = 1;
-
plane_resources = drmModeGetPlaneResources(display->drm_fd);
igt_assert(plane_resources);
--
2.21.0
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/17] drm/vkms: Convert to using __drm_atomic_helper_crtc_reset() for reset.
On 03/01, Maarten Lankhorst wrote:
> Convert vkms to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(),
> call it directly for freeing the old state.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_crtc.c | 33 +---
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 8a9aeb0a9ea8..550888e72c96 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -83,26 +83,6 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev,
> unsigned int pipe,
> return true;
> }
>
> -static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
> -{
> - struct vkms_crtc_state *vkms_state = NULL;
> -
> - if (crtc->state) {
> - vkms_state = to_vkms_crtc_state(crtc->state);
> - __drm_atomic_helper_crtc_destroy_state(crtc->state);
> - kfree(vkms_state);
> - crtc->state = NULL;
> - }
> -
> - vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> - if (!vkms_state)
> - return;
> - INIT_WORK(_state->crc_work, vkms_crc_work_handle);
> -
> - crtc->state = _state->base;
> - crtc->state->crtc = crtc;
> -}
> -
> static struct drm_crtc_state *
> vkms_atomic_crtc_duplicate_state(struct drm_crtc *crtc)
> {
> @@ -135,6 +115,19 @@ static void vkms_atomic_crtc_destroy_state(struct
> drm_crtc *crtc,
> }
> }
>
> +static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
> +{
> + struct vkms_crtc_state *vkms_state =
> + kzalloc(sizeof(*vkms_state), GFP_KERNEL);
> +
> + if (crtc->state)
> + vkms_atomic_crtc_destroy_state(crtc, crtc->state);
> +
> + __drm_atomic_helper_crtc_reset(crtc, _state->base);
> + if (vkms_state)
> + INIT_WORK(_state->crc_work, vkms_crc_work_handle);
> +}
> +
> static const struct drm_crtc_funcs vkms_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .destroy= drm_crtc_cleanup,
> --
> 2.20.1
>
Hi Maarten,
First of all, thanks for the patch :)
I tested it on my VM with the IGT test, and everything looks fine.
Reviewed-by: Rodrigo Siqueira
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
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.IGT: success for drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev4)
== Series Details ==
Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev4)
URL : https://patchwork.freedesktop.org/series/56059/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5712_full -> Patchwork_12397_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12397_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@invalid-param-get:
- shard-skl: NOTRUN -> FAIL [fdo#109559]
* igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] /
[fdo#107807]
* igt@kms_atomic_transition@1x-modeset-transitions:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108470]
* igt@kms_atomic_transition@5x-modeset-transitions:
- shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +8
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_color@pipe-b-degamma:
- shard-skl: NOTRUN -> FAIL [fdo#104782]
* igt@kms_color@pipe-c-legacy-gamma:
- shard-glk: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] +1
* igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614] +1
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#103833]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: NOTRUN -> FAIL [fdo#105363]
* igt@kms_flip_tiling@flip-changes-tiling-y:
- shard-skl: PASS -> FAIL [fdo#107931] / [fdo#108303]
* igt@kms_flip_tiling@flip-to-yf-tiled:
- shard-skl: NOTRUN -> FAIL [fdo#107931]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt:
- shard-hsw: NOTRUN -> SKIP [fdo#109271] +28
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-msflip-blt:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +77
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-move:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +88
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- shard-skl: NOTRUN -> FAIL [fdo#107362]
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_plane@pixel-format-pipe-c-planes:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
- shard-hsw: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +2
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: PASS -> DMESG-FAIL [fdo#105763]
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: PASS -> FAIL [fdo#109016]
Possible fixes
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl: FAIL [fdo#103232] -> PASS +6
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +7
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS +4
Warnings
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- shard-skl: INCOMPLETE [fdo#107807] -> SKIP [fdo#109271]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/ddi: Fix default eDP detection on port A
== Series Details == Series: drm/i915/ddi: Fix default eDP detection on port A URL : https://patchwork.freedesktop.org/series/57663/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12399 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12399 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12399, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/57663/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12399: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@module-reload: - fi-kbl-7560u: NOTRUN -> CRASH Known issues Here are the changes found in Patchwork_12399 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-sdma: - fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +17 * igt@gem_ctx_create@basic-files: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106 * igt@kms_busy@basic-flip-b: - fi-gdg-551: NOTRUN -> FAIL [fdo#103182] * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +20 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718] Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_module_load@reload-with-fault-injection: - fi-kbl-7560u: INCOMPLETE -> PASS * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: SKIP [fdo#109271] -> PASS * igt@i915_pm_rpm@basic-rte: - fi-byt-j1900: FAIL [fdo#108800] -> PASS * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: WARN [fdo#109380] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - fi-kbl-7567u: SKIP [fdo#109271] -> PASS +33 * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: FAIL [fdo#104008] -> PASS [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380 Participating hosts (44 -> 41) -- Additional (1): fi-gdg-551 Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u Build changes - * Linux: CI_DRM_5713 -> Patchwork_12399 CI_DRM_5713: 29a41cf5dd10ee68873c16b67d6212b3bd470906 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4875: 91908d36d0d5c90eea86e29736d2748d5ec55335 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12399: f237acf466f217188c30792db6deb1fb3bac @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f237acf466f2 drm/i915/ddi: Fix default eDP detection on port A == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12399/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 7/7] kms_flip: Standardize return value for fb_is_bound
On 03/06, Maarten Lankhorst wrote:
> Op 04-03-2019 om 16:32 schreef Rodrigo Siqueira:
> > The function fb_is_bound() mix integer value with booleans for handling
> > the return value. This commit standardizes the return value of
> > fb_is_bound() for using only booleans.
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > tests/kms_flip.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> > index de3ab600..abfdd363 100755
> > --- a/tests/kms_flip.c
> > +++ b/tests/kms_flip.c
> > @@ -947,8 +947,7 @@ static void paint_flip_mode(struct igt_fb *fb, bool
> > odd_frame)
> > igt_put_cairo_ctx(drm_fd, fb, cr);
> > }
> >
> > -static int
> > -fb_is_bound(struct test_output *o, int fb)
> > +static bool fb_is_bound(struct test_output *o, int fb)
> > {
> > int n;
> >
> > @@ -958,7 +957,7 @@ fb_is_bound(struct test_output *o, int fb)
> > };
> >
> > if (drmIoctl(drm_fd, DRM_IOCTL_MODE_GETCRTC, ))
> > - return 0;
> > + return false;
> >
> > if (!mode.mode_valid || mode.fb_id != fb)
> > return false;
> >
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
>
> Nice cleanup. Hope we can eventually convert kms_flip to igt_display at some
> point for readability.
Hi Petri and Maarten,
First of all, thanks for your review and the clarification in the patch
4 (I really missed the ret = 0, thanks for highlight this case :)
Maarten, could you give some extra details about the idea of converting
kms_flip to igt_display? Could you point out some links or code
reference? I'm just curious to know a little more about this subject.
Best Regards
Rodrigo Siqueira
> For all except patch 4:
>
> Reviewed-by: Maarten Lankhorst
>
> :)
>
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v5 1/6] lib/igt_kms: Add writeback support
Hi Liviu,
I’m using your patchset to guide my implementation of writeback in the
VKMS, so, first of all, thanks :)
During my work, I noticed that you’re setting the drmSetClientCap()
before drmModeGetResources() which make the writeback capability
‘invisible’ for drmModeGetResources(). I made the following change, and
I could pass the igt_display_require():
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f4ff3a96..bb2d8e06 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1912,6 +1912,12 @@ void igt_display_require(igt_display_t *display, int
drm_fd)
display->drm_fd = drm_fd;
+ drmSetClientCap(drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
+ if (drmSetClientCap(drm_fd, DRM_CLIENT_CAP_ATOMIC, 1) == 0)
+ display->is_atomic = 1;
+
+ drmSetClientCap(drm_fd, DRM_CLIENT_CAP_WRITEBACK_CONNECTORS, 1);
+
resources = drmModeGetResources(display->drm_fd);
if (!resources)
goto out;
@@ -1924,12 +1930,6 @@ void igt_display_require(igt_display_t *display, int
drm_fd)
display->pipes = calloc(sizeof(igt_pipe_t), display->n_pipes);
igt_assert_f(display->pipes, "Failed to allocate memory for %d
pipes\n", display->n_pipes);
- drmSetClientCap(drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 1);
- if (drmSetClientCap(drm_fd, DRM_CLIENT_CAP_ATOMIC, 1) == 0)
- display->is_atomic = 1;
-
- drmSetClientCap(drm_fd, DRM_CLIENT_CAP_WRITEBACK_CONNECTORS, 1);
-
plane_resources = drmModeGetPlaneResources(display->drm_fd);
igt_assert(plane_resources);
I'm not 100% confident about this issue, because of this I will send an
RFC and see if I can get more details about this issue.
Additionally, if you need any help with this patchset I will be glad to
help since I’m using it \o/
Best Regards
Rodrigo Siqueira
On 02/04, Brian Starkey wrote:
> Hi Liviu,
>
> On Tue, Jan 15, 2019 at 05:47:42PM +, Liviu Dudau wrote:
> > From: Brian Starkey
>
> [snip]
>
> >
> > +/**
> > + * igt_output_set_writeback_fb:
> > + * @output: Target output
> > + * @fb: Target framebuffer
> > + *
> > + * This function sets the given @fb to be used as the target framebuffer
> > for the
> > + * writeback engine at the next atomic commit. It will also request a
> > writeback
> > + * out fence that will contain the fd number of the out fence created by
> > KMS if
> > + * the given @fb is valid.
> > + */
> > +void igt_output_set_writeback_fb(igt_output_t *output, struct igt_fb *fb)
> > +{
> > + igt_display_t *display = output->display;
> > +
> > + LOG(display, "%s: output_set_writeback_fb(%d)\n", output->name, fb ?
> > fb->fb_id : 0);
> > +
> > + igt_output_set_prop_value(output, IGT_CONNECTOR_WRITEBACK_FB_ID, fb ?
> > fb->fb_id : 0);
> > + /* only request a writeback out fence if the framebuffer is valid */
> > + if (fb)
> > + igt_output_set_prop_value(output,
> > IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR,
> > +
> > (ptrdiff_t)>writeback_out_fence_fd);
>
> I'm still not sure (ptrdiff_t) is the right type here, (uintptr_t)
> seems better.
>
> Thanks,
> -Brian
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
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: success for Polish DRAM information readout code (rev6)
== Series Details == Series: Polish DRAM information readout code (rev6) URL : https://patchwork.freedesktop.org/series/57213/ State : success == Summary == CI Bug Log - changes from CI_DRM_5713 -> Patchwork_12398 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57213/revisions/6/mbox/ Known issues Here are the changes found in Patchwork_12398 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-sdma: - fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +17 * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965] * igt@gem_ctx_create@basic-files: - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106 * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: PASS -> SKIP [fdo#109271] / [fdo#109278] +2 * igt@kms_busy@basic-flip-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] - fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: - fi-blb-e6850: NOTRUN -> SKIP [fdo#109271] +20 * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-7560u: PASS -> FAIL [fdo#103375] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718] Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS * igt@i915_module_load@reload-with-fault-injection: - fi-kbl-7560u: INCOMPLETE -> PASS * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: SKIP [fdo#109271] -> PASS * igt@i915_pm_rpm@basic-rte: - fi-byt-j1900: FAIL [fdo#108800] -> PASS * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: WARN [fdo#109380] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: - fi-kbl-7567u: SKIP [fdo#109271] -> PASS +33 * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: FAIL [fdo#104008] -> PASS [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380 Participating hosts (44 -> 41) -- Additional (1): fi-gdg-551 Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u Build changes - * Linux: CI_DRM_5713 -> Patchwork_12398 CI_DRM_5713: 29a41cf5dd10ee68873c16b67d6212b3bd470906 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4875: 91908d36d0d5c90eea86e29736d2748d5ec55335 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12398: a8f88038519591587c54a4eabe4b3c36233635b5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a8f880385195 drm/i915: Read out memory type 46998aeec480 drm/i915: Extract DIMM info on cnl+ a29bb0ba5839 drm/i915: Clean up intel_get_dram_info() a bit 9ca275a44663 drm/i914: s/l_info/dimm_l/ etc. 309b2b7535a4 drm/i915: Generalize intel_is_dram_symmetric() c697cd312061 drm/i915: Use dram_dimm_info more 71c1e40d02c4 drm/i915: Extract DIMM info on GLK too c3765df44e64 drm/i915: Fix DRAM size reporting for BXT 73fd5eb48602 drm/i915: Extract BXT DIMM helpers 29a5a84fc0bc drm/i915: Polish skl_is_16gb_dimm() 574621760038 drm/i915: Extract functions to derive SKL+ DIMM info 79f39cc66d09 drm/i915: Store DIMM rank information as a number == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12398/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 5/6] drm/i915/dp: Change a link bandwidth computation for DP YCbCr 4:2:0 output
On Wed, Mar 06, 2019 at 09:31:01PM +0200, Gwan-gyeong Mun wrote:
> All of the link bandwidth and Data M/N calculations were assumed a bpp as
> RGB format. But When we are using YCbCr 4:2:0 output format on DP,
> we should change bpp calculations as YCbCr 4:2:0 format.
> The pipe_bpp value was assumed RGB format, therefore, it was multiplied
> with 3. But YCbCr 4:2:0 requires a multiplier value to 1.5.
> Therefore we need to divide pipe_bpp to 2 while DP output uses YCbCr4:2:0
> format.
> - RGB format bpp = bpc x 3
> - YCbCr 4:2:0 format bpp = bpc x 1.5
>
> And it adds missed bpc values for a programming of VSC Header.
> It only affects dp and edp port which use YCbCr 4:2:0 output format.
> And for now, it does not consider a use case of DSC + YCbCr 4:2:0.
>
> v2:
> Addressed review comments from Ville.
> Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
> Because the pipe is running at the full bpp, keep pipe_bpp as RGB
> even though YCbCr 4:2:0 output format is used.
> Add a link bandwidth computation for YCbCr4:2:0 output format.
>
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/intel_dp.c | 64 +
> 1 file changed, 57 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 74f051428fb2..c6826cda8c5f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1723,7 +1723,8 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp,
> int port_clock,
> struct link_config_limits {
> int min_clock, max_clock;
> int min_lane_count, max_lane_count;
> - int min_bpp, max_bpp;
> + int min_bpp, max_bpp, bpp_step;
> + bool is_ycbcr420;
> };
>
> static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> @@ -1833,7 +1834,7 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> int bpp, clock, lane_count;
> int mode_rate, link_clock, link_avail;
>
> - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -=
> limits->bpp_step) {
> mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> bpp);
>
> @@ -1847,7 +1848,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
>
> if (mode_rate <= link_avail) {
> pipe_config->lane_count = lane_count;
> - pipe_config->pipe_bpp = bpp;
> + if (limits->is_ycbcr420)
> + pipe_config->pipe_bpp = bpp * 2;
> + else
> + pipe_config->pipe_bpp = bpp;
This approach feels needlessly complicated.
Can't we just do something like this?
static int intel_dp_output_bpp(const struct intel_crtc_state *crtc_state, int
bpp)
{
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
bpp /= 2;
return bpp;
}
intel_dp_compute_link_config_*(struct intel_dp *intel_dp,
{
...
for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+ int output_bpp = intel_dp_output_bpp(pipe_config, bpp);
+
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
- bpp);
+ output_bpp);
> pipe_config->port_clock = link_clock;
>
> return 0;
> @@ -1869,7 +1873,7 @@ intel_dp_compute_link_config_fast(struct intel_dp
> *intel_dp,
> int bpp, clock, lane_count;
> int mode_rate, link_clock, link_avail;
>
> - for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> + for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -=
> limits->bpp_step) {
> mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> bpp);
>
> @@ -1883,7 +1887,10 @@ intel_dp_compute_link_config_fast(struct intel_dp
> *intel_dp,
>
> if (mode_rate <= link_avail) {
> pipe_config->lane_count = lane_count;
> - pipe_config->pipe_bpp = bpp;
> + if (limits->is_ycbcr420)
> + pipe_config->pipe_bpp = bpp * 2;
> + else
> + pipe_config->pipe_bpp = bpp;
> pipe_config->port_clock = link_clock;
>
> return 0;
> @@ -2015,6 +2022,8 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
>
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Polish DRAM information readout code (rev6)
== Series Details == Series: Polish DRAM information readout code (rev6) URL : https://patchwork.freedesktop.org/series/57213/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Store DIMM rank information as a number -O:drivers/gpu/drm/i915/i915_drv.c:1192:35: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_drv.c:1192:35: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1187:36: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_drv.c:1187:36: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3543:16: warning: expression using sizeof(void) Commit: drm/i915: Extract functions to derive SKL+ DIMM info Okay! Commit: drm/i915: Polish skl_is_16gb_dimm() -drivers/gpu/drm/i915/selftests/../i915_drv.h:3543:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3545:16: warning: expression using sizeof(void) Commit: drm/i915: Extract BXT DIMM helpers Okay! Commit: drm/i915: Fix DRAM size reporting for BXT Okay! Commit: drm/i915: Extract DIMM info on GLK too Okay! Commit: drm/i915: Use dram_dimm_info more Okay! Commit: drm/i915: Generalize intel_is_dram_symmetric() Okay! Commit: drm/i914: s/l_info/dimm_l/ etc. Okay! Commit: drm/i915: Clean up intel_get_dram_info() a bit Okay! Commit: drm/i915: Extract DIMM info on cnl+ Okay! Commit: drm/i915: Read out memory type -drivers/gpu/drm/i915/selftests/../i915_drv.h:3545:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3552:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Polish DRAM information readout code (rev6)
== Series Details == Series: Polish DRAM information readout code (rev6) URL : https://patchwork.freedesktop.org/series/57213/ State : warning == Summary == $ dim checkpatch origin/drm-tip 79f39cc66d09 drm/i915: Store DIMM rank information as a number 574621760038 drm/i915: Extract functions to derive SKL+ DIMM info 29a5a84fc0bc drm/i915: Polish skl_is_16gb_dimm() 73fd5eb48602 drm/i915: Extract BXT DIMM helpers c3765df44e64 drm/i915: Fix DRAM size reporting for BXT 71c1e40d02c4 drm/i915: Extract DIMM info on GLK too c697cd312061 drm/i915: Use dram_dimm_info more 309b2b7535a4 drm/i915: Generalize intel_is_dram_symmetric() 9ca275a44663 drm/i914: s/l_info/dimm_l/ etc. a29bb0ba5839 drm/i915: Clean up intel_get_dram_info() a bit 46998aeec480 drm/i915: Extract DIMM info on cnl+ a8f880385195 drm/i915: Read out memory type -:27: ERROR:BRACKET_SPACE: space prohibited before open square bracket '[' #27: FILE: drivers/gpu/drm/i915/i915_drv.c:1071: +#define DRAM_TYPE_STR(type) [INTEL_DRAM_ ## type] = #type total: 1 errors, 0 warnings, 0 checks, 167 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v4 1/6] drm/i915/dp: Add a config function for YCBCR420 outputs
On Wed, Mar 06, 2019 at 09:30:57PM +0200, Gwan-gyeong Mun wrote:
> This patch checks a support of YCBCR420 outputs on an encoder level.
> If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
> output, else it continues with RGB output mode.
> It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
> a pipe scaler as RGB to YCbCr 4:4:4.
>
> v2:
> Addressed review comments from Ville.
> Style fixed with few naming.
> %s/config/crtc_state/
> %s/intel_crtc/crtc/
> If lscon is active, it makes not to call intel_dp_ycbcr420_config()
> to avoid to clobber of lspcon_ycbcr420_config() routine.
> And it move the 420_only check into the intel_dp_ycbcr420_config().
>
> v3: Fix uninitialized return value and it is reported by Dan Carpenter.
>
> Signed-off-by: Gwan-gyeong Mun
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_dp.c | 39 -
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e1a051c0fbfe..882afba6e0f1 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2104,6 +2104,38 @@ intel_dp_compute_link_config(struct intel_encoder
> *encoder,
> return 0;
> }
>
> +static int
> +intel_dp_ycbcr420_config(struct drm_connector *connector,
> + struct intel_crtc_state *crtc_state)
> +{
> + const struct drm_display_info *info = >display_info;
> + const struct drm_display_mode *adjusted_mode =
> + _state->base.adjusted_mode;
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + int ret;
> +
> + if (drm_mode_is_420_only(info, adjusted_mode) &&
> + connector->ycbcr_420_allowed) {
I would invert this into an early return. That way we avoid the
extra indentation for the rest of the function.
> + crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> +
> + /* YCBCR 420 output conversion needs a scaler */
> + ret = skl_update_scaler_crtc(crtc_state);
> + if (ret) {
> + DRM_DEBUG_KMS("Scaler allocation for output failed\n");
> + goto err;
> + }
> +
> + intel_pch_panel_fitting(crtc, crtc_state,
> + DRM_MODE_SCALE_FULLSCREEN);
> + }
> +
> + return 0;
> +
> +err:
> + DRM_ERROR("Can't support YCBCR420 output\n");
Remove the error print. That is user triggerable which means
no errors prints allowed. And we already have the debug print.
> + return ret;
> +}
> +
> int
> intel_dp_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> @@ -2120,7 +2152,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> to_intel_digital_connector_state(conn_state);
> bool constant_n = drm_dp_has_quirk(_dp->desc,
> DP_DPCD_QUIRK_CONSTANT_N);
> - int ret;
> + int ret = 0;
>
> if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
> pipe_config->has_pch_encoder = true;
> @@ -2128,6 +2160,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> if (lspcon->active)
> lspcon_ycbcr420_config(_connector->base, pipe_config);
> + else
> + ret = intel_dp_ycbcr420_config(_connector->base,
> pipe_config);
> +
> + if (ret)
> + return ret;
>
> pipe_config->has_drrs = false;
> if (IS_G4X(dev_priv) || port == PORT_A)
> --
> 2.21.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ddi: Fix default eDP detection on port A
We rely on VBT DDI port info for eDP detection on GEN9 platforms and
above. This breaks GEN9 platforms which don't have VBT because port A
eDP now defaults to false. Fix this by defaulting to true when VBT is
missing.
Fixes: commit a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP
detection")
Signed-off-by: Thomas Preston
---
drivers/gpu/drm/i915/intel_bios.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 1faa494e2bc9..efbbfb64b55f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1629,6 +1629,7 @@ init_vbt_missing_defaults(struct drm_i915_private
*dev_priv)
info->supports_dvi = (port != PORT_A && port != PORT_E);
info->supports_hdmi = info->supports_dvi;
info->supports_dp = (port != PORT_E);
+ info->supports_edp = (port == PORT_A);
}
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/12] drm/i915: Extract DIMM info on cnl+
From: Ville Syrjälä
We'll need information about the memory configuration on cnl+ too.
Extend the code to parse the slightly changed register layout.
v2: Document what cnl_get_dimm_size() returns (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 66 ++---
drivers/gpu/drm/i915/i915_reg.h | 17 -
2 files changed, 68 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0d00f837ba7f..611e15edcd66 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1106,6 +1106,39 @@ static int skl_get_dimm_ranks(u16 val)
return val + 1;
}
+/* Returns total GB for the whole DIMM */
+static int cnl_get_dimm_size(u16 val)
+{
+ return (val & CNL_DRAM_SIZE_MASK) / 2;
+}
+
+static int cnl_get_dimm_width(u16 val)
+{
+ if (cnl_get_dimm_size(val) == 0)
+ return 0;
+
+ switch (val & CNL_DRAM_WIDTH_MASK) {
+ case CNL_DRAM_WIDTH_X8:
+ case CNL_DRAM_WIDTH_X16:
+ case CNL_DRAM_WIDTH_X32:
+ val = (val & CNL_DRAM_WIDTH_MASK) >> CNL_DRAM_WIDTH_SHIFT;
+ return 8 << val;
+ default:
+ MISSING_CASE(val);
+ return 0;
+ }
+}
+
+static int cnl_get_dimm_ranks(u16 val)
+{
+ if (cnl_get_dimm_size(val) == 0)
+ return 0;
+
+ val = (val & CNL_DRAM_RANK_MASK) >> CNL_DRAM_RANK_SHIFT;
+
+ return val + 1;
+}
+
static bool
skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
{
@@ -1114,12 +1147,19 @@ skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
}
static void
-skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
+skl_dram_get_dimm_info(struct drm_i915_private *dev_priv,
+ struct dram_dimm_info *dimm,
int channel, char dimm_name, u16 val)
{
- dimm->size = skl_get_dimm_size(val);
- dimm->width = skl_get_dimm_width(val);
- dimm->ranks = skl_get_dimm_ranks(val);
+ if (INTEL_GEN(dev_priv) >= 10) {
+ dimm->size = cnl_get_dimm_size(val);
+ dimm->width = cnl_get_dimm_width(val);
+ dimm->ranks = cnl_get_dimm_ranks(val);
+ } else {
+ dimm->size = skl_get_dimm_size(val);
+ dimm->width = skl_get_dimm_width(val);
+ dimm->ranks = skl_get_dimm_ranks(val);
+ }
DRM_DEBUG_KMS("CH%u DIMM %c size: %u GB, width: X%u, ranks: %u, 16Gb
DIMMs: %s\n",
channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
@@ -1127,11 +1167,14 @@ skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
}
static int
-skl_dram_get_channel_info(struct dram_channel_info *ch,
+skl_dram_get_channel_info(struct drm_i915_private *dev_priv,
+ struct dram_channel_info *ch,
int channel, u32 val)
{
- skl_dram_get_dimm_info(>dimm_l, channel, 'L', val & 0x);
- skl_dram_get_dimm_info(>dimm_s, channel, 'S', val >> 16);
+ skl_dram_get_dimm_info(dev_priv, >dimm_l,
+ channel, 'L', val & 0x);
+ skl_dram_get_dimm_info(dev_priv, >dimm_s,
+ channel, 'S', val >> 16);
if (ch->dimm_l.size == 0 && ch->dimm_s.size == 0) {
DRM_DEBUG_KMS("CH%u not populated\n", channel);
@@ -1173,12 +1216,12 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
int ret;
val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, 0, val);
+ ret = skl_dram_get_channel_info(dev_priv, , 0, val);
if (ret == 0)
dram_info->num_channels++;
val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, 1, val);
+ ret = skl_dram_get_channel_info(dev_priv, , 1, val);
if (ret == 0)
dram_info->num_channels++;
@@ -1375,13 +1418,10 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
if (INTEL_GEN(dev_priv) < 9)
return;
- /* Need to calculate bandwidth only for Gen9 */
if (IS_GEN9_LP(dev_priv))
ret = bxt_get_dram_info(dev_priv);
- else if (IS_GEN(dev_priv, 9))
- ret = skl_get_dram_info(dev_priv);
else
- ret = skl_dram_get_channels_info(dev_priv);
+ ret = skl_get_dram_info(dev_priv);
if (ret)
return;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 75236b4f0daf..695eb3ec7187 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9877,8 +9877,21 @@ enum skl_power_gate {
#define SKL_DRAM_WIDTH_X32(0x2 << 8)
#define SKL_DRAM_RANK_MASK(0x1 << 10)
#define SKL_DRAM_RANK_SHIFT 10
-#define SKL_DRAM_RANK_SINGLE
[Intel-gfx] [PATCH v2 12/12] drm/i915: Read out memory type
From: Ville Syrjälä
We'll need to know the memory type in the system for some
bandwidth limitations and whatnot. Let's read that out on
gen9+.
v2: Rebase
v3: Fix the copy paste fail in the BXT bit definitions (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 84 +++--
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 13 +
3 files changed, 100 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 611e15edcd66..bcfc12dd9dda 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,6 +1068,26 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
}
+#define DRAM_TYPE_STR(type) [INTEL_DRAM_ ## type] = #type
+
+static const char *intel_dram_type_str(enum intel_dram_type type)
+{
+ static const char * const str[] = {
+ DRAM_TYPE_STR(UNKNOWN),
+ DRAM_TYPE_STR(DDR3),
+ DRAM_TYPE_STR(DDR4),
+ DRAM_TYPE_STR(LPDDR3),
+ DRAM_TYPE_STR(LPDDR4),
+ };
+
+ if (type >= ARRAY_SIZE(str))
+ type = INTEL_DRAM_UNKNOWN;
+
+ return str[type];
+}
+
+#undef DRAM_TYPE_STR
+
static int intel_dimm_num_devices(const struct dram_dimm_info *dimm)
{
return dimm->ranks * 64 / (dimm->width ?: 1);
@@ -1254,6 +1274,28 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
return 0;
}
+static enum intel_dram_type
+skl_get_dram_type(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ val = I915_READ(SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN);
+
+ switch (val & SKL_DRAM_DDR_TYPE_MASK) {
+ case SKL_DRAM_DDR_TYPE_DDR3:
+ return INTEL_DRAM_DDR3;
+ case SKL_DRAM_DDR_TYPE_DDR4:
+ return INTEL_DRAM_DDR4;
+ case SKL_DRAM_DDR_TYPE_LPDDR3:
+ return INTEL_DRAM_LPDDR3;
+ case SKL_DRAM_DDR_TYPE_LPDDR4:
+ return INTEL_DRAM_LPDDR4;
+ default:
+ MISSING_CASE(val);
+ return INTEL_DRAM_UNKNOWN;
+ }
+}
+
static int
skl_get_dram_info(struct drm_i915_private *dev_priv)
{
@@ -1261,6 +1303,9 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
u32 mem_freq_khz, val;
int ret;
+ dram_info->type = skl_get_dram_type(dev_priv);
+ DRM_DEBUG_KMS("DRAM type: %s\n", intel_dram_type_str(dram_info->type));
+
ret = skl_dram_get_channels_info(dev_priv);
if (ret)
return ret;
@@ -1327,6 +1372,26 @@ static int bxt_get_dimm_ranks(u32 val)
}
}
+static enum intel_dram_type bxt_get_dimm_type(u32 val)
+{
+ if (!bxt_get_dimm_size(val))
+ return INTEL_DRAM_UNKNOWN;
+
+ switch (val & BXT_DRAM_TYPE_MASK) {
+ case BXT_DRAM_TYPE_DDR3:
+ return INTEL_DRAM_DDR3;
+ case BXT_DRAM_TYPE_LPDDR3:
+ return INTEL_DRAM_LPDDR3;
+ case BXT_DRAM_TYPE_DDR4:
+ return INTEL_DRAM_DDR4;
+ case BXT_DRAM_TYPE_LPDDR4:
+ return INTEL_DRAM_LPDDR4;
+ default:
+ MISSING_CASE(val);
+ return INTEL_DRAM_UNKNOWN;
+ }
+}
+
static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
u32 val)
{
@@ -1369,6 +1434,7 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
*/
for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
struct dram_dimm_info dimm;
+ enum intel_dram_type type;
val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
if (val == 0x)
@@ -1377,10 +1443,16 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
dram_info->num_channels++;
bxt_get_dimm_info(, val);
+ type = bxt_get_dimm_type(val);
+
+ WARN_ON(type != INTEL_DRAM_UNKNOWN &&
+ dram_info->type != INTEL_DRAM_UNKNOWN &&
+ dram_info->type != type);
- DRM_DEBUG_KMS("CH%u DIMM size: %u GB, width: X%u, ranks: %u\n",
+ DRM_DEBUG_KMS("CH%u DIMM size: %u GB, width: X%u, ranks: %u,
type: %s\n",
i - BXT_D_CR_DRP0_DUNIT_START,
- dimm.size, dimm.width, dimm.ranks);
+ dimm.size, dimm.width, dimm.ranks,
+ intel_dram_type_str(type));
/*
* If any of the channel is single rank channel,
@@ -1391,10 +1463,14 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
dram_info->ranks = dimm.ranks;
else if (dimm.ranks == 1)
dram_info->ranks = 1;
+
+ if (type != INTEL_DRAM_UNKNOWN)
+ dram_info->type = type;
[Intel-gfx] [PATCH v2 09/12] drm/i914: s/l_info/dimm_l/ etc.
From: Ville Syrjälä
Rename the dimm info structs for clarity.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 18 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 08914761303d..54b40c9ea1f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1130,24 +1130,24 @@ static int
skl_dram_get_channel_info(struct dram_channel_info *ch,
int channel, u32 val)
{
- skl_dram_get_dimm_info(>l_info, channel, 'L', val & 0x);
- skl_dram_get_dimm_info(>s_info, channel, 'S', val >> 16);
+ skl_dram_get_dimm_info(>dimm_l, channel, 'L', val & 0x);
+ skl_dram_get_dimm_info(>dimm_s, channel, 'S', val >> 16);
- if (ch->l_info.size == 0 && ch->s_info.size == 0) {
+ if (ch->dimm_l.size == 0 && ch->dimm_s.size == 0) {
DRM_DEBUG_KMS("CH%u not populated\n", channel);
return -EINVAL;
}
- if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
+ if (ch->dimm_l.ranks == 2 || ch->dimm_s.ranks == 2)
ch->ranks = 2;
- else if (ch->l_info.ranks == 1 && ch->s_info.ranks == 1)
+ else if (ch->dimm_l.ranks == 1 && ch->dimm_s.ranks == 1)
ch->ranks = 2;
else
ch->ranks = 1;
ch->is_16gb_dimm =
- skl_is_16gb_dimm(>l_info) ||
- skl_is_16gb_dimm(>s_info);
+ skl_is_16gb_dimm(>dimm_l) ||
+ skl_is_16gb_dimm(>dimm_s);
DRM_DEBUG_KMS("CH%u ranks: %u, 16Gb DIMMs: %s\n",
channel, ch->ranks, yesno(ch->is_16gb_dimm));
@@ -1160,8 +1160,8 @@ intel_is_dram_symmetric(const struct dram_channel_info
*ch0,
const struct dram_channel_info *ch1)
{
return !memcmp(ch0, ch1, sizeof(*ch0)) &&
- (ch0->s_info.size == 0 ||
-!memcmp(>l_info, >s_info, sizeof(ch0->l_info)));
+ (ch0->dimm_s.size == 0 ||
+!memcmp(>dimm_l, >dimm_s, sizeof(ch0->dimm_l)));
}
static int
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 84e3e3a0bd1e..41b7530b3d05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2057,7 +2057,7 @@ struct dram_dimm_info {
};
struct dram_channel_info {
- struct dram_dimm_info l_info, s_info;
+ struct dram_dimm_info dimm_l, dimm_s;
u8 ranks;
bool is_16gb_dimm;
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/12] drm/i915: Clean up intel_get_dram_info() a bit
From: Ville Syrjälä
Remove the pointless zero initialization of bunch of things
(the thing is kzalloc()ed).
Also throw out the mostly useless on-stack string. I think
it'll be clear enough from the logs that 0 means unknown.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 54b40c9ea1f7..0d00f837ba7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1363,14 +1363,8 @@ static void
intel_get_dram_info(struct drm_i915_private *dev_priv)
{
struct dram_info *dram_info = _priv->dram_info;
- char bandwidth_str[32];
int ret;
- dram_info->valid = false;
- dram_info->ranks = 0;
- dram_info->bandwidth_kbps = 0;
- dram_info->num_channels = 0;
-
/*
* Assume 16Gb DIMMs are present until proven otherwise.
* This is only used for the level 0 watermark latency
@@ -1391,12 +1385,10 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
if (ret)
return;
- if (dram_info->bandwidth_kbps)
- sprintf(bandwidth_str, "%d KBps", dram_info->bandwidth_kbps);
- else
- sprintf(bandwidth_str, "unknown");
- DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
- bandwidth_str, dram_info->num_channels);
+ DRM_DEBUG_KMS("DRAM bandwidth: %u kBps, channels: %u\n",
+ dram_info->bandwidth_kbps,
+ dram_info->num_channels);
+
DRM_DEBUG_KMS("DRAM ranks: %u, 16Gb DIMMs: %s\n",
dram_info->ranks, yesno(dram_info->is_16gb_dimm));
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/12] drm/i915: Fix DRAM size reporting for BXT
From: Ville Syrjälä
The BXT DUNIT register tells us the size of each DRAM device
in Gb. We want to report the size of the whole DIMM in GB, so
that it matches how we report it for non-LP platforms.
v2: Deobfuscate the math (Chris)
s/GB/GBIT/ in the register bit definitions (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 17 +++--
drivers/gpu/drm/i915/i915_reg.h | 10 +-
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bba051d9f21d..a3cf74a00b3f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1242,15 +1242,15 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
static int bxt_get_dimm_size(u32 val)
{
switch (val & BXT_DRAM_SIZE_MASK) {
- case BXT_DRAM_SIZE_4GB:
+ case BXT_DRAM_SIZE_4GBIT:
return 4;
- case BXT_DRAM_SIZE_6GB:
+ case BXT_DRAM_SIZE_6GBIT:
return 6;
- case BXT_DRAM_SIZE_8GB:
+ case BXT_DRAM_SIZE_8GBIT:
return 8;
- case BXT_DRAM_SIZE_12GB:
+ case BXT_DRAM_SIZE_12GBIT:
return 12;
- case BXT_DRAM_SIZE_16GB:
+ case BXT_DRAM_SIZE_16GBIT:
return 16;
default:
MISSING_CASE(val);
@@ -1287,9 +1287,14 @@ static int bxt_get_dimm_ranks(u32 val)
static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
u32 val)
{
- dimm->size = bxt_get_dimm_size(val);
dimm->width = bxt_get_dimm_width(val);
dimm->ranks = bxt_get_dimm_ranks(val);
+
+ /*
+* Size in register is Gb per DRAM device. Convert to total
+* GB to match the way we report this for non-LP platforms.
+*/
+ dimm->size = bxt_get_dimm_size(val) * intel_dimm_num_devices(dimm) / 8;
}
static int
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 16ce9c609c65..75236b4f0daf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9856,11 +9856,11 @@ enum skl_power_gate {
#define BXT_DRAM_WIDTH_X64(0x3 << 4)
#define BXT_DRAM_SIZE_MASK(0x7 << 6)
#define BXT_DRAM_SIZE_SHIFT 6
-#define BXT_DRAM_SIZE_4GB (0x0 << 6)
-#define BXT_DRAM_SIZE_6GB (0x1 << 6)
-#define BXT_DRAM_SIZE_8GB (0x2 << 6)
-#define BXT_DRAM_SIZE_12GB(0x3 << 6)
-#define BXT_DRAM_SIZE_16GB(0x4 << 6)
+#define BXT_DRAM_SIZE_4GBIT (0x0 << 6)
+#define BXT_DRAM_SIZE_6GBIT (0x1 << 6)
+#define BXT_DRAM_SIZE_8GBIT (0x2 << 6)
+#define BXT_DRAM_SIZE_12GBIT (0x3 << 6)
+#define BXT_DRAM_SIZE_16GBIT (0x4 << 6)
#define SKL_MEMORY_FREQ_MULTIPLIER_HZ 2
#define SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x5E04)
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/12] drm/i915: Store DIMM rank information as a number
From: Ville Syrjälä
Life will be easier later if we have the ranks stored
as a bare number.
v2: s/%d/%u/ all over (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 92 +++--
drivers/gpu/drm/i915/i915_drv.h | 11 ++--
2 files changed, 45 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b548c292738c..ec3fb349d49e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,28 +1068,28 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
}
-static enum dram_rank skl_get_dimm_rank(u8 size, u32 rank)
+static int skl_get_dimm_ranks(u8 size, u32 rank)
{
if (size == 0)
- return I915_DRAM_RANK_INVALID;
+ return 0;
if (rank == SKL_DRAM_RANK_SINGLE)
- return I915_DRAM_RANK_SINGLE;
+ return 1;
else if (rank == SKL_DRAM_RANK_DUAL)
- return I915_DRAM_RANK_DUAL;
+ return 2;
- return I915_DRAM_RANK_INVALID;
+ return 0;
}
static bool
-skl_is_16gb_dimm(enum dram_rank rank, u8 size, u8 width)
+skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
{
- if (rank == I915_DRAM_RANK_SINGLE && width == 8 && size == 16)
+ if (ranks == 1 && width == 8 && size == 16)
return true;
- else if (rank == I915_DRAM_RANK_DUAL && width == 8 && size == 32)
+ else if (ranks == 2 && width == 8 && size == 32)
return true;
- else if (rank == SKL_DRAM_RANK_SINGLE && width == 16 && size == 8)
+ else if (ranks == 1 && width == 16 && size == 8)
return true;
- else if (rank == SKL_DRAM_RANK_DUAL && width == 16 && size == 16)
+ else if (ranks == 2 && width == 16 && size == 16)
return true;
return false;
@@ -1120,28 +1120,24 @@ skl_dram_get_channel_info(struct dram_channel_info *ch,
u32 val)
tmp_l = val & SKL_DRAM_RANK_MASK;
tmp_s = s_val & SKL_DRAM_RANK_MASK;
- ch->l_info.rank = skl_get_dimm_rank(ch->l_info.size, tmp_l);
- ch->s_info.rank = skl_get_dimm_rank(ch->s_info.size, tmp_s);
-
- if (ch->l_info.rank == I915_DRAM_RANK_DUAL ||
- ch->s_info.rank == I915_DRAM_RANK_DUAL)
- ch->rank = I915_DRAM_RANK_DUAL;
- else if (ch->l_info.rank == I915_DRAM_RANK_SINGLE &&
-ch->s_info.rank == I915_DRAM_RANK_SINGLE)
- ch->rank = I915_DRAM_RANK_DUAL;
+ ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
+ ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
+
+ if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
+ ch->ranks = 2;
+ else if (ch->l_info.ranks == 1 && ch->s_info.ranks == 1)
+ ch->ranks = 2;
else
- ch->rank = I915_DRAM_RANK_SINGLE;
+ ch->ranks = 1;
- ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.rank, ch->l_info.size,
+ ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
ch->l_info.width) ||
- skl_is_16gb_dimm(ch->s_info.rank, ch->s_info.size,
+ skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
ch->s_info.width);
- DRM_DEBUG_KMS("(size:width:rank) L(%dGB:X%d:%s) S(%dGB:X%d:%s)\n",
- ch->l_info.size, ch->l_info.width,
- ch->l_info.rank ? "dual" : "single",
- ch->s_info.size, ch->s_info.width,
- ch->s_info.rank ? "dual" : "single");
+ DRM_DEBUG_KMS("(size:width:ranks) L(%uGB:X%u:%u) S(%uGB:X%u:%u)\n",
+ ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
+ ch->s_info.size, ch->s_info.width, ch->s_info.ranks);
return 0;
}
@@ -1154,7 +1150,7 @@ intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
(ch0->s_info.size == 0 ||
(ch0->l_info.size == ch0->s_info.size &&
ch0->l_info.width == ch0->s_info.width &&
- ch0->l_info.rank == ch0->s_info.rank)));
+ ch0->l_info.ranks == ch0->s_info.ranks)));
}
static int
@@ -1185,13 +1181,12 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
* will be same as if single rank memory, so consider single rank
* memory.
*/
- if (ch0.rank == I915_DRAM_RANK_SINGLE ||
- ch1.rank == I915_DRAM_RANK_SINGLE)
- dram_info->rank = I915_DRAM_RANK_SINGLE;
+ if (ch0.ranks == 1 || ch1.ranks == 1)
+ dram_info->ranks = 1;
else
- dram_info->rank = max(ch0.rank, ch1.rank);
+ dram_info->ranks = max(ch0.ranks, ch1.ranks);
- if
[Intel-gfx] [PATCH v2 02/12] drm/i915: Extract functions to derive SKL+ DIMM info
From: Ville Syrjälä
Make the code less repetitive by extracting a few small helpers.
v2: Squash in the switch removal for skl_get_dimm_ranks()
(it got misplaced in a rebase accident)
Document what skl_get_dimm_size() returns (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 63 -
1 file changed, 38 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec3fb349d49e..45d70ecd9037 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,16 +1068,37 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
}
-static int skl_get_dimm_ranks(u8 size, u32 rank)
+/* Returns total GB for the whole DIMM */
+static int skl_get_dimm_size(u16 val)
{
- if (size == 0)
+ return val & SKL_DRAM_SIZE_MASK;
+}
+
+static int skl_get_dimm_width(u16 val)
+{
+ if (skl_get_dimm_size(val) == 0)
return 0;
- if (rank == SKL_DRAM_RANK_SINGLE)
- return 1;
- else if (rank == SKL_DRAM_RANK_DUAL)
- return 2;
- return 0;
+ switch (val & SKL_DRAM_WIDTH_MASK) {
+ case SKL_DRAM_WIDTH_X8:
+ case SKL_DRAM_WIDTH_X16:
+ case SKL_DRAM_WIDTH_X32:
+ val = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
+ return 8 << val;
+ default:
+ MISSING_CASE(val);
+ return 0;
+ }
+}
+
+static int skl_get_dimm_ranks(u16 val)
+{
+ if (skl_get_dimm_size(val) == 0)
+ return 0;
+
+ val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
+
+ return val + 1;
}
static bool
@@ -1098,30 +1119,22 @@ skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
static int
skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
{
- u32 tmp_l, tmp_s;
- u32 s_val = val >> SKL_DRAM_S_SHIFT;
+ u16 tmp_l, tmp_s;
- if (!val)
- return -EINVAL;
+ tmp_l = val & 0x;
+ tmp_s = val >> 16;
- tmp_l = val & SKL_DRAM_SIZE_MASK;
- tmp_s = s_val & SKL_DRAM_SIZE_MASK;
+ ch->l_info.size = skl_get_dimm_size(tmp_l);
+ ch->s_info.size = skl_get_dimm_size(tmp_s);
- if (tmp_l == 0 && tmp_s == 0)
+ if (ch->l_info.size == 0 && ch->s_info.size == 0)
return -EINVAL;
- ch->l_info.size = tmp_l;
- ch->s_info.size = tmp_s;
-
- tmp_l = (val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
- tmp_s = (s_val & SKL_DRAM_WIDTH_MASK) >> SKL_DRAM_WIDTH_SHIFT;
- ch->l_info.width = (1 << tmp_l) * 8;
- ch->s_info.width = (1 << tmp_s) * 8;
+ ch->l_info.width = skl_get_dimm_width(tmp_l);
+ ch->s_info.width = skl_get_dimm_width(tmp_s);
- tmp_l = val & SKL_DRAM_RANK_MASK;
- tmp_s = s_val & SKL_DRAM_RANK_MASK;
- ch->l_info.ranks = skl_get_dimm_ranks(ch->l_info.size, tmp_l);
- ch->s_info.ranks = skl_get_dimm_ranks(ch->s_info.size, tmp_s);
+ ch->l_info.ranks = skl_get_dimm_ranks(tmp_l);
+ ch->s_info.ranks = skl_get_dimm_ranks(tmp_s);
if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
ch->ranks = 2;
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/12] drm/i915: Generalize intel_is_dram_symmetric()
From: Ville Syrjälä
Decouple intel_is_dram_symmetric() from the raw register values
by comparing just the dram_channel_info structs.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 71a4da5caee7..08914761303d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1156,14 +1156,12 @@ skl_dram_get_channel_info(struct dram_channel_info *ch,
}
static bool
-intel_is_dram_symmetric(u32 val_ch0, u32 val_ch1,
- struct dram_channel_info *ch0)
+intel_is_dram_symmetric(const struct dram_channel_info *ch0,
+ const struct dram_channel_info *ch1)
{
- return (val_ch0 == val_ch1 &&
+ return !memcmp(ch0, ch1, sizeof(*ch0)) &&
(ch0->s_info.size == 0 ||
-(ch0->l_info.size == ch0->s_info.size &&
- ch0->l_info.width == ch0->s_info.width &&
- ch0->l_info.ranks == ch0->s_info.ranks)));
+!memcmp(>l_info, >s_info, sizeof(ch0->l_info)));
}
static int
@@ -1171,16 +1169,16 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
{
struct dram_info *dram_info = _priv->dram_info;
struct dram_channel_info ch0 = {}, ch1 = {};
- u32 val_ch0, val_ch1;
+ u32 val;
int ret;
- val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, 0, val_ch0);
+ val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+ ret = skl_dram_get_channel_info(, 0, val);
if (ret == 0)
dram_info->num_channels++;
- val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, 1, val_ch1);
+ val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+ ret = skl_dram_get_channel_info(, 1, val);
if (ret == 0)
dram_info->num_channels++;
@@ -1206,12 +1204,10 @@ skl_dram_get_channels_info(struct drm_i915_private
*dev_priv)
dram_info->is_16gb_dimm = ch0.is_16gb_dimm || ch1.is_16gb_dimm;
- dev_priv->dram_info.symmetric_memory = intel_is_dram_symmetric(val_ch0,
- val_ch1,
- );
+ dram_info->symmetric_memory = intel_is_dram_symmetric(, );
- DRM_DEBUG_KMS("memory configuration is %sSymmetric memory\n",
- dev_priv->dram_info.symmetric_memory ? "" : "not ");
+ DRM_DEBUG_KMS("Memory configuration is symmetric? %s\n",
+ yesno(dram_info->symmetric_memory));
return 0;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/12] drm/i915: Extract DIMM info on GLK too
From: Ville Syrjälä The BXT code for parsing DIMM info works for GLK too. Let's dig it out even if we might not need it immediately. Reviewed-by: Jani Nikula Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index a3cf74a00b3f..7f8bdebd9f1a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1378,11 +1378,11 @@ intel_get_dram_info(struct drm_i915_private *dev_priv) */ dram_info->is_16gb_dimm = !IS_GEN9_LP(dev_priv); - if (INTEL_GEN(dev_priv) < 9 || IS_GEMINILAKE(dev_priv)) + if (INTEL_GEN(dev_priv) < 9) return; /* Need to calculate bandwidth only for Gen9 */ - if (IS_BROXTON(dev_priv)) + if (IS_GEN9_LP(dev_priv)) ret = bxt_get_dram_info(dev_priv); else if (IS_GEN(dev_priv, 9)) ret = skl_get_dram_info(dev_priv); -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/12] drm/i915: Extract BXT DIMM helpers
From: Ville Syrjälä
Polish the bxt DIMM parsing by extracting a few small helpers.
v2: Use struct dram_dimm_info
v3: Document what bxt_get_dimm_size() returns (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 94 ++---
1 file changed, 63 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e35a75be3a2a..bba051d9f21d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1238,6 +1238,60 @@ skl_get_dram_info(struct drm_i915_private *dev_priv)
return 0;
}
+/* Returns Gb per DRAM device */
+static int bxt_get_dimm_size(u32 val)
+{
+ switch (val & BXT_DRAM_SIZE_MASK) {
+ case BXT_DRAM_SIZE_4GB:
+ return 4;
+ case BXT_DRAM_SIZE_6GB:
+ return 6;
+ case BXT_DRAM_SIZE_8GB:
+ return 8;
+ case BXT_DRAM_SIZE_12GB:
+ return 12;
+ case BXT_DRAM_SIZE_16GB:
+ return 16;
+ default:
+ MISSING_CASE(val);
+ return 0;
+ }
+}
+
+static int bxt_get_dimm_width(u32 val)
+{
+ if (!bxt_get_dimm_size(val))
+ return 0;
+
+ val = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
+
+ return 8 << val;
+}
+
+static int bxt_get_dimm_ranks(u32 val)
+{
+ if (!bxt_get_dimm_size(val))
+ return 0;
+
+ switch (val & BXT_DRAM_RANK_MASK) {
+ case BXT_DRAM_RANK_SINGLE:
+ return 1;
+ case BXT_DRAM_RANK_DUAL:
+ return 2;
+ default:
+ MISSING_CASE(val);
+ return 0;
+ }
+}
+
+static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
+ u32 val)
+{
+ dimm->size = bxt_get_dimm_size(val);
+ dimm->width = bxt_get_dimm_width(val);
+ dimm->ranks = bxt_get_dimm_ranks(val);
+}
+
static int
bxt_get_dram_info(struct drm_i915_private *dev_priv)
{
@@ -1266,41 +1320,19 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
*/
for (i = BXT_D_CR_DRP0_DUNIT_START; i <= BXT_D_CR_DRP0_DUNIT_END; i++) {
- u8 size, width, ranks;
- u32 tmp;
+ struct dram_dimm_info dimm;
val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
if (val == 0x)
continue;
dram_info->num_channels++;
- tmp = val & BXT_DRAM_RANK_MASK;
-
- if (tmp == BXT_DRAM_RANK_SINGLE)
- ranks = 1;
- else if (tmp == BXT_DRAM_RANK_DUAL)
- ranks = 2;
- else
- ranks = 0;
-
- tmp = val & BXT_DRAM_SIZE_MASK;
- if (tmp == BXT_DRAM_SIZE_4GB)
- size = 4;
- else if (tmp == BXT_DRAM_SIZE_6GB)
- size = 6;
- else if (tmp == BXT_DRAM_SIZE_8GB)
- size = 8;
- else if (tmp == BXT_DRAM_SIZE_12GB)
- size = 12;
- else if (tmp == BXT_DRAM_SIZE_16GB)
- size = 16;
- else
- size = 0;
-
- tmp = (val & BXT_DRAM_WIDTH_MASK) >> BXT_DRAM_WIDTH_SHIFT;
- width = (1 << tmp) * 8;
- DRM_DEBUG_KMS("dram size:%uGB width:X%u ranks:%u\n",
- size, width, ranks);
+
+ bxt_get_dimm_info(, val);
+
+ DRM_DEBUG_KMS("CH%u DIMM size: %u GB, width: X%u, ranks: %u\n",
+ i - BXT_D_CR_DRP0_DUNIT_START,
+ dimm.size, dimm.width, dimm.ranks);
/*
* If any of the channel is single rank channel,
@@ -1308,8 +1340,8 @@ bxt_get_dram_info(struct drm_i915_private *dev_priv)
* memory, so consider single rank memory.
*/
if (dram_info->ranks == 0)
- dram_info->ranks = ranks;
- else if (ranks == 1)
+ dram_info->ranks = dimm.ranks;
+ else if (dimm.ranks == 1)
dram_info->ranks = 1;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/12] drm/i915: Use dram_dimm_info more
From: Ville Syrjälä
Reduce the code duplication a bit by sharing the same
code for parsing both DIMMs on a channel.
v2: s/%d/%u/ all over (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 44 ++---
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f8bdebd9f1a..71a4da5caee7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1113,25 +1113,30 @@ skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
return 8 * dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
}
-static int
-skl_dram_get_channel_info(struct dram_channel_info *ch, u32 val)
+static void
+skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
+ int channel, char dimm_name, u16 val)
{
- u16 tmp_l, tmp_s;
+ dimm->size = skl_get_dimm_size(val);
+ dimm->width = skl_get_dimm_width(val);
+ dimm->ranks = skl_get_dimm_ranks(val);
- tmp_l = val & 0x;
- tmp_s = val >> 16;
+ DRM_DEBUG_KMS("CH%u DIMM %c size: %u GB, width: X%u, ranks: %u, 16Gb
DIMMs: %s\n",
+ channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
+ yesno(skl_is_16gb_dimm(dimm)));
+}
- ch->l_info.size = skl_get_dimm_size(tmp_l);
- ch->s_info.size = skl_get_dimm_size(tmp_s);
+static int
+skl_dram_get_channel_info(struct dram_channel_info *ch,
+ int channel, u32 val)
+{
+ skl_dram_get_dimm_info(>l_info, channel, 'L', val & 0x);
+ skl_dram_get_dimm_info(>s_info, channel, 'S', val >> 16);
- if (ch->l_info.size == 0 && ch->s_info.size == 0)
+ if (ch->l_info.size == 0 && ch->s_info.size == 0) {
+ DRM_DEBUG_KMS("CH%u not populated\n", channel);
return -EINVAL;
-
- ch->l_info.width = skl_get_dimm_width(tmp_l);
- ch->s_info.width = skl_get_dimm_width(tmp_s);
-
- ch->l_info.ranks = skl_get_dimm_ranks(tmp_l);
- ch->s_info.ranks = skl_get_dimm_ranks(tmp_s);
+ }
if (ch->l_info.ranks == 2 || ch->s_info.ranks == 2)
ch->ranks = 2;
@@ -1144,9 +1149,8 @@ skl_dram_get_channel_info(struct dram_channel_info *ch,
u32 val)
skl_is_16gb_dimm(>l_info) ||
skl_is_16gb_dimm(>s_info);
- DRM_DEBUG_KMS("(size:width:ranks) L(%uGB:X%u:%u) S(%uGB:X%u:%u)\n",
- ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
- ch->s_info.size, ch->s_info.width, ch->s_info.ranks);
+ DRM_DEBUG_KMS("CH%u ranks: %u, 16Gb DIMMs: %s\n",
+ channel, ch->ranks, yesno(ch->is_16gb_dimm));
return 0;
}
@@ -1166,17 +1170,17 @@ static int
skl_dram_get_channels_info(struct drm_i915_private *dev_priv)
{
struct dram_info *dram_info = _priv->dram_info;
- struct dram_channel_info ch0, ch1;
+ struct dram_channel_info ch0 = {}, ch1 = {};
u32 val_ch0, val_ch1;
int ret;
val_ch0 = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, val_ch0);
+ ret = skl_dram_get_channel_info(, 0, val_ch0);
if (ret == 0)
dram_info->num_channels++;
val_ch1 = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
- ret = skl_dram_get_channel_info(, val_ch1);
+ ret = skl_dram_get_channel_info(, 1, val_ch1);
if (ret == 0)
dram_info->num_channels++;
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/12] drm/i915: Polish skl_is_16gb_dimm()
From: Ville Syrjälä
Pass the dimm struct to skl_is_16gb_dimm() rather than passing each
value separately. And let's replace the hardcoded set of values with
some simple arithmetic.
Also fix the byte vs. bit inconsistency in the debug message,
and polish the wording otherwise as well.
v2: Deobfuscate the math (Chris)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 28
drivers/gpu/drm/i915/i915_drv.h | 8 +---
2 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 45d70ecd9037..e35a75be3a2a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1068,6 +1068,11 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
intel_gvt_sanitize_options(dev_priv);
}
+static int intel_dimm_num_devices(const struct dram_dimm_info *dimm)
+{
+ return dimm->ranks * 64 / (dimm->width ?: 1);
+}
+
/* Returns total GB for the whole DIMM */
static int skl_get_dimm_size(u16 val)
{
@@ -1102,18 +1107,10 @@ static int skl_get_dimm_ranks(u16 val)
}
static bool
-skl_is_16gb_dimm(u8 ranks, u8 size, u8 width)
+skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
{
- if (ranks == 1 && width == 8 && size == 16)
- return true;
- else if (ranks == 2 && width == 8 && size == 32)
- return true;
- else if (ranks == 1 && width == 16 && size == 8)
- return true;
- else if (ranks == 2 && width == 16 && size == 16)
- return true;
-
- return false;
+ /* Convert total GB to Gb per DRAM device */
+ return 8 * dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
}
static int
@@ -1143,10 +1140,9 @@ skl_dram_get_channel_info(struct dram_channel_info *ch,
u32 val)
else
ch->ranks = 1;
- ch->is_16gb_dimm = skl_is_16gb_dimm(ch->l_info.ranks, ch->l_info.size,
- ch->l_info.width) ||
- skl_is_16gb_dimm(ch->s_info.ranks, ch->s_info.size,
- ch->s_info.width);
+ ch->is_16gb_dimm =
+ skl_is_16gb_dimm(>l_info) ||
+ skl_is_16gb_dimm(>s_info);
DRM_DEBUG_KMS("(size:width:ranks) L(%uGB:X%u:%u) S(%uGB:X%u:%u)\n",
ch->l_info.size, ch->l_info.width, ch->l_info.ranks,
@@ -1364,7 +1360,7 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
sprintf(bandwidth_str, "unknown");
DRM_DEBUG_KMS("DRAM bandwidth:%s, total-channels: %u\n",
bandwidth_str, dram_info->num_channels);
- DRM_DEBUG_KMS("DRAM ranks: %u, 16GB-dimm:%s\n",
+ DRM_DEBUG_KMS("DRAM ranks: %u, 16Gb DIMMs: %s\n",
dram_info->ranks, yesno(dram_info->is_16gb_dimm));
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6f8e9910bb47..84e3e3a0bd1e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2052,10 +2052,12 @@ struct drm_i915_private {
*/
};
+struct dram_dimm_info {
+ u8 size, width, ranks;
+};
+
struct dram_channel_info {
- struct info {
- u8 size, width, ranks;
- } l_info, s_info;
+ struct dram_dimm_info l_info, s_info;
u8 ranks;
bool is_16gb_dimm;
};
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/12] Polish DRAM information readout code
From: Ville Syrjälä Addressed Jani's review comments (thanks!). Should be good to land once CI gives the green light. Ville Syrjälä (12): drm/i915: Store DIMM rank information as a number drm/i915: Extract functions to derive SKL+ DIMM info drm/i915: Polish skl_is_16gb_dimm() drm/i915: Extract BXT DIMM helpers drm/i915: Fix DRAM size reporting for BXT drm/i915: Extract DIMM info on GLK too drm/i915: Use dram_dimm_info more drm/i915: Generalize intel_is_dram_symmetric() drm/i914: s/l_info/dimm_l/ etc. drm/i915: Clean up intel_get_dram_info() a bit drm/i915: Extract DIMM info on cnl+ drm/i915: Read out memory type drivers/gpu/drm/i915/i915_drv.c | 422 +--- drivers/gpu/drm/i915/i915_drv.h | 24 +- drivers/gpu/drm/i915/i915_reg.h | 40 ++- 3 files changed, 331 insertions(+), 155 deletions(-) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 09:00:01PM +0200, Ville Syrjälä wrote: > On Wed, Mar 06, 2019 at 10:55:01AM -0800, Lucas De Marchi wrote: > > On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote: > > >On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote: > > >> On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: > > >> >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: > > >> >> Quoting Ville Syrjälä (2019-03-06 14:52:11) > > >> >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > > >> >> > > Quoting Ville Syrjala (2019-03-05 19:29:05) > > >> >> > > > From: Ville Syrjälä > > >> >> > > > > > >> >> > > > At some point people have started to assume that > > >> >> > > > pipe_offsets[] & co. are only populated for pipes and whatnot > > >> >> > > > that actually exist. That is in fact not currently true, but > > >> >> > > > we can easily make it so. > > >> >> > > > > >> >> > > Any benefits of knock on effect? > > >> >> > > > >> >> > What kind of knock on effect we're thinking? > > >> >> > > >> >> Just wondering why people are eager to make the assumption that > > >> >> non-existent pipes are not set. I presume its to make code neater. > > >> >> > > >> >> i.e. why cater to their whims at all? > > >> > > > >> >Yeah, I guess this was done just to avoid having convoluted platform > > >> >checks all over. I've not checked the code to see if there are > > >> >more places where we could simplify the existing code by adopting > > >> >this approach. > > >> > > > >> >However now that you forced me to think a bit I realize that this > > >> >may break in the presence of fused off pipes. Not quite sure how > > >> >the registers for such fused off blocks would behave. If we aren't > > >> >allowed to touch those registers we'd need to move this stuff > > >> >into the runtime info. That feels a bit wasteful, so as an > > >> >alternative we could just add one or two bitmasks instead. > > >> > > > >> >Cc:ing Lucas who seems to the main offender here... > > >> > > >> humn.. is this about the EDP transcoder? Missing some context here. > > >> Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, > > >> even if it has? glancing over the possible mistake chv? :-/ > > > > > >Currently .trans_offsets[TRANSCODER_EDP] != 0 on _every_ platform. > > > > the commit was made to _allow_ platforms not to have the edp transcoder > > so we don't need to keep adding platform checks when the needs arrise. > > Most of the platforms don't have EDP transcoder. > > > > > checking now that that probably broke chv though. > > No, chv is fine. All pre-hsw platforms are busted though. I pushed the patch so at least we should be closer to the old state of things now. Oh, and I just realized that BXT DSI is now also potentially broken. The error capture code is going to attempt to read registers which do not exist on those transcoders. Not sure if that's going to succeed or not. In fact, wasn't there something about the clock having to be on before we can even access the DSI registers? Hmm, yes there was (look for for bxt_dsi_pll_is_enabled()), but I'm not sure if the transcoder registers were affected or not. -- Ville Syrjälä Intel ___ 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/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev4)
== Series Details == Series: drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs (rev4) URL : https://patchwork.freedesktop.org/series/56059/ State : success == Summary == CI Bug Log - changes from CI_DRM_5712 -> Patchwork_12397 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/56059/revisions/4/mbox/ Known issues Here are the changes found in Patchwork_12397 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76 * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: PASS -> SKIP [fdo#109271] * igt@i915_pm_rpm@basic-rte: - fi-bsw-kefka: PASS -> FAIL [fdo#108800] * igt@i915_selftest@live_evict: - fi-bsw-kefka: PASS -> DMESG-WARN [fdo#107709] * igt@kms_busy@basic-flip-c: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] * igt@runner@aborted: - fi-bsw-kefka: NOTRUN -> FAIL [fdo#107709] Possible fixes * igt@i915_pm_rpm@module-reload: - fi-kbl-7560u: CRASH -> PASS * igt@i915_selftest@live_hangcheck: - fi-kbl-7560u: INCOMPLETE [fdo#108044] / [fdo#108744] -> PASS * igt@kms_busy@basic-flip-a: - fi-gdg-551: FAIL [fdo#103182] -> PASS * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: - fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS [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#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 Participating hosts (45 -> 40) -- Additional (1): fi-pnv-d510 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-guc fi-ctg-p8600 Build changes - * Linux: CI_DRM_5712 -> Patchwork_12397 CI_DRM_5712: 5d4de376b9a03c2f74e049ee6a8221df96687ba0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4875: 91908d36d0d5c90eea86e29736d2748d5ec55335 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12397: 8de1624bb2ad3bd1ca1f4f29849c78f594591778 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8de1624bb2ad drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11 3ce464d81e62 drm/i915/dp: Change a link bandwidth computation for DP YCbCr 4:2:0 output c116a1f0d6f3 drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA a3c55fec3da1 drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format f9fd6ebb5127 drm: Add a VSC structure for handling Pixel Encoding/Colorimetry Formats 294637783bfb drm/i915/dp: Add a config function for YCBCR420 outputs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12397/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extract DIMM info on cnl+
On Wed, 06 Mar 2019, Ville Syrjälä wrote:
> On Tue, Mar 05, 2019 at 06:16:57PM +0200, Jani Nikula wrote:
>> On Mon, 25 Feb 2019, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > We'll need information about the memory configuration on cnl+ too.
>> > Extend the code to parse the slightly changed register layout.
>> >
>> > Signed-off-by: Ville Syrjälä
>> > ---
>> > drivers/gpu/drm/i915/i915_drv.c | 69 -
>> > drivers/gpu/drm/i915/i915_reg.h | 17 +++-
>> > 2 files changed, 66 insertions(+), 20 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> > b/drivers/gpu/drm/i915/i915_drv.c
>> > index e3aafe2bf3b7..95361814b531 100644
>> > --- a/drivers/gpu/drm/i915/i915_drv.c
>> > +++ b/drivers/gpu/drm/i915/i915_drv.c
>> > @@ -1095,17 +1095,43 @@ static int skl_get_dimm_ranks(u16 val)
>> >if (skl_get_dimm_size(val) == 0)
>> >return 0;
>> >
>> > - switch (val & SKL_DRAM_RANK_MASK) {
>> > - case SKL_DRAM_RANK_SINGLE:
>> > - case SKL_DRAM_RANK_DUAL:
>> > - val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
>> > - return val + 1;
>> > + val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
>> > +
>> > + return val + 1;
>>
>> This part is a bit out of place. Rebase fail?
>
> Aye. Moved to patch 02 where it belongs.
>
>>
>> > +}
>> > +
>> > +static int cnl_get_dimm_size(u16 val)
>> > +{
>> > + return (val & CNL_DRAM_SIZE_MASK) / 2;
>>
>> Multiples of 0.5 GB... what an odd unit. What if there's an odd value?
>
> The worst thing that could happen is that the 16 Gb detection
> gives us the wrong answer. The other thing is that we'd print
> out the wrong size.
>
> I'm not sure if there is any chance of having such oddly sized
> DRAM chips on any modern DIMM that we'd hit this. I didn't
> really want to change everything just for this at this time.
> We can always revisit it later if necesary.
Ack.
>
>>
>> > +}
>> > +
>> > +static int cnl_get_dimm_width(u16 val)
>> > +{
>> > + if (cnl_get_dimm_size(val) == 0)
>> > + return 0;
>> > +
>> > + switch (val & CNL_DRAM_WIDTH_MASK) {
>> > + case CNL_DRAM_WIDTH_X8:
>> > + case CNL_DRAM_WIDTH_X16:
>> > + case CNL_DRAM_WIDTH_X32:
>> > + val = (val & CNL_DRAM_WIDTH_MASK) >> CNL_DRAM_WIDTH_SHIFT;
>> > + return 8 << val;
>> >default:
>> >MISSING_CASE(val);
>> >return 0;
>> >}
>> > }
>> >
>> > +static int cnl_get_dimm_ranks(u16 val)
>> > +{
>> > + if (cnl_get_dimm_size(val) == 0)
>> > + return 0;
>> > +
>> > + val = (val & CNL_DRAM_RANK_MASK) >> CNL_DRAM_RANK_SHIFT;
>> > +
>> > + return val + 1;
>> > +}
>> > +
>> > static bool
>> > skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
>> > {
>> > @@ -1113,12 +1139,19 @@ skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
>> > }
>> >
>> > static void
>> > -skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
>> > +skl_dram_get_dimm_info(struct drm_i915_private *dev_priv,
>> > + struct dram_dimm_info *dimm,
>> > int channel, char dimm_name, u16 val)
>> > {
>> > - dimm->size = skl_get_dimm_size(val);
>> > - dimm->width = skl_get_dimm_width(val);
>> > - dimm->ranks = skl_get_dimm_ranks(val);
>> > + if (INTEL_GEN(dev_priv) >= 10) {
>> > + dimm->size = cnl_get_dimm_size(val);
>> > + dimm->width = cnl_get_dimm_width(val);
>> > + dimm->ranks = cnl_get_dimm_ranks(val);
>> > + } else {
>> > + dimm->size = skl_get_dimm_size(val);
>> > + dimm->width = skl_get_dimm_width(val);
>> > + dimm->ranks = skl_get_dimm_ranks(val);
>> > + }
>> >
>> >DRM_DEBUG_KMS("CH%d DIMM %c size: %d GB, width: X%d, ranks: %d, 16Gb
>> > DIMMs: %s\n",
>> > channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
>> > @@ -1126,11 +1159,14 @@ skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
>> > }
>> >
>> > static int
>> > -skl_dram_get_channel_info(struct dram_channel_info *ch,
>> > +skl_dram_get_channel_info(struct drm_i915_private *dev_priv,
>> > +struct dram_channel_info *ch,
>> > int channel, u32 val)
>> > {
>> > - skl_dram_get_dimm_info(>dimm_l, channel, 'L', val & 0x);
>> > - skl_dram_get_dimm_info(>dimm_s, channel, 'S', val >> 16);
>> > + skl_dram_get_dimm_info(dev_priv, >dimm_l,
>> > + channel, 'L', val & 0x);
>> > + skl_dram_get_dimm_info(dev_priv, >dimm_s,
>> > + channel, 'S', val >> 16);
>> >
>> >if (ch->dimm_l.size == 0 && ch->dimm_s.size == 0) {
>> >DRM_DEBUG_KMS("CH%d not populated\n", channel);
>> > @@ -1172,12 +1208,12 @@ skl_dram_get_channels_info(struct drm_i915_private
>> > *dev_priv)
>> >int ret;
>> >
>> >val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
>> > - ret = skl_dram_get_channel_info(, 0, val);
>> > + ret = skl_dram_get_channel_info(dev_priv, , 0, val);
>> >if (ret == 0)
>> >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Canonicalise gen8 addresses (rev2)
== Series Details ==
Series: drm/i915/selftests: Canonicalise gen8 addresses (rev2)
URL : https://patchwork.freedesktop.org/series/57645/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5712_full -> Patchwork_12396_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12396_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@invalid-param-get:
- shard-skl: NOTRUN -> FAIL [fdo#109559]
* igt@gem_softpin@noreloc-s3:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_busy@extended-pageflip-hang-newfb-render-e:
- shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-skl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_color@pipe-a-degamma:
- shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145]
* igt@kms_color@pipe-c-legacy-gamma:
- shard-glk: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw: PASS -> FAIL [fdo#105767]
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_flip_tiling@flip-to-yf-tiled:
- shard-skl: NOTRUN -> FAIL [fdo#107931]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt:
- shard-hsw: NOTRUN -> SKIP [fdo#109271] +28
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-indfb-msflip-blt:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +77
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-move:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +71
* igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
- shard-hsw: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_scaling@pipe-a-scaler-with-rotation:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +6
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: PASS -> DMESG-FAIL [fdo#105763]
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: PASS -> FAIL [fdo#109016]
* igt@kms_universal_plane@universal-plane-pipe-b-functional:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-hsw: NOTRUN -> FAIL [fdo#104894]
Possible fixes
* igt@kms_color@pipe-b-legacy-gamma:
- shard-apl: FAIL [fdo#104782] -> PASS
* igt@kms_cursor_crc@cursor-128x128-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +4
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk: FAIL [fdo#108145] -> PASS +1
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: FAIL [fdo#107815] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS +4
* igt@kms_setmode@basic:
- shard-kbl: FAIL [fdo#99912] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-modeset-rpm:
- shard-apl: FAIL [fdo#104894] -> PASS +1
Warnings
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- shard-skl: INCOMPLETE [fdo#107807] -> SKIP [fdo#109271]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[Intel-gfx] [RFC v4 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120:VSC SDP Payload for DB16 through DB18.
v2:
Minor style fix. [Maarten]
Refer to commit ids instead of patchwork. [Maarten]
Cc: Maarten Lankhorst
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
drivers/gpu/drm/i915/intel_dp.c | 73
drivers/gpu/drm/i915/intel_drv.h | 2 +
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 7e3b4e8fdf3a..d89a77a20fcd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3400,6 +3400,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
+ intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 882afba6e0f1..74f051428fb2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4412,6 +4412,79 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
+static void
+intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct dp_vsc_sdp vsc_sdp;
+
+ if (!intel_dp->attached_connector->base.ycbcr_420_allowed)
+ return;
+
+ /* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119 */
+ memset(_sdp, 0, sizeof(vsc_sdp));
+ vsc_sdp.sdp_header.HB0 = 0;
+ vsc_sdp.sdp_header.HB1 = 0x7;
+
+ /* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication. A DP Source device is allowed
+* to indicate the pixel encoding/colorimetry format to the DP Sink
+* device with VSC SDP only when the DP Sink device supports it
+* (i.e., VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the
register
+* DPRX_FEATURE_ENUMERATION_LIST (DPCD Address 02210h, bit 3) is set to
1)
+*/
+ vsc_sdp.sdp_header.HB2 = 0x5;
+
+ /* VSC SDP supporting 3D stereo, + PSR2, + Pixel Encoding/
+* Colorimetry Format indication (HB2 = 05h).
+*/
+ vsc_sdp.sdp_header.HB3 = 0x13;
+ /* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
+* DB16[3:0] DP 1.4a spec, Table 2-120
+*/
+
+ /* Commit id (25edf91501b8 "drm/i915: prepare csc unit for YCBCR420
output")
+* uses the BT.709 color space to perform RGB->YCBCR conversion.
+*/
+ vsc_sdp.DB16 = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
+ vsc_sdp.DB16 |= 0x1; /* 0x1, ITU-R BT.709 */
+
+ /* For pixel encoding formats YCbCr444, YCbCr422, YCbCr420, and Y Only,
+* the following Component Bit Depth values are defined:
+* 001b = 8bpc.
+* 010b = 10bpc.
+* 011b = 12bpc.
+* 100b = 16bpc.
+*/
+ vsc_sdp.DB17 = 0x1;
+
+ /*
+* Content Type (Bits 2:0)
+* 000b = Not defined.
+* 001b = Graphics.
+* 010b = Photo.
+* 011b = Video.
+* 100b = Game
+* All other values are RESERVED.
+* Note: See CTA-861-G for the definition and expected
+* processing by a stream sink for the above contect types.
+*/
+ vsc_sdp.DB18 = 0;
+
+ intel_dig_port->write_infoframe(_dig_port->base,
+ crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
+}
+
+void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+ return;
+
+ intel_pixel_encoding_setup_vsc(intel_dp, crtc_state);
+}
+
static u8 intel_dp_autotest_link_training(struct intel_dp *intel_dp)
{
int status = 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5412373e2f98..b029aa5ab35a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1977,6 +1977,8 @@ u16 intel_dp_dsc_get_output_bpp(int link_clock, u8
lane_count,
int mode_clock, int mode_hdisplay);
u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, int mode_clock,
int mode_hdisplay);
+void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
+ const struct
[Intel-gfx] [RFC v4 6/6] drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and HDMI ports. v2: Minor style fix. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index c6826cda8c5f..8fc9cb939533 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -7435,6 +7435,9 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, connector->interlace_allowed = true; connector->doublescan_allowed = 0; + if (INTEL_GEN(dev_priv) >= 11) + connector->ycbcr_420_allowed = true; + intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); intel_dp_aux_init(intel_dp); -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 2/6] drm: Add a VSC structure for handling Pixel Encoding/Colorimetry Formats
SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
include/drm/drm_dp_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 97ce790a5b5a..3793bea7b7fe 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1096,6 +1096,23 @@ struct edp_vsc_psr {
u8 DB8_31[24]; /* Reserved */
} __packed;
+struct dp_vsc_sdp {
+ struct dp_sdp_header sdp_header;
+ u8 DB0; /* Stereo Interface */
+ u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
+ u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
+ u8 DB3; /* CRC value bits 15:8 of the R or Cr component */
+ u8 DB4; /* CRC value bits 7:0 of the G or Y component */
+ u8 DB5; /* CRC value bits 15:8 of the G or Y component */
+ u8 DB6; /* CRC value bits 7:0 of the B or Cb component */
+ u8 DB7; /* CRC value bits 15:8 of the B or Cb component */
+ u8 DB8_15[8]; /* Reserved */
+ u8 DB16; /* Pixel Encoding and Colorimetry Formats */
+ u8 DB17; /* Dynamic Range and Component Bit Depth */
+ u8 DB18; /* Content Type */
+ u8 DB19_31[13]; /* Reserved */
+} __packed;
+
#define EDP_VSC_PSR_STATE_ACTIVE (1<<0)
#define EDP_VSC_PSR_UPDATE_RFB (1<<1)
#define EDP_VSC_PSR_CRC_VALUES_VALID (1<<2)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 5/6] drm/i915/dp: Change a link bandwidth computation for DP YCbCr 4:2:0 output
All of the link bandwidth and Data M/N calculations were assumed a bpp as
RGB format. But When we are using YCbCr 4:2:0 output format on DP,
we should change bpp calculations as YCbCr 4:2:0 format.
The pipe_bpp value was assumed RGB format, therefore, it was multiplied
with 3. But YCbCr 4:2:0 requires a multiplier value to 1.5.
Therefore we need to divide pipe_bpp to 2 while DP output uses YCbCr4:2:0
format.
- RGB format bpp = bpc x 3
- YCbCr 4:2:0 format bpp = bpc x 1.5
And it adds missed bpc values for a programming of VSC Header.
It only affects dp and edp port which use YCbCr 4:2:0 output format.
And for now, it does not consider a use case of DSC + YCbCr 4:2:0.
v2:
Addressed review comments from Ville.
Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
Because the pipe is running at the full bpp, keep pipe_bpp as RGB
even though YCbCr 4:2:0 output format is used.
Add a link bandwidth computation for YCbCr4:2:0 output format.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/intel_dp.c | 64 +
1 file changed, 57 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 74f051428fb2..c6826cda8c5f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1723,7 +1723,8 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, int
port_clock,
struct link_config_limits {
int min_clock, max_clock;
int min_lane_count, max_lane_count;
- int min_bpp, max_bpp;
+ int min_bpp, max_bpp, bpp_step;
+ bool is_ycbcr420;
};
static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp,
@@ -1833,7 +1834,7 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
int bpp, clock, lane_count;
int mode_rate, link_clock, link_avail;
- for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+ for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -=
limits->bpp_step) {
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
bpp);
@@ -1847,7 +1848,10 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
if (mode_rate <= link_avail) {
pipe_config->lane_count = lane_count;
- pipe_config->pipe_bpp = bpp;
+ if (limits->is_ycbcr420)
+ pipe_config->pipe_bpp = bpp * 2;
+ else
+ pipe_config->pipe_bpp = bpp;
pipe_config->port_clock = link_clock;
return 0;
@@ -1869,7 +1873,7 @@ intel_dp_compute_link_config_fast(struct intel_dp
*intel_dp,
int bpp, clock, lane_count;
int mode_rate, link_clock, link_avail;
- for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+ for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -=
limits->bpp_step) {
mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
bpp);
@@ -1883,7 +1887,10 @@ intel_dp_compute_link_config_fast(struct intel_dp
*intel_dp,
if (mode_rate <= link_avail) {
pipe_config->lane_count = lane_count;
- pipe_config->pipe_bpp = bpp;
+ if (limits->is_ycbcr420)
+ pipe_config->pipe_bpp = bpp * 2;
+ else
+ pipe_config->pipe_bpp = bpp;
pipe_config->port_clock = link_clock;
return 0;
@@ -2015,6 +2022,8 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
struct link_config_limits limits;
int common_len;
int ret;
+ bool is_ycbcr420 =
+ pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ?
true : false;
common_len = intel_dp_common_len_rate_limit(intel_dp,
intel_dp->max_link_rate);
@@ -2030,6 +2039,20 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
limits.min_bpp = 6 * 3;
limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
+ limits.bpp_step = 2 * 3;
+
+ limits.is_ycbcr420 = is_ycbcr420;
+
+ if (is_ycbcr420) {
+ /*
+* bpp value was assumed to RGB therefore it was multiplied
+* with 3. But YCbCr 4:2:0 requires multiplier value to 1.5
+* therefore it divides pipe_bpp to 2.
+*/
+
[Intel-gfx] [RFC v4 4/6] drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for the Pixel
Encoding/Colorimetry Format.
v2: Block comment style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 16ce9c609c65..7076207c90e2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9474,6 +9474,7 @@ enum skl_power_gate {
#define TRANS_MSA_12_BPC (3 << 5)
#define TRANS_MSA_16_BPC (4 << 5)
#define TRANS_MSA_CEA_RANGE (1 << 3)
+#define TRANS_MSA_USE_VSC_SDP (1 << 13)
/* LCPLL Control */
#define LCPLL_CTL _MMIO(0x130040)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d89a77a20fcd..4be076774b84 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1732,6 +1732,14 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
*/
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
+ /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut] while sending
+* YCBCR 420 signals we should program MSA MISC1 fields which
+* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ temp |= TRANS_MSA_USE_VSC_SDP;
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 1/6] drm/i915/dp: Add a config function for YCBCR420 outputs
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
v2:
Addressed review comments from Ville.
Style fixed with few naming.
%s/config/crtc_state/
%s/intel_crtc/crtc/
If lscon is active, it makes not to call intel_dp_ycbcr420_config()
to avoid to clobber of lspcon_ycbcr420_config() routine.
And it move the 420_only check into the intel_dp_ycbcr420_config().
v3: Fix uninitialized return value and it is reported by Dan Carpenter.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 39 -
1 file changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e1a051c0fbfe..882afba6e0f1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2104,6 +2104,38 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
return 0;
}
+static int
+intel_dp_ycbcr420_config(struct drm_connector *connector,
+struct intel_crtc_state *crtc_state)
+{
+ const struct drm_display_info *info = >display_info;
+ const struct drm_display_mode *adjusted_mode =
+ _state->base.adjusted_mode;
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ int ret;
+
+ if (drm_mode_is_420_only(info, adjusted_mode) &&
+ connector->ycbcr_420_allowed) {
+ crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
+ /* YCBCR 420 output conversion needs a scaler */
+ ret = skl_update_scaler_crtc(crtc_state);
+ if (ret) {
+ DRM_DEBUG_KMS("Scaler allocation for output failed\n");
+ goto err;
+ }
+
+ intel_pch_panel_fitting(crtc, crtc_state,
+ DRM_MODE_SCALE_FULLSCREEN);
+ }
+
+ return 0;
+
+err:
+ DRM_ERROR("Can't support YCBCR420 output\n");
+ return ret;
+}
+
int
intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -2120,7 +2152,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
to_intel_digital_connector_state(conn_state);
bool constant_n = drm_dp_has_quirk(_dp->desc,
DP_DPCD_QUIRK_CONSTANT_N);
- int ret;
+ int ret = 0;
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)
pipe_config->has_pch_encoder = true;
@@ -2128,6 +2160,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
+ else
+ ret = intel_dp_ycbcr420_config(_connector->base,
pipe_config);
+
+ if (ret)
+ return ret;
pipe_config->has_drrs = false;
if (IS_G4X(dev_priv) || port == PORT_A)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v4 0/6] drm/i915/dp: Preliminary support for DP YCbCr4:2:0 outputs
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
This patches are RFC patches that add a VSC structure for handling
Pixel Encoding/Colorimetry Formats and program YCBCR 4:2:0 to MSA and VSC SDP.
This is currently not tested, but I wanted to get some inputs on this approach.
The idea of a scaling (RGB -> YCbCr4:4:4 -> YCbCr 4:2:0) is to follow the
same approach used in YCbCr 4:2:0 on HDMI.
v2: Addressed Maarten's review comments, fixed minor coding and block comment
style. And reordered a first patch ("drm/i915/dp: Support DP ports
YUV 4:2:0 output to GEN11") as a last patch.
v3: Addressed Ville's review comments.
Style fixed with few naming.
If lscon is active, it makes not to call intel_dp_ycbcr420_config() to avoid
to clobber of lspcon_ycbcr420_config() routine.
And it move the 420_only check into the intel_dp_ycbcr420_config().
Remove a changing of pipe_bpp on intel_ddi_set_pipe_settings().
Because the pipe is running at the full bpp, keep pipe_bpp as RGB even though
YCbCr 4:2:0 output format is used.
Add a link bandwidth computation for YCbCr4:2:0 output format.
v4: Fix uninitialized return value which is reported by Dan Carpenter.
Gwan-gyeong Mun (6):
drm/i915/dp: Add a config function for YCBCR420 outputs
drm: Add a VSC structure for handling Pixel Encoding/Colorimetry
Formats
drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry
Format
drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA
drm/i915/dp: Change a link bandwidth computation for DP YCbCr 4:2:0
output
drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 9 ++
drivers/gpu/drm/i915/intel_dp.c | 179 +--
drivers/gpu/drm/i915/intel_drv.h | 2 +
include/drm/drm_dp_helper.h | 17 +++
5 files changed, 200 insertions(+), 8 deletions(-)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extract DIMM info on cnl+
On Tue, Mar 05, 2019 at 06:16:57PM +0200, Jani Nikula wrote:
> On Mon, 25 Feb 2019, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll need information about the memory configuration on cnl+ too.
> > Extend the code to parse the slightly changed register layout.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 69 -
> > drivers/gpu/drm/i915/i915_reg.h | 17 +++-
> > 2 files changed, 66 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index e3aafe2bf3b7..95361814b531 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1095,17 +1095,43 @@ static int skl_get_dimm_ranks(u16 val)
> > if (skl_get_dimm_size(val) == 0)
> > return 0;
> >
> > - switch (val & SKL_DRAM_RANK_MASK) {
> > - case SKL_DRAM_RANK_SINGLE:
> > - case SKL_DRAM_RANK_DUAL:
> > - val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
> > - return val + 1;
> > + val = (val & SKL_DRAM_RANK_MASK) >> SKL_DRAM_RANK_SHIFT;
> > +
> > + return val + 1;
>
> This part is a bit out of place. Rebase fail?
Aye. Moved to patch 02 where it belongs.
>
> > +}
> > +
> > +static int cnl_get_dimm_size(u16 val)
> > +{
> > + return (val & CNL_DRAM_SIZE_MASK) / 2;
>
> Multiples of 0.5 GB... what an odd unit. What if there's an odd value?
The worst thing that could happen is that the 16 Gb detection
gives us the wrong answer. The other thing is that we'd print
out the wrong size.
I'm not sure if there is any chance of having such oddly sized
DRAM chips on any modern DIMM that we'd hit this. I didn't
really want to change everything just for this at this time.
We can always revisit it later if necesary.
>
> > +}
> > +
> > +static int cnl_get_dimm_width(u16 val)
> > +{
> > + if (cnl_get_dimm_size(val) == 0)
> > + return 0;
> > +
> > + switch (val & CNL_DRAM_WIDTH_MASK) {
> > + case CNL_DRAM_WIDTH_X8:
> > + case CNL_DRAM_WIDTH_X16:
> > + case CNL_DRAM_WIDTH_X32:
> > + val = (val & CNL_DRAM_WIDTH_MASK) >> CNL_DRAM_WIDTH_SHIFT;
> > + return 8 << val;
> > default:
> > MISSING_CASE(val);
> > return 0;
> > }
> > }
> >
> > +static int cnl_get_dimm_ranks(u16 val)
> > +{
> > + if (cnl_get_dimm_size(val) == 0)
> > + return 0;
> > +
> > + val = (val & CNL_DRAM_RANK_MASK) >> CNL_DRAM_RANK_SHIFT;
> > +
> > + return val + 1;
> > +}
> > +
> > static bool
> > skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
> > {
> > @@ -1113,12 +1139,19 @@ skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
> > }
> >
> > static void
> > -skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
> > +skl_dram_get_dimm_info(struct drm_i915_private *dev_priv,
> > + struct dram_dimm_info *dimm,
> >int channel, char dimm_name, u16 val)
> > {
> > - dimm->size = skl_get_dimm_size(val);
> > - dimm->width = skl_get_dimm_width(val);
> > - dimm->ranks = skl_get_dimm_ranks(val);
> > + if (INTEL_GEN(dev_priv) >= 10) {
> > + dimm->size = cnl_get_dimm_size(val);
> > + dimm->width = cnl_get_dimm_width(val);
> > + dimm->ranks = cnl_get_dimm_ranks(val);
> > + } else {
> > + dimm->size = skl_get_dimm_size(val);
> > + dimm->width = skl_get_dimm_width(val);
> > + dimm->ranks = skl_get_dimm_ranks(val);
> > + }
> >
> > DRM_DEBUG_KMS("CH%d DIMM %c size: %d GB, width: X%d, ranks: %d, 16Gb
> > DIMMs: %s\n",
> > channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
> > @@ -1126,11 +1159,14 @@ skl_dram_get_dimm_info(struct dram_dimm_info *dimm,
> > }
> >
> > static int
> > -skl_dram_get_channel_info(struct dram_channel_info *ch,
> > +skl_dram_get_channel_info(struct drm_i915_private *dev_priv,
> > + struct dram_channel_info *ch,
> > int channel, u32 val)
> > {
> > - skl_dram_get_dimm_info(>dimm_l, channel, 'L', val & 0x);
> > - skl_dram_get_dimm_info(>dimm_s, channel, 'S', val >> 16);
> > + skl_dram_get_dimm_info(dev_priv, >dimm_l,
> > + channel, 'L', val & 0x);
> > + skl_dram_get_dimm_info(dev_priv, >dimm_s,
> > + channel, 'S', val >> 16);
> >
> > if (ch->dimm_l.size == 0 && ch->dimm_s.size == 0) {
> > DRM_DEBUG_KMS("CH%d not populated\n", channel);
> > @@ -1172,12 +1208,12 @@ skl_dram_get_channels_info(struct drm_i915_private
> > *dev_priv)
> > int ret;
> >
> > val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> > - ret = skl_dram_get_channel_info(, 0, val);
> > + ret = skl_dram_get_channel_info(dev_priv, , 0, val);
> > if (ret == 0)
> > dram_info->num_channels++;
> >
> > val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> > - ret = skl_dram_get_channel_info(,
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Fixing error code for WOPCM initialization
-Original Message- From: Chris Wilson Sent: Wednesday, March 6, 2019 1:08 AM To: Wajdeczko, Michal ; Sundaresan, Sujaritha ; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Fixing error code for WOPCM initialization Quoting Michal Wajdeczko (2019-03-06 09:01:09) > On Wed, 06 Mar 2019 09:45:17 +0100, Chris Wilson > > Now doing an if (i915_error_injected() && !err) err = -EINVAL; makes > > sense to catch places where we've eaten that error and so breaking > > the test. > > This will not work today, as at least in one place - i915_gem_init - > we inject -EIO which later we try to replace with success. And for > that case we may rather want to add I think we may want to move that particular test to one side, something along the lines of i915.disable_gpu=1 ? -Chris Just to clarify on how to proceed with the fix. I'm not sure if the suggestion is to go back to the previous version of the patch or to go for a different approach. It also looks like this issue will be flaggin up on the public CI, following the changes Arek has said will be made to the dmesg style. -Sujaritha ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Fixing error code for WOPCM initialization
On 3/6/19 1:08 AM, Chris Wilson wrote: Quoting Michal Wajdeczko (2019-03-06 09:01:09) On Wed, 06 Mar 2019 09:45:17 +0100, Chris Wilson Now doing an if (i915_error_injected() && !err) err = -EINVAL; makes sense to catch places where we've eaten that error and so breaking the test. This will not work today, as at least in one place - i915_gem_init - we inject -EIO which later we try to replace with success. And for that case we may rather want to add I think we may want to move that particular test to one side, something along the lines of i915.disable_gpu=1 ? -Chris Just to clarify on how to proceed with the fix. I'm not sure if the suggestion is to go back to the previous version of the fix or to go for a different approach. Also Arek has said in the internal mailing list that there are some changes being made to the -piglit-style-dmesg, so looks like this issue will be flagging up in the public CI as well. -Sujaritha ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 10:55:01AM -0800, Lucas De Marchi wrote: > On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote: > >On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote: > >> On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: > >> >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: > >> >> Quoting Ville Syrjälä (2019-03-06 14:52:11) > >> >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > >> >> > > Quoting Ville Syrjala (2019-03-05 19:29:05) > >> >> > > > From: Ville Syrjälä > >> >> > > > > >> >> > > > At some point people have started to assume that > >> >> > > > pipe_offsets[] & co. are only populated for pipes and whatnot > >> >> > > > that actually exist. That is in fact not currently true, but > >> >> > > > we can easily make it so. > >> >> > > > >> >> > > Any benefits of knock on effect? > >> >> > > >> >> > What kind of knock on effect we're thinking? > >> >> > >> >> Just wondering why people are eager to make the assumption that > >> >> non-existent pipes are not set. I presume its to make code neater. > >> >> > >> >> i.e. why cater to their whims at all? > >> > > >> >Yeah, I guess this was done just to avoid having convoluted platform > >> >checks all over. I've not checked the code to see if there are > >> >more places where we could simplify the existing code by adopting > >> >this approach. > >> > > >> >However now that you forced me to think a bit I realize that this > >> >may break in the presence of fused off pipes. Not quite sure how > >> >the registers for such fused off blocks would behave. If we aren't > >> >allowed to touch those registers we'd need to move this stuff > >> >into the runtime info. That feels a bit wasteful, so as an > >> >alternative we could just add one or two bitmasks instead. > >> > > >> >Cc:ing Lucas who seems to the main offender here... > >> > >> humn.. is this about the EDP transcoder? Missing some context here. > >> Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, > >> even if it has? glancing over the possible mistake chv? :-/ > > > >Currently .trans_offsets[TRANSCODER_EDP] != 0 on _every_ platform. > > the commit was made to _allow_ platforms not to have the edp transcoder > so we don't need to keep adding platform checks when the needs arrise. Most of the platforms don't have EDP transcoder. > > checking now that that probably broke chv though. No, chv is fine. All pre-hsw platforms are busted though. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 08:01:05PM +0200, Ville Syrjälä wrote: On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote: On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote: > On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: > >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: > >> Quoting Ville Syrjälä (2019-03-06 14:52:11) > >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > >> > > Quoting Ville Syrjala (2019-03-05 19:29:05) > >> > > > From: Ville Syrjälä > >> > > > > >> > > > At some point people have started to assume that > >> > > > pipe_offsets[] & co. are only populated for pipes and whatnot > >> > > > that actually exist. That is in fact not currently true, but > >> > > > we can easily make it so. > >> > > > >> > > Any benefits of knock on effect? > >> > > >> > What kind of knock on effect we're thinking? > >> > >> Just wondering why people are eager to make the assumption that > >> non-existent pipes are not set. I presume its to make code neater. > >> > >> i.e. why cater to their whims at all? > > > >Yeah, I guess this was done just to avoid having convoluted platform > >checks all over. I've not checked the code to see if there are > >more places where we could simplify the existing code by adopting > >this approach. > > > >However now that you forced me to think a bit I realize that this > >may break in the presence of fused off pipes. Not quite sure how > >the registers for such fused off blocks would behave. If we aren't > >allowed to touch those registers we'd need to move this stuff > >into the runtime info. That feels a bit wasteful, so as an > >alternative we could just add one or two bitmasks instead. > > > >Cc:ing Lucas who seems to the main offender here... > > humn.. is this about the EDP transcoder? Missing some context here. > Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, > even if it has? glancing over the possible mistake chv? :-/ Currently .trans_offsets[TRANSCODER_EDP] != 0 on _every_ platform. So using that to determine if a transcoder is present is not going to work. So far the HAS_EDP_TRANSCODER() thing is not actually a problem as it's only called from the ddi code which guarantees that the transcoder is in fact present. But the error capture code is now very much wrong. Commit 062de72bc0c73f4b9fa8532e5a98bf609ebd08da was done in preparation for HAS_EDP_TRANSCODER to account for that. Lucas De Marchi -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/bios: iterate over child devices to initialize ddi_port_info
On Wed, Mar 06, 2019 at 05:34:14PM +0200, Jani Nikula wrote:
> Iterate over child devices instead of ports in parse_ddi_ports() to
> initialize dri_port_info. We'll eventually need to decide some stuff
> based on the child device order, which may be different from the port
> order.
>
> As a bonus, this allows better abstractions for e.g. dvo port mapping.
>
> There's a subtle change in the DDC pin and AUX channel sanitization as
> we change the order. Otherwise, this should not change behaviour.
I have a feeling we had some odd cases with the port A vs. port E, but I
think those were probably due to the non-VBT defaults for port A
smashing into the VBT provided values of port E.
So yeah, I think (or at least hope) that this is fine.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 104 +-
> 2 files changed, 59 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ff039750069d..eeeb0d9cfdcd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -946,6 +946,7 @@ struct ddi_vbt_port_info {
> #define HDMI_LEVEL_SHIFT_UNKNOWN 0xff
> u8 hdmi_level_shift;
>
> + u8 present:1;
> u8 supports_dvi:1;
> u8 supports_hdmi:1;
> u8 supports_dp:1;
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index b508d8a735e0..fc27ffe81c14 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1222,10 +1222,11 @@ static void sanitize_ddc_pin(struct drm_i915_private
> *dev_priv,
> if (!info->alternate_ddc_pin)
> return;
>
> - for_each_port_masked(p, (1 << port) - 1) {
> + for (p = PORT_A; p < I915_MAX_PORTS; p++) {
> struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
>
> - if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> + if (p == port || !i->present ||
> + info->alternate_ddc_pin != i->alternate_ddc_pin)
> continue;
>
> DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as
> port %c, "
> @@ -1239,8 +1240,8 @@ static void sanitize_ddc_pin(struct drm_i915_private
> *dev_priv,
>* port. Otherwise they share the same ddc bin and
>* system couldn't communicate with them separately.
>*
> - * Due to parsing the ports in alphabetical order,
> - * a higher port will always clobber a lower one.
> + * Due to parsing the ports in child device order,
> + * a later device will always clobber an earlier one.
>*/
> i->supports_dvi = false;
> i->supports_hdmi = false;
> @@ -1258,10 +1259,11 @@ static void sanitize_aux_ch(struct drm_i915_private
> *dev_priv,
> if (!info->alternate_aux_channel)
> return;
>
> - for_each_port_masked(p, (1 << port) - 1) {
> + for (p = PORT_A; p < I915_MAX_PORTS; p++) {
> struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
>
> - if (info->alternate_aux_channel != i->alternate_aux_channel)
> + if (p == port || !i->present ||
> + info->alternate_aux_channel != i->alternate_aux_channel)
> continue;
>
> DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as
> port %c, "
> @@ -1275,8 +1277,8 @@ static void sanitize_aux_ch(struct drm_i915_private
> *dev_priv,
>* port. Otherwise they share the same aux channel
>* and system couldn't communicate with them separately.
>*
> - * Due to parsing the ports in alphabetical order,
> - * a higher port will always clobber a lower one.
> + * Due to parsing the ports in child device order,
> + * a later device will always clobber an earlier one.
>*/
> i->supports_dp = false;
> i->alternate_aux_channel = 0;
> @@ -1324,49 +1326,58 @@ static u8 map_ddc_pin(struct drm_i915_private
> *dev_priv, u8 vbt_pin)
> return 0;
> }
>
> -static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
> -u8 bdb_version)
> +static enum port dvo_port_to_port(u8 dvo_port)
> {
> - struct child_device_config *it, *child = NULL;
> - struct ddi_vbt_port_info *info = _priv->vbt.ddi_port_info[port];
> - int i, j;
> - bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
> - /* Each DDI port can have more than one value on the "DVO Port" field,
> + /*
> + * Each DDI port can have more than one value on the "DVO Port" field,
>* so look for all the possible values for each port.
>*/
> - int dvo_ports[][3] = {
> -
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote: On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote: On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: >> Quoting Ville Syrjälä (2019-03-06 14:52:11) >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: >> > > Quoting Ville Syrjala (2019-03-05 19:29:05) >> > > > From: Ville Syrjälä >> > > > >> > > > At some point people have started to assume that >> > > > pipe_offsets[] & co. are only populated for pipes and whatnot >> > > > that actually exist. That is in fact not currently true, but >> > > > we can easily make it so. >> > > >> > > Any benefits of knock on effect? >> > >> > What kind of knock on effect we're thinking? >> >> Just wondering why people are eager to make the assumption that >> non-existent pipes are not set. I presume its to make code neater. >> >> i.e. why cater to their whims at all? > >Yeah, I guess this was done just to avoid having convoluted platform >checks all over. I've not checked the code to see if there are >more places where we could simplify the existing code by adopting >this approach. > >However now that you forced me to think a bit I realize that this >may break in the presence of fused off pipes. Not quite sure how >the registers for such fused off blocks would behave. If we aren't >allowed to touch those registers we'd need to move this stuff >into the runtime info. That feels a bit wasteful, so as an >alternative we could just add one or two bitmasks instead. > >Cc:ing Lucas who seems to the main offender here... humn.. is this about the EDP transcoder? Missing some context here. Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, even if it has? glancing over the possible mistake chv? :-/ Currently .trans_offsets[TRANSCODER_EDP] != 0 on _every_ platform. the commit was made to _allow_ platforms not to have the edp transcoder so we don't need to keep adding platform checks when the needs arrise. checking now that that probably broke chv though. Lucas De Marchi So using that to determine if a transcoder is present is not going to work. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/cml: Introduce Comet Lake PCH
On Tue, Mar 05, 2019 at 01:46:56PM -0800, Anusha wrote:
> From: Anusha Srivatsa
>
> Comet Lake PCH is based off of Cannon Point(CNP).
> Add PCI ID for Comet Lake PCH.
>
> v2: Code cleanup (DK)
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1b2f5a6f8c25..e787c999b2c6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -188,6 +188,10 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> unsigned short id)
> DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
> WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> return PCH_CNP;
> + case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Comet Lake LP PCH (CMP)\n");
> + WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
Please remove CNL from this list...
also please add a comment here before the return
/* CM has same south display engine from CNP */
> + return PCH_CNP;
> case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> DRM_DEBUG_KMS("Found Ice Lake PCH\n");
> WARN_ON(!IS_ICELAKE(dev_priv));
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 453af7438e67..55298e19e740 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -530,7 +530,7 @@ enum intel_pch {
> PCH_LPT,/* Lynxpoint/Wildcatpoint PCH */
> PCH_SPT,/* Sunrisepoint PCH */
> PCH_KBP,/* Kaby Lake PCH */
> - PCH_CNP,/* Cannon Lake PCH */
> + PCH_CNP,/* Cannon/Comet Lake PCH */
> PCH_ICP,/* Ice Lake PCH */
> PCH_NOP,/* PCH without south display */
> };
> @@ -2552,6 +2552,7 @@ static inline unsigned int i915_sg_segment_size(void)
> #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
> #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE 0x9D80
> +#define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
> --
> 2.21.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/cml: Add CML PCI IDS
On Tue, Mar 05, 2019 at 01:46:55PM -0800, Anusha wrote:
> From: Anusha Srivatsa
>
> Comet Lake is a Intel Processor containing Gen9
> Intel HD Graphics. This patch adds the initial set of
> PCI IDs. Comet Lake comes off of Coffee Lake - adding
> the IDs to Coffee Lake ID list.
>
> More support and features will be in the patches that follow.
>
> v2: Split IDs according to GT. (Rodrigo)
>
> Cc: Rodrigo Vivi
> Cc: Lucas De Marchi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> include/drm/i915_pciids.h | 31 ++-
> 2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index a9211c370cd1..63ca4ffcad8a 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -723,6 +723,8 @@ static const struct pci_device_id pciidlist[] = {
> INTEL_WHL_U_GT2_IDS(_coffeelake_gt2_info),
> INTEL_AML_CFL_GT2_IDS(_coffeelake_gt2_info),
> INTEL_WHL_U_GT3_IDS(_coffeelake_gt3_info),
> + INTEL_CML_GT1_IDS(_coffeelake_gt1_info),
> + INTEL_CML_GT2_IDS(_coffeelake_gt2_info),
I prefer the order that you added here, but this is not the currently
order in use. worth to sort WHL/AML with per-platform instead of per-gt?
> INTEL_CNL_IDS(_cannonlake_info),
> INTEL_ICL_11_IDS(_icelake_11_info),
> {0, 0, 0}
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index d2fad7b0fcf6..e9ed75ac8252 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -373,6 +373,34 @@
> #define INTEL_AML_CFL_GT2_IDS(info) \
> INTEL_VGA_DEVICE(0x87CA, info)
>
> +/* CML GT1 */
> +#define INTEL_CML_GT1_IDS(info) \
> + INTEL_VGA_DEVICE(0x9BA1, info), \
> + INTEL_VGA_DEVICE(0x9BAA, info), \
> + INTEL_VGA_DEVICE(0x9BAB, info), \
> + INTEL_VGA_DEVICE(0x9BAC, info), \
> + INTEL_VGA_DEVICE(0x9BA0, info), \
> + INTEL_VGA_DEVICE(0x9BA5, info), \
> + INTEL_VGA_DEVICE(0x9BA8, info), \
> + INTEL_VGA_DEVICE(0x9BA4, info), \
> + INTEL_VGA_DEVICE(0x9BA2, info)
> +
> +/* CML GT2 */
> +#define INTEL_CML_GT2_IDS(info) \
> + INTEL_VGA_DEVICE(0x9BC1, info), \
> + INTEL_VGA_DEVICE(0x9BCA, info), \
> + INTEL_VGA_DEVICE(0x9BCB, info), \
> + INTEL_VGA_DEVICE(0x9BCC, info), \
> + INTEL_VGA_DEVICE(0x9BC0, info), \
> + INTEL_VGA_DEVICE(0x9BC5, info), \
> + INTEL_VGA_DEVICE(0x9BC8, info), \
> + INTEL_VGA_DEVICE(0x9BC4, info), \
> + INTEL_VGA_DEVICE(0x9BC2, info)
would you believe me if I tell you the table changed again? :P
> +
> +#define INTEL_CML_IDS(info) \
> + INTEL_CML_GT1_IDS(info), \
> + INTEL_CML_GT2_IDS(info)
> +
> #define INTEL_KBL_IDS(info) \
> INTEL_KBL_GT1_IDS(info), \
> INTEL_KBL_GT2_IDS(info), \
> @@ -436,7 +464,8 @@
> INTEL_WHL_U_GT1_IDS(info), \
> INTEL_WHL_U_GT2_IDS(info), \
> INTEL_WHL_U_GT3_IDS(info), \
> - INTEL_AML_CFL_GT2_IDS(info)
> + INTEL_AML_CFL_GT2_IDS(info), \
> + INTEL_CML_IDS(info)
>
> /* CNL */
> #define INTEL_CNL_IDS(info) \
> --
> 2.21.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote: > On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote: > > On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: > > >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: > > >> Quoting Ville Syrjälä (2019-03-06 14:52:11) > > >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > > >> > > Quoting Ville Syrjala (2019-03-05 19:29:05) > > >> > > > From: Ville Syrjälä > > >> > > > > > >> > > > At some point people have started to assume that > > >> > > > pipe_offsets[] & co. are only populated for pipes and whatnot > > >> > > > that actually exist. That is in fact not currently true, but > > >> > > > we can easily make it so. > > >> > > > > >> > > Any benefits of knock on effect? > > >> > > > >> > What kind of knock on effect we're thinking? > > >> > > >> Just wondering why people are eager to make the assumption that > > >> non-existent pipes are not set. I presume its to make code neater. > > >> > > >> i.e. why cater to their whims at all? > > > > > >Yeah, I guess this was done just to avoid having convoluted platform > > >checks all over. I've not checked the code to see if there are > > >more places where we could simplify the existing code by adopting > > >this approach. > > > > > >However now that you forced me to think a bit I realize that this > > >may break in the presence of fused off pipes. Not quite sure how > > >the registers for such fused off blocks would behave. If we aren't > > >allowed to touch those registers we'd need to move this stuff > > >into the runtime info. That feels a bit wasteful, so as an > > >alternative we could just add one or two bitmasks instead. > > > > > >Cc:ing Lucas who seems to the main offender here... > > > > humn.. is this about the EDP transcoder? Missing some context here. > > Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, > > even if it has? glancing over the possible mistake chv? :-/ > > Currently .trans_offsets[TRANSCODER_EDP] != 0 on _every_ platform. > So using that to determine if a transcoder is present is not going > to work. So far the HAS_EDP_TRANSCODER() thing is not actually a problem as it's only called from the ddi code which guarantees that the transcoder is in fact present. But the error capture code is now very much wrong. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 07:55:33PM +0200, Ville Syrjälä wrote: > On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote: > > On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: > > >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: > > >> Quoting Ville Syrjälä (2019-03-06 14:52:11) > > >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > > >> > > Quoting Ville Syrjala (2019-03-05 19:29:05) > > >> > > > From: Ville Syrjälä > > >> > > > > > >> > > > At some point people have started to assume that > > >> > > > pipe_offsets[] & co. are only populated for pipes and whatnot > > >> > > > that actually exist. That is in fact not currently true, but > > >> > > > we can easily make it so. > > >> > > > > >> > > Any benefits of knock on effect? > > >> > > > >> > What kind of knock on effect we're thinking? > > >> > > >> Just wondering why people are eager to make the assumption that > > >> non-existent pipes are not set. I presume its to make code neater. > > >> > > >> i.e. why cater to their whims at all? > > > > > >Yeah, I guess this was done just to avoid having convoluted platform > > >checks all over. I've not checked the code to see if there are > > >more places where we could simplify the existing code by adopting > > >this approach. > > > > > >However now that you forced me to think a bit I realize that this > > >may break in the presence of fused off pipes. Not quite sure how > > >the registers for such fused off blocks would behave. If we aren't > > >allowed to touch those registers we'd need to move this stuff > > >into the runtime info. That feels a bit wasteful, so as an > > >alternative we could just add one or two bitmasks instead. > > > > > >Cc:ing Lucas who seems to the main offender here... > > > > humn.. is this about the EDP transcoder? Missing some context here. > > Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, > > even if it has? glancing over the possible mistake chv? :-/ > > Currently .trans_offsets[TRANSCODER_EDP] != 0 on _every_ platform. > So using that to determine if a transcoder is present is not going > to work. Make that "every platform excep chv". -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 09:42:57AM -0800, Lucas De Marchi wrote: > On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: > >On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: > >> Quoting Ville Syrjälä (2019-03-06 14:52:11) > >> > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > >> > > Quoting Ville Syrjala (2019-03-05 19:29:05) > >> > > > From: Ville Syrjälä > >> > > > > >> > > > At some point people have started to assume that > >> > > > pipe_offsets[] & co. are only populated for pipes and whatnot > >> > > > that actually exist. That is in fact not currently true, but > >> > > > we can easily make it so. > >> > > > >> > > Any benefits of knock on effect? > >> > > >> > What kind of knock on effect we're thinking? > >> > >> Just wondering why people are eager to make the assumption that > >> non-existent pipes are not set. I presume its to make code neater. > >> > >> i.e. why cater to their whims at all? > > > >Yeah, I guess this was done just to avoid having convoluted platform > >checks all over. I've not checked the code to see if there are > >more places where we could simplify the existing code by adopting > >this approach. > > > >However now that you forced me to think a bit I realize that this > >may break in the presence of fused off pipes. Not quite sure how > >the registers for such fused off blocks would behave. If we aren't > >allowed to touch those registers we'd need to move this stuff > >into the runtime info. That feels a bit wasteful, so as an > >alternative we could just add one or two bitmasks instead. > > > >Cc:ing Lucas who seems to the main offender here... > > humn.. is this about the EDP transcoder? Missing some context here. > Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, > even if it has? glancing over the possible mistake chv? :-/ Currently .trans_offsets[TRANSCODER_EDP] != 0 on _every_ platform. So using that to determine if a transcoder is present is not going to work. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/bios: parse ddi ports also on VLV
On Wed, Mar 06, 2019 at 05:34:16PM +0200, Jani Nikula wrote: > The main benefit is improved debug logging of the ports also on VLV. The fact that this causes VLV to start using the AUX/DDC pins from VBT needs to be called out in the commit msg. > > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_bios.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index 9beff569b010..030a5e9c67b3 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1514,7 +1514,8 @@ static void parse_ddi_ports(struct drm_i915_private > *dev_priv, u8 bdb_version) > const struct child_device_config *child; > int i; > > - if (!HAS_DDI(dev_priv) && !IS_CHERRYVIEW(dev_priv)) > + if (!HAS_DDI(dev_priv) && > + !IS_CHERRYVIEW(dev_priv) && !IS_VALLEYVIEW(dev_priv)) > return; > > if (bdb_version < 155) > -- > 2.20.1 -- Ville Syrjälä Intel ___ 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/selftests: Canonicalise gen8 addresses (rev2)
Quoting Patchwork (2019-03-06 17:38:42) > * igt@i915_selftest@live_contexts: > - fi-icl-u3: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569] Still no luck with that fix, then? It's just the one fix actually. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/bios: parse dsi devices in parse_ddi_ports()
On Wed, Mar 06, 2019 at 05:34:15PM +0200, Jani Nikula wrote:
> For the time being this is only for completeness and better debug
> logging of DSI ports.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_bios.c | 14 --
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index eeeb0d9cfdcd..e14563418aad 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -951,6 +951,7 @@ struct ddi_vbt_port_info {
> u8 supports_hdmi:1;
> u8 supports_dp:1;
> u8 supports_edp:1;
> + u8 supports_dsi:1;
> u8 supports_typec_usb:1;
> u8 supports_tbt:1;
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index fc27ffe81c14..9beff569b010 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1333,9 +1333,9 @@ static enum port dvo_port_to_port(u8 dvo_port)
>* so look for all the possible values for each port.
>*/
> static const int dvo_ports[][3] = {
> - [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
> - [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
> - [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
> + [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, DVO_PORT_MIPIA },
> + [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, DVO_PORT_MIPIB },
> + [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, DVO_PORT_MIPIC },
I wonder if this is going to end up badly on CHV...
> [PORT_D] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1},
> [PORT_E] = { DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
> [PORT_F] = { DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
> @@ -1361,7 +1361,7 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv,
> u8 bdb_version)
> {
> struct ddi_vbt_port_info *info;
> - bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
> + bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, is_dsi;
> enum port port;
>
> port = dvo_port_to_port(child->dvo_port);
> @@ -1383,6 +1383,7 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv,
> is_crt = child->device_type & DEVICE_TYPE_ANALOG_OUTPUT;
> is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT)
> == 0;
> is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
> + is_dsi = child->device_type & DEVICE_TYPE_MIPI_OUTPUT;
>
> if (port == PORT_A && is_dvi) {
> DRM_DEBUG_KMS("VBT claims port A supports DVI%s, ignoring\n",
> @@ -1395,6 +1396,7 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv,
> info->supports_hdmi = is_hdmi;
> info->supports_dp = is_dp;
> info->supports_edp = is_edp;
> + info->supports_dsi = is_dsi;
>
> if (bdb_version >= 195)
> info->supports_typec_usb = child->dp_usb_type_c;
> @@ -1402,8 +1404,8 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv,
> if (bdb_version >= 209)
> info->supports_tbt = child->tbt;
>
> - DRM_DEBUG_KMS("Port %c VBT info: DP:%d HDMI:%d DVI:%d EDP:%d CRT:%d
> TCUSB:%d TBT:%d\n",
> - port_name(port), is_dp, is_hdmi, is_dvi, is_edp, is_crt,
> + DRM_DEBUG_KMS("Port %c VBT info: DP:%d HDMI:%d DVI:%d EDP:%d DSI:%d
> CRT:%d TCUSB:%d TBT:%d\n",
> + port_name(port), is_dp, is_hdmi, is_dvi, is_edp, is_dsi,
> is_crt,
> info->supports_typec_usb, info->supports_tbt);
>
> if (is_edp && is_dvi)
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 05:13:39PM +0200, Ville Syrjälä wrote: On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: Quoting Ville Syrjälä (2019-03-06 14:52:11) > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > > Quoting Ville Syrjala (2019-03-05 19:29:05) > > > From: Ville Syrjälä > > > > > > At some point people have started to assume that > > > pipe_offsets[] & co. are only populated for pipes and whatnot > > > that actually exist. That is in fact not currently true, but > > > we can easily make it so. > > > > Any benefits of knock on effect? > > What kind of knock on effect we're thinking? Just wondering why people are eager to make the assumption that non-existent pipes are not set. I presume its to make code neater. i.e. why cater to their whims at all? Yeah, I guess this was done just to avoid having convoluted platform checks all over. I've not checked the code to see if there are more places where we could simplify the existing code by adopting this approach. However now that you forced me to think a bit I realize that this may break in the presence of fused off pipes. Not quite sure how the registers for such fused off blocks would behave. If we aren't allowed to touch those registers we'd need to move this stuff into the runtime info. That feels a bit wasteful, so as an alternative we could just add one or two bitmasks instead. Cc:ing Lucas who seems to the main offender here... humn.. is this about the EDP transcoder? Missing some context here. Did I miss any platform not setting trans_offsets for TRANSCODER_EDP, even if it has? glancing over the possible mistake chv? :-/ Lucas De Marchi -- Ville Syrjälä Intel ___ 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/selftests: Canonicalise gen8 addresses (rev2)
== Series Details == Series: drm/i915/selftests: Canonicalise gen8 addresses (rev2) URL : https://patchwork.freedesktop.org/series/57645/ State : success == Summary == CI Bug Log - changes from CI_DRM_5712 -> Patchwork_12396 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/57645/revisions/2/mbox/ Known issues Here are the changes found in Patchwork_12396 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: PASS -> SKIP [fdo#109271] * igt@i915_pm_rpm@basic-rte: - fi-bsw-kefka: PASS -> FAIL [fdo#108800] * igt@kms_busy@basic-flip-b: - fi-gdg-551: PASS -> FAIL [fdo#103182] * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#107362] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1 Possible fixes * igt@i915_pm_rpm@module-reload: - fi-kbl-7560u: CRASH -> PASS * igt@i915_selftest@live_hangcheck: - fi-kbl-7560u: INCOMPLETE [fdo#108044] / [fdo#108744] -> PASS * igt@kms_busy@basic-flip-a: - fi-gdg-551: FAIL [fdo#103182] -> PASS Warnings * igt@i915_selftest@live_contexts: - fi-icl-u3: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569] [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#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108044]: https://bugs.freedesktop.org/show_bug.cgi?id=108044 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 Participating hosts (45 -> 40) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 Build changes - * Linux: CI_DRM_5712 -> Patchwork_12396 CI_DRM_5712: 5d4de376b9a03c2f74e049ee6a8221df96687ba0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4875: 91908d36d0d5c90eea86e29736d2748d5ec55335 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12396: 7d5bc8a26b168a0480ca17ba0c2af3c8f34b99ff @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 7d5bc8a26b16 drm/i915/selftests: Canonicalise gen8 addresses == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12396/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/43] drm/i915: Move shmem object setup to its own file
Quoting Matthew Auld (2019-03-06 17:05:47)
> On 06/03/2019 14:25, Chris Wilson wrote:
> > Split the plain old shmem object into its own file to start decluttering
> > i915_gem.c
> >
> > Signed-off-by: Chris Wilson
>
> [snip]
>
> > +
> > +const struct drm_i915_gem_object_ops i915_gem_shmem_ops = {
> > + .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
> > + I915_GEM_OBJECT_IS_SHRINKABLE,
> > +
> > + .get_pages = shmem_get_pages_gtt,
> > + .put_pages = shmem_put_pages_gtt,
> > +
> > + .pwrite = shmem_pwrite_gtt,
>
> I never really understood the _gtt thing here...maybe because of the
> prepare_gtt?
Historical accident, and prepare_gtt is pretty much the reason why, but
mostly I recall it being !phys. I guess now would be a perfect time to
add a drop of consistency and drop the _gtt suffix.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/43] drm/i915: Move shmem object setup to its own file
On 06/03/2019 14:25, Chris Wilson wrote:
Split the plain old shmem object into its own file to start decluttering
i915_gem.c
Signed-off-by: Chris Wilson
[snip]
+
+const struct drm_i915_gem_object_ops i915_gem_shmem_ops = {
+ .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
+I915_GEM_OBJECT_IS_SHRINKABLE,
+
+ .get_pages = shmem_get_pages_gtt,
+ .put_pages = shmem_put_pages_gtt,
+
+ .pwrite = shmem_pwrite_gtt,
I never really understood the _gtt thing here...maybe because of the
prepare_gtt?
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: failure for drm/i915/bios: ddi port parsing changes
== Series Details == Series: drm/i915/bios: ddi port parsing changes URL : https://patchwork.freedesktop.org/series/57651/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5712 -> Patchwork_12395 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12395 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12395, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/57651/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12395: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - fi-kbl-7560u: PASS -> INCOMPLETE Known issues Here are the changes found in Patchwork_12395 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_basic@readonly-bsd2: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] +76 * igt@kms_busy@basic-flip-b: - fi-gdg-551: PASS -> FAIL [fdo#103182] * igt@kms_busy@basic-flip-c: - fi-pnv-d510:NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: PASS -> FAIL [fdo#103167] * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] [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#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 Participating hosts (45 -> 40) -- Additional (1): fi-pnv-d510 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-lmem Build changes - * Linux: CI_DRM_5712 -> Patchwork_12395 CI_DRM_5712: 5d4de376b9a03c2f74e049ee6a8221df96687ba0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4875: 91908d36d0d5c90eea86e29736d2748d5ec55335 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12395: 24aa5327f54f0d3d4dbfaed57d4b92a7b2d9d5a1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 24aa5327f54f drm/i915/bios: parse ddi ports also on VLV dc783312f4fe drm/i915/bios: parse dsi devices in parse_ddi_ports() 0542ee4a7b9f drm/i915/bios: iterate over child devices to initialize ddi_port_info == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12395/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/43] drm/i915: Move object->pages API to i915_gem_object.[ch]
Quoting Matthew Auld (2019-03-06 16:23:19)
> On 06/03/2019 14:25, Chris Wilson wrote:
> > Currently the code for manipulating the pages on an object is still
> > residing in i915_gem.c, move it to i915_gem_object.c
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/Makefile | 3 +-
> > .../gpu/drm/i915/{ => gem}/i915_gem_object.c | 3 +-
> > .../gpu/drm/i915/{ => gem}/i915_gem_object.h | 119 +++-
> > .../gem/test_i915_gem_object_standalone.c | 7 +
> > drivers/gpu/drm/i915/i915_drv.h | 129 +-
> > drivers/gpu/drm/i915/i915_globals.c | 2 +-
> > drivers/gpu/drm/i915/i915_vma.h | 2 +-
> > 7 files changed, 137 insertions(+), 128 deletions(-)
> > rename drivers/gpu/drm/i915/{ => gem}/i915_gem_object.c (99%)
> > rename drivers/gpu/drm/i915/{ => gem}/i915_gem_object.h (60%)
> > create mode 100644
> > drivers/gpu/drm/i915/gem/test_i915_gem_object_standalone.c
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > index 2f84fac02578..d270f01e1091 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -60,6 +60,7 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
> > # Test the headers are compilable as standalone units
> > i915-$(CONFIG_DRM_I915_WERROR) += \
> > gem/test_i915_gem_ioctls_standalone.o \
> > + gem/test_i915_gem_object_standalone.o \
> > gem/test_i915_gem_object_types_standalone.o \
> > test_i915_active_types_standalone.o \
> > test_i915_gem_context_types_standalone.o \
> > @@ -70,6 +71,7 @@ i915-$(CONFIG_DRM_I915_WERROR) += \
> >
> > # GEM code
> > i915-y += \
> > + gem/i915_gem_object.o \
> > i915_active.o \
> > i915_cmd_parser.o \
> > i915_gem_batch_pool.o \
> > @@ -82,7 +84,6 @@ i915-y += \
> > i915_gem_gtt.o \
> > i915_gem_internal.o \
> > i915_gem.o \
> > - i915_gem_object.o \
> > i915_gem_render_state.o \
> > i915_gem_shrinker.o \
> > i915_gem_stolen.o \
> > diff --git a/drivers/gpu/drm/i915/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > similarity index 99%
> > rename from drivers/gpu/drm/i915/i915_gem_object.c
> > rename to drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index ac6a5ab84586..93f4d92c9909 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -22,10 +22,11 @@
> >*
> >*/
> >
> > -#include "i915_drv.h"
> > #include "i915_gem_object.h"
> > #include "i915_globals.h"
> >
> > +#include "../i915_drv.h"
>
> #include "../i915_globals.h" ?
Yes. For some reason #include "" handling differs between my machines.,
yet they all have gcc 8.3, and it happens to compile happily on my build
machine (and CI) but fails on the test boxen. Weird. The ugly ".." at
least serves as a reminder about what needs to be weeded out.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/43] drm/i915: Move object->pages API to i915_gem_object.[ch]
On 06/03/2019 14:25, Chris Wilson wrote:
Currently the code for manipulating the pages on an object is still
residing in i915_gem.c, move it to i915_gem_object.c
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Makefile | 3 +-
.../gpu/drm/i915/{ => gem}/i915_gem_object.c | 3 +-
.../gpu/drm/i915/{ => gem}/i915_gem_object.h | 119 +++-
.../gem/test_i915_gem_object_standalone.c | 7 +
drivers/gpu/drm/i915/i915_drv.h | 129 +-
drivers/gpu/drm/i915/i915_globals.c | 2 +-
drivers/gpu/drm/i915/i915_vma.h | 2 +-
7 files changed, 137 insertions(+), 128 deletions(-)
rename drivers/gpu/drm/i915/{ => gem}/i915_gem_object.c (99%)
rename drivers/gpu/drm/i915/{ => gem}/i915_gem_object.h (60%)
create mode 100644 drivers/gpu/drm/i915/gem/test_i915_gem_object_standalone.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2f84fac02578..d270f01e1091 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -60,6 +60,7 @@ i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
# Test the headers are compilable as standalone units
i915-$(CONFIG_DRM_I915_WERROR) += \
gem/test_i915_gem_ioctls_standalone.o \
+ gem/test_i915_gem_object_standalone.o \
gem/test_i915_gem_object_types_standalone.o \
test_i915_active_types_standalone.o \
test_i915_gem_context_types_standalone.o \
@@ -70,6 +71,7 @@ i915-$(CONFIG_DRM_I915_WERROR) += \
# GEM code
i915-y += \
+ gem/i915_gem_object.o \
i915_active.o \
i915_cmd_parser.o \
i915_gem_batch_pool.o \
@@ -82,7 +84,6 @@ i915-y += \
i915_gem_gtt.o \
i915_gem_internal.o \
i915_gem.o \
- i915_gem_object.o \
i915_gem_render_state.o \
i915_gem_shrinker.o \
i915_gem_stolen.o \
diff --git a/drivers/gpu/drm/i915/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
similarity index 99%
rename from drivers/gpu/drm/i915/i915_gem_object.c
rename to drivers/gpu/drm/i915/gem/i915_gem_object.c
index ac6a5ab84586..93f4d92c9909 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -22,10 +22,11 @@
*
*/
-#include "i915_drv.h"
#include "i915_gem_object.h"
#include "i915_globals.h"
+#include "../i915_drv.h"
#include "../i915_globals.h" ?
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: failure for series starting with [01/43] drm/i915/selftests: Canonicalise gen8 addresses
== Series Details == Series: series starting with [01/43] drm/i915/selftests: Canonicalise gen8 addresses URL : https://patchwork.freedesktop.org/series/57646/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5711 -> Patchwork_12394 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12394 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12394, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/57646/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12394: ### IGT changes ### Possible regressions * igt@i915_selftest@live_contexts: - fi-bdw-5557u: PASS -> INCOMPLETE - fi-kbl-guc: PASS -> INCOMPLETE - fi-kbl-r: PASS -> INCOMPLETE - fi-skl-6260u: PASS -> INCOMPLETE - fi-kbl-8809g: PASS -> INCOMPLETE - fi-skl-6770hq: PASS -> INCOMPLETE - fi-cfl-guc: PASS -> INCOMPLETE - fi-kbl-x1275: PASS -> INCOMPLETE - fi-skl-6700k2: PASS -> INCOMPLETE - fi-cfl-8700k: PASS -> INCOMPLETE - fi-skl-6600u: PASS -> INCOMPLETE - fi-whl-u: PASS -> INCOMPLETE - fi-skl-guc: PASS -> INCOMPLETE - fi-kbl-7567u: PASS -> INCOMPLETE - fi-cfl-8109u: PASS -> INCOMPLETE * igt@runner@aborted: - fi-bdw-gvtdvm: NOTRUN -> FAIL - fi-cfl-8109u: NOTRUN -> FAIL - fi-bxt-j4205: NOTRUN -> FAIL - fi-whl-u: NOTRUN -> FAIL - fi-kbl-7560u: NOTRUN -> FAIL - fi-cfl-guc: NOTRUN -> FAIL - fi-kbl-7567u: NOTRUN -> FAIL - fi-kbl-x1275: NOTRUN -> FAIL - fi-cfl-8700k: NOTRUN -> FAIL - fi-kbl-8809g: NOTRUN -> FAIL - fi-apl-guc: NOTRUN -> FAIL - fi-kbl-r: NOTRUN -> FAIL - fi-bdw-5557u: NOTRUN -> FAIL - fi-kbl-guc: NOTRUN -> FAIL New tests - New tests have been introduced between CI_DRM_5711 and Patchwork_12394: ### New IGT tests (1) ### * igt@i915_selftest@live_mman: - Statuses : 27 pass(s) - Exec time: [5.65, 81.50] s Known issues Here are the changes found in Patchwork_12394 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-sdma: - fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +17 * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718] * igt@i915_selftest@live_contexts: - fi-bxt-j4205: PASS -> INCOMPLETE [fdo#103927] - fi-bdw-gvtdvm: PASS -> INCOMPLETE [fdo#105600] - fi-skl-gvtdvm: PASS -> INCOMPLETE [fdo#105600] - fi-apl-guc: PASS -> INCOMPLETE [fdo#103927] - fi-kbl-7560u: NOTRUN -> INCOMPLETE [fdo#108767] * igt@runner@aborted: - fi-skl-guc: NOTRUN -> FAIL [fdo#104108] - fi-skl-6700k2: NOTRUN -> FAIL [fdo#104108] - fi-skl-6600u: NOTRUN -> FAIL [fdo#104108] - fi-skl-6770hq: NOTRUN -> FAIL [fdo#104108] - fi-skl-gvtdvm: NOTRUN -> FAIL [fdo#104108] - fi-skl-6260u: NOTRUN -> FAIL [fdo#104108] Possible fixes * igt@i915_module_load@reload-with-fault-injection: - fi-kbl-7560u: INCOMPLETE [fdo#109831] -> PASS * igt@prime_vgem@basic-fence-flip: - fi-gdg-551: FAIL [fdo#103182] -> PASS [fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108 [fdo#105600]: https://bugs.freedesktop.org/show_bug.cgi?id=105600 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109831]: https://bugs.freedesktop.org/show_bug.cgi?id=109831 Participating hosts (46 -> 30) -- Missing(16): fi-hsw-4770r fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-hsw-peppy fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-snb-2520m fi-hsw-4770 fi-ivb-3770 fi-pnv-d510 fi-ivb-3520m fi-byt-n2820 fi-byt-clapper fi-snb-2600 Build changes - * Linux: CI_DRM_5711 -> Patchwork_12394 CI_DRM_5711: 221f1aafa4d61ada2b5693b88454d75b825bee0c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4873: f273b14e5e963195d7b2278693c361aec67abeac @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12394: 1436f6156861c2108e3e2a15e841fb34991d2c93 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1436f6156861
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/bios: ddi port parsing changes
== Series Details == Series: drm/i915/bios: ddi port parsing changes URL : https://patchwork.freedesktop.org/series/57651/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/bios: iterate over child devices to initialize ddi_port_info -drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3549:16: warning: expression using sizeof(void) Commit: drm/i915/bios: parse dsi devices in parse_ddi_ports() -drivers/gpu/drm/i915/selftests/../i915_drv.h:3549:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3550:16: warning: expression using sizeof(void) Commit: drm/i915/bios: parse ddi ports also on VLV Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 30/43] drm/i915: Pull GEM ioctls interface to its own file
On 06/03/2019 14:25, Chris Wilson wrote: Declutter i915_gem.h by moving the ioctl API into its own header. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Canonicalise gen8 addresses
For igt_vm_isolation, we write into the whole 48b address space, and not
just our usual low 4G of global GTT. For these MI operations, play safe
and ensure we use the canonical address form.
v2: Leave original offset unmolested as we use that for our CPU pointer
offset
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c| 19 -
drivers/gpu/drm/i915/intel_gpu_commands.h | 21 +++
.../gpu/drm/i915/selftests/i915_gem_context.c | 12 +++
3 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 943a221acb21..c335c0a4099a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -289,25 +289,6 @@ struct i915_execbuffer {
#define exec_entry(EB, VMA) (&(EB)->exec[(VMA)->exec_flags - (EB)->flags])
-/*
- * Used to convert any address to canonical form.
- * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
- * MI_LOAD_REGISTER_MEM and others, see Broadwell PRM Vol2a) require the
- * addresses to be in a canonical form:
- * "GraphicsAddress[63:48] are ignored by the HW and assumed to be in correct
- * canonical form [63:48] == [47]."
- */
-#define GEN8_HIGH_ADDRESS_BIT 47
-static inline u64 gen8_canonical_addr(u64 address)
-{
- return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
-}
-
-static inline u64 gen8_noncanonical_addr(u64 address)
-{
- return address & GENMASK_ULL(GEN8_HIGH_ADDRESS_BIT, 0);
-}
-
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
{
return intel_engine_needs_cmd_parser(eb->engine) && eb->batch_len;
diff --git a/drivers/gpu/drm/i915/intel_gpu_commands.h
b/drivers/gpu/drm/i915/intel_gpu_commands.h
index a34ece53a771..b017bc928d00 100644
--- a/drivers/gpu/drm/i915/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/intel_gpu_commands.h
@@ -7,6 +7,8 @@
#ifndef _INTEL_GPU_COMMANDS_H_
#define _INTEL_GPU_COMMANDS_H_
+#include
+
/*
* Instruction field definitions used by the command parser
*/
@@ -275,4 +277,23 @@
#define COLOR_BLT ((0x2<<29)|(0x40<<22))
#define SRC_COPY_BLT ((0x2<<29)|(0x43<<22))
+/*
+ * Used to convert any address to canonical form.
+ * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
+ * MI_LOAD_REGISTER_MEM and others, see Broadwell PRM Vol2a) require the
+ * addresses to be in a canonical form:
+ * "GraphicsAddress[63:48] are ignored by the HW and assumed to be in correct
+ * canonical form [63:48] == [47]."
+ */
+#define GEN8_HIGH_ADDRESS_BIT 47
+static inline u64 gen8_canonical_addr(u64 address)
+{
+ return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
+}
+
+static inline u64 gen8_noncanonical_addr(u64 address)
+{
+ return address & GENMASK_ULL(GEN8_HIGH_ADDRESS_BIT, 0);
+}
+
#endif /* _INTEL_GPU_COMMANDS_H_ */
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 0346ff224d5d..25cb431824da 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -1194,8 +1194,10 @@ static int write_to_scratch(struct i915_gem_context *ctx,
*cmd++ = MI_STORE_DWORD_IMM_GEN4;
if (INTEL_GEN(i915) >= 8) {
- *cmd++ = lower_32_bits(offset);
- *cmd++ = upper_32_bits(offset);
+ u64 addr = gen8_canonical_addr(offset);
+
+ *cmd++ = lower_32_bits(addr);
+ *cmd++ = upper_32_bits(addr);
} else {
*cmd++ = 0;
*cmd++ = offset;
@@ -1282,10 +1284,12 @@ static int read_from_scratch(struct i915_gem_context
*ctx,
memset(cmd, POISON_INUSE, PAGE_SIZE);
if (INTEL_GEN(i915) >= 8) {
+ u64 addr = gen8_canonical_addr(offset);
+
*cmd++ = MI_LOAD_REGISTER_MEM_GEN8;
*cmd++ = RCS_GPR0;
- *cmd++ = lower_32_bits(offset);
- *cmd++ = upper_32_bits(offset);
+ *cmd++ = lower_32_bits(addr);
+ *cmd++ = upper_32_bits(addr);
*cmd++ = MI_STORE_REGISTER_MEM_GEN8;
*cmd++ = RCS_GPR0;
*cmd++ = result;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 22/43] drm/i915: Introduce intel_context.pin_mutex for pin management
On 06/03/2019 14:51, Chris Wilson wrote: Quoting Tvrtko Ursulin (2019-03-06 14:43:13) On 06/03/2019 14:24, Chris Wilson wrote: Introduce a mutex to start locking the HW contexts independently of struct_mutex, with a view to reducing the coarse struct_mutex. The intel_context.pin_mutex is used to guard the transition to and from being pinned on the gpu, and so is required before starting to build any request. The intel_context will then remain pinned until the request completes, but the mutex can be released immediately unpin completion of pinning the context. A slight variant of the above is used by per-context sseu that wants to inspect the pinned status of the context, and requires that it remains stable (either !pinned or pinned) across its operation. By using the pin_mutex to serialise operations while pin_count==0, we can take that pin_mutex for stabilise the boolean pin status. Change log! v2: no code changes, or at least I can only remember rewriting the commitmsg, so see above. v2: * Improved commit message. * Dropped _gpu suffix from gen8_modify_rpcs_gpu. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 29/43] drm/i915: Split GEM object type definition to its own header
On 06/03/2019 14:25, Chris Wilson wrote: For convenience in avoiding inline spaghetti, keep the type definition as a separate header. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ 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/selftests: Canonicalise gen8 addresses
Quoting Patchwork (2019-03-06 15:42:32) > == Series Details == > > Series: drm/i915/selftests: Canonicalise gen8 addresses > URL : https://patchwork.freedesktop.org/series/57645/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_5711 -> Patchwork_12393 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12393 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12393, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/57645/revisions/1/mbox/ > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_12393: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live_contexts: > - fi-bdw-5557u: PASS -> INCOMPLETE > - fi-kbl-guc: PASS -> INCOMPLETE > - fi-kbl-r: PASS -> INCOMPLETE > - fi-skl-6260u: PASS -> INCOMPLETE > - fi-kbl-8809g: PASS -> INCOMPLETE > - fi-skl-6770hq: PASS -> INCOMPLETE > - fi-cfl-guc: PASS -> INCOMPLETE > - fi-kbl-x1275: PASS -> INCOMPLETE > - fi-skl-6700k2: PASS -> INCOMPLETE > - fi-cfl-8700k: PASS -> INCOMPLETE > - fi-skl-6600u: PASS -> INCOMPLETE > - fi-whl-u: PASS -> INCOMPLETE > - fi-skl-guc: PASS -> INCOMPLETE > - fi-kbl-7567u: PASS -> INCOMPLETE > - fi-cfl-8109u: PASS -> INCOMPLETE <3> [454.630961] check_scratch:1165 GEM_BUG_ON(offset >= node->start + node->size) The offset wasn't as local as I thought. -Chris ___ 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/selftests: Canonicalise gen8 addresses
== Series Details ==
Series: drm/i915/selftests: Canonicalise gen8 addresses
URL : https://patchwork.freedesktop.org/series/57645/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5711 -> Patchwork_12393
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12393 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12393, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57645/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12393:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_contexts:
- fi-bdw-5557u: PASS -> INCOMPLETE
- fi-kbl-guc: PASS -> INCOMPLETE
- fi-kbl-r: PASS -> INCOMPLETE
- fi-skl-6260u: PASS -> INCOMPLETE
- fi-kbl-8809g: PASS -> INCOMPLETE
- fi-skl-6770hq: PASS -> INCOMPLETE
- fi-cfl-guc: PASS -> INCOMPLETE
- fi-kbl-x1275: PASS -> INCOMPLETE
- fi-skl-6700k2: PASS -> INCOMPLETE
- fi-cfl-8700k: PASS -> INCOMPLETE
- fi-skl-6600u: PASS -> INCOMPLETE
- fi-whl-u: PASS -> INCOMPLETE
- fi-skl-guc: PASS -> INCOMPLETE
- fi-kbl-7567u: PASS -> INCOMPLETE
- fi-cfl-8109u: PASS -> INCOMPLETE
* igt@runner@aborted:
- fi-bdw-gvtdvm: NOTRUN -> FAIL
- fi-cfl-8109u: NOTRUN -> FAIL
- fi-bxt-j4205: NOTRUN -> FAIL
- fi-whl-u: NOTRUN -> FAIL
- fi-kbl-7560u: NOTRUN -> FAIL
- fi-cfl-guc: NOTRUN -> FAIL
- fi-kbl-7567u: NOTRUN -> FAIL
- fi-kbl-x1275: NOTRUN -> FAIL
- fi-cfl-8700k: NOTRUN -> FAIL
- fi-kbl-8809g: NOTRUN -> FAIL
- fi-apl-guc: NOTRUN -> FAIL
- fi-kbl-r: NOTRUN -> FAIL
- fi-bdw-5557u: NOTRUN -> FAIL
- fi-kbl-guc: NOTRUN -> FAIL
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_contexts:
- {fi-skl-lmem}: NOTRUN -> INCOMPLETE
Known issues
Here are the changes found in Patchwork_12393 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7560u: NOTRUN -> SKIP [fdo#109271] +17
* igt@i915_selftest@live_contexts:
- fi-bxt-j4205: PASS -> INCOMPLETE [fdo#103927]
- fi-bdw-gvtdvm: PASS -> INCOMPLETE [fdo#105600]
- fi-skl-gvtdvm: PASS -> INCOMPLETE [fdo#105600]
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
- fi-kbl-7560u: NOTRUN -> INCOMPLETE [fdo#108767]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@runner@aborted:
- fi-skl-guc: NOTRUN -> FAIL [fdo#104108]
- fi-skl-6700k2: NOTRUN -> FAIL [fdo#104108]
- fi-skl-6600u: NOTRUN -> FAIL [fdo#104108]
- fi-skl-6770hq: NOTRUN -> FAIL [fdo#104108]
- fi-skl-gvtdvm: NOTRUN -> FAIL [fdo#104108]
- fi-skl-6260u: NOTRUN -> FAIL [fdo#104108]
Possible fixes
* igt@i915_module_load@reload-with-fault-injection:
- fi-kbl-7560u: INCOMPLETE [fdo#109831] -> PASS
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[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#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#105600]: https://bugs.freedesktop.org/show_bug.cgi?id=105600
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109831]: https://bugs.freedesktop.org/show_bug.cgi?id=109831
Participating hosts (46 -> 40)
--
Additional (1): fi-skl-lmem
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan
fi-icl-u3 fi-ivb-3520m
Build changes
-
* Linux: CI_DRM_5711 -> Patchwork_12393
CI_DRM_5711: 221f1aafa4d61ada2b5693b88454d75b825bee0c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4873: f273b14e5e963195d7b2278693c361aec67abeac @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
[Intel-gfx] [PATCH 2/3] drm/i915/bios: parse dsi devices in parse_ddi_ports()
For the time being this is only for completeness and better debug
logging of DSI ports.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 14 --
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eeeb0d9cfdcd..e14563418aad 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -951,6 +951,7 @@ struct ddi_vbt_port_info {
u8 supports_hdmi:1;
u8 supports_dp:1;
u8 supports_edp:1;
+ u8 supports_dsi:1;
u8 supports_typec_usb:1;
u8 supports_tbt:1;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index fc27ffe81c14..9beff569b010 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1333,9 +1333,9 @@ static enum port dvo_port_to_port(u8 dvo_port)
* so look for all the possible values for each port.
*/
static const int dvo_ports[][3] = {
- [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
- [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
- [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
+ [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, DVO_PORT_MIPIA },
+ [PORT_B] = { DVO_PORT_HDMIB, DVO_PORT_DPB, DVO_PORT_MIPIB },
+ [PORT_C] = { DVO_PORT_HDMIC, DVO_PORT_DPC, DVO_PORT_MIPIC },
[PORT_D] = { DVO_PORT_HDMID, DVO_PORT_DPD, -1},
[PORT_E] = { DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
[PORT_F] = { DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
@@ -1361,7 +1361,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv,
u8 bdb_version)
{
struct ddi_vbt_port_info *info;
- bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
+ bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, is_dsi;
enum port port;
port = dvo_port_to_port(child->dvo_port);
@@ -1383,6 +1383,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv,
is_crt = child->device_type & DEVICE_TYPE_ANALOG_OUTPUT;
is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT)
== 0;
is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
+ is_dsi = child->device_type & DEVICE_TYPE_MIPI_OUTPUT;
if (port == PORT_A && is_dvi) {
DRM_DEBUG_KMS("VBT claims port A supports DVI%s, ignoring\n",
@@ -1395,6 +1396,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv,
info->supports_hdmi = is_hdmi;
info->supports_dp = is_dp;
info->supports_edp = is_edp;
+ info->supports_dsi = is_dsi;
if (bdb_version >= 195)
info->supports_typec_usb = child->dp_usb_type_c;
@@ -1402,8 +1404,8 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv,
if (bdb_version >= 209)
info->supports_tbt = child->tbt;
- DRM_DEBUG_KMS("Port %c VBT info: DP:%d HDMI:%d DVI:%d EDP:%d CRT:%d
TCUSB:%d TBT:%d\n",
- port_name(port), is_dp, is_hdmi, is_dvi, is_edp, is_crt,
+ DRM_DEBUG_KMS("Port %c VBT info: DP:%d HDMI:%d DVI:%d EDP:%d DSI:%d
CRT:%d TCUSB:%d TBT:%d\n",
+ port_name(port), is_dp, is_hdmi, is_dvi, is_edp, is_dsi,
is_crt,
info->supports_typec_usb, info->supports_tbt);
if (is_edp && is_dvi)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/bios: parse ddi ports also on VLV
The main benefit is improved debug logging of the ports also on VLV. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_bios.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 9beff569b010..030a5e9c67b3 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1514,7 +1514,8 @@ static void parse_ddi_ports(struct drm_i915_private *dev_priv, u8 bdb_version) const struct child_device_config *child; int i; - if (!HAS_DDI(dev_priv) && !IS_CHERRYVIEW(dev_priv)) + if (!HAS_DDI(dev_priv) && + !IS_CHERRYVIEW(dev_priv) && !IS_VALLEYVIEW(dev_priv)) return; if (bdb_version < 155) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] drm/i915/bios: ddi port parsing changes
Some prep work for future changes which will be easier with ddi port info being initialized in child device order instead of port order. BR, Jani. Jani Nikula (3): drm/i915/bios: iterate over child devices to initialize ddi_port_info drm/i915/bios: parse dsi devices in parse_ddi_ports() drm/i915/bios: parse ddi ports also on VLV drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/intel_bios.c | 113 +- 2 files changed, 66 insertions(+), 49 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/bios: iterate over child devices to initialize ddi_port_info
Iterate over child devices instead of ports in parse_ddi_ports() to
initialize dri_port_info. We'll eventually need to decide some stuff
based on the child device order, which may be different from the port
order.
As a bonus, this allows better abstractions for e.g. dvo port mapping.
There's a subtle change in the DDC pin and AUX channel sanitization as
we change the order. Otherwise, this should not change behaviour.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 104 +-
2 files changed, 59 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff039750069d..eeeb0d9cfdcd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -946,6 +946,7 @@ struct ddi_vbt_port_info {
#define HDMI_LEVEL_SHIFT_UNKNOWN 0xff
u8 hdmi_level_shift;
+ u8 present:1;
u8 supports_dvi:1;
u8 supports_hdmi:1;
u8 supports_dp:1;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index b508d8a735e0..fc27ffe81c14 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1222,10 +1222,11 @@ static void sanitize_ddc_pin(struct drm_i915_private
*dev_priv,
if (!info->alternate_ddc_pin)
return;
- for_each_port_masked(p, (1 << port) - 1) {
+ for (p = PORT_A; p < I915_MAX_PORTS; p++) {
struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
- if (info->alternate_ddc_pin != i->alternate_ddc_pin)
+ if (p == port || !i->present ||
+ info->alternate_ddc_pin != i->alternate_ddc_pin)
continue;
DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as
port %c, "
@@ -1239,8 +1240,8 @@ static void sanitize_ddc_pin(struct drm_i915_private
*dev_priv,
* port. Otherwise they share the same ddc bin and
* system couldn't communicate with them separately.
*
-* Due to parsing the ports in alphabetical order,
-* a higher port will always clobber a lower one.
+* Due to parsing the ports in child device order,
+* a later device will always clobber an earlier one.
*/
i->supports_dvi = false;
i->supports_hdmi = false;
@@ -1258,10 +1259,11 @@ static void sanitize_aux_ch(struct drm_i915_private
*dev_priv,
if (!info->alternate_aux_channel)
return;
- for_each_port_masked(p, (1 << port) - 1) {
+ for (p = PORT_A; p < I915_MAX_PORTS; p++) {
struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
- if (info->alternate_aux_channel != i->alternate_aux_channel)
+ if (p == port || !i->present ||
+ info->alternate_aux_channel != i->alternate_aux_channel)
continue;
DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as
port %c, "
@@ -1275,8 +1277,8 @@ static void sanitize_aux_ch(struct drm_i915_private
*dev_priv,
* port. Otherwise they share the same aux channel
* and system couldn't communicate with them separately.
*
-* Due to parsing the ports in alphabetical order,
-* a higher port will always clobber a lower one.
+* Due to parsing the ports in child device order,
+* a later device will always clobber an earlier one.
*/
i->supports_dp = false;
i->alternate_aux_channel = 0;
@@ -1324,49 +1326,58 @@ static u8 map_ddc_pin(struct drm_i915_private
*dev_priv, u8 vbt_pin)
return 0;
}
-static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
- u8 bdb_version)
+static enum port dvo_port_to_port(u8 dvo_port)
{
- struct child_device_config *it, *child = NULL;
- struct ddi_vbt_port_info *info = _priv->vbt.ddi_port_info[port];
- int i, j;
- bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
- /* Each DDI port can have more than one value on the "DVO Port" field,
+ /*
+* Each DDI port can have more than one value on the "DVO Port" field,
* so look for all the possible values for each port.
*/
- int dvo_ports[][3] = {
- {DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
- {DVO_PORT_HDMIB, DVO_PORT_DPB, -1},
- {DVO_PORT_HDMIC, DVO_PORT_DPC, -1},
- {DVO_PORT_HDMID, DVO_PORT_DPD, -1},
- {DVO_PORT_CRT, DVO_PORT_HDMIE, DVO_PORT_DPE},
- {DVO_PORT_HDMIF, DVO_PORT_DPF, -1},
+ static const int dvo_ports[][3] = {
+ [PORT_A] = { DVO_PORT_HDMIA, DVO_PORT_DPA, -1},
+
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Do not temporarily disable the DPLL on i830
On Tue, Mar 05, 2019 at 09:13:39PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/2] drm/i915: Do not temporarily disable > the DPLL on i830 > URL : https://patchwork.freedesktop.org/series/57598/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_5708 -> Patchwork_12377 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_12377 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_12377, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/57598/revisions/1/mbox/ > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_12377: > > ### IGT changes ### > > Possible regressions > > * igt@i915_module_load@reload-with-fault-injection: > - fi-kbl-7560u: PASS -> INCOMPLETE Unrelated, and v1 (which was 100% identical) passed everything -> series pushed to dinq -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/43] drm/i915/selftests: Canonicalise gen8 addresses
== Series Details == Series: series starting with [01/43] drm/i915/selftests: Canonicalise gen8 addresses URL : https://patchwork.freedesktop.org/series/57646/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/selftests: Canonicalise gen8 addresses Okay! Commit: drm/i915: Force GPU idle on suspend Okay! Commit: drm/i915/selftests: Improve switch-to-kernel-context checking Okay! Commit: drm/i915: Do a synchronous switch-to-kernel-context on idling Okay! Commit: drm/i915: Refactor common code to load initial power context Okay! Commit: drm/i915: Reduce presumption of request ordering for barriers -drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3549:16: warning: expression using sizeof(void) Commit: drm/i915: Remove has-kernel-context Okay! Commit: drm/i915: Introduce the i915_user_extension_method Okay! Commit: drm/i915: Track active engines within a context Okay! Commit: drm/i915: Introduce a context barrier callback Okay! Commit: drm/i915: Create/destroy VM (ppGTT) for use with contexts -drivers/gpu/drm/i915/selftests/../i915_drv.h:3549:16: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/selftests/i915_gem_context.c:1134:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3552:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1260:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:1260:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/selftests/i915_gem_context.c:564:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/selftests/i915_gem_context.c:564:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:568:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:568:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:689:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_gem_context.c:689:33: warning: expression using sizeof(void) Commit: drm/i915: Extend CONTEXT_CREATE to set parameters upon construction Okay! Commit: drm/i915: Allow contexts to share a single timeline across all engines Okay! Commit: drm/i915: Allow userspace to clone contexts on creation Okay! Commit: drm/i915: Allow a context to define its set of engines +./include/linux/slab.h:664:13: error: not a function Commit: drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[] Okay! Commit: drm/i915: Split struct intel_context definition to its own header +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Store the intel_context_ops in the intel_engine_cs Okay! Commit: drm/i915: Move over to intel_context_lookup() +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Make context pinning part of intel_context_ops Okay! Commit: drm/i915: Track the pinned kernel contexts on each engine Okay! Commit: drm/i915: Introduce intel_context.pin_mutex for pin management +drivers/gpu/drm/i915/intel_context.c:129:22: warning: context imbalance in 'intel_context_pin_lock' - wrong count at exit Commit: drm/i915: Load balancing across a virtual engine +./include/linux/overflow.h:285:13: error: incorrect type in conditional +./include/linux/overflow.h:285:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/overflow.h:285:13:got void +./include/linux/overflow.h:285:13: warning: call with no type! +./include/linux/overflow.h:287:13: error: incorrect type in conditional +./include/linux/overflow.h:287:13: error: undefined identifier '__builtin_add_overflow' +./include/linux/overflow.h:287:13:got void +./include/linux/overflow.h:287:13: warning: call with no type! Commit: drm/i915: Extend execution fence to support a callback Okay! Commit: drm/i915/execlists: Virtual engine bonding Okay! Commit: drm/i915: Allow specification of parallel execbuf Okay! Commit: drm/i915/selftests: Check preemption support on each engine Okay! Commit: drm/i915/execlists: Skip direct submission if only lite-restore Okay! Commit: drm/i915: Split GEM object type definition to its own header -drivers/gpu/drm/i915/selftests/../i915_drv.h:3552:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3553:16: warning: expression using sizeof(void) Commit: drm/i915: Pull GEM ioctls interface to its own file -drivers/gpu/drm/i915/selftests/../i915_drv.h:3553:16: warning: expression using sizeof(void)
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 02:55:58PM +, Chris Wilson wrote: > Quoting Ville Syrjälä (2019-03-06 14:52:11) > > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > > > Quoting Ville Syrjala (2019-03-05 19:29:05) > > > > From: Ville Syrjälä > > > > > > > > At some point people have started to assume that > > > > pipe_offsets[] & co. are only populated for pipes and whatnot > > > > that actually exist. That is in fact not currently true, but > > > > we can easily make it so. > > > > > > Any benefits of knock on effect? > > > > What kind of knock on effect we're thinking? > > Just wondering why people are eager to make the assumption that > non-existent pipes are not set. I presume its to make code neater. > > i.e. why cater to their whims at all? Yeah, I guess this was done just to avoid having convoluted platform checks all over. I've not checked the code to see if there are more places where we could simplify the existing code by adopting this approach. However now that you forced me to think a bit I realize that this may break in the presence of fused off pipes. Not quite sure how the registers for such fused off blocks would behave. If we aren't allowed to touch those registers we'd need to move this stuff into the runtime info. That feels a bit wasteful, so as an alternative we could just add one or two bitmasks instead. Cc:ing Lucas who seems to the main offender here... -- Ville Syrjälä Intel ___ 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 [01/43] drm/i915/selftests: Canonicalise gen8 addresses
== Series Details ==
Series: series starting with [01/43] drm/i915/selftests: Canonicalise gen8
addresses
URL : https://patchwork.freedesktop.org/series/57646/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
38853354b213 drm/i915/selftests: Canonicalise gen8 addresses
9afdcdabf817 drm/i915: Force GPU idle on suspend
8f0b3a1f1c4b drm/i915/selftests: Improve switch-to-kernel-context checking
b2434f6ad1c7 drm/i915: Do a synchronous switch-to-kernel-context on idling
9e04c16a66c2 drm/i915: Refactor common code to load initial power context
490633baebd7 drm/i915: Reduce presumption of request ordering for barriers
f2b5c6562b0d drm/i915: Remove has-kernel-context
185722d64d2f drm/i915: Introduce the i915_user_extension_method
-:58: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#58:
new file mode 100644
-:63: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#63: FILE: drivers/gpu/drm/i915/i915_user_extensions.c:1:
+/*
-:112: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#112: FILE: drivers/gpu/drm/i915/i915_user_extensions.h:1:
+/*
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ptr' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:108:
+#define container_of_user(ptr, type, member) ({
\
+ void __user *__mptr = (void __user *)(ptr); \
+ BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
+!__same_type(*(ptr), void),\
+"pointer type mismatch in container_of()");\
+ ((type __user *)(__mptr - offsetof(type, member))); })
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:108:
+#define container_of_user(ptr, type, member) ({
\
+ void __user *__mptr = (void __user *)(ptr); \
+ BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
+!__same_type(*(ptr), void),\
+"pointer type mismatch in container_of()");\
+ ((type __user *)(__mptr - offsetof(type, member))); })
-:140: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'member' may be better as
'(member)' to avoid precedence issues
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:108:
+#define container_of_user(ptr, type, member) ({
\
+ void __user *__mptr = (void __user *)(ptr); \
+ BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
+!__same_type(*(ptr), void),\
+"pointer type mismatch in container_of()");\
+ ((type __user *)(__mptr - offsetof(type, member))); })
total: 0 errors, 3 warnings, 3 checks, 109 lines checked
9093f0976b36 drm/i915: Track active engines within a context
-:111: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#111: FILE: drivers/gpu/drm/i915/i915_gem_context.h:167:
+ struct mutex mutex;
total: 0 errors, 0 warnings, 1 checks, 198 lines checked
3d0a65eefd18 drm/i915: Introduce a context barrier callback
67651b3feee0 drm/i915: Create/destroy VM (ppGTT) for use with contexts
-:40: CHECK:UNCOMMENTED_DEFINITION: struct mutex definition without comment
#40: FILE: drivers/gpu/drm/i915/i915_drv.h:221:
+ struct mutex vm_lock;
-:551: WARNING:LINE_SPACING: Missing a blank line after declarations
#551: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:503:
+ struct drm_file *file;
+ IGT_TIMEOUT(end_time);
-:613: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#613: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:565:
+ ncontexts = dw = 0;
-:688: WARNING:LINE_SPACING: Missing a blank line after declarations
#688: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:633:
+ struct i915_gem_context *ctx = NULL;
+ IGT_TIMEOUT(end_time);
-:746: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#746: FILE: drivers/gpu/drm/i915/selftests/i915_gem_context.c:686:
+ ncontexts = dw = 0;
-:853: WARNING:LONG_LINE: line over 100 characters
#853: FILE: include/uapi/drm/i915_drm.h:405:
+#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
-:854: WARNING:LONG_LINE: line over 100 characters
#854: FILE: include/uapi/drm/i915_drm.h:406:
+#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
-:854: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#854: FILE: include/uapi/drm/i915_drm.h:406:
+#define DRM_IOCTL_I915_GEM_VM_DESTROY
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/dp: deconflate PPS unlock from divisor register (rev3)
== Series Details == Series: series starting with [1/2] drm/i915/dp: deconflate PPS unlock from divisor register (rev3) URL : https://patchwork.freedesktop.org/series/57579/ State : success == Summary == CI Bug Log - changes from CI_DRM_5708_full -> Patchwork_12392_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12392_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_big: - shard-hsw: PASS -> TIMEOUT [fdo#107937] * igt@gem_exec_schedule@preempt-other-chain-blt: - shard-snb: NOTRUN -> SKIP [fdo#109271] +115 * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: - shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] +1 * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-d: - shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] * igt@kms_busy@extended-pageflip-hang-newfb-render-f: - shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5 * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c: - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] * igt@kms_chv_cursor_fail@pipe-c-256x256-bottom-edge: - shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +17 * igt@kms_color@pipe-a-legacy-gamma: - shard-glk: PASS -> FAIL [fdo#104782] / [fdo#108145] * igt@kms_color@pipe-c-legacy-gamma: - shard-apl: PASS -> FAIL [fdo#104782] * igt@kms_cursor_crc@cursor-128x128-onscreen: - shard-apl: PASS -> FAIL [fdo#103232] * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232] * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-skl: NOTRUN -> FAIL [fdo#103232] * igt@kms_fbcon_fbt@psr: - shard-skl: NOTRUN -> FAIL [fdo#103833] * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: PASS -> FAIL [fdo#105363] * igt@kms_flip_tiling@flip-yf-tiled: - shard-skl: PASS -> FAIL [fdo#108145] * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: - shard-apl: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-render: - shard-glk: PASS -> FAIL [fdo#103167] * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> SKIP [fdo#109271] +46 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt: - shard-kbl: NOTRUN -> SKIP [fdo#109271] +15 * igt@kms_panel_fitting@legacy: - shard-skl: NOTRUN -> FAIL [fdo#105456] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773] * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885] * igt@kms_plane_alpha_blend@pipe-b-alpha-7efc: - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-apl: PASS -> FAIL [fdo#103166] * igt@kms_rotation_crc@multiplane-rotation-cropping-top: - shard-kbl: PASS -> FAIL [fdo#109016] * igt@kms_setmode@basic: - shard-kbl: PASS -> FAIL [fdo#99912] Possible fixes * igt@i915_pm_rpm@gem-execbuf-stress-extra-wait: - shard-skl: INCOMPLETE [fdo#107803] / [fdo#107807] -> PASS * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-glk: FAIL [fdo#108145] -> PASS * igt@kms_chv_cursor_fail@pipe-a-256x256-bottom-edge: - shard-skl: FAIL [fdo#104671] -> PASS * igt@kms_cursor_crc@cursor-256x85-offscreen: - shard-skl: FAIL [fdo#103232] -> PASS * igt@kms_cursor_crc@cursor-64x64-sliding: - shard-apl: FAIL [fdo#103232] -> PASS +1 * igt@kms_cursor_crc@cursor-alpha-opaque: - shard-apl: FAIL [fdo#109350] -> PASS - shard-glk: FAIL [fdo#109350] -> PASS * igt@kms_cursor_crc@cursor-size-change: - shard-glk: FAIL [fdo#103232] -> PASS * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite: - shard-apl: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu: - shard-glk: FAIL [fdo#103167] -> PASS * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu: - shard-skl: FAIL [fdo#103167] -> PASS +1 * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-skl: FAIL [fdo#105682] -> PASS * igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc: - shard-skl: FAIL [fdo#103167] / [fdo#105682] -> PASS * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: FAIL [fdo#107815] / [fdo#108145] -> PASS
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Pass around the intel_context
== Series Details ==
Series: drm/i915: Pass around the intel_context
URL : https://patchwork.freedesktop.org/series/57635/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5708_full -> Patchwork_12391_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12391_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ringfill@basic-default-forked:
- {shard-iclb}: NOTRUN -> FAIL +2
* igt@perf_pmu@busy-hang-vcs0:
- {shard-iclb}: NOTRUN -> INCOMPLETE
* igt@runner@aborted:
- {shard-iclb}: NOTRUN -> ( 5 FAIL ) [fdo#103232]
Known issues
Here are the changes found in Patchwork_12391_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_big:
- shard-hsw: PASS -> TIMEOUT [fdo#107937]
* igt@gem_exec_schedule@preempt-other-chain-blt:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +115
* igt@gem_softpin@noreloc-s3:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#107773]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-snb: NOTRUN -> DMESG-WARN [fdo#107956] +1
* igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-d:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_busy@extended-pageflip-hang-newfb-render-f:
- shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +5
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145]
* igt@kms_chv_cursor_fail@pipe-c-256x256-bottom-edge:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +17
* igt@kms_cursor_crc@cursor-256x85-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +8
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw: PASS -> FAIL [fdo#105767]
* igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
- shard-skl: PASS -> FAIL [fdo#103184]
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#103833]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: PASS -> FAIL [fdo#102887]
* igt@kms_flip_tiling@flip-changes-tiling-y:
- shard-skl: PASS -> FAIL [fdo#107931] / [fdo#108303]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-render:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +46
* igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
- shard-skl: PASS -> FAIL [fdo#105682]
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-kbl: NOTRUN -> SKIP [fdo#109271] +15
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-blt:
- shard-skl: PASS -> FAIL [fdo#103167]
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: PASS -> FAIL [fdo#109016]
Possible fixes
* igt@i915_pm_rpm@gem-execbuf-stress-extra-wait:
- shard-skl: INCOMPLETE [fdo#107803] / [fdo#107807] -> PASS
* igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc:
- shard-skl: FAIL [fdo#103167] / [fdo#105682] -> PASS
* igt@kms_rotation_crc@multiplane-rotation:
- shard-kbl: INCOMPLETE [fdo#103665] -> PASS
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-apl: FAIL [fdo#103166] -> PASS +1
{name}: This
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
Quoting Ville Syrjälä (2019-03-06 14:52:11) > On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote: > > Quoting Ville Syrjala (2019-03-05 19:29:05) > > > From: Ville Syrjälä > > > > > > At some point people have started to assume that > > > pipe_offsets[] & co. are only populated for pipes and whatnot > > > that actually exist. That is in fact not currently true, but > > > we can easily make it so. > > > > Any benefits of knock on effect? > > What kind of knock on effect we're thinking? Just wondering why people are eager to make the assumption that non-existent pipes are not set. I presume its to make code neater. i.e. why cater to their whims at all? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Populate pipe_offsets[] & co. accurately
On Wed, Mar 06, 2019 at 09:31:48AM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-03-05 19:29:05)
> > From: Ville Syrjälä
> >
> > At some point people have started to assume that
> > pipe_offsets[] & co. are only populated for pipes and whatnot
> > that actually exist. That is in fact not currently true, but
> > we can easily make it so.
>
> Any benefits of knock on effect?
What kind of knock on effect we're thinking?
>
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 146 +++-
> > 1 file changed, 104 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index c42c5ccf38fe..9e610e4bdd7d 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -35,7 +35,37 @@
> > #define PLATFORM(x) .platform = (x), .platform_mask = BIT(x)
> > #define GEN(x) .gen = (x), .gen_mask = BIT((x) - 1)
> >
> > -#define GEN_DEFAULT_PIPEOFFSETS \
> > +#define I845_PIPE_OFFSETS \
> > + .pipe_offsets = { \
> > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > + }, \
> > + .trans_offsets = { \
> > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > + }
> > +
> > +#define I9XX_PIPE_OFFSETS \
> > + .pipe_offsets = { \
> > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > + [TRANSCODER_B] = PIPE_B_OFFSET, \
> > + }, \
> > + .trans_offsets = { \
> > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > + [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> > + }
> > +
> > +#define IVB_PIPE_OFFSETS \
> > + .pipe_offsets = { \
> > + [TRANSCODER_A] = PIPE_A_OFFSET, \
> > + [TRANSCODER_B] = PIPE_B_OFFSET, \
> > + [TRANSCODER_C] = PIPE_C_OFFSET, \
> > + }, \
> > + .trans_offsets = { \
> > + [TRANSCODER_A] = TRANSCODER_A_OFFSET, \
> > + [TRANSCODER_B] = TRANSCODER_B_OFFSET, \
> > + [TRANSCODER_C] = TRANSCODER_C_OFFSET, \
> > + }
> > +
> > +#define HSW_PIPE_OFFSETS \
> > .pipe_offsets = { \
> > [TRANSCODER_A] = PIPE_A_OFFSET, \
> > [TRANSCODER_B] = PIPE_B_OFFSET, \
> > @@ -49,7 +79,7 @@
> > [TRANSCODER_EDP] = TRANSCODER_EDP_OFFSET, \
> > }
> >
> > -#define GEN_CHV_PIPEOFFSETS \
> > +#define CHV_PIPE_OFFSETS \
> > .pipe_offsets = { \
> > [TRANSCODER_A] = PIPE_A_OFFSET, \
> > [TRANSCODER_B] = PIPE_B_OFFSET, \
> > @@ -61,11 +91,30 @@
> > [TRANSCODER_C] = CHV_TRANSCODER_C_OFFSET, \
> > }
> >
> > -#define CURSOR_OFFSETS \
> > - .cursor_offsets = { CURSOR_A_OFFSET, CURSOR_B_OFFSET,
> > CHV_CURSOR_C_OFFSET }
> > +#define I845_CURSOR_OFFSETS \
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + }
> > +
> > +#define I9XX_CURSOR_OFFSETS \
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + [PIPE_B] = CURSOR_B_OFFSET, \
> > + }
> > +
> > +#define CHV_CURSOR_OFFSETS \
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + [PIPE_B] = CURSOR_B_OFFSET, \
> > + [PIPE_C] = CHV_CURSOR_C_OFFSET, \
> > + }
> >
> > #define IVB_CURSOR_OFFSETS \
> > - .cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET,
> > IVB_CURSOR_C_OFFSET }
> > + .cursor_offsets = { \
> > + [PIPE_A] = CURSOR_A_OFFSET, \
> > + [PIPE_B] = IVB_CURSOR_B_OFFSET, \
> > + [PIPE_C] = IVB_CURSOR_C_OFFSET, \
> > + }
>
> Ok, those tables all match up with my understanding and rummaging.
>
> > static const struct intel_device_info intel_i865g_info = {
> > - GEN2_FEATURES,
> > + I845_FEATURES,
>
> Hmm, 865g had dvo in addition to vga (unlike 845g)
845g doesn't have dvo? The docs don't seem to quite agree with that.
I should probably hunt one down just to complete my gen2 collection :)
> so did it have a
> second pipe? Though memory says dual pipe was a luxury of mobile only.
Yeah, single pipe only I'm afraid.
>
> > PLATFORM(INTEL_I865G),
> > };
> > #define G75_FEATURES \
> > @@ -404,6 +465,7 @@ static const struct intel_device_info
> > intel_valleyview_info = {
>
> Grr.
>
> > .display.has_psr = 1, \
> > .display.has_dp_mst = 1, \
> > .has_rc6p = 0 /* RC6p removed-by HSW */, \
> > + HSW_PIPE_OFFSETS, \
>
> Was thinking vlv using HSW? but then realised that diff was misleading.
I rather dislike these template macros for this exact reason.
>
> And the device tables look to be using the correct feature sets.
>
> Reviewed-by: Chris Wilson
Thanks.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 22/43] drm/i915: Introduce intel_context.pin_mutex for pin management
Quoting Tvrtko Ursulin (2019-03-06 14:43:13) > > On 06/03/2019 14:24, Chris Wilson wrote: > > Introduce a mutex to start locking the HW contexts independently of > > struct_mutex, with a view to reducing the coarse struct_mutex. The > > intel_context.pin_mutex is used to guard the transition to and from being > > pinned on the gpu, and so is required before starting to build any > > request. The intel_context will then remain pinned until the request > > completes, but the mutex can be released immediately unpin completion of > > pinning the context. > > > > A slight variant of the above is used by per-context sseu that wants to > > inspect the pinned status of the context, and requires that it remains > > stable (either !pinned or pinned) across its operation. By using the > > pin_mutex to serialise operations while pin_count==0, we can take that > > pin_mutex for stabilise the boolean pin status. > > Change log! v2: no code changes, or at least I can only remember rewriting the commitmsg, so see above. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 26/43] drm/i915: Allow specification of parallel execbuf
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that with all things idle the second execbufs are executed
in parallel with the first. The key difference here between the new
EXEC_FENCE_SUBMIT and the existing EXEC_FENCE_IN is that the in-fence
waits for the completion of the first request (so that all of its
rendering results are visible to the second execbuf, the more common
userspace fence requirement).
Since we only have a single input fence slot, userspace cannot mix an
in-fence and a submit-fence. It has to use one or the other! This is not
such a harsh requirement, since by virtue of the submit-fence, the
secondary execbuf inherit all of the dependencies from the first
request, and for the application the dependencies should be common
between the primary and secondary execbuf.
Suggested-by: Tvrtko Ursulin
Testcase: igt/gem_exec_fence/parallel
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 25 +-
include/uapi/drm/i915_drm.h| 17 ++-
3 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a54030d60f84..8e65def8bcc5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -421,6 +421,7 @@ static int i915_getparam_ioctl(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_EXEC_CAPTURE:
case I915_PARAM_HAS_EXEC_BATCH_FIRST:
case I915_PARAM_HAS_EXEC_FENCE_ARRAY:
+ case I915_PARAM_HAS_EXEC_SUBMIT_FENCE:
/* For the time being all of these are always true;
* if some supported hardware does not have one of these
* features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8fc5bbdba9fa..87f059e418ab 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2266,6 +2266,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
{
struct i915_execbuffer eb;
struct dma_fence *in_fence = NULL;
+ struct dma_fence *exec_fence = NULL;
struct sync_file *out_fence = NULL;
intel_wakeref_t wakeref;
int out_fence_fd = -1;
@@ -2309,11 +2310,24 @@ i915_gem_do_execbuffer(struct drm_device *dev,
return -EINVAL;
}
+ if (args->flags & I915_EXEC_FENCE_SUBMIT) {
+ if (in_fence) {
+ err = -EINVAL;
+ goto err_in_fence;
+ }
+
+ exec_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
+ if (!exec_fence) {
+ err = -EINVAL;
+ goto err_in_fence;
+ }
+ }
+
if (args->flags & I915_EXEC_FENCE_OUT) {
out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
if (out_fence_fd < 0) {
err = out_fence_fd;
- goto err_in_fence;
+ goto err_exec_fence;
}
}
@@ -2445,6 +2459,13 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_request;
}
+ if (exec_fence) {
+ err = i915_request_await_execution(eb.request, exec_fence,
+ eb.engine->bond_execute);
+ if (err < 0)
+ goto err_request;
+ }
+
if (fences) {
err = await_fence_array(, fences);
if (err)
@@ -2505,6 +2526,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err_out_fence:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
+err_exec_fence:
+ dma_fence_put(exec_fence);
err_in_fence:
dma_fence_put(in_fence);
return err;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index c9683b19aaf2..677d435ac64b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -591,6 +591,12 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_MMAP_GTT_COHERENT 52
+/*
+ * Query whether DRM_I915_GEM_EXECBUFFER2 supports coordination of parallel
+ * execution through use of explicit fence support.
+ * See I915_EXEC_FENCE_OUT and I915_EXEC_FENCE_SUBMIT.
+ */
+#define I915_PARAM_HAS_EXEC_SUBMIT_FENCE 53
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
@@ -1113,7 +1119,16 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_FENCE_ARRAY (1<<19)
-#define __I915_EXEC_UNKNOWN_FLAGS
Re: [Intel-gfx] [PATCH 22/43] drm/i915: Introduce intel_context.pin_mutex for pin management
On 06/03/2019 14:24, Chris Wilson wrote:
Introduce a mutex to start locking the HW contexts independently of
struct_mutex, with a view to reducing the coarse struct_mutex. The
intel_context.pin_mutex is used to guard the transition to and from being
pinned on the gpu, and so is required before starting to build any
request. The intel_context will then remain pinned until the request
completes, but the mutex can be released immediately unpin completion of
pinning the context.
A slight variant of the above is used by per-context sseu that wants to
inspect the pinned status of the context, and requires that it remains
stable (either !pinned or pinned) across its operation. By using the
pin_mutex to serialise operations while pin_count==0, we can take that
pin_mutex for stabilise the boolean pin status.
Change log!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_context.c | 76 +++
drivers/gpu/drm/i915/intel_context.c | 56 --
drivers/gpu/drm/i915/intel_context.h | 38 ++
drivers/gpu/drm/i915/intel_context_types.h| 8 +-
drivers/gpu/drm/i915/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +-
.../gpu/drm/i915/selftests/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
9 files changed, 110 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 71d8ce38f42c..8863dd414cde 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4662,7 +4662,7 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
if (!state)
continue;
- GEM_BUG_ON(ce->pin_count);
+ GEM_BUG_ON(intel_context_is_pinned(ce));
/*
* As we will hold a reference to the logical state, it will
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f7a075efccad..35541f99b37d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1098,23 +1098,27 @@ static int gen8_emit_rpcs_config(struct i915_request
*rq,
}
static int
-gen8_modify_rpcs_gpu(struct intel_context *ce,
-struct intel_engine_cs *engine,
-struct intel_sseu sseu)
+gen8_modify_rpcs(struct intel_context *ce, struct intel_sseu sseu)
{
- struct drm_i915_private *i915 = engine->i915;
+ struct drm_i915_private *i915 = ce->engine->i915;
struct i915_request *rq, *prev;
intel_wakeref_t wakeref;
int ret;
- GEM_BUG_ON(!ce->pin_count);
+ lockdep_assert_held(>pin_mutex);
- lockdep_assert_held(>drm.struct_mutex);
+ /*
+* If context is not idle we have to submit an ordered request to modify
+* its context image via the kernel context. Pristine and idle contexts
+* will be configured on pinning.
+*/
+ if (!intel_context_is_pinned(ce))
+ return 0;
/* Submitting requests etc needs the hw awake. */
wakeref = intel_runtime_pm_get(i915);
- rq = i915_request_alloc(engine, i915->kernel_context);
+ rq = i915_request_alloc(ce->engine, i915->kernel_context);
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
goto out_put;
@@ -1158,53 +1162,30 @@ gen8_modify_rpcs_gpu(struct intel_context *ce,
}
static int
-__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
- struct intel_engine_cs *engine,
- struct intel_sseu sseu)
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
{
struct intel_context *ce;
int ret = 0;
- ce = intel_context_instance(ctx, engine);
- if (IS_ERR(ce))
- return PTR_ERR(ce);
-
GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
GEM_BUG_ON(engine->id != RCS0);
+ ce = intel_context_pin_lock(ctx, engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
/* Nothing to do if unmodified. */
if (!memcmp(>sseu, , sizeof(sseu)))
- return 0;
-
- /*
-* If context is not idle we have to submit an ordered request to modify
-* its context image via the kernel context. Pristine and idle contexts
-* will be configured on pinning.
-*/
- if (ce->pin_count)
- ret = gen8_modify_rpcs_gpu(ce, engine, sseu);
+ goto unlock;
+ ret = gen8_modify_rpcs(ce, sseu);
if (!ret)
ce->sseu = sseu;
- return ret;
-}
-
-static int
-i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
-
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Canonicalise gen8 addresses
Chris Wilson writes:
> For igt_vm_isolation, we write into the whole 48b address space, and not
> just our usual low 4G of global GTT. For these MI operations, play safe
> and ensure we use the canonical address form.
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c| 19 -
> drivers/gpu/drm/i915/intel_gpu_commands.h | 21 +++
> .../gpu/drm/i915/selftests/i915_gem_context.c | 2 ++
> 3 files changed, 23 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 943a221acb21..c335c0a4099a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -289,25 +289,6 @@ struct i915_execbuffer {
>
> #define exec_entry(EB, VMA) (&(EB)->exec[(VMA)->exec_flags - (EB)->flags])
>
> -/*
> - * Used to convert any address to canonical form.
> - * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
> - * MI_LOAD_REGISTER_MEM and others, see Broadwell PRM Vol2a) require the
> - * addresses to be in a canonical form:
> - * "GraphicsAddress[63:48] are ignored by the HW and assumed to be in correct
> - * canonical form [63:48] == [47]."
> - */
> -#define GEN8_HIGH_ADDRESS_BIT 47
> -static inline u64 gen8_canonical_addr(u64 address)
> -{
> - return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
> -}
> -
> -static inline u64 gen8_noncanonical_addr(u64 address)
> -{
> - return address & GENMASK_ULL(GEN8_HIGH_ADDRESS_BIT, 0);
> -}
> -
> static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
> {
> return intel_engine_needs_cmd_parser(eb->engine) && eb->batch_len;
> diff --git a/drivers/gpu/drm/i915/intel_gpu_commands.h
> b/drivers/gpu/drm/i915/intel_gpu_commands.h
> index a34ece53a771..b017bc928d00 100644
> --- a/drivers/gpu/drm/i915/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/intel_gpu_commands.h
> @@ -7,6 +7,8 @@
> #ifndef _INTEL_GPU_COMMANDS_H_
> #define _INTEL_GPU_COMMANDS_H_
>
> +#include
> +
> /*
> * Instruction field definitions used by the command parser
> */
> @@ -275,4 +277,23 @@
> #define COLOR_BLT ((0x2<<29)|(0x40<<22))
> #define SRC_COPY_BLT ((0x2<<29)|(0x43<<22))
>
> +/*
> + * Used to convert any address to canonical form.
> + * Starting from gen8, some commands (e.g. STATE_BASE_ADDRESS,
> + * MI_LOAD_REGISTER_MEM and others, see Broadwell PRM Vol2a) require the
> + * addresses to be in a canonical form:
> + * "GraphicsAddress[63:48] are ignored by the HW and assumed to be in correct
> + * canonical form [63:48] == [47]."
> + */
> +#define GEN8_HIGH_ADDRESS_BIT 47
> +static inline u64 gen8_canonical_addr(u64 address)
> +{
> + return sign_extend64(address, GEN8_HIGH_ADDRESS_BIT);
> +}
> +
> +static inline u64 gen8_noncanonical_addr(u64 address)
> +{
> + return address & GENMASK_ULL(GEN8_HIGH_ADDRESS_BIT, 0);
> +}
> +
> #endif /* _INTEL_GPU_COMMANDS_H_ */
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> index 0346ff224d5d..34a8c15273f4 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> @@ -1194,6 +1194,7 @@ static int write_to_scratch(struct i915_gem_context
> *ctx,
>
> *cmd++ = MI_STORE_DWORD_IMM_GEN4;
> if (INTEL_GEN(i915) >= 8) {
> + offset = gen8_canonical_addr(offset);
> *cmd++ = lower_32_bits(offset);
> *cmd++ = upper_32_bits(offset);
> } else {
> @@ -1284,6 +1285,7 @@ static int read_from_scratch(struct i915_gem_context
> *ctx,
> if (INTEL_GEN(i915) >= 8) {
> *cmd++ = MI_LOAD_REGISTER_MEM_GEN8;
> *cmd++ = RCS_GPR0;
> + offset = gen8_canonical_addr(offset);
Yes. Now, I need to go and really convince myself that
MI_STORE_DWORD_IMM is not part of this club.
-Mika
> *cmd++ = lower_32_bits(offset);
> *cmd++ = upper_32_bits(offset);
> *cmd++ = MI_STORE_REGISTER_MEM_GEN8;
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/43] drm/i915: Move over to intel_context_lookup()
On 06/03/2019 14:24, Chris Wilson wrote:
In preparation for an ever growing number of engines and so ever
increasing static array of HW contexts within the GEM context, move the
array over to an rbtree, allocated upon first use.
Unfortunately, this imposes an rbtree lookup at a few frequent callsites,
but we should be able to mitigate those by moving over to using the HW
context as our primary type and so only incur the lookup on the boundary
with the user GEM context and engines.
v2: Check for no HW context in guc_stage_desc_init
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gvt/mmio_context.c | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 9 +-
drivers/gpu/drm/i915/i915_gem_context.c | 91 -
drivers/gpu/drm/i915/i915_gem_context.h | 1 -
drivers/gpu/drm/i915/i915_gem_context_types.h | 7 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c| 4 +-
drivers/gpu/drm/i915/i915_globals.c | 1 +
drivers/gpu/drm/i915/i915_globals.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 4 +-
drivers/gpu/drm/i915/intel_context.c | 180 ++
drivers/gpu/drm/i915/intel_context.h | 40 +++-
drivers/gpu/drm/i915/intel_context_types.h| 2 +
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/intel_engine_types.h | 5 +
drivers/gpu/drm/i915/intel_guc_ads.c | 4 +-
drivers/gpu/drm/i915/intel_guc_submission.c | 6 +-
drivers/gpu/drm/i915/intel_lrc.c | 29 ++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 23 ++-
drivers/gpu/drm/i915/selftests/mock_context.c | 7 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 6 +-
21 files changed, 324 insertions(+), 102 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_context.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 524cace37d85..60de05f3fa60 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -95,6 +95,7 @@ i915-y += \
i915_trace_points.o \
i915_vma.o \
intel_breadcrumbs.o \
+ intel_context.o \
intel_engine_cs.o \
intel_hangcheck.o \
intel_lrc.o \
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index 0209d27fcaf0..f64c76dd11d4 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -494,7 +494,8 @@ static void switch_mmio(struct intel_vgpu *pre,
* itself.
*/
if (mmio->in_context &&
-
!is_inhibit_context(>shadow_ctx->__engine[ring_id]))
+
!is_inhibit_context(intel_context_lookup(s->shadow_ctx,
+
dev_priv->engine[ring_id])))
continue;
if (mmio->mask)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8d5918b99fc9..71d8ce38f42c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4650,15 +4650,20 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
}
for_each_engine(engine, i915, id) {
+ struct intel_context *ce;
struct i915_vma *state;
void *vaddr;
- GEM_BUG_ON(to_intel_context(ctx, engine)->pin_count);
+ ce = intel_context_lookup(ctx, engine);
+ if (!ce)
+ continue;
- state = to_intel_context(ctx, engine)->state;
+ state = ce->state;
if (!state)
continue;
+ GEM_BUG_ON(ce->pin_count);
+
/*
* As we will hold a reference to the logical state, it will
* not be torn down with the context, and importantly the
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index bc89d01d338d..f7a075efccad 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -96,7 +96,7 @@
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
-static struct i915_global_context {
+static struct i915_global_gem_context {
struct i915_global base;
struct kmem_cache *slab_luts;
} global;
@@ -240,7 +240,7 @@ static void release_hw_id(struct i915_gem_context *ctx)
static void i915_gem_context_free(struct i915_gem_context *ctx)
{
- unsigned int n;
+ struct intel_context *it, *n;
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
@@ -251,12 +251,8 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
kfree(ctx->engines);
- for (n = 0; n
Re: [Intel-gfx] [PATCH 18/43] drm/i915: Store the intel_context_ops in the intel_engine_cs
On 06/03/2019 14:24, Chris Wilson wrote:
If we place a pointer to the engine specific intel_context_ops in the
engine itself, we can assign the ops pointer on initialising the
context, and then rely on it being set. This simplifies the code in
later patches.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/intel_engine_types.h| 1 +
drivers/gpu/drm/i915/intel_lrc.c | 13 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 22 +---
drivers/gpu/drm/i915/selftests/mock_engine.c | 13 ++--
5 files changed, 24 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8037d0efbb4a..bc89d01d338d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -379,6 +379,7 @@ intel_context_init(struct intel_context *ce,
{
ce->gem_context = ctx;
ce->engine = engine;
+ ce->ops = engine->cops;
INIT_LIST_HEAD(>signal_link);
INIT_LIST_HEAD(>signals);
diff --git a/drivers/gpu/drm/i915/intel_engine_types.h
b/drivers/gpu/drm/i915/intel_engine_types.h
index f7ceda334169..4d2c0ba58e6e 100644
--- a/drivers/gpu/drm/i915/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/intel_engine_types.h
@@ -351,6 +351,7 @@ struct intel_engine_cs {
void (*set_default_submission)(struct intel_engine_cs *engine);
+ const struct intel_context_ops *cops;
struct intel_context *(*context_pin)(struct intel_engine_cs *engine,
struct i915_gem_context *ctx);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0bd837b64ade..31cc4a82b928 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1386,11 +1386,6 @@ __execlists_context_pin(struct intel_engine_cs *engine,
return ERR_PTR(ret);
}
-static const struct intel_context_ops execlists_context_ops = {
- .unpin = execlists_context_unpin,
- .destroy = execlists_context_destroy,
-};
-
static struct intel_context *
execlists_context_pin(struct intel_engine_cs *engine,
struct i915_gem_context *ctx)
@@ -1404,11 +1399,14 @@ execlists_context_pin(struct intel_engine_cs *engine,
return ce;
GEM_BUG_ON(!ce->pin_count); /* no overflow please! */
- ce->ops = _context_ops;
-
return __execlists_context_pin(engine, ctx, ce);
}
+static const struct intel_context_ops execlists_context_ops = {
+ .unpin = execlists_context_unpin,
+ .destroy = execlists_context_destroy,
+};
+
static int gen8_emit_init_breadcrumb(struct i915_request *rq)
{
u32 *cs;
@@ -2352,6 +2350,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->reset.reset = execlists_reset;
engine->reset.finish = execlists_reset_finish;
+ engine->cops = _context_ops;
engine->context_pin = execlists_context_pin;
engine->request_alloc = execlists_request_alloc;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 82f33ff94dc8..78e3c03aab4e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1349,7 +1349,7 @@ intel_ring_free(struct intel_ring *ring)
kfree(ring);
}
-static void intel_ring_context_destroy(struct intel_context *ce)
+static void ring_context_destroy(struct intel_context *ce)
{
GEM_BUG_ON(ce->pin_count);
@@ -1426,7 +1426,7 @@ static void __context_unpin(struct intel_context *ce)
i915_vma_unpin(vma);
}
-static void intel_ring_context_unpin(struct intel_context *ce)
+static void ring_context_unpin(struct intel_context *ce)
{
__context_unpin_ppgtt(ce->gem_context);
__context_unpin(ce);
@@ -1549,14 +1549,8 @@ __ring_context_pin(struct intel_engine_cs *engine,
return ERR_PTR(err);
}
-static const struct intel_context_ops ring_context_ops = {
- .unpin = intel_ring_context_unpin,
- .destroy = intel_ring_context_destroy,
-};
-
static struct intel_context *
-intel_ring_context_pin(struct intel_engine_cs *engine,
- struct i915_gem_context *ctx)
+ring_context_pin(struct intel_engine_cs *engine, struct i915_gem_context *ctx)
{
struct intel_context *ce = to_intel_context(ctx, engine);
@@ -1566,11 +1560,14 @@ intel_ring_context_pin(struct intel_engine_cs *engine,
return ce;
GEM_BUG_ON(!ce->pin_count); /* no overflow please! */
- ce->ops = _context_ops;
-
return __ring_context_pin(engine, ctx, ce);
}
+static const struct intel_context_ops ring_context_ops = {
+ .unpin = ring_context_unpin,
+ .destroy = ring_context_destroy,
+};
+
static int intel_init_ring_buffer(struct intel_engine_cs *engine)
{
struct
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Move find_active_request() to the engine
Chris Wilson writes: > Quoting Tvrtko Ursulin (2019-03-05 18:13:34) >> >> intel_engine.h in 3...2...1.. ;) > > As soon as we have a good name for the legacy submission method. At the > moment, my favorites are: > gen2_submission.c / legacy_submission.c (actually that's winning again) > gen8_submission.c / execlists_submission.c > guc_submission.c I would favour the name of the method instead of gens. And legacy is always sneaking steadily towards present. So how about ringbuf_submission.c ? -Mika > > intel_ring.[ch] can provide the small bit of common struct intel_ring, > and intel_engine.[ch] for the common setup/poking. > -Chris > ___ > 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] [PATCH 07/43] drm/i915: Remove has-kernel-context
We can no longer assume execution ordering, and in particular we cannot
assume which context will execute last. One side-effect of this is that
we cannot determine if the kernel-context is resident on the GPU, so
remove the routines that claimed to do so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.h | 13 ---
drivers/gpu/drm/i915/i915_gem.c | 18 --
drivers/gpu/drm/i915/i915_gem_evict.c | 16 +++--
drivers/gpu/drm/i915/intel_engine_cs.c | 31 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
5 files changed, 3 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 8142a334b37b..7d758719ce39 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -108,19 +108,6 @@ i915_active_request_set_retire_fn(struct
i915_active_request *active,
active->retire = fn ?: i915_active_retire_noop;
}
-static inline struct i915_request *
-__i915_active_request_peek(const struct i915_active_request *active)
-{
- /*
-* Inside the error capture (running with the driver in an unknown
-* state), we want to bend the rules slightly (a lot).
-*
-* Work is in progress to make it safer, in the meantime this keeps
-* the known issue from spamming the logs.
-*/
- return rcu_dereference_protected(active->request, 1);
-}
-
/**
* i915_active_request_raw - return the active request
* @active - the active tracker
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ed7695fd444a..8d5918b99fc9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2828,23 +2828,6 @@ i915_gem_retire_work_handler(struct work_struct *work)
round_jiffies_up_relative(HZ));
}
-static void assert_kernel_context_is_current(struct drm_i915_private *i915)
-{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- if (i915_reset_failed(i915))
- return;
-
- i915_retire_requests(i915);
-
- for_each_engine(engine, i915, id) {
-
GEM_BUG_ON(__i915_active_request_peek(>timeline.last_request));
- GEM_BUG_ON(engine->last_retired_context !=
- to_intel_context(i915->kernel_context, engine));
- }
-}
-
static bool switch_to_kernel_context_sync(struct drm_i915_private *i915,
unsigned long mask)
{
@@ -2857,7 +2840,6 @@ static bool switch_to_kernel_context_sync(struct
drm_i915_private *i915,
HZ / 10))
return false;
- assert_kernel_context_is_current(i915);
return true;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 7d8e90dfca84..060f5903544a 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -38,25 +38,15 @@ I915_SELFTEST_DECLARE(static struct igt_evict_ctl {
static bool ggtt_is_idle(struct drm_i915_private *i915)
{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- if (i915->gt.active_requests)
- return false;
-
- for_each_engine(engine, i915, id) {
- if (!intel_engine_has_kernel_context(engine))
- return false;
- }
-
- return true;
+ return !i915->gt.active_requests;
}
static int ggtt_flush(struct drm_i915_private *i915)
{
int err;
- /* Not everything in the GGTT is tracked via vma (otherwise we
+ /*
+* Not everything in the GGTT is tracked via vma (otherwise we
* could evict as required with minimal stalling) so we are forced
* to idle the GPU and explicitly retire outstanding requests in
* the hopes that we can then remove contexts and the like only
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 18174f808fd8..8e326556499e 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1090,37 +1090,6 @@ bool intel_engines_are_idle(struct drm_i915_private
*i915)
return true;
}
-/**
- * intel_engine_has_kernel_context:
- * @engine: the engine
- *
- * Returns true if the last context to be executed on this engine, or has been
- * executed if the engine is already idle, is the kernel context
- * (#i915.kernel_context).
- */
-bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine)
-{
- const struct intel_context *kernel_context =
- to_intel_context(engine->i915->kernel_context, engine);
- struct i915_request *rq;
-
- lockdep_assert_held(>i915->drm.struct_mutex);
-
- if (!engine->context_size)
- return true;
-
- /*
-* Check the last context seen by
[Intel-gfx] [PATCH 09/43] drm/i915: Track active engines within a context
For use in the next patch, if we track which engines have been used by
the HW, we can reduce the work required to flush our state off the HW to
those engines.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 +--
drivers/gpu/drm/i915/i915_gem_context.c | 5 +
drivers/gpu/drm/i915/i915_gem_context.h | 5 +
drivers/gpu/drm/i915/intel_lrc.c | 22 +--
drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +++-
drivers/gpu/drm/i915/selftests/mock_context.c | 2 ++
drivers/gpu/drm/i915/selftests/mock_engine.c | 6 +
7 files changed, 43 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0a6348ad7c98..6a90558de213 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -388,12 +388,9 @@ static void print_context_stats(struct seq_file *m,
struct i915_gem_context *ctx;
list_for_each_entry(ctx, >contexts.list, link) {
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
-
- for_each_engine(engine, i915, id) {
- struct intel_context *ce = to_intel_context(ctx,
engine);
+ struct intel_context *ce;
+ list_for_each_entry(ce, >active_engines, active_link) {
if (ce->state)
per_file_stats(0, ce->state->obj, );
if (ce->ring)
@@ -1880,9 +1877,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_device *dev = _priv->drm;
- struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
- enum intel_engine_id id;
int ret;
ret = mutex_lock_interruptible(>struct_mutex);
@@ -1890,6 +1885,8 @@ static int i915_context_status(struct seq_file *m, void
*unused)
return ret;
list_for_each_entry(ctx, _priv->contexts.list, link) {
+ struct intel_context *ce;
+
seq_puts(m, "HW context ");
if (!list_empty(>hw_id_link))
seq_printf(m, "%x [pin %u]", ctx->hw_id,
@@ -1912,11 +1909,8 @@ static int i915_context_status(struct seq_file *m, void
*unused)
seq_putc(m, ctx->remap_slice ? 'R' : 'r');
seq_putc(m, '\n');
- for_each_engine(engine, dev_priv, id) {
- struct intel_context *ce =
- to_intel_context(ctx, engine);
-
- seq_printf(m, "%s: ", engine->name);
+ list_for_each_entry(ce, >active_engines, active_link) {
+ seq_printf(m, "%s: ", ce->engine->name);
if (ce->state)
describe_obj(m, ce->state->obj);
if (ce->ring)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 486203e9d205..d997695a4f77 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -226,6 +226,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
lockdep_assert_held(>i915->drm.struct_mutex);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+ GEM_BUG_ON(!list_empty(>active_engines));
release_hw_id(ctx);
i915_ppgtt_put(ctx->ppgtt);
@@ -241,6 +242,7 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
put_pid(ctx->pid);
list_del(>link);
+ mutex_destroy(>mutex);
kfree_rcu(ctx, rcu);
}
@@ -353,6 +355,7 @@ intel_context_init(struct intel_context *ce,
struct intel_engine_cs *engine)
{
ce->gem_context = ctx;
+ ce->engine = engine;
INIT_LIST_HEAD(>signal_link);
INIT_LIST_HEAD(>signals);
@@ -381,6 +384,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(>link, _priv->contexts.list);
ctx->i915 = dev_priv;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
+ INIT_LIST_HEAD(>active_engines);
+ mutex_init(>mutex);
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
intel_context_init(>__engine[n], ctx, dev_priv->engine[n]);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index e1188d77a23d..124c2a082b99 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -163,6 +163,9 @@ struct i915_gem_context {
atomic_t hw_id_pin_count;
struct list_head hw_id_link;
+ struct list_head active_engines;
+ struct mutex mutex;
+
/**
* @user_handle: userspace identifier
*
@@ -176,7 +179,9 @@ struct
[Intel-gfx] [PATCH 02/43] drm/i915: Force GPU idle on suspend
To facilitate the next patch to allow preemptible kernels not to incur
the wrath of hangcheck, we need to ensure that we can still suspend and
shutdown. That is we will not be able to rely on hangcheck to terminate
a blocking kernel and instead must manually do so ourselves. The
advantage is that we can apply more pressure!
As we now perform a GPU reset to clean up any residual kernels, we leave
the GPU in an unknown state and in particular can not talk to the GuC
before we reinitialise it following resume. For example, we no longer
need to tell the GuC to suspend itself, as it is already reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0b23cf3be718..c10be23d959e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3123,13 +3123,6 @@ int i915_gem_wait_for_idle(struct drm_i915_private *i915,
lockdep_assert_held(>drm.struct_mutex);
- if (GEM_SHOW_DEBUG() && !timeout) {
- /* Presume that timeout was non-zero to begin with! */
- dev_warn(>drm.pdev->dev,
-"Missed idle-completion interrupt!\n");
- GEM_TRACE_DUMP();
- }
-
err = wait_for_engines(i915);
if (err)
return err;
@@ -4379,11 +4372,12 @@ int i915_gem_suspend(struct drm_i915_private *i915)
I915_WAIT_INTERRUPTIBLE |
I915_WAIT_LOCKED |
I915_WAIT_FOR_IDLE_BOOST,
-MAX_SCHEDULE_TIMEOUT);
- if (ret && ret != -EIO)
+HZ / 5);
+ if (ret == -EINTR)
goto err_unlock;
- assert_kernel_context_is_current(i915);
+ /* Forcibly cancel outstanding work and leave the gpu quiet. */
+ i915_gem_set_wedged(i915);
}
i915_retire_requests(i915); /* ensure we flush after wedging */
@@ -4398,15 +4392,11 @@ int i915_gem_suspend(struct drm_i915_private *i915)
*/
drain_delayed_work(>gt.idle_work);
- intel_uc_suspend(i915);
-
/*
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- WARN_ON(i915->gt.awake);
- if (WARN_ON(!intel_engines_are_idle(i915)))
- i915_gem_set_wedged(i915); /* no hope, discard everything */
+ GEM_BUG_ON(i915->gt.awake);
intel_runtime_pm_put(i915, wakeref);
return 0;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/43] drm/i915: Store the intel_context_ops in the intel_engine_cs
If we place a pointer to the engine specific intel_context_ops in the
engine itself, we can assign the ops pointer on initialising the
context, and then rely on it being set. This simplifies the code in
later patches.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/intel_engine_types.h| 1 +
drivers/gpu/drm/i915/intel_lrc.c | 13 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 22 +---
drivers/gpu/drm/i915/selftests/mock_engine.c | 13 ++--
5 files changed, 24 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8037d0efbb4a..bc89d01d338d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -379,6 +379,7 @@ intel_context_init(struct intel_context *ce,
{
ce->gem_context = ctx;
ce->engine = engine;
+ ce->ops = engine->cops;
INIT_LIST_HEAD(>signal_link);
INIT_LIST_HEAD(>signals);
diff --git a/drivers/gpu/drm/i915/intel_engine_types.h
b/drivers/gpu/drm/i915/intel_engine_types.h
index f7ceda334169..4d2c0ba58e6e 100644
--- a/drivers/gpu/drm/i915/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/intel_engine_types.h
@@ -351,6 +351,7 @@ struct intel_engine_cs {
void(*set_default_submission)(struct intel_engine_cs
*engine);
+ const struct intel_context_ops *cops;
struct intel_context *(*context_pin)(struct intel_engine_cs *engine,
struct i915_gem_context *ctx);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0bd837b64ade..31cc4a82b928 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1386,11 +1386,6 @@ __execlists_context_pin(struct intel_engine_cs *engine,
return ERR_PTR(ret);
}
-static const struct intel_context_ops execlists_context_ops = {
- .unpin = execlists_context_unpin,
- .destroy = execlists_context_destroy,
-};
-
static struct intel_context *
execlists_context_pin(struct intel_engine_cs *engine,
struct i915_gem_context *ctx)
@@ -1404,11 +1399,14 @@ execlists_context_pin(struct intel_engine_cs *engine,
return ce;
GEM_BUG_ON(!ce->pin_count); /* no overflow please! */
- ce->ops = _context_ops;
-
return __execlists_context_pin(engine, ctx, ce);
}
+static const struct intel_context_ops execlists_context_ops = {
+ .unpin = execlists_context_unpin,
+ .destroy = execlists_context_destroy,
+};
+
static int gen8_emit_init_breadcrumb(struct i915_request *rq)
{
u32 *cs;
@@ -2352,6 +2350,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->reset.reset = execlists_reset;
engine->reset.finish = execlists_reset_finish;
+ engine->cops = _context_ops;
engine->context_pin = execlists_context_pin;
engine->request_alloc = execlists_request_alloc;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 82f33ff94dc8..78e3c03aab4e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1349,7 +1349,7 @@ intel_ring_free(struct intel_ring *ring)
kfree(ring);
}
-static void intel_ring_context_destroy(struct intel_context *ce)
+static void ring_context_destroy(struct intel_context *ce)
{
GEM_BUG_ON(ce->pin_count);
@@ -1426,7 +1426,7 @@ static void __context_unpin(struct intel_context *ce)
i915_vma_unpin(vma);
}
-static void intel_ring_context_unpin(struct intel_context *ce)
+static void ring_context_unpin(struct intel_context *ce)
{
__context_unpin_ppgtt(ce->gem_context);
__context_unpin(ce);
@@ -1549,14 +1549,8 @@ __ring_context_pin(struct intel_engine_cs *engine,
return ERR_PTR(err);
}
-static const struct intel_context_ops ring_context_ops = {
- .unpin = intel_ring_context_unpin,
- .destroy = intel_ring_context_destroy,
-};
-
static struct intel_context *
-intel_ring_context_pin(struct intel_engine_cs *engine,
- struct i915_gem_context *ctx)
+ring_context_pin(struct intel_engine_cs *engine, struct i915_gem_context *ctx)
{
struct intel_context *ce = to_intel_context(ctx, engine);
@@ -1566,11 +1560,14 @@ intel_ring_context_pin(struct intel_engine_cs *engine,
return ce;
GEM_BUG_ON(!ce->pin_count); /* no overflow please! */
- ce->ops = _context_ops;
-
return __ring_context_pin(engine, ctx, ce);
}
+static const struct intel_context_ops ring_context_ops = {
+ .unpin = ring_context_unpin,
+ .destroy = ring_context_destroy,
+};
+
static int intel_init_ring_buffer(struct intel_engine_cs *engine)
{
struct i915_timeline *timeline;
@@ -2276,7 +2273,8 @@ static void
[Intel-gfx] [PATCH 13/43] drm/i915: Allow contexts to share a single timeline across all engines
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the user level the context often
represents a single timeline (e.g. GL contexts) and userspace must
ensure that the individual engines are serialised to present that
ordering to the client (or forgot about this detail entirely and hope no
one notices - a fair ploy if the client can only directly control one
engine themselves ;)
In the next patch, we will want to construct a set of engines that
operate as one, that have a single timeline interwoven between them, to
present a single virtual engine to the user. (They submit to the virtual
engine, then we decide which engine to execute on based.)
To that end, we want to be able to create contexts which have a single
timeline (fence context) shared between all engines, rather than multiple
timelines.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 32 ---
drivers/gpu/drm/i915/i915_gem_context.h | 3 ++
drivers/gpu/drm/i915/i915_request.c | 10 -
drivers/gpu/drm/i915/i915_request.h | 5 ++-
drivers/gpu/drm/i915/i915_sw_fence.c | 39 ---
drivers/gpu/drm/i915/i915_sw_fence.h | 13 ++-
drivers/gpu/drm/i915/intel_lrc.c | 5 ++-
.../gpu/drm/i915/selftests/i915_gem_context.c | 18 +
drivers/gpu/drm/i915/selftests/mock_context.c | 2 +-
include/uapi/drm/i915_drm.h | 3 +-
10 files changed, 103 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index bc042b0e0082..9927f1296fd6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -241,6 +241,9 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
ce->ops->destroy(ce);
}
+ if (ctx->timeline)
+ i915_timeline_put(ctx->timeline);
+
kfree(ctx->name);
put_pid(ctx->pid);
@@ -480,12 +483,17 @@ static void __assign_ppgtt(struct i915_gem_context *ctx,
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *dev_priv,
- struct drm_i915_file_private *file_priv)
+ struct drm_i915_file_private *file_priv,
+ unsigned int flags)
{
struct i915_gem_context *ctx;
lockdep_assert_held(_priv->drm.struct_mutex);
+ if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
+ !HAS_EXECLISTS(dev_priv))
+ return ERR_PTR(-EINVAL);
+
/* Reap the most stale context */
contexts_free_first(dev_priv);
@@ -508,6 +516,18 @@ i915_gem_create_context(struct drm_i915_private *dev_priv,
i915_ppgtt_put(ppgtt);
}
+ if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
+ struct i915_timeline *timeline;
+
+ timeline = i915_timeline_create(dev_priv, ctx->name, NULL);
+ if (IS_ERR(timeline)) {
+ __destroy_hw_context(ctx, file_priv);
+ return ERR_CAST(timeline);
+ }
+
+ ctx->timeline = timeline;
+ }
+
trace_i915_context_create(ctx);
return ctx;
@@ -536,7 +556,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
if (ret)
return ERR_PTR(ret);
- ctx = i915_gem_create_context(to_i915(dev), NULL);
+ ctx = i915_gem_create_context(to_i915(dev), NULL, 0);
if (IS_ERR(ctx))
goto out;
@@ -572,7 +592,7 @@ i915_gem_context_create_kernel(struct drm_i915_private
*i915, int prio)
struct i915_gem_context *ctx;
int err;
- ctx = i915_gem_create_context(i915, NULL);
+ ctx = i915_gem_create_context(i915, NULL, 0);
if (IS_ERR(ctx))
return ctx;
@@ -704,7 +724,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
idr_init_base(_priv->vm_idr, 1);
mutex_lock(>drm.struct_mutex);
- ctx = i915_gem_create_context(i915, file_priv);
+ ctx = i915_gem_create_context(i915, file_priv, 0);
mutex_unlock(>drm.struct_mutex);
if (IS_ERR(ctx)) {
idr_destroy(_priv->context_idr);
@@ -820,7 +840,7 @@ last_request_on_engine(struct i915_timeline *timeline,
rq = i915_active_request_raw(>last_request,
>i915->drm.struct_mutex);
- if (rq && rq->engine == engine) {
+ if (rq && rq->engine->mask & engine->mask) {
GEM_TRACE("last request for %s on engine %s: %llx:%llu\n",
timeline->name, engine->name,
rq->fence.context, rq->fence.seqno);
@@ -1478,7 +1498,7 @@ int
