[Intel-gfx] [PATCH i-g-t 1/1] tools/intel_guc_logger: Send GuC log level in new i915 expected format
i915 expects GuC log level to be specified as: 0: disabled 1: enabled (verbosity level 0 = min) 2: enabled (verbosity level 1) 3: enabled (verbosity level 2) 4: enabled (verbosity level 3 = max) Remove the earlier internal layout based logging control from guc_log_control and send new expected values. Signed-off-by: Sagar Arun Kamble Cc: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Chris Wilson --- tools/intel_guc_logger.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/tools/intel_guc_logger.c b/tools/intel_guc_logger.c index 031fd84..e695497 100644 --- a/tools/intel_guc_logger.c +++ b/tools/intel_guc_logger.c @@ -51,18 +51,27 @@ uint32_t test_duration, max_filesize; pthread_cond_t underflow_cond, overflow_cond; bool stop_logging, discard_oldlogs, capturing_stopped; -static void guc_log_control(bool enable_logging) +static void guc_log_control(bool enable, uint32_t log_level) { int control_fd; char data[19]; - uint64_t val; + uint64_t val = 0; int ret; + /* +* i915 expects GuC log level to be specified as: +* 0: disabled +* 1: enabled (verbosity level 0 = min) +* 2: enabled (verbosity level 1) +* 3: enabled (verbosity level 2) +* 4: enabled (verbosity level 3 = max) +*/ + if (enable) + val = log_level + 1; + control_fd = igt_debugfs_open(-1, CONTROL_FILE_NAME, O_WRONLY); igt_assert_f(control_fd >= 0, "couldn't open the guc log control file\n"); - val = enable_logging ? ((verbosity_level << 4) | 0x1) : 0; - ret = snprintf(data, sizeof(data), "0x%" PRIx64, val); igt_assert(ret > 2 && ret < sizeof(data)); @@ -288,7 +297,7 @@ static void init_main_thread(void) /* Enable the logging, it may not have been enabled from boot and so * the relay file also wouldn't have been created. */ - guc_log_control(true); + guc_log_control(true, verbosity_level); open_relay_file(); open_output_file(); @@ -420,7 +429,7 @@ int main(int argc, char **argv) } while (!stop_logging); /* Pause logging on the GuC side */ - guc_log_control(false); + guc_log_control(false, 0); /* Signal flusher thread to make an exit */ capturing_stopped = 1; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active
On Fri, Jan 12, 2018 at 11:32:30AM +0530, Sagar Arun Kamble wrote: > Is skl-gvtdvm not having vGPU active? > > It has flag X86_FEATURE_HYPERVISOR set however it might be set on host too > so relying intel_vgpu_active(). > Do you mean flag X86_FEATURE_HYPERVISOR is set on host, too? This is weird since this flag indicates the OS is running on a hypervisor. > > On 1/11/2018 10:27 PM, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU > > is active > > URL : https://patchwork.freedesktop.org/series/36343/ > > State : failure > > > > == Summary == > > > > Series 36343v1 series starting with [1/2] drm/i915/guc: Don't enable GuC > > when vGPU is active > > https://patchwork.freedesktop.org/api/1.0/series/36343/revisions/1/mbox/ > > > > Test core_auth: > > Subgroup basic-auth: > > pass -> SKIP (fi-skl-gvtdvm) > > Test core_prop_blob: > > Subgroup basic: > > pass -> SKIP (fi-skl-gvtdvm) > > Test debugfs_test: > > Subgroup read_all_entries: > > dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 > > pass -> SKIP (fi-skl-gvtdvm) > > Test drv_getparams_basic: > > Subgroup basic-eu-total: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-subslice-total: > > pass -> SKIP (fi-skl-gvtdvm) > > Test drv_hangman: > > Subgroup error-state-basic: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_basic: > > Subgroup bad-close: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup create-close: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup create-fd-close: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_busy: > > Subgroup basic-busy-default: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-hang-default: > > pass -> SKIP (fi-skl-gvtdvm) fdo#104108 +2 > > Test gem_close_race: > > Subgroup basic-process: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-threads: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_cpu_reloc: > > Subgroup basic: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_cs_tlb: > > Subgroup basic-default: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_ctx_create: > > Subgroup basic: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-files: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_ctx_exec: > > Subgroup basic: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_ctx_param: > > Subgroup basic: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-default: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_ctx_switch: > > Subgroup basic-default: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-default-heavy: > > pass -> SKIP (fi-skl-gvtdvm) > > Test gem_exec_basic: > > Subgroup basic-blt: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-bsd: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-bsd1: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-bsd2: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-default: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-render: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup basic-vebox: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup gtt-blt: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup gtt-bsd: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup gtt-bsd1: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup gtt-bsd2: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup gtt-default: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup gtt-render: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup gtt-vebox: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup readonly-blt: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup readonly-bsd: > > pass -> SKIP (fi-skl-gvtdvm) > > Subgroup readonly-bsd1: > >
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active
Is skl-gvtdvm not having vGPU active? It has flag X86_FEATURE_HYPERVISOR set however it might be set on host too so relying intel_vgpu_active(). On 1/11/2018 10:27 PM, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active URL : https://patchwork.freedesktop.org/series/36343/ State : failure == Summary == Series 36343v1 series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active https://patchwork.freedesktop.org/api/1.0/series/36343/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: pass -> SKIP (fi-skl-gvtdvm) Test core_prop_blob: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 pass -> SKIP (fi-skl-gvtdvm) Test drv_getparams_basic: Subgroup basic-eu-total: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-subslice-total: pass -> SKIP (fi-skl-gvtdvm) Test drv_hangman: Subgroup error-state-basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_basic: Subgroup bad-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-fd-close: pass -> SKIP (fi-skl-gvtdvm) Test gem_busy: Subgroup basic-busy-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-hang-default: pass -> SKIP (fi-skl-gvtdvm) fdo#104108 +2 Test gem_close_race: Subgroup basic-process: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-threads: pass -> SKIP (fi-skl-gvtdvm) Test gem_cpu_reloc: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_cs_tlb: Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_create: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-files: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_exec: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_param: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_switch: Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default-heavy: pass -> SKIP (fi-skl-gvtdvm) Test gem_exec_basic: Subgroup basic-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-render: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-vebox: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-render: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-vebox: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-default: WARNING: Long output truncated da4321c7c088d01ad62b18d37dcfe5ef8d0b855d drm-tip: 2018y-01m-11d-14h-59m-37s UTC integration manifest a0e8e84432b0 HAX: drm/i915/uc: Enable GuC/HuC for CI 973357da236a drm/i915/guc: Don't enable GuC when vGPU is active == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7651/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control
On 1/11/2018 8:54 PM, Michal Wajdeczko wrote: Today we have format mismatch between read/write operations of i915_guc_log_control entry. For read we return (0, 1..4) that represents disable/verbosity levels, but for write we force user to follow internal structure format (0,1,9,11,13). 0x0, 0x1, 0x11, 0x21, 0x31 Let's hide internals from the user and accept same values as we support for read and related guc_log_level modparam. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_guc_log.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index e6d59bf..1719f1e 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -58,11 +58,15 @@ static int guc_log_flush(struct intel_guc *guc) return intel_guc_send(guc, action, ARRAY_SIZE(action)); } -static int guc_log_control(struct intel_guc *guc, u32 control_val) +static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity) { + union guc_log_control control_val = { .logging_enabled = enable, + .reserved1 = 0, + .verbosity = verbosity, + .reserved2 = 0 }; u32 action[] = { INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING, - control_val + control_val.value }; return intel_guc_send(guc, action, ARRAY_SIZE(action)); @@ -567,28 +571,27 @@ void intel_guc_log_destroy(struct intel_guc *guc) int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val) { struct intel_guc *guc = &dev_priv->guc; - - union guc_log_control log_param; + bool enable_logging = control_val > 0; + u32 verbosity; int ret; - log_param.value = control_val; - - if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN || - log_param.verbosity > GUC_LOG_VERBOSITY_MAX) + BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN); + if (control_val > 1 + GUC_LOG_VERBOSITY_MAX) return -EINVAL; /* This combination doesn't make sense & won't have any effect */ - if (!log_param.logging_enabled && !i915_modparams.guc_log_level) + if (!enable_logging && !i915_modparams.guc_log_level) return 0; - ret = guc_log_control(guc, log_param.value); + verbosity = enable_logging ? control_val - 1 : 0; + ret = guc_log_control(guc, enable_logging, verbosity); if (ret < 0) { DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret); return ret; } - if (log_param.logging_enabled) { - i915_modparams.guc_log_level = 1 + log_param.verbosity; + if (enable_logging) { + i915_modparams.guc_log_level = 1 + verbosity; /* * If log was disabled at boot time, then the relay channel file ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Redefine guc_log_level modparam values
On 1/11/2018 8:54 PM, Michal Wajdeczko wrote: We used value -1 to indicate "disabled" and values 0..3 to indicate "enabled", but most of our other modparams are using -1 for "auto" mode and 0 for "disable". For consistency let's change our log level values to: -1: auto (depends on platform and Kconfig.debug settings) 0: disabled 1: enabled (severity level 0 = min) 2: enabled (severity level 1) 3: enabled (severity level 2) 4: enabled (severity level 3 = max) v2: fix commit message (Sagar) display sanitized modparam value (Sagar) unify sanitize messages (Sagar/Michal) Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_params.c | 3 +- drivers/gpu/drm/i915/intel_guc.c | 21 - drivers/gpu/drm/i915/intel_guc_log.c | 47 +--- drivers/gpu/drm/i915/intel_uc.c | 60 4 files changed, 92 insertions(+), 39 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b5f3eb4..0b553a8 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = { "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)"); i915_param_named(guc_log_level, int, 0400, - "GuC firmware logging level (-1:disabled (default), 0-3:enabled)"); + "GuC firmware logging level. Requires GuC to be loaded. " + "(-1=auto [default], 0=disable, 1..4=enable with verbosity min..max)"); i915_param_named_unsafe(guc_firmware_path, charp, 0400, "GuC firmware path to use instead of the default one"); diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 50b4725..4681537 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -215,6 +215,18 @@ static u32 get_core_family(struct drm_i915_private *dev_priv) } } +static u32 get_log_verbosity_flags(void) +{ + if (i915_modparams.guc_log_level > 0) { + u32 verbosity = i915_modparams.guc_log_level - 1; + + GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX); + return verbosity << GUC_LOG_VERBOSITY_SHIFT; + } + GEM_BUG_ON(i915_modparams.enable_guc < 0); + return GUC_LOG_DISABLED; +} + /* * Initialise the GuC parameter block before starting the firmware * transfer. These parameters are read by the firmware on startup @@ -247,12 +259,7 @@ void intel_guc_init_params(struct intel_guc *guc) params[GUC_CTL_LOG_PARAMS] = guc->log.flags; - if (i915_modparams.guc_log_level >= 0) { - params[GUC_CTL_DEBUG] = - i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT; - } else { - params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED; - } + params[GUC_CTL_DEBUG] = get_log_verbosity_flags(); /* If GuC submission is enabled, set up additional parameters here */ if (USES_GUC_SUBMISSION(dev_priv)) { @@ -445,7 +452,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv) if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) return 0; - if (i915_modparams.guc_log_level >= 0) + if (i915_modparams.guc_log_level) gen9_enable_guc_interrupts(dev_priv); data[0] = INTEL_GUC_ACTION_EXIT_S_STATE; diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index eaedd63..e6d59bf 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -33,11 +33,10 @@ /** * DOC: GuC firmware log * - * Firmware log is enabled by setting i915.guc_log_level to non-negative level. + * Firmware log is enabled by setting i915.guc_log_level to the positive level. * Log data is printed out via reading debugfs i915_guc_log_dump. Reading from * i915_guc_load_status will print out firmware loading status and scratch * registers value. - * */ static int guc_log_flush_complete(struct intel_guc *guc) @@ -147,7 +146,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc) struct dentry *log_dir; int ret; - if (i915_modparams.guc_log_level < 0) + if (!i915_modparams.guc_log_level) return 0; /* For now create the log file in /sys/kernel/debug/dri/0 dir */ @@ -423,8 +422,8 @@ static void guc_log_runtime_destroy(struct intel_guc *guc) { /* * It's possible that the runtime stuff was never allocated because -* guc_log_level was < 0 at the time -**/ +* GuC log was disabled at the boot time. +*/ if (!guc_log_has_runtime(guc)) return; @@ -441,9 +440,10 @@ static int guc_log_late_setup(struct intel_guc *guc) lockde
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Add a comment exlaining CCS hsub/vsub
On Wed, Jan 10, 2018 at 9:48 AM, Ville Syrjälä < ville.syrj...@linux.intel.com> wrote: > On Wed, Jan 10, 2018 at 09:03:14AM -0800, Jason Ekstrand wrote: > > On Fri, Dec 22, 2017 at 11:22 AM, Ville Syrjala < > > ville.syrj...@linux.intel.com> wrote: > > > > > From: Ville Syrjälä > > > > > > Let's document why we claim hsub==8,vsub==16 for CCS even though the > > > memory layout would suggest that we use 16x8 instead. > > > > > > Cc: Daniel Vetter > > > Cc: Ben Widawsky > > > Cc: Jason Ekstrand > > > Cc: Daniel Stone > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/intel_display.c | 7 +++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index 0cd355978ab4..83aec68537b4 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -2387,6 +2387,13 @@ static unsigned int intel_fb_modifier_to_tiling( > uint64_t > > > fb_modifier) > > > } > > > } > > > > > > +/* > > > + * 1 byte of CCS actually corresponds to 16x8 pixels on the main > > > + * surface, and the memory layout for the CCS tile is 64x64 bytes. > > > + * But since we're pretending the CCS tile is 128 bytes wide we > > > + * adjust hsub/vsub here accordingly to 8x16 so that the > > > + * bytes<->x/y conversions come out correct. > > > > > > > I'm not particularly happy with this comment as I think it pushes the > > mental model for these calculations in the wrong direction. The PRM > says: > > > > The Color Control Surface (CCS) contains the compression status of the > > cache-line pairs. The > > compression state of the cache-line pair is specified by 2 bits in the > CCS. > > Each CCS cache-line represents > > an area on the main surface of 16 x16 sets of 128 byte Y-tiled > > cache-line-pairs. CCS is always Y tiled. > > > > If you understand that a "cache line pair" in the main surface is a > > horizontally adjacent cache line pair (cl1_addr = cl0_addr + 512) and you > > just accept the statement about Y-tiling, this is the correct > calculation. > > Calculating these things in terms of pixels is occasionally useful but is > > the wrong mental model. The cache line statement above both accurately > > describes the layout of the CCS (at the cache line granularity) and > scales > > to other pixel formats which are not 32-bit. > > > > I know that Ville and I have disagreed on this in the past but I don't > > think adding comments about how we're "pretending the CCS tile is 128 > bytes > > wide" is making anything more clear. > > I don't really see how talk about cachelines is going to help explain > the hsub/vsub values we use here. > > But I don't really care that much. We could just leave them as magic > numbers if no one can come up with a clear explanation for them. > How about a comment like this: /*From the Sky Lake PRM: * *The Color Control Surface (CCS) contains the compression status of the cache-line pairs. The *compression state of the cache-line pair is specified by 2 bits in the CCS. Each CCS cache-line represents *an area on the main surface of 16 x16 sets of 128 byte Y-tiled cache-line-pairs. CCS is always Y tiled. * * Since cache line pairs refers to horizontally adjacent cache lines, each cache line in the CCS * corresponds to an area of 32x16 cache lines on the main surface. Since each pixel is 4 bytes, * this gives us a ratio of one byte in the CCS for each 8x16 pixels in the main surface. */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2 v4] drm/i915/icl: Gen11 render context size
On 11/01/18 14:55, Oscar Mateo wrote: From: Tvrtko Ursulin Gen11 removes the Resource Streamer, which frees up a big chunk of the context image. BSpec indicates 12538 DWORDs (13 pages), plus one page for PPHWSP. This is actually 12544 dwords according to the specs (I've already confirmed it with Oscar via IM). Still 13 pages anyway. Reviewed-by: Daniele Ceraolo Spurio Thanks, Daniele Please notice that, when looking at the BSpec context image table, the right filter has to be applied as some rows are excluded for specific GENs. Also, some rows apply per-subslice (for the calculation above, we have supposed I915_MAX_SUBSLICES = 8). v2: Rebase. v3: Use the right size as per the BSpec. v4: - Rebased on top of the default context size (Rodrigo) - Clarify in the commit message where the subslice calculation comes from. BSpec: 18907 Acked-by: Ben Widawsky Signed-off-by: Tvrtko Ursulin Signed-off-by: Oscar Mateo Cc: Rodrigo Vivi Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index db758c5..1e7bf40 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -42,6 +42,7 @@ #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE) #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE) #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) +#define GEN11_LR_CONTEXT_RENDER_SIZE (14 * PAGE_SIZE) #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE) @@ -183,6 +184,8 @@ struct engine_info { default: MISSING_CASE(INTEL_GEN(dev_priv)); return DEFAULT_LR_CONTEXT_RENDER_SIZE; + case 11: + return GEN11_LR_CONTEXT_RENDER_SIZE; case 10: return GEN10_LR_CONTEXT_RENDER_SIZE; case 9: ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP
On Thu, Jan 11, 2018 at 09:48:57PM +, James Ausmus wrote: > On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote: > > From: Anusha Srivatsa > > > > ICP has two backlight controllers - similar to previous platforms like > > BXT. > > > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani) > > Reuse BXT code since it is very similar.(Ville) > > > > v3 (from Paulo): Rebase. > > > > Cc: Jani Nikula > > Cc: Ville Syrjala > > Reviewed-by: Paulo Zanoni > > Signed-off-by: Anusha Srivatsa > > Signed-off-by: Paulo Zanoni > > --- > > drivers/gpu/drm/i915/intel_panel.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > > b/drivers/gpu/drm/i915/intel_panel.c > > index fa6831f8c004..ad80cca8c110 100644 > > --- a/drivers/gpu/drm/i915/intel_panel.c > > +++ b/drivers/gpu/drm/i915/intel_panel.c > > @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel > > *panel) > > panel->backlight.set = bxt_set_backlight; > > panel->backlight.get = bxt_get_backlight; > > panel->backlight.hz_to_pwm = bxt_hz_to_pwm; > > - } else if (HAS_PCH_CNP(dev_priv)) { > > + } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) { > > The commit message says reuse BXT, but the code says reuse CNP - which > one should it be? well, CNP is like BXT, but with only one controller. ICP is like BXT, including 2 controllers. I don't know if it makes more sense re-use the cnp or bxt functions But one way or another we have to address these lines from cnp_setup: /* * CNP has the BXT implementation of backlight, but with only * one controller. Future platforms could have multiple controll\ ers * so let's make this extensible and prepared for the future. */ panel->backlight.controller = 0; > > > panel->backlight.setup = cnp_setup_backlight; > > panel->backlight.enable = cnp_enable_backlight; > > panel->backlight.disable = cnp_disable_backlight; > > -- > > 2.14.3 > > > > ___ > > 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/27] drm/i915/icl: Make use of the SW counter field in the new context descriptor
On 11/01/18 14:37, Oscar Mateo wrote: On 01/11/2018 01:10 PM, Daniele Ceraolo Spurio wrote: This could potentially be squashed with patch 15, as it doesn't make much sense to add a TODO there and solve it here. We might also want to update the comment above intel_lr_context_descriptor_update to remove the implication that SW context ID == ctx->hw_id (which is still technically true after this patch but we're preparing for it not to be anymore). I was actually thinking of a different fate for this patch: leave patch 15 as is (maybe make the TODO more open, like "TODO: decide what to do with sw_counter"), slap a "drm/i915/icl/guc" prefix on this one and consider it together with the rest of the GuC patches. At least in the meantime, while we decide how to go about sw_counter (CCing Tvrtko). What do you think? Sounds good to me, this patch doesn't really impact the !GuC path anyway since the number of IDs stays the same. I'll wait to see if there is any more feedback and if no one complains I'll send a new revision of patch 15. Thanks, Daniele On 09/01/18 15:28, Paulo Zanoni wrote: From: Oscar Mateo The new context descriptor format in Gen11 contains two assignable fields: the SW Context ID (technically 11 bits, but practically limited to 2032 entries due to some being reserved for future use by the GuC) and the SW Counter (6 bits). We don't want to limit ourselves too much in the maximum number of concurrent contexts we want to allow, so ideally we want to employ every possible bit available. Unfortunately, a further limitation in the interface with the GuC means the combination of SW Context ID + SW Counter has to be unique within the same engine class (as we use the SW Context ID to index in the GuC stage descriptor pool, and the Engine Class + SW Counter to index in the 2-dimensional lrc array). This essentially means we need to somehow encode the engine instance. Since the BSpec allows 6 bits for engine instance, we use the whole SW counter for this task. If the limitation of 2032 maximum simultaneous contexts is too restrictive, we can always squeeze things a bit more (3 extras bits for hw_id, 3 bits for instance) and things will still work (Gen11 does not instance more than 8 engines of any class). Another alternative would be to generate the hw_id per HW context instead of per GEM context, but that has other problems (e.g. maximum number of user-created contexts would be variable, no relationship between a GuC principal descriptor and the proxy descriptor it uses, etc...). Bspec: 12254 v2: - Squashed with parts of "Interface changes for GuC fw 22.108" (Daniele) - Do not apply the 16 reserved entries limitation to the non-GuC path (Joonas) v3: Rebased by Rodrigo. v4: Rebased (s/i915_modparams.enable_guc_submission/USES_GUC_SUBMISSION(dev_priv)) Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Michal Wajdeczko Cc: Michel Thierry Signed-off-by: Oscar Mateo Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 11 --- drivers/gpu/drm/i915/i915_gem_context.c | 9 ++--- drivers/gpu/drm/i915/i915_gem_context.h | 2 ++ drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_lrc.c | 15 --- 5 files changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index aa4f2b178d97..3f1d8c0d2b0a 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2079,11 +2079,16 @@ struct drm_i915_private { /* The hw wants to have a stable context identifier for the * lifetime of the context (for OA, PASID, faults, etc). - * This is limited in execlists to 21 bits. + * This is limited in execlists to 21 bits. In enhanced execlist + * (GEN11+) this is limited to 11 bits (the SW Context ID field) + * but GuC limits it a bit further (11 bits - 16) due to some + * entries being reserved for future use (so the firmware only + * supports a GuC stage descriptor pool of 2032 entries). */ struct ida hw_ida; -#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */ -#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */ +#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */ +#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */ +#define GEN11_MAX_CONTEXT_HW_ID_WITH_GUC GEN11_MAX_CONTEXT_HW_ID - 16 } contexts; u32 fdi_rx_config; diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index dbc50b9e18c9..bb5d070083f5 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -213,9 +213,12 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out) int ret; unsigned int max; - if (INTEL_GEN(dev_priv) >= 11) - max = GEN11_MAX_CONTEXT_HW_ID; -
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Return a default RCS context size
On 11/01/18 14:55, Oscar Mateo wrote: Instead of returning whatever size the latest GEN used. This is because context sizes for new GENs can go up or down, but the only safe thing to do for missing cases is to use the largest known one, whatever that is. Suggested-by: Rodrigo Vivi Signed-off-by: Oscar Mateo Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index e88b2fd..db758c5 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -38,6 +38,7 @@ */ #define HSW_CXT_TOTAL_SIZE(17 * PAGE_SIZE) Could use a comment here with the explanation in the commit message, but it is relatively clear anyway, so: Reviewed-by: Daniele Ceraolo Spurio Thanks, Daniele +#define DEFAULT_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE) #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE) #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE) #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) @@ -181,6 +182,7 @@ struct engine_info { switch (INTEL_GEN(dev_priv)) { default: MISSING_CASE(INTEL_GEN(dev_priv)); + return DEFAULT_LR_CONTEXT_RENDER_SIZE; case 10: return GEN10_LR_CONTEXT_RENDER_SIZE; case 9: ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Return a default RCS context size
Instead of returning whatever size the latest GEN used. This is because context sizes for new GENs can go up or down, but the only safe thing to do for missing cases is to use the largest known one, whatever that is. Suggested-by: Rodrigo Vivi Signed-off-by: Oscar Mateo Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index e88b2fd..db758c5 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -38,6 +38,7 @@ */ #define HSW_CXT_TOTAL_SIZE (17 * PAGE_SIZE) +#define DEFAULT_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE) #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE) #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE) #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) @@ -181,6 +182,7 @@ struct engine_info { switch (INTEL_GEN(dev_priv)) { default: MISSING_CASE(INTEL_GEN(dev_priv)); + return DEFAULT_LR_CONTEXT_RENDER_SIZE; case 10: return GEN10_LR_CONTEXT_RENDER_SIZE; case 9: -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2 v4] drm/i915/icl: Gen11 render context size
From: Tvrtko Ursulin Gen11 removes the Resource Streamer, which frees up a big chunk of the context image. BSpec indicates 12538 DWORDs (13 pages), plus one page for PPHWSP. Please notice that, when looking at the BSpec context image table, the right filter has to be applied as some rows are excluded for specific GENs. Also, some rows apply per-subslice (for the calculation above, we have supposed I915_MAX_SUBSLICES = 8). v2: Rebase. v3: Use the right size as per the BSpec. v4: - Rebased on top of the default context size (Rodrigo) - Clarify in the commit message where the subslice calculation comes from. BSpec: 18907 Acked-by: Ben Widawsky Signed-off-by: Tvrtko Ursulin Signed-off-by: Oscar Mateo Cc: Rodrigo Vivi Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index db758c5..1e7bf40 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -42,6 +42,7 @@ #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE) #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE) #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) +#define GEN11_LR_CONTEXT_RENDER_SIZE (14 * PAGE_SIZE) #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE) @@ -183,6 +184,8 @@ struct engine_info { default: MISSING_CASE(INTEL_GEN(dev_priv)); return DEFAULT_LR_CONTEXT_RENDER_SIZE; + case 11: + return GEN11_LR_CONTEXT_RENDER_SIZE; case 10: return GEN10_LR_CONTEXT_RENDER_SIZE; case 9: -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/icl: Gen11 render context size
On 01/11/2018 11:40 AM, Rodrigo Vivi wrote: On Thu, Jan 11, 2018 at 06:23:20PM +, Oscar Mateo wrote: From: Tvrtko Ursulin Gen11 removes the Resource Streamer, which frees up a big chunk of the context image. BSpec indicates 12538 DWORDs (13 pages), plus one page for PPHWSP. Please notice that, when looking at the BSpec context image table, the right filter has to be applied (e.g. "IcelakeLP") as some rows are excluded for specific GENs. Also, some rows apply per-subslice (for the calculation above, we have supposed 8 subslices which is the maximum SKU we expect). v2: Rebase. v3: Use the right size as per the BSpec. BSpec: 18907 Acked-by: Ben Widawsky Signed-off-by: Tvrtko Ursulin Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index e88b2fd..79b7d36 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -41,6 +41,7 @@ #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE) #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE) #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) +#define GEN11_LR_CONTEXT_RENDER_SIZE (14 * PAGE_SIZE) #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE) @@ -181,6 +182,8 @@ struct engine_info { switch (INTEL_GEN(dev_priv)) { default: MISSING_CASE(INTEL_GEN(dev_priv)); I believe this default is getting danger as we decrease the size here. I believe the safest one for missing case is the largest one whatever that is. That's a very sensible idea. I don't know to put the default case in the middle of the other ones or change the numerical order, so I'll create a new define for the default case... + case 11: + return GEN11_LR_CONTEXT_RENDER_SIZE; case 10: return GEN10_LR_CONTEXT_RENDER_SIZE; case 9: -- 1.9.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 20/27] drm/i915/icl: Make use of the SW counter field in the new context descriptor
On 01/11/2018 01:10 PM, Daniele Ceraolo Spurio wrote: This could potentially be squashed with patch 15, as it doesn't make much sense to add a TODO there and solve it here. We might also want to update the comment above intel_lr_context_descriptor_update to remove the implication that SW context ID == ctx->hw_id (which is still technically true after this patch but we're preparing for it not to be anymore). I was actually thinking of a different fate for this patch: leave patch 15 as is (maybe make the TODO more open, like "TODO: decide what to do with sw_counter"), slap a "drm/i915/icl/guc" prefix on this one and consider it together with the rest of the GuC patches. At least in the meantime, while we decide how to go about sw_counter (CCing Tvrtko). What do you think? Thanks, Daniele On 09/01/18 15:28, Paulo Zanoni wrote: From: Oscar Mateo The new context descriptor format in Gen11 contains two assignable fields: the SW Context ID (technically 11 bits, but practically limited to 2032 entries due to some being reserved for future use by the GuC) and the SW Counter (6 bits). We don't want to limit ourselves too much in the maximum number of concurrent contexts we want to allow, so ideally we want to employ every possible bit available. Unfortunately, a further limitation in the interface with the GuC means the combination of SW Context ID + SW Counter has to be unique within the same engine class (as we use the SW Context ID to index in the GuC stage descriptor pool, and the Engine Class + SW Counter to index in the 2-dimensional lrc array). This essentially means we need to somehow encode the engine instance. Since the BSpec allows 6 bits for engine instance, we use the whole SW counter for this task. If the limitation of 2032 maximum simultaneous contexts is too restrictive, we can always squeeze things a bit more (3 extras bits for hw_id, 3 bits for instance) and things will still work (Gen11 does not instance more than 8 engines of any class). Another alternative would be to generate the hw_id per HW context instead of per GEM context, but that has other problems (e.g. maximum number of user-created contexts would be variable, no relationship between a GuC principal descriptor and the proxy descriptor it uses, etc...). Bspec: 12254 v2: - Squashed with parts of "Interface changes for GuC fw 22.108" (Daniele) - Do not apply the 16 reserved entries limitation to the non-GuC path (Joonas) v3: Rebased by Rodrigo. v4: Rebased (s/i915_modparams.enable_guc_submission/USES_GUC_SUBMISSION(dev_priv)) Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Michal Wajdeczko Cc: Michel Thierry Signed-off-by: Oscar Mateo Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 11 --- drivers/gpu/drm/i915/i915_gem_context.c | 9 ++--- drivers/gpu/drm/i915/i915_gem_context.h | 2 ++ drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_lrc.c | 15 --- 5 files changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index aa4f2b178d97..3f1d8c0d2b0a 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2079,11 +2079,16 @@ struct drm_i915_private { /* The hw wants to have a stable context identifier for the * lifetime of the context (for OA, PASID, faults, etc). - * This is limited in execlists to 21 bits. + * This is limited in execlists to 21 bits. In enhanced execlist + * (GEN11+) this is limited to 11 bits (the SW Context ID field) + * but GuC limits it a bit further (11 bits - 16) due to some + * entries being reserved for future use (so the firmware only + * supports a GuC stage descriptor pool of 2032 entries). */ struct ida hw_ida; -#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */ -#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */ +#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */ +#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */ +#define GEN11_MAX_CONTEXT_HW_ID_WITH_GUC GEN11_MAX_CONTEXT_HW_ID - 16 } contexts; u32 fdi_rx_config; diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index dbc50b9e18c9..bb5d070083f5 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -213,9 +213,12 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out) int ret; unsigned int max; - if (INTEL_GEN(dev_priv) >= 11) - max = GEN11_MAX_CONTEXT_HW_ID; - else + if (INTEL_GEN(dev_priv) >= 11) { + if (USES_GUC_SUBMISSION(dev_priv)) + max = GEN11_MAX_CONTEXT_HW_ID_WITH_GUC; + else + max = GEN11_MAX_CONTEXT_HW_ID; + } else max = MAX_CONTEXT_HW_ID; ret = ida_simp
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband
Hi, On 11-01-18 22:42, Hans de Goede wrote: Hi, On 11-01-18 22:17, Ville Syrjälä wrote: On Thu, Jan 11, 2018 at 08:53:42PM +, Chris Wilson wrote: Quoting Ville Syrjälä (2018-01-11 20:10:45) On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote: While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to ensure that all core are indeed awake (out of Cstate) and that the package is awake. To do so, we need to supplement the pm_qos with a manual ping on_each_cpu. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051 References: https://bugs.freedesktop.org/show_bug.cgi?id=102657 References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Hans de Goede --- drivers/gpu/drm/i915/i915_drv.c | 6 drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_sideband.c | 61 --- 3 files changed, 50 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 6c8da9d20c33..d4b90cc0130b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv, spin_lock_init(&dev_priv->uncore.lock); mutex_init(&dev_priv->sb_lock); + pm_qos_add_request(&dev_priv->sb_qos, + PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE); + mutex_init(&dev_priv->modeset_restore_lock); mutex_init(&dev_priv->av_mutex); mutex_init(&dev_priv->wm.wm_mutex); @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv) intel_irq_fini(dev_priv); i915_workqueues_cleanup(dev_priv); i915_engines_cleanup(dev_priv); + + pm_qos_remove_request(&dev_priv->sb_qos); + mutex_destroy(&dev_priv->sb_lock); } static int i915_mmio_setup(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a689396d0ff6..ff3f9effc0bb 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1887,6 +1887,7 @@ struct drm_i915_private { /* Sideband mailbox protection */ struct mutex sb_lock; + struct pm_qos_request sb_qos; /** Cached value of IMR to avoid reads in updating the bitfield */ union { diff --git a/drivers/gpu/drm/i915/intel_sideband.c b/drivers/gpu/drm/i915/intel_sideband.c index 75c872bb8cc9..02bdd2e2cef6 100644 --- a/drivers/gpu/drm/i915/intel_sideband.c +++ b/drivers/gpu/drm/i915/intel_sideband.c @@ -22,6 +22,8 @@ * */ +#include + #include "i915_drv.h" #include "intel_drv.h" @@ -39,18 +41,20 @@ /* Private register write, double-word addressing, non-posted */ #define SB_CRWRDA_NP 0x07 -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, - u32 port, u32 opcode, u32 addr, u32 *val) +static void ping(void *info) { - u32 cmd, be = 0xf, bar = 0; - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); +} - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) | - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) | - (bar << IOSF_BAR_SHIFT); +static int vlv_sideband_rw(struct drm_i915_private *dev_priv, + u32 devfn, u32 port, u32 opcode, + u32 addr, u32 *val) +{ + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); + int err; - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock)); + lockdep_assert_held(&dev_priv->sb_lock); + /* Flush the previous comms, just in case it failed last time. */ if (intel_wait_for_register(dev_priv, VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, 5)) { @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, return -EAGAIN; } - I915_WRITE(VLV_IOSF_ADDR, addr); - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val); - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd); + iosf_mbi_punit_acquire(); - if (intel_wait_for_register(dev_priv, - VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, - 5)) { + /* + * Prevent the cpu from sleeping while we use this sideband, otherwise + * the punit may cause a machine hang. + */ + pm_qos_update_request(&dev_priv->sb_qos, 0); + on_each_cpu(ping, NULL, 1); pm_qos_update_request() doesn't wake up the cpus on its own? I wonder kind of latency guarantees it can actually give without doing that. intel_idle plugs into the update to wake up idle cpus, but it is not synchronous. If
Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP
On Thu, Jan 11, 2018 at 04:00:08PM -0200, Paulo Zanoni wrote: > From: Anusha Srivatsa > > ICP has two backlight controllers - similar to previous platforms like > BXT. > > v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani) > Reuse BXT code since it is very similar.(Ville) > > v3 (from Paulo): Rebase. > > Cc: Jani Nikula > Cc: Ville Syrjala > Reviewed-by: Paulo Zanoni > Signed-off-by: Anusha Srivatsa > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_panel.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index fa6831f8c004..ad80cca8c110 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel > *panel) > panel->backlight.set = bxt_set_backlight; > panel->backlight.get = bxt_get_backlight; > panel->backlight.hz_to_pwm = bxt_hz_to_pwm; > - } else if (HAS_PCH_CNP(dev_priv)) { > + } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) { The commit message says reuse BXT, but the code says reuse CNP - which one should it be? > panel->backlight.setup = cnp_setup_backlight; > panel->backlight.enable = cnp_enable_backlight; > panel->backlight.disable = cnp_disable_backlight; > -- > 2.14.3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband
Hi, On 11-01-18 22:17, Ville Syrjälä wrote: On Thu, Jan 11, 2018 at 08:53:42PM +, Chris Wilson wrote: Quoting Ville Syrjälä (2018-01-11 20:10:45) On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote: While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to ensure that all core are indeed awake (out of Cstate) and that the package is awake. To do so, we need to supplement the pm_qos with a manual ping on_each_cpu. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051 References: https://bugs.freedesktop.org/show_bug.cgi?id=102657 References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Hans de Goede --- drivers/gpu/drm/i915/i915_drv.c | 6 drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_sideband.c | 61 --- 3 files changed, 50 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 6c8da9d20c33..d4b90cc0130b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv, spin_lock_init(&dev_priv->uncore.lock); mutex_init(&dev_priv->sb_lock); + pm_qos_add_request(&dev_priv->sb_qos, +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE); + mutex_init(&dev_priv->modeset_restore_lock); mutex_init(&dev_priv->av_mutex); mutex_init(&dev_priv->wm.wm_mutex); @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv) intel_irq_fini(dev_priv); i915_workqueues_cleanup(dev_priv); i915_engines_cleanup(dev_priv); + + pm_qos_remove_request(&dev_priv->sb_qos); + mutex_destroy(&dev_priv->sb_lock); } static int i915_mmio_setup(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a689396d0ff6..ff3f9effc0bb 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1887,6 +1887,7 @@ struct drm_i915_private { /* Sideband mailbox protection */ struct mutex sb_lock; + struct pm_qos_request sb_qos; /** Cached value of IMR to avoid reads in updating the bitfield */ union { diff --git a/drivers/gpu/drm/i915/intel_sideband.c b/drivers/gpu/drm/i915/intel_sideband.c index 75c872bb8cc9..02bdd2e2cef6 100644 --- a/drivers/gpu/drm/i915/intel_sideband.c +++ b/drivers/gpu/drm/i915/intel_sideband.c @@ -22,6 +22,8 @@ * */ +#include + #include "i915_drv.h" #include "intel_drv.h" @@ -39,18 +41,20 @@ /* Private register write, double-word addressing, non-posted */ #define SB_CRWRDA_NP 0x07 -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, -u32 port, u32 opcode, u32 addr, u32 *val) +static void ping(void *info) { - u32 cmd, be = 0xf, bar = 0; - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); +} - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) | - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) | - (bar << IOSF_BAR_SHIFT); +static int vlv_sideband_rw(struct drm_i915_private *dev_priv, +u32 devfn, u32 port, u32 opcode, +u32 addr, u32 *val) +{ + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); + int err; - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock)); + lockdep_assert_held(&dev_priv->sb_lock); + /* Flush the previous comms, just in case it failed last time. */ if (intel_wait_for_register(dev_priv, VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, 5)) { @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, return -EAGAIN; } - I915_WRITE(VLV_IOSF_ADDR, addr); - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val); - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd); + iosf_mbi_punit_acquire(); - if (intel_wait_for_register(dev_priv, - VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, - 5)) { + /* + * Prevent the cpu from sleeping while we use this sideband, otherwise + * the punit may cause a machine hang. + */ + pm_qos_update_request(&dev_priv->sb_qos, 0); + on_each_cpu(ping, NULL, 1); pm_qos_update_request() doesn't wake up the cpus on its own? I wonder kind of latency guarantees it can actually give without doing that. intel_idle plugs into the update to wake up idle cpus, but it is not synchronous.
Re: [Intel-gfx] [PATCH 14/27] drm/i915/icl: Set graphics mode register for gen11
On 09/01/18 15:28, Paulo Zanoni wrote: From: kgardine This patch clears a single bit. The bit is 0 by default but expected not to be set. Explicitly clearing the bit in this patch is intended to indicate some thinking has occurred, and that we want this bit cleared and we are not just excepting the default value. v2 (from Paulo): fix indentation. v3 (from Paulo): rebase. Signed-off-by: kgardine Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_lrc.c | 10 -- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index f383ee5cc592..a16a8a2b17b4 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2597,6 +2597,8 @@ enum i915_power_well_id { #define GFX_FORWARD_VBLANK_ALWAYS (1<<5) #define GFX_FORWARD_VBLANK_COND (2<<5) +#define GEN11_GFX_DISABLE_LEGACY_MODE (1<<3) + #define VLV_DISPLAY_BASE 0x18 #define VLV_MIPI_BASE VLV_DISPLAY_BASE #define BXT_MIPI_BASE 0x6 diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index dab988f20833..d435a9982d0b 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1500,8 +1500,14 @@ static void enable_execlists(struct intel_engine_cs *engine) struct drm_i915_private *dev_priv = engine->i915; I915_WRITE(RING_HWSTAM(engine->mmio_base), 0x); - I915_WRITE(RING_MODE_GEN7(engine), - _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); + + if (IS_GEN11(dev_priv)) INTEL_GEN >= 11? I'd expect this to be valid going forward instead of flipping back to the old value settings. Also we could use a comment, because the bit name is not very clear. Something like: /* * Make sure we're not enabling the new 12-deep CSB * FIFO as that requires a slightly updated handling * in the ctx switch irq. Since we're currently only * using only 2 elements of the enhanced execlists the * deeper FIFO it's not needed and it's not worth adding * more statements to the irq handler to support it. */ Daniele + I915_WRITE(RING_MODE_GEN7(engine), + _MASKED_BIT_DISABLE(GEN11_GFX_DISABLE_LEGACY_MODE)); + else + I915_WRITE(RING_MODE_GEN7(engine), + _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); + I915_WRITE(RING_HWS_PGA(engine->mmio_base), engine->status_page.ggtt_offset); POSTING_READ(RING_HWS_PGA(engine->mmio_base)); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband
On Thu, Jan 11, 2018 at 08:53:42PM +, Chris Wilson wrote: > Quoting Ville Syrjälä (2018-01-11 20:10:45) > > On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote: > > > While we talk to the punit over its sideband, we need to prevent the cpu > > > from sleeping in order to prevent a potential machine hang. > > > > > > Note that by itself, it appears that pm_qos_update_request (via > > > intel_idle) doesn't provide a sufficient barrier to ensure that all core > > > are indeed awake (out of Cstate) and that the package is awake. To do so, > > > we need to supplement the pm_qos with a manual ping on_each_cpu. > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051 > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=102657 > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 > > > Signed-off-by: Chris Wilson > > > Cc: Mika Kuoppala > > > Cc: Hans de Goede > > > --- > > > drivers/gpu/drm/i915/i915_drv.c | 6 > > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > > drivers/gpu/drm/i915/intel_sideband.c | 61 > > > --- > > > 3 files changed, 50 insertions(+), 18 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > b/drivers/gpu/drm/i915/i915_drv.c > > > index 6c8da9d20c33..d4b90cc0130b 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct > > > drm_i915_private *dev_priv, > > > spin_lock_init(&dev_priv->uncore.lock); > > > > > > mutex_init(&dev_priv->sb_lock); > > > + pm_qos_add_request(&dev_priv->sb_qos, > > > +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE); > > > + > > > mutex_init(&dev_priv->modeset_restore_lock); > > > mutex_init(&dev_priv->av_mutex); > > > mutex_init(&dev_priv->wm.wm_mutex); > > > @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct > > > drm_i915_private *dev_priv) > > > intel_irq_fini(dev_priv); > > > i915_workqueues_cleanup(dev_priv); > > > i915_engines_cleanup(dev_priv); > > > + > > > + pm_qos_remove_request(&dev_priv->sb_qos); > > > + mutex_destroy(&dev_priv->sb_lock); > > > } > > > > > > static int i915_mmio_setup(struct drm_i915_private *dev_priv) > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > > b/drivers/gpu/drm/i915/i915_drv.h > > > index a689396d0ff6..ff3f9effc0bb 100644 > > > --- a/drivers/gpu/drm/i915/i915_drv.h > > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > > @@ -1887,6 +1887,7 @@ struct drm_i915_private { > > > > > > /* Sideband mailbox protection */ > > > struct mutex sb_lock; > > > + struct pm_qos_request sb_qos; > > > > > > /** Cached value of IMR to avoid reads in updating the bitfield */ > > > union { > > > diff --git a/drivers/gpu/drm/i915/intel_sideband.c > > > b/drivers/gpu/drm/i915/intel_sideband.c > > > index 75c872bb8cc9..02bdd2e2cef6 100644 > > > --- a/drivers/gpu/drm/i915/intel_sideband.c > > > +++ b/drivers/gpu/drm/i915/intel_sideband.c > > > @@ -22,6 +22,8 @@ > > > * > > > */ > > > > > > +#include > > > + > > > #include "i915_drv.h" > > > #include "intel_drv.h" > > > > > > @@ -39,18 +41,20 @@ > > > /* Private register write, double-word addressing, non-posted */ > > > #define SB_CRWRDA_NP 0x07 > > > > > > -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, > > > -u32 port, u32 opcode, u32 addr, u32 *val) > > > +static void ping(void *info) > > > { > > > - u32 cmd, be = 0xf, bar = 0; > > > - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); > > > +} > > > > > > - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) | > > > - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) > > > | > > > - (bar << IOSF_BAR_SHIFT); > > > +static int vlv_sideband_rw(struct drm_i915_private *dev_priv, > > > +u32 devfn, u32 port, u32 opcode, > > > +u32 addr, u32 *val) > > > +{ > > > + const bool is_read = (opcode == SB_MRD_NP || opcode == > > > SB_CRRDDA_NP); > > > + int err; > > > > > > - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock)); > > > + lockdep_assert_held(&dev_priv->sb_lock); > > > > > > + /* Flush the previous comms, just in case it failed last time. */ > > > if (intel_wait_for_register(dev_priv, > > > VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, > > > 5)) { > > > @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private > > > *dev_priv, u32 devfn, > > > return -EAGAIN; > > > } > > > > > > - I915_WRITE(VLV_IOSF_ADDR, addr); > > > - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val); > > > - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd); > > > + iosf_mbi_punit_acquire(); > > > > > >
Re: [Intel-gfx] [PATCH 20/27] drm/i915/icl: Make use of the SW counter field in the new context descriptor
This could potentially be squashed with patch 15, as it doesn't make much sense to add a TODO there and solve it here. We might also want to update the comment above intel_lr_context_descriptor_update to remove the implication that SW context ID == ctx->hw_id (which is still technically true after this patch but we're preparing for it not to be anymore). Thanks, Daniele On 09/01/18 15:28, Paulo Zanoni wrote: From: Oscar Mateo The new context descriptor format in Gen11 contains two assignable fields: the SW Context ID (technically 11 bits, but practically limited to 2032 entries due to some being reserved for future use by the GuC) and the SW Counter (6 bits). We don't want to limit ourselves too much in the maximum number of concurrent contexts we want to allow, so ideally we want to employ every possible bit available. Unfortunately, a further limitation in the interface with the GuC means the combination of SW Context ID + SW Counter has to be unique within the same engine class (as we use the SW Context ID to index in the GuC stage descriptor pool, and the Engine Class + SW Counter to index in the 2-dimensional lrc array). This essentially means we need to somehow encode the engine instance. Since the BSpec allows 6 bits for engine instance, we use the whole SW counter for this task. If the limitation of 2032 maximum simultaneous contexts is too restrictive, we can always squeeze things a bit more (3 extras bits for hw_id, 3 bits for instance) and things will still work (Gen11 does not instance more than 8 engines of any class). Another alternative would be to generate the hw_id per HW context instead of per GEM context, but that has other problems (e.g. maximum number of user-created contexts would be variable, no relationship between a GuC principal descriptor and the proxy descriptor it uses, etc...). Bspec: 12254 v2: - Squashed with parts of "Interface changes for GuC fw 22.108" (Daniele) - Do not apply the 16 reserved entries limitation to the non-GuC path (Joonas) v3: Rebased by Rodrigo. v4: Rebased (s/i915_modparams.enable_guc_submission/USES_GUC_SUBMISSION(dev_priv)) Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Michal Wajdeczko Cc: Michel Thierry Signed-off-by: Oscar Mateo Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 11 --- drivers/gpu/drm/i915/i915_gem_context.c | 9 ++--- drivers/gpu/drm/i915/i915_gem_context.h | 2 ++ drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_lrc.c| 15 --- 5 files changed, 26 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index aa4f2b178d97..3f1d8c0d2b0a 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2079,11 +2079,16 @@ struct drm_i915_private { /* The hw wants to have a stable context identifier for the * lifetime of the context (for OA, PASID, faults, etc). -* This is limited in execlists to 21 bits. +* This is limited in execlists to 21 bits. In enhanced execlist +* (GEN11+) this is limited to 11 bits (the SW Context ID field) +* but GuC limits it a bit further (11 bits - 16) due to some +* entries being reserved for future use (so the firmware only +* supports a GuC stage descriptor pool of 2032 entries). */ struct ida hw_ida; -#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */ -#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */ +#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */ +#define GEN11_MAX_CONTEXT_HW_ID(1<<11) /* exclusive */ +#define GEN11_MAX_CONTEXT_HW_ID_WITH_GUC GEN11_MAX_CONTEXT_HW_ID - 16 } contexts; u32 fdi_rx_config; diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index dbc50b9e18c9..bb5d070083f5 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -213,9 +213,12 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out) int ret; unsigned int max; - if (INTEL_GEN(dev_priv) >= 11) - max = GEN11_MAX_CONTEXT_HW_ID; - else + if (INTEL_GEN(dev_priv) >= 11) { + if (USES_GUC_SUBMISSION(dev_priv)) + max = GEN11_MAX_CONTEXT_HW_ID_WITH_GUC; + else + max = GEN11_MAX_CONTEXT_HW_ID; + } else max = MAX_CONTEXT_HW_ID; ret = ida_simple_get(&dev_priv->contexts.hw_ida, diff --git a/drivers/gpu/drm/i915/i915_gem_context.h b/drivers/gpu/drm/i915/i915_gem_context.h index 4bfb72f8e1cb..7a39d54e9962 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.h +++ b/drivers/gpu/drm/i915/i915_gem_context.h @@ -156,6 +156,8 @@ struct i915_gem_context {
Re: [Intel-gfx] [PATCH 10/27] drm/i915/icl: Enhanced execution list support
The review from Chris had ended up in my spam folder and I missed it, apologies for duplicating some of the comments. Daniele On 11/01/18 11:55, Daniele Ceraolo Spurio wrote: On 09/01/18 15:28, Paulo Zanoni wrote: From: Thomas Daniel Supports two-element submission using the new enhanced execlist mechanism This could use a few lines to describe enhanced execlist. Something like: "Enhanced Execlists is an upgraded version of execlists which supports up to 8 ports. The lrcs to be submitted are written to a submit queue, which is then loaded on the HW. When writing to the ELSP register, the lrcs are written cyclically in the queue from position 0 to position 7. Alternatively, it is possible to write directly in the individual positions of the queue using the ELSQ registers. To be able to re-use all the existing code we're using the latter method and we're currently limiting ourself to only using 2 elements" v2: Rebase. v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio). v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio) Signed-off-by: Thomas Daniel Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_lrc.c | 21 - drivers/gpu/drm/i915/intel_lrc.h | 3 +++ 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index de41ad2d5fbc..3c6f587fa903 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -430,9 +430,18 @@ static inline void elsp_write(u64 desc, u32 __iomem *elsp) static void execlists_submit_ports(struct intel_engine_cs *engine) { + struct drm_i915_private *dev_priv = engine->i915; struct execlist_port *port = engine->execlists.port; + u32 __iomem *elsq = + engine->i915->regs + i915_mmio_reg_offset(RING_ELSQ(engine)); Should we cache this, like we do for execlists.elsp? unsigned int n; + /* + * Gen11+ note: the submit queue is not cleared after being submitted + * to the HW so we need to make sure we always clean it up. This is + * currently ensured by the fact that we always write the same number + * of elsq entries, keep this in mind before changing the loop below. + */ for (n = execlists_num_ports(&engine->execlists); n--; ) { struct drm_i915_gem_request *rq; unsigned int count; @@ -456,8 +465,18 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) desc = 0; } - elsp_write(desc, engine->execlists.elsp); + if (INTEL_GEN(engine->i915) >= 11) { + writel(lower_32_bits(desc), elsq + n * 2); + writel(upper_32_bits(desc), elsq + n * 2 + 1); + } else { + elsp_write(desc, engine->execlists.elsp); + } } + + /* for gen11+ we need to manually load the submit queue */ + if (INTEL_GEN(engine->i915) >= 11) + I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD); + execlists_clear_active(&engine->execlists, EXECLISTS_ACTIVE_HWACK); } diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h index 6d4f9b995a11..cb00e1dd6ed2 100644 --- a/drivers/gpu/drm/i915/intel_lrc.h +++ b/drivers/gpu/drm/i915/intel_lrc.h @@ -38,6 +38,9 @@ #define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0) #define CTX_CTRL_RS_CTX_ENABLE (1 << 1) #define RING_CONTEXT_STATUS_BUF_BASE(engine) _MMIO((engine)->mmio_base + 0x370) +#define RING_ELSQ(engine) _MMIO((engine)->mmio_base + 0x510) +#define RING_ELCR(engine) _MMIO((engine)->mmio_base + 0x550) Do we need to add the new regs to the forcewake domain identification in logical_ring_setup? They should be in the same well as ELSP so maybe just that one is enough. +#define ELCR_LOAD (1 << 0) > #define RING_CONTEXT_STATUS_BUF_LO(engine, i) _MMIO((engine)->mmio_base + 0x370 + (i) * 8) #define RING_CONTEXT_STATUS_BUF_HI(engine, i) _MMIO((engine)->mmio_base + 0x370 + (i) * 8 + 4) #define RING_CONTEXT_STATUS_PTR(engine) _MMIO((engine)->mmio_base + 0x3a0) Side note, we do have pre-emption enabled in the features but this patch does not update inject_preempt_context to use the new way to submit to the HW, so I guess that's probably break. Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband
Quoting Ville Syrjälä (2018-01-11 20:10:45) > On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote: > > While we talk to the punit over its sideband, we need to prevent the cpu > > from sleeping in order to prevent a potential machine hang. > > > > Note that by itself, it appears that pm_qos_update_request (via > > intel_idle) doesn't provide a sufficient barrier to ensure that all core > > are indeed awake (out of Cstate) and that the package is awake. To do so, > > we need to supplement the pm_qos with a manual ping on_each_cpu. > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051 > > References: https://bugs.freedesktop.org/show_bug.cgi?id=102657 > > References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > Cc: Hans de Goede > > --- > > drivers/gpu/drm/i915/i915_drv.c | 6 > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > drivers/gpu/drm/i915/intel_sideband.c | 61 > > --- > > 3 files changed, 50 insertions(+), 18 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > b/drivers/gpu/drm/i915/i915_drv.c > > index 6c8da9d20c33..d4b90cc0130b 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.c > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct > > drm_i915_private *dev_priv, > > spin_lock_init(&dev_priv->uncore.lock); > > > > mutex_init(&dev_priv->sb_lock); > > + pm_qos_add_request(&dev_priv->sb_qos, > > +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE); > > + > > mutex_init(&dev_priv->modeset_restore_lock); > > mutex_init(&dev_priv->av_mutex); > > mutex_init(&dev_priv->wm.wm_mutex); > > @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct > > drm_i915_private *dev_priv) > > intel_irq_fini(dev_priv); > > i915_workqueues_cleanup(dev_priv); > > i915_engines_cleanup(dev_priv); > > + > > + pm_qos_remove_request(&dev_priv->sb_qos); > > + mutex_destroy(&dev_priv->sb_lock); > > } > > > > static int i915_mmio_setup(struct drm_i915_private *dev_priv) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index a689396d0ff6..ff3f9effc0bb 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++ b/drivers/gpu/drm/i915/i915_drv.h > > @@ -1887,6 +1887,7 @@ struct drm_i915_private { > > > > /* Sideband mailbox protection */ > > struct mutex sb_lock; > > + struct pm_qos_request sb_qos; > > > > /** Cached value of IMR to avoid reads in updating the bitfield */ > > union { > > diff --git a/drivers/gpu/drm/i915/intel_sideband.c > > b/drivers/gpu/drm/i915/intel_sideband.c > > index 75c872bb8cc9..02bdd2e2cef6 100644 > > --- a/drivers/gpu/drm/i915/intel_sideband.c > > +++ b/drivers/gpu/drm/i915/intel_sideband.c > > @@ -22,6 +22,8 @@ > > * > > */ > > > > +#include > > + > > #include "i915_drv.h" > > #include "intel_drv.h" > > > > @@ -39,18 +41,20 @@ > > /* Private register write, double-word addressing, non-posted */ > > #define SB_CRWRDA_NP 0x07 > > > > -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, > > -u32 port, u32 opcode, u32 addr, u32 *val) > > +static void ping(void *info) > > { > > - u32 cmd, be = 0xf, bar = 0; > > - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); > > +} > > > > - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) | > > - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) | > > - (bar << IOSF_BAR_SHIFT); > > +static int vlv_sideband_rw(struct drm_i915_private *dev_priv, > > +u32 devfn, u32 port, u32 opcode, > > +u32 addr, u32 *val) > > +{ > > + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); > > + int err; > > > > - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock)); > > + lockdep_assert_held(&dev_priv->sb_lock); > > > > + /* Flush the previous comms, just in case it failed last time. */ > > if (intel_wait_for_register(dev_priv, > > VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, > > 5)) { > > @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private > > *dev_priv, u32 devfn, > > return -EAGAIN; > > } > > > > - I915_WRITE(VLV_IOSF_ADDR, addr); > > - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val); > > - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd); > > + iosf_mbi_punit_acquire(); > > > > - if (intel_wait_for_register(dev_priv, > > - VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, > > - 5)) { > > + /* > > + * Prevent the cpu from sleeping while we use this sideband, otherwise > > + * the punit may cause a machine hang.
Re: [Intel-gfx] [PATCH 1/8] drm/i915/cnl: Add Port F definition.
On Thu, Jan 11, 2018 at 06:00:03PM +, Paulo Zanoni wrote: > From: Rodrigo Vivi > > Some Cannonlake SKUs will come with a full split between > port A and port E. This will be called port F although it > is not a 6th port, but only a split. > > Note this patch alone is not sufficient for port F enabling, > it's just the first step. > > v2: Fix size of dvo_ports found by Ander. > v3: Adding missing cases from intel_bios.c for Port_F > v4: Adding other missing cases and fix the commit message. > v5: Rebase on top of display headers rework. > v6 (from Paulo): improve commit message, bikeshed bit definitions. Acked-by: Rodrigo Vivi Thanks > > Cc: Lucas De Marchi > Cc: Manasi Navare > Reviewed-by: Paulo Zanoni > Signed-off-by: Rodrigo Vivi > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_bios.c | 9 + > drivers/gpu/drm/i915/intel_display.h | 1 + > drivers/gpu/drm/i915/intel_dp.c | 2 ++ > drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ > include/drm/i915_component.h | 3 +-- > 5 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index 51108ffc28d1..59a150e2adce 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1140,6 +1140,7 @@ static void parse_ddi_port(struct drm_i915_private > *dev_priv, enum port port, > {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}, > }; > > /* > @@ -1688,6 +1689,7 @@ bool intel_bios_is_port_present(struct drm_i915_private > *dev_priv, enum port por > [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, }, > [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, }, > [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, }, > + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, }, > }; > int i; > > @@ -1726,6 +1728,7 @@ bool intel_bios_is_port_edp(struct drm_i915_private > *dev_priv, enum port port) > [PORT_C] = DVO_PORT_DPC, > [PORT_D] = DVO_PORT_DPD, > [PORT_E] = DVO_PORT_DPE, > + [PORT_F] = DVO_PORT_DPF, > }; > int i; > > @@ -1761,6 +1764,7 @@ static bool child_dev_is_dp_dual_mode(const struct > child_device_config *child, > [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, }, > [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, }, > [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, }, > + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, }, > }; > > if (port == PORT_A || port >= ARRAY_SIZE(port_mapping)) > @@ -1927,6 +1931,11 @@ intel_bios_is_lspcon_present(struct drm_i915_private > *dev_priv, > if (port == PORT_D) > return true; > break; > + case DVO_PORT_DPF: > + case DVO_PORT_HDMIF: > + if (port == PORT_F) > + return true; > + break; > default: > break; > } > diff --git a/drivers/gpu/drm/i915/intel_display.h > b/drivers/gpu/drm/i915/intel_display.h > index a0d2b6169361..e47638931b51 100644 > --- a/drivers/gpu/drm/i915/intel_display.h > +++ b/drivers/gpu/drm/i915/intel_display.h > @@ -119,6 +119,7 @@ enum port { > PORT_C, > PORT_D, > PORT_E, > + PORT_F, > > I915_MAX_PORTS > }; > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 68229f53d5b8..46937a8c48cc 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1402,6 +1402,7 @@ static i915_reg_t skl_aux_ctl_reg(struct > drm_i915_private *dev_priv, > case PORT_B: > case PORT_C: > case PORT_D: > + case PORT_F: > return DP_AUX_CH_CTL(port); > default: > MISSING_CASE(port); > @@ -1417,6 +1418,7 @@ static i915_reg_t skl_aux_data_reg(struct > drm_i915_private *dev_priv, > case PORT_B: > case PORT_C: > case PORT_D: > + case PORT_F: > return DP_AUX_CH_DATA(port, index); > default: > MISSING_CASE(port); > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > b/drivers/gpu/drm/i915/intel_vbt_defs.h > index e3d7745a9151..b5d2341f932c 100644 > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > @@ -299,6 +299,8 @@ struct bdb_general_features { > #define DVO_PORT_DPA 10 > #define DVO_PORT_DPE 11 /* 193 */ > #define DVO_PORT_HDMIE 12 /* 193 > */ > +#define DVO_PORT_DPF 13 /* N/A */ > +#define DVO_PORT_HDMIF 14
[Intel-gfx] [PATCH v2 0/6] drm/i915: expose RCS topology to userspace
Hi all, Tvrtko found a few bugs in the previous iteration of this series and also made quite a few recommendations on the stored internal state as well uapi, so here is an update. Details in the patches. Thanks a lot, Lionel Landwerlin (6): drm/i915: store all subslice masks drm/i915/debugfs: reuse max slice/subslices already stored in sseu drm/i915/debugfs: add rcs topology entry drm/i915: add rcs topology to error state drm/i915: add query uAPI drm/i915: expose rcs topology through query uAPI drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/i915_debugfs.c | 94 +++ drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_gpu_error.c| 40 +++ drivers/gpu/drm/i915/i915_query.c| 184 + drivers/gpu/drm/i915/intel_device_info.c | 196 +++ drivers/gpu/drm/i915/intel_device_info.h | 36 +- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/intel_query_info.c | 88 ++ drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- include/uapi/drm/i915_drm.h | 82 + 12 files changed, 652 insertions(+), 79 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_query.c create mode 100644 drivers/gpu/drm/i915/intel_query_info.c -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v13] tests/kms_frontbuffer_tracking: Including DRRS test coverage
On Thu, Jan 11, 2018 at 05:27:52AM +, Ramalingam C wrote: > > > On Wednesday 10 January 2018 11:45 PM, Rodrigo Vivi wrote: > > On Wed, Jan 10, 2018 at 02:47:00PM +, Lohith BS wrote: > > Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's > refresh rate to the lowest vrefresh supported by panel, when frame is > not flipped for more than a Sec. > > In kernel, DRRS uses the front buffer tracking infrastructure. > Hence DRRS test coverage is added along with other frontbuffer > tracking > based features such as FBC and PSR tests. > > Here, we are testing DRRS with other features in all possible > combinations, in all required test cases, to capture any possible > regression. > > v2: Addressed the comments and suggestions from Vlad, Marius. > The signoff details from the earlier work are also included. > > v3: Modified vblank rate calculation by using reply-sequence, > provided by drmWaitVBlank, as suggested by Chris Wilson. > > v4: As suggested from Chris Wilson and Daniel Vetter > 1) Avoided using pthread for calculating vblank refresh rate, >instead used drmWaitVBlank reply sequence. > 2) Avoided using kernel-specific info like transitional delays, >instead polling mechanism with timeout is used. > 3) Included edp-DRRS as a subtest in kms_frontbuffer_tracking.c, >instead of having a separate test. > > v5: This patch adds DRRS as a new feature in the > kms_frontbuffer_tracking IGT. > DRRS switch to lower vrefresh rate is tested at slow-draw subtest. > > Note: > 1) Currently kernel doesn't have support to enable and disable >the DRRS feature dynamically(as in case of PSR). Hence if the >panel supports DRRS it will be enabled by default. > > This is in continuation of last patch > "https://patchwork.freedesktop.org/patch/162726/"; > > v6: This patch adds runtime enable and disable feature for testing > DRRS > > v7: This patch adds runtime enable and disable feature for testing > DRRS > through debugfs entry "i915_drrs_ctl". > > v8: Commit message is updated to reflect current implementation. > > v9: Addressed Paulo Zanoni comments. > Check for DRRS_LOW at tests with OFFSCREEN + FBS_INDIVIDUAL. > > v10: Corrected DRRS state expectation in suspend related subtests. > > v11: Removing the global flag is_psr_drrs_combo [Rodrigo]. > > v12: Rewriting the DRRS inactive deduction [Rodrigo]. > > v13: En/Dis-able DRRS only when DRRS is capable on the setup. > > Signed-off-by: Lohith BS > Signed-off-by: aknautiy > --- > tests/kms_frontbuffer_tracking.c | 172 > +-- > 1 file changed, 164 insertions(+), 8 deletions(-) > > diff --git a/tests/kms_frontbuffer_tracking.c > b/tests/kms_frontbuffer_tracking.c > index 1601cab..6b2299b 100644 > --- a/tests/kms_frontbuffer_tracking.c > +++ b/tests/kms_frontbuffer_tracking.c > @@ -34,7 +34,7 @@ > > > IGT_TEST_DESCRIPTION("Test the Kernel's frontbuffer tracking > mechanism and " > -"its related features: FBC and PSR"); > +"its related features: FBC, PSR and DRRS"); > > /* > * One of the aspects of this test is that, for every subtest, we > try different > @@ -105,8 +105,9 @@ struct test_mode { > FEATURE_NONE = 0, > FEATURE_FBC = 1, > FEATURE_PSR = 2, > - FEATURE_COUNT = 4, > - FEATURE_DEFAULT = 4, > + FEATURE_DRRS = 4, > + FEATURE_COUNT = 8, > + FEATURE_DEFAULT = 8, > } feature; > > /* Possible pixel formats. We just use FORMAT_DEFAULT for > most tests and > @@ -182,6 +183,13 @@ struct { > .can_test = false, > }; > > +#define MAX_DRRS_STATUS_BUF_LEN 256 > + > +struct { > + bool can_test; > +} drrs = { > + .can_test = false, > +}; > > #define SINK_CRC_SIZE 12 > typedef struct { > @@ -790,7 +798,14 @@ static void __debugfs_read(const char *param, > char *buf, int len) > buf[len] = '\0'; > } > > +static void __debugfs_write(const char *param, char *buf, int len) > +{ > + igt_assert_eq(igt_sysfs_write(drm.debugfs, param, buf, len - > 1), > + len - 1); > +} > + > #define debu
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband
On Wed, Jan 10, 2018 at 12:55:05PM +, Chris Wilson wrote: > While we talk to the punit over its sideband, we need to prevent the cpu > from sleeping in order to prevent a potential machine hang. > > Note that by itself, it appears that pm_qos_update_request (via > intel_idle) doesn't provide a sufficient barrier to ensure that all core > are indeed awake (out of Cstate) and that the package is awake. To do so, > we need to supplement the pm_qos with a manual ping on_each_cpu. > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051 > References: https://bugs.freedesktop.org/show_bug.cgi?id=102657 > References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > Cc: Hans de Goede > --- > drivers/gpu/drm/i915/i915_drv.c | 6 > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/intel_sideband.c | 61 > --- > 3 files changed, 50 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 6c8da9d20c33..d4b90cc0130b 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private > *dev_priv, > spin_lock_init(&dev_priv->uncore.lock); > > mutex_init(&dev_priv->sb_lock); > + pm_qos_add_request(&dev_priv->sb_qos, > +PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE); > + > mutex_init(&dev_priv->modeset_restore_lock); > mutex_init(&dev_priv->av_mutex); > mutex_init(&dev_priv->wm.wm_mutex); > @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct > drm_i915_private *dev_priv) > intel_irq_fini(dev_priv); > i915_workqueues_cleanup(dev_priv); > i915_engines_cleanup(dev_priv); > + > + pm_qos_remove_request(&dev_priv->sb_qos); > + mutex_destroy(&dev_priv->sb_lock); > } > > static int i915_mmio_setup(struct drm_i915_private *dev_priv) > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index a689396d0ff6..ff3f9effc0bb 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1887,6 +1887,7 @@ struct drm_i915_private { > > /* Sideband mailbox protection */ > struct mutex sb_lock; > + struct pm_qos_request sb_qos; > > /** Cached value of IMR to avoid reads in updating the bitfield */ > union { > diff --git a/drivers/gpu/drm/i915/intel_sideband.c > b/drivers/gpu/drm/i915/intel_sideband.c > index 75c872bb8cc9..02bdd2e2cef6 100644 > --- a/drivers/gpu/drm/i915/intel_sideband.c > +++ b/drivers/gpu/drm/i915/intel_sideband.c > @@ -22,6 +22,8 @@ > * > */ > > +#include > + > #include "i915_drv.h" > #include "intel_drv.h" > > @@ -39,18 +41,20 @@ > /* Private register write, double-word addressing, non-posted */ > #define SB_CRWRDA_NP 0x07 > > -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, > -u32 port, u32 opcode, u32 addr, u32 *val) > +static void ping(void *info) > { > - u32 cmd, be = 0xf, bar = 0; > - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); > +} > > - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) | > - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) | > - (bar << IOSF_BAR_SHIFT); > +static int vlv_sideband_rw(struct drm_i915_private *dev_priv, > +u32 devfn, u32 port, u32 opcode, > +u32 addr, u32 *val) > +{ > + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); > + int err; > > - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock)); > + lockdep_assert_held(&dev_priv->sb_lock); > > + /* Flush the previous comms, just in case it failed last time. */ > if (intel_wait_for_register(dev_priv, > VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, > 5)) { > @@ -59,22 +63,43 @@ static int vlv_sideband_rw(struct drm_i915_private > *dev_priv, u32 devfn, > return -EAGAIN; > } > > - I915_WRITE(VLV_IOSF_ADDR, addr); > - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val); > - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd); > + iosf_mbi_punit_acquire(); > > - if (intel_wait_for_register(dev_priv, > - VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0, > - 5)) { > + /* > + * Prevent the cpu from sleeping while we use this sideband, otherwise > + * the punit may cause a machine hang. > + */ > + pm_qos_update_request(&dev_priv->sb_qos, 0); > + on_each_cpu(ping, NULL, 1); pm_qos_update_request() doesn't wake up the cpus on its own? I wonder kind of latency guarantees it can actually give without doing that. Shouldn't we check if we're actually be talking to
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Disable preemption and sleeping while using the punit sideband
Hi, On 10-01-18 14:18, Hans de Goede wrote: Hi, On 10-01-18 13:55, Chris Wilson wrote: While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to ensure that all core are indeed awake (out of Cstate) and that the package is awake. To do so, we need to supplement the pm_qos with a manual ping on_each_cpu. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051 References: https://bugs.freedesktop.org/show_bug.cgi?id=102657 References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Hans de Goede Interesting, I've added similar pm_qos code in drivers/i2c/busses/i2c-designware-baytrail.c quite a while ago because the CPU transitioning to higher C-state while accessing the i2c bus to the pmic (if it is shared) also causes the SoC to hang. I could reproduce this quite easily by doing "i2cdump" on the pmic, usually the system would hang in one or 2 i2cdump calls. Note IIRC this was on CHT. I see that you also block any pmic-i2c bus accesses while doing punit access by calling iosf_mbi_punit_acquire(); Maybe we need to move the pm_qos stuff out of drivers/i2c/busses/i2c-designware-baytrail.c And into iosf_mbi_punit_acquire? The i2c-designware-baytrail.c does its own pm_qos dance directly after calling iosf_mbi_punit_acquire / before calling iosf_mbi_punit_release(); I just remembered that the i915 code also call iosf_mbi_punit_acquire() from drivers/gpu/drm/i915/intel_uncore.c and does it for non VLV/CHT boards there too. Currently that is not an issue because iosf_mbi_punit_acquire() currently is a nop for non VLV/CHT, but if we move the pm_qos stuff there then it no longer is a nop, so it is probably best to keep separate pm_qos code in intel_sideband.c and i2c-designware-baytrail.c, iow move ahead with this patch as as, except for maybe moving the ping stuff to the intel_idle.c code. Regards, Hans --- drivers/gpu/drm/i915/i915_drv.c | 6 drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_sideband.c | 61 --- 3 files changed, 50 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 6c8da9d20c33..d4b90cc0130b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv, spin_lock_init(&dev_priv->uncore.lock); mutex_init(&dev_priv->sb_lock); + pm_qos_add_request(&dev_priv->sb_qos, + PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE); + mutex_init(&dev_priv->modeset_restore_lock); mutex_init(&dev_priv->av_mutex); mutex_init(&dev_priv->wm.wm_mutex); @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv) intel_irq_fini(dev_priv); i915_workqueues_cleanup(dev_priv); i915_engines_cleanup(dev_priv); + + pm_qos_remove_request(&dev_priv->sb_qos); + mutex_destroy(&dev_priv->sb_lock); } static int i915_mmio_setup(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a689396d0ff6..ff3f9effc0bb 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1887,6 +1887,7 @@ struct drm_i915_private { /* Sideband mailbox protection */ struct mutex sb_lock; + struct pm_qos_request sb_qos; /** Cached value of IMR to avoid reads in updating the bitfield */ union { diff --git a/drivers/gpu/drm/i915/intel_sideband.c b/drivers/gpu/drm/i915/intel_sideband.c index 75c872bb8cc9..02bdd2e2cef6 100644 --- a/drivers/gpu/drm/i915/intel_sideband.c +++ b/drivers/gpu/drm/i915/intel_sideband.c @@ -22,6 +22,8 @@ * */ +#include + #include "i915_drv.h" #include "intel_drv.h" @@ -39,18 +41,20 @@ /* Private register write, double-word addressing, non-posted */ #define SB_CRWRDA_NP 0x07 -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn, - u32 port, u32 opcode, u32 addr, u32 *val) +static void ping(void *info) { - u32 cmd, be = 0xf, bar = 0; - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); +} - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) | - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) | - (bar << IOSF_BAR_SHIFT); +static int vlv_sideband_rw(struct drm_i915_private *dev_priv, + u32 devfn, u32 port, u32 opcode, + u32 addr, u32 *val) +{ + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP); + int err; - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock)); + lockdep_assert_held(&dev_priv->sb_lock); + /* Flush the previous comms, just in cas
[Intel-gfx] [PATCH v2 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu
Now that we have that information in topology fields, let's just reused it. v2: Style tweaks (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 27 +++ 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 463029f72a0b..2d1c9cce5fe4 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4300,11 +4300,11 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { const struct intel_device_info *info = INTEL_INFO(dev_priv); - int s_max = 6, ss_max = 4; int s, ss; - u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2]; + u32 s_reg[info->sseu.max_slices]; + u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2]; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { /* * FIXME: Valid SS Mask respects the spec and read * only valid bits for those registers, excluding reserverd @@ -4326,7 +4326,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4334,7 +4334,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); sseu->subslice_mask[s] = info->sseu.subslice_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss @@ -4354,17 +4354,12 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { - int s_max = 3, ss_max = 4; + const struct intel_device_info *info = INTEL_INFO(dev_priv); int s, ss; - u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2]; - - /* BXT has a single slice and at most 3 subslices. */ - if (IS_GEN9_LP(dev_priv)) { - s_max = 1; - ss_max = 3; - } + u32 s_reg[info->sseu.max_slices]; + u32 eu_reg[2 * info->sseu.max_subslices], eu_mask[2]; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s)); eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s)); eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s)); @@ -4379,7 +4374,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4390,7 +4385,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->subslice_mask[s] = INTEL_INFO(dev_priv)->sseu.subslice_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (IS_GEN9_LP(dev_priv)) { -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/6] drm/i915: add rcs topology to error state
This might be useful information for developers looking at an error state. v2: Place topology towards the end of the error state (Chris) Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_gpu_error.c | 40 +++ 1 file changed, 40 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 944059322daa..cc7f53cc9a77 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -605,6 +605,45 @@ static void err_print_uc(struct drm_i915_error_state_buf *m, print_error_obj(m, NULL, "GuC log buffer", error_uc->guc_log); } +static void err_print_rcs_topology(struct drm_i915_error_state_buf *m, + const struct sseu_dev_info *sseu) +{ + int s, ss; + int subslice_stride = + DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE); + + /* Unavailable prior to Gen 8. */ + if (sseu->max_slices == 0) + return; + + err_printf(m, "RCS topology:\n"); + + for (s = 0; s < sseu->max_slices; s++) { + err_printf(m, " slice%i %u subslice(s) (0x%hhx):\n", + s, hweight8(sseu->subslice_mask[s]), + sseu->subslice_mask[s]); + + for (ss = 0; ss < sseu->max_subslices; ss++) { + int eu_group, n_subslice_eus = 0; + + for (eu_group = 0; eu_group < subslice_stride; eu_group++) { + n_subslice_eus += + hweight8(sseu_eu_mask(sseu, s, ss, eu_group)); + } + + err_printf(m, "subslice%i: %u EUs (", ss, n_subslice_eus); + for (eu_group = 0; +eu_group < max(0, subslice_stride - 1); +eu_group++) { + u8 val = sseu_eu_mask(sseu, s, ss, eu_group); + err_printf(m, " 0x%hhx", val); + } + err_printf(m, "0x%hhx)\n", + sseu_eu_mask(sseu, s, ss, subslice_stride - 1)); + } + } +} + int i915_error_state_to_str(struct drm_i915_error_state_buf *m, const struct i915_gpu_state *error) { @@ -787,6 +826,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf *m, intel_display_print_error_state(m, error->display); err_print_capabilities(m, &error->device_info); + err_print_rcs_topology(m, &INTEL_INFO(dev_priv)->sseu); err_print_params(m, &error->params); err_print_uc(m, &error->uc); -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/6] drm/i915: store all subslice masks
Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all slices. v2: Rework how we store total numbers in sseu_dev_info (Tvrtko) Fix CHV eu masks, was reading disabled as enabled (Tvrtko) Readability changes (Tvrtko) Add EU index helper (Tvrtko) Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 25 ++-- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/intel_device_info.c | 196 +++ drivers/gpu/drm/i915/intel_device_info.h | 36 +- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 6 files changed, 200 insertions(+), 63 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 2bb63073d73f..463029f72a0b 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4285,7 +4285,7 @@ static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask = BIT(0); - sseu->subslice_mask |= BIT(ss); + sseu->subslice_mask[0] |= BIT(ss); eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) + @@ -4332,7 +4332,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask |= BIT(s); - sseu->subslice_mask = info->sseu.subslice_mask; + sseu->subslice_mask[s] = info->sseu.subslice_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4387,8 +4387,8 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); if (IS_GEN9_BC(dev_priv)) - sseu->subslice_mask = - INTEL_INFO(dev_priv)->sseu.subslice_mask; + sseu->subslice_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslice_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4398,7 +4398,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, /* skip disabled subslice */ continue; - sseu->subslice_mask |= BIT(ss); + sseu->subslice_mask[s] |= BIT(ss); } eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & @@ -4420,9 +4420,12 @@ static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK; if (sseu->slice_mask) { - sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask; sseu->eu_per_subslice = INTEL_INFO(dev_priv)->sseu.eu_per_subslice; + for (s = 0; s < fls(sseu->slice_mask); s++) { + sseu->subslice_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslice_mask[s]; + } sseu->eu_total = sseu->eu_per_subslice * sseu_subslice_total(sseu); @@ -4441,6 +,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, { struct drm_i915_private *dev_priv = node_to_i915(m->private); const char *type = is_available_info ? "Available" : "Enabled"; + int s; seq_printf(m, " %s Slice Mask: %04x\n", type, sseu->slice_mask); @@ -4448,10 +4452,11 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, hweight8(sseu->slice_mask)); seq_printf(m, " %s Subslice Total: %u\n", type, sseu_subslice_total(sseu)); - seq_printf(m, " %s Subslice Mask: %04x\n", type, - sseu->subslice_mask); - seq_printf(m, " %s Subslice Per Slice: %u\n", type, - hweight8(sseu->subslice_mask)); + for (s = 0; s < fls(sseu->slice_mask); s++) { + seq_printf(m, " %s Slice%i %u subslices, mask=%04x\n", type, + s, hweight8(sseu->subslice_mask[s]), + sseu->subslice_mask[s]); + } seq_printf(m, " %s EU Total: %u\n", type, sseu->eu_total); seq_printf(m, " %s EU Per Subslice: %u\n", type, diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gp
Re: [Intel-gfx] [PATCH v3] drm/i915/icl: Gen11 render context size
On Thu, Jan 11, 2018 at 06:23:20PM +, Oscar Mateo wrote: > From: Tvrtko Ursulin > > Gen11 removes the Resource Streamer, which frees up a big chunk of > the context image. BSpec indicates 12538 DWORDs (13 pages), plus > one page for PPHWSP. > > Please notice that, when looking at the BSpec context image table, > the right filter has to be applied (e.g. "IcelakeLP") as some rows > are excluded for specific GENs. Also, some rows apply per-subslice > (for the calculation above, we have supposed 8 subslices which is > the maximum SKU we expect). > > v2: Rebase. > v3: Use the right size as per the BSpec. > > BSpec: 18907 > > Acked-by: Ben Widawsky > Signed-off-by: Tvrtko Ursulin > Signed-off-by: Oscar Mateo > --- > drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > b/drivers/gpu/drm/i915/intel_engine_cs.c > index e88b2fd..79b7d36 100644 > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > @@ -41,6 +41,7 @@ > #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE) > #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE) > #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) > +#define GEN11_LR_CONTEXT_RENDER_SIZE (14 * PAGE_SIZE) > > #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE) > > @@ -181,6 +182,8 @@ struct engine_info { > switch (INTEL_GEN(dev_priv)) { > default: > MISSING_CASE(INTEL_GEN(dev_priv)); I believe this default is getting danger as we decrease the size here. I believe the safest one for missing case is the largest one whatever that is. > + case 11: > + return GEN11_LR_CONTEXT_RENDER_SIZE; > case 10: > return GEN10_LR_CONTEXT_RENDER_SIZE; > case 9: > -- > 1.9.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 10/27] drm/i915/icl: Enhanced execution list support
On 09/01/18 15:28, Paulo Zanoni wrote: From: Thomas Daniel Supports two-element submission using the new enhanced execlist mechanism This could use a few lines to describe enhanced execlist. Something like: "Enhanced Execlists is an upgraded version of execlists which supports up to 8 ports. The lrcs to be submitted are written to a submit queue, which is then loaded on the HW. When writing to the ELSP register, the lrcs are written cyclically in the queue from position 0 to position 7. Alternatively, it is possible to write directly in the individual positions of the queue using the ELSQ registers. To be able to re-use all the existing code we're using the latter method and we're currently limiting ourself to only using 2 elements" v2: Rebase. v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio). v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio) Signed-off-by: Thomas Daniel Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_lrc.c | 21 - drivers/gpu/drm/i915/intel_lrc.h | 3 +++ 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index de41ad2d5fbc..3c6f587fa903 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -430,9 +430,18 @@ static inline void elsp_write(u64 desc, u32 __iomem *elsp) static void execlists_submit_ports(struct intel_engine_cs *engine) { + struct drm_i915_private *dev_priv = engine->i915; struct execlist_port *port = engine->execlists.port; + u32 __iomem *elsq = + engine->i915->regs + i915_mmio_reg_offset(RING_ELSQ(engine)); Should we cache this, like we do for execlists.elsp? unsigned int n; + /* +* Gen11+ note: the submit queue is not cleared after being submitted +* to the HW so we need to make sure we always clean it up. This is +* currently ensured by the fact that we always write the same number +* of elsq entries, keep this in mind before changing the loop below. +*/ for (n = execlists_num_ports(&engine->execlists); n--; ) { struct drm_i915_gem_request *rq; unsigned int count; @@ -456,8 +465,18 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) desc = 0; } - elsp_write(desc, engine->execlists.elsp); + if (INTEL_GEN(engine->i915) >= 11) { + writel(lower_32_bits(desc), elsq + n * 2); + writel(upper_32_bits(desc), elsq + n * 2 + 1); + } else { + elsp_write(desc, engine->execlists.elsp); + } } + + /* for gen11+ we need to manually load the submit queue */ + if (INTEL_GEN(engine->i915) >= 11) + I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD); + execlists_clear_active(&engine->execlists, EXECLISTS_ACTIVE_HWACK); } diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h index 6d4f9b995a11..cb00e1dd6ed2 100644 --- a/drivers/gpu/drm/i915/intel_lrc.h +++ b/drivers/gpu/drm/i915/intel_lrc.h @@ -38,6 +38,9 @@ #define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0) #define CTX_CTRL_RS_CTX_ENABLE(1 << 1) #define RING_CONTEXT_STATUS_BUF_BASE(engine) _MMIO((engine)->mmio_base + 0x370) +#define RING_ELSQ(engine) _MMIO((engine)->mmio_base + 0x510) +#define RING_ELCR(engine) _MMIO((engine)->mmio_base + 0x550) Do we need to add the new regs to the forcewake domain identification in logical_ring_setup? They should be in the same well as ELSP so maybe just that one is enough. +#define ELCR_LOAD(1 << 0) > #define RING_CONTEXT_STATUS_BUF_LO(engine, i) _MMIO((engine)->mmio_base + 0x370 + (i) * 8) #define RING_CONTEXT_STATUS_BUF_HI(engine, i) _MMIO((engine)->mmio_base + 0x370 + (i) * 8 + 4) #define RING_CONTEXT_STATUS_PTR(engine) _MMIO((engine)->mmio_base + 0x3a0) Side note, we do have pre-emption enabled in the features but this patch does not update inject_preempt_context to use the new way to submit to the HW, so I guess that's probably break. Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/6] drm/i915: expose rcs topology through query uAPI
With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts of the GPU with the OA unit, because counters need to be normalized to the number of EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do not gives us sufficient information. As a bonus we can draw representations of the GPU : https://imgur.com/a/vuqpa v2: Rename uapi struct s/_mask/_info/ (Tvrtko) Report max_slice/subslice/eus_per_subslice rather than strides (Tvrtko) Add uapi macros to read data from *_info structs (Tvrtko) Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_query.c | 133 drivers/gpu/drm/i915/intel_query_info.c | 88 + include/uapi/drm/i915_drm.h | 51 3 files changed, 272 insertions(+) create mode 100644 drivers/gpu/drm/i915/intel_query_info.c diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index 5694cfea4553..1d9f5a15323c 100644 --- a/drivers/gpu/drm/i915/i915_query.c +++ b/drivers/gpu/drm/i915/i915_query.c @@ -25,8 +25,128 @@ #include "i915_drv.h" #include +static int query_slices_info(struct drm_i915_private *dev_priv, +struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_slices_info slices_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; + + data_length = sizeof(u8); + length = sizeof(slices_info) + data_length; + + /* +* If we ever change the internal slice mask data type, we'll need to +* update this function. +*/ + BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask)); + + if (query_item->length == 0) { + query_item->length = length; + return 0; + } + + if (query_item->length != length) + return -EINVAL; + + memset(&slices_info, 0, sizeof(slices_info)); + slices_info.max_slices = sseu->max_slices; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), &slices_info, +sizeof(slices_info))) + return -EFAULT; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + +offsetof(struct drm_i915_query_slices_info, data)), +&sseu->slice_mask, data_length)) + return -EFAULT; + + return 0; +} + +static int query_subslices_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_subslices_info subslices_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&subslices_info, 0, sizeof(subslices_info)); + subslices_info.max_slices = sseu->max_slices; + subslices_info.max_subslices = sseu->max_subslices; + + data_length = subslices_info.max_slices * + DIV_ROUND_UP(subslices_info.max_subslices, BITS_PER_BYTE); + length = sizeof(subslices_info) + data_length; + + if (query_item->length == 0) { + query_item->length = length; + return 0; + } + + if (query_item->length != length) + return -EINVAL; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), &subslices_info, +sizeof(subslices_info))) + return -EFAULT; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + +offsetof(struct drm_i915_query_subslices_info, data)), +sseu->subslice_mask, data_length)) + return -EFAULT; + + return 0; +} + +static int query_eus_info(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_eus_info eus_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&eus_info, 0, sizeof(eus_info)); + eus_info.max_slices = sseu->max_slices; + eus_info.max_subslices = sseu->max_subslices; + eus_info.max_eus_per_subslice = sseu->max_eus_per_subslice; + + data_length = eus_info.max_slices * eus_info.max_subslices * + DIV_ROUND_UP(eus_info.max_eus_per_subslice, BITS_PER_BYTE); + length = sizeof(eus_info) + data_length; + + if (query_item->length == 0) { + query_item->length = length; +
[Intel-gfx] [PATCH v2 5/6] drm/i915: add query uAPI
There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die recovery). At the moment the GET_PARAM ioctl covers some basic needs, but generally is only able to return a single value for each defined parameter. This is a bit problematic with topology descriptions which are array/maps of available units. This change introduces a new ioctl that can deal with requests to fill structures of potentially variable lengths. The user is expected fill a query with length fields set at 0 on the first call, the kernel then sets the length fields to the their expected values. A second call to the kernel with length fields at their expected values will trigger a copy of the data to the pointed memory locations. The scope of this uAPI is only to provide information to userspace, not to allow configuration of the device. v2: Simplify dispatcher code iteration (Tvrtko) Tweak uapi drm_i915_query_item structure (Tvrtko) Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/i915_query.c | 51 +++ include/uapi/drm/i915_drm.h | 31 5 files changed, 87 insertions(+) create mode 100644 drivers/gpu/drm/i915/i915_query.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 3bddd8a06806..b0415a3e2d59 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \ i915_gem_timeline.o \ i915_gem_userptr.o \ i915_gemfs.o \ + i915_query.o \ i915_trace_points.o \ i915_vma.o \ intel_breadcrumbs.o \ diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 969835d3cbcd..d92e1b7236fc 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -2824,6 +2824,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), }; static struct drm_driver driver = { diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a689396d0ff6..de0eb6ce2fcd 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3623,6 +3623,9 @@ extern void i915_perf_fini(struct drm_i915_private *dev_priv); extern void i915_perf_register(struct drm_i915_private *dev_priv); extern void i915_perf_unregister(struct drm_i915_private *dev_priv); +/* i915_query.c */ +int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file); + /* i915_suspend.c */ extern int i915_save_state(struct drm_i915_private *dev_priv); extern int i915_restore_state(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c new file mode 100644 index ..5694cfea4553 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_query.c @@ -0,0 +1,51 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ + +#include "i915_drv.h" +#include + +int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file) +{ + struct drm_i915_query *args = data; + struct drm_i915_query_item __user *user_item_ptr
[Intel-gfx] [PATCH v2 3/6] drm/i915/debugfs: add rcs topology entry
While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs (0xff) subslice3: 0 EUs (0x0) slice1: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs (0xff) subslice3: 0 EUs (0x0) slice2: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs (0xff) subslice3: 0 EUs (0x0) v2: Reformat debugfs printing (Tvrtko) Use the new EU mask helper (Tvrtko) Suggested-by: Chris Wilson Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 42 + 1 file changed, 42 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 2d1c9cce5fe4..83af1029b907 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3162,6 +3162,47 @@ static int i915_engine_info(struct seq_file *m, void *unused) return 0; } +static int i915_rcs_topology(struct seq_file *m, void *unused) +{ + struct drm_i915_private *dev_priv = node_to_i915(m->private); + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + int s, ss; + int subslice_stride = + DIV_ROUND_UP(sseu->max_eus_per_subslice, BITS_PER_BYTE); + + if (sseu->max_slices == 0) { + seq_printf(m, "Unavailable\n"); + return 0; + } + + for (s = 0; s < sseu->max_slices; s++) { + seq_printf(m, "slice%i: %u subslice(s) (0x%hhx):\n", + s, hweight8(sseu->subslice_mask[s]), + sseu->subslice_mask[s]); + + for (ss = 0; ss < sseu->max_subslices; ss++) { + int eu_group, n_subslice_eus = 0; + + for (eu_group = 0; eu_group < subslice_stride; eu_group++) { + n_subslice_eus += + hweight8(sseu_eu_mask(sseu, s, ss, eu_group)); + } + + seq_printf(m, "\tsubslice%i: %u EUs (", ss, n_subslice_eus); + for (eu_group = 0; +eu_group < max(0, subslice_stride - 1); +eu_group++) { + u8 val = sseu_eu_mask(sseu, s, ss, eu_group); + seq_printf(m, "0x%hhx, ", val); + } + seq_printf(m, "0x%hhx)\n", + sseu_eu_mask(sseu, s, ss, subslice_stride - 1)); + } + } + + return 0; +} + static int i915_shrinker_info(struct seq_file *m, void *unused) { struct drm_i915_private *i915 = node_to_i915(m->private); @@ -4692,6 +4733,7 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_dmc_info", i915_dmc_info, 0}, {"i915_display_info", i915_display_info, 0}, {"i915_engine_info", i915_engine_info, 0}, + {"i915_rcs_topology", i915_rcs_topology, 0}, {"i915_shrinker_info", i915_shrinker_info, 0}, {"i915_shared_dplls_info", i915_shared_dplls_info, 0}, {"i915_dp_mst_info", i915_dp_mst_info, 0}, -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling
On 10/01/18 02:12, Chris Wilson wrote: Quoting Paulo Zanoni (2018-01-09 23:23:17) From: Tvrtko Ursulin Since it is not possible to mask individual engine instances and they are all permanently unmasked we do not need to do anything for engine interrupt management. This scares me as we will more than double our interrupt generation rate as we have a breadcrumb interrupt after every request, just in case we need to synchronize with the request. We've been relying on the ability to mask those interrupts off, as historically we have been able to saturate cpus with the amount of interrupts we could generate. -Chris We do have masks per instance, but they're in gunit and not in the CS. they're defined in patch 4 of this series: +#define GEN11_RCS0_RSVD_INTR_MASK _MMIO(0x190090) +#define GEN11_BCS_RSVD_INTR_MASK _MMIO(0x1900a0) +#define GEN11_VCS0_VCS1_INTR_MASK _MMIO(0x1900a8) +#define GEN11_VCS2_VCS3_INTR_MASK _MMIO(0x1900ac) +#define GEN11_VECS0_VECS1_INTR_MASK_MMIO(0x1900d0) Each instance gets half of a register for a 16 bits vector. I think there was some gotcha with the masks being in gunit but can't remember exactly what. Tvrtko, do you remember anything on this? Thanks, Daniele ___ 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] ✓ Fi.CI.IGT: success for ICP initial support
== Series Details == Series: ICP initial support URL : https://patchwork.freedesktop.org/series/36350/ State : success == Summary == Test kms_atomic_transition: Subgroup plane-all-modeset-transition-fencing: dmesg-warn -> PASS (shard-hsw) fdo#102614 +1 Test gem_tiled_swapping: Subgroup non-threaded: pass -> INCOMPLETE (shard-snb) fdo#104218 +1 Test kms_flip: Subgroup flip-vs-panning-vs-hang: dmesg-warn -> PASS (shard-snb) fdo#103821 Test gem_eio: Subgroup in-flight: dmesg-warn -> PASS (shard-snb) fdo#104058 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058 shard-hswtotal:2643 pass:1497 dwarn:2 dfail:0 fail:6 skip:1137 time:8871s shard-snbtotal:2643 pass:1273 dwarn:1 dfail:0 fail:8 skip:1360 time:7722s Blacklisted hosts: shard-apltotal:2691 pass:1664 dwarn:1 dfail:0 fail:23 skip:1001 time:13133s shard-kbltotal:2709 pass:1807 dwarn:1 dfail:0 fail:23 skip:877 time:10316s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7652/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs
On Thu, Jan 11, 2018 at 10:31 AM, Rodrigo Vivi wrote: > On Thu, Jan 11, 2018 at 06:20:53PM +, Anuj Phogat wrote: >> Rodrigo, Can you push it upstream for me? > > I just pushed the libdrm. > > Do I also need to push the mesa one? > No, I've pushed the mesa patch. Thanks. > Thanks, > Rodrigo. > >> >> Thanks >> Anuj >> >> On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi wrote: >> > On Wed, Jan 10, 2018 at 11:51:02PM +, Anuj Phogat wrote: >> >> Cc: Rodrigo Vivi >> >> Cc: Anusha Srivatsa >> >> Signed-off-by: Anuj Phogat >> > >> > Reviewed-by: Rodrigo Vivi >> > >> >> --- >> >> intel/intel_chipset.h | 30 +++--- >> >> 1 file changed, 23 insertions(+), 7 deletions(-) >> >> >> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h >> >> index d81b1646..3818e71e 100644 >> >> --- a/intel/intel_chipset.h >> >> +++ b/intel/intel_chipset.h >> >> @@ -223,15 +223,23 @@ >> >> >> >> #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90 >> >> #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93 >> >> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99 >> >> #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91 >> >> #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92 >> >> #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 >> >> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A >> >> #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B >> >> #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 >> >> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7 >> >> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8 >> >> >> >> #define PCI_CHIP_CANNONLAKE_U_GT2_0 0x5A52 >> >> #define PCI_CHIP_CANNONLAKE_U_GT2_1 0x5A5A >> >> @@ -477,17 +485,25 @@ >> >> >> >> #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 >> >> || \ >> >> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3) >> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4) >> >> >> >> #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2) >> >> >> >> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 >> >> || \ >> >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 >> >> || \ >> >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 >> >> || \ >> >> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4) >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 >> >> || \ >> >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5) >> >> >> >> #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \ >> >> IS_CFL_H(devid) || \ >> >> -- >> >> 2.13.6 >> >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: expose rcs topology through query uAPI
On 11/01/18 12:45, Tvrtko Ursulin wrote: On 18/12/2017 15:35, Lionel Landwerlin wrote: With the introduction of asymetric slices in CNL, we cannot rely on asymmetric Check ;) the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts of the GPU with the OA unit, because counters need to be normalized to the number of EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do not gives us sufficient information. As a bonus we can draw representations of the GPU : https://imgur.com/a/vuqpa Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_query.c | 134 drivers/gpu/drm/i915/intel_query_info.c | 88 + include/uapi/drm/i915_drm.h | 45 +++ 3 files changed, 267 insertions(+) create mode 100644 drivers/gpu/drm/i915/intel_query_info.c diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index 227a28978190..7c0eb09d3aac 100644 --- a/drivers/gpu/drm/i915/i915_query.c +++ b/drivers/gpu/drm/i915/i915_query.c @@ -25,24 +25,158 @@ #include "i915_drv.h" #include +static int query_slices_mask(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_slices_mask slices_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; Do you need to handle this explicitly or just return all zeros? I guess I don't know which GPUs have zero slices. Again, this is < gen8. I rather not care about those and return ENODEV. + + memset(&slices_info, 0, sizeof(slices_info)); Is this needed since a) you will write to the only field just below, and b) it won't clear the tail data array anyway? I don't know. It's just being careful, this struct lives on the stack and I don't want to leak any data to userspace. + + slices_info.n_slices = sseu->max_slices; Move to after the query_item->length checks. Done. + + data_length = sizeof(u8); Size is dependant on number of slices? DIV_ROUND_UP(n_slices, BITS_PER_BYTE) ? Done. + length = sizeof(struct drm_i915_query_slices_mask) + data_length; sizeof(slices_info) Done. + + /* + * If we ever change the internal slice mask data type, we'll need to + * update this function. + */ + BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask)); Hm a bit weak since it is not only about size but also data representation. But I don't have any better ideas. + + if (query_item->length == 0) { + query_item->length = length; + return 0; + } + + if (query_item->length != length) + return -EINVAL; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), &slices_info, + sizeof(slices_info))) + return -EFAULT; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + + offsetof(struct drm_i915_query_slices_mask, data)), + &sseu->slice_mask, data_length)) + return -EFAULT; + + return 0; +} Some of the above comments also apply to the other two query functions below. +static int query_subslices_mask(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_subslices_mask subslices_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&subslices_info, 0, sizeof(subslices_info)); + + subslices_info.n_slices = sseu->max_slices; + subslices_info.slice_stride = ALIGN(sseu->max_subslices, 8) / 8; + + data_length = subslices_info.n_slices * subslices_info.slice_stride; + length = sizeof(struct drm_i915_query_subslices_mask) + data_length; + + if (query_item->length == 0) { + query_item->length = length; + return 0; + } + + if (query_item->length != length) + return -EINVAL; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), &subslices_info, + sizeof(subslices_info))) + return -EFAULT; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + + offsetof(struct drm_i915_query_subslices_mask, data)), + sseu->subslices_mask, data_length)) + return -EFAULT; + + return 0; +} + +static int query_eus_mask(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_eus_mask eus_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&eus_info, 0, sizeof(eus
Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs
On Thu, Jan 11, 2018 at 06:20:53PM +, Anuj Phogat wrote: > Rodrigo, Can you push it upstream for me? I just pushed the libdrm. Do I also need to push the mesa one? Thanks, Rodrigo. > > Thanks > Anuj > > On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi wrote: > > On Wed, Jan 10, 2018 at 11:51:02PM +, Anuj Phogat wrote: > >> Cc: Rodrigo Vivi > >> Cc: Anusha Srivatsa > >> Signed-off-by: Anuj Phogat > > > > Reviewed-by: Rodrigo Vivi > > > >> --- > >> intel/intel_chipset.h | 30 +++--- > >> 1 file changed, 23 insertions(+), 7 deletions(-) > >> > >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h > >> index d81b1646..3818e71e 100644 > >> --- a/intel/intel_chipset.h > >> +++ b/intel/intel_chipset.h > >> @@ -223,15 +223,23 @@ > >> > >> #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90 > >> #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93 > >> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99 > >> #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91 > >> #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92 > >> #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 > >> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A > >> #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B > >> #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 > >> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 > >> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 > >> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 > >> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 > >> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1 > >> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4 > >> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0 > >> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3 > >> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9 > >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2 > >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5 > >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6 > >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7 > >> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8 > >> > >> #define PCI_CHIP_CANNONLAKE_U_GT2_0 0x5A52 > >> #define PCI_CHIP_CANNONLAKE_U_GT2_1 0x5A5A > >> @@ -477,17 +485,25 @@ > >> > >> #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 > >> || \ > >> (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 > >> || \ > >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 > >> || \ > >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 > >> || \ > >> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3) > >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4) > >> > >> #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 > >> || \ > >> (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2) > >> > >> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 > >> || \ > >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 > >> || \ > >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 > >> || \ > >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 > >> || \ > >> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4) > >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 > >> || \ > >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5) > >> > >> #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \ > >> IS_CFL_H(devid) || \ > >> -- > >> 2.13.6 > >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/icl: Update subslice define for ICL 11
From: Kelvin Gardiner ICL 11 has a greater number of maximum subslices. This patch reflects this. v2: GEN11 updates to MCR_SELECTOR (Oscar) Bspec: 21139 BSpec: 21108 Reviewed-by: Daniele Ceraolo Spurio (v1) Signed-off-by: Kelvin Gardiner Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 4 drivers/gpu/drm/i915/intel_engine_cs.c | 22 ++ drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 3 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index c9b6250..c79ca5b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2444,6 +2444,10 @@ enum i915_power_well_id { #define GEN8_MCR_SLICE_MASK GEN8_MCR_SLICE(3) #define GEN8_MCR_SUBSLICE(subslice) (((subslice) & 3) << 24) #define GEN8_MCR_SUBSLICE_MASK GEN8_MCR_SUBSLICE(3) +#define GEN11_MCR_SLICE(slice) (((slice) & 0xf) << 27) +#define GEN11_MCR_SLICE_MASK GEN8_MCR_SLICE(0xf) +#define GEN11_MCR_SUBSLICE(subslice) (((subslice) & 0x7) << 24) +#define GEN11_MCR_SUBSLICE_MASK GEN8_MCR_SUBSLICE(0x7) #define RING_IPEIR(base) _MMIO((base)+0x64) #define RING_IPEHR(base) _MMIO((base)+0x68) /* diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index a373bcb..8c0da94 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -775,10 +775,24 @@ const char *i915_cache_level_str(struct drm_i915_private *i915, int type) read_subslice_reg(struct drm_i915_private *dev_priv, int slice, int subslice, i915_reg_t reg) { + uint32_t mcr_slice_subslice_mask; + uint32_t mcr_slice_subslice_select; uint32_t mcr; uint32_t ret; enum forcewake_domains fw_domains; + if (INTEL_GEN(dev_priv) >= 11) { + mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | + GEN11_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) | + GEN11_MCR_SUBSLICE(subslice); + } else { + mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK | + GEN8_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) | + GEN8_MCR_SUBSLICE(subslice); + } + fw_domains = intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ); fw_domains |= intel_uncore_forcewake_for_reg(dev_priv, @@ -793,14 +807,14 @@ const char *i915_cache_level_str(struct drm_i915_private *i915, int type) * The HW expects the slice and sublice selectors to be reset to 0 * after reading out the registers. */ - WARN_ON_ONCE(mcr & (GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK)); - mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK); - mcr |= GEN8_MCR_SLICE(slice) | GEN8_MCR_SUBSLICE(subslice); + WARN_ON_ONCE(mcr & mcr_slice_subslice_mask); + mcr &= ~mcr_slice_subslice_mask; + mcr |= mcr_slice_subslice_select; I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr); ret = I915_READ_FW(reg); - mcr &= ~(GEN8_MCR_SLICE_MASK | GEN8_MCR_SUBSLICE_MASK); + mcr &= ~mcr_slice_subslice_mask; I915_WRITE_FW(GEN8_MCR_SELECTOR, mcr); intel_uncore_forcewake_put__locked(dev_priv, fw_domains); diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index 2a88231..029093a 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -82,7 +82,7 @@ enum intel_engine_hangcheck_action { } #define I915_MAX_SLICES3 -#define I915_MAX_SUBSLICES 3 +#define I915_MAX_SUBSLICES 8 #define instdone_slice_mask(dev_priv__) \ (INTEL_GEN(dev_priv__) == 7 ? \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for ICP initial support
== Series Details == Series: ICP initial support URL : https://patchwork.freedesktop.org/series/36350/ State : success == Summary == Series 36350v1 ICP initial support https://patchwork.freedesktop.org/api/1.0/series/36350/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: fail -> PASS (fi-elk-e7500) fdo#103989 incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:419s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:373s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:491s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:481s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:466s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:452s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:271s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:513s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:390s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:401s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:460s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:467s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:499s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:503s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:581s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:429s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:510s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:532s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:480s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:432s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:530s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-glk-dsi total:288 pass:257 dwarn:0 dfail:0 fail:1 skip:30 time:487s fi-cnl-y2 failed to collect. IGT log at Patchwork_7652/fi-cnl-y2/igt.log dbc7615897f6cbe121a316b4209b278407cb2eb4 drm-tip: 2018y-01m-11d-16h-49m-38s UTC integration manifest 2fe9e815bb0b drm/i915/icp: Add the ID for ICL PCH - ICP a44a57cf52df drm/i915/icp: add ICP gmbus and gpio support 5c79b9a3856e drm/i915/icp: Add backlight Support for ICP 8dd9bdee33e6 drm/i915/icp: Add Panel Power Sequencing Support 4b221f1e5a65 drm/i915/icp: Get/set proper Raw clock frequency on ICP 05c7311d391a drm/i915/icp: Introduce Ice Lake PCH 09ae110fc4bb drm/i915/icl: Add initial Icelake definitions. 71e6a3f6aa93 drm/i915/cnl: Add Port F definition. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7652/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/icl: Gen11 render context size
From: Tvrtko Ursulin Gen11 removes the Resource Streamer, which frees up a big chunk of the context image. BSpec indicates 12538 DWORDs (13 pages), plus one page for PPHWSP. Please notice that, when looking at the BSpec context image table, the right filter has to be applied (e.g. "IcelakeLP") as some rows are excluded for specific GENs. Also, some rows apply per-subslice (for the calculation above, we have supposed 8 subslices which is the maximum SKU we expect). v2: Rebase. v3: Use the right size as per the BSpec. BSpec: 18907 Acked-by: Ben Widawsky Signed-off-by: Tvrtko Ursulin Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index e88b2fd..79b7d36 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -41,6 +41,7 @@ #define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE) #define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE) #define GEN10_LR_CONTEXT_RENDER_SIZE (18 * PAGE_SIZE) +#define GEN11_LR_CONTEXT_RENDER_SIZE (14 * PAGE_SIZE) #define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE) @@ -181,6 +182,8 @@ struct engine_info { switch (INTEL_GEN(dev_priv)) { default: MISSING_CASE(INTEL_GEN(dev_priv)); + case 11: + return GEN11_LR_CONTEXT_RENDER_SIZE; case 10: return GEN10_LR_CONTEXT_RENDER_SIZE; case 9: -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm] intel: Add more Coffeelake PCI IDs
Rodrigo, Can you push it upstream for me? Thanks Anuj On Wed, Jan 10, 2018 at 4:50 PM, Rodrigo Vivi wrote: > On Wed, Jan 10, 2018 at 11:51:02PM +, Anuj Phogat wrote: >> Cc: Rodrigo Vivi >> Cc: Anusha Srivatsa >> Signed-off-by: Anuj Phogat > > Reviewed-by: Rodrigo Vivi > >> --- >> intel/intel_chipset.h | 30 +++--- >> 1 file changed, 23 insertions(+), 7 deletions(-) >> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h >> index d81b1646..3818e71e 100644 >> --- a/intel/intel_chipset.h >> +++ b/intel/intel_chipset.h >> @@ -223,15 +223,23 @@ >> >> #define PCI_CHIP_COFFEELAKE_S_GT1_1 0x3E90 >> #define PCI_CHIP_COFFEELAKE_S_GT1_2 0x3E93 >> +#define PCI_CHIP_COFFEELAKE_S_GT1_3 0x3E99 >> #define PCI_CHIP_COFFEELAKE_S_GT2_1 0x3E91 >> #define PCI_CHIP_COFFEELAKE_S_GT2_2 0x3E92 >> #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 >> +#define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A >> #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B >> #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 >> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 >> +#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1 >> +#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4 >> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0 >> +#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3 >> +#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8 >> >> #define PCI_CHIP_CANNONLAKE_U_GT2_0 0x5A52 >> #define PCI_CHIP_CANNONLAKE_U_GT2_1 0x5A5A >> @@ -477,17 +485,25 @@ >> >> #define IS_CFL_S(devid) ((devid) == PCI_CHIP_COFFEELAKE_S_GT1_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_S_GT1_2 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT1_3 || \ >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_S_GT2_2 || \ >> - (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3) >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_3 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_S_GT2_4) >> >> #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2) >> >> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \ >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \ >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 || \ >> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 || \ >> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4) >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5) >> >> #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \ >> IS_CFL_H(devid) || \ >> -- >> 2.13.6 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/27] drm/i915/icl: Gen11 render context size
On 01/10/2018 05:21 PM, Rodrigo Vivi wrote: On Tue, Jan 09, 2018 at 11:28:19PM +, Paulo Zanoni wrote: From: Tvrtko Ursulin The current size may be bigger than the correct one, this needs to be revisited later. I don't believe this is true anymore. When this was written initially CNL had a higher value. Higher values are ok, but smaller can be problematic if I understood correctly. So we might need to check the accurate number. Oscar has a good method for that if iirc ;) My method says 14 pages. Seems a bit low, so I went ahead and tested it. Everything seems to work fine, so I'll send a new patch. v2: Rebase. Acked-by: Ben Widawsky Signed-off-by: Tvrtko Ursulin Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index e88b2fd44724..a373bcbd85d8 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -181,6 +181,8 @@ __intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class) switch (INTEL_GEN(dev_priv)) { default: MISSING_CASE(INTEL_GEN(dev_priv)); + case 11: + /* TODO: Make sure this is correct. */ case 10: return GEN10_LR_CONTEXT_RENDER_SIZE; case 9: -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915/icp: Get/set proper Raw clock frequency on ICP
From: Anusha Srivatsa Add register definitions for setting the rawclock. Set the numerator,denominator and divider values. v2: Simplify the commit message. Simplify the math. Add register bits for numerator. (Paulo) v3 (from Paulo): coding style bikesheds. Reviewed-by: Paulo Zanoni Signed-off-by: Anusha Srivatsa Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h| 2 ++ drivers/gpu/drm/i915/intel_cdclk.c | 29 +++-- 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index c0a4fc356145..f756512041c6 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -7352,6 +7352,8 @@ enum { #define CNP_RAWCLK_DIV(div) ((div) << 16) #define CNP_RAWCLK_FRAC_MASK (0xf << 26) #define CNP_RAWCLK_FRAC(frac) ((frac) << 26) +#define ICP_RAWCLK_DEN(den) ((den) << 26) +#define ICP_RAWCLK_NUM(num) ((num) << 11) #define PCH_DPLL_TMR_CFG_MMIO(0xc6208) diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index ca36321eafac..4f921fd331fd 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -2342,6 +2342,30 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv) return divider + fraction; } +static int icp_rawclk(struct drm_i915_private *dev_priv) +{ + u32 rawclk; + int divider, numerator, denominator, frequency; + + if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) { + frequency = 24000; + divider = 23; + numerator = 0; + denominator = 0; + } else { + frequency = 19200; + divider = 18; + numerator = 1; + denominator = 4; + } + + rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) | +ICP_RAWCLK_DEN(denominator); + + I915_WRITE(PCH_RAWCLK_FREQ, rawclk); + return frequency; +} + static int pch_rawclk(struct drm_i915_private *dev_priv) { return (I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK) * 1000; @@ -2389,8 +2413,9 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv) */ void intel_update_rawclk(struct drm_i915_private *dev_priv) { - - if (HAS_PCH_CNP(dev_priv)) + if (HAS_PCH_ICP(dev_priv)) + dev_priv->rawclk_freq = icp_rawclk(dev_priv); + else if (HAS_PCH_CNP(dev_priv)) dev_priv->rawclk_freq = cnp_rawclk(dev_priv); else if (HAS_PCH_SPLIT(dev_priv)) dev_priv->rawclk_freq = pch_rawclk(dev_priv); -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/icp: Add Panel Power Sequencing Support
From: Anusha Srivatsa ICP, like BXT, has has two panel power sequencers. v2: Simplify the code. Remove unwanted register definitions. Make code as close to BXT style as possible. (Ville) Also, remove the use of ICP_SECOND_PPS_BACKLIGHT for now. Moving forward, if we are sure we need to set this register, we can access it. v3: Use INTEL_GEN(dev_priv), make code more readeable. (Ville) v4 (from Paulo): - Coding style fixes. - Add a missing HAS_PCH_CNP -> gen10+ check. - Rebase. v5: Use per platform checks rather than INTEL_GEN(). v4 of this patch breaks on CoffeeLake, since CFL uses CNP and per platform check makes sense in that case. v6 (from Paulo): - v5 was a patch on top of v4, not a new version. Now v6 is correctly a new version of the original patch. Cc: Ville Syrjala Reviewed-by: Paulo Zanoni Signed-off-by: Anusha Srivatsa Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_dp.c | 18 -- 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 46937a8c48cc..cdfdacf27939 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -796,7 +796,8 @@ static void intel_pps_get_registers(struct intel_dp *intel_dp, regs->pp_stat = PP_STATUS(pps_idx); regs->pp_on = PP_ON_DELAYS(pps_idx); regs->pp_off = PP_OFF_DELAYS(pps_idx); - if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv) && + !HAS_PCH_ICP(dev_priv)) regs->pp_div = PP_DIVISOR(pps_idx); } @@ -5453,7 +5454,8 @@ intel_pps_readout_hw_state(struct intel_dp *intel_dp, struct edp_power_seq *seq) pp_on = I915_READ(regs.pp_on); pp_off = I915_READ(regs.pp_off); - if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) { + if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv) && + !HAS_PCH_ICP(dev_priv)) { I915_WRITE(regs.pp_ctrl, pp_ctl); pp_div = I915_READ(regs.pp_div); } @@ -5471,7 +5473,8 @@ intel_pps_readout_hw_state(struct intel_dp *intel_dp, struct edp_power_seq *seq) seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >> PANEL_POWER_DOWN_DELAY_SHIFT; - if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) { + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv) || + HAS_PCH_ICP(dev_priv)) { seq->t11_t12 = ((pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >> BXT_POWER_CYCLE_DELAY_SHIFT) * 1000; } else { @@ -5642,7 +5645,8 @@ intel_dp_init_panel_power_sequencer_registers(struct intel_dp *intel_dp, (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT); /* Compute the divisor for the pp clock, simply match the Bspec * formula. */ - if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) { + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv) || + HAS_PCH_ICP(dev_priv)) { pp_div = I915_READ(regs.pp_ctrl); pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK; pp_div |= (DIV_ROUND_UP(seq->t11_t12, 1000) @@ -5668,7 +5672,8 @@ intel_dp_init_panel_power_sequencer_registers(struct intel_dp *intel_dp, I915_WRITE(regs.pp_on, pp_on); I915_WRITE(regs.pp_off, pp_off); - if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) + if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv) || + HAS_PCH_ICP(dev_priv)) I915_WRITE(regs.pp_ctrl, pp_div); else I915_WRITE(regs.pp_div, pp_div); @@ -5676,7 +5681,8 @@ intel_dp_init_panel_power_sequencer_registers(struct intel_dp *intel_dp, DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, PP_OFF %#x, PP_DIV %#x\n", I915_READ(regs.pp_on), I915_READ(regs.pp_off), - (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ? + (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv) || + HAS_PCH_ICP(dev_priv)) ? (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) : I915_READ(regs.pp_div)); } -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/icp: add ICP gmbus and gpio support
From: Anusha Srivatsa In ICP, there are three TC ports and 3 DDI ports. v2: - Correct Pin mapping. v3: - Update pin mapping into per platform implementation rather than previous approach of port wise mapping. v4: - Update GMBUS_NUM_PINS (Paulo) v5: - rebase. v6: - Update function name, GMBUS_PIN_NUM (Paulo) v7 (from Paulo): - Make it apply. v8 (from Paulo): - Maintain consistent if ladder ordering. Suggested by: Ville Syrjala Cc: Jani Nikula Reviewed-by: Paulo Zanoni Signed-off-by: Anusha Srivatsa Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 7 ++- drivers/gpu/drm/i915/intel_hdmi.c | 33 + drivers/gpu/drm/i915/intel_i2c.c | 17 +++-- 3 files changed, 54 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index f756512041c6..698e1649f287 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3064,7 +3064,12 @@ enum i915_power_well_id { #define GMBUS_PIN_2_BXT 2 #define GMBUS_PIN_3_BXT 3 #define GMBUS_PIN_4_CNP 4 -#define GMBUS_NUM_PINS 7 /* including 0 */ +#define GMBUS_PIN_9_TC1_ICP 9 +#define GMBUS_PIN_10_TC2_ICP 10 +#define GMBUS_PIN_11_TC3_ICP 11 +#define GMBUS_PIN_12_TC4_ICP 12 + +#define GMBUS_NUM_PINS 13 /* including 0 */ #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* command/status */ #define GMBUS_SW_CLR_INT (1<<31) #define GMBUS_SW_RDY (1<<30) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 691f15b59124..d3212afe1eba 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2183,6 +2183,37 @@ static u8 cnp_port_to_ddc_pin(struct drm_i915_private *dev_priv, return ddc_pin; } +static u8 icl_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port port) +{ + u8 ddc_pin; + + switch (port) { + case PORT_A: + ddc_pin = GMBUS_PIN_1_BXT; + break; + case PORT_B: + ddc_pin = GMBUS_PIN_2_BXT; + break; + case PORT_C: + ddc_pin = GMBUS_PIN_9_TC1_ICP; + break; + case PORT_D: + ddc_pin = GMBUS_PIN_10_TC2_ICP; + break; + case PORT_E: + ddc_pin = GMBUS_PIN_11_TC3_ICP; + break; + case PORT_F: + ddc_pin = GMBUS_PIN_12_TC4_ICP; + break; + default: + MISSING_CASE(port); + ddc_pin = GMBUS_PIN_2_BXT; + break; + } + return ddc_pin; +} + static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port port) { @@ -2225,6 +2256,8 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv, ddc_pin = bxt_port_to_ddc_pin(dev_priv, port); else if (HAS_PCH_CNP(dev_priv)) ddc_pin = cnp_port_to_ddc_pin(dev_priv, port); + else if (IS_ICELAKE(dev_priv)) + ddc_pin = icl_port_to_ddc_pin(dev_priv, port); else ddc_pin = g4x_port_to_ddc_pin(dev_priv, port); diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 6f7ef4e225ee..e6875509bcd9 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -76,11 +76,22 @@ static const struct gmbus_pin gmbus_pins_cnp[] = { [GMBUS_PIN_4_CNP] = { "dpd", GPIOE }, }; +static const struct gmbus_pin gmbus_pins_icp[] = { + [GMBUS_PIN_1_BXT] = { "dpa", GPIOA }, + [GMBUS_PIN_2_BXT] = { "dpb", GPIOB }, + [GMBUS_PIN_9_TC1_ICP] = { "tc1", GPIOC }, + [GMBUS_PIN_10_TC2_ICP] = { "tc2", GPIOD }, + [GMBUS_PIN_11_TC3_ICP] = { "tc3", GPIOE }, + [GMBUS_PIN_12_TC4_ICP] = { "tc4", GPIOF }, +}; + /* pin is expected to be valid */ static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv, unsigned int pin) { - if (HAS_PCH_CNP(dev_priv)) + if (HAS_PCH_ICP(dev_priv)) + return &gmbus_pins_icp[pin]; + else if (HAS_PCH_CNP(dev_priv)) return &gmbus_pins_cnp[pin]; else if (IS_GEN9_LP(dev_priv)) return &gmbus_pins_bxt[pin]; @@ -97,7 +108,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv, { unsigned int size; - if (HAS_PCH_CNP(dev_priv)) + if (HAS_PCH_ICP(dev_priv)) + size = ARRAY_SIZE(gmbus_pins_icp); + else if (HAS_PCH_CNP(dev_priv)) size = ARRAY_SIZE(gmbus_pins_cnp); else if (IS_GEN9_LP(dev_priv)) size = ARRAY_SIZE(gmbus_pins_bxt); -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP
From: Anusha Srivatsa ICP has two backlight controllers - similar to previous platforms like BXT. v2: Remove the usage of ICP_SECOND_PPS_BACKLIGHT register.(Jani) Reuse BXT code since it is very similar.(Ville) v3 (from Paulo): Rebase. Cc: Jani Nikula Cc: Ville Syrjala Reviewed-by: Paulo Zanoni Signed-off-by: Anusha Srivatsa Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index fa6831f8c004..ad80cca8c110 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1865,7 +1865,7 @@ intel_panel_init_backlight_funcs(struct intel_panel *panel) panel->backlight.set = bxt_set_backlight; panel->backlight.get = bxt_get_backlight; panel->backlight.hz_to_pwm = bxt_hz_to_pwm; - } else if (HAS_PCH_CNP(dev_priv)) { + } else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv)) { panel->backlight.setup = cnp_setup_backlight; panel->backlight.enable = cnp_enable_backlight; panel->backlight.disable = cnp_disable_backlight; -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915/icp: Add the ID for ICL PCH - ICP
From: Anusha Srivatsa Add the PCI ID for the ICL PCH - ICP. v2: rebased. v3: rebased. v4: fix ICP name. v5: fix the ID mask (Fei Li). v6 (from Paulo): bikesheds. Cc: Li, Fei Reviewed-by: Paulo Zanoni Signed-off-by: Anusha Srivatsa Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.c | 4 drivers/gpu/drm/i915/i915_drv.h | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 6c8da9d20c33..95071a1e875b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -252,6 +252,10 @@ static void intel_detect_pch(struct drm_i915_private *dev_priv) DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n"); WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv)); + } else if (id == INTEL_PCH_ICP_DEVICE_ID_TYPE) { + dev_priv->pch_type = PCH_ICP; + DRM_DEBUG_KMS("Found Ice Lake PCH\n"); + WARN_ON(!IS_ICELAKE(dev_priv)); } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE || id == INTEL_PCH_P3X_DEVICE_ID_TYPE || (id == INTEL_PCH_QEMU_DEVICE_ID_TYPE && diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 482517af58f6..e0c6f1f4bafd 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2846,6 +2846,7 @@ intel_info(const struct drm_i915_private *dev_priv) #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_ICP_DEVICE_ID_TYPE 0x3480 #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100 #define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE 0x2900 /* qemu q35 has 2918 */ -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915/cnl: Add Port F definition.
From: Rodrigo Vivi Some Cannonlake SKUs will come with a full split between port A and port E. This will be called port F although it is not a 6th port, but only a split. Note this patch alone is not sufficient for port F enabling, it's just the first step. v2: Fix size of dvo_ports found by Ander. v3: Adding missing cases from intel_bios.c for Port_F v4: Adding other missing cases and fix the commit message. v5: Rebase on top of display headers rework. v6 (from Paulo): improve commit message, bikeshed bit definitions. Cc: Lucas De Marchi Cc: Manasi Navare Reviewed-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_bios.c | 9 + drivers/gpu/drm/i915/intel_display.h | 1 + drivers/gpu/drm/i915/intel_dp.c | 2 ++ drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ include/drm/i915_component.h | 3 +-- 5 files changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 51108ffc28d1..59a150e2adce 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1140,6 +1140,7 @@ static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port, {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}, }; /* @@ -1688,6 +1689,7 @@ bool intel_bios_is_port_present(struct drm_i915_private *dev_priv, enum port por [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, }, [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, }, [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, }, + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, }, }; int i; @@ -1726,6 +1728,7 @@ bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port) [PORT_C] = DVO_PORT_DPC, [PORT_D] = DVO_PORT_DPD, [PORT_E] = DVO_PORT_DPE, + [PORT_F] = DVO_PORT_DPF, }; int i; @@ -1761,6 +1764,7 @@ static bool child_dev_is_dp_dual_mode(const struct child_device_config *child, [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, }, [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, }, [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, }, + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, }, }; if (port == PORT_A || port >= ARRAY_SIZE(port_mapping)) @@ -1927,6 +1931,11 @@ intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv, if (port == PORT_D) return true; break; + case DVO_PORT_DPF: + case DVO_PORT_HDMIF: + if (port == PORT_F) + return true; + break; default: break; } diff --git a/drivers/gpu/drm/i915/intel_display.h b/drivers/gpu/drm/i915/intel_display.h index a0d2b6169361..e47638931b51 100644 --- a/drivers/gpu/drm/i915/intel_display.h +++ b/drivers/gpu/drm/i915/intel_display.h @@ -119,6 +119,7 @@ enum port { PORT_C, PORT_D, PORT_E, + PORT_F, I915_MAX_PORTS }; diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 68229f53d5b8..46937a8c48cc 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1402,6 +1402,7 @@ static i915_reg_t skl_aux_ctl_reg(struct drm_i915_private *dev_priv, case PORT_B: case PORT_C: case PORT_D: + case PORT_F: return DP_AUX_CH_CTL(port); default: MISSING_CASE(port); @@ -1417,6 +1418,7 @@ static i915_reg_t skl_aux_data_reg(struct drm_i915_private *dev_priv, case PORT_B: case PORT_C: case PORT_D: + case PORT_F: return DP_AUX_CH_DATA(port, index); default: MISSING_CASE(port); diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h b/drivers/gpu/drm/i915/intel_vbt_defs.h index e3d7745a9151..b5d2341f932c 100644 --- a/drivers/gpu/drm/i915/intel_vbt_defs.h +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h @@ -299,6 +299,8 @@ struct bdb_general_features { #define DVO_PORT_DPA 10 #define DVO_PORT_DPE 11 /* 193 */ #define DVO_PORT_HDMIE 12 /* 193 */ +#define DVO_PORT_DPF 13 /* N/A */ +#define DVO_PORT_HDMIF 14 /* N/A */ #define DVO_PORT_MIPIA 21 /* 171 */ #define DVO_PORT_MIPIB 22 /* 171 */ #define DVO_PORT_MIPIC 23 /* 171 */ diff --git a/in
[Intel-gfx] [PATCH 3/8] drm/i915/icp: Introduce Ice Lake PCH
From: Anusha Srivatsa Add the enum additions to ICP PCH. v2 (from Paulo): don't set any platforms to it yet since ICP support is incomplete. v3 (from Rodrigo): Fix ICP name. Reviewed-by: Paulo Zanoni Signed-off-by: Anusha Srivatsa Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 016920f58ae6..482517af58f6 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -783,6 +783,7 @@ enum intel_pch { PCH_SPT,/* Sunrisepoint PCH */ PCH_KBP,/* Kaby Lake PCH */ PCH_CNP,/* Cannon Lake PCH */ + PCH_ICP,/* Ice Lake PCH */ PCH_NOP, }; @@ -2850,6 +2851,7 @@ intel_info(const struct drm_i915_private *dev_priv) #define INTEL_PCH_QEMU_DEVICE_ID_TYPE 0x2900 /* qemu q35 has 2918 */ #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type) +#define HAS_PCH_ICP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_ICP) #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP) #define HAS_PCH_CNP_LP(dev_priv) \ ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE) -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915/icl: Add initial Icelake definitions.
From: Rodrigo Vivi Icelake is an Intel® Processor containing an Intel® Graphics Controller. This is just an initial Icelake definition. PCI IDs, Icelake support and new features coming in following patches. v2: Add .ddb_size and .has_guc (Michal Wajdeczko). v3: Add the ICL_FEATURES macro (Kelvin Gardiner). v4 (from Paulo): Add missing __initconst (Paulo) and say "graphics controller" instead of something that looks like an official marketing name but isn't (Chris). Reviewed-by: Rodrigo Vivi Reviewed-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_pci.c | 13 + drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 2 ++ 4 files changed, 18 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a689396d0ff6..016920f58ae6 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2595,6 +2595,7 @@ intel_info(const struct drm_i915_private *dev_priv) #define IS_GEMINILAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_GEMINILAKE) #define IS_COFFEELAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_COFFEELAKE) #define IS_CANNONLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_CANNONLAKE) +#define IS_ICELAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ICELAKE) #define IS_MOBILE(dev_priv)((dev_priv)->info.is_mobile) #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \ (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00) @@ -2706,6 +2707,7 @@ intel_info(const struct drm_i915_private *dev_priv) #define IS_GEN8(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(7))) #define IS_GEN9(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(8))) #define IS_GEN10(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(9))) +#define IS_GEN11(dev_priv) (!!((dev_priv)->info.gen_mask & BIT(10))) #define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) #define IS_GEN9_LP(dev_priv) (IS_GEN9(dev_priv) && IS_LP(dev_priv)) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 36d48422b475..f28c165fc49d 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -579,6 +579,19 @@ static const struct intel_device_info intel_cannonlake_gt2_info __initconst = { .gt = 2, }; +#define GEN11_FEATURES \ + GEN10_FEATURES, \ + .gen = 11, \ + .ddb_size = 2048, \ + .has_csr = 0 + +static const struct intel_device_info intel_icelake_11_info __initconst = { + GEN11_FEATURES, + .platform = INTEL_ICELAKE, + .is_alpha_support = 1, + .has_resource_streamer = 0, +}; + /* * Make sure any device matches here are from most specific to most * general. For example, since the Quanta match is based on the subsystem diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index d28592e43512..a2c16140169f 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -56,6 +56,7 @@ static const char * const platform_names[] = { PLATFORM_NAME(GEMINILAKE), PLATFORM_NAME(COFFEELAKE), PLATFORM_NAME(CANNONLAKE), + PLATFORM_NAME(ICELAKE), }; #undef PLATFORM_NAME diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 49cb27bd04c1..9542018d11d0 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -69,6 +69,8 @@ enum intel_platform { INTEL_COFFEELAKE, /* gen10 */ INTEL_CANNONLAKE, + /* gen11 */ + INTEL_ICELAKE, INTEL_MAX_PLATFORMS }; -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] ICP initial support
Hi This series adds the initial support for ICP. No conflicts with the other series. Patches 1 and 2 are parts of other series that we've already been discussing on this mailing list, but I put them here so CI can do the right thing. I have just re-reviewed all of Anusha's patches and my reviewed-by tags still stand, which means every patch on this series has a r-b tag. I'll let the series sit on the mailing list for a while before merging, just in case someone else has something to say. The one thing missing for complete ICP support is the patch that adds the interrupts, but that requires code from other series (including the GEM one currently under review), so it will be sent later. Thanks, Paulo Anusha Srivatsa (6): drm/i915/icp: Introduce Ice Lake PCH drm/i915/icp: Get/set proper Raw clock frequency on ICP drm/i915/icp: Add Panel Power Sequencing Support drm/i915/icp: Add backlight Support for ICP drm/i915/icp: add ICP gmbus and gpio support drm/i915/icp: Add the ID for ICL PCH - ICP Rodrigo Vivi (2): drm/i915/cnl: Add Port F definition. drm/i915/icl: Add initial Icelake definitions. drivers/gpu/drm/i915/i915_drv.c | 4 drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_pci.c | 13 + drivers/gpu/drm/i915/i915_reg.h | 9 - drivers/gpu/drm/i915/intel_bios.c| 9 + drivers/gpu/drm/i915/intel_cdclk.c | 29 ++-- drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 2 ++ drivers/gpu/drm/i915/intel_display.h | 1 + drivers/gpu/drm/i915/intel_dp.c | 20 +-- drivers/gpu/drm/i915/intel_hdmi.c| 33 drivers/gpu/drm/i915/intel_i2c.c | 17 ++-- drivers/gpu/drm/i915/intel_panel.c | 2 +- drivers/gpu/drm/i915/intel_vbt_defs.h| 2 ++ include/drm/i915_component.h | 3 +-- 15 files changed, 136 insertions(+), 14 deletions(-) -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: add query uAPI
Applied all of your comments here. On 11/01/18 12:19, Tvrtko Ursulin wrote: On 18/12/2017 15:35, Lionel Landwerlin wrote: There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die recovery). At the moment the GET_PARAM ioctl covers some basic needs, but generally is only able to return a single value for each defined parameter. This is a bit problematic with topology descriptions which are array/maps of available units. This change introduces a new ioctl that can deal with requests to fill structures of potentially variable lengths. The user is expected fill a query with length fields set at 0 on the first call, the kernel then sets the length fields to the their expected values. A second call to the kernel with length fields at their expected values will trigger a copy of the data to the pointed memory locations. The scope of this uAPI is only to provide information to userspace, not to allow configuration of the device. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/i915_query.c | 52 +++ include/uapi/drm/i915_drm.h | 31 +++ 5 files changed, 88 insertions(+) create mode 100644 drivers/gpu/drm/i915/i915_query.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 091aef281963..9627e7e309dc 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \ i915_gem_timeline.o \ i915_gem_userptr.o \ i915_gemfs.o \ + i915_query.o \ i915_trace_points.o \ i915_vma.o \ intel_breadcrumbs.o \ diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 8b99e415c345..a90ed9f2b759 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -2814,6 +2814,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), }; static struct drm_driver driver = { diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 82fc59078c6a..3415a3d2399c 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -4084,6 +4084,9 @@ extern void i915_perf_fini(struct drm_i915_private *dev_priv); extern void i915_perf_register(struct drm_i915_private *dev_priv); extern void i915_perf_unregister(struct drm_i915_private *dev_priv); +/* i915_query.c */ +int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file); + /* i915_suspend.c */ extern int i915_save_state(struct drm_i915_private *dev_priv); extern int i915_restore_state(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c new file mode 100644 index ..227a28978190 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_query.c @@ -0,0 +1,52 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ + +#include "i915_drv.h" +#include + +int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file) +{ + struct drm_i915_query *args = data; An alternativ
Re: [Intel-gfx] [PATCH 3/6] drm/i915/debugfs: add rcs topology entry
On 11/01/18 11:31, Tvrtko Ursulin wrote: On 18/12/2017 15:35, Lionel Landwerlin wrote: While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0 (subslice_mask=0x7): I'd add a subslice count while at it, since the eu lines have counts. Bike-shedding on whether counts or masks are typically more important? Slice0: 3 slices (0x7): Subslice 0: 8 EUs (0xff) Subslice 1: 8 EUs (0xff) ... ? Yeah, sure. subslice0: eu_mask: 0xff (8) subslice1: eu_mask: 0xff (8) subslice2: eu_mask: 0xff (8) subslice3: eu_mask: 0x0 (0) slice1 (subslice_mask=0x7): subslice0: eu_mask: 0xff (8) subslice1: eu_mask: 0xff (8) subslice2: eu_mask: 0xff (8) subslice3: eu_mask: 0x0 (0) slice2 (subslice_mask=0x7): subslice0: eu_mask: 0xff (8) subslice1: eu_mask: 0xff (8) subslice2: eu_mask: 0xff (8) subslice3: eu_mask: 0x0 (0) Suggested-by: Chris Wilson Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 37 + 1 file changed, 37 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 6ec7543e698f..79ca6e9f9ec9 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3173,6 +3173,42 @@ static int i915_engine_info(struct seq_file *m, void *unused) return 0; } +static int i915_rcs_topology(struct seq_file *m, void *unused) +{ + struct drm_i915_private *dev_priv = node_to_i915(m->private); + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + int s, ss; + int subslice_stride = ALIGN(sseu->max_eus_per_subslice, 8) / 8; + int slice_stride = sseu->max_subslices * subslice_stride; Another case for the before mentioned helper for indexing into eu_mask array? Done. + + if (sseu->max_slices == 0) { + seq_printf(m, "Unavailable\n"); + return 0; + } Is this possible? Yeah, there are no registers to read on anything < gen8. I've decided not to generate data there. Most userspaces already has the numbers from a table by pci-id. + + for (s = 0; s < sseu->max_slices; s++) { + seq_printf(m, "slice%i (subslice_mask=0x%x):\n", %i always confuses me. Googling shows it is equivalent to %d for printing? Or is it something different in kernel space? If it is equivalent I would go with a more standard one. And I would even change to unsigned variables for iterators but I realize some people have a different opinion so up to you. Yeah, I'm always using %i, but I must be the only one. It's been easier to remember int -> %i. + s, sseu->subslices_mask[s]); + + for (ss = 0; ss < slice_stride / subslice_stride; ss++) { With the indexing helpers hopefully it would be possible to simply iterate to hweight8(sseu->sublice_mask[s]) ? Actually I should use sseu->max_subslices. + int eu, n_subslice_eus = 0; + + seq_printf(m, "\tsubslice%i:\n", ss); + + seq_printf(m, "\t\teu_mask:"); + for (eu = 0; eu < subslice_stride; eu++) { + u8 val = sseu->eu_mask[s * slice_stride + + ss * subslice_stride + eu]; + seq_printf(m, " 0x%x", val); + n_subslice_eus += hweight8(val); + } + seq_printf(m, " (%i)\n", n_subslice_eus); + } + } + + return 0; +} + static int i915_shrinker_info(struct seq_file *m, void *unused) { struct drm_i915_private *i915 = node_to_i915(m->private); @@ -4658,6 +4694,7 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_dmc_info", i915_dmc_info, 0}, {"i915_display_info", i915_display_info, 0}, {"i915_engine_info", i915_engine_info, 0}, + {"i915_rcs_topology", i915_rcs_topology, 0}, {"i915_shrinker_info", i915_shrinker_info, 0}, {"i915_shared_dplls_info", i915_shared_dplls_info, 0}, {"i915_dp_mst_info", i915_dp_mst_info, 0}, Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active
== Series Details == Series: series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active URL : https://patchwork.freedesktop.org/series/36343/ State : failure == Summary == Series 36343v1 series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active https://patchwork.freedesktop.org/api/1.0/series/36343/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: pass -> SKIP (fi-skl-gvtdvm) Test core_prop_blob: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 pass -> SKIP (fi-skl-gvtdvm) Test drv_getparams_basic: Subgroup basic-eu-total: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-subslice-total: pass -> SKIP (fi-skl-gvtdvm) Test drv_hangman: Subgroup error-state-basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_basic: Subgroup bad-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-fd-close: pass -> SKIP (fi-skl-gvtdvm) Test gem_busy: Subgroup basic-busy-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-hang-default: pass -> SKIP (fi-skl-gvtdvm) fdo#104108 +2 Test gem_close_race: Subgroup basic-process: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-threads: pass -> SKIP (fi-skl-gvtdvm) Test gem_cpu_reloc: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_cs_tlb: Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_create: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-files: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_exec: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_param: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_switch: Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default-heavy: pass -> SKIP (fi-skl-gvtdvm) Test gem_exec_basic: Subgroup basic-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-render: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-vebox: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-render: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-vebox: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-default: WARNING: Long output truncated da4321c7c088d01ad62b18d37dcfe5ef8d0b855d drm-tip: 2018y-01m-11d-14h-59m-37s UTC integration manifest a0e8e84432b0 HAX: drm/i915/uc: Enable GuC/HuC for CI 973357da236a drm/i915/guc: Don't enable GuC when vGPU is active == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7651/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] HAX: drm/i915/uc: Enable GuC/HuC for CI
Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b5f3eb4..a9cc03a 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -152,7 +152,7 @@ struct i915_params i915_modparams __read_mostly = { i915_param_named_unsafe(enable_guc, int, 0400, "Enable GuC load for GuC submission and/or HuC load. " "Required functionality can be selected using bitmask values. " - "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)"); + "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)"); i915_param_named(guc_log_level, int, 0400, "GuC firmware logging level (-1:disabled (default), 0-3:enabled)"); diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/guc: Don't enable GuC when vGPU is active
In GVT-g, if GuC is to be used it is to be loaded by Host and not by VM/vGPU. Currently, GVT-g host is not supported with GuC submission. Also currently vGPU is to be not supported with GuC submission AFAIK. CI BAT highlighted GuC init issue on skl-gvtdvm due to lack of movntdqa needed for logging with below warning: WARN_ON(!i915_memcpy_from_wc(((void *)0), ((void *)0), 0)) WARNING: CPU: 0 PID: 216 at drivers/gpu/drm/i915/intel_guc_log.c:383 This patch disables GuC when vGPU is active. Signed-off-by: Sagar Arun Kamble Cc: Chris Wilson Cc: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Changbin Du --- drivers/gpu/drm/i915/intel_uc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index d82ca0f..a836cf8 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -61,6 +61,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ + if (intel_vgpu_active(dev_priv)) + enable_guc = 0; return enable_guc; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/guc: Redefine guc_log_level modparam values
== Series Details == Series: series starting with [v2,1/2] drm/i915/guc: Redefine guc_log_level modparam values URL : https://patchwork.freedesktop.org/series/36341/ State : success == Summary == Series 36341v1 series starting with [v2,1/2] drm/i915/guc: Redefine guc_log_level modparam values https://patchwork.freedesktop.org/api/1.0/series/36341/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-bdw-5557u) fdo#104162 fail -> PASS (fi-skl-6700k2) fdo#103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fi-bdw-5557u total:245 pass:227 dwarn:0 dfail:0 fail:0 skip:17 fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:375s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:485s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:484s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:483s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:475s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:454s fi-cnl-y2total:288 pass:258 dwarn:3 dfail:0 fail:0 skip:27 time:543s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:275s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:511s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:393s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:412s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:413s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:468s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:500s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:504s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:579s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:512s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:529s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:478s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:431s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:394s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:568s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:472s fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7650/fi-bdw-gvtdvm/igt.log da4321c7c088d01ad62b18d37dcfe5ef8d0b855d drm-tip: 2018y-01m-11d-14h-59m-37s UTC integration manifest 6623668a0fee drm/i915/guc: Change values for i915_guc_log_control a7d4778bb579 drm/i915/guc: Redefine guc_log_level modparam values == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7650/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep
== Series Details == Series: drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep URL : https://patchwork.freedesktop.org/series/36337/ State : failure == Summary == Test kms_plane_multiple: Subgroup atomic-pipe-a-tiling-none: pass -> SKIP (shard-hsw) Subgroup legacy-pipe-b-tiling-none: incomplete -> PASS (shard-hsw) Test kms_busy: Subgroup basic-modeset-a: pass -> SKIP (shard-snb) Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: skip -> PASS (shard-hsw) fdo#101623 +2 Test kms_flip: Subgroup vblank-vs-hang-interruptible: pass -> INCOMPLETE (shard-hsw) Test drv_suspend: Subgroup fence-restore-untiled-hibernate: skip -> FAIL (shard-hsw) fdo#103375 Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hswtotal:2605 pass:1474 dwarn:1 dfail:0 fail:9 skip:1119 time:8494s shard-snbtotal:2713 pass:1309 dwarn:1 dfail:0 fail:11 skip:1392 time:7878s Blacklisted hosts: shard-apltotal:2547 pass:1584 dwarn:1 dfail:0 fail:26 skip:934 time:11842s shard-kbltotal:2609 pass:1725 dwarn:14 dfail:0 fail:28 skip:839 time:8865s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7649/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks
On 11/01/18 11:12, Tvrtko Ursulin wrote: */ + eu_en = ~I915_READ(GEN8_EU_DISABLE0); + for (ss = 0; ss < sseu->max_subslices; ss++) + sseu->eu_mask[ss] = (eu_en >> (8 * ss)) & eu_mask; + /* Slice1 */ + sseu->eu_mask[sseu->max_subslices] = (eu_en >> 24) & eu_mask; + eu_en = ~I915_READ(GEN8_EU_DISABLE1); + sseu->eu_mask[sseu->max_subslices + 1] = eu_en & eu_mask; I suggest a helper to index into sse->eu_mask, like sseu->eu_mask[_eu_mask_idx(slice, subslice)] or something, so it is more readable what is happening here. Or even: _eu_mask(sseu, slice, subslice) = mask; Doable? I am not 100% I picked up exactly on the layout of the eu_mask array.. each element is one subslice? Consecutive for slice0, subslice0..N, slice1... sliceN ? Oops, I misread that part. I thought you wanted a helper for accessing the registers. I'll add a helper for what you would like. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks
On 11/01/2018 15:48, Lionel Landwerlin wrote: On 11/01/18 11:12, Tvrtko Ursulin wrote: On 18/12/2017 15:35, Lionel Landwerlin wrote: Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymetric (for example slice0 asymmetric, thanks auto spell checker. :) Done, thanks. has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all slices. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 23 - drivers/gpu/drm/i915/intel_device_info.c | 169 ++- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 6 files changed, 161 insertions(+), 61 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 0ddce72552bf..0c7890b695c5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4293,7 +4293,7 @@ static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask = BIT(0); - sseu->subslice_mask |= BIT(ss); + sseu->subslices_mask[0] |= BIT(ss); eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) + @@ -4340,7 +4340,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask |= BIT(s); - sseu->subslice_mask = info->sseu.subslice_mask; + sseu->subslices_mask[s] = info->sseu.subslices_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4395,8 +4395,8 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); if (IS_GEN9_BC(dev_priv)) - sseu->subslice_mask = - INTEL_INFO(dev_priv)->sseu.subslice_mask; + sseu->subslices_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4406,7 +4406,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, /* skip disabled subslice */ continue; - sseu->subslice_mask |= BIT(ss); + sseu->subslices_mask[s] |= BIT(ss); } eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & @@ -4428,9 +4428,12 @@ static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK; if (sseu->slice_mask) { - sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask; sseu->eu_per_subslice = INTEL_INFO(dev_priv)->sseu.eu_per_subslice; + for (s = 0; s < fls(sseu->slice_mask); s++) { + sseu->subslices_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; + } sseu->eu_total = sseu->eu_per_subslice * sseu_subslice_total(sseu); @@ -4449,6 +4452,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, { struct drm_i915_private *dev_priv = node_to_i915(m->private); const char *type = is_available_info ? "Available" : "Enabled"; + int s; seq_printf(m, " %s Slice Mask: %04x\n", type, sseu->slice_mask); @@ -4456,10 +4460,10 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, hweight8(sseu->slice_mask)); seq_printf(m, " %s Subslice Total: %u\n", type, sseu_subslice_total(sseu)); - seq_printf(m, " %s Subslice Mask: %04x\n", type, - sseu->subslice_mask); - seq_printf(m, " %s Subslice Per Slice: %u\n", type, - hweight8(sseu->subslice_mask)); + for (s = 0; s < fls(sseu->slice_mask); s++) { Slice mask is always contiguous bits? I have a 2x6 BXT on my desk where the subslice0 appears to be fused-off. I assumed same could be true for slices. fls() should make us iterate through all the slices (even the fused off ones). Do you then want to skip printing the fused off ones? Just asking, don't think it matters hugely. + seq_printf(m, " %s Slice%i Subslice Mask: %04x\n", type, + s, sseu->subslices_mask[s]); Don't want to keep printing the count? Like maybe " %s Slice%u %u sublices, mask=%04x\n" ? Sure, done. + } seq_printf(m, " %s EU Total: %u\n", type, sseu->eu_total); seq_printf(m, " %s EU Per Subslice: %u\n", type, diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 72bea281edb7..8b99
[Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Change values for i915_guc_log_control
Today we have format mismatch between read/write operations of i915_guc_log_control entry. For read we return (0, 1..4) that represents disable/verbosity levels, but for write we force user to follow internal structure format (0,1,9,11,13). Let's hide internals from the user and accept same values as we support for read and related guc_log_level modparam. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_guc_log.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index e6d59bf..1719f1e 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -58,11 +58,15 @@ static int guc_log_flush(struct intel_guc *guc) return intel_guc_send(guc, action, ARRAY_SIZE(action)); } -static int guc_log_control(struct intel_guc *guc, u32 control_val) +static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity) { + union guc_log_control control_val = { .logging_enabled = enable, + .reserved1 = 0, + .verbosity = verbosity, + .reserved2 = 0 }; u32 action[] = { INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING, - control_val + control_val.value }; return intel_guc_send(guc, action, ARRAY_SIZE(action)); @@ -567,28 +571,27 @@ void intel_guc_log_destroy(struct intel_guc *guc) int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val) { struct intel_guc *guc = &dev_priv->guc; - - union guc_log_control log_param; + bool enable_logging = control_val > 0; + u32 verbosity; int ret; - log_param.value = control_val; - - if (log_param.verbosity < GUC_LOG_VERBOSITY_MIN || - log_param.verbosity > GUC_LOG_VERBOSITY_MAX) + BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN); + if (control_val > 1 + GUC_LOG_VERBOSITY_MAX) return -EINVAL; /* This combination doesn't make sense & won't have any effect */ - if (!log_param.logging_enabled && !i915_modparams.guc_log_level) + if (!enable_logging && !i915_modparams.guc_log_level) return 0; - ret = guc_log_control(guc, log_param.value); + verbosity = enable_logging ? control_val - 1 : 0; + ret = guc_log_control(guc, enable_logging, verbosity); if (ret < 0) { DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret); return ret; } - if (log_param.logging_enabled) { - i915_modparams.guc_log_level = 1 + log_param.verbosity; + if (enable_logging) { + i915_modparams.guc_log_level = 1 + verbosity; /* * If log was disabled at boot time, then the relay channel file -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Redefine guc_log_level modparam values
We used value -1 to indicate "disabled" and values 0..3 to indicate "enabled", but most of our other modparams are using -1 for "auto" mode and 0 for "disable". For consistency let's change our log level values to: -1: auto (depends on platform and Kconfig.debug settings) 0: disabled 1: enabled (severity level 0 = min) 2: enabled (severity level 1) 3: enabled (severity level 2) 4: enabled (severity level 3 = max) v2: fix commit message (Sagar) display sanitized modparam value (Sagar) unify sanitize messages (Sagar/Michal) Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_params.c | 3 +- drivers/gpu/drm/i915/intel_guc.c | 21 - drivers/gpu/drm/i915/intel_guc_log.c | 47 +--- drivers/gpu/drm/i915/intel_uc.c | 60 4 files changed, 92 insertions(+), 39 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b5f3eb4..0b553a8 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = { "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)"); i915_param_named(guc_log_level, int, 0400, - "GuC firmware logging level (-1:disabled (default), 0-3:enabled)"); + "GuC firmware logging level. Requires GuC to be loaded. " + "(-1=auto [default], 0=disable, 1..4=enable with verbosity min..max)"); i915_param_named_unsafe(guc_firmware_path, charp, 0400, "GuC firmware path to use instead of the default one"); diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 50b4725..4681537 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -215,6 +215,18 @@ static u32 get_core_family(struct drm_i915_private *dev_priv) } } +static u32 get_log_verbosity_flags(void) +{ + if (i915_modparams.guc_log_level > 0) { + u32 verbosity = i915_modparams.guc_log_level - 1; + + GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX); + return verbosity << GUC_LOG_VERBOSITY_SHIFT; + } + GEM_BUG_ON(i915_modparams.enable_guc < 0); + return GUC_LOG_DISABLED; +} + /* * Initialise the GuC parameter block before starting the firmware * transfer. These parameters are read by the firmware on startup @@ -247,12 +259,7 @@ void intel_guc_init_params(struct intel_guc *guc) params[GUC_CTL_LOG_PARAMS] = guc->log.flags; - if (i915_modparams.guc_log_level >= 0) { - params[GUC_CTL_DEBUG] = - i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT; - } else { - params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED; - } + params[GUC_CTL_DEBUG] = get_log_verbosity_flags(); /* If GuC submission is enabled, set up additional parameters here */ if (USES_GUC_SUBMISSION(dev_priv)) { @@ -445,7 +452,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv) if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) return 0; - if (i915_modparams.guc_log_level >= 0) + if (i915_modparams.guc_log_level) gen9_enable_guc_interrupts(dev_priv); data[0] = INTEL_GUC_ACTION_EXIT_S_STATE; diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index eaedd63..e6d59bf 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -33,11 +33,10 @@ /** * DOC: GuC firmware log * - * Firmware log is enabled by setting i915.guc_log_level to non-negative level. + * Firmware log is enabled by setting i915.guc_log_level to the positive level. * Log data is printed out via reading debugfs i915_guc_log_dump. Reading from * i915_guc_load_status will print out firmware loading status and scratch * registers value. - * */ static int guc_log_flush_complete(struct intel_guc *guc) @@ -147,7 +146,7 @@ static int guc_log_relay_file_create(struct intel_guc *guc) struct dentry *log_dir; int ret; - if (i915_modparams.guc_log_level < 0) + if (!i915_modparams.guc_log_level) return 0; /* For now create the log file in /sys/kernel/debug/dri/0 dir */ @@ -423,8 +422,8 @@ static void guc_log_runtime_destroy(struct intel_guc *guc) { /* * It's possible that the runtime stuff was never allocated because -* guc_log_level was < 0 at the time -**/ +* GuC log was disabled at the boot time. +*/ if (!guc_log_has_runtime(guc)) return; @@ -441,9 +440,10 @@ static int guc_log_late_setup(struct intel_guc *guc) lockdep_assert_held(&dev_priv->drm.struct_mutex); if (!guc_log_has_runtime(guc)) { -
Re: [Intel-gfx] [PATCH 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu
On 11/01/18 11:21, Tvrtko Ursulin wrote: On 18/12/2017 15:35, Lionel Landwerlin wrote: Now that we have that information in topology fields, let's just reused it. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 0c7890b695c5..6ec7543e698f 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4308,11 +4308,11 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { const struct intel_device_info *info = INTEL_INFO(dev_priv); - int s_max = 6, ss_max = 4; int s, ss; - u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2]; + u32 s_reg[info->sseu.max_slices], + eu_reg[2 * info->sseu.max_subslices], eu_mask[2]; This is a bit unusual style, perhaps split into separate declarations. Done. - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { /* * FIXME: Valid SS Mask respects the spec and read * only valid bits for those registers, excluding reserverd @@ -4334,7 +4334,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4342,7 +4342,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); sseu->subslices_mask[s] = info->sseu.subslices_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss @@ -4362,17 +4362,11 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { - int s_max = 3, ss_max = 4; + const struct intel_device_info *info = INTEL_INFO(dev_priv); int s, ss; - u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2]; - - /* BXT has a single slice and at most 3 subslices. */ - if (IS_GEN9_LP(dev_priv)) { - s_max = 1; - ss_max = 3; - } + u32 s_reg[info->sseu.max_slices], eu_reg[2*info->sseu.max_subslices], eu_mask[2]; Spaces around operators are preferred. Done. - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s)); eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s)); eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s)); @@ -4387,7 +4381,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4398,7 +4392,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->subslices_mask[s] = INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (IS_GEN9_LP(dev_priv)) { With the formatting tweaks, Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks
On 11/01/18 11:12, Tvrtko Ursulin wrote: On 18/12/2017 15:35, Lionel Landwerlin wrote: Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymetric (for example slice0 asymmetric, thanks auto spell checker. :) Done, thanks. has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all slices. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 23 - drivers/gpu/drm/i915/intel_device_info.c | 169 ++- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 6 files changed, 161 insertions(+), 61 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 0ddce72552bf..0c7890b695c5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4293,7 +4293,7 @@ static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask = BIT(0); - sseu->subslice_mask |= BIT(ss); + sseu->subslices_mask[0] |= BIT(ss); eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) + @@ -4340,7 +4340,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask |= BIT(s); - sseu->subslice_mask = info->sseu.subslice_mask; + sseu->subslices_mask[s] = info->sseu.subslices_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4395,8 +4395,8 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); if (IS_GEN9_BC(dev_priv)) - sseu->subslice_mask = - INTEL_INFO(dev_priv)->sseu.subslice_mask; + sseu->subslices_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4406,7 +4406,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, /* skip disabled subslice */ continue; - sseu->subslice_mask |= BIT(ss); + sseu->subslices_mask[s] |= BIT(ss); } eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & @@ -4428,9 +4428,12 @@ static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK; if (sseu->slice_mask) { - sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask; sseu->eu_per_subslice = INTEL_INFO(dev_priv)->sseu.eu_per_subslice; + for (s = 0; s < fls(sseu->slice_mask); s++) { + sseu->subslices_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; + } sseu->eu_total = sseu->eu_per_subslice * sseu_subslice_total(sseu); @@ -4449,6 +4452,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, { struct drm_i915_private *dev_priv = node_to_i915(m->private); const char *type = is_available_info ? "Available" : "Enabled"; + int s; seq_printf(m, " %s Slice Mask: %04x\n", type, sseu->slice_mask); @@ -4456,10 +4460,10 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, hweight8(sseu->slice_mask)); seq_printf(m, " %s Subslice Total: %u\n", type, sseu_subslice_total(sseu)); - seq_printf(m, " %s Subslice Mask: %04x\n", type, - sseu->subslice_mask); - seq_printf(m, " %s Subslice Per Slice: %u\n", type, - hweight8(sseu->subslice_mask)); + for (s = 0; s < fls(sseu->slice_mask); s++) { Slice mask is always contiguous bits? I have a 2x6 BXT on my desk where the subslice0 appears to be fused-off. I assumed same could be true for slices. fls() should make us iterate through all the slices (even the fused off ones). + seq_printf(m, " %s Slice%i Subslice Mask: %04x\n", type, + s, sseu->subslices_mask[s]); Don't want to keep printing the count? Like maybe " %s Slice%u %u sublices, mask=%04x\n" ? Sure, done. + } seq_printf(m, " %s EU Total: %u\n", type, sseu->eu_total); seq_printf(m, " %s EU Per Subslice: %u\n", type, diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 72bea281edb7..8b99e415c345 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -414,7 +414,7 @@ static int i915_getparam(struct drm_d
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave - Hopefully final drm/i915 fixes for v4.15: - Fix a KASAN reported use after free - Whitelist a register to avoid hangs - GVT fixes BR, Jani. The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d: Linux 4.15-rc7 (2018-01-07 14:22:41 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-01-11-1 for you to fetch changes up to 5005c8514285ae4f28e862f8d91faaa2015e03a3: drm/i915: Don't adjust priority on an already signaled fence (2018-01-11 11:42:53 +0200) Hopefully final drm/i915 fixes for v4.15: - Fix a KASAN reported use after free - Whitelist a register to avoid hangs - GVT fixes Changbin Du (1): drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser Chris Wilson (1): drm/i915: Don't adjust priority on an already signaled fence Jani Nikula (1): Merge tag 'gvt-fixes-2018-01-08' of https://github.com/intel/gvt-linux into drm-intel-fixes Kenneth Graunke (1): drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. Zhi Wang (1): drm/i915/gvt: Clear the shadow page table entry after post-sync drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/gvt/gtt.c | 5 - drivers/gpu/drm/i915/i915_gem.c| 2 +- drivers/gpu/drm/i915/i915_reg.h| 2 ++ drivers/gpu/drm/i915/intel_engine_cs.c | 5 + drivers/gpu/drm/i915/intel_lrc.c | 3 +++ 6 files changed, 17 insertions(+), 4 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep
Quoting Tvrtko Ursulin (2018-01-11 14:12:38) > You beat me to it, after I noticed the report on IRC and started > digging, just to find sysfs_attr_init, your fix arrived. Thanks! > > It looks like a standard way of silencing lockdep for this case, > although I am not sure what exactly is the purpose of lock class keys in > sysfs attributes, and what this kind of defeat could also imply. > > I planned to do it another loop, iterating the attr array, but I don't > see how it matters. It would be one static key versus the two. :? It shouldn't as far as I'm aware. I'm conscious that each static attr has its own lockclass, but dynamic users tend to have a shared lockclass. It shouldn't matter unless we nest the sysfs operations? -Chris ___ 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/pmu: Initialise our dynamic sysfs attributes for use with lockdep
Quoting Patchwork (2018-01-11 14:39:43) > == Series Details == > > Series: drm/i915/pmu: Initialise our dynamic sysfs attributes for use with > lockdep > URL : https://patchwork.freedesktop.org/series/36337/ > State : success > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7649/issues.html Looks like it did the job. Thanks for double checking, and pushed, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 282dbf9b "drm/i915: Pass intel_plane and intel_crtc to plane hooks" breaks i945GM in 4.13 and above
Hello, I have an old Lenovo Thinkpad X60 laptop with a Core 2 Duo T7200 CPU and i945GM integrated graphics whose graphics broke when I tried to update the kernel to get the Meltdown fixes. GRUB2 shows a graphical boot menu, and Linux displays the Tux boot logos correctly at first. However, almost immediately after displaying the Tuxes, the actively scrolling area of the display shifts about two text lines downward, so that two decapitated penguin heads are left at the top of the screen and new text appears below the lower edge of the screen. When X starts, it too is shifted down the same amount, and only shows a black screen with a (working) mouse cursor. My display manager (SDDM) never shows up. Sometimes, while X is running, random pixels appear in the non-active area at the top of the screen containing the decapitated penguin heads. My hardware is: $ grep name /proc/cpuinfo model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz model name : Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) # grep Chipset: /var/log/Xorg.0.log [33.085] (--) intel(0): Integrated Graphics Chipset: Intel(R) 945GM $ xrandr | grep primary LVDS1 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 250mm x 180mm Kernel 4.12.14 does not have the bug. 4.13 and 4.14.11 have the bug in console and X mode. 4.15-rc7 has the bug in console mode, but crashes (completely black screen, Magic SysRq to reboot is the only thing that works) when starting X. Bisecting from 4.12 to 4.13 pointed to this as the first bad commit: commit 282dbf9b017bc6d5fdaeadf14e534c2fe22fee2d Author: Ville Syrjälä Date: Mon Mar 27 21:55:33 2017 +0300 drm/i915: Pass intel_plane and intel_crtc to plane hooks But I know nothing about the driver internals to explain why. -- Karl-Johan Karlsson signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set (rev2)
HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Petri Latvala > Sent: torstai 11. tammikuuta 2018 12.02 > To: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ignore TMDS clock > limit for DP++ when EDID override is set (rev2) > > On Thu, Jan 11, 2018 at 09:54:02AM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Ignore TMDS clock limit for DP++ when EDID override is > set (rev2) > > URL : https://patchwork.freedesktop.org/series/35338/ > > State : failure > > > > == Summary == > > > > Warning: bzip CI_DRM_3609/shard-glkb6/results32.json.bz2 wasn't in > > correct JSON format Test kms_cursor_crc: > > Subgroup cursor-64x21-onscreen: > > skip -> PASS (shard-hsw) > > Subgroup cursor-64x64-suspend: > > skip -> PASS (shard-snb) fdo#102365 > > skip -> PASS (shard-hsw) fdo#103540 > > Test drv_suspend: > > Subgroup debugfs-reader: > > pass -> SKIP (shard-snb) > > Test kms_frontbuffer_tracking: > > Subgroup fbc-1p-offscren-pri-shrfb-draw-render: > > fail -> PASS (shard-snb) fdo#101623 > > Test kms_flip: > > Subgroup vblank-vs-modeset-suspend: > > pass -> INCOMPLETE (shard-hsw) > > > > fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 > > fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 > > fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > shard-hswtotal:2681 pass:1521 dwarn:1 dfail:0 fail:10 skip:1148 > time:8681s > > shard-snbtotal:2713 pass:1310 dwarn:1 dfail:0 fail:10 skip:1392 > time:7926s > > Blacklisted hosts: > > shard-apltotal:2713 pass:1684 dwarn:1 dfail:0 fail:25 skip:1002 > time:13555s > > shard-kbltotal:2713 pass:1808 dwarn:1 dfail:0 fail:24 skip:880 > time:10569s > > > > == Logs == > > > > For more details see: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7628/shards.html > > kbl results now shown in the text diff but this page shows: > > igt@kms_hdmi_inject@inject-4k fail -> PASS This was expected here. Jani N, how do you patch in general? > > > -- > Petri Latvala ___ 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/pmu: Initialise our dynamic sysfs attributes for use with lockdep
== Series Details == Series: drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep URL : https://patchwork.freedesktop.org/series/36337/ State : success == Summary == Series 36337v1 drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep https://patchwork.freedesktop.org/api/1.0/series/36337/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test kms_chamelium: Subgroup dp-edid-read: dmesg-warn -> PASS (fi-kbl-7500u) fdo#102505 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-kbl-r) fdo#104172 +1 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:422s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:485s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:487s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:469s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:458s fi-cnl-y2total:288 pass:258 dwarn:3 dfail:0 fail:0 skip:27 time:535s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:274s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:514s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:390s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:400s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:459s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:414s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:465s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:499s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:457s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:505s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:579s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:425s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:532s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:493s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:473s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:527s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:571s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:471s d9bbaa0c520357cb67793548f2817ab4de55089b drm-tip: 2018y-01m-11d-12h-31m-18s UTC integration manifest c79818971e71 drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7649/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] drm/i915/cnl: Add Port F definition.
Em Sex, 2017-12-22 às 15:18 -0800, Rodrigo Vivi escreveu: > Some Cannonlake SKUs will come with a full split between > port A and port E. This will be called port F although it > is not a 6th port, but only a split. I think that a small comment explaining that port F support is still not complete even with this patch would help. One more comment below. > > v2: Fix size of dvo_ports found by Ander. > v3: Adding missing cases from intel_bios.c for Port_F > v4: Adding other missing cases and fix the commit message. > v5: Rebase on top of display headers rework. > > Cc: Lucas De Marchi > Cc: Manasi Navare > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_bios.c | 9 + > drivers/gpu/drm/i915/intel_display.h | 1 + > drivers/gpu/drm/i915/intel_dp.c | 2 ++ > drivers/gpu/drm/i915/intel_vbt_defs.h | 2 ++ > include/drm/i915_component.h | 3 +-- > 5 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index 51108ffc28d1..59a150e2adce 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1140,6 +1140,7 @@ static void parse_ddi_port(struct > drm_i915_private *dev_priv, enum port port, > {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}, > }; > > /* > @@ -1688,6 +1689,7 @@ bool intel_bios_is_port_present(struct > drm_i915_private *dev_priv, enum port por > [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, }, > [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, }, > [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, }, > + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, }, > }; > int i; > > @@ -1726,6 +1728,7 @@ bool intel_bios_is_port_edp(struct > drm_i915_private *dev_priv, enum port port) > [PORT_C] = DVO_PORT_DPC, > [PORT_D] = DVO_PORT_DPD, > [PORT_E] = DVO_PORT_DPE, > + [PORT_F] = DVO_PORT_DPF, > }; > int i; > > @@ -1761,6 +1764,7 @@ static bool child_dev_is_dp_dual_mode(const > struct child_device_config *child, > [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, }, > [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, }, > [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, }, > + [PORT_F] = { DVO_PORT_DPF, DVO_PORT_HDMIF, }, > }; > > if (port == PORT_A || port >= ARRAY_SIZE(port_mapping)) > @@ -1927,6 +1931,11 @@ intel_bios_is_lspcon_present(struct > drm_i915_private *dev_priv, > if (port == PORT_D) > return true; > break; > + case DVO_PORT_DPF: > + case DVO_PORT_HDMIF: > + if (port == PORT_F) > + return true; > + break; > default: > break; > } > diff --git a/drivers/gpu/drm/i915/intel_display.h > b/drivers/gpu/drm/i915/intel_display.h > index a0d2b6169361..e47638931b51 100644 > --- a/drivers/gpu/drm/i915/intel_display.h > +++ b/drivers/gpu/drm/i915/intel_display.h > @@ -119,6 +119,7 @@ enum port { > PORT_C, > PORT_D, > PORT_E, > + PORT_F, > > I915_MAX_PORTS > }; > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c > index 35c5299feab6..71721de39e6b 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1378,6 +1378,7 @@ static i915_reg_t skl_aux_ctl_reg(struct > drm_i915_private *dev_priv, > case PORT_B: > case PORT_C: > case PORT_D: > + case PORT_F: > return DP_AUX_CH_CTL(port); > default: > MISSING_CASE(port); > @@ -1393,6 +1394,7 @@ static i915_reg_t skl_aux_data_reg(struct > drm_i915_private *dev_priv, > case PORT_B: > case PORT_C: > case PORT_D: > + case PORT_F: > return DP_AUX_CH_DATA(port, index); > default: > MISSING_CASE(port); > diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h > b/drivers/gpu/drm/i915/intel_vbt_defs.h > index e3d7745a9151..8713e8295957 100644 > --- a/drivers/gpu/drm/i915/intel_vbt_defs.h > +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h > @@ -299,6 +299,8 @@ struct bdb_general_features { > #define DVO_PORT_DPA 10 > #define DVO_PORT_DPE 11 > /* 193 */ > #define DVO_PORT_HDMIE 12 > /* 193 */ > +#define DVO_PORT_DPF 13 > +#define DVO_PORT_HDMIF 14 Needs ones more tab before the number. Besides, I suppose we could "/* N/A */" or /* Missing from spec */ or something that clarifies that it's not that our code is missing the version, it's the spec that doesn't have it. Wit
Re: [Intel-gfx] [PATCH 06/11] drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
Em Sex, 2017-12-22 às 15:18 -0800, Rodrigo Vivi escreveu: > On CNP Pin 3 is for misc of Port F usage depending on the > configuration. For CNL that uses Port F, pin 3 is the one. > > v2: Make it more generic and update commit message. Reviewed-by: Paulo Zanoni > > Cc: Anusha Srivatsa > Cc: Lucas De Marchi > Cc: Manasi Navare > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_hdmi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index bced7b954d93..6f460c4534fa 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1924,6 +1924,9 @@ static u8 cnp_port_to_ddc_pin(struct > drm_i915_private *dev_priv, > case PORT_D: > ddc_pin = GMBUS_PIN_4_CNP; > break; > + case PORT_F: > + ddc_pin = GMBUS_PIN_3_BXT; > + break; > default: > MISSING_CASE(port); > ddc_pin = GMBUS_PIN_1_BXT; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep
On 11/01/2018 14:04, Chris Wilson wrote: As we kmalloc our dynamic sysfs attributes, we have to give them an external static lock_class_key for them to use with lockdep. Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pmu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index 9139bc8df82b..95ab5e28f5be 100644 --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -719,6 +719,7 @@ static const struct attribute_group *i915_pmu_attr_groups[] = { static struct i915_ext_attribute * add_i915_attr(struct i915_ext_attribute *attr, const char *name, u64 config) { + sysfs_attr_init(&attr->attr.attr); attr->attr.attr.name = name; attr->attr.attr.mode = 0444; attr->attr.show = i915_pmu_event_show; @@ -731,6 +732,7 @@ static struct perf_pmu_events_attr * add_pmu_attr(struct perf_pmu_events_attr *attr, const char *name, const char *str) { + sysfs_attr_init(&attr->attr.attr); attr->attr.attr.name = name; attr->attr.attr.mode = 0444; attr->attr.show = perf_event_sysfs_show; You beat me to it, after I noticed the report on IRC and started digging, just to find sysfs_attr_init, your fix arrived. Thanks! It looks like a standard way of silencing lockdep for this case, although I am not sure what exactly is the purpose of lock class keys in sysfs attributes, and what this kind of defeat could also imply. I planned to do it another loop, iterating the attr array, but I don't see how it matters. It would be one static key versus the two. :? Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2 6/8] drm: Handle fbdev emulation in core
Den 11.01.2018 08.45, skrev Daniel Vetter: On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote: Den 09.01.2018 11.38, skrev Daniel Vetter: On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote: Prepare for generic fbdev emulation by letting DRM core work directly with the fbdev compatibility layer. This is done by adding new fbdev helper vtable callbacks for restore, hotplug_event, unregister and release. Signed-off-by: Noralf Trønnes No clue whether my idea is any good, but inspired by the bootsplash discussion, and the prospect that we might get other in-kernel drm/kms clients I'm wondering whether we should make this a bit more generic and tie it to drm_file? The idea would be to have a list of internal drm clients by putting all the internal drm_files onto a list (same way we do with the userspace ones). Then we'd just walk that list and call ->hotplug, ->unregister and ->release at the right places. ->restore would be a bit different, I guess for that we'd only call the ->restore callback of the very first kernel-internal client. With that we could then add/remove kernel-internal drm clients like normal userspace clients, which should make integration of emergency consoles, boot splashes and whatever else real easy. And I think it would be a lot cleaner than leaking fb_helper knowledge into the drm core, which feels a rather backwards. Otoh that feels a bit overengineered (but at least it shouldn't be a lot more code really). If the list is too much work we could start with 1 drm_file * pointer for internal stuff (but would still need locking, so list_head is probably easier). Thoughts? I prefer to have a proper in-kernel client API from the get go, instead of fixing it up later. The reason I skipped spending time on it in this RFC, was that I didn't know if I was on the right track at the right time to get the necessary attention to make this dumb_buffer idea happen. With a drm_file centric approach, are you thinking something like this: struct drm_device { + struct list_head filelist_internal; }; +struct drm_file_funcs { + int (*restore)(struct drm_file *file); + void (*hotplug)(struct drm_file *file); + void (*unregister)(struct drm_file *file); I guess we still need a cleanup callback here? For the usual two-stage driver unload sequence of 1. unregister 2. cleanup. There's no need for a cleanup callback in this scenario. The client holds a ref on drm_device through drm_internal_open() and if it can't release the drm_file on .unregister, there won't be any cleanup. When the client is in a position to release drm_file (fb_close), it will do so and the ref is dropped. If for some reason we can't take a ref, then we need to use drm_device.open_count to avoid drm_device going away in drm_dev_unplug(). Noralf. +}; struct drm_file { + struct drm_device *dev; + const struct drm_file_funcs *funcs; }; struct drm_file *drm_file_alloc(struct drm_minor *minor) { + file->dev = dev; } struct drm_file* drm_internal_open(struct drm_device *dev, const struct drm_file_funcs *funcs) struct drm_file *file; int ret; if (!try_module_get(dev->driver->fops->owner)) return ERR_PTR(-ENODEV); drm_dev_ref(dev); file = drm_file_alloc(dev); if (IS_ERR(file)) { drm_dev_unref(dev); module_put(dev->driver->fops->owner); return file; } file->funcs = funcs; mutex_lock(&dev->filelist_mutex); list_add(&file->lhead, &dev->filelist_internal); mutex_unlock(&dev->filelist_mutex); return file; } void drm_internal_release(struct drm_file *file) { struct drm_device *dev = file->dev; mutex_lock(&dev->filelist_mutex); list_del(&file->lhead); mutex_unlock(&dev->filelist_mutex); drm_file_free(file); drm_dev_unref(dev); module_put(dev->driver->fops->owner); } void drm_lastclose(struct drm_device *dev) { + mutex_lock(&dev->filelist_mutex); + list_for_each_entry(file, &dev->filelist_internal, lhead) { + if (file->funcs && file->funcs->restore && + !file->funcs->restore(file)) + break; + mutex_unlock(&dev->filelist_mutex); } void drm_kms_helper_hotplug_event(struct drm_device *dev) { + mutex_lock(&dev->filelist_mutex); + list_for_each_entry(file, &dev->filelist_internal, lhead) { + if (file->funcs && file->funcs->hotplug) + file->funcs->hotplug(file); + mutex_unlock(&dev->filelist_mutex); } How is locking done when .unregister will call into drm_internal_release()? void drm_dev_unregister(struct drm_device *dev) { + list_for_each_entry(file, &dev->filelist_internal, lhead) { + if (file->funcs && file->funcs->unregister) + file->funcs->unregister(file); } There is also the case where .unregister can't release the drm_file because userspace has mmap'ed the buffer (fbdev). The client holds a ref on
[Intel-gfx] [PATCH] drm/i915/pmu: Initialise our dynamic sysfs attributes for use with lockdep
As we kmalloc our dynamic sysfs attributes, we have to give them an external static lock_class_key for them to use with lockdep. Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pmu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index 9139bc8df82b..95ab5e28f5be 100644 --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -719,6 +719,7 @@ static const struct attribute_group *i915_pmu_attr_groups[] = { static struct i915_ext_attribute * add_i915_attr(struct i915_ext_attribute *attr, const char *name, u64 config) { + sysfs_attr_init(&attr->attr.attr); attr->attr.attr.name = name; attr->attr.attr.mode = 0444; attr->attr.show = i915_pmu_event_show; @@ -731,6 +732,7 @@ static struct perf_pmu_events_attr * add_pmu_attr(struct perf_pmu_events_attr *attr, const char *name, const char *str) { + sysfs_attr_init(&attr->attr.attr); attr->attr.attr.name = name; attr->attr.attr.mode = 0444; attr->attr.show = perf_event_sysfs_show; -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/1] tools: Update .gitignore
== Series Details == Series: series starting with [1/1] tools: Update .gitignore URL : https://patchwork.freedesktop.org/series/36322/ State : failure == Summary == IGT patchset tested on top of latest successful build d37369c7146a2ceb332592297d311d501c1c748e Revert "build: make meson more official" damage with latest DRM-Tip kernel build CI_DRM_3621 d9bbaa0c5203 drm-tip: 2018y-01m-11d-12h-31m-18s UTC integration manifest No testlist changes. Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 Test gem_exec_flush: Subgroup basic-uc-pro-default: pass -> INCOMPLETE (fi-cnl-y2) Test kms_chamelium: Subgroup dp-edid-read: dmesg-warn -> PASS (fi-kbl-7500u) fdo#102505 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-kbl-r) fdo#104172 +1 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:411s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:423s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:361s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:444s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:260s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:463s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:464s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:430s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:427s fi-cnl-y2total:53 pass:45 dwarn:0 dfail:0 fail:0 skip:7 fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:247s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:496s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:383s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:392s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:403s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:448s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:401s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:456s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:498s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:442s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:490s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:422s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:502s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:516s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:484s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:419s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:387s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:557s fi-glk-dsi total:288 pass:257 dwarn:0 dfail:0 fail:1 skip:30 time:453s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_769/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for build: make meson more official
== Series Details == Series: build: make meson more official URL : https://patchwork.freedesktop.org/series/36320/ State : failure == Summary == Applying: build: make meson more official Using index info to reconstruct a base tree... M CONTRIBUTING M NEWS M README M meson.sh Falling back to patching base and 3-way merge... Auto-merging README CONFLICT (content): Merge conflict in README Auto-merging CONTRIBUTING CONFLICT (content): Merge conflict in CONTRIBUTING Patch failed at 0001 build: make meson more official The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] tests/perf_pmu: Verify busyness when PMU is enabled after engine got busy (rev3)
== Series Details == Series: series starting with [v2,1/2] tests/perf_pmu: Verify busyness when PMU is enabled after engine got busy (rev3) URL : https://patchwork.freedesktop.org/series/36201/ State : failure == Summary == IGT patchset tested on top of latest successful build d37369c7146a2ceb332592297d311d501c1c748e Revert "build: make meson more official" damage with latest DRM-Tip kernel build CI_DRM_3621 d9bbaa0c5203 drm-tip: 2018y-01m-11d-12h-31m-18s UTC integration manifest Testlist changes: +igt@perf_pmu@busy-double-start-bcs0 +igt@perf_pmu@busy-double-start-rcs0 +igt@perf_pmu@busy-double-start-vcs0 +igt@perf_pmu@busy-double-start-vcs1 +igt@perf_pmu@busy-double-start-vecs0 +igt@perf_pmu@busy-start-bcs0 +igt@perf_pmu@busy-start-rcs0 +igt@perf_pmu@busy-start-vcs0 +igt@perf_pmu@busy-start-vcs1 +igt@perf_pmu@busy-start-vecs0 Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test gem_ringfill: Subgroup basic-default: pass -> INCOMPLETE (fi-cnl-y2) Test kms_chamelium: Subgroup dp-edid-read: dmesg-warn -> PASS (fi-kbl-7500u) fdo#102505 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:410s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:414s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:359s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:451s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:262s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:461s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:432s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:423s fi-cnl-y2total:142 pass:130 dwarn:0 dfail:0 fail:0 skip:11 fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:245s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:501s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:382s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:392s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:404s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:449s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:403s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:458s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:492s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:443s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:494s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:488s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:414s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:497s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:519s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:484s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:423s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:526s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:391s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:563s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:452s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_767/issues.html ___ 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: Reinitialize sink scrambling/TMDS clock ratio on HPD
Regards Shashank On 1/10/2018 9:53 PM, Ville Syrjälä wrote: On Wed, Jan 10, 2018 at 10:07:43AM +0530, Sharma, Shashank wrote: Regards Shashank On 1/9/2018 11:31 PM, Ville Syrjälä wrote: On Thu, Dec 28, 2017 at 08:32:05PM +0530, Sharma, Shashank wrote: On 12/22/2017 11:58 PM, Ville Syrjala wrote: From: Ville Syrjälä The LG 4k TV I have doesn't deassert HPD when I turn the TV off, but when I turn it back on it will pulse the HPD line. By that time it has forgotten everything we told it about scrambling and the clock ratio. Hence if we want to get a picture out if it again we have to tell it whether we're currently sending scrambled data or not. Implement that via the encoder->post_hotplug() hook. I am not sure if I understood the problem statement correctly. Even if the TV triggers HPD line while turning it back, I would expect: - EDID read for TV's detection, which will refresh SCDC and scrambling capabilities - A new modeset will be triggered, which will program the scrambling and high tmds clock ratio again - Once HDMI controller is programmed, it will generate scrambled signals till next modeset / disable. So why do we need to do this ? I might be missing something, but lets discus about it. The EDID is readable even when the HPD gets deasserted for a short perios, hence we never consider the sink as being disconnected. Hence there will be no modeset triggered by userspace. This is a bigger problem then, in that case, the pipe/port would be enabled, and IMHO I don't think fixing just the scrambling status is right thing to do. Hmm. The spec does say "the Source shall not begin transmission of a scrambled video signal before writing a 1 to the Scrambling_Enable bit". So I guess you're right. We can't follow that rule 100% though because we can't detect that the the sink has been turned off. If we checked the live hpd status during hpd processing we should be able to detect that the sink was logically disconnected for a short period, but as we know the live hpd status is not exactly reliable for HDMI. Also that would still be racy on account of hpd processing delays. Agree. This inaccuracy of Live status HW has been a nightmare for us since a long time, it really cripples proper hotplug handling. When talking about the TMDS clock ratio the spec says that we have to suspend TMDS clock/data transmission when we change the TMDS clock ratio setting in the sink. So I guess what we could do is force a full modeset if and when the sink has become confused about these settings. Or if we want to optimize things a bit I suppose we could just turn off DDI_BUF_CTL around the operation. But probably no point in optimizing that part since it's a rare event. Agree, again. Also it would be difficult to detect exactly when do we have a genuine confusion :-) - Shashank Also, is this the right behavior from the monitor ? I am also worried if we are trying to fix the monitor's fault in our driver. I don't think that's specified anywhere. Also doesn't matter because we have to fix sink specific issues in the driver all the time. Otherwise a lot of sinks would just fail to work. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] x86/gpu: add CFL to early quirks
On 15.12.2017 23:19, Rodrigo Vivi wrote: > On Fri, Dec 15, 2017 at 04:39:25PM +, Ingo Molnar wrote: >> >> * Lucas De Marchi wrote: >> >>> CFL was missing from intel_early_ids[]. The PCI ID needs to be there to >>> allow the memory region to be stolen, otherwise we could have RAM being >>> arbitrarily overwritten if for example we keep using the UEFI framebuffer, >>> depending on how BIOS has set up the e820 map. >>> >>> Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.") >>> Signed-off-by: Lucas De Marchi >>> Cc: Rodrigo Vivi >>> Cc: Anusha Srivatsa >>> Cc: Jani Nikula >>> Cc: Joonas Lahtinen >>> Cc: David Airlie >>> Cc: intel-gfx@lists.freedesktop.org >>> Cc: dri-de...@lists.freedesktop.org >>> Cc: Ingo Molnar >>> Cc: H. Peter Anvin >>> Cc: Thomas Gleixner >>> Cc: x...@kernel.org >>> Cc: # v4.13+ 0890540e21cf drm/i915: add GT number >>> to intel_device_info >>> Cc: # v4.13+ 41693fd52373 drm/i915/kbl: Change a >>> KBL pci id to GT2 from GT1.5 >>> Cc: # v4.13+ >>> Reviewed-by: Rodrigo Vivi >>> --- >>> >>> v2: improve commit message, add Fixes tag and CC stable >>> >>> arch/x86/kernel/early-quirks.c | 1 + >>> include/drm/i915_pciids.h | 6 ++ >>> 2 files changed, 7 insertions(+) >> >> Acked-by: Ingo Molnar > > Merged to drm-intel-next-queued. > Thanks for the patches, suggestions and acks. Shouldn't this go to v4.15 as well, because CFL is enabled there? I don't see it in rc8. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915: expose rcs topology through query uAPI
On 18/12/2017 15:35, Lionel Landwerlin wrote: With the introduction of asymetric slices in CNL, we cannot rely on asymmetric the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts of the GPU with the OA unit, because counters need to be normalized to the number of EUs/subslices/slices. The current aggregated numbers like EU_TOTAL do not gives us sufficient information. As a bonus we can draw representations of the GPU : https://imgur.com/a/vuqpa Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_query.c | 134 drivers/gpu/drm/i915/intel_query_info.c | 88 + include/uapi/drm/i915_drm.h | 45 +++ 3 files changed, 267 insertions(+) create mode 100644 drivers/gpu/drm/i915/intel_query_info.c diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c index 227a28978190..7c0eb09d3aac 100644 --- a/drivers/gpu/drm/i915/i915_query.c +++ b/drivers/gpu/drm/i915/i915_query.c @@ -25,24 +25,158 @@ #include "i915_drv.h" #include +static int query_slices_mask(struct drm_i915_private *dev_priv, +struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_slices_mask slices_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; Do you need to handle this explicitly or just return all zeros? I guess I don't know which GPUs have zero slices. + + memset(&slices_info, 0, sizeof(slices_info)); Is this needed since a) you will write to the only field just below, and b) it won't clear the tail data array anyway? + + slices_info.n_slices = sseu->max_slices; Move to after the query_item->length checks. + + data_length = sizeof(u8); Size is dependant on number of slices? DIV_ROUND_UP(n_slices, BITS_PER_BYTE) ? + length = sizeof(struct drm_i915_query_slices_mask) + data_length; sizeof(slices_info) + + /* +* If we ever change the internal slice mask data type, we'll need to +* update this function. +*/ + BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask)); Hm a bit weak since it is not only about size but also data representation. But I don't have any better ideas. + + if (query_item->length == 0) { + query_item->length = length; + return 0; + } + + if (query_item->length != length) + return -EINVAL; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), &slices_info, +sizeof(slices_info))) + return -EFAULT; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + +offsetof(struct drm_i915_query_slices_mask, data)), +&sseu->slice_mask, data_length)) + return -EFAULT; + + return 0; +} Some of the above comments also apply to the other two query functions below. +static int query_subslices_mask(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_subslices_mask subslices_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; + + memset(&subslices_info, 0, sizeof(subslices_info)); + + subslices_info.n_slices = sseu->max_slices; + subslices_info.slice_stride = ALIGN(sseu->max_subslices, 8) / 8; + + data_length = subslices_info.n_slices * subslices_info.slice_stride; + length = sizeof(struct drm_i915_query_subslices_mask) + data_length; + + if (query_item->length == 0) { + query_item->length = length; + return 0; + } + + if (query_item->length != length) + return -EINVAL; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr), &subslices_info, +sizeof(subslices_info))) + return -EFAULT; + + if (copy_to_user(u64_to_user_ptr(query_item->data_ptr + +offsetof(struct drm_i915_query_subslices_mask, data)), +sseu->subslices_mask, data_length)) + return -EFAULT; + + return 0; +} + +static int query_eus_mask(struct drm_i915_private *dev_priv, + struct drm_i915_query_item *query_item) +{ + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + struct drm_i915_query_eus_mask eus_info; + u32 data_length, length; + + if (sseu->max_slices == 0) + return -ENODEV; + +
Re: [Intel-gfx] [PATCH 5/6] drm/i915: add query uAPI
On 18/12/2017 15:35, Lionel Landwerlin wrote: There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die recovery). At the moment the GET_PARAM ioctl covers some basic needs, but generally is only able to return a single value for each defined parameter. This is a bit problematic with topology descriptions which are array/maps of available units. This change introduces a new ioctl that can deal with requests to fill structures of potentially variable lengths. The user is expected fill a query with length fields set at 0 on the first call, the kernel then sets the length fields to the their expected values. A second call to the kernel with length fields at their expected values will trigger a copy of the data to the pointed memory locations. The scope of this uAPI is only to provide information to userspace, not to allow configuration of the device. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/i915_query.c | 52 +++ include/uapi/drm/i915_drm.h | 31 +++ 5 files changed, 88 insertions(+) create mode 100644 drivers/gpu/drm/i915/i915_query.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 091aef281963..9627e7e309dc 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -69,6 +69,7 @@ i915-y += i915_cmd_parser.o \ i915_gem_timeline.o \ i915_gem_userptr.o \ i915_gemfs.o \ + i915_query.o \ i915_trace_points.o \ i915_vma.o \ intel_breadcrumbs.o \ diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 8b99e415c345..a90ed9f2b759 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -2814,6 +2814,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW), }; static struct drm_driver driver = { diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 82fc59078c6a..3415a3d2399c 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -4084,6 +4084,9 @@ extern void i915_perf_fini(struct drm_i915_private *dev_priv); extern void i915_perf_register(struct drm_i915_private *dev_priv); extern void i915_perf_unregister(struct drm_i915_private *dev_priv); +/* i915_query.c */ +int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file); + /* i915_suspend.c */ extern int i915_save_state(struct drm_i915_private *dev_priv); extern int i915_restore_state(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/i915_query.c b/drivers/gpu/drm/i915/i915_query.c new file mode 100644 index ..227a28978190 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_query.c @@ -0,0 +1,52 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ + +#include "i915_drv.h" +#include + +int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file) +{ + struct drm_i915_query *args = data; An alternative I think could be: struct drm_i915_query_item __user *user_item_ptr = u64_t
Re: [Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last I915_CONTEXT_PARAM+1 for invalid tests
> -Original Message- > From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com] > Sent: Thursday, January 11, 2018 1:46 PM > To: Lofstedt, Marta ; intel- > g...@lists.freedesktop.org > Cc: Chris Wilson > Subject: Re: [Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last > I915_CONTEXT_PARAM+1 for invalid tests > > > On 11/01/2018 11:38, Marta Lofstedt wrote: > > The invalid-param-[get|set] exploits the last I915_CONTEXT_PARAM + 1, > > to check for ABI extentsions. However, the last param was set to > > I915_CONTEXT_PARAM_BANNABLE, so when > I915_CONTEXT_PARAM_PRIORITY was > > added to the next enum, the test started failing. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103107 > > Signed-off-by: Marta Lofstedt > > --- > > tests/gem_ctx_param.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c index > > c20ae1ee..75d2a20f 100644 > > --- a/tests/gem_ctx_param.c > > +++ b/tests/gem_ctx_param.c > > @@ -140,7 +140,7 @@ igt_main > > * to catch ABI extensions. Don't "fix" this testcase without > adding all > > * the tests for the new param first. > > */ > > - arg.param = I915_CONTEXT_PARAM_BANNABLE + 1; > > + arg.param = I915_CONTEXT_PARAM_PRIORITY + 1; > > > > igt_subtest("invalid-param-get") { > > arg.ctx_id = ctx; > > > > We tried before, last time AFAIR > https://patchwork.freedesktop.org/patch/187073/, but again AFAIR I think > Chris objected and would rather remove negative tests in general. Shrug, an > impasse. :I > Well, then maybe V2 will be to remove these test ;) > Regards, > > Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last I915_CONTEXT_PARAM+1 for invalid tests
On 11/01/2018 11:38, Marta Lofstedt wrote: The invalid-param-[get|set] exploits the last I915_CONTEXT_PARAM + 1, to check for ABI extentsions. However, the last param was set to I915_CONTEXT_PARAM_BANNABLE, so when I915_CONTEXT_PARAM_PRIORITY was added to the next enum, the test started failing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103107 Signed-off-by: Marta Lofstedt --- tests/gem_ctx_param.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c index c20ae1ee..75d2a20f 100644 --- a/tests/gem_ctx_param.c +++ b/tests/gem_ctx_param.c @@ -140,7 +140,7 @@ igt_main * to catch ABI extensions. Don't "fix" this testcase without adding all * the tests for the new param first. */ - arg.param = I915_CONTEXT_PARAM_BANNABLE + 1; + arg.param = I915_CONTEXT_PARAM_PRIORITY + 1; igt_subtest("invalid-param-get") { arg.ctx_id = ctx; We tried before, last time AFAIR https://patchwork.freedesktop.org/patch/187073/, but again AFAIR I think Chris objected and would rather remove negative tests in general. Shrug, an impasse. :I Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] test/gem_ctx_param - Use the last I915_CONTEXT_PARAM+1 for invalid tests
The invalid-param-[get|set] exploits the last I915_CONTEXT_PARAM + 1, to check for ABI extentsions. However, the last param was set to I915_CONTEXT_PARAM_BANNABLE, so when I915_CONTEXT_PARAM_PRIORITY was added to the next enum, the test started failing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103107 Signed-off-by: Marta Lofstedt --- tests/gem_ctx_param.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c index c20ae1ee..75d2a20f 100644 --- a/tests/gem_ctx_param.c +++ b/tests/gem_ctx_param.c @@ -140,7 +140,7 @@ igt_main * to catch ABI extensions. Don't "fix" this testcase without adding all * the tests for the new param first. */ - arg.param = I915_CONTEXT_PARAM_BANNABLE + 1; + arg.param = I915_CONTEXT_PARAM_PRIORITY + 1; igt_subtest("invalid-param-get") { arg.ctx_id = ctx; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915/debugfs: add rcs topology entry
On 18/12/2017 15:35, Lionel Landwerlin wrote: While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0 (subslice_mask=0x7): I'd add a subslice count while at it, since the eu lines have counts. Bike-shedding on whether counts or masks are typically more important? Slice0: 3 slices (0x7): Subslice 0: 8 EUs (0xff) Subslice 1: 8 EUs (0xff) ... ? subslice0: eu_mask: 0xff (8) subslice1: eu_mask: 0xff (8) subslice2: eu_mask: 0xff (8) subslice3: eu_mask: 0x0 (0) slice1 (subslice_mask=0x7): subslice0: eu_mask: 0xff (8) subslice1: eu_mask: 0xff (8) subslice2: eu_mask: 0xff (8) subslice3: eu_mask: 0x0 (0) slice2 (subslice_mask=0x7): subslice0: eu_mask: 0xff (8) subslice1: eu_mask: 0xff (8) subslice2: eu_mask: 0xff (8) subslice3: eu_mask: 0x0 (0) Suggested-by: Chris Wilson Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 37 + 1 file changed, 37 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 6ec7543e698f..79ca6e9f9ec9 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3173,6 +3173,42 @@ static int i915_engine_info(struct seq_file *m, void *unused) return 0; } +static int i915_rcs_topology(struct seq_file *m, void *unused) +{ + struct drm_i915_private *dev_priv = node_to_i915(m->private); + const struct sseu_dev_info *sseu = &INTEL_INFO(dev_priv)->sseu; + int s, ss; + int subslice_stride = ALIGN(sseu->max_eus_per_subslice, 8) / 8; + int slice_stride = sseu->max_subslices * subslice_stride; Another case for the before mentioned helper for indexing into eu_mask array? + + if (sseu->max_slices == 0) { + seq_printf(m, "Unavailable\n"); + return 0; + } Is this possible? + + for (s = 0; s < sseu->max_slices; s++) { + seq_printf(m, "slice%i (subslice_mask=0x%x):\n", %i always confuses me. Googling shows it is equivalent to %d for printing? Or is it something different in kernel space? If it is equivalent I would go with a more standard one. And I would even change to unsigned variables for iterators but I realize some people have a different opinion so up to you. + s, sseu->subslices_mask[s]); + + for (ss = 0; ss < slice_stride / subslice_stride; ss++) { With the indexing helpers hopefully it would be possible to simply iterate to hweight8(sseu->sublice_mask[s]) ? + int eu, n_subslice_eus = 0; + + seq_printf(m, "\tsubslice%i:\n", ss); + + seq_printf(m, "\t\teu_mask:"); + for (eu = 0; eu < subslice_stride; eu++) { + u8 val = sseu->eu_mask[s * slice_stride + + ss * subslice_stride + eu]; + seq_printf(m, " 0x%x", val); + n_subslice_eus += hweight8(val); + } + seq_printf(m, " (%i)\n", n_subslice_eus); + } + } + + return 0; +} + static int i915_shrinker_info(struct seq_file *m, void *unused) { struct drm_i915_private *i915 = node_to_i915(m->private); @@ -4658,6 +4694,7 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_dmc_info", i915_dmc_info, 0}, {"i915_display_info", i915_display_info, 0}, {"i915_engine_info", i915_engine_info, 0}, + {"i915_rcs_topology", i915_rcs_topology, 0}, {"i915_shrinker_info", i915_shrinker_info, 0}, {"i915_shared_dplls_info", i915_shared_dplls_info, 0}, {"i915_dp_mst_info", i915_dp_mst_info, 0}, Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu
On 18/12/2017 15:35, Lionel Landwerlin wrote: Now that we have that information in topology fields, let's just reused it. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 0c7890b695c5..6ec7543e698f 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4308,11 +4308,11 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { const struct intel_device_info *info = INTEL_INFO(dev_priv); - int s_max = 6, ss_max = 4; int s, ss; - u32 s_reg[s_max], eu_reg[2 * s_max], eu_mask[2]; + u32 s_reg[info->sseu.max_slices], + eu_reg[2 * info->sseu.max_subslices], eu_mask[2]; This is a bit unusual style, perhaps split into separate declarations. - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { /* * FIXME: Valid SS Mask respects the spec and read * only valid bits for those registers, excluding reserverd @@ -4334,7 +4334,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4342,7 +4342,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); sseu->subslices_mask[s] = info->sseu.subslices_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss @@ -4362,17 +4362,11 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, struct sseu_dev_info *sseu) { - int s_max = 3, ss_max = 4; + const struct intel_device_info *info = INTEL_INFO(dev_priv); int s, ss; - u32 s_reg[s_max], eu_reg[2*s_max], eu_mask[2]; - - /* BXT has a single slice and at most 3 subslices. */ - if (IS_GEN9_LP(dev_priv)) { - s_max = 1; - ss_max = 3; - } + u32 s_reg[info->sseu.max_slices], eu_reg[2*info->sseu.max_subslices], eu_mask[2]; Spaces around operators are preferred. - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { s_reg[s] = I915_READ(GEN9_SLICE_PGCTL_ACK(s)); eu_reg[2*s] = I915_READ(GEN9_SS01_EU_PGCTL_ACK(s)); eu_reg[2*s + 1] = I915_READ(GEN9_SS23_EU_PGCTL_ACK(s)); @@ -4387,7 +4381,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, GEN9_PGCTL_SSB_EU210_ACK | GEN9_PGCTL_SSB_EU311_ACK; - for (s = 0; s < s_max; s++) { + for (s = 0; s < info->sseu.max_slices; s++) { if ((s_reg[s] & GEN9_PGCTL_SLICE_ACK) == 0) /* skip disabled slice */ continue; @@ -4398,7 +4392,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->subslices_mask[s] = INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; - for (ss = 0; ss < ss_max; ss++) { + for (ss = 0; ss < info->sseu.max_subslices; ss++) { unsigned int eu_cnt; if (IS_GEN9_LP(dev_priv)) { With the formatting tweaks, Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: store all subslice masks
On 18/12/2017 15:35, Lionel Landwerlin wrote: Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymetric (for example slice0 asymmetric, thanks auto spell checker. :) has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all slices. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 24 +++-- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 23 - drivers/gpu/drm/i915/intel_device_info.c | 169 ++- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +- 6 files changed, 161 insertions(+), 61 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 0ddce72552bf..0c7890b695c5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4293,7 +4293,7 @@ static void cherryview_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask = BIT(0); - sseu->subslice_mask |= BIT(ss); + sseu->subslices_mask[0] |= BIT(ss); eu_cnt = ((sig1[ss] & CHV_EU08_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU19_PG_ENABLE) ? 0 : 2) + ((sig1[ss] & CHV_EU210_PG_ENABLE) ? 0 : 2) + @@ -4340,7 +4340,7 @@ static void gen10_sseu_device_status(struct drm_i915_private *dev_priv, continue; sseu->slice_mask |= BIT(s); - sseu->subslice_mask = info->sseu.subslice_mask; + sseu->subslices_mask[s] = info->sseu.subslices_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4395,8 +4395,8 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask |= BIT(s); if (IS_GEN9_BC(dev_priv)) - sseu->subslice_mask = - INTEL_INFO(dev_priv)->sseu.subslice_mask; + sseu->subslices_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; for (ss = 0; ss < ss_max; ss++) { unsigned int eu_cnt; @@ -4406,7 +4406,7 @@ static void gen9_sseu_device_status(struct drm_i915_private *dev_priv, /* skip disabled subslice */ continue; -sseu->subslice_mask |= BIT(ss); + sseu->subslices_mask[s] |= BIT(ss); } eu_cnt = 2 * hweight32(eu_reg[2*s + ss/2] & @@ -4428,9 +4428,12 @@ static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv, sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK; if (sseu->slice_mask) { - sseu->subslice_mask = INTEL_INFO(dev_priv)->sseu.subslice_mask; sseu->eu_per_subslice = INTEL_INFO(dev_priv)->sseu.eu_per_subslice; + for (s = 0; s < fls(sseu->slice_mask); s++) { + sseu->subslices_mask[s] = + INTEL_INFO(dev_priv)->sseu.subslices_mask[s]; + } sseu->eu_total = sseu->eu_per_subslice * sseu_subslice_total(sseu); @@ -4449,6 +4452,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, { struct drm_i915_private *dev_priv = node_to_i915(m->private); const char *type = is_available_info ? "Available" : "Enabled"; + int s; seq_printf(m, " %s Slice Mask: %04x\n", type, sseu->slice_mask); @@ -4456,10 +4460,10 @@ static void i915_print_sseu_info(struct seq_file *m, bool is_available_info, hweight8(sseu->slice_mask)); seq_printf(m, " %s Subslice Total: %u\n", type, sseu_subslice_total(sseu)); - seq_printf(m, " %s Subslice Mask: %04x\n", type, - sseu->subslice_mask); - seq_printf(m, " %s Subslice Per Slice: %u\n", type, - hweight8(sseu->subslice_mask)); + for (s = 0; s < fls(sseu->slice_mask); s++) { Slice mask is always contiguous bits? + seq_printf(m, " %s Slice%i Subslice Mask: %04x\n", type, + s, sseu->subslices_mask[s]); Don't want to keep printing the count? Like maybe " %s Slice%u %u sublices, mask=%04x\n" ? + } seq_printf(m, " %s EU Total: %u\n", type, sseu->eu_total); seq_printf(m, " %s EU Per Subslice: %u\n", type, diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 72bea281edb7..8b99e415c345 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/
Re: [Intel-gfx] [PATCH i-g-t] build: make meson more official
On Thu, Jan 11, 2018 at 9:58 AM, Petri Latvala wrote: > On Thu, Jan 11, 2018 at 09:51:40AM +0100, Daniel Vetter wrote: >> I also noticed that meson.sh doesn't set the prefix for patch >> submission. Fix that (even thought hopefully real soon igt will move >> to its own list). >> >> Cc: Petri Latvala >> Cc: Arkadiusz Hiler >> Signed-off-by: Daniel Vetter >> --- >> CONTRIBUTING | 2 +- >> NEWS | 6 ++ >> README | 17 - >> meson.sh | 2 ++ >> 4 files changed, 21 insertions(+), 6 deletions(-) >> >> diff --git a/CONTRIBUTING b/CONTRIBUTING >> index 561c5dd80bba..0d70346526d3 100644 >> --- a/CONTRIBUTING >> +++ b/CONTRIBUTING >> @@ -12,7 +12,7 @@ A short list of contribution guidelines: >> >>Please use --subject-prefix="PATCH i-g-t" so that i-g-t patches are easily >>identified in the massive amount mails on intel-gfx. To ensure this is >> always >> - done, autogen.sh will run: >> + done, meson.sh will run: > > > We still support both build systems, so mention both autogen.sh and > meson.sh here. > > >> >> git config format.subjectprefix "PATCH i-g-t" >> >> diff --git a/NEWS b/NEWS >> index b6d0958228ab..885c1baf3691 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -1,3 +1,9 @@ >> +Release 1.21 >> + >> + >> +- Upgrade meson to official production status, automake is still kept >> around for >> + now. >> + > > Building up the release notes as-we-go, wonderful. But I wonder if the > upcoming stuff should be placed elsewhere while 1.21 doesn't yet > exist, to avoid confusion. > > Maybe have the title of the section be: > > Release 1.21 (not yet released) In the past I think we've used (-XX-XX) for that. And yes I've always tried to build up the release notes as we go, and encouraging people to help out by creating the new title right after the release is tagged. See git log NEWS :-) Will fix the other two and push. -Daniel > > or so? > > >> Release 1.20 (2017-10-03) >> - >> >> diff --git a/README b/README >> index e0f829defb51..5b4a59e9ac24 100644 >> --- a/README >> +++ b/README >> @@ -167,11 +167,11 @@ The following dependencies are requires for building >> audio support >> libasound2-dev >> libgsl-dev >> >> -Experimental meson build system support >> >> +Meson build system support >> +-- >> >> -Right now this is just a preview for developers, automake is still used by >> CI >> -and needs to keep working. One-liner howto: >> +Currently we support both meson and automake as build systems, but meson is >> the >> +recommened choice. Oneliner to get started: > > > Typo: recommended > > > > Otherwise: > Reviewed-by: Petri Latvala -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Only enumerate available counters in sysfs (rev3)
On 11/01/2018 09:09, Patchwork wrote: == Series Details == Series: drm/i915/pmu: Only enumerate available counters in sysfs (rev3) URL : https://patchwork.freedesktop.org/series/35689/ State : success == Summary == Series 35689v3 drm/i915/pmu: Only enumerate available counters in sysfs https://patchwork.freedesktop.org/api/1.0/series/35689/revisions/3/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +1 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-kbl-r) fdo#104172 +1 Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:414s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:413s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:357s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:444s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:262s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:463s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:464s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:426s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:421s fi-cnl-y2total:288 pass:258 dwarn:3 dfail:0 fail:0 skip:27 time:556s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:247s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:493s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:379s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:388s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:395s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:445s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:408s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:459s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:490s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:492s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:481s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:415s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:517s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:478s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:465s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:419s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:386s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:554s fi-glk-dsi total:288 pass:189 dwarn:1 dfail:4 fail:0 skip:94 time:382s 7b72161536aa58d5d20f7d1e15d24884374f5d10 drm-tip: 2018y-01m-10d-19h-08m-42s UTC integration manifest 0d4c6f0e843e drm/i915/pmu: Only enumerate available counters in sysfs Pushed, thanks for the review! Regards, Tvrtko ___ 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: Apply headless DMC workaround for CNL
On 11/01/2018 08:45, Patchwork wrote: == Series Details == Series: drm/i915: Apply headless DMC workaround for CNL URL : https://patchwork.freedesktop.org/series/36317/ State : success == Summary == Series 36317v1 drm/i915: Apply headless DMC workaround for CNL https://patchwork.freedesktop.org/api/1.0/series/36317/revisions/1/mbox/ Test kms_frontbuffer_tracking: Subgroup basic: skip -> INCOMPLETE (fi-elk-e7500) fdo#103989 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-kbl-r) fdo#104172 +1 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:418s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:488s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:485s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:487s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:469s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:458s fi-cnl-y2total:288 pass:258 dwarn:3 dfail:0 fail:0 skip:27 time:541s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:272s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:513s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:390s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:451s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:412s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:465s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:497s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:260 dwarn:1 dfail:0 fail:0 skip:27 time:512s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:428s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:528s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:482s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:523s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:400s Blacklisted hosts: fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-glk-dsi total:288 pass:152 dwarn:1 dfail:4 fail:0 skip:131 time:276s fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7647/fi-bdw-gvtdvm/igt.log 7b72161536aa58d5d20f7d1e15d24884374f5d10 drm-tip: 2018y-01m-10d-19h-08m-42s UTC integration manifest bece3c28fe29 drm/i915: Apply headless DMC workaround for CNL Pushed, thanks for the review! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set (rev2)
On Thu, Jan 11, 2018 at 09:54:02AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set > (rev2) > URL : https://patchwork.freedesktop.org/series/35338/ > State : failure > > == Summary == > > Warning: bzip CI_DRM_3609/shard-glkb6/results32.json.bz2 wasn't in correct > JSON format > Test kms_cursor_crc: > Subgroup cursor-64x21-onscreen: > skip -> PASS (shard-hsw) > Subgroup cursor-64x64-suspend: > skip -> PASS (shard-snb) fdo#102365 > skip -> PASS (shard-hsw) fdo#103540 > Test drv_suspend: > Subgroup debugfs-reader: > pass -> SKIP (shard-snb) > Test kms_frontbuffer_tracking: > Subgroup fbc-1p-offscren-pri-shrfb-draw-render: > fail -> PASS (shard-snb) fdo#101623 > Test kms_flip: > Subgroup vblank-vs-modeset-suspend: > pass -> INCOMPLETE (shard-hsw) > > fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 > fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 > fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > shard-hswtotal:2681 pass:1521 dwarn:1 dfail:0 fail:10 skip:1148 > time:8681s > shard-snbtotal:2713 pass:1310 dwarn:1 dfail:0 fail:10 skip:1392 > time:7926s > Blacklisted hosts: > shard-apltotal:2713 pass:1684 dwarn:1 dfail:0 fail:25 skip:1002 > time:13555s > shard-kbltotal:2713 pass:1808 dwarn:1 dfail:0 fail:24 skip:880 > time:10569s > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7628/shards.html kbl results now shown in the text diff but this page shows: igt@kms_hdmi_inject@inject-4k fail -> PASS -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: Add NV12 as supported format for sprite plane
> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Tuesday, January 9, 2018 3:32 PM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: Add NV12 as supported > format for sprite plane > > Op 09-01-18 om 03:19 schreef Srinivas, Vidya: > > > >> -Original Message- > >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > >> Sent: Monday, January 8, 2018 6:04 PM > >> To: Srinivas, Vidya ; intel- > >> g...@lists.freedesktop.org > >> Subject: Re: [Intel-gfx] [PATCH 14/15] drm/i915: Add NV12 as > >> supported format for sprite plane > >> > >> Op 07-01-18 om 10:59 schreef Vidya Srinivas: > >>> From: Chandra Konduru > >>> > >>> This patch adds NV12 to list of supported formats for sprite plane. > >>> > >>> v2: Rebased (me) > >>> > >>> v3: Review comments by Ville addressed > >>> - Removed skl_plane_formats_with_nv12 and added > >>> NV12 case in existing skl_plane_formats > >>> - Added the 10bpc RGB formats > >>> > >>> v4: Addressed review comments from Clinton A Taylor "Why are we > >> adding > >>> 10 bit RGB formats with the NV12 series patches? > >>> Trying to set XR30 or AB30 results in error returned even though the > >>> modes are advertised for the planes" > >>> - Removed 10bit RGB formats added previously with NV12 series > >>> > >>> v5: Missed the Tested-by/Reviewed-by in the previous series Adding > >>> the same to commit message in this version. > >>> Addressed review comments from Clinton A Taylor "Why are we adding > >>> 10 bit RGB formats with the NV12 series patches? > >>> Trying to set XR30 or AB30 results in error returned even though the > >>> modes are advertised for the planes" > >>> - Previous version has 10bit RGB format removed from VLV formats by > >>> mistake. Fixing that in this version. > >>> Removed 10bit RGB formats added previously with NV12 series for SKL. > >>> > >>> v6: Addressed review comments by Ville Restricting the NV12 to BXT > >>> and PIPE A and B > >>> > >>> v7: Rebased (me) > >>> > >>> v8: Rebased (me) > >>> Restricting NV12 changes to BXT and KBL Restricting NV12 changes for > >>> plane 0 (overlay) > >>> > >>> v9: Rebased (me) > >>> > >>> Tested-by: Clinton Taylor > >>> Reviewed-by: Clinton Taylor > >>> Signed-off-by: Chandra Konduru > >>> Signed-off-by: Nabendu Maiti > >>> Signed-off-by: Vidya Srinivas > >>> --- > >>> drivers/gpu/drm/i915/intel_sprite.c | 24 +--- > >>> 1 file changed, 21 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c > >>> b/drivers/gpu/drm/i915/intel_sprite.c > >>> index 09732ae..1d35a18 100644 > >>> --- a/drivers/gpu/drm/i915/intel_sprite.c > >>> +++ b/drivers/gpu/drm/i915/intel_sprite.c > >>> @@ -1279,6 +1279,19 @@ static const struct drm_plane_funcs > >> intel_sprite_plane_funcs = { > >>> .format_mod_supported = > >>> intel_sprite_plane_format_mod_supported, > >>> }; > >>> > >>> +static uint32_t nv12_plane_formats[] = { > >>> + DRM_FORMAT_RGB565, > >>> + DRM_FORMAT_ABGR, > >>> + DRM_FORMAT_ARGB, > >>> + DRM_FORMAT_XBGR, > >>> + DRM_FORMAT_XRGB, > >>> + DRM_FORMAT_YUYV, > >>> + DRM_FORMAT_YVYU, > >>> + DRM_FORMAT_UYVY, > >>> + DRM_FORMAT_VYUY, > >>> + DRM_FORMAT_NV12, > >>> +}; > >>> + > >>> struct intel_plane * > >>> intel_sprite_plane_create(struct drm_i915_private *dev_priv, > >>> enum pipe pipe, int plane) > >>> @@ -1323,9 +1336,14 @@ intel_sprite_plane_create(struct > >> drm_i915_private *dev_priv, > >>> intel_plane->update_plane = skl_update_plane; > >>> intel_plane->disable_plane = skl_disable_plane; > >>> intel_plane->get_hw_state = skl_plane_get_hw_state; > >>> - > >>> - plane_formats = skl_plane_formats; > >>> - num_plane_formats = ARRAY_SIZE(skl_plane_formats); > >>> + if ((IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)) && > >>> + (pipe == PIPE_A || pipe == PIPE_B) && plane == 0) { > >>> + plane_formats = nv12_plane_formats; > >>> + num_plane_formats = > >> ARRAY_SIZE(nv12_plane_formats); > >>> + } else { > >>> + plane_formats = skl_plane_formats; > >>> + num_plane_formats = > >> ARRAY_SIZE(skl_plane_formats); > >>> + } > >> I understand we don't have enough scalers, but is there something > >> wrong with allowing nv12 on any plane? > >> > > On BXT (Gen9), NV12 is supported only on primary and sprite 0. > Ah ok, nm that comment then. :) > > Same comment applies as for the other patch that adds it to the primary > plane, would be better to have a single array and tinker with > num_plane_formats, should gen10 also have NV12 support here btw? > > I can't r-b the series right now, there are no tests. Judging from the > comments this is what the kms_plane_scaling is about, so I started looking > at it. > Thank you. I could add support for Ge
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set (rev2)
== Series Details == Series: drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set (rev2) URL : https://patchwork.freedesktop.org/series/35338/ State : failure == Summary == Warning: bzip CI_DRM_3609/shard-glkb6/results32.json.bz2 wasn't in correct JSON format Test kms_cursor_crc: Subgroup cursor-64x21-onscreen: skip -> PASS (shard-hsw) Subgroup cursor-64x64-suspend: skip -> PASS (shard-snb) fdo#102365 skip -> PASS (shard-hsw) fdo#103540 Test drv_suspend: Subgroup debugfs-reader: pass -> SKIP (shard-snb) Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render: fail -> PASS (shard-snb) fdo#101623 Test kms_flip: Subgroup vblank-vs-modeset-suspend: pass -> INCOMPLETE (shard-hsw) fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 shard-hswtotal:2681 pass:1521 dwarn:1 dfail:0 fail:10 skip:1148 time:8681s shard-snbtotal:2713 pass:1310 dwarn:1 dfail:0 fail:10 skip:1392 time:7926s Blacklisted hosts: shard-apltotal:2713 pass:1684 dwarn:1 dfail:0 fail:25 skip:1002 time:13555s shard-kbltotal:2713 pass:1808 dwarn:1 dfail:0 fail:24 skip:880 time:10569s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7628/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/scheduler: Assert that we do not have a dep cycle back to request
On Fri, Jan 05, 2018 at 02:13:22PM +, Chris Wilson wrote: > When reprioritising a request, we build a list of its dependencies in > topological order. This should leave our origin request as the first > element in our list, if it moves we have a dependency cycle and severe > breakage. Assert that it doesn't move. > > Complete, but expensive checking is done by swfence, this assert is more > about documenting the topologically ordered list. > > Signed-off-by: Chris Wilson > Cc: Michał Winiarski Reviewed-by: Michał Winiarski -Michał > --- > drivers/gpu/drm/i915/intel_lrc.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 4e150b095a11..42705e3875cd 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -1050,6 +1050,13 @@ static void execlists_schedule(struct > drm_i915_gem_request *request, int prio) > } > } > > + /* > + * We should never have a dep cycle back to ourselves, leaving > + * the original request as the origin of our topologically sorted > + * list. > + */ > + GEM_BUG_ON(list_first_entry(&dfs, typeof(stack), dfs_link) != &stack); > + > /* >* If we didn't need to bump any existing priorities, and we haven't >* yet submitted this request (i.e. there is no potential race with > -- > 2.15.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Redefine guc_log_level modparam values
On 1/11/2018 2:54 PM, Michal Wajdeczko wrote: On Thu, 11 Jan 2018 06:52:18 +0100, Sagar Arun Kamble wrote: On 1/10/2018 9:35 PM, Michal Wajdeczko wrote: We used value -1 to indicate "disabled" and values 0..3 to indicate "enabled", but most of our other modparams are using -1 for "auto" mode and 0 for "disable". For consistency let's change our log level values to: -1: auto (depends on USES_GUC and DRM_I915_DEBUG) "depends on HAS_GUC, USES_GUC, DRM_I915_DEBUG and DRM_I915_DEBUG_GEM" I should write "(depends on platform and Kconfig.debug settings)" as actual condition may change in the near feature. Yes s/intel_uc_is_using_guc()/USES_GUC seeing some more intel_uc_is_using_* instead of macro usage USES_* It was by design, as in intel_uc_sanitize_options() function we are using only HAS_xxx macros and instead of USES_xxx we call intel_uc_is_xxx helpers directly. Got it 0: disabled 1: enabled (severity level 0 = min) 2: enabled (severity level 1) 3: enabled (severity level 2) 4: enabled (severity level 3 = max) Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_params.c | 3 ++- drivers/gpu/drm/i915/intel_guc.c | 21 ++- drivers/gpu/drm/i915/intel_guc_log.c | 47 - drivers/gpu/drm/i915/intel_uc.c | 51 ++-- 4 files changed, 87 insertions(+), 35 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b5f3eb4..0b553a8 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -155,7 +155,8 @@ struct i915_params i915_modparams __read_mostly = { "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)"); i915_param_named(guc_log_level, int, 0400, - "GuC firmware logging level (-1:disabled (default), 0-3:enabled)"); + "GuC firmware logging level. Requires GuC to be loaded. " + "(-1=auto [default], 0=disable, 1..4=enable with verbosity min..max)"); i915_param_named_unsafe(guc_firmware_path, charp, 0400, "GuC firmware path to use instead of the default one"); diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 50b4725..2227236 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -215,6 +215,18 @@ static u32 get_core_family(struct drm_i915_private *dev_priv) } } +static u32 get_log_verbosity_flags(void) +{ making this inline would be good i guess. No need to do so. Compiler will take care of it as needed (as this function is already marked as static) + if (i915_modparams.guc_log_level > 0) { + u32 verbosity = i915_modparams.guc_log_level - 1; + + GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX); + return verbosity << GUC_LOG_VERBOSITY_SHIFT; + } + GEM_BUG_ON(i915_modparams.enable_guc < 0); + return GUC_LOG_DISABLED; +} + /* * Initialise the GuC parameter block before starting the firmware * transfer. These parameters are read by the firmware on startup @@ -247,12 +259,7 @@ void intel_guc_init_params(struct intel_guc *guc) params[GUC_CTL_LOG_PARAMS] = guc->log.flags; - if (i915_modparams.guc_log_level >= 0) { - params[GUC_CTL_DEBUG] = - i915_modparams.guc_log_level << GUC_LOG_VERBOSITY_SHIFT; - } else { - params[GUC_CTL_DEBUG] = GUC_LOG_DISABLED; - } + params[GUC_CTL_DEBUG] = get_log_verbosity_flags(); /* If GuC submission is enabled, set up additional parameters here */ if (USES_GUC_SUBMISSION(dev_priv)) { @@ -445,7 +452,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv) if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) return 0; - if (i915_modparams.guc_log_level >= 0) + if (i915_modparams.guc_log_level > 0) if (i915_modparams.guc_log_level) gen9_enable_guc_interrupts(dev_priv); data[0] = INTEL_GUC_ACTION_EXIT_S_STATE; diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index eaedd63..e6d59bf 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -582,7 +578,7 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val) return -EINVAL; /* This combination doesn't make sense & won't have any effect */ - if (!log_param.logging_enabled && (i915_modparams.guc_log_level < 0)) + if (!log_param.logging_enabled && !i915_modparams.guc_log_level) return 0; ret = guc_log_control(guc, log_param.value); @@ -592,11 +588,12 @@ int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val) } if (log_param.logging_enabled) { - i915_modparams.guc_log_level = log_param.verbosity; + i915_modparams.guc_log_level = 1 + log_param.verbosity; readi
Re: [Intel-gfx] [PATCH i-g-t 1/1] tools: Update .gitignore
On Thu, 2018-01-11 at 11:27 +0200, Petri Latvala wrote: > Fixes: 834321a5d76a ("tools: Cannonlake port clock programming") Reviewed-by: Mika Kahola > Signed-off-by: Petri Latvala > Cc: Mika Kahola > --- > tools/.gitignore | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/.gitignore b/tools/.gitignore > index 2e16cb26..2de665a3 100644 > --- a/tools/.gitignore > +++ b/tools/.gitignore > @@ -1,4 +1,5 @@ > # Please keep sorted alphabetically > +cnl_compute_wrpll > hsw_compute_wrpll > igt_stats > intel_aubdump -- Mika Kahola - Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx