aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2016-12-20drm/i915: Reorder phys backing storage releaseChris Wilson1-19/+34
In commit a4f5ea64f0a8 ("drm/i915: Refactor object page API"), I reordered the object->pages teardown to be more friendly wrt to a separate obj->mm.lock. However, I overlooked the phys object and left it with a dangling use-after-free of its phys_handle. Move the allocation of the phys handle to get_pages and it release to put_pages to prevent the invalid access and to improve symmetry. v2: Add commentary about always aligning to page size. Testcase: igt/drv_selftest/objects Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: a4f5ea64f0a8 ("drm/i915: Refactor object page API") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161207133411.8028-1-chris@chris-wilson.co.uk (cherry picked from commit dbb4351bab0a8440f6b02895c142bce6c30b7097) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-20drm/i915/gen9: Fix PCODE polling during SAGV disablingImre Deak1-25/+9
According to the previous patch, it's possible atm that we call intel_do_sagv_disable() only once during the 1ms period and time out if that call fails. As opposed to this the spec says that we need to keep retrying this request for a 1ms duration, so let's do this similarly to the CDCLK change notification request. v4-5: - Rebased on the reply_mask, reply change. v6: - Remove w/s change. (Lyude) - Rebased on the timeout_base argument change. Cc: Lyude <cpaul@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 656d1b89e5ff ("drm/i915/skl: Add support for the SAGV, fix underrun hangs") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-2-git-send-email-imre.deak@intel.com (cherry picked from commit b3b8e99984a4eace91bc097e8f8cec71441cae16) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-20drm/i915/gen9: Fix PCODE polling during CDCLK change notificationImre Deak3-21/+87
commit 848496e5902833600f7992f4faa82dc1546051ba Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at least one SKL. A CDCLK change request following the failed one will succeed nevertheless. I could reproduce this problem easily by running kms_pipe_crc_basic in a loop. In all failure cases _wait_for() was pre-empted for >3ms and so in the worst case - when the pre-emption happened right after calculating timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only once which failed and so _wait_for() timed out. As opposed to this the spec says to keep retrying the request for at most a 3ms period. To fix this send the first request explicitly to guarantee that there is 3ms between the first and last request. Though this matches the spec, I noticed that in rare cases this can still time out if we sent only a few requests (in the worst case 2) _and_ PCODE is busy for some reason even after a previous request and a 3ms delay. To work around this retry the polling with pre-emption disabled to maximize the number of requests. Also increase the timeout to 10ms to account for interrupts that could reduce the number of requests. With this change I couldn't trigger the problem. v2: - Use 1ms poll period instead of 10us. (Chris) v3: - Poll with pre-emption disabled to increase the number of request attempts. (Ville, Chris) - Factor out a helper to poll, it's also needed by the next patch. v4: - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the reply is generic. (Ville) v5: - List the request specific timeout values as code comment. (Ville) v6: - Try the poll first with preemption enabled. - Add code comment about first request being queued by PCODE. (Art) - Add timeout_base_ms argument. (Ville) v7: - Clarify code comment about first queued request. (Chris) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: <stable@vger.kernel.org> # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms Cc: <stable@vger.kernel.org> # v4.2- Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume") Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com (cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-20drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is settingHans de Goede1-1/+2
Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161201202925.12220-3-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit b2b45fcd921e864a5e9bbc7aa55dee96d5e11c06) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-20drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESETHans de Goede2-5/+11
Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline i915 code was doing the same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET / MIPI_SEQ_DEASSERT_RESET. Looking at the naming of the sequences that is the right thing to do, but the problem is, that the old mainline code and the ADF code was actually calling the right sequence (tested on a cube iwork8 air tablet), and the swapping of the calling breaks things. This breakage was likely not noticed in testing because on cherrytrail, currently chv_exec_gpio ends up disabling the gpio pins rather then setting them (this is fixed in the next patch in this patch-set). This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's places in the enum defining them, so that their (new) names match their actual use. Changes in v2: -Add a comment to the enum explaining that the assert/reassert names are swapped in the spec Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202150128.29871-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 2b8208ac93be2783edc627fc02d9ca50cc479923) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-20drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gatingHans de Goede1-1/+12
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161202142904.25613-1-hdegoede@redhat.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-20drm/i915: drop the struct_mutex when wedged or trying to resetMatthew Auld1-1/+2
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged or a reset is in progress we bail early but never seem to actually release the lock. Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in display pageflips") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161128103648.9235-1-matthew.auld@intel.com Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v4.7+ (cherry picked from commit ddbb271aea87fc6004d3c8bcdb0710e980c7ec85) Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit e411072d5740a49cdc9d0713798c30440757e451) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-12-20drm/i915: fully apply WaSkipStolenMemoryFirstPagePaulo Zanoni3-26/+22
Don't even tell the mm allocator to handle the first page of stolen on the affected platforms. This means that we won't inherit the FB in case the BIOS decides to put it at the start of stolen. But the BIOS should not be putting it at the start of stolen since it's going to get corrupted. I suppose the bug here is that some pixels at the very top of the screen will be corrupted, so it's not exactly easy to notice. We have confirmation that the first page of stolen does actually get corrupted, so I really think we should do this in order to avoid any possible future headaches, even if that means losing BIOS framebuffer inheritance. Let's not use the HW in a way it's not supposed to be used. Notice that now ggtt->stolen_usable_size won't reflect the ending address of the stolen usable range anymore, so we have to fix the places that rely on this. To simplify, we'll just use U64_MAX. v2: don't even put the first page on the mm (Chris) v3: drm_mm_init() takes size instead of end as argument (Ville) v4: add a comment explaining the reserved ranges (Chris) use 0 for start and U64_MAX for end when possible (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1481808235-27607-1-git-send-email-paulo.r.zanoni@intel.com
2016-12-20drm/i915: skip the first 4k of stolen memory on everything >= gen8Paulo Zanoni1-3/+2
BSpec got updated and this workaround is now listed as standard required programming for all subsequent projects. This is confirmed to fix Skylake screen flickering issues (probably caused by the fact that we initialized a ring in the first page of stolen, but I didn't 100% confirm this theory). v2: this is the patch that fixes the screen flickering, document it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605 Cc: stable@vger.kernel.org Tested-by: Dominik Klementowski <dominik232@gmail.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481727338-9901-1-git-send-email-paulo.r.zanoni@intel.com
2016-12-20drm/i915: Add a test that we terminate the trimmed sgtable as expectedChris Wilson1-0/+1
In commit 0c40ce130e38 ("drm/i915: Trim the object sg table"), we expect to copy exactly orig_st->nents across and allocate the table thusly. The copy loop should therefore end with the new_sg being NULL. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161219124346.550-2-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-12-20drm/i915: Fallback to single PAGE_SIZE segments for DMA remappingChris Wilson1-4/+22
If we at first do not succeed with attempting to remap our physical pages using a coalesced scattergather list, try again with one scattergather entry per page. This should help with swiotlb as it uses a limited buffer size and only searches for contiguous chunks within its buffer aligned up to the next boundary - i.e. we may prematurely cause a failure as we are unable to utilize the unused space between large chunks and trigger an error such as: i915 0000:00:02.0: swiotlb buffer is full (sz: 1630208 bytes) Reported-by: Juergen Gross <jgross@suse.com> Tested-by: Juergen Gross <jgross@suse.com> Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161219124346.550-1-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-12-20drm/i915/breadcrumbs: s/container_of/rb_entry/Chris Wilson1-2/+2
In keeping with commit f802cf7e0986 ("drm/i915/debugfs: use rb_entry()"), convert the primary user of the rbtrees over to using rb_entry rather than the equivalent container_of. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161220104003.8044-1-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-12-20drm/i915/debugfs: use rb_entry()Geliang Tang1-3/+3
To make the code clearer, use rb_entry() instead of container_of() to deal with rbtree. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/62ce937ae9a341421942b4418515610d055fa653.1482158544.git.geliangtang@gmail.com
2016-12-19drm/amdgpu: fix cursor setting of dce6/dce8Flora Cui2-7/+1
Fixes: 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register when necessary") Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-12-19drm/i915: Simplify gem stolen initialization.Rodrigo Vivi1-5/+4
Let's take usage of IS_LP to simplify the gem stolen initialization as suggest by Tvrtko. Also assume that all new LP platforms follows the chv+ and others bdw+. v2: Remove the wrong commit message about bxt and glk. (Ander) Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482174347-24911-1-git-send-email-rodrigo.vivi@intel.com
2016-12-19drm/i915: Rename get stolen functions for LP platforms chv+Rodrigo Vivi1-2/+2
gen8 is used for both Broadwell and Cherryview but this function here is only Cherryview and all next atom LP platforms. So let's rename it to avoid confusion as suggested by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482096988-400-2-git-send-email-rodrigo.vivi@intel.com
2016-12-19drm/i915: Expand is_lp backwards to gen8_lp and gen7_lp.Rodrigo Vivi2-0/+3
Valleyview/Baytrail (gen7_lp) and Cherryview/Braswell (gen8_lp) are both Atom platforms like Broxton/Apollolake and Geminilake. So let's expand this is_lp back to these platforms and create the IS_LP(dev_priv) so we can start simplifying a bit our if/else for platform lists. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482096988-400-1-git-send-email-rodrigo.vivi@intel.com
2016-12-19drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.Maarten Lankhorst3-18/+163
Do something similar to vc4, only allow updating the cursor state in-place through a fastpath when the watermarks are unaffected. This will allow cursor movement to be smooth, but changing cursor size or showing/hiding cursor will still fall back so watermarks can be updated. Only moving and changing fb is allowed. Changes since v1: - Set page flip to always_unused for trybot. - Copy fence correctly, ignore plane_state->state, should be NULL. - Check crtc_state for !active and modeset, go to slowpath if the case. Changes since v2: - Make error handling work correctly. (Matthew Auld) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/a8e4cb00-5171-14e5-bbe3-dadb654ff296@linux.intel.com
2016-12-19drm/atomic: Remove drm_atomic_helper_framebuffer_changed.Maarten Lankhorst1-35/+0
This function is now completely unused, zap it. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481204729-9058-6-git-send-email-maarten.lankhorst@linux.intel.com
2016-12-19drm/atomic: Wait for vblank whenever a plane is added to state.Maarten Lankhorst1-5/+1
There's 2 reasons for doing a vblank wait: - To fulfill uabi expectations, but the legacy ioctls are ill-defined enough that we really only need this when we do send out an event. - To make sure we don't tear down mappings before the scanout engine stops accessing it. The later is problematic with the current code since e.g. rotation might need a different mapping than normal orientation. And rotation is a plane property, and not on the fb. Hence we need to remove this optimization. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Completely new commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481204729-9058-5-git-send-email-maarten.lankhorst@linux.intel.com
2016-12-19drm/atomic: Clean up wait_for_vblanks, v2.Maarten Lankhorst1-14/+14
Stop relying on a per crtc_state last_vblank_count, we shouldn't touch crtc_state after commit. Move it to atomic_state->crtcs. Also stop re-using new_crtc_state->enable, we can now simply set a bitmask with crtc_crtc_mask. Changes since v1: - Keep last_vblank_count in __drm_crtc_state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/8e4759a4-24d3-3f80-bd1a-1e7a9c83b612@linux.intel.com
2016-12-19drm/atomic: Unconditionally call prepare_fb.Maarten Lankhorst1-9/+0
Atomic drivers may set properties like rotation on the same fb, which may require a call to prepare_fb even when framebuffer stays identical. Instead of handling all the special cases in the core, let the driver decide when prepare_fb and cleanup_fb are noops. This is a revert of: commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba Author: Keith Packard <keithp@keithp.com> Date: Sat Jun 4 01:16:22 2016 -0700 drm: Don't prepare or cleanup unchanging frame buffers [v3] The original commit mentions that this prevents waiting in i915 on all previous rendering during cursor updates, but there are better ways to fix this. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/6d82f9b6-9d16-91d1-d176-4a37b09afc44@linux.intel.com
2016-12-19drm/i915: Prevent PPS stealing from a normal DP port on VLV/CHVVille Syrjälä2-47/+111
VLV apparently gets upset if the PPS for a pipe currently driving an external DP port gets used for VDD stuff on another eDP port. The DP port falls over and fails to retrain when this happens, leaving the user staring at a black screen. Let's fix it by also tracking which pipe is driving which DP/eDP port. We'll track this under intel_dp so that we'll share the protection of the pps_mutex alongside the pps_pipe tracking, since the two things are intimately related. I had plans to reduce the protection of pps_mutex to cover only eDP ports, but with this we can't do that. Well, for for VLV/CHV at least. For other platforms it should still be possible, which would allow AUX communication to occur in parallel for multiple DP ports. v2: Drop stray crap from a comment (Imre) Grab pps_mutex when clearing active_pipe Fix a typo in the commit message v3: Make vlv_active_pipe() static Cc: stable@vger.kernel.org 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/1481738423-29738-1-git-send-email-ville.syrjala@linux.intel.com
2016-12-19drm/i915: Drop mutex after successful kref_put_mutex()Chris Wilson1-3/+4
The kref_put_mutex() returns with the mutex held after freeing the object - so we must remember to drop it... Fixes: 69df05e11ab8 ("drm/i915: Simplify releasing context reference") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161219101357.28140-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2016-12-19drm: omapdrm: Perform initialization/cleanup at probe/remove timeLaurent Pinchart2-108/+105
The drm driver .load() operation is prone to race conditions as it initializes the driver after registering the device nodes. Its usage is deprecated, inline it in the probe function and call drm_dev_alloc() and drm_dev_register() explicitly. For consistency inline the .unload() handler in the remove function as well. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: Move vblank cleanup from unregister to releaseLaurent Pinchart1-2/+2
Calling drm_vblank_cleanup() in drm_dev_unregister() causes issues with drivers that have moved away from the .load() and .unload() midlayer. Those drivers call drm_dev_unregister() as the first operation at unbind time, before shutting down the device. This results in warnings due to drm_vblank_cleanup() being called with vblank interrupts still active, and then to vblank events being sent after cleanup. Fix the problem by moving vblank cleanup from drm_dev_unregister() to drm_dev_release() that is guaranteed to be called after drivers shut down the device. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
2016-12-19drm: omapdrm: Use sizeof(*var) instead of sizeof(type) for structuresLaurent Pinchart5-8/+7
By linking the sizeof to a variable type the code will be less prone to bugs due to future type changes of variables. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Remove global variablesLaurent Pinchart2-21/+24
Move the list of pending IRQ wait instances to the omap_drm_private structure and the wait queue head to the IRQ wait structure. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Simplify IRQ wait implementationLaurent Pinchart2-74/+37
Now that the IRQ list is used for IRQ wait only we can merge omap_drm_irq and omap_irq_wait and simplify the implementation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Inline the pipe2vbl functionLaurent Pinchart3-11/+3
The function is only used in omap_irq.c and is just a wrapper around dispc_mgr_get_vsync_irq(). Remove it and call the dispc function directly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Don't call DISPC power handling in IRQ wait functionsLaurent Pinchart1-4/+0
The IRQ wait functions are called from the DSS enable and disable operations only, where the DISPC is guaranteed to be enabled. There's no need for manual DISPC power management there. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Remove unused parameter from omap_drm_irq handlerLaurent Pinchart2-3/+3
The only omap_drm_irq handler doesn't use the irqstatus parameter passed to the function. Remove it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Don't expose the omap_irq_(un)register() functionsLaurent Pinchart2-22/+5
The IRQ registration functions are not used outside of their compilation unit, make them static. As the __omap_irq_(un)register() functions are only called by their omap_irq_(un)register() counterparts, merge them together. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Keep vblank interrupt enabled while CRTC is activeLaurent Pinchart3-47/+37
Instead of going through a complicated private IRQ registration mechanism, handle the vblank interrupt activation with the standard drm_crtc_vblank_get() and drm_crtc_vblank_put() mechanism. This will let the DRM core keep the vblank interrupt enabled as long as needed to update the frame counter. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Use a spinlock to protect the CRTC pending flagLaurent Pinchart1-11/+22
The CRTC pending flag will need to be accessed atomically in the vblank interrupt handler, memory barriers won't be enough to protect it. Use a spinlock instead. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Prevent processing the same event multiple timesLaurent Pinchart1-8/+15
The vblank interrupt is disabled after one occurrence, preventing the atomic update event from being processed twice. However, this also prevents the software frame counter from being updated correctly that would require vblank interrupts to be kept enabled while the CRTC is active. In preparation for vblank interrupt fixes, make sure that the atomic update event will be processed once only when the vblank interrupt will be kept enabled. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Check the CRTC software state at enable/disable timeLaurent Pinchart3-18/+16
The omapdrm DSS manager enable/disable operations check the DSS manager state to avoid double enabling/disabling. Check the CRTC software state instead to decrease the dependency of the DRM layer to the DSS layer. The dispc_mgr_is_enabled() function then be turned into a static function, but needs to be moved up in its compilation unit to avoid a forward declaration. Add a WARN_ON to catch double enable or disable that should be prevented by the DRM core and would be a clear sign of a bug. The warning should eventually be removed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Let the DRM core skip plane commit on inactive CRTCsLaurent Pinchart2-2/+9
The DRM core supports skipping plane update for inactive CRTCs for hardware that don't need it or can't cope with it. That's our case, and the driver already skips flushing planes on inactice CRTCs. We can't remove the check from the driver, as active CRTCs are disabled at the hardware level when an atomic flush is performed if a mode set is pending. There's however no need to forward the plane commit calls to the driver, so use the DRM core infrastructure to skip them with a detailed comment to explain why the check must still be kept in the driver. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Replace DSS manager state check with omapdrm CRTC stateLaurent Pinchart1-9/+13
Instead of conditioning planes update based on the DSS manager hardware state, use the enabled field newly added to the omap_crtc structure. This reduces the dependency from the DRM layer to the DSS layer. The enabled field is a transitory measure, the implementation should use the CRTC atomic state instead. However, given that CRTCs are currently not enabled/disabled through their .enable() and .disable() operations but through a convoluted code paths starting at the associated encoder operations, there is not clear guarantee that the atomic state always matches the hardware state. This will be refactored later, at which point the enabled field will be removed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Handle OCP error IRQ directlyLaurent Pinchart2-19/+10
Instead of going through a complicated registration mechanism, just call the OCP error IRQ handler directly from the main IRQ handler. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Handle CRTC error IRQs directlyLaurent Pinchart3-10/+11
Instead of going through a complicated registration mechanism, just expose the CRTC error IRQ function and call it directly from the main IRQ handler. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: Handle FIFO underflow IRQs internallyLaurent Pinchart4-30/+67
As the FIFO underflow IRQ handler just prints an error message to the kernel log, simplify the code by not registering one IRQ handler per plane but print the messages directly from the main IRQ handler. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: fb: Turn framebuffer creation error messages into debugLaurent Pinchart1-5/+5
Don't print userspace parameters validation failures as error messages to avoid giving userspace the ability to flood the kernel log. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: fb: Simplify mode command checks when creating framebufferLaurent Pinchart1-27/+23
The hardware requires all planes to have an identical pitch in number of pixels. Given that all supported formats use the same number of bytes per pixel in all planes, framebuffer creation checks can be simplified. The implementations assumes that no format use more than two planes which is true with the existing hardware. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: fb: Simplify objects lookup when creating framebufferLaurent Pinchart2-36/+18
Merge the single-user objects_lookup inline function into its caller, allowing reuse of the error code path. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: fb: Use format information provided by the DRM coreLaurent Pinchart1-45/+46
The driver stores in a custom structure named format several pieces of information about the format that are available in the DRM core. Remove them and get the information from the DRM core instead. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-19drm: omapdrm: fb: Limit number of planes per framebuffer to twoLaurent Pinchart1-2/+2
The only multi-planar format supported by the driver is NV12, there will thus never be more than two planes per framebuffer. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2016-12-18drm/i915: Swap if(enable_execlists) in i915_gem_request_alloc for a vfuncChris Wilson5-10/+8
A fairly trivial move of a matching pair of routines (for preparing a request for construction) onto an engine vfunc. The ulterior motive is to be able to create a mock request implementation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-7-chris@chris-wilson.co.uk
2016-12-18drm/i915/execlists: Request the kernel context be pinned highChris Wilson1-2/+6
PIN_HIGH is an expensive operation (in comparison to allocating from the hole stack) unsuitable for frequent use (such as switching between contexts). However, the kernel context should be pinned just once for the lifetime of the driver, and here it is appropriate to keep it out of the mappable range (in order to maximise mappable space for users). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-6-chris@chris-wilson.co.uk
2016-12-18drm/i915: Mark the shadow gvt context as closedChris Wilson2-9/+2
As the shadow gvt is not user accessible and does not have an associated vm, we can mark it as closed during its construction. This saves leaking the internal knowledge of i915_gem_context into gvt/. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-5-chris@chris-wilson.co.uk