- 17 Sep, 2020 4 commits
-
-
Ville Syrjälä authored
Our definitions for the DPCD DFP capabilities are lacking. Add the missing bits. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-5-ville.syrjala@linux.intel.comReviewed-by:
Lyude Paul <lyude@redhat.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol converters. Define those. Signed-off-by:
-
Ville Syrjälä authored
Non-HDMI sinks shouldn't be sent infoframes. Check for that when using LSPCON. FIXME: How do we turn off infoframes once enabled? Do we even have to? Signed-off-by: -
Ville Syrjälä authored
It helps when the logs have a dump of the DFP capabilities. v2: Move the dumping to the new helper Signed-off-by:
-
- 16 Sep, 2020 2 commits
-
-
Chris Wilson authored
Since we store a pointer to the fake iommu device that is allocated on the stack, as soon as we leave the function it goes out of scope and any future dereference is undefined behaviour. Just in case we may need to look at the fake iommu device after initialiation, move the allocation from the stack into the data. Fixes: 01b9d4e2 ("iommu/vt-d: Use dev_iommu_priv_get/set()") 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/20200916105022.28316-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Just in case the caller passes in 0 for both slow&fast timeouts, make sure we initialise the stack value returned. Add an assert so that we don't make the mistake of passing 0 timeouts for the wait. drivers/gpu/drm/i915/intel_uncore.c:2011 __intel_wait_for_register_fw() error: uninitialized symbol 'reg_value'. References: 3f649ab7 ("treewide: Remove uninitialized_var() usage") Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200916105022.28316-1-chris@chris-wilson.co.uk
-
- 15 Sep, 2020 15 commits
-
-
Anusha Srivatsa authored
We currenty check for platform at multiple parts in the driver to grab the correct PLL. Let us begin to centralize it through a helper function. v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville) v3: Clean up combo_pll_disable() (Rodrigo) v4: s/dev_priv/i915 (Jani) Move static and return type to the same line( Ville, Jani) Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200914175703.15024-1-anusha.srivatsa@intel.comReviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
No point in assigning the function return value to a local variable if we're just going to use it the one time. Signed-off-by:
-
Ville Syrjälä authored
Introduce intel_hpd_hotplug_irqs() as a partner to intel_hpd_enabled_irqs(). There's no need to care about the encoders which we're not exposing, so we can avoid hardcoding the masks in various places. Signed-off-by:
-
Ville Syrjälä authored
Make a clean split between hpd pins for DDI vs. TC. This matches how the actual hardware is split. And with this we move the DDI/PHY->HPD pin mapping into the encoder init instead of having to remap yet again in the interrupt code. Signed-off-by:
-
Ville Syrjälä authored
Currently DP/HDMI/DDI encoders init their hpd_pin from the connector init. Let's move it to the encoder init so that we don't need to add platform specific junk to the connector init (which is shared by all g4x+ platforms). Signed-off-by:
-
Ville Syrjälä authored
No reason to stuff both DDI and TC port handling into the same function. Split it into two. Signed-off-by:
-
Ville Syrjälä authored
gen11_hpd_detection_setup() is missing ports TC5/6. Add them. TODO: Might be nice to only enable the hpd detection logic for ports we actually have. Should be rolled out for all platforms if/when done... Signed-off-by:
-
Ville Syrjälä authored
We have nice parametrized GEN11_{TC,TBT}_HOTPLUG() so nuke the overlapping defines. Signed-off-by: -
Ville Syrjälä authored
As with everything else VBT can now specify AUX CH H or I. Signed-off-by:
-
Ville Syrjälä authored
VBT has ports H and I since version 217. Signed-off-by:
-
Ville Syrjälä authored
AUX CH H/I need their power domains too. Signed-off-by:
-
Ville Syrjälä authored
We need to go up to PORT_I (aka. TC6) these days. Signed-off-by:
-
Ville Syrjälä authored
We need to go up to AUX_CH_I (aka. AUX CH USBC6) these days. Signed-off-by:
-
Ville Syrjälä authored
Since the display hardware is all there even when INTEL_DISPLAY_ENABLED return false we have to be capable of shutting it down cleanly so as to not anger the hw. To that end let's reduce the effect of !INTEL_DISPLAY_ENABLE to just treating all outputs as disconnected. Should prevent anyone from automagically enabling any of them, while still allowing us to cleanly shut them down. v2: Put the check into the right place for CRT Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Having a mode where the display hardware is present but we try to pretend it isn't just leads to massive headaches when trying to reason what the fallout might be from skipping some random bits of programming. Let's just neuter INTEL_DISPLAY_ENABLED so that we treat the hardware as fully present, except we just don't register any outputs. That's still rather sketchy if the outputs are already enabled when the driver is loaded. I think the simplest solution would be to probe everything as normal and just return disconnected" from all .detect() hooks. That would avoid anything automagically enabling those outputs, but the driver could then shut things down using the normal codepaths. Signed-off-by:
-
- 14 Sep, 2020 9 commits
-
-
Rodrigo Vivi authored
Signed-off-by: -
Rodrigo Vivi authored
Signed-off-by: -
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2020-09-10 - Cleanup command access flag (Yan) - New workaround cmd access fix (Colin) - MIA reset state fix (Colin) Signed-off-by:
-
Ville Syrjälä authored
g4x+ sprites have an extra cdclk limitation listed for RGB formats. For some random reason I chose to use cpp>=4 as the check for that. While that does actually work let's deobfuscate it by checking for !is_yuv instead. I suspect is_yuv didn't exist way back when I originally write the code. Also drop the duplicate comment. Signed-off-by:
-
Ville Syrjälä authored
Even if we're not doing downscaling we should account for some of the extra dotclock limitations for g4x+ sprites. In particular we must never exceed the 90% rule, and with RGB that limits actually drops to 80%. So instead of bailing out when upscaling let's clamp the scaling factor appropriately and go through the rest of calculation normally. By luck we already did the full calculations for the 1:1 case. Signed-off-by:
-
Ville Syrjälä authored
The CACHE_MODE_0 save/restore was added without explanation in commit 1f84e550 ("drm/i915 more registers for S3 (DSPCLK_GATE_D, CACHE_MODE_0, MI_ARB_STATE)"). If there are any bits we care about those should be set explicitly during some appropriate init function. Let's assume it's all good and just nuke this magic save/restore. Signed-off-by:
-
Ville Syrjälä authored
Originally added in commit 1f84e550 ("drm/i915 more registers for S3 (DSPCLK_GATE_D, CACHE_MODE_0, MI_ARB_STATE)") to fix some underruns. I suspect that was due to the trickle feed settings getting clobbered during suspend. We've been disabling trickle feed explicitly since commit 20f94967 ("drm/i915: Disable trickle feed via MI_ARB_STATE for the gen4") so this magic save/restore should no longer be needed. Signed-off-by:
-
Ville Syrjälä authored
The FBC_CONTROL save restore is there just to preserve the compression interval setting. Since commit a68ce21b ("drm/i915/fbc: Store the fbc1 compression interval in the params") we've been explicitly setting the interval to a specific value, so the sace/restore is now entirely pointless. Signed-off-by:
-
Ville Syrjälä authored
We don't save/restore PCH_PORT_HOTPLUG so no point in reseving space for the value. Signed-off-by:
-
- 12 Sep, 2020 1 commit
-
-
Rodrigo Vivi authored
Sync drm-intel-gt-next here so we can have an unified fixes flow. Signed-off-by:
-
- 11 Sep, 2020 4 commits
-
-
Ville Syrjälä authored
There's no real reason to stash away the DPIO PHY IOSF sideband port numbers for VLV/CHV. Just compute them at runtime in the sideband code. Gets rid of the oddball intel_init_dpio() function from the high level init flow. Signed-off-by:
-
Jani Nikula authored
Logically part of the display restore. Note: This has been in place since the introduction of gmbus support. The gmbus code also does the resets before transfers. Is this really needed, or a historical accident? Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Logically part of the display save/restore. No functional changes. Reviewed-by:
-
Jani Nikula authored
Disable all display feature flags when there are no pipes i.e. there is no display. This should help with not having to additionally check for HAS_DISPLAY() when a feature flag check would suffice. Also disable modeset and atomic driver features. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 10 Sep, 2020 5 commits
-
-
Maarten Lankhorst authored
This function should be an int, not a bool. Presumably because we had the same 2 reverts in a slightly different way, git got confused. Thanks to Dan for reporting. :) The conflict is between the 3 reverts in drm-fixes: 4993a8a3 ("Revert "drm/i915: Remove i915_gem_object_get_dirty_page()"") ad5d95e4 ("Revert "drm/i915/gem: Async GPU relocations only"") 20561da3 ("Revert "drm/i915/gem: Delete unused code"") And the slightly different combined revert in drm-intel-gt-next, but with the same goal: 102a0a90 ("Revert "drm/i915/gem: Async GPU relocations only"") In the merge commit 1f4b2aca ("Merge tag 'drm-intel-gt-next-2020-09-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next") things went wrong, but the merge commit view now doesn't show any conflict anymore (as git tends to do when the resolution picks one or the other branch). The need to handle other than just true/false error codes in __reloc_entry_gpu was added in the dma_resv locking changes in c43ce123 ("drm/i915: Use per object locking in execbuf, v12.") Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Dave Airlie <airlied@redhat.com> [danvet: Explain this entire saga a lot better, adding tons of commit references. Also note that this was merged before full intel-gfx-CI results, only after BAT, since the breakage at the BAT run is already severe enough to block all pre-merge testing.] Fixes: 1f4b2aca ("Merge tag 'drm-intel-gt-next-2020-09-07' of git://anongit.freedesktop.org/drm/drm-intel into drm-next") Acked-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Colin Xu authored
Although GVT doesn't support guest GuC, MIA core is still expected to be GS_MIA_IN_RESET after uc HW reset. Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Colin Xu <colin.xu@intel.com> Signed-off-by:
-
Colin Xu authored
Without F_CMD_ACCESS, guest LRI cmd will fail due to "access to non-render register" when init below WAs: WaDisableDynamicCreditSharing: GAMT_CHKN_BIT_REG WaCompressedResourceSamplerPbeMediaNewHashMode: MMCD_MISC_CTRL So add F_CMD_ACCESS to the two MMIO. Reviewed-by:
-
Yan Zhao authored
some registers cannot be cmd accessible. remove them from the list Reviewed-by:
Wang Zhi <zhi.a.wang@intel.com> Signed-off-by:
Yan Zhao <yan.y.zhao@intel.com> Signed-off-by:
-
Yan Zhao authored
flag F_CMD_ACCESS represents whether an MMIO is able to be accessed by GPU commands. In this patch, 1. add interface to set this flag 2. rename intel_gvt_mmio_is_cmd_access() to intel_gvt_mmio_is_cmd_accessible() and update its description message. Reviewed-by:
-
