- 27 Mar, 2019 3 commits
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20190326142556.21176-1-ville.syrjala@linux.intel.com
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190326230223.26336-1-jose.souza@intel.com
-
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:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
- 26 Mar, 2019 17 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:
-
Lucas De Marchi authored
By the time cnl_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. This also affects the code for ICL since it partially reuses the CNL code. However the more intricate part on ICL is left for another patch. Signed-off-by:
-
Lucas De Marchi authored
Rename state to pll_state and use it as the argument to bxt_calc_pll_link(), similar to how it's done in the skl variant. The WARN_ON(!crtc_state->shared_dpll) is not very useful, so remove it as well. Signed-off-by:
-
Lucas De Marchi authored
By the time skl_ddi_clock_get() is called - and thus skl_calc_wrpll_link() - 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. v2: rename state variable to pll_state, make argument const in skl_calc_wrpll_link() and remove not useful warning (from Ville) Signed-off-by: -
Dan Carpenter authored
The live_context() function returns error pointers. It never returns NULL. Fixes: 9c1477e8 ("drm/i915/selftests: Exercise adding requests to a full GGTT") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
- 25 Mar, 2019 6 commits
-
-
Daniele Ceraolo Spurio authored
We're already updating the engine_mask to reflect what's in the HW, so we can just get the info from there. A couple of macros have been added to facilitate this. v2: Appease checkpatch Suggested-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Jani Nikula authored
Iterate over child devices instead of ports in parse_ddi_ports() to initialize ddi_port_info. We'll eventually need to decide some stuff based on the child device order, which may be different from the port order. As a bonus, this allows better abstractions for e.g. dvo port mapping. There's a subtle change in the DDC pin and AUX channel sanitization as we change the order. Otherwise, this should not change behaviour. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322121008.4456-1-jani.nikula@intel.com
-
Chris Wilson authored
Fixup the errno as we adjusted the error path to receive the errno and not compute it itself from ERR_PTR(ctx) anymore. drivers/gpu/drm/i915/i915_gem_context.c:793 i915_gem_context_open() warn: passing a valid pointer to 'PTR_ERR' Reported-by:
-
Ville Syrjälä authored
The vblank timestamp->counter guesstimator seems to be working sufficiently well, so there's no reason not to disable vblank interrupts ASAP even on gen2. Signed-off-by:
-
Ville Syrjälä authored
The AGPBUSY thing doesn't work on i945gm anymore. This means the gmch is incapable of waking the CPU from C3 when an interrupt is generated. The interrupts just get postponed indefinitely until something wakes up the CPU. This is rather annoying for vblank interrupts as we are unable to maintain a steady framerate unless the machine is sufficiently loaded to stay out of C3. To combat this let's use pm_qos to prevent C3 whenever vblank interrupts are enabled. To maintain reasonable amount of powersaving we will attempt to limit this to C3 only while leaving C1 and C2 enabled. v2: Use READ_ONCE() (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30364Signed-off-by:
-
Ville Syrjälä authored
If I'm reading the spec right AML 0x87CA is a Y SKU, so it should be marked as ULX in our old style terminology. Cc: stable@vger.kernel.org Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: c0c46ca4 ("drm/i915/aml: Add new Amber Lake PCI ID") Signed-off-by:
-
- 24 Mar, 2019 3 commits
-
-
Chris Wilson authored
Since commit b7137e0c ("drm/i915: Defer enabling rc6 til after we submit the first batch/context"), intel_suspend_gt_powersave() has been a no-op. As we still do not need to do anything explicitly on suspend (we do everything required on idling), remove the defunct function. References: b7137e0c ("drm/i915: Defer enabling rc6 til after we submit the first batch/context") Suggested-by:
"Hiatt, Don" <don.hiatt@intel.com> Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190323214009.23294-1-chris@chris-wilson.co.uk
-
Michal Wajdeczko authored
GuC may send notification messages with payload larger than single u32. Prepare driver to accept longer messages. Signed-off-by:
-
Zhenyu Wang authored
Initially found issue with closed context debug check when pin hw_id for GVT context, looks we should always pin hw_id for that as GVT context is fixed for each vGPU life cycle, and we'd also like to get pinned hw_id e.g for perf reason, etc. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by:
-
- 22 Mar, 2019 11 commits
-
-
Anusha Srivatsa authored
EHL uses the same firmware as ICL. Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by:
-
Bob Paauwe authored
EHL has a different number of subslices. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Bob Paauwe authored
Configure the correct set of outputs for EHL. EHL has three DDI's plus DSI. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Elkhart Lake has a different set of PLLs as compared to Ice Lake, although programming them is very similar. v2: Rebase on top of s/icl_pll_funcs/combo_pll_funcs Signed-off-by:
-
Bob Paauwe authored
Add ElkhartLake as a unique platform as there are some differences between it and Icelake. Signed-off-by:
-
James Ausmus authored
Add known EHL PCI IDs. v2 (Rodrigo): Removed x86 early quirk. To be sent in a separated patch cc'ing the appropriated list and maintainers for proper ack. v3: (Rodrigo): - Removed .num_pipes = 3 that is coming since GEN&_FEATURES. - Added ppgtt type and size after rework from Bob and Chris v4: (Rodrigo): - remove ppgtt type added on v3. Jose pointed it is not needed. Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:James Ausmus <james.ausmus@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Rename intel_find_panel_downclock() to intel_panel_edid_downclock_mode() to make it clear it's looking for the downclock mode in the EDID. And while at it polish the implementation a bit as well. Signed-off-by:
-
Ville Syrjälä authored
Utilize drm_mode_match() instead of hand rolling it when looking for the DRRS downclock mode. Signed-off-by:
-
Ville Syrjälä authored
DSI has its own convoluted way of grabbing the fixed mode from the VBT. Change it to follow the path laid out by LVDS/eDP. Signed-off-by:
-
Ville Syrjälä authored
LVDS and eDP have essentially the same code for grabbing the fixed mode from VBT. Pull that code to a common location. Signed-off-by:
-
Ville Syrjälä authored
Some monitors apparently forget to mark any mode as preferred in the EDID. In this particular case we have a very generic looking ID "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk doesn't seem particularly wise. Also the quirk we have (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd have to fix it first. When there is no preferred mode we currently fall back to the VBT. That approach fails us here as the VBT mode is 1024x768 whereas the panel resolution is 800x600. So instead of falling back to the VBT when there is no preferred mode let's just pick the first probed mode. Only if the EDID provided no modes we fall back to the VBT. For this machine the VBIOS would appear to select the 800x600 60Hz EST mode rather than the first detailed mode (which is the new fallback will pick). The two modes differ only by having opposite sync polarities, which does not seem to matter to the panel in question. v2: Make sure the probed_modes list is not empty Cc: Adam Jackson <ajax@redhat.com> Cc: Roberto Viola <cagnulein@gmail.com> Tested-by:
Roberto Viola <cagnulein@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109780Signed-off-by:
Adam Jackson <ajax@redhat.com> Acked-by:
-
