- 03 Jul, 2019 9 commits
-
-
Ville Syrjälä authored
When SAGV is forced to disabled/min/med/max in the BIOS pcode will only hand us a single QGV point instead of the normal three. Fix the code to deal with that instead declaring the bandwidth limit to be 0 MB/s (and thus preventing any planes from being enabled). Also shrink the max_bw sturct a bit while at it, and change the deratedbw type to unsigned since the code returns the bw as an unsigned int. Since we now keep track of how many qgv points we got from pcode we can drop the earlier check added for the "pcode doesn't support the memory subsystem query" case. Cc: felix.j.degrood@intel.com Cc: Mark Janes <mark.a.janes@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Fixes: c457d9cf ("drm/i915: Make sure we have enough memory bandwidth on ICL") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110838Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606124210.3482-1-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
-
Chris Wilson authored
Since a shrinker may be forced to wait on GPU activity, i915_active_wait(&vma->active) must be safe for use inside a shrinker, and so let's mark up the lock as being acquired by the shrinker to avoid any nasty surprises creeping in. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-8-chris@chris-wilson.co.uk
-
Chris Wilson authored
Make the lockchains more deterministic via i915_active by flagging the potential lock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-7-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we have dropped the final reference to the object, we do not need to wait until after the rcu grace period to drop its pages. We still require struct_mutex to completely unbind the object to release the pages, so we still need a free-worker to manage that from process context. By scheduling the release of pages before waiting for the rcu should mean that we are not trapping those pages from beyond the reach of the shrinker. v2: Pass along the request to skip if the vma is busy to the underlying unbind routine, to avoid checking the reservation underneath the i915->mm.obj_lock which may be used from inside irq context. v3: Flip the bit for unbinding while active, for later convenience. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111035 Fixes: a93615f9 ("drm/i915: Throw away the active object retirement complexity") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-6-chris@chris-wilson.co.uk
-
Chris Wilson authored
Be a little more hesitant before injecting a timeslice, and try to take into account any change in priority that is due for the running task before switching to another task. This will allow us to arbitrarily prevent switching away from a request if we deem it necessarily to disable preemption, for instance. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-9-chris@chris-wilson.co.uk
-
Chris Wilson authored
Remember to lock the drm_mm as we modify it, lest it be modified in the background by retire/free workers! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
We frequently, but not frequently enough!, remember to flush residual operations and objects at the end of a live subtest. The purpose is to cleanup after every subtest, leaving a clean slate for the next subtest, and perform early detection of leaky state. As this should ideally be common for all live subtests, pull the task into a common teardown routine. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703091726.11690-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
icl-dsi is dying on suspend/resume at RIP: 0010:icl_update_active_dpll+0x2c/0xa0 [i915] which appears due to the loss of the time primary_port across suspend. Protect against the potential NULL dereference by assuming ICL_PORT_DPLL_DEFAULT unless the port is actively specified otherwise. Fixes: 24a7bfe0 ("drm/i915: Keep the TypeC port mode fixed when the port is active") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190702140950.7069-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
When eliminating our use of drm_irq_install() I failed to convert all our synchronize_irq() calls to consult pdev->irq instead of dev_priv->drm.irq. As we no longer populate dev_priv->drm.irq we're no longer synchronizing against anything. v2: Add intel_syncrhonize_irq() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Imre Deak <imre.deak@intel.com> Fixes: b318b824 ("drm/i915: Nuke drm_driver irq vfuncs") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111012Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190702151723.29739-1-ville.syrjala@linux.intel.com
-
- 02 Jul, 2019 7 commits
-
-
Michał Winiarski authored
We missed one place where we check PPGTT-only platform for PPGTT presence. Let's remove it. While I'm here let's assert that this particular code is never called on pre-gen8 platforms. References: 4bdafb9d ("drm/i915: Remove i915.enable_ppgtt override") Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190702113149.21200-2-michal.winiarski@intel.com
-
Michał Winiarski authored
This reverts commit 4395890a. It's been over a year since this was merged, and the actual users of intel_ppat_get / intel_ppat_put never materialized. Time to remove it! v2: Unbreak suspend (Chris) v3: Rebase, drop fixes tag to avoid confusion Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190702113149.21200-1-michal.winiarski@intel.com
-
Mika Kuoppala authored
If we untrack wakerefs, the actual count may reach zero. However the krealloced owners array is still there and needs to be taken care of. Free the owners unconditionally to fix the leak. Fixes: bd780f37 ("drm/i915: Track all held rpm wakerefs") Reported-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190701104442.9319-1-mika.kuoppala@linux.intel.com
-
Lionel Landwerlin authored
The same tests failing on CFL+ platforms are also failing on ICL. Documentation doesn't list the WaAllowPMDepthAndInvocationCountAccessFromUMD workaround for ICL but applying it fixes the same tests as CFL. v2: Use only one whitelist entry (Lionel) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Tested-by: Anuj Phogat <anuj.phogat@gmail.com> Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190628120720.21682-4-lionel.g.landwerlin@intel.com
-
Lionel Landwerlin authored
CFL:C0+ changed the status of those registers which are now blacklisted by default. This is breaking a number of CTS tests on GL & Vulkan : KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations (GL) dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.* (Vulkan) v2: Only use one whitelist entry (Lionel) Bspec: 14091 Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190628120720.21682-3-lionel.g.landwerlin@intel.com
-
Lionel Landwerlin authored
When a register is readonly there is not much we can tell about its value (apart from its default value?). This can be covered by tests exercising the value of the register from userspace. For PS_INVOCATION_COUNT we've got the following piglit tests : KHR-GL45.pipeline_statistics_query_tests_ARB.functional_fragment_shader_invocations Vulkan CTS tests : dEQP-VK.query_pool.statistics_query.fragment_shader_invocations.* v2: Use a local to shrink under 80cols. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 86554f48 ("drm/i915/selftests: Verify whitelist of context registers") Tested-by: Anuj Phogat <anuj.phogat@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190629131350.31185-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we try to wait on an i915_active from within a critical section, it will remain busy (such as if we are shrinking from within i915_active_ref). Report the failure so that we do not proceed thinking it is idle. Extracted from a future patch "drm/i915: Coordinate i915_active with its own mutex". Fixes: 12c255b5 ("drm/i915: Provide an i915_active.acquire callback") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190702092117.1707-1-chris@chris-wilson.co.uk
-
- 01 Jul, 2019 24 commits
-
-
Chris Wilson authored
Daniele pointed out that the CSB status information will change with Tigerlake and suggested that we could rearrange our state machine to hide the differences in generation. gcc also prefers the explicit state machine, so make it so: process_csb 1980 1967 -13 Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190701100502.15639-4-chris@chris-wilson.co.uk
-
Matt Roper authored
Although EHL added a third combo PHY, no PHY_MISC register was added for PHY C. The bspec indicates that there's no need to program the "DE to IO Comp Pwr Down" setting for this PHY that we usually need to set in PHY_MISC. v2: - Add IS_ELKHARTLAKE() guards since future platforms that have a PHY C are likely to reinstate the PHY_MISC register. (Jose) - Use goto's to skip PHY_MISC programming & minimize code deltas. (Jose) Bspec: 33148 Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-4-matthew.d.roper@intel.comReviewed-by: José Roberto de Souza <jose.souza@intel.com>
-
Matt Roper authored
v2: Rename register to _EHL_COMBOPHY_C. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-3-matthew.d.roper@intel.com
-
Matt Roper authored
The port parameter hasn't been used since the last bspec phy programming update. Drop it to make some upcoming changes simpler. References: 9659c1af ("drm/i915/icl: combo port vswing programming changes per BSPEC") Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626000352.31926-2-matthew.d.roper@intel.com
-
Chris Wilson authored
During reset, we must be very selective in which locks we take as most are tainted by being held across a wait or reclaim (kmalloc) which implicitly waits. Inside the guc reset path, we reset the ADS to sane defaults, but must keep it pinned from initialisation to avoid having to pin it during reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190701100502.15639-1-chris@chris-wilson.co.uk
-
Imre Deak authored
Lane reversal happens only in the FIA module for TBT-alt/DP-alt mode, so WARN if lane reversal is attempted at a different level. See the BSpec DDI_BUF_CTL register description. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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-24-imre.deak@intel.com
-
Imre Deak authored
Disconnecting the TypeC PHY when the port is in legacy mode is not necessary: - BSpec doesn't specify a disconnect sequence for legacy mode. - The use of the PHY is dedicated for the display in legacy mode. - We keep the PHY always connected during runtime as well in legacy mode. We disconnect the PHY when needed during a disabling modeset for the port, so we can also remove the disconnect call from the destroy hook. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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-23-imre.deak@intel.com
-
Imre Deak authored
Add state verification for the TypeC port mode wrt. the port's AUX power well enabling/disabling. Also check the correctness of changing the port mode: - When enabling/disabling the AUX power well for a TypeC port we must hold the TypeC port lock - the case for AUX transfers - or hold a Type C port link reference - the case for modeset enabling/disabling. - When changing the TypeC port mode the port's AUX power domain must be disabled. v2: (Ville) - Simplify power_well_async_ref_count(). - Fix the commit log, clarifying what are the valid conditions to enable/disable the AUX power wells. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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-22-imre.deak@intel.com
-
Imre Deak authored
The TypeC port mode needs to stay fixed whenever the port is active. Do that by introducing a tc_link_refcount to account for active ports, avoiding changing the port mode if a reference is held. During the modeset commit phase we also have to reset the port mode and update the active PLL reflecting the new port mode. We can do this only once the port and its old PLL has been already disabled. Add the new encoder update_prepare/complete hooks that are called around the whole enabling sequence. The TypeC specific hooks of these will reset the port mode, update the active PLL if the port will be active and ensure that the port mode will stay fixed for the duration of the whole enabling sequence by holding a tc_link_refcount. During the port enabling, the pre_pll_enable/post_pll_disable hooks will take/release a tc_link_refcount to ensure the port mode stays fixed while the port is active. Changing the port mode should also be avoided during connector detection and AUX transfers if the port is active, we'll do that by checking the port's tc_link_refcount. When resetting the port mode we also have to take into account the maximum lanes provided by the FIA. It's guaranteed to be 4 in TBT-alt and legacy modes, but there may be less lanes available in DP-alt mode, in which case we have to fall back to TBT-alt mode. While at it also update icl_tc_phy_connect()'s code comment, reflecting the current way of switching the port mode. v2: - Add the update_prepare/complete hooks to the encoder instead of the connector. (Ville) - Simplify intel_connector_needs_modeset() by removing redundant if. (Ville) v3: - Fix sparse warning, marking static functions as such. v4: - Rebase on drm-tip. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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-21-imre.deak@intel.com
-
Imre Deak authored
When enabling a TypeC port we need to reserve all the required PLLs for it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks. We can select the proper PLL for the current port mode from the reserved PLLs only once we selected and locked down the port mode for the whole duration of the port's active state. Resetting and locking down the port mode can in turn happen only during the modeset commit phase once we disabled the given port and the PLL it used. To support the above reserve-and-select PLL semantic we store the reserved PLLs along with their HW state in the CRTC state and provide a way to select the active PLL from these. The selected PLL along with its HW state will be pointed at by crtc_state->shared_dpll/dpll_hw_state as in the case of other port types. Besides reserving all required PLLs no functional changes. v2: - Fix releasing the ICL PLLs, not clearing the PLLs from the old crtc_state. - Init port_dpll to ICL_PORT_DPLL_DEFAULT closer to where port_dpll is used for symmetry with the corresponding ICL_PORT_DPLL_MG_PHY init. (Ville) v3: - Add FIXME: for clearing the ICL port PLLs from the new crtc state. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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-20-imre.deak@intel.com
-
Imre Deak authored
For clarity factor out the combo PHY and TypeC PHY specific code from icl_get_dplls() into their own functions. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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-19-imre.deak@intel.com
-
Imre Deak authored
Pass the PLL HW state to the PLL find/reference functions making it clearer what is their input. Also pass to these the atomic state and the CRTC object instead of the CRTC state, since they don't require the latter. Move setting the PLL in the crtc_state to the get_dpll() hook, which is the more logical place for this, where the related PLL HW state was also set. This refactoring is also a preparation for a follow-up patch that will have to find/reference multiple PLLs. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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-18-imre.deak@intel.com
-
Imre Deak authored
For consistency s/intel_get_shared_dpll()/intel_reserve_shared_dplls()/ to better match intel_release_shared_dplls(). Also, pass to the reserve/release and get_dplls/put_dplls hooks the intel_atomic_state and CRTC object, that way these functions can look up the old or new state as needed. Also release the PLLs from the atomic state via a new put_dplls->intel_unreference_shared_dpll() call chain for better symmetry with the reservation via the get_dplls->intel_reference_shared_dpll() call chain. Since nothing uses the PLL returned by intel_reserve_shared_dplls(), make it return only a bool. While at it also clarify the reserve/release function docbook headers making it clear that multiple DPLLs will be reserved/released and whether the new or old atomic CRTC state is affected. This refactoring is also a preparation for a follow-up change that needs to reserve multiple DPLLs. Kudos to Ville for the idea to pass intel_atomic_state around, to make things clearer locally where an object's old/new atomic state is required. No functional changes. v2: - Fix checkpatch issue: typo in code comment. v3: - Rebase on drm-tip. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@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-17-imre.deak@intel.com
-
Imre Deak authored
Use hex numbers, since that makes more sense when decoding a bit pattern. No functional change. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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-16-imre.deak@intel.com
-
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: 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-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 <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-13-imre.deak@intel.com
-
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 <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-12-imre.deak@intel.com
-
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 <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-11-imre.deak@intel.com
-
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 <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-10-imre.deak@intel.com
-
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 <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-8-imre.deak@intel.com
-
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 <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-7-imre.deak@intel.com
-
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 <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-6-imre.deak@intel.com
-