- 12 Jun, 2019 3 commits
-
-
Ville Syrjälä authored
Our PCH refclk init code currently assumes that the PCH SSC reference can only be used for FDI. That is not true and it can be used by SPLL/WRPLL for eDP SSC or clock bending as well. Before we go reconfiguring it let's make sure no PLL is currently using the PCH SSC reference. For some reason the hw is not particularly upset about losing the clock if we immediately follow up with a modeset. Can't really explain why nothing times out during the crtc disable at least, but that's what the logs say. With fastboot the story is quite different and we lose the entire display if we turn off the PCH SSC reference when it's still being used. Since we totally skip configuring the PCH SSC reference it may not be in the proper state for FDI. Hopefully that won't be a problem in practice. We really should move this code to be part of the modeset seqeuence and properly deal with the potentially conflicting requirements imposed on PLL reference clocks. But that requires actual work. Let's toss in a TODO for that. v2: Pimp the commit message with the fastboot vs. not details Cc: Julius B. <freedesktop@blln.gr> Cc: Johannes Krampf <johannes.krampf@gmail.com> Tested-by:Johannes Krampf <johannes.krampf@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108773Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190604200933.29417-1-ville.syrjala@linux.intel.comReviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Chris Wilson authored
We cannot allow ourselves to wait on the GPU while holding any lock as we may need to reset the GPU. While there is not an explicit lock between the two operations, lockdep cannot detect the dependency. So let's tell lockdep about the wait/reset dependency with an explicit lockmap. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190612085246.16374-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we don't give it a label, it does not appear as a configuration option. Signed-off-by:
-
- 11 Jun, 2019 7 commits
-
-
Lucas De Marchi authored
Like was done for ICL, let's convert the voltage level lookup to use frequency ranges rather than individual frequencies. For deciding the voltage, the individual value doesn't really matter. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Like was done for ICL, let's convert the voltage level lookup to use frequency ranges rather than individual frequencies. For deciding the voltage, the individual value doesn't really matter. Signed-off-by:
-
Lucas De Marchi authored
Spec shows voltage level 0 as 307.2, 312, or lower and suggests to use range checks. Prepare for having other frequencies in these ranges by not comparing the exact frequency. v2: invert checks by comparing biggest cdclk first (suggested by Ville) Signed-off-by:
-
Tvrtko Ursulin authored
These functions operate on ggtt so make them take that directly as parameter. At the same time move the USES_GUC conditional down to intel_guc_reserve_ggtt_top for symmetry with intel_guc_reserved_gtt_size. v2: * Rename and move functions to be static in i915_gem_gtt.c (Michal) v3: * Add comment explaining reason for reservation, add assert and fix error message. (Michal) v4: * Fix checkpatch error. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190611122350.15060-1-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
Reduces pointer chasing and gets more to the point. v2: * Tidy whitespace. * Tidy comment. (Michal) Signed-off-by:
-
Chris Wilson authored
Keeping the _hw_ in there does not help to distinguish it from its only brethren i915_ggtt, so drop it. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190611091238.15808-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Make the kref common to both derived structs (i915_ggtt and i915_ppgtt) so that we can safely reference count an abstract ctx->vm address space. Signed-off-by:
-
- 10 Jun, 2019 16 commits
-
-
Chris Wilson authored
The intent is to be able to update the mm.lists from inside an irqsoff section (e.g. from a softirq rcu workqueue), ergo we need to make the i915->mm.obj_lock irqsafe. v2: can_discard_pages() ensures we are shrinkable v3: Beware shadowing of 'flags' Fixes: 3b4fa964 ("drm/i915: Track the purgeable objects on a separate eviction list") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110869Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610145430.17717-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Before we commit ourselves to writing commands into the ringbuffer and submitting the request, allow signals to interrupt acquisition of the timeline mutex. We allow ourselves to be interrupted at any time later if we need to block for space in the ring, anyway. Signed-off-by:
-
Tvrtko Ursulin authored
The function operates on the render engine so make the input reflect it. v2: * Pass engine to read_subslice_reg. (Chris) * Drop inline from read_subslice_reg. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Tvrtko Ursulin authored
Now that all their users are gone we can remove the macros and accompanying duplicated comment. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
More implicit dev_priv removal. Signed-off-by:
-
Tvrtko Ursulin authored
More implicit dev_priv removal. Signed-off-by:
-
Tvrtko Ursulin authored
More removal of implicit dev_priv. Signed-off-by:
-
Tvrtko Ursulin authored
No excuse for code located in intel_uncore.c to not use intel_uncore_ helpers. Signed-off-by:
-
Tvrtko Ursulin authored
On the path of removing mmio accessors with implicit dev_priv, easy first step is to remove all such unused macros. Signed-off-by:
-
Lionel Landwerlin authored
Gen10 added an additional NOA_WRITE register (high bits) and we forgot to whitelist it for userspace. Fixes: 95690a02 ("drm/i915/perf: enable perf support on CNL") Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190601225845.12600-1-lionel.g.landwerlin@intel.com
-
Tvrtko Ursulin authored
The code is logically about reset so it makes sense. It also enables making i915_clear_error_registers static. Signed-off-by:
-
Geert Uytterhoeven authored
Fix the grammar. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Jani Nikula authored
This no longer exists. Reviewed-by:
-
Jani Nikula authored
Some function declarations in intel_drv.h were missed when intel_atomic_plane.h was created. Reviewed-by:
-
Jani Nikula authored
intel_mark_busy(), intel_mark_idle(), and skl_cdclk_get_vco() no longer exist. Reviewed-by:
-
Jani Nikula authored
Move more missed declarations from i915_drv.h to intel_pm.h. Reviewed-by:
-
- 09 Jun, 2019 2 commits
-
-
Daniele Ceraolo Spurio authored
The size has been increased to 2MB starting from Gen11. GuC and HuC FWs fit in 1MB so we were fine even with the legacy define, but let's still move to the correct one before the blobs grow to avoid being caught off guard in the future. v2: return early if the platform doesn't have GuC, fix nits (Michal) Bspec: 12690 Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Stuart Summers <stuart.summers@intel.com> [ickle: use SZ consistently] Signed-off-by:
-
Daniele Ceraolo Spurio authored
Now that we've moved the Gen9 GuC blobs to version 32 we have CTB support on all gens, so no need to restrict the usage to Gen11+. Note that MMIO communication is still required for CTB initialization. v2: fix commit message nits (Michal) Signed-off-by:
-
- 08 Jun, 2019 3 commits
-
-
Hans de Goede authored
The GOP sometimes initializes the pclk at a (slightly) different frequency then the pclk which we've calculated. This commit makes the DSI code read-back the pclk set by the GOP and if that is within a reasonable margin of the calculated pclk, uses that instead. This fixes the first modeset being a full modeset instead of a fast modeset on systems where the GOP pclk is different. Changes in v2: -Use intel_encoder_current_mode() to get the pclk setup by the GOP Changes in v3: -Back to the readback approach, skipping the dsi_pll.ctrl / .dev checks in intel_pipe_config_compare() when adjust is set leads to: [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.ctrl (...) [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.div (...) -Do the readback and pclk overriding from vlv_dsi_init(), rather then from intel_dsi_vbt_init() as the vbt code should not be touching the hw Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605181735.7020-3-hdegoede@redhat.com
-
Hans de Goede authored
The vlv/icl_dphy_param_init calls do various calculations to set dphy parameters based on the pclk. Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give vlv_dsi_init a chance to tweak the pclk before these calculations are done. Changes in v2: -Also moves the icl and vlv specific dphy_param_init functions from the generic intel_dsi_vbt.c file into the icl_ and vlv_dsi.c specific files. Note icl_dphy_param_init() and vlv_dphy_param_init() are only moved, otherwise they are completely unchanged. Reviewed-by:
-
Hans de Goede authored
This is a preparation patch for moving the calling of *_dphy_param_init() out of intel_dsi_vbt_init. Reviewed-by:
-
- 07 Jun, 2019 9 commits
-
-
Ville Syrjälä authored
It's much easier to figure out why the SDVO encoder refuses to cooperate if we can see what status we got back. v2: Zero initialize only the first character, not the whole buffer Signed-off-by:
-
Ville Syrjälä authored
Pass the length returned by hdmi_infoframe_pack_only() to intel_sdvo_write_infoframe() so that we don't end up writing stack garbage into the hbuf. Signed-off-by:
-
Ville Syrjälä authored
Pass the length returned by intel_sdvo_read_infoframe() to hdmi_infoframe_unpack() so that we don't try to unpack any leftover stack garbage. Signed-off-by:
-
Ville Syrjälä authored
Before we go writing the infoframe let's make sure we have the space for it. Not that it really matters since the write loop would just terminate early in that case. v2: Check after the debug print and ++ (Chris) Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com>
-
Ville Syrjälä authored
The "audio enable" bit on the SDVO/HDMI control register is only meant for HDMI. Audio is never delivered over the SDVO bus. Rename the define to reflect this fact. Signed-off-by:
-
Ville Syrjälä authored
Our SDVO audio support is pretty bogus. We can't push audio over the SDVO bus, so trying to enable audio in the SDVO control register doesn't do anything. In fact it looks like the SDVO encoder will always mix in the audio coming over HDA, and there's no (at least documented) way to disable that from our side. So HDMI audio does work currently on gen4 but only by luck really. On gen3 it got broken by the referenced commit. And what has always been missing on every platform is the ELD. To pass the ELD to the audio driver we need to write it to magic buffer in the SDVO encoder hardware which then gets pulled out via HDA in the other end. Ie. pretty much the same thing we had for native HDMI before we started to just pass the ELD between the drivers. This sort of explains why we even have that silly hardware buffer with native HDMI. $ cat /proc/asound/card0/eld#1.0 -monitor_present 0 -eld_valid 0 +monitor_present 1 +eld_valid 1 +monitor_name LG TV +connection_type HDMI +... This also fixes our state readout since we can now query the SDVO encoder about the state of the "ELD valid" and "presence detect" bits. As mentioned those don't actually control whether audio gets sent over the HDMI cable, but it's the best we can do. And with the state checker appeased we can re-enable HDMI audio for gen3. Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: zardam@gmail.com Tested-by: zardam@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976 Fixes: de44e256 ("drm/i915/sdvo: Shut up state checker with hdmi cards on gen3") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
The AVI infoframe readout code currently issues a SDVO_CMD_GET_HBUF_TXRATE before SDVO_CMD_SET_HBUF_INDEX, which is not the correct order for these two operations. So far this wasn't a problem since we left the index pointing at the AVI infoframe buffer at the end of the modeset. However once we start to write to other buffers (namely ELD) that is no longer going to be true. Fix up the order so that we always read out the TX rate for the correct buffer. Signed-off-by:
-
Ville Syrjälä authored
We forgot to set .has_alpha=true for the A+CCS formats when the code started to consult .has_alpha. This manifests as A+CCS being treated as X+CCS which means no per-pixel alpha blending. Fix the format list appropriately. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Heinrich Fink <heinrich.fink@daqri.com> Reported-by:
Heinrich Fink <heinrich.fink@daqri.com> Tested-by:
-
Ville Syrjälä authored
intel_dp_link_down() is static and it's only called from the pre-ddi DP functions, so having a WARN_ON(HAS_DDI) in there is quite pointless. Remove it. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
