summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_drv.h
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Remove update_sprite_watermarks.Maarten Lankhorst2016-02-251-1/+0
| | | | | | | | | Commit 791a32be6eb2 ("drm/i915: Drop intel_update_sprite_watermarks") removes the use of this variable, but forgot to remove it. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-5-git-send-email-maarten.lankhorst@linux.intel.com
* drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.Maarten Lankhorst2016-02-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we perform our own wait in post_plane_update, but the atomic core performs another one in wait_for_vblanks. This means that 2 vblanks are done when a fb is changed, which is a bit overkill. Merge them by creating a helper function that takes a crtc mask for the planes to wait on. The broadwell vblank workaround may look gone entirely but this is not the case. pipe_config->wm_changed is set to true when any plane is turned on, which forces a vblank wait. Changes since v1: - Removing the double vblank wait on broadwell moved to its own commit. Changes since v2: - Move out POWER_DOMAIN_MODESET handling to its own commit. Changes since v3: - Do not wait for vblank on legacy cursor updates. (Ville) - Move broadwell vblank workaround comment to page_flip_finished. (Ville) Changes since v4: - Compile fix, legacy_cursor_flip -> *_update. Changes since v5: - Kill brackets. - Add WARN_ON when wait_for_vblanks fails. - Remove extra newlines. - Split the checks whether vblank is needed to a separate function, with comments why a vblank is needed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56CD84DA.5030507@linux.intel.com Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
* drm/i915: Make sure pipe interrupts are processed before turning off power ↵Ville Syrjälä2016-02-221-0/+2
| | | | | | | | | | | | | | | | well on BDW+ Starting from BDW the DE_PIPE interrupts for pipe B and C belong to the relevant display power well. So we should make sure we've finished processing them before turning off the power well. The pipe interrupts shouldn't really happen at this point anymore since we've already shut down the planes/pipes/whatnot, but being a bit paranoid shouldn't hurt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
* drm/i915/gen9: Write dc state debugmask bits only onceMika Kuoppala2016-02-221-1/+1
| | | | | | | | | | | | DMC debugmask bits should stick so no need to write them everytime dc state is changed. v2: Write after firmware has been successfully loaded (Ville) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-5-git-send-email-mika.kuoppala@intel.com
* drm/i915: Use atomic state to obtain load detection crtc, v3.Maarten Lankhorst2016-02-181-3/+1
| | | | | | | | | | | | | | | Instead of restoring dpms and a flag for whether a temp fb is allocated duplicate an atomic state before the new state is committed, and commit it the old state in intel_release_load_detect_pipe. Changes since v1: - Use a real atomic state. (Ville) Changes since v2: - Do not preserve shared_dpll any more, no need to do so. (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-2-git-send-email-maarten.lankhorst@linux.intel.com
* drm/i915: Add helper to get a display power ref if it was already enabledImre Deak2016-02-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always hold. In such cases we get either the wakeref not held, or an unclaimed register access error message. To fix this in a future-proof way that's independent of other locks wrap any such access with a get_ref_if_enabled()/put_ref() pair. Kudos to Ville and Joonas for the ideas of this new interface. v2: - init the power_domains ptr when declaring it everywhere (Joonas) v3: - don't report the device to be powered if runtime PM is disabled CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com
* drm/i915: edp resume/On time optimization.Abhay Kumar2016-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if this time is already spent in suspend/poweron time. v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle delay calculation(Ville). v3: Addressed below comments 1. Tracking time from where last powercycle is initiated. 2. Used ktime_get_bootime() wrapper for boottime clock. 3. Used ktime_ms_delta() to get time difference. v4: Updated v3 change log in detail. v5: Removed static from panel_power_on_time(Stéphane). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Abhay Kumar <abhay.kumar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453513144-14135-1-git-send-email-abhay.kumar@intel.com
* Merge tag 'topic/drm-misc-2016-02-12' into drm-intel-next-queuedDaniel Vetter2016-02-121-1/+0
|\ | | | | | | | | | | Backmerge to get at the new encoder_mask support in atomic helpers. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * Merge tag 'topic/drm-misc-2016-02-08' of ↵Dave Airlie2016-02-091-1/+0
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next First drm-misc pull req for 4.6. Big one is the drm_event cleanup, which is also prep work for adding android fence support to kms (Gustavo is planning to do that). Otherwise random small bits all over. * tag 'topic/drm-misc-2016-02-08' of git://anongit.freedesktop.org/drm-intel: (33 commits) gma500: clean up an excessive and confusing helper drm/gma500: remove helper function drm/vmwgfx: Nuke preclose hook drm/vc4: Nuke preclose hook drm/tilcdc: Nuke preclose hook drm/tegra: Stop cancelling page flip events drm/shmob: Nuke preclose hook drm/rcar: Nuke preclose hook drm/omap: Nuke close hooks drm/msm: Nuke preclose hooks drm/imx: Unconfuse preclose logic drm/exynos: Remove event cancelling from postclose drm/atmel: Nuke preclose drm/i915: Nuke intel_modeset_preclose drm: Nuke vblank event file cleanup code drm: Clean up pending events in the core drm/vblank: Use drm_event_reserve_init drm/vmwgfx: fix a NULL dereference drm/crtc-helper: Add caveat to disable_unused_functions doc drm/gma500: Remove empty preclose hook ...
| | * drm/i915: Nuke intel_modeset_precloseDaniel Vetter2016-02-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the drm core unlinks/disarms events there's no need to do so ourselves anymore. Nuke the code. Acked-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453756616-28942-4-git-send-email-daniel.vetter@ffwll.ch
| | * drm/i915: Tune down rpm wakelock debug checksDaniel Vetter2016-01-131-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They're causing massive amounts of dmesg noise and hence CI noise all over the place. Enabling them for a bit was good enough to refresh our task list of what's still needed to enable rpm by default. To make sure we're not forgetting to make this noisy again add a FIXME comment. Fixes: da5827c36607 ("drm/i915: add assert_rpm_wakelock_held helper") Cc: Imre Deak <imre.deak@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452012847-4737-1-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (cherry picked from commit becd9ca2de656ccd8d02c434742388aead336147) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | drm/i915: Remove atomic.pre_disable_primary.Maarten Lankhorst2016-02-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | This can be derived from the atomic state in pre_plane_update, which makes it more clear when it's supposed to be called. Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454514805-10595-3-git-send-email-maarten.lankhorst@linux.intel.com
* | | drm/i915: Remove intel_crtc->atomic.disable_ips.Maarten Lankhorst2016-02-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a revert of commit 066cf55b9ce3 "drm/i915: Fix IPS related flicker". intel_pre_disable_primary already handles this, and now everything goes through the atomic path there's no need to try to disable ips twice. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454514805-10595-2-git-send-email-maarten.lankhorst@linux.intel.com
* | | drm/i915/bxt: Check BIOS RC6 setup before enabling RC6Sagar Arun Kamble2016-02-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 setup registers. If those are not setup Driver should not enable RC6. For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values to know if BIOS has enabled HW/SW RC6. This will also enable user to control RC6 using BIOS settings alone. RC6 related instability can be avoided by disabling via BIOS settings till driver fixes it. v2: Had placed logic in gen8 function by mistake. Fixed it. Ensuring RPM is not enabled in case BIOS disabled RC6. v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel) Runtime PM enabling happens before gen9_enable_rc6. Moved the updation of enable_rc6 parameter in intel_uncore_sanitize. v4: Added elaborate check for BIOS RC6 setup. Prepared check_pctx for bxt. (Imre) v5: Caching reserved stolen base and size in the driver private data. Reorganized RC6 setup check. Moved from gen9_enable_rc6 to intel_uncore_sanitize. (Imre) v6: Rebasing on the patch submitted by Imre that moves gem_init_stolen earlier in the load. v7: Removed PWRCTX_MAXCNT_VCSUNIT1 check as it applies to SKL. (Imre) v8: Fixed formatting and checkpatch issues. Fixed functional issue where RC6 ctx size check was missing. (Imre) Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454697809-22113-1-git-send-email-sagar.a.kamble@intel.com
* | | drm/i915/fbc: choose the new FBC CRTC during atomic checkPaulo Zanoni2016-01-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This opens the possibility of implementing nicer schemes to choose the CRTC, such as checking the amount of stolen memory available, or choosing the best pipe on platforms that don't die FBC to pipe or plane A. This code was written for another refactor that I ended up discarding, so I don't actually need it, but I figured this patch would be an improvement on its own so I kept it on the series. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-18-git-send-email-paulo.r.zanoni@intel.com
* | | drm/i915/fbc: rewrite the multiple_pipes_ok() code for lockingPaulo Zanoni2016-01-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Older FBC platforms have this restriction where FBC can't be enabled if multiple pipes are enabled. In the current code, we disable FBC before the second pipe becomes visible. One of the problems with this code is that the current multiple_pipes_ok() implementation just iterates through all CRTCs looking at their states, but it doesn't make sure that the state locks are grabbed. It also can't just grab the locks for every CRTC since this would kill one of the biggest advantages of atomic modesetting. After the recent FBC changes, we now have the appropriate locks for the given CRTC, so we can just try to maintain the state of each CRTC and update it once intel_fbc_pre_update is called. As a last note, I don't have gen 2/3 machines to test this code. My current plan is to enable FBC on just the newer platforms, so this patch is just an attempt to get the gen 2/3 code at least looking sane, so if one day someone decide to fix FBC on these platforms, they may have less work to do. Not-tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (only on HSW+) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-16-git-send-email-paulo.r.zanoni@intel.com
* | | drm/i915/fbc: rename the FBC disable functionsPaulo Zanoni2016-01-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of: - intel_fbc_disable_crtc(crtc) - intel_fbc_disable(dev_priv) we now have: - intel_fbc_disable(crtc) - intel_fbc_global_disable(dev_priv) This is because all the other functions that take a CRTC are called - intel_fbc_something(crtc) Instead of: - intel_fbc_something_crtc(crtc) And I also hope that the word "global" is going to help make it more explicit that "global" is the unusual case, not the opposite. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-14-git-send-email-paulo.r.zanoni@intel.com
* | | drm/i915/fbc: unexport intel_fbc_deactivatePaulo Zanoni2016-01-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the addition and usage of intel_fbc_pre_update, intel_fbc_deactivate is not used anymore outside intel_fbc.c, so kill the exported function and rename __intel_fbc_deactivate. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-13-git-send-email-paulo.r.zanoni@intel.com
* | | drm/i915/fbc: fix the FBC state checking codePaulo Zanoni2016-01-291-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate during atomic commits. This will continue to guarantee that we deactivate FBC and it will also update the state checking structures at the correct time. Then, later, at the point where we were calling intel_fbc_update, we'll only need to call intel_fbc_post_update. Also add the proper warnings in case we don't have the appropriate locks. Daniel mentioned the warnings will have to be removed for async commits, but let's keep them here while we can. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-12-git-send-email-paulo.r.zanoni@intel.com
* | | drm/i915: Make display gtt offsets u32Ville Syrjälä2016-01-281-6/+6
|/ / | | | | | | | | | | | | | | | | Using 'unsigned long' for ggtt offsets doesn't make much sense. Use 'u32' instead since we've not yet seen a >4GiB ggtt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Do not put big intel_crtc_state on the stackTvrtko Ursulin2016-01-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having this on stack triggers the -Wframe-larger-than=1024 and is not nice to put such big things on the kernel stack anyway. This required a little bit of refactoring to handle the new failure path from vlv_force_pll_on. v2: Corrected some whitespace. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: John Harrison <john.c.harrison@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453217117-26125-1-git-send-email-tvrtko.ursulin@linux.intel.com
* | Revert "drm/i915: Add two-stage ILK-style watermark programming (v10)"Matt Roper2016-01-201-26/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 396e33ae204f52abebec9e578f44c749305500f4. This commit was triggering some FIFO underrun warnings on ILK-IVB platforms (but surprisingly not on HSW/BDW that share more or less the same codepaths). These underruns were caught by the continuous integration (CI) system and could be reproduced consistently when running the basic acceptance tests (BAT) on the affected platforms. Note that this revert will cause a visible regression for some end-users; the "flicker when mouse moves between monitors in X" issue that was reported before this patch was merged will now return. However regressions that are visible to CI have higher priority since they prevent proper testing of future patches on those platforms. Hopefully we'll be able to figure out the cause of the underruns quickly and remerge an improved version of this patch to fix the regression. Cc: Daniel Vetter <daniel@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93640 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453232584-8543-1-git-send-email-matthew.d.roper@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: s/intel_gen4_compute_page_offset/intel_compute_tile_offset/Ville Syrjälä2016-01-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Since intel_gen4_compute_page_offset() can now handle tiling formats all the way down to gen2, rename it to intel_compute_tile_offset(). Not that we actually use it on gen2/3 since there's no DSPSURF etc. registers which would take a page aligned address. v2: s/page/tile/ (Daniel) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-7-git-send-email-ville.syrjala@linux.intel.com
* | drm/i915: Redo intel_tile_height() as intel_tile_size() / intel_tile_width()Ville Syrjälä2016-01-131-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | I find more usual to think about tile widths than heights, so changing the intel_tile_height() to calculate the tile height as tile_size/tile_width is easier than the opposite to the poor brain. v2: Reorder arguments for consistency Constify dev_priv arguments Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-4-git-send-email-ville.syrjala@linux.intel.com
* | drm/i915: Factor out intel_tile_width()Ville Syrjälä2016-01-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull the tile width calculations from intel_fb_stride_alignment() into a new function intel_tile_width(). Also take the opportunity to pass aroun dev_priv instead of dev to intel_fb_stride_alignment(). v2: Reorder argumnents to be more consistent with other functions Change intel_fb_stride_alignment() to accept dev_priv instead of dev v3: Deal with Y tilling (Daniel) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-3-git-send-email-ville.syrjala@linux.intel.com
* | drm/i915: Pass modifier instead of tiling_mode to gen4_compute_page_offset()Ville Syrjälä2016-01-131-2/+2
| | | | | | | | | | | | | | | | | | In preparation for handling more than X tiling, pass the fb modifier to gen4_compute_page_offset() instead of the obj->tiling_mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-2-git-send-email-ville.syrjala@linux.intel.com
* | drm/i915: Kill intel_prepare_ddi()Ville Syrjälä2016-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Move the ddi buffer translation programming to occur from the encoder .pre_enable() hook, for just the ddi port we are enabling. Previously we used to reprogram the translations for all ddi ports during init and during power well enabling. v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel) Resolve conflicts due to dev_priv->atomic_cdclk_freq Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Store max lane count in intel_digital_portVille Syrjälä2016-01-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | Rather than having open coded checks for the DDI A/E configuration, just store the max supported lane count in intel_digital_port. We had an open coded check for DDI A, but not for DDI E. So we may have been vilating the DDI E max lane count. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Remove commit_plane function pointer.Maarten Lankhorst2016-01-071-2/+0
| | | | | | | | | | | | | | | | | | | | With sprites, cursors and primary planes taking the atomic state this is now unused. It's removed in a separate commit to allow a revert. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-8-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* | drm/i915: Use passed plane state for sprite planes, v4.Maarten Lankhorst2016-01-071-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't use plane->state directly, use the pointer from commit_plane. Changes since v1: - Fix uses of plane->state->rotation and color key to use the passed state too. - Only pass crtc_state and plane_state to update_plane. Changes since v2: - Rebased. Changes since v3: - Small whitespace changes and only assign 1 variable per line. - Constify plane_state and crtc_state. (vsyrjala) 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/1452164052-21752-2-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* | drm/i915: Add two-stage ILK-style watermark programming (v10)Matt Roper2016-01-071-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means they can be programmed immediately when we commit the atomic state (without waiting for a vblank). Once the vblank does happen, we can then re-program watermarks to the more optimal final value. v2: Significant rebasing/rewriting. v3: - Move 'need_postvbl_update' flag to CRTC state (Daniel) - Don't forget to check intermediate watermark values for validity (Maarten) - Don't due async watermark optimization; just do it at the end of the atomic transaction, after waiting for vblanks. We do want it to be async eventually, but adding that now will cause more trouble for Maarten's in-progress work. (Maarten) - Don't allocate space in crtc_state for intermediate watermarks on platforms that don't need it (gen9+). - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit now that ilk_update_wm is gone. v4: - Add a wm_mutex to cover updates to intel_crtc->active and the need_postvbl_update flag. Since we don't have async yet it isn't terribly important yet, but might as well add it now. - Change interface to program watermarks. Platforms will now expose .initial_watermarks() and .optimize_watermarks() functions to do watermark programming. These should lock wm_mutex, copy the appropriate state values into intel_crtc->active, and then call the internal program watermarks function. v5: - Skip intermediate watermark calculation/check during initial hardware readout since we don't trust the existing HW values (and don't have valid values of our own yet). - Don't try to call .optimize_watermarks() on platforms that don't have atomic watermarks yet. (Maarten) v6: - Rebase v7: - Further rebase v8: - A few minor indentation and line length fixes v9: - Yet another rebase since Maarten's patches reworked a bunch of the code (wm_pre, wm_post, etc.) that this was previously based on. v10: - Move wm_mutex to dev_priv to protect against racing commits against disjoint CRTC sets. (Maarten) - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452108870-24204-1-git-send-email-matthew.d.roper@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
* | drm/i915: Tune down rpm wakelock debug checksDaniel Vetter2016-01-061-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They're causing massive amounts of dmesg noise and hence CI noise all over the place. Enabling them for a bit was good enough to refresh our task list of what's still needed to enable rpm by default. To make sure we're not forgetting to make this noisy again add a FIXME comment. Fixes: da5827c36607 ("drm/i915: add assert_rpm_wakelock_held helper") Cc: Imre Deak <imre.deak@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452012847-4737-1-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* | drm/i915: Keep track of the cdclk as if all crtc's were active.Maarten Lankhorst2015-12-221-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On skylake when calculating plane visibility with the crtc in dpms off mode the real cdclk may be different from what it would be if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock) from skl_max_scale. The fix is to keep a atomic_cdclk that would be true if all crtc's were active. This is required to get the same calculations done correctly regardless of dpms mode. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-12-git-send-email-maarten.lankhorst@linux.intel.com
* | drm/i915: Do not acquire crtc state to check clock during modeset, v4.Maarten Lankhorst2015-12-221-1/+6
|/ | | | | | | | | | | | | | | | | | | | | | Parallel modesets are still not allowed, but this will allow updating a different crtc during a modeset if the clock is not changed. Additionally when all pipes are DPMS off the cdclk will be lowered to the minimum allowed. Changes since v1: - Add dev_priv->active_crtcs for tracking which crtcs are active. - Rename min_cdclk to min_pixclk and move to dev_priv. - Add a active_crtcs mask which is updated atomically. - Add intel_atomic_state->modeset which is set on modesets. - Commit new pixclk/active_crtcs right after state swap. Changes since v2: - Make the changes related to max_pixel_rate calculations more readable. Changes since v3: - Add cherryview and missing WARN_ON to readout. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com>
* drm/i915: add support for checking RPM atomic sectionsImre Deak2015-12-171-0/+17
| | | | | | | | | | | | | | | | | | | | | | In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic section and that we hold the wakelock at the beginning of the section. Motivated by Chris. v2-v3: - unchanged v4: - swap the order of atomic_read() and assert_rpm_wakelock_held() in assert_rpm_atomic_begin() to avoid race Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-10-git-send-email-imre.deak@intel.com
* drm/i915: add support for checking if we hold an RPM referenceImre Deak2015-12-171-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm, we assert that the device is not suspended until the point when the device is truly put to a suspended state. This is fine, but we can catch more problems if we check that RPM refcount is non-zero. After that one drops to zero we shouldn't access the device any more, even if the actual device suspend may be delayed. Change assert_rpm_wakelock_held() accordingly to check for a non-zero RPM refcount in addition to the current device-not-suspended check. For the new asserts to work we need to annotate every place explicitly in the code where we expect that the device is powered. The places where we only assume this, but may not hold an RPM reference: - driver load We assume the device to be powered until we enable RPM. Make this explicit by taking an RPM reference around the load function. - system and runtime sudpend/resume handlers These handlers are called when the RPM reference becomes 0 and know the exact point after which the device can get powered off. Disable the RPM-reference-held check for their duration. - the IRQ, hangcheck and RPS work handlers These handlers are flushed in the system/runtime suspend handler before the device is powered off, so it's guaranteed that they won't run while the device is powered off even though they don't hold any RPM reference. Disable the RPM-reference-held check for their duration. In all these cases we still check that the device is not suspended. These explicit annotations also have the positive side effect of documenting our assumptions better. This caught additional WARNs from the atomic modeset path, those should be fixed separately. v2: - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville) v3: - use a new dedicated RPM wakelock refcount to also catch cases where our own RPM get/put functions were not called (Chris) - assert also that the new RPM wakelock refcount is 0 in the RPM suspend handler (Chris) - change the assert error message to be more meaningful (Chris) - prevent false assert errors and check that the RPM wakelock is 0 in the RPM resume handler too - prevent false assert errors in the hangcheck work too - add a device not suspended assert check to the hangcheck work v4: - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts and wakelock_count to wakeref_count - disable the wakeref asserts in the IRQ handlers and RPS work too - update/clarify commit message v5: - mark places we plan to change to use proper RPM refcounting with separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris) 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/1450227139-13471-1-git-send-email-imre.deak@intel.com
* drm/i915: add assert_rpm_wakelock_held helperImre Deak2015-12-171-0/+14
| | | | | | | | | | | | | | | | | | | | | | | As a preparation for follow-up patches add a new helper that checks whether we hold an RPM reference, since this is what we want most of the cases. Atm this helper will only check for the HW suspended state, a follow-up patch will do the actual change to check the refcount instead. One exception is the forcewake release timer function, where it's guaranteed that the HW is on even though the RPM refcount drops to zero. This guarantee is provided by flushing the timer in the runtime suspend handler. So leave the assert_device_not_suspended check in place there. Also rename assert_device_suspended for consistency and export these helpers as a preparation for the follow-up patches. No functional change. v3: - change the assert warning message to be more meaningful (Chris) 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/1450203038-5150-6-git-send-email-imre.deak@intel.com
* drm/i915: Kill intel_crtc->cursor_boVille Syrjälä2015-12-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | The vma may have been rebound between the last time the cursor was enabled and now, so skipping the cursor gtt offset deduction is not safe unless we would also reset cursor_bo to NULL when disabling the cursor. Just thow cursor_bo to the bin instead since it's lost all other uses thanks to universal plane support. Chris pointed out that cursor updates are currently too slow via universal planes that micro optimizations like these wouldn't even help. v2: Add a note about futility of micro optimizations (Chris) Cc: drm-intel-fixes@lists.freedesktop.org References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
* Merge tag 'drm-i915-get-eld' of tiwai/sound into drm-intel-next-queuedDaniel Vetter2015-12-111-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | Add get_eld audio component for i915/HD-audio Currently, the HDMI/DP audio status and ELD are notified and obtained via the hardware-level communication over HD-audio unsolicited event and verbs although the graphics driver holds the exactly same information. As we already have a notification via audio component, this is another step forward; namely, the audio driver may fetch directly the audio status and ELD via the new component op. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: Add get_eld audio componentTakashi Iwai2015-12-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a new i915_audio_component_ops, get_eld(). It's called by the audio driver to fetch the current audio status and ELD of the given HDMI/DP port. It returns the size of expected ELD bytes if it's valid, zero if no valid ELD is found, or a negative error code. The current state of audio on/off is stored in the given pointer, too. Note that the returned size isn't limited to the given max bytes. If the size is greater than the max bytes, it means that only a part of ELD has been copied back. For achieving this implementation, a new field audio_connector is added to struct intel_digital_port. It points to the connector assigned to the given digital port. It's set/reset at each audio enable/disable call in intel_audio.c, and protected with av_mutex. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * Merge tag 'drm-intel-next-2015-11-20-merged' of ↵Dave Airlie2015-12-011-61/+98
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2015-11-20-rebased: 4 weeks because of my vacation, so a bit more: - final bits of the typesafe register mmio functions (Ville) - power domain fix for hdmi detection (Imre) - tons of fixes and improvements to the psr code (Rodrigo) - refactoring of the dp detection code (Ander) - complete rework of the dmc loader and dc5/dc6 handling (Imre, Patrik and others) - dp compliance improvements from Shubhangi Shrivastava - stop_machine hack from Chris to fix corruptions when updating GTT ptes on bsw - lots of fifo underrun fixes from Ville - big pile of fbc fixes and improvements from Paulo - fix fbdev failures paths (Tvrtko and Lukas Wunner) - dp link training refactoring (Ander) - interruptible prepare_plane for atomic (Maarten) - basic kabylake support (Deepak&Rodrigo) - don't leak ringspace on resets (Chris) drm-intel-next-2015-10-23: - 2nd attempt at atomic watermarks from Matt, but just prep for now - fixes all over * tag 'drm-intel-next-2015-11-20-merged' of git://anongit.freedesktop.org/drm-intel: (209 commits) drm/i915: Update DRIVER_DATE to 20151120 drm/i915: take a power domain reference while checking the HDMI live status drm/i915: take a power domain ref only when needed during HDMI detect drm/i915: Tear down fbdev if initialization fails async: export current_is_async() Revert "drm/i915: Initialize HWS page address after GPU reset" drm/i915: Fix oops caused by fbdev initialization failure drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly drm/i915: Stuff rotation params into view union drm/i915: Drop return value from intel_fill_fb_ggtt_view drm/i915 : Fix to remove unnecsessary checks in postclose function. drm/i915: add MISSING_CASE to a few port/aux power domain helpers drm/i915/ddi: fix intel_display_port_aux_power_domain() after HDMI detect drm/i915: Remove platform specific *_dp_detect() functions drm/i915: Don't do edp panel detection in g4x_dp_detect() drm/i915: Send TP1 TP2/3 even when panel claims no NO_TRAIN_ON_EXIT. drm/i915: PSR: Don't Skip aux handshake on DP_PSR_NO_TRAIN_ON_EXIT. drm/i915: Reduce PSR re-activation time for VLV/CHV. drm/i915: Delay first PSR activation. drm/i915: Type safe register read/write ...
| * | drm: Remove unused fbdev_list membersLukas Wunner2015-11-241-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that intel_fbdev->our_mode is unused. Introduced by 79e539453b34 ("DRM: i915: add mode setting support"). Then I noticed that intel_fbdev->fbdev_list is unused as well. Introduced by 386516744ba4 ("drm/fb: fix fbdev object model + cleanup properly.") in i915, nouveau and radeon. Subsequently cargo culted to amdgpu, ast, cirrus, qxl, udl, virtio and mgag200. Already removed from the latter with cc59487a05b1 ("drm/mgag200: 'fbdev_list' in 'struct mga_fbdev' is not used"). Remove it from the others. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: start adding dp mst audioLibin Yang2015-12-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio flag is set. Another separated patches to support DP MST audio will be implemented in audio driver. Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Libin Yang <libin.yang@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449036584-105393-2-git-send-email-libin.yang@linux.intel.com
* | | drm/i915: Calculate watermark related members in the crtc_state, v4.Maarten Lankhorst2015-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes pre/post_wm_update from intel_crtc->atomic, and creates atomic state for it in intel_crtc. Changes since v1: - Rebase on top of wm changes. Changes since v2: - Split disable_cxsr into a separate patch. Changes since v3: - Move some of the changes to intel_wm_need_update. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56603A49.5000507@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Move disable_cxsr to the crtc_state.Maarten Lankhorst2015-12-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | intel_crtc->atomic will be removed later on, move this member to intel_crtc_state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-2-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
* | | drm/i915: introduce intel_fbc_{enable,disable}Paulo Zanoni2015-12-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to call FBC enable/disable only once per modeset, while activate/deactivate/update will be called multiple times. The enable() function will be responsible for deciding if a CRTC will have FBC on it and then it will "lock" FBC on this CRTC: it won't be possible to change FBC's CRTC until disable(). With this, all checks and resource acquisition that only need to be done once per modeset can be moved from update() to enable(). And then the update(), activate() and deactivate() code will also get simpler since they won't need to worry about the CRTC being changed. The disable() function will do the reverse operation of enable(). One of its features is that it should only be called while the pipe is already off. This guarantees that FBC is stopped and nothing is using the CFB. With this, the activate() and deactivate() functions just start and temporarily stop FBC. They are the ones touching the hardware enable bit, so HW state reflects dev_priv->crtc.active. The last function remaining is update(). A lot of times I thought about renaming update() to activate() or try_to_activate() since it's called when we want to activate FBC. The thing is that update() may not only decide to activate FBC, but also deactivate or keep it on the same state, so I'll leave this name for now. Moving code to enable() and disable() will also help in case we decide to move FBC to pipe_config or something else later. The current patch only puts the very basic code on enable() and disable(). The next commits will take care of moving more stuff from update() to the new functions. v2: - Rebase. - Improve commit message (Chris). v3: Rebase after changing the patch order. v4: Rebase again after upstream changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
* | | drm/i915: introduce is_active/activate/deactivate to the FBC terminologyPaulo Zanoni2015-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The long term goal is to have enable/disable as the higher level functions and activate/deactivate as the lower level functions, just like we do for PSR and for the CRTC. This way, we'll run enable and disable once per modeset, while update, activate and deactivate will be run many times. With this, we can move the checks and code that need to run only once per modeset to enable(), making the code simpler and possibly a little faster. This patch is just the first step on the conversion: it starts by converting the current low level functions from enable/disable to activate/deactivate. This patch by itself has no benefits other than making review and rebase easier. Please see the next patches for more details on the conversion. v2: - Rebase. - Improve commit message (Chris). v3: Rebase after changing the patch order. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
* | | drm/i915: pass the crtc as an argument to intel_fbc_update()Paulo Zanoni2015-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no need to reevaluate the status of every single crtc when a single crtc changes its state. With this, we're cutting the case where due to a change in pipe B, intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC should be enabled on pipe A, then it completely rechecks the state of pipe A only to conclude FBC should remain enabled on pipe A. If any change on pipe A triggers a need to recompute whether FBC is valid on pipe A, then at some point someone is going to call intel_fbc_update(PIPE_A). The addition of intel_fbc_deactivate() is necessary so we keep track of the previously selected CRTC when we do invalidate/flush. We're also going to continue the enable/disable/activate/deactivate concept in the next patches. v2: Rebase. v3: Rebase after changing the patch order. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
* | | drm/i915: Don't use crtc->config when reading out infoframe stateVille Syrjälä2015-12-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The .get_config() hooks should not reference anything in crtc->config, everything should be based on the passed in pipe_config instead. So don't dig out the cpu_transcoder from crtc->config on ddi platfforms, and also avoid using the encoder->crtc link and instead look up the pipe via pipe_config->base.crtc. I don't think this will actually fix anything since during the initial state readout we set up the encoder->crtc link prior to calling .get_config(), and during the modeset state check the encoder->crtc ought to be correct anyway since it's that state we just programmed. But this seems the right thing to do anyway. While at it, do some house cleaning on the local variables in the .infoframe_enabled() hooks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448555227-31403-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: add has_dsi_encoder to crtc stateJani Nikula2015-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DSI has quite a few special cases, like DP, so add it to crtc state. This way we can get rid of a number of intel_pipe_has_type() checks for DSI. This isn't necessarily the prettiest way, but it's a step towards being aligned with what's being done with other encoders. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448619706-21293-3-git-send-email-jani.nikula@intel.com
OpenPOWER on IntegriCloud