- 01 Jul, 2019 20 commits
-
-
Imre Deak authored
We must keep the TypeC port mode fixed for the duration of the connector detection and each AUX transfers. Add a new TypeC lock holding it around these two sequences. For consistency also hold the lock during the port mode sanitization. Whenever resetting the port mode (only during the detection for now) the port's AUX power domain must be disabled already. Flush the async power domain disabling work to ensure this. A follow-up patch will make the port mode changing more robust by postponing the change for active ports. v2: - Fix checkpatch issue: missing annotation for tc_lock. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-15-imre.deak@intel.com
-
Imre Deak authored
For using the correct AUX power domains we have to sanitize the TypeC port mode early, so move that before encoder sanitization. To do this properly read out the actual port mode instead of just relying on the VBT legacy port flag (which can be incorrect). We also verify that the PHY is connected as expected if the port is active. In case the port is inactive we connect the PHY in case of a legacy port - as we did so far. The PHY will be connected during detection for DP-alt mode - as it was done so far. For TBT-alt mode nothing needs to be done to connect the PHY. v2: - Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José) v3: - Detect TCCOLD any time PORT_TX_DFLEXDPCSSS is read. (Ville) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-14-imre.deak@intel.com
-
Imre Deak authored
Make the order during detection more consistent: first reset the TypeC port mode if needed (adding new helpers for this), then detect any connected sink. To check if a port mode reset is needed determine first the target port mode based on the live status if a sink is already connected or the PHY status complete flag otherwise. Add a WARN in legacy mode if unexpectedly we can't set the unsafe mode or if the FIA doesn't provide the 4 lanes required. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Based on a recent BSpec update (Index/21750) we must handle the TCCOLD event associated with the DP-alt mode. We can detect this event by reading an invalid all-1s value from FIA registers. After detecting TCCOLD we will: - fall back to TBT-alt mode when attempting to switch to DP-alt mode - conclude that nothing is connected during live status detection - WARN when already in unsafe mode, since then TCCOLD is unexpected v2: - Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José) v3: - Use 0xffffffff instead of -1 as invalid FIA reg value. (José, Ville) - Check for TCCOLD in icl_tc_phy_status_complete() too. (Ville) 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
The PHY status complete flag normally clears when disconnecting the PHY in DP-alt mode (achieved by switching to safe mode), so wait for the flag to clear. v2: - Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Imre Deak authored
Factor out helpers reading/parsing the TypeC specific registers, making current users of them clearer and letting us use them later. While at it also: - Simplify icl_tc_phy_connect() with an early return in legacy mode. - Simplify the live status check using one bitmask for all HPD bits. - Remove a micro-optimisation of the repeated safe-mode clearing. - Make sure we fix the legacy port flag in all cases. Except for the last two, no functional changes. v2: - Don't do reg reads at variable declarations. (Jani) - Prevent constant truncated compiler warning when assigning the valid_hpd_mask. (Nick) - s/intel_tc_port_get_lane_info/intel_tc_port_get_lane_mask/ (Ville) v3: - Make valid_hpd_mask init clear. (Ville) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
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 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:
-
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 7 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:
-
