summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_display.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: set "ret" correctly on error pathsDan Carpenter2017-04-151-0/+2
| | | | | | | | | | | | | | If "crtc" is NULL, then my static checker complains that "ret" isn't initialized on that path. It doesn't really cause a problem unless "ret" is somehow set to -EDEADLK which is not likely. Chris Wilson also noticed another error path where "ret" isn't set correctly. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170414195425.GA8144@mwanda Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* Revert "drm/i915: Lock mode_config.mutex in intel_display_resume."Maarten Lankhorst2017-04-121-8/+0
| | | | | | | | | | | | | | | | This reverts commit ea49c9acf2db7082f0406bb3a570cc6bad37082b. mode_config.mutex was originally added to fix WARNs in connector functions, but now that atomic nonblocking modeset support is included, we will likely never hold any any lock at all. The WARN mentioned in commit bbf35e9defb9a6d1 ("drm/i915: Pass atomic state to intel_audio_codec_enable, v2."), so it's safe to revert this now. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491312168-18147-1-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge airlied/drm-next into drm-intel-next-queuedDaniel Vetter2017-04-121-72/+18
|\ | | | | | | | | | | | | | | Maarten needs both the new connector->atomic_check hook and the connection_mutex locking changes in the probe helpers to be able to start merging the connector property conversion to atomic. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'drm-misc-next-2017-04-07' of ↵Dave Airlie2017-04-111-70/+15
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/git/drm-misc into drm-next Last drm-misc-next pull req for 4.12 Core changes: - fb_helper checkpatch cleanup and simplified _add_one_connector() (Thierry) - drm_ioctl and drm_sysfs improved/gained documentation (Daniel) - [ABI] Repurpose reserved field in drm_event_vblank for crtc_id (Ander) - Plumb acquire ctx through legacy paths to avoid lock_all and legacy_backoff (Daniel) - Add connector_atomic_check to check conn constraints on modeset (Maarten) - Add drm_of_find_panel_or_bridge to remove boilerplate in drivers (Rob) Driver changes: - meson moved to drm-misc (Neil) - Added support for Amlogic GX SoCs in dw-hdmi (Neil) - Rockchip unbind actually cleans up the things bind initializes (Jeffy) - A couple misc fixes in virtio, dw-hdmi NOTE: this also includes a backmerge of drm-next as well rc5 (we needed vmwgfx as well as the new synopsys media formats) * tag 'drm-misc-next-2017-04-07' of git://anongit.freedesktop.org/git/drm-misc: (77 commits) Revert "drm: Don't allow interruptions when opening debugfs/crc" drm: Only take cursor locks when the cursor plane exists drm/vmwgfx: Fix fbdev emulation using legacy functions drm/rockchip: Shutdown all crtcs when unbinding drm drm/rockchip: Reorder drm bind/unbind sequence drm/rockchip: analogix_dp: Disable clock when unbinding drm/rockchip: vop: Unprepare clocks when unbinding drm/rockchip: vop: Enable pm domain before vop_initial drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding drm/rockchip: cdn-dp: Don't try to release firmware when not loaded drm: bridge: analogix: Destroy connector & encoder when unbinding drm: bridge: analogix: Disable clock when unbinding drm: bridge: analogix: Unregister dp aux when unbinding drm: bridge: analogix: Detach panel when unbinding analogix dp drm: Don't allow interruptions when opening debugfs/crc drm/virtio: don't leak bo on drm_gem_object_init failure drm: bridge: dw-hdmi: fix input format/encoding from plat_data drm: omap: use common OF graph helpers drm: convert drivers to use drm_of_find_panel_or_bridge drm: convert drivers to use of_graph_get_remote_node ...
| | * drm/atomic: Acquire connection_mutex lock in ↵Maarten Lankhorst2017-04-061-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_helper_probe_single_connector_modes, v4. mode_valid() called from drm_helper_probe_single_connector_modes() may need to look at connector->state because what a valid mode is may depend on connector properties being set. For example some HDMI modes might be rejected when a connector property forces the connector into DVI mode. Some implementations of detect() already lock all state, so we have to pass an acquire_ctx to them to prevent a deadlock. This means changing the function signature of detect() slightly, and passing the acquire_ctx for locking multiple crtc's. For the callbacks, it will always be non-zero. To allow callers not to worry about this, drm_helper_probe_detect_ctx is added which might handle -EDEADLK for you. Changes since v1: - Always set ctx parameter. Changes since v2: - Always take connection_mutex when probing. Changes since v3: - Remove the ctx from intel_dp_long_pulse, and add WARN_ON(!connection_mutex) (danvet) - Update docs to clarify the locking situation. (danvet) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1491504920-4017-1-git-send-email-maarten.lankhorst@linux.intel.com
| | * drm/fb-helper: Give up on kgdb for atomic driversDaniel Vetter2017-04-061-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It just doesn't work. It probably stopped working way, way before that (e.g. i915 grabbed random mutexes all over in modeset code at least since gen6), but with atomic and all the ww_mutex stuff it's indeed hopeless. Remove ->mode_set_base_atomic from the 2 atomic drivers (i915 and nouveau) that still had one (both had dummy implementations already anyway), and shunt atomic drivers in the helpers debug_enter/leave functions. I'll leave the code in for radeon and amdgpu, but I think as soon as amdgpu is atomic we should think about just ripping it out. Only having it around for radeon and pre-nv50 is rather pointless. This would also allow us to nuke all that code from fbdev. Funny part is that _all_ kms drivers set this hook, despite that no one else provides the required ->mode_set_base_atomic implementation. The reason I'm jumping on this is that I want to wire up a full acquire ctx for the benefit of atomic drivers, everywhere. And the debug_enter/leave implementations call ->gamma_set. And there's just no way ever we can create an acquire_ctx in the nmi context of kgdb. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-11-daniel.vetter@ffwll.ch
| | * drm/i915: Nuke intel_atomic_legacy_gamma_setDaniel Vetter2017-04-051-43/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do set DRIVER_ATOMIC now. Note that the comment is outdated, the property paths switched over to checking drm_drv_uses_atomic_modeset() a while ago. Which means this can't even break if we revert DRIVER_ATOMIC again. v2: Add note that this is even safer (Maarten). Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-9-daniel.vetter@ffwll.ch
| | * drm: Remove drm_modeset_legacy_acquire_ctx and crtc->acquire_ctxDaniel Vetter2017-04-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With all the callers of drm_modeset_lock_crtc gone, and all the places it was formerly used properly wiring the acquire ctx through, we can remove this. The only hidden context magic we still have is now the global one. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-4-daniel.vetter@ffwll.ch
| * | Merge tag 'drm-intel-testing-2017-04-03' of ↵Dave Airlie2017-04-111-203/+226
| |\ \ | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/git/drm-intel into drm-next Last 4.12 feature pile: GVT updates: - Add mdev attribute group for per-vgpu info - Time slice based vGPU scheduling QoS support (Gao Ping) - Initial KBL support for E3 server (Han Xu) - other misc. i915: - lots and lots of small fixes and improvements all over - refactor fw_domain code (Chris Wilson) - improve guc code (Oscar Mateo) - refactor cursor/sprite code, precompute more for less overhead in the critical path (Ville) - refactor guc/huc fw loading code a bit (Michal Wajdeczko) * tag 'drm-intel-testing-2017-04-03' of git://anongit.freedesktop.org/git/drm-intel: (121 commits) drm/i915: Update DRIVER_DATE to 20170403 drm/i915: Clear gt.active_requests before checking idle status drm/i915/uc: Drop use of MISSING_CASE on trivial enums drm/i915: make a few DDI functions static drm/i915: Combine reset_all_global_seqno() loops into one drm/i915: Remove redudant wait for each engine to idle from seqno wrap drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle() drm/i915: Move retire-requests into i915_gem_wait_for_idle() drm/i915/uc: Move fw path check to fetch_uc_fw() drm/i915/huc: Remove unused intel_huc_fini() drm/i915/uc: Add intel_uc_fw_fini() drm/i915/uc: Add intel_uc_fw_type_repr() drm/i915/uc: Move intel_uc_fw_status_repr() to intel_uc.h drivers: gpu: drm: i915L intel_lpe_audio: Fix kerneldoc comments drm/i915: Suppress busy status for engines if wedged drm/i915: Do request retirement before marking engines as wedged drm/i915: Drop verbose and archaic "ring" from our internal engine names drm/i915: Use a dummy timeline name for a signaled fence drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex drm/i915/guc: Take enable_guc_loading check out of GEM core code ...
| * | Revert unrelated part of "drm: simplify the locking in the GETCRTC ioctl"Maarten Lankhorst2017-03-301-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v2 of the commit 2c77bb29d398 ("drm: simplify the locking in the GETCRTC ioctl") accidentally introduced a unrelated change in intel_display.c, revert the unrelated change. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 2c77bb29d398 ("drm: simplify the locking in the GETCRTC ioctl") Reported-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/6be47261-475f-c190-af56-c136677246d9@linux.intel.com
| * | drm: simplify the locking in the GETCRTC ioctlDaniel Vetter2017-03-291-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No need to grab both plane and crtc locks at the same time, we can do them one after the other. If userspace races it'll get what it deserves either way. This removes another user of drm_modeset_lock_crtc. There's only one left. v2: Make sure all access to primary->state is properly protected (Harry). Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170328070145.21520-1-daniel.vetter@ffwll.ch
| * | drm: Add acquire ctx parameter to ->update_planeDaniel Vetter2017-03-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just rolling it out, no code change here. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Rob Clark <robdclark@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-3-daniel.vetter@ffwll.ch
* | | drm/i915: Simplify shrinker lockingJoonas Lahtinen2017-04-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By using the same structure for both interruptible and uninterruptible locking in shrinker code, combined with the information that mm.interruptible is only being written to, the code can be greatly simplified. Also removing the i915_gem_ prefix from the locking functions so that nobody in their wildest dreams considers exporting them. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1491562175-27680-1-git-send-email-joonas.lahtinen@linux.intel.com
* | | i915: initialize the free_list of the fencing atomic_helperAndrea Arcangeli2017-04-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just in case the llist model changes and NULL isn't valid initialization. Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170406232347.988-4-aarcange@redhat.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
* | | drm/i915: Make legacy cursor updates more unsyncedVille Syrjälä2017-04-041-11/+20
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're clearing the legacy_cursor_update flag before calling drm_atomic_helper_setup_commit() which means the helper will wait for the flip to complete before cleaning up the framebuffers. That's not what we want for the legacy cursor, so let's clear the flag after setting up the commit. Also toss in a FIXME about solving these problems in a nicer way using the fabled vblank workers. v2: Also unsync with legacy page flips Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Uwe Kleine-König <uwe@kleine-koenig.org> Cc: Rafael Ristovski <rafael.ristovski@gmail.com> Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170329142123.5923-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* | drm/i915: Use LINEAR modifier instead of NONEBen Widawsky2017-03-291-14/+14
| | | | | | | | | | | | | | | | | | They're the same, so use the one which makes more sense. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170324212950.2206-1-ben@bwidawsk.net Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* | drm/i915/dp: reduce link M/N parametersJani Nikula2017-03-281-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several major vendor USB-C->HDMI converters, in particular the DA200, fail to recover a 5.4 GHz 1 lane signal if the link N is greater than 0x80000. The link M and N depend on the pixel clock and link clock ratio. With current code link N exceeds 0x80000 only when link clock >= 540000 kHz. Except for the eDP intermediate link clocks, at least the four least significant bits are always zero. Just one bit shift right would be enough to bring even the DP 1.4 810000 kHz link clock under 0x80000 link N. The pixel clock for modes that require a link clock >= 540000 kHz would also have several least significant bits zero. Unless the user provides a mode with an odd pixel clock value, we can reduce the numbers to reach the goal, with no loss in precision. The DP spec even mentions sources making choices that "allow for static and relatively small Mvid and Nvid values", thus reducing the link M/N regardless of the sink in question seems justified. Everything here is based on the work and information gathered by Clint Taylor <clinton.a.taylor@intel.com>. This is just an iteration to reduce the parameters regardless of lane count, link rate, or sink. Reference: http://patchwork.freedesktop.org/patch/msgid/1490225256-11667-1-git-send-email-clinton.a.taylor@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578 Tested-by: Mads <mads@ab3.no> Tested-by: PJ <foobar@pjmodos.net> Tested-by: François Guerraz <kubrick@fgv6.net> Tested-by: Lev Popov <leo@nabam.net> Tested-by: Igor Krivenko <igor.s.krivenko@gmail.com> Tested-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1490614405-23337-1-git-send-email-jani.nikula@intel.com
* | drm/i915: enable scramblingShashank Sharma2017-03-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks, for reduced RF footprint. This patch checks if the monitor supports scrambling, and if required, enables it during the modeset. V2: Addressed review comments from Ville: - Do not track scrambling status in DRM layer, track somewhere in driver like in intel_crtc_state. - Don't talk to monitor at such a low layer, set monitor scrambling in intel_enable_ddi() before enabling the port. V3: Addressed review comments from Jani - In comments, function names, use "sink" instead of "monitor", so that the implementation could be close to the language of HDMI spec. V4: Addressed review comment from Maarten - scrambling -> hdmi_scrambling - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio V5: Addressed review comments from Ville and Ander - Do not modifiy the crtc_state after compute_config. Move all scrambling and tmds_clock_ratio calcutations to compute_config. - While setting scrambling for source/sink, do not check the conditions again, just go by the crtc_state flags. This will simplyfy the condition checks. V6: Addressed review comments from Ville - Do not add IS_GLK check in disable/enable function, instead add it in compute_config, while setting state flags. - Remove unnecessary paranthesis. - Simplyfy handle_sink_scrambling function as suggested. - Add readout code for scrambling status in get_ddi_config and add a check for the same in pipe_config_compare. V7: Addressed review comments from Ander/Ville - No separate function for source scrambling, make it inline - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK - Do not add platform check while setting source scrambling - Use pipe_config instead of crtc->config to set sink scrambling - To readout scrambling status, Compare with SCRAMBLING_MASK not any of its bits - Remove platform check in intel_pipe_config_compare while checking scrambling status V8: Fixed mege conflict, Addressed review comments from Ander - Remove the desciption/comment about scrambling fom the caller, move it to the function - Move the IS_GLK check into scrambling function - Fix alignment V9: Fixed review comments from Ville, Ander - Pass the scrambling state variables as bool input to the sink_scrambling function and let the disable call be unconditional. - Fix alignments in function calls and debug messages. - Add kernel doc for function intel_hdmi_handle_sink_scrambling V10: Rebase Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
* | drm/i915: kill intel_ddi_pll_select()Paulo Zanoni2017-03-271-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | All it does is pick the encoder and call intel_get_shared_dpll(). We can just do this in the caller. One less indirection level during code reading. As another plus, now the two callers of intel_get_shared_dpll() are {ironlake,haswell}_crtc_compute_clock(). Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1490209125-20046-2-git-send-email-paulo.r.zanoni@intel.com
* | drm/i915: Use i9xx_check_plane_surface() for sprite planes as wellVille Syrjälä2017-03-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Eliminate ironlake_update_primary_plane()Ville Syrjälä2017-03-271-49/+6
| | | | | | | | | | | | | | | | | | | | | | The effective difference between i9xx_update_primary_plane() and ironlake_update_primary_plane() is only the HSW/BDW DSPOFFSET special case. So bring that over into i9xx_update_primary_plane() and eliminate the duplicated 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/20170323192712.30682-6-ville.syrjala@linux.intel.com
* | drm/i915: Introduce i9xx_check_plane_surface()Ville Syrjälä2017-03-271-32/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extract the primary plane surfae offset/x/y calculations for pre-SKL platforms into a common function, and call it during the atomic check phase to reduce the amount of stuff we have to do during the commit phase. SKL is already doing this. v2: Update the comment about the rotation adjustments to match the code better (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> 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-5-ville.syrjala@linux.intel.com
* | drm/i915: Pre-compute plane control register valueVille Syrjälä2017-03-271-20/+21
| | | | | | | | | | | | | | | | | | | | 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
* | drm/i915: Nuke ironlake_plane_ctl()Ville Syrjälä2017-03-271-52/+6
| | | | | | | | | | | | | | | | | | | | | | | | Share the code to compute the primary plane control register value between the i9xx and ilk codepaths as the differences are minimal. Actually there are no differences between g4x and ilk, so the current split doesn't really make any sense. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl()Ville Syrjälä2017-03-271-38/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | Pull the code to calculate the pre-SKL primary plane control register value into separate functions. Allows us to pre-compute it in the future. v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl()Ville Syrjälä2017-03-231-47/+72
| | | | | | | | | | | | | | | | | | Pull the code to calculate the cursor control register value into separate functions. Allows us to pre-compute them in the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317211808.14693-8-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
* | drm/i915: Use skl_plane_ctl() for the SKL "sprite" planesVille Syrjälä2017-03-231-5/+11
| | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Extract skl_plane_ctl()Ville Syrjälä2017-03-231-12/+26
|/ | | | | | | | | Pull the code to calculate the SKL plane 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-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
* drm/i915: Remove superfluous i915_add_request_no_flush() helperChris Wilson2017-03-171-2/+2
| | | | | | | | | | | The only time we need to emit a flush inside request emission is after an execbuffer, for which we can use the full __i915_add_request(). All other instances want the simpler i915_add_request() without flushing, so remove the useless helper. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170317114709.8388-1-chris@chris-wilson.co.uk
* drm/i915: Split I915_RESET_IN_PROGRESS into two flagsChris Wilson2017-03-161-2/+2
| | | | | | | | | | | | | | | I915_RESET_IN_PROGRESS is being used for both signaling the requirement to i915_mutex_lock_interruptible() to avoid taking the struct_mutex and to instruct a waiter (already holding the struct_mutex) to perform the reset. To allow for a little more coordination, split these two meaning into a couple of distinct flags. I915_RESET_BACKOFF tells i915_mutex_lock_interruptible() not to acquire the mutex and I915_RESET_HANDOFF tells the waiter to call i915_reset(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170316171305.12972-1-chris@chris-wilson.co.uk
* drm/i915: Use I915_READ_FW for plane updatesVille Syrjälä2017-03-131-64/+94
| | | | | | | | | | | | | | | | | | | 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>
* drm/i915: Organize plane register writes into tighter bunchesVille Syrjälä2017-03-131-20/+24
| | | | | | | | | | | | | 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>
* drm/i915: Use new atomic iterator macros in display codeMaarten Lankhorst2017-03-131-79/+82
| | | | | | | | | | | | Add a big fat warning in __intel_display_resume that the old state is invalid, and use the correct state everywhere. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-5-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [mlankhorst: Change one occurence of conn_state to new_conn_state in verify_connector_state, and drop old_conn_state there]
* drm/i915: Fix up verify_encoder_stateDaniel Vetter2017-03-081-11/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The trouble here is that looking at all connector->state in the verifier isn't good, because that's run from the commit work, which doesn't hold the connection_mutex. Which means we're only allowed to look at states in our atomic update. The simple fix for future proofing would be to switch over to drm_for_each_connector_in_state, but that has the problem that the verification then fails if not all connectors are in the state. And we also need to be careful to check both old and new encoders, and not screw things up when an encoder gets reassigned. Note that this isn't the full fix, since we still look at connector->state. To fix that, we need Maarten's patch series to switch over to state pointers within drm_atomic_state, but that's a different series. v2: Use oldnew iterator (Maarten). v3: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-6-daniel.vetter@ffwll.ch
* drm/i915: use for_each_intel_connector_iter in intel_display.cDaniel Vetter2017-03-081-4/+16
| | | | | | | | | | | | | | | | | | | This gets rid of the last users of for_each_intel_connector(), remove that too. At first I wasn't sure whether the 2 loops in the modeset state checker should instead only loop over the connectors in the atomic commit. But we never add connectors to an atomic update if they don't (or won't have) a CRTC assigned, which means there'd be a gap in check coverage. Hence loop over everything on those too. v2: Rebase onto the iter_get/put->iter_begin/end rename. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-5-daniel.vetter@ffwll.ch
* drm/i915: Make intel_get_pipe_from_connector atomicDaniel Vetter2017-03-081-3/+2
| | | | | | | | | | | | Drive-by fixup while looking at all the connector_list walkers - holding connection_mutex does actually _not_ give you locking to look at the legacy drm_connector->encoder->crtc pointer chain. That one is solely owned by the atomic commit workers. Instead we must inspect the atomic state. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170301095226.30584-4-daniel.vetter@ffwll.ch
* drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messagesVille Syrjälä2017-03-081-33/+33
| | | | | | | | | | | | | DRM_UT_CORE generates way too much noise usually, so having the framebuffer init failures use DRM_UT_CORE is a pain when trying to find out the reason why you failed in creating a framebuffer. Let's use DRM_UT_KMS for these debug messages instead. v2: s/at less than/at most/ in the debug message (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307194210.13400-6-ville.syrjala@linux.intel.com
* drm/i915: Pass the correct plane index to _intel_compute_tile_offset()Ville Syrjälä2017-03-081-1/+1
| | | | | | | | | | intel_fill_fb_info() should pass the correct plane index to _intel_compute_tile_offset() once we start to care about the AUX surface. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307194210.13400-5-ville.syrjala@linux.intel.com
* drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux planeVille Syrjälä2017-03-081-1/+6
| | | | | | | | | | To make life easier let's allow skl_plane_stride() to be called for the AUX surface even when there is no AUX surface. Avoids special cases in the callers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307194210.13400-4-ville.syrjala@linux.intel.com
* drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()Ville Syrjälä2017-03-081-7/+5
| | | | | | | | | | Let's try to keep the alignment requirements in one place, and so towards that end let's move the AUX_DIST alignment handling into intel_surf_alignment() alongside the main surface alignment stuff. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307194210.13400-3-ville.syrjala@linux.intel.com
* drm/i915: Plumb drm_framebuffer into more placesVille Syrjälä2017-03-081-78/+54
| | | | | | | | | | Now that framebuffers can be used even before calling drm_framebuffer_init() we can start to plumb them into more places, instead of passing individual pieces for fb metadata. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307194210.13400-2-ville.syrjala@linux.intel.com
* drm/i915: Nuke debug messages from the pipe update critical sectionVille Syrjälä2017-03-081-11/+1
| | | | | | | | | | | | | | | | | | | 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 bfd16b2a23dc ("drm/i915: Make updating pipe without modeset atomic.") 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. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: bfd16b2a23dc ("drm/i915: Make updating pipe without modeset atomic.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170307205419.19447-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queuedDaniel Vetter2017-03-081-6/+7
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge drm-next to get at all the good stuff in drm-misc. We need that because: - drm_connector_list_iter conversion for i915 needs the core patches. - Maarten's patches to use the new atomic state iterators also need the core patches. - We need the new link status property to complete the DP retraining work, merging through 2 branches wasn't a good idea and we had to partially backtrack. - Chris needs reservation_object_trylock and we want to roll out kref_read everywhere. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * Merge tag 'drm-intel-next-2017-03-06' of ↵Dave Airlie2017-03-081-2190/+523
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/git/drm-intel into drm-next 4 weeks worth of stuff since I was traveling&lazy: - lspcon improvements (Imre) - proper atomic state for cdclk handling (Ville) - gpu reset improvements (Chris) - lots and lots of polish around fences, requests, waiting and everything related all over (both gem and modeset code), from Chris - atomic by default on gen5+ minus byt/bsw (Maarten did the patch to flip the default, really this is a massive joint team effort) - moar power domains, now 64bit (Ander) - big pile of in-kernel unit tests for various gem subsystems (Chris), including simple mock objects for i915 device and and the ggtt manager. - i915_gpu_info in debugfs, for taking a snapshot of the current gpu state. Same thing as i915_error_state, but useful if the kernel didn't notice something is stick. From Chris. - bxt dsi fixes (Umar Shankar) - bxt w/a updates (Jani) - no more struct_mutex for gem object unreference (Chris) - some execlist refactoring (Tvrtko) - color manager support for glk (Ander) - improve the power-well sync code to better take over from the firmware (Imre) - gem tracepoint polish (Tvrtko) - lots of glk fixes all around (Ander) - ctx switch improvements (Chris) - glk dsi support&fixes (Deepak M) - dsi fixes for vlv and clanups, lots of them (Hans de Goede) - switch to i915.ko types in lots of our internal modeset code (Ander) - byt/bsw atomic wm update code, yay (Ville) * tag 'drm-intel-next-2017-03-06' of git://anongit.freedesktop.org/git/drm-intel: (432 commits) drm/i915: Update DRIVER_DATE to 20170306 drm/i915: Don't use enums for hardware engine id drm/i915: Split breadcrumbs spinlock into two drm/i915: Refactor wakeup of the next breadcrumb waiter drm/i915: Take reference for signaling the request from hardirq drm/i915: Add FIFO underrun tracepoints drm/i915: Add cxsr toggle tracepoint drm/i915: Add VLV/CHV watermark/FIFO programming tracepoints drm/i915: Add plane update/disable tracepoints drm/i915: Kill level 0 wm hack for VLV/CHV drm/i915: Workaround VLV/CHV sprite1->sprite0 enable underrun drm/i915: Sanitize VLV/CHV watermarks properly drm/i915: Only use update_wm_{pre,post} for pre-ilk platforms drm/i915: Nuke crtc->wm.cxsr_allowed drm/i915: Compute proper intermediate wms for vlv/cvh drm/i915: Skip useless watermark/FIFO related work on VLV/CHV when not needed drm/i915: Compute vlv/chv wms the atomic way drm/i915: Compute VLV/CHV FIFO sizes based on the PM2 watermarks drm/i915: Plop vlv/chv fifo sizes into crtc state drm/i915: Plop vlv wm state into crtc_state ...
| * \ Merge airlied/drm-next into drm-misc-nextDaniel Vetter2017-02-261-6/+37
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge the main pull request to sync up with all the newly landed drivers. Otherwise we'll have chaos even before 4.12 started in earnest. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| | * \ Merge tag 'v4.10-rc8' into drm-nextDave Airlie2017-02-231-6/+37
| | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 4.10-rc8 Backmerge Linus rc8 to fix some conflicts, but also to avoid pulling it in via a fixes pull from someone.
| | | * | drm/i915: fix use-after-free in page_flip_completed()Andrey Ryabinin2017-02-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | page_flip_completed() dereferences 'work' variable after executing queue_work(). This is not safe as the 'work' item might be already freed by queued work: BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90 Call Trace: __asan_report_load8_noabort+0x59/0x80 page_flip_completed+0x3ff/0x490 intel_finish_page_flip_mmio+0xe3/0x130 intel_pipe_handle_vblank+0x2d/0x40 gen8_irq_handler+0x4a7/0xed0 __handle_irq_event_percpu+0xf6/0x860 handle_irq_event_percpu+0x6b/0x160 handle_irq_event+0xc7/0x1b0 handle_edge_irq+0x1f4/0xa50 handle_irq+0x41/0x70 do_IRQ+0x9a/0x200 common_interrupt+0x89/0x89 Freed: kfree+0x113/0x4d0 intel_unpin_work_fn+0x29a/0x3b0 process_one_work+0x79e/0x1b70 worker_thread+0x611/0x1460 kthread+0x241/0x3a0 ret_from_fork+0x27/0x40 Move queue_work() after trace_i915_flip_complete() to fix this. Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests & completions") Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> # v2.6.36+ Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com (cherry picked from commit 05c41f926fcc7ef838c80a6a99d84f67b4e0b824) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | | * | drm/i915: Track pinned vma in intel_plane_stateChris Wilson2017-02-011-83/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With atomic plane states we are able to track an allocation right from preparation, during use and through to the final free after being swapped out for a new plane. We can couple the VMA we pin for the framebuffer (and its rotation) to this lifetime and avoid all the clumsy lookups in between. v2: Remove residual vma on plane cleanup (Chris) v3: Add a description for the vma destruction in intel_plane_destroy_state (Maarten) References: https://bugs.freedesktop.org/show_bug.cgi?id=98829 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170116152131.18089-1-chris@chris-wilson.co.uk Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit be1e341513ca23b0668b7b0f26fa6e2ffc46ba20) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485854491-27389-3-git-send-email-maarten.lankhorst@linux.intel.com
| | | * | drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()Linus Torvalds2017-01-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've seen this trigger twice now, where the i915_gem_object_to_ggtt() call in intel_unpin_fb_obj() returns NULL, resulting in an oops immediately afterwards as the (inlined) call to i915_vma_unpin_fence() tries to dereference it. It seems to be some race condition where the object is going away at shutdown time, since both times happened when shutting down the X server. The call chains were different: - VT ioctl(KDSETMODE, KD_TEXT): intel_cleanup_plane_fb+0x5b/0xa0 [i915] drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper] intel_atomic_commit_tail+0x749/0xfe0 [i915] intel_atomic_commit+0x3cb/0x4f0 [i915] drm_atomic_commit+0x4b/0x50 [drm] restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper] intel_fbdev_set_par+0x18/0x70 [i915] fb_set_var+0x236/0x460 fbcon_blank+0x30f/0x350 do_unblank_screen+0xd2/0x1a0 vt_ioctl+0x507/0x12a0 tty_ioctl+0x355/0xc30 do_vfs_ioctl+0xa3/0x5e0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x13/0x94 - i915 unpin_work workqueue: intel_unpin_work_fn+0x58/0x140 [i915] process_one_work+0x1f1/0x480 worker_thread+0x48/0x4d0 kthread+0x101/0x140 and this patch purely papers over the issue by adding a NULL pointer check and a WARN_ON_ONCE() to avoid the oops that would then generally make the machine unresponsive. Other callers of i915_gem_object_to_ggtt() seem to also check for the returned pointer being NULL and warn about it, so this clearly has happened before in other places. [ Reported it originally to the i915 developers on Jan 8, applying the ugly workaround on my own now after triggering the problem for the second time with no feedback. This is likely to be the same bug reported as https://bugs.freedesktop.org/show_bug.cgi?id=98829 https://bugs.freedesktop.org/show_bug.cgi?id=99134 which has a patch for the underlying problem, but it hasn't gotten to me, so I'm applying the workaround. ] Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | * | drm/i915: Move atomic state free from out of fence releaseChris Wilson2017-01-251-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fences are required to support being released from under an atomic context. The drm_atomic_state struct may take a mutex when being released and so we cannot drop a reference to the drm_atomic_state from the fence release path directly, and so we need to defer that unreference to a worker. [ 326.576697] WARNING: CPU: 2 PID: 366 at kernel/sched/core.c:7737 __might_sleep+0x5d/0x80 [ 326.576816] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffc0359549>] intel_breadcrumbs_signaler+0x59/0x270 [i915] [ 326.576818] Modules linked in: rfcomm fuse snd_hda_codec_hdmi bnep snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer input_leds led_class snd punit_atom_debug btusb btrtl btbcm btintel intel_rapl bluetooth i915 drm_kms_helper syscopyarea sysfillrect iwlwifi sysimgblt soundcore fb_sys_fops mei_txe cfg80211 drm pwm_lpss_platform pwm_lpss pinctrl_cherryview fjes acpi_pad parport_pc ppdev parport autofs4 [ 326.576899] CPU: 2 PID: 366 Comm: i915/signal:0 Tainted: G U 4.10.0-rc3-patser+ #5030 [ 326.576902] Hardware name: /NUC5PPYB, BIOS PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015 [ 326.576905] Call Trace: [ 326.576920] dump_stack+0x4d/0x6d [ 326.576926] __warn+0xc0/0xe0 [ 326.576931] warn_slowpath_fmt+0x5a/0x80 [ 326.577004] ? intel_breadcrumbs_signaler+0x59/0x270 [i915] [ 326.577075] ? intel_breadcrumbs_signaler+0x59/0x270 [i915] [ 326.577079] __might_sleep+0x5d/0x80 [ 326.577087] mutex_lock+0x1b/0x40 [ 326.577133] drm_property_free_blob+0x1e/0x80 [drm] [ 326.577167] ? drm_property_destroy+0xe0/0xe0 [drm] [ 326.577200] drm_mode_object_unreference+0x5c/0x70 [drm] [ 326.577233] drm_property_unreference_blob+0xe/0x10 [drm] [ 326.577260] __drm_atomic_helper_crtc_destroy_state+0x14/0x40 [drm_kms_helper] [ 326.577278] drm_atomic_helper_crtc_destroy_state+0x10/0x20 [drm_kms_helper] [ 326.577352] intel_crtc_destroy_state+0x9/0x10 [i915] [ 326.577388] drm_atomic_state_default_clear+0xea/0x1d0 [drm] [ 326.577462] intel_atomic_state_clear+0xd/0x20 [i915] [ 326.577497] drm_atomic_state_clear+0x1a/0x30 [drm] [ 326.577532] __drm_atomic_state_free+0x13/0x60 [drm] [ 326.577607] intel_atomic_commit_ready+0x6f/0x78 [i915] [ 326.577670] i915_sw_fence_release+0x3a/0x50 [i915] [ 326.577733] dma_i915_sw_fence_wake+0x39/0x80 [i915] [ 326.577741] dma_fence_signal+0xda/0x120 [ 326.577812] ? intel_breadcrumbs_signaler+0x59/0x270 [i915] [ 326.577884] intel_breadcrumbs_signaler+0xb1/0x270 [i915] [ 326.577889] kthread+0x127/0x130 [ 326.577961] ? intel_engine_remove_wait+0x1a0/0x1a0 [i915] [ 326.577964] ? kthread_stop+0x120/0x120 [ 326.577970] ret_from_fork+0x22/0x30 Fixes: c004a90b7263 ("drm/i915: Restore nonblocking awaits for modesetting") Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170123212939.30345-1-chris@chris-wilson.co.uk Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+ Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit eb955eee27d9dc176871540c43c9070ee4701642) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
OpenPOWER on IntegriCloud