- 13 Jul, 2021 2 commits
-
-
José Roberto de Souza authored
This workaround is not needed for platforms with display 13. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-5-jose.souza@intel.com
-
José Roberto de Souza authored
Most of the places are using this format so lets consolidate it. v2: - split patch in two: display and non-display because of conflicts between drm-intel-gt-next x drm-intel-next Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-1-jose.souza@intel.com
-
- 11 Jul, 2021 1 commit
-
-
Kai-Heng Feng authored
On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX to discrete GFX after S3. This is not desirable, because userspace will treat connected display as a new one, losing display settings. The expected behavior is to let discrete GFX drives all external displays. The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX. The method is inside the another _DSM, so add the _DSM and call it accordingly. I also tested some MUX-less and iGPU only laptops with that _DSM, no regression was found. v4: - Rebase. - Change the DSM name to avoid confusion. - Move the function call to intel_opregion. v3: - Remove BXT from names. - Change the parameter type. - Fold the function into intel_modeset_init_hw(). v2: - Forward declare struct pci_dev. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113 References: https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.manna@intel.com/Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210520065832.614245-1-kai.heng.feng@canonical.com
-
- 09 Jul, 2021 4 commits
-
-
Lucas De Marchi authored
Besides the arch version returned by GRAPHICS_VER(), new platforms contain a "release id" to make clear the difference from one platform to another. The release id number is not formally defined by hardware until future platforms that will expose it via a new GMD_ID register. For the platforms we support before that register becomes available we will set the values in software and we can set them as we please. So the plan is to set them so we can group different features under a single GRAPHICS_VER_FULL() check. After GMD_ID is used, the usefulness of a "full version check" will be greatly reduced and will be mostly used for deciding workarounds and a few code paths. So it makes sense to keep it as a separate field from graphics_ver. Also, as a platform with `release == n` may be closer feature-wise to `n - 2` than to `n - 1`, use the word "release" rather than the more common "minor" for this This is a mix of 2 independent changes: one by me and the other by Matt Roper. v2: - Reword commit message to make it clearer why we don't call it "minor" (Matt Roper and Tvrtko) - Rename variables s/*_ver_release/*_rel/ and print them in a single line formatted as {ver}.{rel:2} (Jani and Matt Roper) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: -
Lucas De Marchi authored
Brevity is not needed here, so just spell out "* version" in the string. Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Clint Taylor authored
The PUNIT FW is currently returning 0 for all memory bandwidth parameters. Read the values directly from MCHBAR offsets 0x5918 and 0x4000(4). v2 (Lucas): tidy up checking for ret slightly v3 (Lucas): - Squash change to double the memory bandwidth based on MCHBAR Gear_type - Move ICL_GEAR_TYPE_MASK to the appropriate place and change prefix to DG1 - Move register definitions to i915_reg.h - Make the MCHBAR path permanent for DG1 - Convert to REG_BIT()/REG_GENMASK() v4: Drop unneeded initializations Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Saarinen <jani.saarinen@intel.com> Signed-off-by:Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Uma Shankar authored
On XELPD platforms, color management support is not yet enabled. Fix wrongly reporting the same through platform info, which was resulting in incorrect initialization and usage. Cc: Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Swati Sharma <swati2.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707095253.23848-1-uma.shankar@intel.com
-
- 08 Jul, 2021 2 commits
-
-
Matt Roper authored
The 'has_cdclk_crawl' field in our device info structure is a boolean flag and doesn't need a whole u8. Add it as another 1-bit feature flag and move it to the display section. While we're at it, replace the has_cdclk_crawl() function with a macro for consistency with our handling of other feature flags. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Jani Nikula authored
Add a small helper to keep intel_plane_helper_funcs static. Reviewed-by:
-
- 07 Jul, 2021 3 commits
-
-
Lucas De Marchi authored
Now that all the codebase is converted to the new *VER macros, remove the old GEN ones. Signed-off-by:
-
Lucas De Marchi authored
Commit 161058fb ("drm/i915: Add remaining conversions to GRAPHICS_VER") did the last conversions to the new macros for version checks, but left one instance behind and some other changes sneaked in to use INTEL_GEN. Remove the last users so we can remove the macros. Signed-off-by:
-
Anshuman Gupta authored
Earlier HDCP over MST support was added for TGL Platform. Extending it to all future platfroms. v2: - Remove the platform check and commit log changes. [Jani] Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
-
- 02 Jul, 2021 1 commit
-
-
Matthew Auld authored
If we hit the error path here we unconditionally call i915_gem_stolen_remove_node, even though we only allocate the compressed_llb on older platforms. Therefore we should first check that we actually allocated the node before trying to remove it. References: https://gitlab.freedesktop.org/drm/intel/-/issues/3709 Fixes: 46b2c40e ("drm/i915/fbc: Allocate llb before cfb") Signed-off-by:
-
- 01 Jul, 2021 2 commits
-
-
José Roberto de Souza authored
_DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one bit for phy C and D. Reusing _cnl_ddi_get_pll() don't take that into cosideration returing DPLL 0 and 1 for phy C and D. That is a regression introduced in the refactor done in commit 351221ff ("drm/i915: Move DDI clock readout to encoder->get_config()"). While at it also dropping the macros previously used, not reusing it to improve readability. BSpec: 50286 Fixes: 351221ff ("drm/i915: Move DDI clock readout to encoder->get_config()") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Bring drm-intel-next closer to drm-next and drm-intel-gt-next for a more feasible baseline for topic branches. Signed-off-by:
-
- 30 Jun, 2021 3 commits
-
-
Bhanuprakash Modem authored
While reading the SDP infoframe, we are getting filtered with the encoder type INTEL_OUTPUT_DDI which causes the infoframe mismatch. This patch will drop encoder->type check as we can mask individual infoframe type. [1025.606556] i915 0000:00:02.0: [drm] *ERROR* mismatch in drm infoframe [1025.607865] i915 0000:00:02.0: [drm] *ERROR* expected: [1025.607879] i915 0000:00:02.0: HDMI infoframe: Dynamic Range and Mastering, version 1, length 26 [1025.607889] i915 0000:00:02.0: length: 26 [1025.607898] i915 0000:00:02.0: metadata type: 0 [1025.608292] i915 0000:00:02.0: eotf: 2 [1025.608302] i915 0000:00:02.0: x[0]: 35400 [1025.608312] i915 0000:00:02.0: y[0]: 14599 [1025.609115] i915 0000:00:02.0: x[1]: 8500 [1025.609947] i915 0000:00:02.0: y[1]: 39850 [1025.609959] i915 0000:00:02.0: x[2]: 6550 [1025.609970] i915 0000:00:02.0: y[2]: 2300 [1025.609980] i915 0000:00:02.0: white point x: 15634 [1025.609989] i915 0000:00:02.0: white point y: 16450 [1025.610381] i915 0000:00:02.0: max_display_mastering_luminance: 1000 [1025.610392] i915 0000:00:02.0: min_display_mastering_luminance: 500 [1025.610401] i915 0000:00:02.0: max_cll: 500 [1025.610816] i915 0000:00:02.0: max_fall: 1000 [1025.612457] i915 0000:00:02.0: [drm] *ERROR* found: [1025.614354] ------------[ cut here ]------------ [1025.616244] pipe state doesn't match! [1025.617640] WARNING: CPU: 6 PID: 2114 at drivers/gpu/drm/i915/display/intel_display.c:9332 intel_atomic_commit_tail+0x14d4/0x17c0 [i915] V2: * Drop encoder->type check V3: * Remove internal reviews Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Bhanuprakash Modem <bhanuprakash.modem@intel.com> Reviewed-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2021-06-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next The biggest fix is the restoration of mmap ioctl for gen12 integrated parts which lack was breaking ADL-P with media stack. Besides that a small selftest fix and a theoretical overflow on i915->pipe_to_crtc_mapping. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YNtsfguvCRSROBUZ@intel.com
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2021-06-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Short summary of fixes pull: * amdgpu: Fix test for allocation failures Signed-off-by:
-
- 29 Jun, 2021 2 commits
-
-
Tejas Upadhyay authored
Removing force probe protection from EHL platform. Did not observe warnings, errors, flickering or any visual defects while doing ordinary tasks like browsing and editing documents in a two monitor setup. For more info drm-tip idle run results : https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html? Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Tejas Upadhyay authored
Removing force probe protection from JSL platform. Did not observe warnings, errors, flickering or any visual defects while doing ordinary tasks like browsing and editing documents in a two monitor setup. For more info drm-tip idle run results : https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html? Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 28 Jun, 2021 2 commits
-
-
Thomas Hellström authored
Reinstate the mmap ioctl for all current integrated platforms. The intention was really to have it disabled for discrete graphics where we enforce a single mmap mode. This was reported to break ADL-P with the media stack, which was not the intention. Although longer term we do still plan to sunset this ioctl even for integrated, in favour of using mmap_offset instead. Fixes: 35cbd91e ("drm/i915: Disable mmap ioctl for gen12+") Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Add a single point of truth for figuring out the primary/secondary crtc for bigjoiner instead of duplicating the magic pipe +/- 1 in multiple places. Also fix the pipe validity checks to properly take non-contiguous pipes into account. The current checks may theoretically overflow i915->pipe_to_crtc_mapping[pipe], albeit with a warning, due to fused off pipes, as INTEL_NUM_PIPES() returns the actual number of pipes on the platform, and the check is for INTEL_NUM_PIPES() == pipe + 1. Prefer primary/secondary terminology going forward. v2: - Improved abstractions for pipe validity etc. Fixes: 8a029c11 ("drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave") Fixes: d961eb20 ("drm/i915/bigjoiner: atomic commit changes for uncompressed joiner") Cc: Animesh Manna <animesh.manna@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Manasi Navare <manasi.dl.navare@intel.com> Signed-off-by:
-
- 25 Jun, 2021 2 commits
-
-
Lucas De Marchi authored
Since we are already loop through the levels to sanitize them, mark what is the real max_level so it can be used in subsequent loop. This makes it simpler to later add the adjustment latency to "valid levels". No change in behavior, just makes the code easier to follow. Signed-off-by:
-
Lucas De Marchi authored
We should no longer increment level 0 by 1usec when we have 16Gb DIMMs. Instead spec says to add 3usec (as opposed to 2) to each valid level when punit replies 0 to level 0. So set wm_lv_0_adjust_needed to false for DISPLAY_VER() >= 12 and set the proper adjustment value when handling WaWmMemoryReadLatency. Bspec: 49326, 4381 Signed-off-by:
-
- 24 Jun, 2021 16 commits
-
-
José Roberto de Souza authored
PSR2 is not compatible with DC3CO or VRR in this stepping, so not enabling PSR2 if VRR will be enabled or not enabling DC3CO if PSR2 is possible. BSpec: 54369 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210616203158.118111-5-jose.souza@intel.com
-
José Roberto de Souza authored
In some modes there is not enough time during hblank to transmit PSR2 SDP plus the pixels CRC SDP, if such case happens PSR2 needs to be disabled. But eDP spec 1.4b allows to transmit PSR2 SDP in a prior scanline alone and than later the CRC SDP, allowing PSR2 to be enabled in those hblank constrained modes. BSpec: 49274 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Another WA that is required for PSR2. BSpec: 54369 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
José Roberto de Souza authored
The PSR2_CTL io buffer wake and fast wake values do not match expected in pre production hardware, so here adding a table that matches with HW to program it with values that HW expect. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
We were only handling X and width granularity, what was causing issues when sink had a granularity different than 4. While at it, renaming su_x_granularity to su_w_granularity to better match reality. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Clear out the straggler 'intel_crtc' variables. Signed-off-by:
-
Ville Syrjälä authored
Sort out the mess with the local variables in intel_fbdev_init_bios(). Get rid of all aliasing pointers, use standard naming/types, and introduce a few more locals in the loops to avoid the hard to read long struct walks. While at we also polish the debugs a bit to use the canonical [CRTC:%d:%s] style. Signed-off-by:
-
Ville Syrjälä authored
Just pass the full atomic state+crtc to the pre-skl watermark functions, and clean up the types/variable names around the area. Note that having both .compute_pipe_wm() and .compute_intermediate_wm() is entirely redundant now. We could unify them to a single vfunc. But let's do this one step at a time. Signed-off-by:
-
Ville Syrjälä authored
Sort out the mess with the local variables in intel_find_initial_plane_obj(). Get rid of all aliasing pointers and use standard naming/types. Signed-off-by:
-
Ville Syrjälä authored
Sort out the mess with the local variables in intel_get_load_detect_pipe(). Get rid of all aliasing pointers and use standard naming/types. Signed-off-by:
-
Ville Syrjälä authored
Use drm_crtc_mask() instead of hand rolling it. Signed-off-by:
-
Ville Syrjälä authored
Since the llb allocation has a fixed size, let's grab it before the potentially variable sized cfb. That should avoid some allocation failure cases once we allow different compression ratios for FBC1. Signed-off-by:
-
Ville Syrjälä authored
Write the cfb allocation loop as an actual loop instead of some hard to read goto thing. Signed-off-by:
-
Ville Syrjälä authored
Declutter find_compression_limit() a bit by extracting intel_fbc_stolen_end(). Signed-off-by:
-
Ville Syrjälä authored
Exctract the limit->register value conversion into a common helper. Signed-off-by:
-
Ville Syrjälä authored
The limit++ for the 16bpp case is nonsense since the compression limit is always supposed to be power of two. Replace it with <<=1. Signed-off-by:
-
