- 01 Jul, 2019 14 commits
-
-
Imre Deak authored
Unify the TypeC port notation in log messages, so that it matches the spec. For instance the first ICL TypeC port will read as 'Port C/TC#1'. v2: - Format print the name only once. (José) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-9-imre.deak@intel.com
-
Imre Deak authored
In the TypeC TBT-alt port mode we must use the TBT AUX power domain, fix that. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL register. Fixes: c7375d95 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
According to the spec we should not enable the DDI-IO power domain if the TypeC port is in the TBT-alt mode, so do that only in the other TypeC modes or for non-TypeC ports. See the internal BSpec Index/22243. v2: - Add the internal BSpec reference to the log message. (José) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
The TypeC port mode can switch dynamically, to reflect that better call the port's mode as 'mode' rather than 'type'. While at it: - s/TC_PORT_TBT/TC_PORT_TBT_ALT/ and s/TC_PORT_TYPEC/TC_PORT_DP_ALT/. 'TYPEC' is ambiguous, TBT_ALT and DP_ALT better match the reality. - Remove the 'unknown' TypeC port mode. The mode is always known, it's the TBT-alt/safe mode after HW reset and after disconnecting the PHY. Simplify the tc_port/tc_type checks accordingly. - Don't WARN if the port mode changes, that can happen normally. No functional changes. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-5-imre.deak@intel.com
-
Imre Deak authored
Move the TypeC port handling functions to a new file for clarity. While at it: - s/icl_tc_port_connected()/intel_tc_port_connected()/ icl_tc_phy_disconnect(), will be unexported later. - s/intel_dp_get_fia_supported_lane_count()/ intel_tc_port_fia_max_lane_count()/ It's used for HDMI legacy mode too. - Simplify function interfaces by passing only dig_port to them. No functional changes. v2: - Fix checkpatch issues: +1/-1 empty lines in intel_tc.c and add missing SPDX to intel_tc.h. (Jani) Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Imre Deak authored
The HW completion flag for the TBT AUX power well enabling/disabling gets stuck if the firmware tears down the TBT DP tunnel before the completion. We shouldn't complain about the timeout, since it's expected to happen and doesn't cause further issues. We suppress the disabling timeout already, do the same for enabling. v2: - Make the debug message more precise. (José) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Add support to read out the TBT PLL HW state. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Instead of directly referencing drm_crtc_state, convert to intel_ctc_state and use the base struct. This is useful when we're making the split between uapi and hw state, and also makes the code slightly more readable. A lot of places also use cstate, instead of the more common crtc_state. Clean those up to use crtc_state. Same for pstate vs plane_state. (Ville) Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-7-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Pass along the correct state as much as possible, instead of relying on the drm state internally. This is required to rely on hw state internally soon. While at it, clean up intel_plane_atomic_check slightly, by using a helper function to get the intel_crtc. (Ville) Signed-off-by:
-
Maarten Lankhorst authored
Get rid of all instances of drm_crtc_state, and rename cstate to crtc_state for more clarity. Signed-off-by:
-
Maarten Lankhorst authored
Like the rest of the intel atomic functions we should pass along intel_crtc_state, and dereference drm_crtc_state only through intel_crtc_state->base While at it, rename old/new_state to old/new_crtc_state. (Ville) Signed-off-by:
-
Maarten Lankhorst authored
Instead of passing along drm_crtc_state and drm_atomic_state, pass along more intel_atomic_state and intel_crtc_state. This will make the code more readable by not casting between drm state and intel state all the time. While at it, rename old_state to state, with the get_new/old helpers there is no point in distinguishing between state before and after swapping state any more. (Ville) Signed-off-by:
-
Maarten Lankhorst authored
In i915 we should use intel_crtc_state as much as possible, pass intel_crtc_state to needs_modeset, before we clean up all other uses of drm_crtc_state. Signed-off-by:
-
- 28 Jun, 2019 1 commit
-
-
Lucas De Marchi authored
This prepares to have possibly more than 3 pipes. I didn't want to continue the previous approach since the check for "are the disabled pipes the last ones" poses a combinatory explosion. We need that check because in several places of the code we have that assumption. If that ever becomes false in a new HW, other parts of the code would have to change. Now we start by considering we have info->num_pipes enabled and disable each pipe that is marked as disabled. Then it's a simple matter of checking if we have at least one pipe and that all the enabled ones are the first pipes, i.e. there are no holes in the bitmask. Cc: Jose Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 27 Jun, 2019 12 commits
-
-
Chris Wilson authored
drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol 'i945gm_vblank_work_func' was not declared. Should it be static? CC [M] drivers/gpu/drm/i915/i915_irq.o drivers/gpu/drm/i915/i915_irq.c:3382:6: error: no previous prototype for ‘i945gm_vblank_work_func’ [-Werror=missing-prototypes] void i945gm_vblank_work_func(struct work_struct *work) Jani wrote the idential patch, so for posterity: The static keyword was apparently accidentally removed in commit 08fa8fd0 ("drm/i915: Switch to per-crtc vblank vfuncs"), leading to sparse warning: drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol 'i945gm_vblank_work_func' was not declared. Should it be static? Make the function static again. Meanwhile, the 0-day kbuilder also spotted the mistake. Fixes: 08fa8fd0 ("drm/i915: Switch to per-crtc vblank vfuncs") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. v2: also include i915_reg.h (Michal) Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
Add the minimal includes/declarations to make the header self-contained, and ensure it stays that way. Reviewed-by:
-
Jani Nikula authored
With the subdirectories we lost the ability to build individual files on the command line, for example: $ make drivers/gpu/drm/i915/display/intel_display.o This was due to the top level directory missing from header search path. Add the header search paths to subdir Makefiles. Note that none of the other options in the top level i915 Makefile are taken into account when building individual files. Usually this is not a concern. Reported-by:
-
Jani Nikula authored
Per commit 43068cb7 ("drm: prefix header search paths with $(srctree)/") this is what we should be doing. Follow suit. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 26 Jun, 2019 13 commits
-
-
Michal Wajdeczko authored
OA files look to be auto-generated so we can keep them all in dedicated subdirectory. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Acked-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
-
José Roberto de Souza authored
EHL has it own voltage level requirement depending on cd clock. BSpec: 21809 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
José Roberto de Souza authored
EHL do not support 648 and 652.8 MHz. v2: - Limiting maximum CD clock by max_cdclk_freq instead of remove it from icl_calc_cdclk()(Ville and Jani) BSpec: 20598 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Now 180, 172.8 and 192 MHz are supported. 180 and 172.8 MHz CD clocks will only be used when audio is not enabled as state by BSpec and implemented in intel_crtc_compute_min_cdclk(), CD clock must be at least twice of Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48 MHz but we are not reading it. v3: - making icl clock arrays static (Ville) BSpec: 20598 BSpec: 15729 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
Since the reset path wants to recover the engines itself, it only wants to reinitialise the hardware using i915_gem_init_hw(). Pull the call to intel_engines_resume() to the module init/resume path so we can avoid it during reset. Fixes: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we issue a reset to a currently idle engine, leave it idle afterwards. This is useful to excise a linkage between reset and the shrinker. When waking the engine, we need to pin the default context image which we use for overwriting a guilty context -- if the engine is idle we do not need this pinned image! However, this pinning means that waking the engine acquires the FS_RECLAIM, and so may trigger the shrinker. The shrinker itself may need to wait upon the GPU to unbind and object and so may require services of reset; ergo we should avoid the engine wake up path. The danger in skipping the recovery for idle engines is that we leave the engine with no context defined, which may interfere with the operation of the power context on some older platforms. In practice, we should only be resetting an active GPU but it something to look out for on Ironlake (if memory serves). Fixes: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
-
Chris Wilson authored
For use in the next patch, we want to acquire a wakeref without having to wake the device up -- i.e. only acquire the engine wakeref if the engine is already active. Signed-off-by:
-
Ville Syrjälä authored
Move the .get_vblank_timestamp() and .get_scanout_position() initialization to happen at compile time. No point in delaying it since we always assign the same functions. Signed-off-by:
-
Ville Syrjälä authored
Stop using the irq vfuncs under drm_driver. That's not going to fly in a mixed gen environment since the structure is shared between all the devices. v2: Allow intel_irq_uninstall() to be called twice due to intel_modeset_cleanup() calling it as well. Toss in a FIXME to remind us that this is not great. Signed-off-by: -
Ville Syrjälä authored
Switch from the driver-wide vblank vfuncs to the per-crtc ones so that we don't have so many platform specific vfuncs in the driver struct. We still need to do something about the rest fo the irq vfuncs... v2: s/INTEL_GEN>=3/IS_GEN3/ Signed-off-by:
-
Ville Syrjälä authored
Gen2 doesn't have a frame counter and apparently we no longer provide a fake .get_vblank_counter() hook for it. That means all tracepoints calling that hook will oops. Update the tracepoints to use intel_crtc_get_vblank_counter() which will gracefully fall back to using the software counter. This is actually a better approach since we now get (hopefully accurate) frame numbers in the traces. This also gets rid of the raw driver->get_vblank_counter() calls, which we need to do in order to switch to the per-crtc vblank vfuncs. v2: Deal with new tracepoints v3: Use a distinct variable name for the internal crtc iterator (Chris) Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 967dd484 ("drm: remove drm_vblank_no_hw_counter assignment from driver code") Signed-off-by:
-
Chris Wilson authored
We require that the intel_gpu_reset() was atomic, not the whole of i915_reset() which is guarded by a mutex. However, we do require that i915_reset_engine() is atomic for use from within the submission tasklet. Signed-off-by:
-
Chris Wilson authored
We no longer need to manually acquire a wakeref for request emission, so drop the redundant wakerefs, letting us test our wakeref handling more precisely. References: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
-
