- 04 Nov, 2021 2 commits
-
-
Ville Syrjälä authored
We're currently forgetting to set the PLANE_SURF_DECRYPT flag in the async flip path. So if the hardware were to latch that bit despite this being an async flip we'd start scanning out garbage. And if it doesn't latch it then I guess we'd just end up with a weird register value that doesn't actually match the hardware state, which isn't great for anyone staring at register dumps. Similarly the async flip path also forgets to call skl_surf_address() which means the DPT address space to GGTT address space downshift is not being applied to the offset. Which means we are pointing PLANE_SURF at some random location in GGTT instead of the correct DPT page. So let's fix two birds with one stone and extract the PLANE_SURF calculation from skl_program_plane() into a small helper and use it in the async flip path as well. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Juston Li <juston.li@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Karthik B S <karthik.b.s@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-3-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Async flips are only capable of changing PLANE_SURF, hence we they can't easily be used with planar formats. Older platforms could require updating AUX_DIST as well, which is not possible. We'd have to make sure AUX_DIST doesn't change before allowing the async flip through. If we could get async flips with CCS then that might be interesting, but since the hw doesn't allow async flips with CCS I don't see much point in allowing this for planar formats either. No one renders their game content in YUV anyway. icl+ could in theory do this I suppose since each color plane has its own PLANE_SURF register, but I don't know if there is some magic to guarantee that both the Y and UV plane would async flip synchronously if you will. Ie. beyond just a clean tear we'd potentially get some kind of weird tear with some random mix of luma and chroma from the old and new frames. So let's just say no to async flips when scanning out planar formats. Cc: Karthik B S <karthik.b.s@intel.com> Signed-off-by:
-
- 03 Nov, 2021 12 commits
-
-
Ville Syrjälä authored
Streamline the code by using intel_de_rmw(). Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
Streamline the code by using intel_de_rmw(). Signed-off-by:
-
Ville Syrjälä authored
Streamline the code by using intel_de_rmw(). Signed-off-by:
-
Ville Syrjälä authored
Now that the link buf_trans, link training, and the combo/mg/dkl/snps phy programming are all fixed up we can allow per-lane DP drive settings on icl+. Make it so. Signed-off-by:
-
Ville Syrjälä authored
Prepare for per-lane drive settings by querying the desired vswing level per-lane. Signed-off-by:
-
Ville Syrjälä authored
Prepare for per-lane drive settings by querying the desired vswing level per-lane. Note that the code only does two loops, with each one writing the levels for two TX lanes. The register offsets also look a bit funny because each time through the loop we write to the exact same register offsets. The crucial bit is the HIP_INDEX_REG write that steers the same mmio window into different places. Signed-off-by:
-
Ville Syrjälä authored
Prepare for per-lane drive settings by querying the desired vswing level per-lane. Note that the code only does two loops, with each one writing the levels for two TX lanes. Signed-off-by:
-
Ville Syrjälä authored
Prepare for per-lane drive settings by querying the desired vswing level per-lane. Signed-off-by:
-
Ville Syrjälä authored
Program each TX lane individually so that we can start to use per-lane drive settings. Signed-off-by:
-
Javier Martinez Canillas authored
The comment mentions that the KMS is enabled by default unless either the i915.modeset module parameter or vga_text_mode_force boot option are used. But the latter does not exist and instead the nomodeset option was meant. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211103122809.1040754-2-javierm@redhat.com
-
Imre Deak authored
At least during hibernation the DPT mappings are lost with all stolen memory content, so suspend/resume these mappings similarly to GGTT mappings. This fixes a problem where the restoring modeset during system resume fails with pipe faults if a tiled framebuffer was active before suspend. v2: Clarify the way restore works in intel_dpt_resume()'s Docbook entry. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Vunny Sodhi <vunny.sodhi@intel.com> Reported-and-tested-by:Vunny Sodhi <vunny.sodhi@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Imre Deak authored
Factor out functions that are needed by the next patch to suspend/resume the memory mappings for DPT FBs. No functional change, except reordering during suspend the ggtt->invalidate(ggtt) call wrt. atomic_set(&ggtt->vm.open, open) and mutex_unlock(&ggtt->vm.mutex). This shouldn't matter due to the i915 suspend sequence being single threaded. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 02 Nov, 2021 8 commits
-
-
Imre Deak authored
As opposed to other GEN12 platforms ADLP provides a way to program the stride of CCS surfaces independently of the main surface stride (within the corresponding limit of the preceding and succeeding power-of-two values of the main surface stride). Using this HW feature we can remove the POT stride restriction on CCS surfaces, making the ADLP CCS FB uAPI (FB modifiers) identical to that of TGL. The HW makes the CCS stride flexible programming possible by deriving the stride from the value programmed to the PLANE_STRIDE register. After that the HW rounds up this value to the next power-of-two value and uses this for walking the pages of the main surface mapped to GTT/DPT. To align with the above scheme, introduce a scanout_stride view parameter which will be programmed to the PLANE_STRIDE register and use the mapping_stride view param to store the POT aligned value of the same. By requiring userspace to pass in FBs with a CCS stride that aligns with the main surface stride (matching the requirement of all GEN12 platforms), the scanout_stride will be the userspace main surface stride and the mapping_stride will be the POT rounded value of the same. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Nanley G Chery <nanley.g.chery@intel.com> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-8-imre.deak@intel.com
-
Imre Deak authored
Since the surfaces of tiled FBs on ADLP are remapped it's pointless to require an alignment in the allocated object. The necessary tile-row alignment (to be programmed to the surface start register) will be ensured later when flipping to the FB. Signed-off-by:
-
Imre Deak authored
The next patch needs to distinguish between a view's mapping and scanout stride. Rename the current stride parameter to mapping_stride with the script below. mapping_stride will keep the same meaning as stride had on all platforms so far, while the meaning of it will change on ADLP. No functional changes. @@ identifier intel_fb_view; identifier i915_color_plane_view; identifier color_plane; expression e; type T; @@ struct intel_fb_view { ... struct i915_color_plane_view { ... - T stride; + T mapping_stride; ... } color_plane[e]; ... }; @@ struct i915_color_plane_view pv; @@ pv. - stride + mapping_stride @@ struct i915_color_plane_view *pvp; @@ pvp-> - stride + mapping_stride Signed-off-by: -
Imre Deak authored
During remapping CCS FBs the CCS AUX surface mapped size and offset->x,y coordinate calculations assumed a tiled layout. This works as long as the CCS surface height is aligned to 64 lines (ensuring a 4k bytes CCS surface tile layout). However this alignment is not required by the HW (and the driver doesn't enforces it either). Add the remapping logic required to remap the pages of CCS surfaces without the above alignment, assuming the natural linear layout of the CCS surface (vs. tiled main surface layout). Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 3d1adc3d ("drm/i915/adlp: Add support for remapping CCS FBs") Signed-off-by:
-
Imre Deak authored
Factor out functions needed to map contiguous FB obj pages to a GTT/DPT VMA view in the next patch. While at it s/4096/I915_GTT_PAGE_SIZE/ in add_padding_pages(). No functional changes. v2: s/4096/I915_GTT_PAGE_SIZE/ (Matthew) Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Imre Deak authored
So far the remapped view size in GTT/DPT was padded to the next aligned offset unnecessarily after the last color plane with an unaligned size. Remove the unnecessary padding. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Fixes: 3d1adc3d ("drm/i915/adlp: Add support for remapping CCS FBs") Signed-off-by:
-
Imre Deak authored
For NV12 FBs with odd main surface tile-row height the CCS surface height was incorrectly calculated 1 less than the actual value. Fix this by rounding up the result of divison. For consistency do the same for the CCS surface width calculation. Fixes: b3e57bcc ("drm/i915/tgl: Gen-12 render decompression") Signed-off-by:
-
Kai Vehmanen authored
XE_LPD display adds support for display audio codec keepalive feature. This feature works also when display codec is in D3 state and the audio link is off (BCLK off). To enable this functionality, display driver must update the AUD_TS_CDCLK_M/N registers whenever CDCLK is changed. Actual timestamps are generated only when the audio codec driver specifically enables the KeepAlive (KAE) feature. This patch adds new hooks to intel_set_cdclk() in order to inform display audio driver when CDCLK change is started and when it is complete. Bspec: 53679 Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Acked-by:
-
- 01 Nov, 2021 4 commits
-
-
José Roberto de Souza authored
For every crtc in state, intel_atomic_check_async() was checking all the crtc and plane states again. v2: comparing pipe ids instead of crtc pointers when iterating over planes Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Looks like our VBIOS/GOP generally fail to turn the DP dual mode adater TMDS output buffers back on after a reboot. This leads to a black screen after reboot if we turned the TMDS output buffers off prior to reboot. And if i915 decides to do a fastboot the black screen will persist even after i915 takes over. Apparently this has been a problem ever since commit b2ccb822 ("drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed") if one rebooted while the display was turned off. And things became worse with commit fe0f1e3b ("drm/i915: Shut down displays gracefully on reboot") since now we always turn the display off before a reboot. This was reported on a RKL, but I confirmed the same behaviour on my SNB as well. So looks pretty universal. Let's fix this by explicitly turning the TMDS output buffers back on in the encoder->shutdown() hook. Note that this gets called after irqs have been disabled, so the i2c communication with the DP dual mode adapter has to be performed via polling (which the gmbus code is perfectly happy to do for us). We also need a bit of care in handling DDI encoders which may or may not be set up for HDMI output. Specifically ddc_pin will not be populated for a DP only DDI encoder, in which case we don't want to call intel_gmbus_get_adapter(). We can handle that by simply doing the dual mode adapter type check before calling intel_gmbus_get_adapter(). Cc: <stable@vger.kernel.org> # v5.11+ Fixes: fe0f1e3b ("drm/i915: Shut down displays gracefully on reboot") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4371Signed-off-by:
-
Ville Syrjälä authored
We will need to do some i2c poking from the encoder->shutdown() hook. Currently that gets called after irqs have been turned off. We still poll the gmbus status bits even if the interrupt never arrives so things will work just fine. But seems like asking gmbus to generate interrupts we will never see is a bit pointless, so don't. Signed-off-by:
-
Anusha Srivatsa authored
So far we had support for main, PipeA and PipeB DMC. If we find a binary from PipeA-D, lets load it. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
- 29 Oct, 2021 7 commits
-
-
José Roberto de Souza authored
New workaround added to specification, requiring bit 15 of GEN8_CHICKEN_DCPR_1 to be programed before power well 1 is enabled. BSpec: 54369 Signed-off-by:
-
Jouni Högander authored
This reverts commit 1f61f065. Now we are supporting selective fetch for biplanar formats. We can revert WA patch which forced using full fetch for biplanar formats. Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
Jouni Högander authored
Biplanar formats are using two planes (Y and UV). This patch adds handling of Y selective fetch area by utilizing existing linked plane mechanism. Also UV plane Y offset configuration is modified according to Bspec. Signed-off-by:
-
Imre Deak authored
By using the modifier plane capability flags to encode the modifiers' CCS type and tiling attributes, it becomes simpler to the check for any of these capabilities when providing the list of supported modifiers. This also allows distinguishing modifiers on future platforms where platforms with the same display version support different modifiers. An example is DG2 and ADLP, both being D13, where DG2 supports only F and X tiling, while ADLP supports only Y and X tiling. With the INTEL_PLANE_CAP_TILING_* flags added in this patch we can provide the correct modifiers for each platform. v2: - Define PLANE_HAS_* with macros instead of an enum. (Jani) - Rename PLANE_HAS_*_ANY to PLANE_HAS_*_MASK. (Jani) - Rename PLANE_HAS_* to INTEL_PLANE_CAP_*. - Set the CCS_RC_CC cap only for DISPLAY_VER >= 12. - Set the TILING_Y cap only for DISPLAY_VER < 13 || ADLP. - Simplify the SKL plane cap display version checks and move them to a separate function. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Variables of enum types can contain only the values listed at the enums definition, so don't store bitmasks in intel_plane_caps enum variables. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Remove the MC CCS plane capability on GEN<12, since it's not present there. This didn't cause a problem, since the display version check filtered out the MC CCS modifiers before GEN12. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Jani Nikula authored
Backmerge to get the DP 2.0 MST changes merged to drm-next. This also syncs us up to v5.15-rc7. Signed-off-by:
-
- 28 Oct, 2021 7 commits
-
-
Ville Syrjälä authored
Our lane power down defines already include the necessary shift, don't shift them a second time. Fortunately we masked off the correct bits, so we accidentally left all lanes powered up all the time. Bits 8-11 where we end up writing our misdirected lane mask are documented as MBZ, but looks like you can actually write there so they're not read only bits. No idea what side effect the bogus register write might have. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4151Signed-off-by:
-
Ville Syrjälä authored
Looks like we never updated intel_bios_is_port_dp_dual_mode() when the VBT port mapping became erratic on modern platforms. This is causing us to look up the wrong child device and thus throwing the heuristic off (ie. we might end looking at a child device for a genuine DP++ port when we were supposed to look at one for a native HDMI port). Fix it up by not using the outdated port_mapping[] in intel_bios_is_port_dp_dual_mode() and rely on intel_bios_encoder_data_lookup() instead. Cc: stable@vger.kernel.org Tested-by:
Randy Dunlap <rdunlap@infradead.org> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138Signed-off-by:
-
José Roberto de Souza authored
PSR2 is supported in transcoder A and B on Alderlake-P. v2: - explicity checking for transcoder A and B to avoid invalid transcoder BSpec: 49185 Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jouni Hogander <jouni.hogander@intel.com> Signed-off-by:
-
Jani Nikula authored
The PPS, RC_RANGE_PARAM, and RC_BUF_THRESH logging are clearly for debugging, and should not be info level messages. Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Laurent Pinchart authored
Add FourCCs for 10- and 12-bit red formats with padding to 16 bits. They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10 and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern permutations). These formats are not used by any kernel driver at this point, but need to be exposed to applications by libcamera, which uses DRM FourCCs for pixel formats. Signed-off-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027233140.12268-1-laurent.pinchart@ideasonboard.com
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
* eDP support in DP sub-driver (for newer SoCs with native eDP output) * dpu irq handling cleanup * CRC support for making igt happy * Support for NO_CONNECTOR bridges * dsi: 14nm phy support for msm8953 * mdp5: support for msm8x53, sdm450, sdm632 * various smaller fixes and cleanups Signed-off-by:
-
Dave Airlie authored
The msm next tree is based on rc3, so let's just backmerge rc7 before pulling it in. Signed-off-by:
-
