summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_drv.h
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/i915: make PC8 be part of runtime PM suspend/resumePaulo Zanoni2014-03-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when our driver becomes idle for i915.pc8_timeout (default: 5s) we enable PC8, so we save some power, but not everything we can. Then, while PC8 is enabled, if we stay idle for more autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the graphics device in D3 state, saving even more power. The two features are separate things with increasing levels of power savings, but if we disable PC8 we'll never get into D3. While from the modularity point of view it would be nice to keep these features as separate, we have reasons to merge them: - We are not aware of anybody wanting a "PC8 without D3" environment. - If we keep both features as separate, we'll have to to test both PC8 and PC8+D3 code paths. We're already having a major pain to make QA do automated testing of just one thing, testing both paths will cost even more. - Only Haswell+ supports PC8, so if we want to add runtime PM support to, for example, IVB, we'll have to copy some code from the PC8 feature to runtime PM, so merging both features as a single thing will make it easier for enabling runtime PM on other platforms. This patch only does the very basic steps required to have PC8 and runtime PM merged on a single feature: the next patches will take care of cleaning up everything. v2: - Rebase. v3: - Rebase. - Fully remove the deprecated i915 params since Daniel doesn't consider them as part of the ABI. v4: - Rebase. - Fix typo in the commit message. v5: - Rebase, again. - Add a huge comment explaining the different forcewake usage (Chris, Daniel). - Use open-coded forcewake functions (Daniel). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'topic/dp-aux-rework' into drm-intel-next-queuedDaniel Vetter2014-03-191-2/+1
|\ | | | | | | | | | | | | | | | | | | Conflicts: drivers/gpu/drm/i915/intel_dp.c A bit a mess with reverts which differe in details between -fixes and -next and some other unrelated shuffling. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: use the new drm helpers for dp i2c-over-auxJani Nikula2014-03-181-2/+0
| | | | | | | | | | | | | | | | | | | | The functionality remains largerly the same. The main difference is that i2c-over-aux defer timeouts are increased to be safe for all use cases instead of depending on DP device type and properties. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: use the new drm helpers for dp auxJani Nikula2014-03-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Functionality remains largely the same as before. Note that the retry loops and native reply handling all moved into the core drm helper functions now. Signed-off-by: Jani Nikula <jani.nikula@intel.com> [danvet: Fix up the stray ; Rodrigo spotted in his review and add a note to the commit message to answer Rodrigo's question in his review.] Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: finish off reverting eDP VDD changesJani Nikula2014-03-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a small follow-up fix to the series of eDP VDD back and forth we've had recently. This is effectively a combined revert of three commits: commit 2c2894f698fffd8ff53e1e1d3834f9e1035b1f39 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Mar 7 20:05:20 2014 -0300 drm/i915: properly disable the VDD when disabling the panel commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Tue Mar 4 00:42:44 2014 +0100 drm/i915: Don't just say it, actually force edp vdd commit dff392dbd258381a6c3164f38420593f2d291e3b Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel which shows that we're pretty close back to where we started already. The first two were basically reverting the last, but missing the WARN. Add that back. We also OCD the intel_ prefix back to intel_edp_panel_vdd_on() which was lost somewhere in between. The circle closes. For future reference, "drm/i915: don't touch the VDD when disabling the panel" failed to take into account commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel and commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Aug 12 22:17:14 2012 +0200 drm/i915: reorder edp disabling to fix ivb MacBook Air Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: properly disable the VDD when disabling the panelPaulo Zanoni2014-03-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 tried to revert commit dff392dbd258381a6c3164f38420593f2d291e3b, but wasn't complete, which resulted in regressions on Haswell. So this commit should fix b3064154dfd37deb386b1e459c54e1ca2460b3d5 by undoing what it did and providing an actual complete revert of dff392dbd258381a6c3164f38420593f2d291e3b. Fixes regression introduced by: commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Tue Mar 4 00:42:44 2014 +0100 drm/i915: Don't just say it, actually force edp vdd Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Make encoder cloning more flexibleVille Syrjälä2014-03-101-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we allow encoders to indicate whether they can be part of a cloned set with just one flag. That's not flexible enough to describe the actual hardware capabilities. Instead make it a bitmask of encoder types with which the current encoder can be cloned. For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should match what the old boolean flag allowed. We will add some more cloning options in the future. Note that this patch also removes the encoder.possible_clones setting from encoder setup code - we compute this dynamically. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add Ville's explanation why removing the encoder possible_clones is save.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: remove early fb allocation dependency on CONFIG_FB v2Jesse Barnes2014-03-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | By stuffing the fb allocation into the crtc, we get mode set lifetime refcounting for free, but have to handle the initial pin & fence slightly differently. It also means we can move the shared fb handling into the core rather than leaving it out in the fbdev code. v2: null out crtc->fb on error (Daniel) take fbdev fb ref and remove unused error path (Daniel) Requested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12Jesse Barnes2014-03-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Retrieve current framebuffer config info from the regs and create an fb object for the buffer the BIOS or boot loader left us. This should allow for smooth transitions to userspace apps once we finish the initial configuration construction. v2: check for non-native modes and adjust (Jesse) fixup aperture and cmap frees (Imre) use unlocked unref if init_bios fails (Jesse) fix curly brace around DSPADDR check (Imre) comment failure path for pin_and_fence (Imre) v3: fixup fixup of aperture frees (Chris) v4: update to current bits (locking & pin_and_fence hack) (Jesse) v5: move fb config fetch to display code (Jesse) re-order hw state readout on initial load to suit fb inherit (Jesse) re-add pin_and_fence in fbdev code to make sure we refcount properly (Je v6: rename to plane_config (Daniel) check for valid object when initializing BIOS fb (Jesse) split from plane_config readout and other display changes (Jesse) drop use_bios_fb option (Chris) update comments (Jesse) rework fbdev_init_bios for clarity (Jesse) drop fb obj ref under lock (Chris) v7: use fb object from plane_config instead (Ville) take ref on fb object (Jesse) v8: put under i915_fastboot option (Jesse) fix fb ptr checking (Jesse) inform drm_fb_helper if we fail to enable a connector (Jesse) drop unnecessary enabled[] modifications in failure cases (Chris) split from BIOS connector config readout (Daniel) don't memset the fb buffer if preallocated (Chris) alloc ifbdev up front and pass to init_bios (Chris) check for bad ifbdev in restore_mode too (Chris) v9: fix up !fastboot bpp setting (Jesse) fix up !fastboot helper alloc (Jesse) make sure BIOS fb is sufficient for biggest active pipe (Jesse) v10:fix up size calculation for proposed fbs (Chris) go back to two pass pipe fb assignment (Chris) add warning for active pipes w/o fbs (Chris) clean up num_pipes checks in fbdev_init and fbdev_restore_mode (Chris) move i915.fastboot into fbdev_init (Chris) v11:make BIOS connector config usage unconditional (Daniel) v12:fix up fb vs pipe size checking (Chris) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add plane_config fetching infrastructure v2Jesse Barnes2014-03-081-0/+9
|/ | | | | | | | | | Early at init time, we can try to read out the plane config structure and try to preserve it if possible. v2: alloc fb obj at init time after fetching plane config Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: power domains: add vlv power wellsImre Deak2014-03-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on an early draft from Jesse. Add support for powering on/off the dynamic power wells on VLV by registering its display and dpio dynamic power wells with the power domain framework. For now power on all PHY TX lanes regardless of the actual lane configuration. Later this can be optimized when the PHY side setup enables only the required lanes. Atm, it enables all lanes in all cases. v2: - undef function local COND macro after its last use (Ville) - Take dev_priv->irq_lock around the whole sequence of intel_set_cpu_fifo_underrun_reporting_nolock() and valleyview_disable_display_irqs(). They are short and releasing the lock in between only makes proving correctness more difficult. - sanitize local var names in vlv_power_well_enabled() v3: - rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict due to my changes in the previous patch. Also throw in an assert_spin_locked for safety. And finally appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add port power domainsImre Deak2014-03-071-0/+2
| | | | | | | | | | | | | | | | | Parts that poke port specific HW blocks like the encoder HW state readout or connector hotplug detect code need a way to check whether required power domains are on or enable/disable these. For this purpose add a set of power domains that refer to the port HW blocks. Get the proper port power domains during modeset. For now when requesting the power domain for a DDI port get it for a 4 lane configuration. This can be optimized later to request only the 2 lane power domain, when proper support is added on the VLV PHY side for this. Atm, the PHY setup code assumes a 4 lane config in all cases. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use drm_i915_private everywhere in the power domain apiImre Deak2014-03-051-9/+8
| | | | | | | | | | | | | The power domains framework is internal to the i915 driver, so pass drm_i915_private instead of drm_device to its functions. Also remove a dangling intel_set_power_well() declaration. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add unregister callback to connectorImre Deak2014-02-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit d9255d57147e1dbcebdf6670409c2fa0ac3609e6 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date:   Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pass explicit mode into mode_from_pipe_config v3Daniel Vetter2014-02-121-0/+2
| | | | | | | | | | We want to reuse this in the fbdev initial config code independently from any fastboot hacks. So allow a bit more flexibility. v2: Forgot to git add ... v3: make non-static (Jesse) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Initialize downclock mode in panel initVandana Kannan2014-02-121-1/+2
| | | | | | | | | | | | | | | Instead of modifying intel_panel in lvds_init_connector/dsi_init/ edp_init_connector, making changes to move intel_panel->downclock_mode initialization to intel_panel_init() v2: Jani's review comments incorporated Removed downclock_mode local variable in dsi_init and edp_init_connector Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix error path leak in fbdev fb allocationDaniel Vetter2014-02-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | In Jesse's patch to switch the fbdev framebuffer from an embedded struct to a pointer the kfree in case of an error was missed. Fix this up by using our own internal fb allocation helper directly instead of reinventing that wheel. We need a to_intel_framebuffer cast unfortunately since all the other callers of _create still look better whith using a drm_framebuffer as return pointer. v2: Add an unlocked __intel_framebuffer_create function since our dev->struct_mutex locking is too much a mess. With ppgtt we even need it to take a look at the global gtt offset of pinned objects, since the vma list might chance from underneath us. At least with the current global gtt lookup functions. Reported by Mika. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use normal fb deref for the fbcon framebufferDaniel Vetter2014-02-121-1/+0
| | | | | | | | | | | | | | | | | | | Now that it's a normally kmalloce buffer we can use the usual cleanup paths. The upside here is that if we get the refcounting wrong will be able to catch it, since the drm core will complain about leftover framebuffers and kref about underflows. v2: Kill intel_framebuffer_fini - no longer needed now that we refcount all fbs properly and only confusing. v3: We actually still need to call unregister_private to remove the fb from the idr and drop the idr reference - the final unref doesn't do that. So much for remembering my own fb liftime rules. Reported by Imre Deak. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: alloc intel_fb in the intel_fbdev structJesse Barnes2014-02-121-1/+1
| | | | | | | | | | Allocate this struct instead, so we can re-use another allocated elsewhere if needed. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: WARN_ON if there's no backing storage attached to an fb, that's a bug.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: debugfs: Add support for probing DP sink CRC.Rodrigo Vivi2014-01-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This debugfs interface will allow intel-gpu-tools test case to verify if screen has been updated properly on cases like PSR. v2: Accepted all Daniel's suggestions: * grab modeset lock * loop over connector and check DPMS on * return errors * use _eDP1 suffix for easy future extension * don't cache crc_supported neither latest crc * return crc as a full array and read it at once with aux. * use 0 to turn TEST_SINK off. * split the drm_helpers definitions in another patch. v3: Accepted 2 Damien's suggestion: remove h from printf hexa and return ENODEV when eDP not present instead of EAGAIN. v4: Accepted 2 Jani' s suggestion: 1 path for unlock and remove _retry from aux read. v5: removing last missing useless _retry (by Damien) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Introduce a get_aux_send_ctl() vfuncDamien Lespiau2014-01-241-0/+8
| | | | | | | | | | | We need a bit more flexibility here in the future, bits get shuffled around. v2: more descriptive commit message (Jani Nikula) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Turn get_aux_clock_divider() into per-platform vfuncsDamien Lespiau2014-01-241-0/+2
| | | | | | | | | | | A tiny clean-up to allow better code separation between platforms. v2: Fix comment placement (put in in i9xx_get_aux_clock_divider()) and nuke the outdated PCH eDP comment (Jani Nikula) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devicesTodd Previte2014-01-241-0/+1
| | | | | | | | | For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that support it. The sink device must report that is supports Displayport 1.2 and the HBR2 bit rate in the DPCD in order to use HBR2. Signed-off-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: drop ironlake_ prefix from edp panel/backlight functionsDaniel Vetter2014-01-241-6/+4
| | | | | | | | | | | | | | | | | | | | | | | They now also work on vlv, which has the regs somewhere else. And daring a glance into the looking glass it seems like this functionality will continue to work the same for the next few hardware platforms. So it's better to just remove that misleading prefix and have a bit shorter code for better readability. The only exceptions are the panel/backlight functions shared with intel_ddi.c, those get an intel_ prefix. While at it make the vdd_on/off functions static. And one straggler was missing the edp_ in the name, so make everything neatly OCD. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: save some time when waiting the eDP timingsPaulo Zanoni2014-01-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The eDP spec defines some points where after you do action A, you have to wait some time before action B. The thing is that in our driver action B does not happen exactly after action A, but we still use msleep() calls directly. What this patch does is that we record the timestamp of when action A happened, then, just before action B, we look at how much time has passed and only sleep the remaining amount needed. With this change, I am able to save about 5-20ms (out of the total 200ms) of the backlight_off delay and completely skip the 1ms backlight_on delay. The 600ms vdd_off delay doesn't happen during normal usage anymore due to a previous patch. v2: - Rename ironlake_wait_jiffies_delay to intel_wait_until_after and move it to intel_display.c - Fix the msleep call: diff is in jiffies v3: - Use "tmp_jiffies" so we don't need to worry about the value of "jiffies" advancing while we're doing the math. v4: - Rename function again. - Move function to i915_drv.h. - Store last_power_cycle at edp_panel_off too. - Use msecs_to_jiffies_timeout, then replace the msleep with an open-coded version that avoids the extra +1 jiffy. - Try to add units to every variable name so we don't confuse jiffies with milliseconds. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Prepare to track new pipe config per pipeVille Syrjälä2014-01-241-0/+1
| | | | | | | | | | | | Add a new_config pointer to intel_crtc which will point to the new pipe config for said crtc while intel_crtc.config will still contain the old config during first parts of the modeset operation. This is a step towards having the entire new state available during the compute phase, so that we can make accurate decisions about global resource usage. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pre-compute pipe enabled stateVille Syrjälä2014-01-241-0/+2
| | | | | | | | | | | Add 'new_enabled' to intel_crtc and precompute it alongside new_encoder and new_crtc. This will allow making decisions about shared resources that are affected by the set of active pipes, before we've clobbered anything for real. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Wait for completion of pending flips when starved of fencesChris Wilson2014-01-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | On older generations (gen2, gen3) the GPU requires fences for many operations, such as blits. The display hardware also requires fences for scanouts and this leads to a situation where an arbitrary number of fences may be pinned by old scanouts following a pageflip but before we have executed the unpin workqueue. This is unpredictable by userspace and leads to random EDEADLK when submitting an otherwise benign execbuffer. However, we can detect when we have an outstanding flip and so cause userspace to wait upon their completion before finally declaring that the system is starved of fences. This is really no worse than forcing the GPU to stall waiting for older execbuffer to retire and release their fences before we can reallocate them for the next execbuffer. v2: move the test for a pending fb unpin to a common routine for later reuse during eviction Reported-and-tested-by: dimon@gmx.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge commit origin/master into drm-intel-nextDaniel Vetter2014-01-161-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts are getting out of hand, and now we have to shuffle even more in -next which was also shuffled in -fixes (the call for drm_mode_config_reset needs to move yet again). So do a proper backmerge. I wanted to wait with this for the 3.13 relaese, but alas let's just do this now. Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_pm.c Besides the conflict around the forcewake get/put (where we chaged the called function in -fixes and added a new parameter in -next) code all the current conflicts are of the adjacent lines changed type. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: fix pm init orderingDaniel Vetter2013-12-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Shovel a bit more of the the code into the setup function, and call it earlier. Otherwise lockdep is unhappy since we cancel the delayed resume work before it's initialized. While at it also shovel the pc8 setup code into the same functions. I wanted to also ditch the header declaration of the hws pc8 functions, but for unfathomable reasons that stuff is in intel_display.c instead of intel_pm.c. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71980 Tested-by: Guo Jinxian <jinxianx.guo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Check VBT for eDP ports on VLVVille Syrjälä2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VLV can have eDP on either port B or C, or even both. Based on the VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we check the correct ports. So instead of hardcoding port D, rename the function to intel_dp_is_edp() and pass the port as a parameter, and use it on VLV ports B and C. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051 Tested-by: Robert Hooker <robert.hooker@canonical.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Wrestle the patch to apply and compile properly.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add braces around KHz/MHz macro parametersJani Nikula2014-01-101-2/+2
| | | | | | | | | | | | | | | | It's an accident waiting to happen. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Introduce new intel_output_name()Damien Lespiau2014-01-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | That we can use for debugging purposes. v2: Use designated initializers for the 'names' array (Paulo Zanoni, Jani Nikula). Add a check in case the array has a hole (which can now remain unnoticed with designated initializers) (Jani Nikula) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (for v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: split intel_ddi_pll_mode_set in 2 piecesPaulo Zanoni2013-12-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first piece, intel_ddi_pll_select, finds a PLL and assigns it to the CRTC, but doesn't write any register. It can also fail in case it doesn't find a PLL. The second piece, intel_ddi_pll_enable, uses the information stored by intel_ddi_pll_select to actually enable the PLL by writing to its register. This function can't fail. We also have some refcount sanity checks here. The idea is that one day we'll remove all the functions that touch registers from haswell_crtc_mode_set to haswell_crtc_enable, so we'll call intel_ddi_pll_select at haswell_crtc_mode_set and then call intel_ddi_pll_enable at haswell_crtc_enable. Since I'm already touching this code, let's take care of this particular split today. v2: - Clock on the debug message is in KHz - Add missing POSTING_READ Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Bikeshed comments.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: remove i915_disable_vga_mem declarationPaulo Zanoni2013-12-121-1/+0
| | | | | | | | | | | | | | | | | | | | It was supposed to have been killed on the same commit that killed the function, e1264ebe9ff48e1b3e1dd11805eec9f5b143ab7c, but I guess the intel_drv.h reorganization accidentally brought it back. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add initial Runtime PM functionsPaulo Zanoni2013-12-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the initial infrastructure to allow a Runtime PM implementation that sets the device to its D3 state. The patch just adds the necessary callbacks and the initial infrastructure. We still don't have any platform that actually uses this infrastructure, we still don't call get/put in all the places we need to, and we don't have any function to save/restore the state of the registers. This is not a problem since no platform uses the code added by this patch. We have a few people simultaneously working on runtime PM, so this initial code could help everybody make their plans. V2: - Move some functions to intel_pm.c - Remove useless pm_runtime_allow() call at init - Remove useless pm_runtime_mark_last_busy() call at get - Use pm_runtime_get_sync() instead of 2 calls - Add a WARN to check if we're really awake V3: - Rebase. V4: - Don't need to call pci_{save,restore}_state and pci_set_power_sate, since they're already called by the PCI layer - Remove wrong pm_runtime_enable() call at init_runtime_pm Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Don't cast away const from infoframe bufferVille Syrjälä2013-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We don't modify the packed infoframe data, so we should keep the const qualifier in place. Just pass the buffer as 'const void *' instead of 'const uint8_t *' and we can drop the cast entirely. v2: Do intel_sdvo_write_infoframe() as well Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Make downclock deduction common for all panelsVandana Kannan2013-12-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | If one mode of a internal panel has more than one refresh rate, then a reduced clock is found for the LFP (LVDS/eDP). This enables switching between low and high frequency dynamically. Moving downclock calculation to intel_panel so that it is common for LVDS and eDP. Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add intel_display_power_enabled_sw() for use in atomic ctxImre Deak2013-11-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm we call intel_display_power_enabled() from i915_capture_error_state() in IRQ context and then take a mutex. To fix this add a new intel_display_power_enabled_sw() which returns the domain state based on software tracking as opposed to reading the actual HW state. Since we use domain_use_count for this without locking on the reader side make sure we increase the counter only after enabling all required power wells and decrease it before disabling any of these power wells. Regression introduced in commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c Author: Imre Deak <imre.deak@intel.com> Date:   Tue Sep 24 16:17:09 2013 +0300     drm/i915: support for multiple power wells Note that atm we depend on the value returned by intel_display_power_enabled_sw() in i915_capture_error_state() to avoid unclaimed register access reports. This was never guaranteed though, since another thread can disable the power concurrently. If this is a problem we need another explicit way to disable the reporting during error captures. v2: - remove barriers as the caller can't depend on the value returned from i915_capture_error_state_sw() anyway (Ville) - dump the state of pipe/transcoder power domain state (Daniel) Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'backlight-rework' into drm-intel-next-queuedDaniel Vetter2013-11-151-4/+18
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in Jani's backlight rework branch. This was merged through a separate branch to be able to sort out the Broadwell conflicts properly before pulling it into the main development branch. Conflicts: drivers/gpu/drm/i915/intel_display.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: gather backlight information at setupJani Nikula2013-11-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Prepare for being able to use the information at enable. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: handle backlight through chip specific functionsJani Nikula2013-11-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The backlight code has grown rather hairy, not least because the hardware registers and bits have repeatedly been shuffled around. And this isn't expected to get any easier with new hardware. Make things easier for our (read: my) poor brains, and split the code up into chip specific functions. There should be no functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: make asle notifications update backlight on all connectorsJani Nikula2013-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ALthough usually there's only one connector that supports backlight, this also finds the correct connector. Before, we only updated the connector on pipe A, which might not be the one with backlight. (This only made a difference on BYT.) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: make backlight info per-connectorJani Nikula2013-11-131-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move from dev_priv to connector->panel. We still don't allow multiple sysfs interfaces, though. There should be no functional changes, except for a slight reordering of connector backlight and sysfs destroy calls. (This change happens now that the backlight device is actually per-connector, even though the destroy calls became per-connector earlier.) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: clean up backlight conditional buildJani Nikula2013-11-131-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | I've always felt the backlight device conditional build has been all backwards. Make it feel right. Gently move things towards connector based stuff while at it. There should be no functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: make backlight functions take a connectorJesse Barnes2013-11-061-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV/BYT, backlight controls a per-pipe, so when adjusting the backlight we need to pass the correct info. So make the externally visible backlight functions take a connector argument, which can be used internally to figure out the pipe backlight to adjust. v2: make connector pipe lookup check for NULL crtc (Jani) fixup connector check in ASLE code (Jani) v3: make sure we take the mode config lock around lookups (Daniel) v4: fix double unlock in panel_get_brightness (Daniel) v5: push ASLE work into a work queue (Daniel) v6: separate ASLE work to a prep patch, rebase (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/vlv: Make the vlv_dpio_read/vlv_dpio_write more PHY centricChon Ming Lee2013-11-111-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vlv_dpio_read/write should be describe more in PHY centric instead of display controller centric. Create a enum dpio_channel for channel index and enum dpio_phy for PHY index. This should better to gather for upcoming platform. v2: Rebase the code based on drm/i915/vlv: Fix typo in the DPIO register define. v3: Rename vlv_phy to dpio_phy_iosf_port and define additional macro DPIO_PHY, and remove unrelated change. (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/vlv: split CCK and DDR freq usageJesse Barnes2013-11-051-1/+1
|/ | | | | | | | | | | It's possible that the CCK clock could run at a different rate than the DDR clock, so use the same method to get CCK as the GMBUS code does when calculating the new CDclk divider in the VLV display code. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rename i915_init_power_well to init_power_domains_initImre Deak2013-10-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Similarly rename the other related functions in the power domain interface. Higher level driver code calling these functions knows only about power domains, not the underlying power wells which may be different on different platforms. Also these functions really init/cleanup/resume power domains and only through that all related power wells, so rename them accordingly. Note that I left i915_{request,release}_power_well as is, since that really changes the state only of a single power well (and is HSW specific). It should also get a better name once we make it more generic by controlling things through a new audio power domain. v4: - use intel prefix instead of i915 everywhere (Paulo) - use a $prefix_$block_$action format (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use power get/put instead of set for power on after initImre Deak2013-10-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we make sure that all power domains are enabled during driver init and turn off unneded ones only after the first modeset. Similarly during suspend we enable all power domains, which will remain on through the following resume until the first modeset. This logic is supported by intel_set_power_well() in the power domain framework. It would be nice to simplify the API, so that we only have get/put functions and make it more explicit on the higher level how this "power well on during init" logic works. This will make it also easier if in the future we want to shorten the time the power wells are on. For this add a new device private flag tracking whether we have the power wells on because of init/suspend and use only intel_display_power_get()/put(). As nothing else uses intel_set_power_well() we can remove it. This also fixes commit 6efdf354ddb186c6604d1692075421e8d2c740e9 Author: Imre Deak <imre.deak@intel.com> Date: Wed Oct 16 17:25:52 2013 +0300 drm/i915: enable only the needed power domains during modeset where removing intel_set_power_well() resulted in not releasing the reference on the power well that was taken during init and thus leaving the power well on all the time. Regression reported by Paulo. v2: - move the init_power_on flag to the power_domains struct (Daniel) v3: - add note about this being a regression fix too (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud