- 29 Mar, 2019 1 commit
-
-
Daniele Ceraolo Spurio authored
edram is not part of uncore and there is no requirement for the detection to be done before we initialize the uncore functions. The first check on HAS_EDRAM is in the ggtt_init path, so move it to i915_driver_init_hw, where other dram-related detection happens. While at it, save the size in MB instead of the capabilities because the size is the only thing we look at outside of the init function. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 28 Mar, 2019 13 commits
-
-
Ville Syrjälä authored
Don't load the linear degamma LUT on ICL. The hardware no longer has any silly linkages between the CSC enable and degamma LUT enable so the degamma LUT is only needed when it's actually enabled. Also add comments to explain the situation on GLK. v2: Drop useless parens around 1<<16 v3: Add missing const Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190327155045.28446-11-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
We now bypass the legacy LUT when it's not needed, so no point in filling it up with a linear LUT. Signed-off-by:
-
Ville Syrjälä authored
With everything else moved out of the way only ilk+ remains using _intel_color_check(). Streamline the logic into ilk_color_check(). v2: Add some comments explaining we that we don't expose the full hardware capabilities currently (Matt) Signed-off-by: -
Ville Syrjälä authored
Provide a separate .color_check() for BDW+ where we currently provide the split gamma mode etc. Signed-off-by:
-
Ville Syrjälä authored
Unlike the earlier platforms GLK has dedicated degamma and gamma LUTs. And quite curiously the degamma LUT is actually controlled via the PLANE_COLOR_CTL CSC enable bit. Hence we must compute gamma_enable and csc_enable differently to pre-GLK platforms. Signed-off-by:
-
Ville Syrjälä authored
ICL is rather easy when it comes to .color_check() as it finally provides us with a full color pipeline with individual knobs for each stage. We'll also start bypassing each LUT individually when it is not needed. Signed-off-by:
-
Ville Syrjälä authored
Since CHV has the CGM unit we require a custom implementation of .color_check(). This fixes the computation of gamma_enable as previously we left it enabled even when were using the CGM gamma instead. Now we turn off the legacy LUT unless it's actually required. v2: Add some comment explaining the color pipeline (Matt) Signed-off-by:
-
Ville Syrjälä authored
Apart from CHV the other gmch platforms don't currently require much work in .color_check(). So let's start by extracting i9xx_color_check(). Signed-off-by:
-
Ville Syrjälä authored
The current intel_color_check() is a mess, and worse yet it is in fact incorrect for several platforms. The hardware has evolved quite a bit over the years, so let's just go for a clean split between the platforms by turning this into a vfunc. The actual work to split it up will follow. v2: Assign the vfuncs in the order they appear in the struct (Matt) Signed-off-by: -
Ville Syrjälä authored
In prepartion for per-platform color_check() functions extract the common code into a separate function. v2: Improve the C8 comment (Matt) Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Joonas Lahtinen authored
Signed-off-by: -
Joonas Lahtinen authored
Signed-off-by:
-
- 27 Mar, 2019 13 commits
-
-
Maarten Lankhorst authored
90/270 rotation is not supported for Y21x and the 12/16 bits XVYU formats, reject support for them. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322135954.20434-3-maarten.lankhorst@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
This was missing in the original addition of those formats, but in PLANE_SIZE description it's mentioned that 8 cpp formats are not valid with Yf tiling. Reject this case properly. Also reject Y21x Yf tiling support this is also not supported. Changes since v1: - Reject Y21x as well. Signed-off-by:
-
Maarten Lankhorst authored
Y41x formats is a 4:4:4 format, so it can be addressed with pixel level accuracy. Meanwhile it seems that while rotating YUYV 4:2:2 formats need a multiple of 2 for width and height, otherwise corruption occurs. For YUV 4:2:2, the spec says that w/h should always be even, but we get away with odd height while unrotated. When rotating it seems corruption occurs with an odd x/y, and w/h should always be even. Just to be completely paranoid, reject odd x/y w/h when rotating 90/270. Signed-off-by:
-
Joonas Lahtinen authored
This is needed to get the fourcc code merged without conflicts. Signed-off-by: -
Chris Wilson authored
The intent was to expose these as part of the means to perform full context recovery (though not the SINGLE_TIMELINE, that is for later and just sucked as collateral damage). As that requires a couple more patches to complete the series, roll back the earlier chunks of ABI for an intervening PR. We keep all the internals intact and under selftests. Signed-off-by:
-
Zhenyu Wang authored
This is to disable semaphore usage when on vGPU for now. Unfortunately GVT-g hasn't fully enabled semaphore usage yet, so current guest with semaphore use would cause vGPU failure. Although current semaphore failure with vGPU can be simply resolved by allowing cmd parser to accept MI_SEMAPHORE_WAIT command with address audit, we're checking general usage of semaphore and how we should handle it properly for virtualization in consider of function and security concern. So we decide to request to disable it for now in guest driver. Once GVT could support it, we would add new compat bit to turn it on. Fixes: e8861964 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+") #vgpu Cc: Kevin Tian <kevin.tian@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by:
-
Ville Syrjälä authored
Update the DP MSA MISC bits for fastsets. This is needed when we change between limited and full range RGB output. On HSW+ changing limited_range does not currently result in a full modeset since we have don't have the readout code for it (for DP we could, and probably should, readout from TRANS_MSA_MISC itself, for HDMI we would have to rely on the infoframe). So the PIPE_CONF_CHECK() is only performed for pre-HSW platforms. That means any change in the value will result in a fastset instead. Fortunately there is no prohibition to changing TRANS_MSA_MISC dynamically, so it looks like we can legally do fastsets for this. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326142556.21176-5-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Allow the user to limit the output bpc with DP MST. Signed-off-by:
-
Ville Syrjälä authored
Allow DP MST to output any color depth. This means deep color as well as falling back to 6bpc if we would otherwise require too much bandwidth. TODO: We should probably extend bw_contstrained scheme to force all streams on the link to 6bpc if we can't fit the new stream(s) otherwise. v2: Use a proper for-loop (Jani) Signed-off-by:
-
Ville Syrjälä authored
We already expose the force_audio property with SST. Do the same with MST. Signed-off-by:
-
Ville Syrjälä authored
Add the "Broadcast RGB" property to MST connectors, and implement the same logic for it as we have in the SST code. v2: Extract and reuse intel_dp_limited_color_range() Cc: Ivan Vlk <ari@adyline.sk> Tested-by:
Ivan Vlk <ari@adyline.sk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108821Signed-off-by:
-
José Roberto de Souza authored
GT VEBOX DISABLE is only 4 bits wide but it was using a 8 bits wide mask, the remaning reserved bits is set to 0 causing 4 more nonexistent VEBOX engines being detected as enabled, triggering the BUG_ON() because of mismatch between vebox_mask and newly added VEBOX_MASK(). [ 64.081621] [drm:intel_device_info_init_mmio [i915]] vdbox enable: 0005, instances: 0005 [ 64.081763] [drm:intel_device_info_init_mmio [i915]] vebox enable: 00f1, instances: 0001 [ 64.081825] intel_device_info_init_mmio:925 GEM_BUG_ON(vebox_mask != ({ unsigned int first__ = (VECS0); unsigned int count__ = (2); ((&(dev_priv)->__info)->engine_mask & (((~0UL) - (1UL << (first__)) + 1) & (~0UL >> (64 - 1 - (first__ + count__ - 1))))) >> first__; })) [ 64.082047] ------------[ cut here ]------------ [ 64.082054] kernel BUG at drivers/gpu/drm/i915/intel_device_info.c:925! BSpec: 20680 Fixes: 9511cb64 ("drm/i915: Adding missing '; ' to ENGINE_INSTANCES") Fixes: 26376a7e ("drm/i915/icl: Check for fused-off VDBOX and VEBOX instances") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
When building with ARCH=i386, readq and writeq are not defined, resulting in: intel_uncore.h: In function ‘__raw_uncore_read64’: intel_uncore.h:257:9: error: implicit declaration of function ‘readq’; did you mean ‘readl’? [-Werror=implicit-function-declaration] return read##s__(uncore->regs + i915_mmio_reg_offset(reg)); \ ^ and: intel_uncore.h: In function ‘__raw_uncore_write64’: intel_uncore.h:264:2: error: implicit declaration of function ‘writeq’; did you mean ‘writel’? [-Werror=implicit-function-declaration] write##s__(val, uncore->regs + i915_mmio_reg_offset(reg)); \ ^ Add the io-64-nonatomic-lo-hi include to have readq and writeq available for all builds. This header internally includes linux/io.h, so the native readq and writeq definitions will be used when available. Fixes: 6cc5ca76 ("drm/i915: rename raw reg access functions") Signed-off-by:
-
- 26 Mar, 2019 13 commits
-
-
Chris Wilson authored
Tvrtko spotted that I left off the trailing ';'. It went unnoticed by CI because despite adding the macro, we didn't add a user, so include one as well (a simple debug print). Reported-by:
-
Michał Winiarski authored
Since GEM_CREATE is trying to outsmart the user by rounding up unaligned objects, we used to update the size returned to userspace. This update seems to have been lost throughout the history. v2: Use round_up(), reorder locals (Chris) References: ff72145b ("drm: dumb scanout create/mmap for intel/radeon (v3)") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Janusz Krzysztofik <janusz.krzysztofik@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
A few advantages: - Prepares us for the planned split of display uncore from GT uncore - Improves our engine-centric view of the world in the engine code and allows us to avoid jumping back to dev_priv. - Allows us to wrap accesses to engine register in nice macros that automatically pick the right mmio base. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of FW, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The full read/write ops can now work on the intel_uncore struct. Introduce intel_uncore_read/write functions working on intel_uncore and switch the I915_READ/WRITE macro to internally call those. v2: no change v3: add intel_uncore_read/write functions (Chris), update commit msg Signed-off-by:
-
Daniele Ceraolo Spurio authored
Remove a bit of pointer dancing in the reg access path. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Save the HW capabilities to avoid having to jump back to dev_priv every time. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
We have several cases where we don't have forcewake (older gens, GVT and planned display-only uncore), so, instead of checking every time against the various condition, save the info in a flag and use that. Note that this patch also change the behavior for gen5 with vpgu enabled, but this is not an issue since we don't support vgpu on gen5. v2: split out from previous path, fix check for missing case (Paulo) v3: Inline helper for clarity in testing flags Signed-off-by:
-
Daniele Ceraolo Spurio authored
They now work on uncore, so use raw_uncore_ prefix. Also move them to uncore.h Signed-off-by:
-
Lucas De Marchi authored
Now that pll_id is not used anymore for combophy, reduce its scope. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322223751.22089-6-lucas.demarchi@intel.comReviewed-by:
-
Lucas De Marchi authored
By the time icl_ddi_clock_get() is called we've just got the hw state from the pll registers. We don't need to read them again: we can rather reuse what was cached in the dpll_hw_state. While at it, s/refclk/ref_clock/ just to be consistent with the name used in code nearby. Signed-off-by:
-
