- 04 Nov, 2021 6 commits
-
-
Ville Syrjälä authored
Chop i9xx_plane_update() into two halves. Fist half becomes the _noarm() variant, second part the _arm() variant. Fortunately I have already previously grouped the register writes into roughtly the correct order, so the split looks surprisingly clean. One slightly surprising fact was that the CHV pipe B PRIMPOS/SIZE registers are self arming unlike their pre-ctg DSPPOS/SIZE counterparts. In fact all the new CHV pipe B registers are self arming. Also we must remind ourselves that i830/i845 are a bit borked in that all of their plane registers are self-arming. I didn't do any i915_update_info measurements for this one alone. I'll get total numbers with the corrsponding sprite plane changes. v2: Don't break my precious i830/i845 Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020212757.13517-1-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
Chop skl_program_plane() into two halves. Fist half becomes the _noarm() variant, second part the _arm() variant. Fortunately I have already previously grouped the register writes into roughtly the correct order, so the split looks surprisingly clean. A few notable oddities I did not realize were self arming are AUX_DIST and COLOR_CTL. i915_update_info doesn't look too terrible on my cfl running kms_atomic_transition --r plane-all-transition --extended: w/o patch w/ patch Updates: 2178 Updates: 2018 | | 1us | 1us | | | 4us | 4us |***** |********* |********** 16us |********** 16us |******* |*** | 66us | 66us | | | 262us | 262us | | | 1ms | 1ms | | | 4ms | 4ms | | | 17ms | 17ms | | | Min update: 8332ns Min update: 6164ns Max update: 48758ns Max update: 31808ns Average update: 19959ns Average update: 13159ns Overruns > 100us: 0 Overruns > 100us: 0 And with lockdep enabled: w/o patch w/ patch Updates: 2177 Updates: 2172 | | 1us | 1us | | | 4us | 4us | |******* |********* 16us |********** 16us |********** |******* |* 66us | 66us | | | 262us | 262us | | | 1ms | 1ms | | | 4ms | 4ms | | | 17ms | 17ms | | | Min update: 12645ns Min update: 9980ns Max update: 50153ns Max update: 33533ns Average update: 25337ns Average update: 18245ns Overruns > 250us: 0 Overruns > 250us: 0 TODO: On icl+ everything seems to be armed by PLANE_SURF, so we can optimize this even further on modern platforms. But I think there's a bit of refactoring to be done first to figure out the best way to go about it (eg. just reusing the current skl+ functions, or doing a lower level split). TODO: Split scaler programming as well, but IIRC the scaler has some oddball double buffering behaviour on some platforms, so needs proper reverse engineering Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: -
Ville Syrjälä authored
The amount of plane registers we have to write has been steadily increasing, putting more pressure on the vblank evasion mechanism and forcing us to increase its time budget. Let's try to take some of the pressure off by splitting plane updates into two parts: 1) write all non-self arming plane registers, ie. the registers where the write actually does nothing until a separate arming register is also written which will cause the hardware to latch the new register values at the next start of vblank 2) write all self arming plane registers, ie. registers which always just latch at the next start of vblank, and registers which also arm other registers to do so Here we just provide the mechanism, but don't actually implement the split on any platform yet. so everything stays now in the _arm() hooks. Subsequently we can move a whole bunch of stuff into the _noarm() part, especially in more modern platforms where the number of registers we have to write is also the greatest. On older platforms this is less beneficial probably, but no real reason to deviate from a common behaviour. And let's sprinkle some TODOs around the areas that will need adapting. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Give all sprite exclusive functions/etc. a proper namespace. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
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ä 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 3 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:
-
