- 22 Sep, 2020 1 commit
-
-
Mauro Carvalho Chehab authored
As warned by kernel-doc: ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or member 'type' not described in 'drm_dp_downstream_is_type' ./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or member 'dev' not described in 'drm_dp_downstream_mode' Some function parameters weren't documented. Fixes: 38784f6f ("drm/dp: Add helpers to identify downstream facing port types") Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200922175357.42998-2-lyude@redhat.com
-
- 17 Sep, 2020 22 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Swathi Dhanavanthri authored
This workaround applies to all TGL and RKL steppings. Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200911221158.4700-1-swathi.dhanavanthri@intel.com
-
Ville Syrjälä authored
Since we now have proper old and new cdclk state we no longer need to keep this flag to indicate that the force min cdclk has changed. Instead just check if the old vs. new value are different. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-4-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
With the dbuf code mostly converted over to the new global state handling we can remove the leftovers of the old global state stuff. Signed-off-by:
-
Ville Syrjälä authored
For platforms that can't do native 4:2:0 outout we may still be able to do it by getting the DP->HDMI protocol converter to perform the 4:4:4->4:2:0 downsamling for us. In this case we have to configure our hardware to output YCbCr 4:4:4, which we've already hooked up so all we need to do is flip the switch. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Add helpers to determine whether the DFP supports YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion. v2: Add kdocs (Lyude) Signed-off-by:
-
Ville Syrjälä authored
Account for the TMDS clock limits declared by the DFP when determining what color depth we're going to use. v2: Drop the reference to DP++ dongle since it's not handled here Signed-off-by:
-
Ville Syrjälä authored
Pull the "do we want to enable audio?" computation into a small helper to make intel_hdmi_compute_config() less messy. Will make it easier to add more checks for this later (eg. we should actually be checking at the hblank is long enough for audio transmission). Signed-off-by:
-
Ville Syrjälä authored
Use drm_dp_downstream_mode() to get a suitable mode for downstream facing ports which don't have an EDID. Signed-off-by:
-
Ville Syrjälä authored
The downstream facing port caps in the DPCD can give us a hint as to what kind of display mode the sink can use if it doesn't have an EDID. Use that information to pick a suitable mode. v2: Use Returns: for kdoc (Lyude) Add kdocs for drm_display_mode_from_cea_vic() (Lyude) Signed-off-by: -
Ville Syrjälä authored
DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion. Let's use that to configure the "HDMI mode" (ie. infoframes vs. not) based on the capabilities of the sink. Signed-off-by:
-
Ville Syrjälä authored
Use the new helpers to extract the TMDS clock limits from the downstream facing port and check them in .mode_valid(). TODO: we should check these in .compute_config() too to eg. determine if we can do deep color on the HDMI side or not Signed-off-by:
-
Ville Syrjälä authored
Add helpers to get the TMDS clock limits for HDMI/DVI downstream facing ports. Signed-off-by:
-
Ville Syrjälä authored
Move the downstream facing port dotclock check into a new function (intel_dp_mode_valid_downstream()) so that we have a nice future place where we can collect other related checks. Signed-off-by:
-
Ville Syrjälä authored
We want to differentiate between the DFP dotclock and TMDS clock limits. Let's convert the current thing to just give us the dotclock limit. v2: Use Returns: for kdoc (Lyude) Fix up nouveau code too Signed-off-by: -
Ville Syrjälä authored
Deal with more cases in drm_dp_downstream_max_bpc(): - DPCD 1.0 -> assume 8bpc for non-DP - DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything - DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap - anything else -> assume 8bpc v2: Use Returns: for kdoc (Lyude) Signed-off-by:
-
Ville Syrjälä authored
Add a few helpers to let us better identify which kind of DFP we're dealing with. v2: Use Returns: for kdoc (Lyude) Signed-off-by:
-
Ville Syrjälä authored
Stash the downstream facing port max bpc away during intel_dp_set_edid(). We'll soon need the EDID in there so we can't figure this out so easily during .compute_config() anymore. Signed-off-by:
-
Ville Syrjälä authored
Our definitions for the DPCD DFP capabilities are lacking. Add the missing bits. Signed-off-by:
-
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:
-
- 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:
-
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:
-
