summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_sprite.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Pass the plane to icl_program_input_csc_coeff()Ville Syrjälä2018-11-281-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | On icl+ the plane state that gets passed to update_slave() is not the plane state of the plane we're programming. With NV12 the plane state would be coming from the master (UV) plane whereas the plane we're programming is the slave (Y) plane. For that reason we need to explicitly pass around the slave plane (or we'd have to otherwise deduce it by checking whether we were called via .update_plane() or .update_slave()). In the case of icl_program_input_csc_coeff() it's actually OK to assume that we are always the master plane because the input CSC only exists on HDR planes which can never be a slave plane. But for consistency let's pass in the plane explicitly anyway. While at it drop the "_coeff" from the function name since it's kinda redundant, and this makes the name a bit shorter :) Cc: Uma Shankar <uma.shankar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-14-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
* drm/i915: Move ddb/wm programming into plane update/disable hooks on skl+Ville Syrjälä2018-11-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | On SKL+ the plane WM/BUF_CFG registers are a proper part of each plane's register set. That means accessing them will cancel any pending plane update, and we would need a PLANE_SURF register write to arm the wm/ddb change as well. To avoid all the problems with that let's just move the wm/ddb programming into the plane update/disable hooks. Now all plane registers get written in one (hopefully atomic) operation. To make that feasible we'll move the plane ddb tracking into the crtc state. Watermarks were already tracked there. v2: Rebase due to input CSC v3: Split out a bunch of junk (Matt) v4: Add skl_wm_add_affected_planes() to deal with cursor special case and non-zero wm register reset value v5: Drop the unrelated for_each_intel_plane_mask() fix (Matt) Remove the redundant ddb memset() (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v3 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181127165900.31298-1-ville.syrjala@linux.intel.com
* drm/i915: Pass the new crtc_state to ->disable_plane()Ville Syrjälä2018-11-281-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | We're going to need access to the new crtc state in ->disable_plane() for SKL+ wm/ddb programming and pre-skl pipe gamma/csc control. Pass the crtc state down. We'll also try to make intel_crtc_disable_planes() do the right thing as much as it's possible. The fact that we don't have a separate crtc state for the disabled state when we're going to re-enable the crtc later means we might end up poking at a few extra planes in there. But that's harmless. I suppose one might argue that we wouldn't have to care about proper ddb/wm/csc/gamma if the pipe is going to permanently disable anyway, but the state checker probably cares so we should try our best to make sure everything is programmed correctly even in that case. v2: Fix the commit message a bit (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-5-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* drm/i915: Move single buffered plane register writes to the endVille Syrjälä2018-11-281-2/+2
| | | | | | | | | | | | | | | The plane color correction registers are single buffered. So ideally we would write them at the start of vblank just after the double buffered plane registers have been latched. Since we have no convenient way to do that for now let's at least move the single buffered register writes to happen after the double buffered registers have been written. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-3-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* drm/i915: Reorganize plane register writes to make them more atomicVille Syrjälä2018-11-281-44/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some observations about the plane registers: - the control register will self-arm if the plane is not already enabled, thus we want to write it as close to (or ideally after) the surface register - tileoff/linoff/offset/aux_offset are self-arming as well so we want them close to the surface register as well - color keying registers we maybe self arming before SKL. Not 100% sure but we can try to keep them near to the surface register as well - chv pipe b csc register are double buffered but self arming so moving them down a bit - the rest should be mostly armed by the surface register so we can safely write them first, and to just for some consistency let's try to follow keep them in order based on the register offset None of this will have any effect of course unless the vblank evasion fails (which it still does sometimes). Another potential future benefit might be pulling the non-self armings registers outside the vblank evasion since they won't latch until the arming register has been written. This would make the critical section a bit lighter and thus less likely to exceed the deadline. v2: Rebase due to input CSC v3: Swap LINOFF/TILEOFF and KEYMSK/KEYMAX to actually follow the last rule above (Matt) Add a bit more rationale to the commit message (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-2-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* drm/i915: Fix plane allocation/free functionsMaarten Lankhorst2018-11-151-29/+0
| | | | | | | | | | | | | | | | | Use intel_plane_destroy_state in intel_plane_free to free the state. Also fix intel_plane_alloc() to use __drm_atomic_helper_plane_reset(), to get sane defaults from the atomic core. This is needed to get the correct alpha value and blend mode from the core, and any new default values added from new properties. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.") [mlankhorst: Update commit description to mention alpha blend support] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181113092804.13304-1-maarten.lankhorst@linux.intel.com
* drm/i915: Account for scale factor when calculating initial phaseVille Syrjälä2018-11-131-6/+14
| | | | | | | | | | | | | | | | | | | | To get the initial phase correct we need to account for the scale factor as well. I forgot this initially and was mostly looking at heavily upscaled content where the minor difference between -0.5 and the proper initial phase was not readily apparent. And let's toss in a comment that tries to explain the formula a little bit. v2: The initial phase upper limit is 1.5, not 24.0! Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 0a59952b24e2 ("drm/i915: Configure SKL+ scaler initial phase correctly") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181029181820.21956-1-ville.syrjala@linux.intel.com Tested-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
* drm/i915: Always write both TILEOFF and LINOFF plane registersVille Syrjälä2018-11-131-14/+7
| | | | | | | | | | | | | | | | | | | | Reduce the clutter in the sprite update functions by writing both TILEOFF and LINOFF registers unconditionally. We already did this for primary planes so might as well do it for the sprites too. There is no harm in writing both registers. Which one gets used depends on the tilimg mode selected in the plane control registers. It might even make sense to clear the register that won't get used. That could make register dumps a little easier to parse. But I'm not sure it's worth the extra hassle. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108150955.23948-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
* drm/i915: Clean up skl+ PLANE_POS vs. scaler handlingVille Syrjälä2018-11-091-7/+9
| | | | | | | | | | On skl+ the scaler (when enabled) will take care of the plane output position. Make the code less ugly by just setting crtc_x/y to 0 when the scaler is enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-6-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915: Polish the skl+ plane keyval/msk/max register setupVille Syrjälä2018-11-091-13/+9
| | | | | | | | | | | | | | Due to the constant alpha we're going to have to program two of the the tree keying registers anyway, so might as well always program all three. And parametrize the plane constant alpha define while at it. v2: Rebase due to input CSC Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107184138.31359-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915: Remove the PS_PWR_GATE write from skl_program_scaler()Ville Syrjälä2018-11-091-1/+0
| | | | | | | | | | If we don't need the PS_PWR_GATE write when programming the pipe scaler I don't see why we'd need it for plane scalers either. Just remove it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-4-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915: Clean up skl_program_scaler()Ville Syrjälä2018-11-071-13/+5
| | | | | | | | | | | Remove the "sizes are 0 based" stuff that is not even true for the scaler. v2: Rebase Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101151736.20522-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915: Nuke posting reads from plane update/disable funcsVille Syrjälä2018-11-071-12/+0
| | | | | | | | | | | No need for the posting reads in the plane update/disable hooks. If we need a posting read for something then a single one at the very end would be sufficient. We have that anyway in the form of eg. scanline/frame counter reads. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* drm/i915/icl: Enable Plane Input CSC for YUV to RGB ConversionUma Shankar2018-11-061-0/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Plane input CSC needs to be enabled to convert frambuffers from YUV to RGB. This is needed for bottom 3 planes on ICL, rest of the planes have hardcoded conversion and taken care by the legacy code. This patch defines the co-efficient values for YUV to RGB conversion in BT709 and BT601 formats. It programs the coefficients and enables the plane input csc unit in hardware. This has been verified and tested by Maarten and the change is working as expecpted. v2: Addressed Maarten's and Ville's review comments and added the coefficients in a 2D array instead of independent Macros. v3: Added individual coefficient matrix (9 values) instead of 6 register values as per Maarten's comment. Also addresed a shift issue with B channel coefficient. v4: Added support for Limited Range Color Handling v5: Fixed Matt and Maarten's review comments. v6: Added human readable matrix values for YUV to RGB Conversion along with just the bspec register values, as per Matt's suggestion. v7: Refactored the code, move csc coefficient programming function to intel_sprite.c and made it static as per Ville's review comment. v8: Addressed Ville's review comment. Called the coefficient programming from within the skl_program_plane and used I915_WRITE_FW instead of I915_WRITE. v9: Fixed Ville's review comments. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1541099420-12419-3-git-send-email-uma.shankar@intel.com
* drm/i915: Define WA 0870 and kill dead code.Rodrigo Vivi2018-11-011-0/+1
| | | | | | | | | | | | | | | | | | | Let's introduce the WA number that is the cause of having NV12 disabled on both SLK and BXT. According to Spec: WA 0870: "Display flickers with NV12 video playback in Y tiling mode. WA: Use YUV422 surface format instead of NV12." v2: remove the useless dead code and consequently avoiding device info flag. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181031162845.12419-3-rodrigo.vivi@intel.com
* drm/i915: Do not program aux plane offsets on gen11+Dhinakaran Pandiyan2018-10-291-3/+5
| | | | | | | | | | | The PLANE_AUX_OFFSET mmio does not exist on ICL, do not program it. We'll still calculate the aux offset as it is required for adjusing x-y offsets. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181026193805.11077-2-dhinakaran.pandiyan@intel.com
* drm/i915: Prefer IS_GEN<n> check with bitmask.Rodrigo Vivi2018-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever possible we should stick with IS_GEN<n> checks. Bitmaks has been introduced on commit ae7617f0ef18 ("drm/i915: Allow optimized platform checks") for efficiency. Let's stick with it whenever possible. This patch was generated with coccinelle: spatch -sp_file is_gen.cocci *{c,h} --in-place is_gen.cocci: @gen2@ expression e; @@ -INTEL_GEN(e) == 2 +IS_GEN2(e) @gen3@ expression e; @@ -INTEL_GEN(e) == 3 +IS_GEN3(e) @gen4@ expression e; @@ -INTEL_GEN(e) == 4 +IS_GEN4(e) @gen5@ expression e; @@ -INTEL_GEN(e) == 5 +IS_GEN5(e) @gen6@ expression e; @@ -INTEL_GEN(e) == 6 +IS_GEN6(e) @gen7@ expression e; @@ -INTEL_GEN(e) == 7 +IS_GEN7(e) @gen8@ expression e; @@ -INTEL_GEN(e) == 8 +IS_GEN8(e) @gen9@ expression e; @@ -INTEL_GEN(e) == 9 +IS_GEN9(e) @gen10@ expression e; @@ -INTEL_GEN(e) == 10 +IS_GEN10(e) @gen11@ expression e; @@ -INTEL_GEN(e) == 11 +IS_GEN11(e) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181026195143.20353-1-rodrigo.vivi@intel.com
* drm/i915: Mark skl_update_plane and skl_disable_plane as staticChris Wilson2018-10-241-2/+2
| | | | | | | | | | | | | | | | | make W=1 caught the implicit prototypes (as would sparse): drivers/gpu/drm/i915/intel_sprite.c:462:1: error: no previous prototype for ‘skl_update_plane’ [-Werror=missing-prototypes] skl_update_plane(struct intel_plane *plane, ^~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_sprite.c:487:1: error: no previous prototype for ‘skl_disable_plane’ [-Werror=missing-prototypes] skl_disable_plane(struct intel_plane *plane, struct intel_crtc *crtc) ^~~~~~~~~~~~~~~~~ Fixes: 1e364f9008a7 ("drm/i915/gen11: Program the Y and UV plane for planar mode correctly, v3.") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181024105402.18915-1-chris@chris-wilson.co.uk
* drm/i915/gen11: Expose planar format support on gen11, v2.Maarten Lankhorst2018-10-241-5/+1
| | | | | | | | | | | | Now that we implemented support for planar formats on gen11, we can finally advertise it. Changes since v1: - Re-add change to skl_plane_has_planar(), was lost in rebase noise. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181022134514.14756-1-maarten.lankhorst@linux.intel.com
* drm/i915/gen11: Program the Y and UV plane for planar mode correctly, v3.Maarten Lankhorst2018-10-241-9/+38
| | | | | | | | | | | | | | | | | The UV plane is the master plane that does all color correction etc. It needs to be programmed with the dimensions for color plane 1 (UV). The Y plane just feeds the Y pixels to it. Program the scaler from the master only, and set PLANE_CTL_YUV420_Y_PLANE on the slave plane. Changes since v1: - Make a common skl_program_plane, and use it for both plane updates. Changes since v2: - Make color_plane explicit, to clarify skl_update_plane(). (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181018115134.9061-8-maarten.lankhorst@linux.intel.com
* drm/i915/gen11: Program the chroma upsampler for HDR planes.Maarten Lankhorst2018-10-241-0/+22
| | | | | | | | | | We configure the chroma upsampler with the same chroma siting as used by the scaler for consistency, the chroma upsampler is used instead of the scaler for YUV 4:2:0 on ICL's HDR planes. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181018115134.9061-7-maarten.lankhorst@linux.intel.com
* drm/i915/gen11: Program the scalers correctly for planar formats, v3.Maarten Lankhorst2018-10-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The first 3 planes (primary, sprite 0 and 1) have a dedicated chroma upsampler to upscale YUV420 to YUV444 and the scaler should only be used for upscaling. Because of this we shouldn't program the scalers in planar mode if NV12 and the chroma upsampler are used. Instead program the scalers like on normal planes. Sprite 2 and 3 have no dedicated scaler, and need to program the selected Y plane in the scaler mode. Changes since v1: - Make the comment less confusing. Changes since v2: - Fix checkpatch warning (Matt) - gen10- -> Pre-gen11 (Ville) - PS_SCALER_MODE_PACKED -> PS_SCALER_MODE_NORMAL. (Matt) - Add comment about scaler mode in intel_atomic_setup_scaler(). (Matt) - Rename need_scaling to need_scaler. (Matt) - Move the crtc need_scaling check to skl_update_scaler_crtc(). Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181018115134.9061-6-maarten.lankhorst@linux.intel.com
* drm/i915: Move the SKL+ zero constant alpha handlingVille Syrjälä2018-10-231-0/+4
| | | | | | | | | | | Let's run through the entire plane check even when the plane is invisible due to zero constant alpha. This makes for more consistent behaviour since we check the src/dst coordinates, stride etc. against the hardware limits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181018195921.9898-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* drm/i915: Relocate SKL+ NV12 src width w/aVille Syrjälä2018-10-231-0/+21
| | | | | | | | | | | | | The SKL+ NV12 src width alignment w/a is still living in an odd place. Everything else was already relocated closer to the main plane check function. Move this workaround as well. As a bonus we avoid the funky rotated vs. not mess with the src coordinates as this now gets checked before we rotate the coordinates. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181018195921.9898-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* drm/i915: s/intel_plane/plane/ in sprite initVille Syrjälä2018-10-081-46/+45
| | | | | | | | | | | | | Use a more familiar naming pattern for our variables in the sprite plane init function. v2: Drop the redundant 'plane' from plane_formats and num_planes_formats too v3: Rebase due to ->max_stride() and ->check_plane() changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-11-ville.syrjala@linux.intel.com
* drm/i915: Extract skl_universal_plane_init()Ville Syrjälä2018-10-081-67/+150
| | | | | | | | | | | | | | | | | | | | | | | There's not much point in following the primary vs. sprite split for the SKL+ universal plane init code. The only difference is of our own doing in the form of the .check_plane(). Let's make a small exception for that little detail and otherwise share the same code to initialize all the universal planes. Eventually we should eliminate the mess around .check_plane() as well, but for now let's be happy with some code reduction. v2: Remember to set up plane->has_fbc Make skl_plane_has_ccs() static v3: Rebase due to NV12, rename some variables v4: Don't leave the color_encoding/range props behind v5: Rebase dur to blend properties, skl_plane_max_stride() and skl_plane_check() v6: Make skl_update_plane() static Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v4 Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-10-ville.syrjala@linux.intel.com
* drm/i915: Introduce intel_plane_alloc()Ville Syrjälä2018-10-081-16/+34
| | | | | | | | | | | Pull the common plane+plane_state allocation into a small helper. Reduces the amount of boilerplate in the plane initialization functions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-9-ville.syrjala@linux.intel.com
* drm/i915: Move plane_state->scaler_id initialization into ↵Ville Syrjälä2018-10-081-2/+0
| | | | | | | | | | | | | | | intel_create_plane_state() No point in having each caller of intel_create_plane_state() initialize the scaler_id to -1. Instead just do it in intel_create_plane_state(). Previously we left scaler_id at 0 for pre-SKL platforms, but I can't see how initializing it to -1 always would cause any harm. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-8-ville.syrjala@linux.intel.com
* drm/i915: Add missing pixel formats for skl+ "sprites"Ville Syrjälä2018-10-081-8/+14
| | | | | | | | | | | | | | All SKL+ universal planes support the same set of formats (with the exception of NV12 which we don't expose yet). Make the format lists for primary and sprites the same. And make the format list const while at it. v2: Deal with the "planar" format list as well Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-7-ville.syrjala@linux.intel.com
* drm/i915: Disallow plane scaling with specific pixel formatsVille Syrjälä2018-10-081-19/+28
| | | | | | | | | | | | | Plane scaling is not supported with specific pixel formats. Disallow plane scaling when such a format is used. Currently the only such pixel format we expose is C8, but in case we add more in the future let's make it easy to deal with them. v2: Redo due to plane_check() refactoring Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-6-ville.syrjala@linux.intel.com
* drm/i915: Allow horizontal mirroring for cnl+ "sprite" planesVille Syrjälä2018-10-081-1/+6
| | | | | | | | | | | | All CNL universal planes support horizontal mirroring. Currently we expose the capability only for the primary plane. Expose it for the overlay planes as well. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-5-ville.syrjala@linux.intel.com
* drm/i915: Don't populate plane->i9xx_plane for spritesVille Syrjälä2018-10-081-1/+0
| | | | | | | | | enum i9xx_plane_id namespace is not valid for any sprite plane, so let's not even populate plane->i9xx_plane. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-4-ville.syrjala@linux.intel.com
* drm/i915: Populate possible_crtcs for primary/cursor planesVille Syrjälä2018-10-081-1/+1
| | | | | | | | | | | | | | | | | We're currently not providing the possible_crtcs mask to drm_universal_plane_init() for primary/cursor planes. While that does work on account of drm_crtc_init_with_planes() filling those up for us, it's inconsisten with what we're doing for sprite planes. Let's just always pass the possible_crtcs bitmask to drm_universal_plane_init(). This does assume that crtc->index == pipe. But we're already making that assumption elsewhere so it doesn't seem like a very big sin here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181005125817.22576-3-ville.syrjala@linux.intel.com
* drm/i915: Add plane alpha blending support, v2.Maarten Lankhorst2018-10-021-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | Add plane alpha blending support with the different blend modes. This has been tested on a icl to show the correct results, on earlier platforms small rounding errors cause issues. But this already happens case with fully transparant or fully opaque RGB8888 fb's. The recommended HW workaround is to disable alpha blending when the plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending). This is easy to implement on any platform, so just do that. The tests for userspace are also available, and pass on gen11. Changes since v1: - Change mistaken < 0xff0 to 0xff00. - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend mode. - Rework disabling FBC when per pixel alpha is used. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mlankhorst: Change MISSING_CASE default to explicit alpha disable (mattrope)] Link: https://patchwork.freedesktop.org/patch/msgid/20180815103405.22679-1-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
* drm/i915: Check fb stride against plane max strideVille Syrjälä2018-09-251-0/+22
| | | | | | | | | | | | | | | | | | | | | | commit 4e0b83a567e2 ("drm/i915: Extract per-platform plane->check() functions") removed the plane max stride check for sprite planes. I was going to add it back when introducing GTT remapping for the display, but after further thought it seems better to re-introduce it separately. So let's add the max stride check back. And let's do it in a nicer form than what we had before and do it for all plane types (easy now that we have the ->max_stride() plane vfunc). Only sprite planes really need this for now since primary planes are capable of scanning out the current max fb size we allow, and cursors have more stringent stride checks elsewhere. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: 4e0b83a567e2 ("drm/i915: Extract per-platform plane->check() functions") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918140243.12207-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
* drm/i915: Enable RGB565 90/270 plane rotation for gen11 onwards.Juha-Pekka Heikkila2018-09-251-4/+10
| | | | | | | | | | | From gen11 onwards RGB565 90/270 plane rotation is supported on hardware. IGT: https://patchwork.freedesktop.org/series/48756/ Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Rebase on top of current dinq (self), fix grammar (Ville).] Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1535373473-3594-3-git-send-email-juhapekka.heikkila@gmail.com
* drm/i915: Force planar YUV coordinates to be a multiple of 2, v2.Maarten Lankhorst2018-09-211-1/+8
| | | | | | | | | | | | We can't make NV12 work any other way. The scaler doesn't handle odd coordinates well, and we will get visual corruption on the screen. Changes since v1: - Put the check in intel_plane_check_src_coordinates. (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-9-maarten.lankhorst@linux.intel.com
* drm/i915: Move programming plane scaler to its own function.Maarten Lankhorst2018-09-211-38/+52
| | | | | | | | This cleans the code up slightly, and will make other changes easier. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-8-maarten.lankhorst@linux.intel.com
* drm/i915: Fix logic fumble in rotation vs. ccs checkVille Syrjälä2018-09-181-2/+1
| | | | | | | | | | | | | | | | | Smatch reports: ../drivers/gpu/drm/i915/intel_sprite.c:1192 skl_plane_check_fb() warn: was || intended here instead of &&? Obviously smatch is correct here since we're trying to check if we're using either of the ccs modifiers. Since we now have is_ccs_modifier() let's use it to fix this. Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: José Roberto de Souza <jose.souza@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: e21c2d331018 ("drm/i915: Move skl plane fb related checks into a better place") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180918131059.793-1-ville.syrjala@linux.intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
* drm/i915: Move chv rotation checks to plane->check()Ville Syrjälä2018-09-121-0/+21
| | | | | | | | | | Move the chv rotation vs. reflections checks to the plane->check() hook, away from the (now) platform agnostic intel_plane_atomic_check_with_state(). Reviewed-by: 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/20180907152413.15761-13-ville.syrjala@linux.intel.com
* drm/i915: Move display w/a #1175Ville Syrjälä2018-09-121-1/+35
| | | | | | | | | | | Move the display w/a #1175 to a better place. That place being the new skl+ specific plane->check() hook. This leaves the skl_check_plane_surface() stuff to deal with the gtt offset and src coordinate stuff as originally envisioned. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-12-ville.syrjala@linux.intel.com
* drm/i915: Move skl plane fb related checks into a better placeVille Syrjälä2018-09-121-0/+66
| | | | | | | | | | | | | Move the skl+ specific framebuffer related checks from intel_plane_atomic_check_with_state() into a new function (skl_plane_check_fb()) which we'll simply call from the skl plane->check() hook. v2: Split out the Y/Yf+CCS vs. interlaced change (José) Reviewed-by: 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/20180907152413.15761-11-ville.syrjala@linux.intel.com
* drm/i915: Extract per-platform plane->check() functionsVille Syrjälä2018-09-121-112/+191
| | | | | | | | | | | | | | Split up intel_check_primary_plane() and intel_check_sprite_plane() into per-platform variants. This way we can get a unified behaviour between the SKL universal planes, and we stop checking for non-SKL specific scaling limits for the "sprite" planes. And we now get a natural place where to add more plarform specific checks. v2: Split the .check_plane() calling convention change out (José) Reviewed-by: 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/20180907152413.15761-10-ville.syrjala@linux.intel.com
* drm/i915: Nuke plane->can_scale/min_downscaleVille Syrjälä2018-09-121-26/+12
| | | | | | | | | | We can easily calculate the plane can_scale/min_downscale on demand. And later on we'll probably want to start calculating these dynamically based on the cdclk just as skl already does. Reviewed-by: 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/20180907152413.15761-9-ville.syrjala@linux.intel.com
* drm/i915: Store the final plane stride in plane_stateVille Syrjälä2018-09-121-6/+6
| | | | | | | | | | | | | | | | | | | | Let's store the final plane stride in the plane state. This avoids having to pick between the normal vs. rotated stride during hardware programming. And once we get GTT remapping the plane stride will no longer match the fb stride so we'll need a place to store it anyway. v2: Keep checking fb->pitches[0] for cursor as later on we won't populate plane_state->color_plane[0].stride for invisible planes and we have been checking the cursor fb stride even for invisible planes v3: s/betwen/between in commit msg (José) v4: Check color_plane[0].stride instead of fb->pitches[0] in the skl_check_main_surface() X-tiling kludge Reviewed-by: 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/20180911150139.23922-1-ville.syrjala@linux.intel.com
* drm/i915: Rename the plane_state->main/aux to plane_state->color_plane[]Ville Syrjälä2018-09-121-14/+15
| | | | | | | | | | Make the main/aux surface stuff a bit more generic by using an array of structures. This will allow us to deal with both the main and aux surfaces with common code. Reviewed-by: 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/20180907152413.15761-5-ville.syrjala@linux.intel.com
* drm/i915: Add .max_stride() plane hookVille Syrjälä2018-09-121-2/+32
| | | | | | | | | | | | | Each plane may have different stride limitations. Let's add a new plane function to retutn the maximum stride for each plane. There's going to be some use for this outside the .atomic_check() stuff hence the separate hook. v2: Fix ilk+ x-tiled max stride to be 32k (José) Reviewed-by: 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/20180907152413.15761-3-ville.syrjala@linux.intel.com
* drm/i915: Don't pass plane to .check_plane()Ville Syrjälä2018-08-281-2/+2
| | | | | | | | | | .check_plane() already gets the plane state, so we can dig out the plane from there if needed. No need in passing it separately. 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/20180828142707.31583-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
* drm/i915: Add a small wrapper to check for CCS modifiers.Dhinakaran Pandiyan2018-08-221-2/+1
| | | | | | | | | Code looks cleaner with modifiers hidden inside this wrapper. v2: Remove const qualifier (Ville) Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180822193827.6341-1-dhinakaran.pandiyan@intel.com
* drm/i915/psr: Print PSR_STATUS when PSR idle wait times out.Dhinakaran Pandiyan2018-08-211-2/+4
| | | | | | | | | | | Knowing the status of the PSR HW state machine is useful for debug, especially since we are seeing errors with PSR2 in CI. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-1-dhinakaran.pandiyan@intel.com
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-13 11:09:11 +0000