Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31 |
|
#
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 (
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
show more ...
|
Revision tags: v6.1.30, v6.1.29 |
|
#
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 r
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
show more ...
|
Revision tags: v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78 |
|
#
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 ->
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
show more ...
|
Revision tags: v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64 |
|
#
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-struc
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
show more ...
|
Revision tags: v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56 |
|
#
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
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
show more ...
|
#
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
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
show more ...
|
Revision tags: v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47 |
|
#
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 cur
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>
show more ...
|
Revision tags: v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29 |
|
#
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ä
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>
show more ...
|
Revision tags: v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23 |
|
#
7ad9993b |
| 10-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
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>
show more ...
|
Revision tags: v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3 |
|
#
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
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>
show more ...
|
#
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é
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>
show more ...
|
#
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 do
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
show more ...
|
#
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 implement
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>
show more ...
|
#
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
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>
show more ...
|
Revision tags: v5.15.2, v5.15.1 |
|
#
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 eve
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>
show more ...
|
Revision tags: v5.15 |
|
#
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
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>
show more ...
|
Revision tags: v5.14.14 |
|
#
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 a
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>
show more ...
|
#
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_st
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
show more ...
|
#
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 che
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
show more ...
|
#
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 su
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
show more ...
|
Revision tags: v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39 |
|
#
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
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
show more ...
|
Revision tags: v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116 |
|
#
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 a
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
show more ...
|
Revision tags: v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25 |
|
#
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/pat
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>
show more ...
|
#
93e7e61e |
| 13-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
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
show more ...
|
#
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_
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
show more ...
|