summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_sprite.c
AgeCommit message (Collapse)Author
2019-04-08drm/i915: extract intel_sprite.h from intel_drv.hJani Nikula
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/679c857a1933ee3d0706f978ab05ca880cd30a00.1554461791.git.jani.nikula@intel.com
2019-04-08drm/i915: extract intel_atomic_plane.h from intel_drv.hJani Nikula
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: revert intel_plane_destroy_state() movement within intel_atomic_plane.c Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fd56c1cbba22b9f195ad944d79f7977423b2b533.1554461791.git.jani.nikula@intel.com
2019-04-08drm/i915: extract intel_pm.h from intel_drv.hJani Nikula
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: gen6_rps_reset_ei() is in i915_irq.c not intel_pm.c. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/adc6463b95eef3440fba9826793f7d1c5f3b0b4a.1554461791.git.jani.nikula@intel.com
2019-04-08drm/i915: extract intel_psr.h from intel_drv.hJani Nikula
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: Fix checkpatch whitespace complaint Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7e776690bf139ccdd0306b30df08dc68e74603de.1554461791.git.jani.nikula@intel.com
2019-03-27drm/i915: Reject rotation for some hdr formatsMaarten Lankhorst
90/270 rotation is not supported for Y21x and the 12/16 bits XVYU formats, reject support for them. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322135954.20434-3-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2019-03-27drm/i915: Reject Yf tiling for HDR formats, v2.Maarten Lankhorst
This was missing in the original addition of those formats, but in PLANE_SIZE description it's mentioned that 8 cpp formats are not valid with Yf tiling. Reject this case properly. Also reject Y21x Yf tiling support this is also not supported. Changes since v1: - Reject Y21x as well. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322135954.20434-2-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2019-03-27drm/i915: Handle YUV subpixel support betterMaarten Lankhorst
Y41x formats is a 4:4:4 format, so it can be addressed with pixel level accuracy. Meanwhile it seems that while rotating YUYV 4:2:2 formats need a multiple of 2 for width and height, otherwise corruption occurs. For YUV 4:2:2, the spec says that w/h should always be even, but we get away with odd height while unrotated. When rotating it seems corruption occurs with an odd x/y, and w/h should always be even. Just to be completely paranoid, reject odd x/y w/h when rotating 90/270. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322135954.20434-1-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2019-03-27Merge drm/drm-next into drm-intel-next-queuedJoonas Lahtinen
This is needed to get the fourcc code merged without conflicts. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2019-03-21drm/fourcc: Fix conflicting Y41x definitionsMaarten Lankhorst
There has unfortunately been a conflict with the following 3 commits: commit e9961ab95af81b8d29054361cd5f0c575102cf87 Author: Ayan Kumar Halder <ayan.halder@arm.com> Date: Fri Nov 9 17:21:12 2018 +0000 drm: Added a new format DRM_FORMAT_XVYU2101010 commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3 Author: Brian Starkey <brian.starkey@arm.com> Date: Fri Oct 5 10:27:00 2018 +0100 drm/fourcc: Add AFBC yuv fourccs for Mali and commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b Author: Swati Sharma <swati2.sharma@intel.com> Date: Mon Mar 4 17:26:33 2019 +0530 drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc Unfortunately gcc didn't warn about the redefinitions, because the double defines were the set to same value, and gcc apparently no longer warns about that. Fix this by using new XYVU for i915, without alpha, and making the Y41x definitions match msdn, with alpha. Fortunately we caught it early, and the conflict hasn't even landed in drm-next yet. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: malidp@foss.arm.com Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: Dave Airlie <airlied@linux.ie> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190319121702.6814-1-maarten.lankhorst@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc Acked-by: Sean Paul <sean@poorly.run> Reviewed-by: Ayan Kumar halder <ayan.halder@arm.com>
2019-03-19drm/i915: stick to kernel fixed size typesJani Nikula
We no longer allow mixed C99 and kernel types, and the preference is to use kernel types exclusively. Fix the C99 types that have crept in since the mass conversion. No functional changes. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Kevin Strasser <kevin.strasser@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20190318160019.9309-1-jani.nikula@intel.com
2019-03-18drm/i915: Turn off the CUS when turning off a HDR planeVille Syrjälä
We're currently leaving the CUS enabled if we disable the master plane directly after scanning out NV12. Could perhaps cause the selected slave plane to misbehave if we try to use it for scanning out something non-NV12? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190315195445.26527-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110032
2019-03-18Merge tag 'topic/hdr-formats-2019-03-13' of ↵Joonas Lahtinen
git://anongit.freedesktop.org/drm/drm-misc into drm-intel-next-queued Add support for floating point half-width formats. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/00b96cd5-91c7-5677-9620-b138c7a92303@linux.intel.com
2019-03-13drm/i915/icl: Implement half float formatsKevin Strasser
64 bpp half float formats are supported on hdr planes only and are subject to the following restrictions: * 90/270 rotation not supported * Yf Tiling not supported * Frame Buffer Compression not supported * Color Keying not supported v2: - Drop handling pixel normalize register - Don't use icl_is_hdr_plane too early v3: - Use refactored icl_is_hdr_plane (Ville) - Use u32 instead of uint32_t (Ville) v6: - Rebase and fix merge conflicts - Reorganize switch statements to keep RGB grouped separately from YUV Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kevin Strasser <kevin.strasser@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-4-git-send-email-kevin.strasser@intel.com
2019-03-13drm/i915: Refactor icl_is_hdr_planeKevin Strasser
Change the api in order to enable callers that can't supply a valid intel_plane pointer, as would be the case prior to calling drm_universal_plane_init. v4: - Rename variables and move a declaration (Ville) v6: - Rebase and fix merge conflict Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Kevin Strasser <kevin.strasser@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1552437513-22648-3-git-send-email-kevin.strasser@intel.com
2019-03-11Merge tag 'topic/hdr-formats-2019-03-07' of ↵Joonas Lahtinen
git://anongit.freedesktop.org/drm/drm-misc into drm-intel-next-queued Add support for Y21x and Y41x to drm core and i915, and P01x support to i915. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2485309-d645-bed4-95f4-e66ff312aa05@linux.intel.com
2019-03-05drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planesSwati Sharma
Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1551700595-21481-7-git-send-email-swati2.sharma@intel.com
2019-03-05drm/i915: Enable P010, P012, P016 formats for primary and sprite planesJuha-Pekka Heikkila
Enabling of P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1551700595-21481-4-git-send-email-swati2.sharma@intel.com
2019-03-05drm/i915: Preparations for enabling P010, P012, P016 formatsJuha-Pekka Heikkila
Preparations for enabling P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Swati Sharma <swati2.sharma@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1551700595-21481-3-git-send-email-swati2.sharma@intel.com
2019-02-08drm/i915: Track pipe csc enable in crtc stateVille Syrjälä
Just like we did for pipe gamma, let's also track the pipe csc state. The hardware only exists on ILK+, and currently we always enable it on hsw+ and never on any other platforms. Just like with pipe gamma, the primary plane control register is used for the readout on pre-SKL, and the pipe bottom color register on SKL+. v2: Rebase v3: Allow fastboot with csc_enable changes (Maarten) Deal with HAS_GMCH Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190207202146.26423-4-ville.syrjala@linux.intel.com
2019-02-08drm/i915: Track pipe gamma enable/disable in crtc stateVille Syrjälä
Track whether pipe gamma is enabled or disabled. For now we stick to the current behaviour of always enabling gamma. But we do get working state readout for this now. On SKL+ we use the pipe bottom color as our hardware state. On pre-SKL we read the state back from the primary plane control register. That only really correct for g4x+, as older platforms never gamma correct pipe bottom color. But doing the readout the same way on all platforms is fine, and there is no other way to do it really. v2: Initialize val at declaration (Uma) Drop the bogus skl scaler comment change (Uma) Rebase v3: Allow fastboot with gamma_enable changes (Maarten) v4: Drop the PIPE_BOTTOM_COLOR write from intel_update_pipe_config() again. It snuck back in during the rebase Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190207203913.5529-1-ville.syrjala@linux.intel.com
2019-02-07drm/i915: Split the gamma/csc enable bits from the plane_ctl() functionVille Syrjälä
On g4x+ the pipe gamma enable bit for the primary plane affects the pipe bottom color as well. The same for the pipe csc enable bit on ilk+. Thus we must configure those bits correctly even when the primary plane is disabled. To make the feasible let's split those settings from the plane_ctl() function into a seprate funciton that we can call from the ->disable_plane() hook as well. For consistency we'll do that on all the plane types. While that has no real benefits at this time, it'll become useful when we start to control the pipe gamma/csc enable bits dynamically when we overhaul the color management code. On pre-g4x there doesn't appear to be any way to gamma correct the pipe bottom color, but sticking to the same pattern doesn't hurt. And it'll still help us to do crtc state readout correctly for the pipe gamma enable bit for the color management overhaul. An alternative apporach would be to still precompute these bits into plane_state->ctl, but that would require that we run through the plane check even when the plane isn't logically enabled on any crtc. Currently that condition causes us to short circuit the entire thing and not call ->check_plane(). There would also be some chicken and egg problems with ->check_plane() vs. crtc color state check that would requite splitting certain things into multiple steps. So all in all this seems like the easier route. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190205160848.24662-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2019-01-29drm/i915: Fix skl srckey mask bitsVille Syrjälä
We're incorrectly masking off the R/V channel enable bit from KEYMSK. Fix it up. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125183846.28755-1-ville.syrjala@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2019-01-17drm/i915/sprite: switch to kernel typesJani Nikula
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/63fe4b9727b55727190e50e57427f513d204f000.1547629303.git.jani.nikula@intel.com
2019-01-14drm/i915: Markup paired operations on display power domainsChris Wilson
The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-16-chris@chris-wilson.co.uk
2019-01-09drm/i915: drop all drmP.h includesJani Nikula
Needs just a few additional includes here and there. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com
2018-12-12drm/i915: replace IS_GEN<N> with IS_GEN(..., N)Lucas De Marchi
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-11-28drm/i915: Pass the plane to icl_program_input_csc_coeff()Ville Syrjälä
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>
2018-11-28drm/i915: Move ddb/wm programming into plane update/disable hooks on skl+Ville Syrjälä
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
2018-11-28drm/i915: Pass the new crtc_state to ->disable_plane()Ville Syrjälä
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>
2018-11-28drm/i915: Move single buffered plane register writes to the endVille Syrjälä
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>
2018-11-28drm/i915: Reorganize plane register writes to make them more atomicVille Syrjälä
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>
2018-11-15drm/i915: Fix plane allocation/free functionsMaarten Lankhorst
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
2018-11-13drm/i915: Account for scale factor when calculating initial phaseVille Syrjälä
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
2018-11-13drm/i915: Always write both TILEOFF and LINOFF plane registersVille Syrjälä
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
2018-11-09drm/i915: Clean up skl+ PLANE_POS vs. scaler handlingVille Syrjälä
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>
2018-11-09drm/i915: Polish the skl+ plane keyval/msk/max register setupVille Syrjälä
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>
2018-11-09drm/i915: Remove the PS_PWR_GATE write from skl_program_scaler()Ville Syrjälä
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>
2018-11-07drm/i915: Clean up skl_program_scaler()Ville Syrjälä
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>
2018-11-07drm/i915: Nuke posting reads from plane update/disable funcsVille Syrjälä
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>
2018-11-06drm/i915/icl: Enable Plane Input CSC for YUV to RGB ConversionUma Shankar
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
2018-11-01drm/i915: Define WA 0870 and kill dead code.Rodrigo Vivi
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
2018-10-29drm/i915: Do not program aux plane offsets on gen11+Dhinakaran Pandiyan
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
2018-10-29drm/i915: Prefer IS_GEN<n> check with bitmask.Rodrigo Vivi
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
2018-10-24drm/i915: Mark skl_update_plane and skl_disable_plane as staticChris Wilson
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
2018-10-24drm/i915/gen11: Expose planar format support on gen11, v2.Maarten Lankhorst
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
2018-10-24drm/i915/gen11: Program the Y and UV plane for planar mode correctly, v3.Maarten Lankhorst
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
2018-10-24drm/i915/gen11: Program the chroma upsampler for HDR planes.Maarten Lankhorst
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
2018-10-24drm/i915/gen11: Program the scalers correctly for planar formats, v3.Maarten Lankhorst
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
2018-10-23drm/i915: Move the SKL+ zero constant alpha handlingVille Syrjälä
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>
2018-10-23drm/i915: Relocate SKL+ NV12 src width w/aVille Syrjälä
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>