summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_sprite.c
AgeCommit message (Collapse)AuthorFilesLines
2018-03-14Merge tag 'drm-misc-next-2018-03-09-3' of ↵Dave Airlie1-25/+109
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 4.17: UAPI Changes: plane: Add color encoding/range properties (Jyri) nouveau: Replace iturbt_709 property with color_encoding property (Ville) Core Changes: atomic: Move plane clipping into plane check helper (Ville) property: Multiple new property checks/verification (Ville) Driver Changes: rockchip: Fixes & improvements for rk3399/chromebook plus (various) sun4i: Add H3/H5 HDMI support (Jernej) i915: Add support for limited/full-range ycbcr toggling (Ville) pl111: Add bandwidth checking/limiting (Linus) Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Jyri Sarha <jsarha@ti.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> * tag 'drm-misc-next-2018-03-09-3' of git://anongit.freedesktop.org/drm/drm-misc: (85 commits) drm/rockchip: Don't use atomic constructs for psr drm/rockchip: analogix_dp: set psr activate/deactivate when enable/disable bridge drm/rockchip: dw_hdmi: Move HDMI vpll clock enable to bind() drm/rockchip: inno_hdmi: reorder clk_disable_unprepare call in unbind drm/rockchip: inno_hdmi: Fix error handling path. drm/rockchip: dw-mipi-dsi: Fix connector and encoder cleanup. drm/nouveau: Replace the iturbt_709 prop with the standard COLOR_ENCODING prop drm/pl111: Use max memory bandwidth for resolution drm/bridge: sii902x: Retry status read after DDI I2C drm/pl111: Handle the RealView variant separately drm/pl111: Make the default BPP a per-variant variable drm: simple_kms_helper: Fix .mode_valid() documentation bridge: Elaborate a bit on dumb VGA bridges in Kconfig drm/atomic: Add new reverse iterator over all plane state (V2) drm: Reject bad property flag combinations drm: Make property flags u32 drm/uapi: Deprecate DRM_MODE_PROP_PENDING drm: WARN when trying to add enum value > 63 to a bitmask property drm: WARN when trying add enum values to non-enum/bitmask properties drm: Reject replacing property enum values ...
2018-03-02drm/i915: Add support for the YCbCr COLOR_RANGE propertyVille Syrjälä1-2/+10
Add support for the COLOR_RANGE property on planes. This property selects whether the input YCbCr data is to treated as limited range or full range. On most platforms this is a matter of setting the "YUV range correction disable" bit, and on VLV/CHV we'll just have to program the color correction logic to pass the data through unmodified. v2: Rebase Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-9-ville.syrjala@linux.intel.com
2018-03-02drm/i915: Change the COLOR_ENCODING prop default value to BT.709Ville Syrjälä1-1/+1
Bring us forward from the stone age and switch our default YCbCr->RGB conversion matrix to BT.709 from BT.601. I would expect most matrial to be BT.709 these days. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Acked-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-8-ville.syrjala@linux.intel.com
2018-03-02drm/i915: Add support for the YCbCr COLOR_ENCODING propertyVille Syrjälä1-15/+46
Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can generally handle BT.601 and BT.709. CHV pipe B sprites have a fully programmable matrix, so in theory we could handle anything, but it doesn't seem all that useful to expose anything beyond BT.601 and BT.709 at this time. GLK can supposedly do BT.2020, but let's leave enabling that for the future as well. v2: Rename bit defines to match the spec more closely (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-7-ville.syrjala@linux.intel.com
2018-03-02drm/i915: Fix plane YCbCr->RGB conversion for GLKVille Syrjälä1-5/+5
On GLK the plane CSC controls moved into the COLOR_CTL register. Update the code to progam the YCbCr->RGB CSC mode correctly when faced with an YCbCr framebuffer. The spec is rather confusing as it calls the mode "YUV601 to RGB709". I'm going to assume that just means it's going to use the YCbCr->RGB matrix as specified in BT.601 and doesn't actually change the gamut. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2018-03-02drm/i915: Correctly handle limited range YCbCr data on VLV/CHVVille Syrjälä1-18/+63
Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color correction registers (brightness, contrast, and saturation). On CHV pipe B we were actually doing the right thing already because we progammed the custom CSC matrix to do expect limited range input. Now that well pre-expand the data out with the color correction unit, we need to change the CSC matrix to operate with full range input instead. This should make the sprite output of the other pipes match the sprite output of pipe B reasonably well. Looking at the resulting pipe CRCs, there can be a slight difference in the output, but as I don't know the formula used by the fixed function CSC of the other pipes, I don't think it's worth the effort to try to match the output exactly. It might not even be possible due to difference in internal precision etc. One slight caveat here is that the color correction registers are single bufferred, so we should really be updating them during vblank, but we still don't have a mechanism for that, so just toss in another FIXME. v2: Rebase v3: s/bri/brightness/ s/con/contrast/ (Shashank) v4: Clarify the constants and math (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: "Tang, Jun" <jun.tang@intel.com> Reported-by: "Tang, Jun" <jun.tang@intel.com> Cc: stable@vger.kernel.org Fixes: 7f1f3851feb0 ("drm/i915: sprite support for ValleyView v4") Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-5-ville.syrjala@linux.intel.com
2018-03-01Merge tag 'drm-intel-next-2018-02-21' of ↵Dave Airlie1-2/+5
git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Lift alpha_support protection from Cannonlake (Rodrigo) * Meaning the driver should mostly work for the hardware we had at our disposal when testing * Used to be preliminary_hw_support - Add missing Cannonlake PCI device ID of 0x5A4C (Rodrigo) - Cannonlake port register fix (Mahesh) - Fix Dell Venue 8 Pro black screen after modeset (Hans) - Fix for always returning zero out-fence from execbuf (Daniele) - Fix HDMI audio when no no relevant video output is active (Jani) - Fix memleak of VBT data on driver_unload (Hans) - Fix for KASAN found locking issue (Maarten) - RCU barrier consolidation to improve igt/gem_sync/idle (Chris) - Optimizations to IRQ handlers (Chris) - vblank tracking improvements (64-bit resolution, PM) (Dhinakaran) - Pipe select bit corrections (Ville) - Reduce runtime computed device_info fields (Chris) - Tune down some WARN_ONs to GEM_BUG_ON now that CI has good coverage (Chris) - A bunch of kerneldoc warning fixes (Chris) * tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel: (113 commits) drm/i915: Update DRIVER_DATE to 20180221 drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning drm/i915: Move the policy for placement of the GGTT vma into the caller drm/i915: Also check view->type for a normal GGTT view drm/i915: Drop WaDoubleCursorLP3Latency:ivb drm/i915: Set the primary plane pipe select bits on gen4 drm/i915: Don't set cursor pipe select bits on g4x+ drm/i915: Assert that we don't overflow frontbuffer tracking bits drm/i915: Track number of pending freed objects drm/i915/: Initialise trans_min for skl_compute_transition_wm() drm/i915: Clear the in-use marker on execbuf failure drm/i915: Prune gen8_gt_irq_handler drm/i915: Track GT interrupt handling using the master iir drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use drm: intel_dpio_phy: fix kernel-doc comments at nested struct drm/i915: Release connector iterator on a digital port conflict. drm/i915/execlists: Remove too early assert drm/i915: Assert that we always complete a submission to guc/execlists drm: move read_domains and write_domain into i915 ...
2018-02-16Merge tag 'drm-misc-next-2018-02-13' of ↵Dave Airlie1-2/+6
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 4.17: UAPI Changes: - drm/vc4: Expose performance counters to userspace (Boris) Cross-subsystem Changes: - MAINTAINERS: Linus to maintain panel-arm-versatile in -misc (Linus) Core Changes: - Only use swiotlb when necessary (Chunming) Driver Changes: - drm/panel: Add support for ARM Versatile panels (Linus) - pl111: Improvements around versatile panel support (Linus) ---------------------------------------- Tagged on 2018-02-06: drm-misc-next for 4.17: UAPI Changes: - Validate mode flags + type (Ville) - Deprecate unused mode flags PIXMUX, BCAST (Ville) - Deprecate unused mode types BUILTIN, CRTC_C, CLOCK_C, DEFAULT (Ville) Cross-subsystem Changes: - MAINTAINERS: s/Daniel/Maarten/ for drm-misc (Daniel) Core Changes: - gem: Export gem functions for drivers to use (Samuel) - bridge: Introduce bridge timings in drm_bridge (Linus) - dma-buf: Allow exclusive fence to be bundled in fence array when calling reservation_object_get_fences_rcu (Christian) - dp: Add training pattern 4 and HBR3 support to dp helpers (Manasi) - fourcc: Add alpha bit to formats to avoid driver format LUTs (Maxime) - mode: Various cleanups + add new device-wide .mode_valid hook (Ville) - atomic: Fix state leak when non-blocking commits fail (Leo) NOTE: IIRC, this was cross-picked to -fixes so it might fall out - crc: Allow polling on the data fd (Maarten) Driver Changes: - bridge/vga-dac: Add THS8134* support (Linus) - tinydrm: Various MIPI DBI improvements/cleanups (Noralf) - bridge/dw-mipi-dsi: Cleanups + use create_packet helper (Brian) - drm/sun4i: Add Display Engine frontend support (Maxime) - drm/sun4i: Add zpos support + increase num planes from 2 to 4 (Maxime) - various: Use drm_mode_get_hv_timing() to fill plane clip rectangle (Ville) - stm: Add 8-bit clut support, add dsi phy v1.31 support, +fixes (Phillipe) Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Chunming Zhou <david1.zhou@amd.com> Cc: Samuel Li <Samuel.Li@amd.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Leo (Sunpeng) Li <sunpeng.li@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> * tag 'drm-misc-next-2018-02-13' of git://anongit.freedesktop.org/drm/drm-misc: (115 commits) drm/radeon: only enable swiotlb path when need v2 drm/amdgpu: only enable swiotlb alloc when need v2 drm: add func to get max iomem address v2 drm/vc4: Expose performance counters to userspace drm: Print the pid when debug logging an ioctl error. drm/stm: ltdc: remove non-alpha color formats on layer 2 for older hw drm/stm: ltdc: add non-alpha color formats drm/bridge/synopsys: dsi: Add 1.31 version support drm/bridge/synopsys: dsi: Add read feature drm/pl111: Support multiple endpoints on the CLCD drm/pl111: Support variants with broken VBLANK drm/pl111: Support variants with broken clock divider drm/pl111: Handle the Versatile RGB/BGR565 mode drm/pl111: Properly detect the ARM PL110 variants drm/panel: Add support for ARM Versatile panels drm/panel: Device tree bindings for ARM Versatile panels drm/bridge: Rename argument from crtc to bridge drm/crc: Add support for polling on the data fd. drm/sun4i: Use drm_mode_get_hv_timing() to populate plane clip rectangle drm/rcar-du: Use drm_mode_get_hv_timing() to populate plane clip rectangle ...
2018-02-09drm/i915: Give all ioctl functions an _ioctl suffixVille Syrjälä1-2/+2
Most of our ioctl functions have an _ioctl suffix in the name. I like that idea since it makes it easy to figure out how the function is going to get called. Rename the handful of exceptions to follow the same pattern. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180207164841.19431-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-02-09drm/i915: Reject undefined colorkey flagsVille Syrjälä1-0/+3
Check that userspace isn't passing in garbage in the colorkey ioctl flags. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180206204333.4399-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-02-05drm/i915: Deprecate I915_SET_COLORKEY_NONEVille Syrjälä1-1/+4
Deprecate the silly I915_SET_COLORKEY_NONE flag. The obvious way to disable colorkey is to just set flags to 0, which is exactly what the intel ddx has been doing all along. Currently when userspace sets the flags to 0, we end up in a funny state where colorkey is disabled, but various colorkey vs. scaling checks still consider colorkey to be enabled, and thus we don't allow plane scaling to kick in. In case there is some other userspace out there that actually uses this flag (unlikely as this is an i915 specific uapi) we'll keep on accepting it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202204231.27905-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-01-30drm/i915: Add display WA #1175 for planes ending close to right screen edgeImre Deak1-1/+1
As described in the WA on GLK and CNL planes on the right edge of the screen that have less than 4 pixels visible from the beginning of the plane to the edge of the screen can cause FIFO underflow and display corruption. On GLK/CNL I could trigger the problem only if the plane was at the same time also aligned to the top edge of the screen (after clipping) and there were exactly 2 pixels visible from the start of the plane to the right edge of the screen (so couldn't trigger it with 1 or 3 pixels visible). Nevertheless, to be sure, I also applied the WA for these cases. I also couldn't see any problem with the cursor plane and later Art confirmed that it's not affected, so the WA is applied only for the other plane types. v2: - Use -ERANGE instead of -EINVAL. (Chris) 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/20180116112415.22060-1-imre.deak@intel.com
2018-01-24drm/i915: Use enum plane_id for frontbuffer trackingVille Syrjälä1-1/+1
Replace the ad-hoc plane indexing scheme used by the frontbuffer tracking with enum plane_id. The old video overlay not being part of the plane_id namespace will just be given the high bit. v2: Drop the unintended whitespace change (Chris) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180123183343.9181-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-01-23drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä1-2/+6
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. No functional changes since pipe_src_w/h are already filled via drm_mode_get_hv_timing(). Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-3-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Thierry Reding <treding@nvidia.com>
2018-01-19drm/i915: Allow up to 32KB stride on SKL+ "sprites"Ville Syrjälä1-1/+2
SKL+ "sprites" no longer have 16KB max stride limit that earlier platforms had. Bump up the limit to 32KB. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171222192231.17981-7-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-01-19drm/i915: Add CCS capability for spritesVille Syrjälä1-13/+37
Allow sprites to scan out compressed framebuffers. Since different platforms have a different set of planes that support CCS let's add a small helper to determine whether a specific plane supports CCS or not. Currently that information is spread around in many places, and not all the pieces of code even agree with each other. In addition to allowing sprites to scan out compressed fbs, the other fix here is that we stop rejecting them on pipe C on CNL. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171222192231.17981-6-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2018-01-19drm/i915: Clean up the sprite modifier checksVille Syrjälä1-19/+29
Split the g4x and snb cases into separate functions to match how we deal with all other platforms. Also sort the switch cases to match the format lists we've declared earlier, to ease comparisons. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171222192231.17981-5-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-01-19drm/i915: Add the missing Y/Yf modifiers for SKL+ spritesVille Syrjälä1-0/+2
Y/Yf were dropped out from the SKL+ sprite modifier list on account of some watermark issues Daniel Stone was having. My subsequent testing seemed to indicate that things work better now, so add the modifiers back in. v2: Update the commit message with a better explanation Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Stone <daniels@collabora.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171222192231.17981-4-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-11-21drm/i915: s/enum plane/enum i9xx_plane_id/Ville Syrjälä1-1/+1
Rename enum plane to enum i9xx_plane_id to make it clear that it only applies to pre-SKL platforms. enum i9xx_plane_id is a global identifier, whereas enum plane_id is per-pipe. We need the old global identifier to index the primary plane (and the pre-g4x sprite C if we ever expose it) registers on pre-SKL platforms. v2: Reorder patches v3: s/old_plane_id/i9xx_plane_id/ (Daniel) Pimp the commit message a bit Note that i9xx_plane_id doesn't apply to SKL+ v4: Rebase due to power domain handling in plane readout v5: Rebase due to crtc->dspaddr_offset removal v6: s/plane/i9xx_plane/ etc. (James) Cc: James Ausmus <james.ausmus@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-4-ville.syrjala@linux.intel.com Reviewed-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-11-21drm/i915: Add .get_hw_state() method for planesVille Syrjälä1-0/+83
Add a .get_hw_state() method for planes, returning true or false depending on whether the plane is enabled. Use it to rewrite the plane enabled/disabled asserts in platform agnostic fashion. We do lose the pre-gen4 plane<->pipe mapping checks, but since we're supposed sanitize that anyway it doesn't really matter. v2: Reoder patches to not depend on enum old_plane_id Just call assert_plane_disabled() from assert_planes_disabled() v3: Deal with disabled power wells in .get_hw_state() v4: Rebase due skl primary plane code removal Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Alex Villacís Lasso <alexvillacislasso@hotmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v2 Tested-by: Thierry Reding <thierry.reding@gmail.com> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-2-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-11-14drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+James Ausmus1-6/+5
Since GLK, some plane configuration settings have moved to the PLANE_COLOR_CTL register. Refactor handling of the register to work like PLANE_CTL. This also allows us to fix the set/read of the plane Alpha Mode for GLK+. v2: Adjust ordering of platform checks to be newest->oldest, drop redundant comment about alpha blending. (Ville) v3: Move Alpha Mode bits out of skl_plane_ctl_format into skl_plane_ctl_alpha, and drop glk_plane_ctl_format, drop initialization of state->color_ctl on platforms that don't use it, and drop color_ctl local var. (Ville) v4: Consolidate skl_plane_ctl_format switch statement on formats that return the same settings. (Ville) Signed-off-by: James Ausmus <james.ausmus@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171113181128.2926-1-james.ausmus@intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-10-18drm/i915: Unify skylake plane disableJuha-Pekka Heikkila1-1/+1
Don't handle skylake primary plane separately as it is similar plane as the others. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1508270891-22186-5-git-send-email-juhapekka.heikkila@gmail.com
2017-10-18drm/i915: Unify skylake plane updateJuha-Pekka Heikkila1-1/+1
Don't handle skylake primary plane separately as it is similar plane as the others. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1508270891-22186-4-git-send-email-juhapekka.heikkila@gmail.com
2017-10-18Merge drm-upstream/drm-next into drm-intel-next-queuedJani Nikula1-1/+1
Needed for timer_setup() and drm_dev_{get,put}() conversions in i915. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-10-12drm: Pass struct drm_file * to __drm_mode_object_find [v2]Keith Packard1-1/+1
This will allow __drm_mode_object_file to be extended to perform access control checks based on the file in use. v2: Also fix up vboxvideo driver in staging [airlied: merging early as this is an API change] Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-10-10drm/i915: Increase atomic update vblank evasion time with lockdepDaniel Vetter1-0/+6
All our mmio writes take forever with lockdep due to the constant lock acquire&dropping we do. Ville has some patches to only acquire the mmio spinlocks once instead for every single mmio, but those aren't ready yet. As an interim solution just extend our budget slightly when lockdep is enabled, to avoid the rare and sporadic noise in CI. v2: I forgot to add the FIXME comment ... Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=103169 References: https://bugs.freedesktop.org/show_bug.cgi?id=103124 References: https://bugs.freedesktop.org/show_bug.cgi?id=102403 References: https://bugs.freedesktop.org/show_bug.cgi?id=103020 References: https://bugs.freedesktop.org/show_bug.cgi?id=103019 References: https://bugs.freedesktop.org/show_bug.cgi?id=102723 References: https://bugs.freedesktop.org/show_bug.cgi?id=102544 References: https://bugs.freedesktop.org/show_bug.cgi?id=103180 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171010091816.26898-1-daniel.vetter@ffwll.ch
2017-08-31drm/i915: Pass the crtc state explicitly to intel_pipe_update_start/end()Ville Syrjälä1-14/+13
Pass the appropriate new crtc state explicitly to intel_pipe_update_start/end() instead of of mucking around with crtc->state. v2: The mmio flip stuff is gone Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-2-ville.syrjala@linux.intel.com
2017-08-11drm/i915: make structure intel_sprite_plane_funcs staticColin Ian King1-1/+1
The structure intel_sprite_plane_funcs is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: symbol 'intel_sprite_plane_funcs' was not declared. Should it be static? Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170811134938.4183-1-colin.king@canonical.com
2017-08-10drm/i915: Add format modifiers for IntelBen Widawsky1-5/+145
This was based on a patch originally by Kristian. It has been modified pretty heavily to use the new callbacks from the previous patch. v2: - Add LINEAR and Yf modifiers to list (Ville) - Combine i8xx and i965 into one list of formats (Ville) - Allow 1010102 formats for Y/Yf tiled (Ville) v3: - Handle cursor formats (Ville) - Put handling for LINEAR in the mod_support functions (Ville) v4: - List each modifier explicitly in supported modifiers (Ville) - Handle the CURSOR plane (Ville) v5: - Split out cursor and sprite handling (Ville) v6: - Actually use the sprite funcs (Emil) - Use unreachable (Emil) v7: - Only allow Intel modifiers and LINEAR (Ben) v8 - Fix spite assert introduced in v6 (Daniel) v9 - Change vendor check logic to avoid magic 56 (Emil) - Reorder skl_mod_support (Ville) - make intel_plane_funcs static, could be done as of v5 (Ville) - rename local variable intel_format_modifiers to modifiers (Ville) - actually use sprite modifiers - split out modifier/formats by platform (Ville) v10: - Undo vendor check from v9 v11: - Squash CCS advertisement into this patch (daniels) - Don't advertise CCS on higher sprite planes (daniels) v12: - Don't advertise Y-tiled or CCS on any sprite planes, since we don't allocate enough DDB space for it to work. (daniels) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (v8) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-08-10drm/i915: Add render decompression supportVille Syrjälä1-0/+5
SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main surface are compressed and which are not. The location of CCS is provided by userspace as just another plane with its own offset. Add the required stuff to validate the user provided AUX plane metadata and convert the user provided linear offset into something the hardware can consume. Due to hardware limitations we require that the main surface and the AUX surface (CCS) be part of the same bo. The hardware also makes life hard by not allowing you to provide separate x/y offsets for the main and AUX surfaces (excpet with NV12), so finding suitable offsets for both requires a bit of work. Assuming we still want keep playing tricks with the offsets. I've just gone with a dumb "search backward for suitable offsets" approach, which is far from optimal, but it works. Also not all planes will be capable of scanning out compressed surfaces, and eg. 90/270 degree rotation is not supported in combination with decompression either. This patch may contain work from at least the following people: * Vandana Kannan <vandana.kannan@intel.com> * Daniel Vetter <daniel@ffwll.ch> * Ben Widawsky <ben@bwidawsk.net> v2: Deal with display workarounds 0390, 0531, 1125 (Paulo) v3: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason) Put the AUX register defines to the correct place Fix up the slightly bogus rotation check v4: Use I915_WRITE_FW() due to plane update locking changes s/return -EINVAL/goto err/ in intel_framebuffer_init() Eliminate a bunch hardcoded numbers in CCS code v5: (By Ben) conflict resolution + - res_blocks += fixed_16_16_to_u32_round_up(y_tile_minimum); + res_blocks += fixed16_to_u32_round_up(y_tile_minimum); v6: (daniels) Fix botched commit message. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Ville Syrjä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Stone <daniels@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170801165817.7063-1-ben@bwidawsk.net
2017-08-10Merge airlied/drm-next into drm-intel-next-queuedDaniel Vetter1-2/+2
Ben Widawsky/Daniel Stone need the extended modifier support from drm-misc to be able to merge CCS support for i915.ko Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-08-01drm: Plumb modifiers through plane initBen Widawsky1-2/+2
This is the plumbing for supporting fb modifiers on planes. Modifiers have already been introduced to some extent, but this series will extend this to allow querying modifiers per plane. Based on this, the client to enable optimal modifications for framebuffers. This patch simply allows the DRM drivers to initialize their list of supported modifiers upon initializing the plane. v2: A minor addition from Daniel v3: * Updated commit message * s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu) * Remove some excess newlines (Liviu) * Update comment for > 64 modifiers (Liviu) v4: Minor comment adjustments (Liviu) v5: Some new platforms added due to rebase v6: Add some missed plane inits (or maybe they're new - who knows at this point) (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Daniel Stone <daniels@collabora.com> (v2) Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-07-20drm/i915: Remove intel_flip_work infrastructureDaniel Vetter1-7/+1
This gets rid of all the interactions between the legacy flip code and the modeset code. Yay! This highlights an ommission in the atomic paths, where we fail to apply a boost to the pending rendering when we miss the target vblank. But the existing code is still dead and can be removed. v2: Note that the boosting doesn't work in atomic (Chris). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-7-daniel.vetter@ffwll.ch
2017-07-07drm/i915/cnl: Cannonlake color init.Rodrigo Vivi1-1/+1
Cannonlake has same color setup as Geminilake. Legacy color load luts doesn't work anymore on Cannonlake+. Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499374873-2454-1-git-send-email-rodrigo.vivi@intel.com
2017-06-06drm/i915: Workaround VLV/CHV DSI scanline counter hardware failVille Syrjälä1-0/+21
The scanline counter is bonkers on VLV/CHV DSI. The scanline counter increment is not lined up with the start of vblank like it is on every other platform and output type. This causes problems for both the vblank timestamping and atomic update vblank evasion. On my FFRD8 machine at least, the scanline counter increment happens about 1/3 of a scanline ahead of the start of vblank (which is where all register latching happens still). That means we can't trust the scanline counter to tell us whether we're in vblank or not while we're on that particular line. In order to keep vblank timestamping in working condition when called from the vblank irq, we'll leave scanline_offset at one, which means that the entire line containing the start of vblank is considered to be inside the vblank. For the vblank evasion we'll need to consider that entire line to be bad, since we can't tell whether the registers already got latched or not. And we can't actually use the start of vblank interrupt to get us past that line as the interrupt would fire too soon, and then we'd up waiting for the next start of vblank instead. One way around that would using the frame start interrupt instead since that wouldn't fire until the next scanline, but that would require some bigger changes in the interrupt code. So for simplicity we'll just poll until we get past the bad line. v2: Adjust the comments a bit Cc: stable@vger.kernel.org Cc: Jonas Aaberg <cja@gmx.net> Tested-by: Jonas Aaberg <cja@gmx.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161215174734.28779-1-ville.syrjala@linux.intel.com Tested-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2017-05-30Merge tag 'drm-intel-next-2017-05-29' of ↵Dave Airlie1-71/+53
git://anongit.freedesktop.org/git/drm-intel into drm-next More stuff for 4.13: - skl+ wm fixes from Mahesh Kumar - some refactor and tests for i915_sw_fence (Chris) - tune execlist/scheduler code (Chris) - g4x,g33 gpu reset improvements (Chris, Mika) - guc code cleanup (Michal Wajdeczko, Michał Winiarski) - dp aux backlight improvements (Puthikorn Voravootivat) - buffer based guc/host communication (Michal Wajdeczko) * tag 'drm-intel-next-2017-05-29' of git://anongit.freedesktop.org/git/drm-intel: (253 commits) drm/i915: Update DRIVER_DATE to 20170529 drm/i915: Keep the forcewake timer alive for 1ms past the most recent use drm/i915/guc: capture GuC logs if FW fails to load drm/i915/guc: Introduce buffer based cmd transport drm/i915/guc: Disable send function on fini drm: Add definition for eDP backlight frequency drm/i915: Drop AUX backlight enable check for backlight control drm/i915: Consolidate #ifdef CONFIG_INTEL_IOMMU drm/i915: Only GGTT vma may be pinned and prevent shrinking drm/i915: Serialize GTT/Aperture accesses on BXT drm/i915: Convert i915_gem_object_ops->flags values to use BIT() drm/i915/selftests: Silence compiler warning in igt_ctx_exec drm/i915/guc: Skip port assign on first iteration of GuC dequeue drm/i915: Remove misleading comment in request_alloc drm/i915/g33: Improve reset reliability Revert "drm/i915: Restore lost "Initialized i915" welcome message" drm/i915/huc: Update GLK HuC version drm/i915: Check for allocation failure drm/i915/guc: Remove action status and statistics from debugfs drm/i915/g4x: Improve gpu reset reliability ...
2017-05-22drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPIRobert Foss1-10/+10
Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As a result these defines are provided purely as a convenience to userspace applications. Changes since v3: - Switched away from past tense in comments - Add define name change to previously mis-spelled DRM_REFLECT_X comment - Improved the comment for the DRM_MODE_REFLECT_<axis> comment Changes since v2: - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_ - Fix compilation errors - Changed comment formatting - Deduplicated comment lines - Clarified DRM_MODE_PROP_REFLECT_ comment Changes since v1: - Moved defines from drm.h to drm_mode.h - Changed define prefix from DRM_ to DRM_MODE_PROP_ - Updated uses of the defines to the new prefix - Removed include from drm_rect.c - Stopped using the BIT() macro Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com
2017-05-12drm/i915: Make vblank evade warnings optionalVille Syrjälä1-2/+5
Add a new Kconfig option to enable/disable the extra warnings from the vblank evade code. For now we'll keep the warning about an actually missed vblank always enabled as that can have an actual user visible impact. But if we miss the deadline othrwise there's no real need to bother the user with that. We'll want these warnings enabled during development however so that we can catch regressions. Based on the reports it looks like this is still very easy to hit on SKL, so we have more work ahead of us to optimize the crtiical section further. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Jens Axboe <axboe@kernel.dk> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Fixes: e1edbd44e23b ("drm/i915: Complain if we take too long under vblank evasion.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-05-10drm/i915: Pass intel_plane and intel_crtc to plane hooksVille Syrjälä1-64/+46
Streamline things by passing intel_plane and intel_crtc instead of the drm types to our plane hooks. v2: s/ilk/g4x/ in sprite code Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170327185546.2977-3-ville.syrjala@linux.intel.com
2017-05-10drm/i915: Add support for sprites on g4xVille Syrjälä1-9/+9
Now that the watermarks are in order, it should be safe to enable sprite planes on g4x. We alreday have the code in fact, we just call it ilk_. Let's rename to g4x_ and let it loose. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170421181432.15216-16-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-03-27drm/i915: Use i9xx_check_plane_surface() for sprite planes as wellVille Syrjälä1-46/+25
All the pre-SKL sprite planes compute the x/y/tile offsets in a similar way. There are a couple of minor differences but the primary planes have those as well. Thus i9xx_check_plane_surface() already does what we need, so let's use it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-7-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-03-27drm/i915: Pre-compute plane control register valueVille Syrjälä1-12/+12
Computing the plane control register value is branchy so moving it out from the plane commit hook seems prudent. Let's pre-compute it during the atomic check phase and store the result in the plane state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-4-ville.syrjala@linux.intel.com
2017-03-23drm/i915: Extract ilk_sprite_ctl()Ville Syrjälä1-31/+41
Pull the code to calculate the ILK-SNB sprite control register value into a separate function. Allows us to pre-compute it in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317211808.14693-7-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-03-23drm/i915: Extract ivb_sprite_ctl()Ville Syrjälä1-36/+44
Pull the code to calculate the IVB-BDW sprite control register value into a separate function. Allows us to pre-compute it in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317211808.14693-6-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-03-23drm/i915: Extract vlv_sprite_ctl()Ville Syrjälä1-34/+37
Pull the code to calculate the VLV/CHV sprite control register value into a separate function. Allows us to pre-compute it in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317211808.14693-5-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-03-23drm/i915: Use skl_plane_ctl() for the SKL "sprite" planesVille Syrjälä1-17/+1
On SKL the planes are uniform so the "sprites" can use the primary plane code perfectly fine. The only difference we have is the color key handling, but since we never enable that for the primary plane the same code works just fine. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317211808.14693-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2017-03-13drm/i915: Use I915_READ_FW for plane updatesVille Syrjälä1-94/+134
Optimize the plane register accesses a little bit by grabbing the uncore lock manually across the entire pile of accesses and using I915_READ_FW(). This helps keep the pipe update vblank evade critical section below our 100 usec deadline, particularly with lockdep enabled. And in general we want to keep that critical section as short as possible as it's executed with interrupts disabled. Not all plane updates currently happen from within the vblank evade critical section, so we must use the irqsave/irqrestore variants of the spinlock functions in the plane hooks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170309154434.29303-5-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-03-13drm/i915: Organize plane register writes into tighter bunchesVille Syrjälä1-29/+30
Pull all the plane register writes closer together to avoid having a lot of unrelated stuff in between them. This will make things more clear once we'll grab the uncore lock around the entire bunch. Also in the future we might even consider moving more of the register value computation out from the plane update hooks. This should make that easier to do. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170309154434.29303-4-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2017-03-09drm/i915: Nuke skl_update_plane debug message from the pipe update critical ↵Maarten Lankhorst1-3/+0
section printks are slow so we should not be doing them from the vblank evade critical section. These could explain why we sometimes seem to blow past our 100 usec deadline. The problem has been there ever since commit c331879ce8ea ("drm/i915: skylake sprite plane scaling using shared scalers.") but it may not have been readily visible until commit e1edbd44e23b ("drm/i915: Complain if we take too long under vblank evasion.") increased our chances of noticing it. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1488974407-25175-1-git-send-email-maarten.lankhorst@linux.intel.com Fixes: c331879ce8ea ("drm/i915: skylake sprite plane scaling using shared scalers") Cc: <stable@vger.kernel.org> # v4.2+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Add missing tags, point to the correct offending commit]
2017-03-08drm/i915: suppress atomic commit error message under gvt-g envBing Niu1-0/+4
under virtualization enviroment, it is possible guest update pipe registers across vblank intervals due to overhead of mmio traps or vm schedule out. However, it is safe since those pipe update happen in virual registers and will not be committed to hardware. suppress that atomic commit error message under virtualization case to avoid confusing user. v2: per ville's comment: return early and against Maarten's patch v3: coding style clean Signed-off-by: Bing Niu <bing.niu@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489004043-15449-1-git-send-email-bing.niu@intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>