- 11 May, 2021 7 commits
-
-
José Roberto de Souza authored
HSW_TVIDEO_DIP_CTL is read but not used. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210418002126.87882-4-jose.souza@intel.com
-
José Roberto de Souza authored
No functional changes in here. Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
José Roberto de Souza authored
All of this places don't need to intel_psr_enabled() that will lock psr mutex, check state and unlock. Instead it can directly check PSR state in intel_crtc_state, the only place that was not possible was intel_read_dp_vsc_sdp() but since "drm/i915/display: Fill PSR state during hardware configuration read out" it is possible. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
So far if we had a mismatch between the state asked and what was programmed in hardware for PSR, this mismatch would go unnoticed. So here adding the PSR to the hardware configuration readout, EDP_PSR_CTL and EDP_PSR2_CTL can't be directly read because its state flips due to other factors like frontbuffer modifications and CRC. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Werner Sembach authored
When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied from my commit message of the AMDGPU patch. On some setups, while the monitor and the gpu support display modes with pixel clocks of up to 600MHz, the link encoder might not. This prevents YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the link encoder capabilities are checked. This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. Signed-off-by:
Werner Sembach <wse@tuxedocomputers.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210510133349.14491-4-wse@tuxedocomputers.com
-
Werner Sembach authored
Couples the decission between RGB and YCbCr420 mode and the check if the port clock can archive the required frequency. Other checks and configuration steps that where previously done in between can also be done before or after. This allows for are cleaner implementation of retrying different color encodings. A slight change in behaviour occurs with this patch: If YCbCr420 is not allowed but display is YCbCr420 only it no longer fails, but just prints an error and tries to fallback on RGB. Signed-off-by:
-
Werner Sembach authored
Moves some checks that later will be performed 2 times to an own function. This avoids duplicate code later on. Signed-off-by:
-
- 10 May, 2021 4 commits
-
-
Lucas De Marchi authored
Instead of poluting the normal code path in intel_display.c, make intel_bios.c handle the brokenness of the VBT. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-5-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Direction on gen9+ was to stop reading the straps and only rely on the VBT for marking the port presence. This happened while dealing with WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the normal flow. See commit 885d3e5b ("drm/i915/display: fix comment on skl straps"). For gen 10 it's hard to say if this will work or not since I can't test it, so leave it with the same behavior as before. For PCH_TGP we should still rely on the VBT to make ports E and F not available. v2 (Ville): - use display ver >= 9 to make it consistent with the rest of the driver instead of checking for == 9 - also handle CNL and only initialize port F if it is IS_CNL_WITH_PORT_F. Eventually CNL may be removed, but while it isn't let's keep it consistent everywhere Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Direction on gen >= 9 was to stop using straps and rely on VBT indicating if the port is present or not. Remove FIXME comment since this will never be "fixed". Signed-off-by:
-
Lucas De Marchi authored
Since commit 45c0673a ("drm/i915/bios: start using the intel_bios_encoder_data directly") we lookup the devdata for each port in intel_ddi_init() and just return if the port is not present in VBT (or if we didn't create a fake devdata for it if VBT is not available). So in intel_display.c we don't have to check intel_bios_is_port_present(), just rely on the check in intel_ddi_init(). v2: Rebase on commit 45c0673a ("drm/i915/bios: start using the intel_bios_encoder_data directly") re-using that check in intel_ddi_init() instead of adding a new one. Signed-off-by:
-
- 07 May, 2021 12 commits
-
-
Imre Deak authored
Enable padding of DPT FB strides to POT, using the FB remapping logic. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
The specification only requires DPT FB strides to be POT aligned, but there seems to be also a minimum of 8 stride tile requirement. Scanning out FBs with < 8 stride tiles will result in pipe faults (even though the stride is POT aligned). Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-10-imre.deak@intel.com
-
Imre Deak authored
The latest specification removed the support for 90/270 FB rotation on ADL_P, even though legacy Y-tiled surfaces are supported. Align the code accordingly. Signed-off-by:
-
José Roberto de Souza authored
Alderlake-P have a new stride restriction when using DPT and it is used by non linear framebuffers. Stride needs to be a power of two to take full DPT rows, but stride is a parameter set by userspace. What we could do is use a fake stride when doing DPT allocation so HW requirements are met and userspace don't need to be changed to met this power of two restrictions but this change will take a while to be implemented so for now adding this restriction in driver to reject atomic commits that would cause visual corruptions. BSpec: 53393 Acked-by:
Matt Roper <matthew.d.roper@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-8-imre.deak@intel.com
-
Juha-Pekka Heikkilä authored
XE_LPD supports plane strides up to 128KB. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Signed-off-by:
-
José Roberto de Souza authored
GTT remapping allow us to have planes with strides larger than HW supports but DPT + GTT remapping is still not properly handled so falling back to plane HW limitations for now. This patch can be dropped when DPT + GTT remapping is correctly handled but until then we need this limitation for all display13 platforms to avoid pipe faults. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Suggested-by:
-
Ville Syrjälä authored
Add support for DPT (display page table). DPT is a slightly peculiar two level page table scheme used for tiled scanout buffers (linear uses direct ggtt mapping still). The plane surface address will point at a page in the DPT which holds the PTEs for 512 actual pages. Thus we require 1/512 of the ggttt address space compared to a direct ggtt mapping. We create a new DPT address space for each framebuffer and track two vmas (one for the DPT, another for the ggtt). TODO: - Is the i915_address_space approaach sane? - Maybe don't map the whole DPT to write the PTEs? - Deal with remapping/rotation? Need to create a separate DPT for each remapped/rotated plane I guess. Or else we'd need to make the per-fb DPT large enough to support potentially several remapped/rotated vmas. How large should that be? Signed-off-by:
Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Wilson Chris P <Chris.P.Wilson@intel.com> Cc: Tang CQ <cq.tang@intel.com> Cc: Auld Matthew <matthew.auld@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Wilson Chris P <Chris.P.Wilson@intel.com> Signed-off-by:
-
Clinton Taylor authored
Add ADL-P to the device_info table and support MACROS. Bspec: 49185, 55372, 55373 Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Clinton Taylor authored
Add 18 known PCI device IDs Bspec: 55376 Cc: Caz Yokoyama <caz.yokoyama@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Matt Roper authored
Let's start preparing for upcoming platforms that will use an XE_LPD design. v2: - Use the now-preferred "XE_LPD" term to refer to this design - Utilize DISPLAY_VER() rather than a feature flag - Drop unused mbus_size field (Lucas) v3: - Adjust for dbuf.{size,slice_mask} (Ville) Signed-off-by: -
Ville Syrjälä authored
When scanning out NV12 if we at any time have the plane enabled while the scaler is disabled we get a pretty catastrophic underrun. Let's reorder the operations so that we try to avoid that happening even if our vblank evade fails and the scaler enable/disable and the plane enable/disable get latched during two diffent frames. This takes care of the most common cases. I suppose there is still at least a theoretical possibility of hitting this if one plane takes the scaler away from another plane before the second plane had a chance to set up another scaler for its use. But that is starting to get a bit complicated, especially since the plane commit order already has to be carefully sequenced to avoid any dbuf overlaps. So plugging this 100% may prove somewhat hard... Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
I doubt anyone has used the display error state since CS flips went the way of the dodo. Just nuke it. It might be semi interesting to have something like this for FIFO underruns and the like, but as it stands this wouldn't provide a sufficient amount of information. So would need an extensive rewrite anyway. The lockless power well handling is also racy, so this could just be contributing noise to test results if we end up accessing something with the relevant power well already disabled. Signed-off-by:
-
- 06 May, 2021 1 commit
-
-
José Roberto de Souza authored
The implementation of two workarounds are missing causing failures in CI with pre-production HW. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210505213801.80772-1-jose.souza@intel.com
-
- 05 May, 2021 8 commits
-
-
Ville Syrjälä authored
Replace the hand rolled PLL lock bit waits with intel_de_wait_for_*(). Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled rmw sequences with intel_de_rmw(). Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled rmw sequences with intel_de_rmw(). Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled rmw sequences with intel_de_rmw(). Jani pointed out that intel_de_rmw() skips the write if the value does not change. That should be totally fine here, but let's at least acknowledge the change in behaviour in case I'm somehow wrong... Signed-off-by:
-
Ville Syrjälä authored
Extract a few of the switch statements into helper functions to reduce the pollution in the cdclk programming functions. Signed-off-by:
-
Ville Syrjälä authored
We lost the i915_reg_rw tracepoint for a lot of display registers when we switched from the heavyweight normal register accessors to the lightweight _fw() variants. See eg. commit dd584fc0 ("drm/i915: Use I915_READ_FW for plane updates"). Put the tracepoints back so that the register traces might actually be useful. Hopefully these should be close to free when the tracepoint is not enabled and thus not slow down our vblank critical sections significantly. v2: Copy paste the same-cacheline-hang warning from intel_uncore.h (Anshuman) Cc: Cooper Chiou <cooper.chiou@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Hoist the intel_de.h include from intel_display_types.h one level up. I need this in order to untangle the include order so that I can add tracepoints into intel_de.h. This little cocci script did most of the work for me: @find@ @@ ( intel_de_read(...) | intel_de_read_fw(...) | intel_de_write(...) | intel_de_write_fw(...) ) @has_include@ @@ ( #include "intel_de.h" | #include "display/intel_de.h" ) @depends on find && !has_include@ @@ + #include "intel_de.h" #include "intel_display_types.h" @depends on find && !has_include@ @@ + #include "display/intel_de.h" #include "display/intel_display_types.h" Cc: Cooper Chiou <cooper.chiou@intel.com> Reviewed-by:
-
Imre Deak authored
Make sure that the XYUV8888 format is handled correctly when it's used with a MC_CCS modifier framebuffer. Besides this format not working, the driver will also return an incorrect error value when trying to use it, indicating that the second color plane in the framebuffer is set unexpectedly. Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210501002853.4132009-1-imre.deak@intel.com
-
- 04 May, 2021 3 commits
-
-
Imre Deak authored
Make one step to pass intel_framebuffer to all intel_fb functions. Signed-off-by:
-
Jani Nikula authored
Cleanup the code. No functional changes. Reviewed-by:
-
Jani Nikula authored
Lift the masking outside of the if branches. No functional changes. Reviewed-by:
-
- 03 May, 2021 2 commits
-
-
Jani Nikula authored
Registering multiple backlight devices with intel_backlight name will obviously fail, regardless of whether they're two connectors in the same drm device or two different drm devices. It would be preferrable to switch to completely unique names, and sunset the generic intel_backlight name. However, there are apparently users out there that hardcode the name, so the change would break backward compatibility. As a compromise, register the first device with intel_backlight name. In the common case, this is the only backlight device anyway. From the second device on, use card%d-%s-backlight format, for example card0-eDP-2-backlight, to make the name unique. This approach does not preclude us from registering the first device using the same naming scheme in the future. v2: Keep using intel_backlight name for first backlight device Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2794Reviewed-by:
-
Jani Nikula authored
Add connector and backlight device name to logging, and propagate error code from backlight_device_register() instead of flattening to -ENODEV. Storing the name in an allocated buffer is unnecessary here, but makes follow-up work on names much cleaner. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 29 Apr, 2021 1 commit
-
-
Anand Moon authored
As per Bspec: 53655 Update PCI ids for Mobile BGA. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Anand Moon <anandx.ram.moon@intel.com> Reviewed-by:
Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
-
- 28 Apr, 2021 2 commits
-
-
Ville Syrjälä authored
Add some tracpoints for frontbuffer tracking so we can try to figure out what's going on. Signed-off-by:
-
Ville Syrjälä authored
The pipe crc code slipped theough the net when we tried to eliminate all crtc->index==pipe abuses. Remedy that. And while at it get rid of those nasty intel_crtc+drm_crtc pointer aliases. Signed-off-by:
-
