#
a8153627 |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Try to relocate the BIOS fb to the start of ggtt On MTL the GOP (for whatever reason) likes to bind its framebuffer high up in the ggtt address space. This can conflict with whatever ggtt_reserve_guc_top() is trying to do, and the result is that ggtt_reserve_guc_top() fails and then we proceed to explode when trying to tear down the driver. Thus far I haven't analyzed what causes the actual fireworks, but it's not super important as even if it didn't explode we'd still fail the driver load and the user would be left with an unusable GPU. To remedy this (without having to figure out exactly what ggtt_reserve_guc_top() is trying to achieve) we can attempt to relocate the BIOS framebuffer to a lower ggtt address. We can do this at this early point in driver init because nothing else is supposed to be clobbering the ggtt yet. So we simply change where in the ggtt we pin the vma, the original PTEs will be left as is, and the new PTEs will get written with the same dma addresses. The plane will keep on scanning out from the original PTEs until we are done with the whole process, and at that point we rewrite the plane's surface address register to point at the new ggtt address. Since we don't need a specific ggtt address for the plane (apart from needing it to land in the mappable region for normal stolen objects) we'll just try to pin it without a fixed offset first. It should end up at the lowest available address (which really should be 0 at this point in the driver init). If that fails we'll fall back to just pinning it exactly to the origianal address. To make sure we don't accidentlally pin it partially over the original ggtt range (as that would corrupt the original PTEs) we reserve the original range temporarily during this process. v2: Try to pin explicitly to ggtt offset 0 as otherwise DG2 puts it even higher (atm we have no PIN_LOW flag to force it low) v3: "fix" xe Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-16-ville.syrjala@linux.intel.com Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
#
c1464a89 |
|
30-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: add minimal i915_gem_object_frontbuffer.h Split out frontbuffer related declarations and static inlines from gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h. The main goal is to reduce header interdependencies. With gem/i915_gem_object.h including display/intel_frontbuffer.h, modification of the latter causes a whopping 300+ objects to be rebuilt, while many of the source files actually needing it aren't explicitly including it at all. After the change, only 21 objects depend on display/intel_frontbuffer.h, directly or indirectly. Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230830085127.2416842-1-jani.nikula@intel.com
|
#
47e157a5 |
|
26-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/plane: warn on non-zero plane offset We assume the plane offset is 0. Warn if it's not. This also fixes a warn on unused but set variable offset. v2: initialize offset on the gen2/3 path (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230526172218.1597394-1-jani.nikula@intel.com
|
#
2b874a02 |
|
15-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: split out display irq handling Split (non-hotplug) display irq handling out of i915_irq.[ch] into display/intel_display_irq.[ch]. v3: - Preserve [I915_MAX_PIPES] harder (kernel test robot) v2: - Rebase - Preserve [I915_MAX_PIPES] in functions (kernel test robot) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-3-jani.nikula@intel.com
|
#
801543b2 |
|
09-Nov-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: stop including i915_irq.h from i915_trace.h Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place. Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place. Also some places actually needed i915_irq.h too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
|
#
80b3842f |
|
29-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move fbc to display.fbc Move display FBC related members under drm_i915_private display sub-struct. Pointers and arrays of pointers to structs that we defined are fine without a sub-struct wrapping. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1151469ec13d392df86b72a375f490fd70a3257a.1661779055.git.jani.nikula@intel.com
|
#
cce32e4e |
|
20-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/atomic-helper: Remove _HELPER_ infix from DRM_PLANE_HELPER_NO_SCALING Rename DRM_PLANE_HELPER_NO_SCALING to DRM_PLANE_NO_SCALING. The constant is not really a helper, but rather a characteristic of the plane itself. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-4-tzimmermann@suse.de
|
#
382fc1f6 |
|
20-Jul-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/atomic-helper: Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers The macro DRM_PLANE_HELPER_NO_SCALING is only useful with the interfaces in drm_atomic_helper.h, but defined in drm_plane_helper.h. So half of DRM includes the latter header file for using this macro. Move the macro and remove the include statements. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220720083058.15371-3-tzimmermann@suse.de
|
#
90bb087f |
|
13-Jun-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Drop drm_blend.h from drm_crtc.h drm_crtc.h has no need for drm_blend.h, so don't include it. Avoids useless rebuilds of the entire universe when touching drm_blend.h. Quite a few placs do currently depend on drm_blend.h without actually including it directly. All of those need to be fixed up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613200317.11305-4-ville.syrjala@linux.intel.com Acked-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
7cfd1a18 |
|
15-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove remaining locks from i9xx plane udpates Now that fbc no longer nukes while a flip is pending we can remove the last uncore.lock from the i9xx plane code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
#
7ad9993b |
|
09-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make most pre-skl primary plane registers unlocked Drop the locks around most primary plane register writes. The lock isn't needed since each plane's register are neatly contained on their own cachelines. The one exception we have to make is DSPADDR/DSPSURF which is (ab)used to also trigger FBC nukes on pre-snb (since the hardware doesn't seem to have any dedicated mechanism to trigger nukes). So we need to keep the lock around it to protect against the rmw performed by the fbc code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210062403.18690-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
#
62236df2 |
|
12-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up PIPESRC defines Use REG_GENMASK() & co. when dealing with PIPESRC. Note that i9xx_get_initial_plane_config() will now use the full 16 bit mask whereas previously it used 12 bits only. But intel_get_pipe_src_size() already used the full 16 bits on all platforms anyway, so at least we're consistent now. The high bits beyond the max supported pipe source size should not be set in any case so this seems fine. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
428cb15d |
|
21-Jan-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up pre-skl primary plane registers Use REG_BIT() & co. for the pre-skl primary plane registers. Also give everything a consistent namespace. v2: s/DSP/DISP/ to avoid confusion (José) Use DISP_WIDTH rather than DISP_POS_X for DSPSIZE (José) Deal with gvt Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121113036.23240-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
c2a9682d |
|
13-Dec-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/fbc: Loop through FBC instances in various places Convert i915->fbc into an array in preparation for multiple FBC instances, and loop through all instances in all places where the caller does not know which instance(s) (if any) are relevant. This is the case for eg. frontbuffer tracking and FIFO underrun hadling. v2: More intel_ namespace (Jani) Leave out debugfs for later Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211213134450.3082-3-ville.syrjala@linux.intel.com
|
#
606754fd |
|
24-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/fbc: Allocate intel_fbc dynamically In the future we may have more than one FBC instance on some platforms. So let's just allocate it dynamically. This also lets us fully hide the implementation from prying eyes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-14-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
#
825bd833 |
|
24-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/fbc: Introduce intel_fbc_add_plane() In order to better encapsulate the FBC implementation introduce a small helper to do the plane<->FBC instance association. We'll also try to structure the plane init code such that introducing multiple FBC instances will be easier down the line. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-13-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
#
02689a20 |
|
04-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/1915/fbc: Replace plane->has_fbc with a pointer to the fbc instance With multiple fbc instances we need to find the right one for each plane. Rather than going looking for the right instance every time let's just replace the has_fbc boolean with a pointer that gets us there straight away. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-18-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
#
4d0d77de |
|
20-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split pre-skl primary plane update into noarm+arm pair 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.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
#
8ac80733 |
|
18-Oct-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split update_plane() into update_noarm() + update_arm() 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
#
be6c1dd5 |
|
26-Oct-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915/fb: Rename i915_color_plane_view::stride to mapping_stride 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 <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-6-imre.deak@intel.com
|
#
10a657dd |
|
27-Oct-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps 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 <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211027125150.2891371-1-imre.deak@intel.com
|
#
e2b83294 |
|
20-Oct-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add a table with a descriptor for all i915 modifiers Add a table describing all the framebuffer modifiers used by i915 at one place. This has the benefit of deduplicating the listing of supported modifiers for each platform and checking the support of these modifiers on a given plane. This also simplifies in a similar way getting some attribute for a modifier, for instance checking if the modifier is a CCS modifier type. While at it drop the cursor plane filtering from skl_plane_has_rc_ccs(), as the cursor plane is registered with DRM core elsewhere. v1: Unchanged. v2: - Keep the plane caps calculation in the plane code and pass an enum with these caps to intel_fb_get_modifiers(). (Ville) - Get the modifiers calling intel_fb_get_modifiers() in i9xx_plane.c as well. v3: - s/.id/.modifier/ (Ville) - Keep modifier_desc vs. plane_cap filter conditions consistent. (Ville) - Drop redundant cursor plane check from skl_plane_has_rc_ccs(). (Ville) - Use from, until display version fields in modifier_desc instead of a mask. (Jani) - Unexport struct intel_modifier_desc, separate its decl and init. (Jani) - Remove enum pipe, plane_id forward decls from intel_fb.h, which are not needed after v2. v4: - Reuse IS_DISPLAY_VER() instead of open-coding it. (Jani) - Preserve the current modifier order exposed to user space. (Ville) v5: Use }, { on one line to seperate the descriptor array elements. (Jani) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (v3) Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-2-imre.deak@intel.com
|
#
d372ba42 |
|
18-May-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/plane: add intel_plane_helper_add() helper Add a small helper to keep intel_plane_helper_funcs static. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210518132426.7567-1-jani.nikula@intel.com
|
#
7785ae0b |
|
30-Apr-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't include intel_de.h from intel_display_types.h 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: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com
|
#
661af379 |
|
18-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove stray newlines A bunch of files have a stray newline at the end. Remove it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318181039.17260-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
93e7e61e |
|
12-Apr-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/display: rename display version macros While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
|
#
61169987 |
|
27-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Unify the FB and plane state view information into one struct To allow the simplification of FB/plane view computation in the follow-up patches, unify the corresponding state in the intel_framebuffer and intel_plane_state structs into a new intel_fb_view struct. This adds some overhead to intel_framebuffer as the rotated view will have now space for 4 color planes instead of the required 2 and it'll also contain the unused offset for each color_plane info. Imo this is an acceptable trade-off to get a simplified way of the remap computation. Use the new intel_fb_view struct for the FB normal view as well, so (in the follow-up patches) we can remove the special casing for normal view calculation wrt. the calculation of remapped/rotated views. This also adds an overhead to the intel_framebuffer struct, as the gtt remap info and per-color plane offset/pitch is not required for the normal view, but imo this is an acceptable trade-off as above. The per-color plane pitch filed will be used by a follow-up patch, so we can retrieve the pitch for each view in the same way. No functional changes in this patch. v2: - Make the patch have _no functional change_. (fix skl_check_nv12_aux_surface() and skl_check_main_surface()). - s/i915_color_plane_view::pitch/stride/ (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-17-imre.deak@intel.com
|
#
3cee6269 |
|
25-Mar-2021 |
Imre Deak <imre.deak@intel.com> |
drm/i915/intel_fb: Pull FB plane functions from intel_display.c Move the FB plane specific functions from intel_display.c to intel_fb.c. There's more functions like this, but I leave moving those as well for a follow up, and for now moving only the ones needed by the end of this patchset (adding support for padding tile-rows in an FB GGTT view). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-11-imre.deak@intel.com
|
#
005e9537 |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate most usage of INTEL_GEN() Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN() in the display code to use DISPLAY_VER() comparisons instead. The following semantic patch was used: @@ expression dev_priv, E; @@ - INTEL_GEN(dev_priv) == E + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; @@ - INTEL_GEN(dev_priv) + DISPLAY_VER(dev_priv) @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_DISPLAY_RANGE(dev_priv, from, until) There are still some display-related uses of INTEL_GEN() in intel_pm.c (watermark code) and i915_irq.c. Those will be updated separately. v2: - Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
|
#
d47d29a6 |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Convert gen5/gen6 tests to IS_IRONLAKE/IS_SANDYBRIDGE ILK is the only platform that we consider "gen5" and SNB is the only platform we consider "gen6." Add an IS_SANDYBRIDGE() macro and then replace numeric platform tests for these two generations with direct platform tests with the following Coccinelle semantic patch: @@ expression dev_priv; @@ - IS_GEN(dev_priv, 5) + IS_IRONLAKE(dev_priv) @@ expression dev_priv; @@ - IS_GEN(dev_priv, 6) + IS_SANDYBRIDGE(dev_priv) @@ expression dev_priv; @@ - IS_GEN_RANGE(dev_priv, 5, 6) + IS_IRONLAKE(dev_priv) || IS_SANDYBRIDGE(dev_priv) This will simplify our upcoming patches which eliminate INTEL_GEN() usage in the display code. v2: - Reverse ilk/snb order for IS_GEN_RANGE conversion. (Ville) - Rebase + regenerate from semantic patch Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-2-matthew.d.roper@intel.com
|
#
59fb8218 |
|
08-Feb-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling ilk+ planes get notably unhappy when the plane x+w exceeds the stride. This wasn't a problem previously because we always aligned SURF to the closest tile boundary so the x offset never got particularly large. But now with async flips we have to align to 256KiB instead and thus this becomes a real issue. On ilk/snb/ivb it looks like the accesses just wrap early to the next tile row when scanout goes past the SURF+n*stride boundary, hsw/bdw suffer more heavily and start to underrun constantly. i965/g4x appear to be immune. vlv/chv I've not yet checked. Let's borrow another trick from the skl+ code and search backwards for a better SURF offset in the hopes of getting the x offset below the limit. IIRC when I ran into a similar issue on skl years ago it was causing the hardware to fall over pretty hard as well. And let's be consistent and include i965/g4x in the check as well, just in case I just got super lucky somehow when I wasn't able to reproduce the issue. Not that it really matters since we still use 4k SURF alignment for i965/g4x anyway. Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv") Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb") Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw") Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
2a301449 |
|
05-Feb-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: migrate i9xx plane get config Migrate this code out like the skylake code. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c003bd458a6bcc703e9e2fb05731fb7124012e8c.1612536383.git.jani.nikula@intel.com
|
#
46d12f91 |
|
05-Feb-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: migrate skl planes code new file (v5) Rework the plane init calls to do the gen test one level higher. Rework some of the plane helpers so they can live in new file, there is still some scope to clean up the plane/fb interactions later. v2: drop atomic code back, rename file to Ville suggestions, add header file. v3: move scaler bits back v4: drop wrong new includes (Ville) v5: integrate the ccs gen12 changes v6: fix unrelated code movement (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> [Jani: fixed up sparse warnings.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4e88a5c6b9ab3b93cc2b6c7d78c26ae86f6abbd0.1612536383.git.jani.nikula@intel.com
|
#
80cf9a88 |
|
08-Feb-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling ilk+ planes get notably unhappy when the plane x+w exceeds the stride. This wasn't a problem previously because we always aligned SURF to the closest tile boundary so the x offset never got particularly large. But now with async flips we have to align to 256KiB instead and thus this becomes a real issue. On ilk/snb/ivb it looks like the accesses just wrap early to the next tile row when scanout goes past the SURF+n*stride boundary, hsw/bdw suffer more heavily and start to underrun constantly. i965/g4x appear to be immune. vlv/chv I've not yet checked. Let's borrow another trick from the skl+ code and search backwards for a better SURF offset in the hopes of getting the x offset below the limit. IIRC when I ran into a similar issue on skl years ago it was causing the hardware to fall over pretty hard as well. And let's be consistent and include i965/g4x in the check as well, just in case I just got super lucky somehow when I wasn't able to reproduce the issue. Not that it really matters since we still use 4k SURF alignment for i965/g4x anyway. Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv") Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb") Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw") Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 59fb8218c8e5001f854e7d5fdb5fb135cba58102) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo also exported some functions from intel_display.c during backport]
|
#
6ede6b06 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flips for vlv/chv Add support for async flips on vlv/chv. Unlike all the other platforms vlv/chv do not use the async flip bit in DSPCNTR and instead we select between async vs. sync flips based on the surface address register. The normal DSPSURF generates sync flips DSPADDR_VLV generates async flips. And as usual the interrupt bits are different from the other platforms. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-12-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
4bb18054 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flip for ilk/snb Add support for async flips on ivb/hsw. Again no need for any workarounds and just have to deal with the interrupt bits being shuffled around a bit. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-11-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
2a636e24 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flip for ivb/hsw Add support for async flips on ivb/hsw. Unlike bdw+ we don't need any workarounds to disable async flips. Apart from that the only real difference from the bdw implementation is the location of the flip_done interrupt bits. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-10-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
cda195f1 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flips for bdw Implement async flip support for BDW. The implementation is similar to the skl+ code. And just like skl/bxt/glk bdw also needs the disable w/a, thus we need to plumb the desired state of the async flip all the way down to i9xx_plane_ctl_crtc(). According to the spec we do need to bump the surface alignment to 256KiB for this. Async flips require an X-tiled buffer so we don't have to worry about linear. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-9-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
cb807055 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Limit plane stride to below TILEOFF.x limit Limit pre-skl plane stride to below 4k or 8k pixels (depending on the platform). We do this in order guarantee that TILEOFF/OFFSET.x does not get too big. Currently this is not a problem as we align SURF to 4k, and so TILEOFF/OFFSET only have to deal with a single tile's worth of pixels. But for async flips we're going to have to bump SURF alignment to 256k, and thus we can no longer guarantee TILEOFF/OFFSET.x will stay within acceptable bounds. We can avoid this by borrowing a trick from the skl+ code and limit the max plane stride to whatever value we can fit into TILEOFF/OFFSET.x. The slight downside is that we may end up doing GTT remapping in a few more cases where previously we did not have to. But since that will only happen with huge buffers I'm not really concerned about it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-3-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
2aa0f4fa |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: WARN if plane src coords are too big Inform us if we're buggy and are about to exceed the size of the bitfields in the plane TILEOFF/OFFSET registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-2-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
00a16d02 |
|
21-Dec-2020 |
Dave Airlie <airlied@redhat.com> |
drm/i915: refactor i915 plane code into separate file. Ville suggested this as a good idea, let's move this before moving the crtc code. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [Jani: fixed i915xx_plane.h standalone build.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201221110957.18215-1-jani.nikula@intel.com
|