summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/tv: fix gen4 composite s-video tv-outJani Nikula2014-03-281-2/+7
| | | | | | | | | | | | | | | | | | | | This is *not* bisected, but the likely regression is commit c35614380d5c956bfda20eab2755b2f5a7d6f1e7 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Tue Nov 24 09:48:48 2009 +0800 drm/i915: Don't set up the TV port if it isn't in the BIOS table. The commit does not check for all TV device types that might be present in the VBT, disabling TV out for the missing ones. Add composite S-video. Reported-and-tested-by: Matthew Khouzam <matthew.khouzam@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73362 Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Split 64bit hexadecimal addresses to make them easier to readChris Wilson2014-03-281-2/+2
| | | | | | | | | | | | | | | | Broadwell introduces large address spaces, greater than 32bits in width. These require that we then store and print 64bit values. If we were to zero pad them out to 16 hexadecimal places, we have to carefully count the leading zeroes - which is easy to make a mistake. Conversely, if we do not zero pad out to 16, but keep it padding to 8 hexadecimal places, it is very easy to miss an address that is actually larger than 4GiB. A suggested compromise is to insert a space between the upper and lower dwords of the address so that we can continue with our accustom 32bit parser. (Alternatively, we could do the equivalent in our userspace decoder.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Broadwell expands ACTHD to 64bitChris Wilson2014-03-286-13/+36
| | | | | | | | | | | | | | | | | | | | | | | As Broadwell has an increased virtual address size, it requires more than 32 bits to store offsets into its address space. This includes the debug registers to track the current HEAD of the individual rings, which may be anywhere within the per-process address spaces. In order to find the full location, we need to read the high bits from a second register. We then also need to expand our storage to keep track of the larger address. v2: Carefully read the two registers to catch wraparound between the reads. v3: Use a WARN_ON rather than loop indefinitely on an unstable register read. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Drop spurious hunk which conflicted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: Implement Wa4x4STCOptimizationDisable:bdwDamien Lespiau2014-03-282-1/+6
| | | | | | | | | | | | Not implementing this W/A can lead to hangs. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Rafael Barbalho <rafael.barbalho@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Undo gtt scratch pte unmapping againDaniel Vetter2014-03-281-1/+1
| | | | | | | | | | | | | | | | | | It apparently blows up on some machines. This functionally reverts commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841 Reported-and-Tested-by: Brad Jackson <bjackson0971@gmail.com> Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Recompute WM when the cursor size changesChris Wilson2014-03-281-1/+7
| | | | | | | | | | | | If the cursor width is changed, we may need to recompute our WM to prevent untold flickering. We hope that the registers are flushed on the same vblank to prevent underruns... Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Compute WM for current cursor sizeChris Wilson2014-03-281-4/+4
| | | | | | | | | | | | | Now that we can use different cursor size, we can not hardcode 64 pixels as the cursor width anymore. v2: Apply to 965gm/g4x paths as well Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove the enabling of VS_TIMER_DISPATCH bit in MI MODE regAkash Goel2014-03-281-1/+2
| | | | | | | | | | | | | | | | | | | This patch Removes the VS_TIMER_DISPATCH bit enable in MI MODE reg for platforms > Gen6. VS_TIMER_DISPATCH bit enable was earlier required as a part of WA 'WaTimedSingleVertexDispatch', which is now applicable only to platforms < Gen7. v2: Enhancing the scope of the patch to full Gen7 (Chris) v3: Modifying the WA condition to the cover the applicable platforms, and adding the WA name in comments. (Ville) Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Sourab Gupta <sourab.gupta@intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # ivb, hsw -Chris Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Track the enabled PM interrupts in dev_priv.Deepak S2014-03-283-12/+17
| | | | | | | | | | | | | | | When we use different rps events for different platforms or due to wa, we might end up needing this logic in a lot of places. Instead of this let's use a variable in dev_priv to track the enabled PM interrupts. v2: Initialize pm_rps_events in intel_irq_init() (Ville). Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Frob the commit message a bit since the English was a bit too garbled ;-) ] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix initial pipe underrun state trackingDaniel Vetter2014-03-281-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Mar 7 20:34:46 2014 +0100 drm/i915: Don't enable display error interrupts from the start we don't enable underrun interrupts any more at takeover time. Unfortunately I've forgotten to also adjust the sw-side tracking. Since the code assumes that disabled pipes have underrun reporting enabled set the disable flag only on all pipes which are active at takeover time. Without this underrun reporting wasn't enabled correctly on the first modeset. Note that for fastboot this is another piece of state that needs to be fixed up by enabling the underrung reporting after watermarks have beend fixed up. On ivb/hsw an additional effect of this regression was that also all cpu crc reporting stopped working since the master error interrupt it shared across all pipes and sources. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76150 [danvet: Augment the code comment and polish the commit message a bit, as discussed with Jani.] Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix up semaphore_waits_forDaniel Vetter2014-03-281-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's an entire pile of issues in here: - Use the main RING_HEAD register, not ACTHD. ACTHD points at the gtt offset of the batch buffer when a batch is executed. Semaphores are always emitted to the main ring, so we always want to look at that. - Mask the obtained HEAD pointer with the actual ring size, which is much smaller. Together with the above issue this resulted us in trying to dereference a pointer way outside of the ring mmio mapping. The resulting invalid access in interrupt context (hangcheck is executed from timers) lead to a full blown kernel panic. The fbcon panic handler then tried to frob our driver harder, resulting in a full machine hang at least on my snb here where I've stumbled over this. - Handle ring wrapping correctly and be a bit more explicit about how many dwords we're scanning. We probably should also scan more than just 4 ... - Space out some of teh computations for readability. This reduces hard-hangs on my snb here. Mika and QA both say that it doesn't completel remove them, but at least for me it's a clear improvement in stability. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=74100 Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add locking to fixed panel edid probingDaniel Vetter2014-03-282-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | With the recent addition of locking checks in commit 62ff94a5492175759546f8bc61383189d6b49122 Author: Daniel Vetter <daniel.vetter@ffwll.ch> AuthorDate: Thu Jan 23 22:18:47 2014 +0100 drm/crtc-helper: remove LOCKING from kerneldoc drm_add_edid_modes started to WARN about the mode_config.mutex not being held in the lvds and dp initialization code. Now since this is init code locking is fairly redudant if it wouldn't be for the drm core registering sysfs files a bit early. And the locking WARNINGs nicely enforce that indeed all access to the mode lists are properly protected. And a full audit shows that only i915 and gma500 touch the modes lists at init time. Hence I've opted to wrap up this entire mode detection sequence for fixed panels with the mode_config mutex for both lvds and edp outputs. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64Chris Wilson2014-03-211-0/+6
| | | | | | | | | | | | | | | It is important that the user is fully aware that the seemingly atomic read/write of a 64-bit value from MMIO space, may in fact be 2 separate operations of 32-bits. This can lead to hilarity, such as commit d18b9619034230b6f945e215276425636ca401fe Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jul 10 13:36:23 2013 +0100 drm/i915: Fix incoherence with fence updates on Sandybridge+ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/sdvo: fix questionable return value checkJani Nikula2014-03-211-3/+3
| | | | | | | | intel_sdvo_get_trained_inputs() returns a bool, check the status accordingly. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix unsafe loop iteration over vma whilst unbinding themChris Wilson2014-03-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | On non-LLC platforms, when changing the cache level of an object, we may need to unbind it so that prefetching across page boundaries does not cross into a different memory domain. This requires us to unbind conflicting vma, but we did so iterating over the objects vma in an unsafe manner (as the list was being modified as we iterated). The regression was introduced in commit 3089c6f239d7d2c4cb2dd5c353e8984cf79af1d7 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:03 2013 -0700 drm/i915: make caching operate on all address spaces apparently as far back as v3.12-rc1, but it has only just begun to trigger real world bug reports. Reported-and-tested-by: Nikolay Martynov <mar.kolya@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Enabling 128x128 and 256x256 ARGB Cursor SupportSagar Kamble2014-03-203-5/+59
| | | | | | | | | | | | | | | | | | | | | | | | With this patch we allow larger cursor planes of sizes 128x128 and 256x256. v2: Added more precise check on size while setting cursor plane. v3: Changes related to restructuring cursor size restrictions and DRM_DEBUG usage. v4: Indentation related changes for setting cursor control and implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT Testcase: igt/kms_cursor_crc Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: G, Pallavi <pallavi.g@intel.com> Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Print how many objects are shared in per-process statsChris Wilson2014-03-201-2/+8
| | | | | | | | | | | | The point of this measure is to gauge why a process has a lot of gem objects in uses and why. Especially for compositors it's interesting to know whether it's a leak of private objects or just a lot of use from buffers shared with clients. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add a bit of commit message flesh to address Ben's comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Per-process stats work better when evaluated per-processChris Wilson2014-03-203-9/+43
| | | | | | | | | | | | | | | | | The idea of printing objects used by each process is to judge how each process is using them. This means that we need to evaluate whether the object is bound for that particular process, rather than just whether it is bound into the global GTT. v2: Restore the non-full-ppgtt path for simplicity as we may not even create vma with older hardware. v3: Tweak handling of global entries and default context entries. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove rps local variablesBen Widawsky2014-03-202-43/+33
| | | | | | | | | | | | | | With the renamed RPS struct members, it's easier to skip the local variables which no longer clarify anything, and if anything just make the code harder to read. The real motivation for this patch is actually the next patch, which attempts to consolidate some of the functionality. Cc: Jeff McGee <jeff.mcgee@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove extraneous MMIO for RPSBen Widawsky2014-03-201-12/+9
| | | | | | | | | | | | | | The values created at initialization must always exist to use the interface. Reading them again is confusing, and pointless. More cleanups are coming in the next patch. Since I am not 100% certain, moreover on BYT, (though I am extremely close to that) that there is no need to leave the MMIO here, I wanted to make it a separate patch for the bisectable 'just-in-case' Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename and comment all the RPS *stuff*Ben Widawsky2014-03-205-107/+120
| | | | | | | | | | | | | | | | | | | | | The names of the struct members for RPS are stupid. Every time I need to do anything in this code I have to spend a significant amount of time to remember what it all means. By renaming the variables (and adding the comments) I hope to clear up the situation. Indeed doing this make some upcoming patches more readable. I've avoided ILK because it's possible that the naming used for Ironlake matches what is in the docs. I believe the ILK power docs were never published, and I am too lazy to dig them up. v2: leave rp0, and rp1 in the names. It is useful to have these limits available at times. min_freq and max_freq (which may be equal to rp0, or rp1 depending on the platform) represent the actual HW min and max. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Store the HW min frequency as min_freqBen Widawsky2014-03-202-1/+2
| | | | | | | | | this leaves a temporarily awkward min_delay (the soft limit) with the new min_freq (the hardware limit). It's fixed in the next patch. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix coding style for RPSBen Widawsky2014-03-201-10/+10
| | | | | | | | | | | | | | Introduced: commit b8a5ff8d7c676a04e0da5ec16bb068dd39459042 Author: Jeff McGee <jeff.mcgee@intel.com> Date: Tue Feb 4 11:37:01 2014 -0600 drm/i915: Update rps interrupt limits Cc: Jeff McGee <jeff.mcgee@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Reorganize the overclock codeBen Widawsky2014-03-201-11/+9
| | | | | | | | | | | | | | | | The existing code (which I changed last) was very convoluted. I believe it was attempting to skip the overclock portion if the previous pcode write failed. When I last touched the code, I was preserving this behavior. There is some benefit to doing it that way in that if the first pcode access fails, the later is likely invalid. Having a bit more confidence in my understanding of how things work, I now feel it's better to have clear, readable, code than to try to skip over this one operation in an unusual case. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: init pm.suspended earlierPaulo Zanoni2014-03-191-2/+1
| | | | | | | | | | | | | | | | | | | Function intel_init_runtime_pm is supposed to start allowing runtime PM from that point, but it's called very late on the driver initialization code, to prevent the driver from trying to suspend while still initializing. The problem is that variables are accessed earlier than that, so initalize them at intel_pm_setup, which is supposed to be the correct place. Notice that this shouldn't fix any specific bugs because dev_priv is zeroed when allocated, so the value is already correct right from the start. v2: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: update the PC8 and runtime PM documentationPaulo Zanoni2014-03-192-40/+35
| | | | | | | | | | | | | Now that PC8 got much simpler, there are less things to document. Also, runtime PM already has a nice documentation, so we don't need to re-explain it on our driver. v2: - Rebase. - Fix typo (Jesse). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rename __hsw_do_{en, dis}able_pc8Paulo Zanoni2014-03-193-6/+6
| | | | | | | | | | | After we removed all the intermediate abstractions, we can rename these functions to just hsw_{en,dis}able_pc8. v2: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: kill struct i915_package_c8Paulo Zanoni2014-03-193-9/+0
| | | | | | | | | | | The only remaining field of the struct was the lock, which was useless. v2: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move pc8.irqs_disabled to pm.irqs_disabledPaulo Zanoni2014-03-197-41/+42
| | | | | | | | | | | | | | | When other platforms add runtime PM support they will also need to disable interrupts, so move the variable to the runtime PM struct. Also notice that the longer-term goal is to completely kill the regsave struct, and I even have patches for that. v2: - Rebase. v3: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove dev_priv->pc8.enabledPaulo Zanoni2014-03-194-9/+0
| | | | | | | | | | | | | | It was just being used on debugfs and on a WARN inside hsw_set_power_well. But now that we PC8 is part of runtime PM and we get/put runtime PM when we get/put any power domain, we shouldn't need the WARN anymore. v2: - Rebase. v3: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't get/put PC8 when getting/putting power wellsPaulo Zanoni2014-03-193-24/+0
| | | | | | | | | | | | | | | | Because we already get/put runtime PM every time we get/put any power domain, and now PC8 and runtime PM are the same thing. With this, we can also now kill the hsw_{en,dis}able_package_c8 functions. v2: - Rebase. v3: - Rebase. v4: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8Paulo Zanoni2014-03-191-3/+2
| | | | | | | | | | | | | | | | | Because we merged the PC8 and runtime PM features, so calling intel_runtime_pm_get now has the same meaning, and we plan to just remove hsw_disable_package_c8 for this exact reason. My first patch tried to completely kill intel_aux_display_runtime_get/put, because I was assuming that whoever needed more than just runtime PM would have to get the appropriate power domain instead of that, but it seems some people still want the intel_aux_display_runtime_get abstraction, so keep it until someone else tries to replace it with the more-standard power domain calls. 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>
* drm/i915: don't get/put PC8 reference on freeze/thawPaulo Zanoni2014-03-191-5/+0
| | | | | | | | | | | We already get runtime PM references, and PC8 is now part of runtime PM, so this is enough. v2: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove an indirection level on PC8 functionsPaulo Zanoni2014-03-191-14/+2
| | | | | | | | After the latest changes, the indirection is useless. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: kill pc8.disable_countPaulo Zanoni2014-03-194-17/+0
| | | | | | | | | Since after the latest patches it's only being used to prevent getting/putting the runtime PM refcount. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: get runtime PM references when the GPU is idle/busyPaulo Zanoni2014-03-191-2/+2
| | | | | | | | | ... instead of PC8 references. Now that both are the same thing and we are killing PC8, just get the runtime PM reference. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove dev_priv->pc8.requirements_metPaulo Zanoni2014-03-194-59/+3
| | | | | | | | | | | | | | | The requirements_met variable was used to track two things: enabled CRTCs and the power well. After the latest chagnes, we get a runtime PM reference whenever we get any of the power domains, and we get power domains when we enable CRTCs or the power well, so we should already be covered, not needing this specific tracking. v2: - Rebase. v3: - Rebase. 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>
* drm/i915: get/put runtime PM when we get/put a power domainPaulo Zanoni2014-03-191-0/+4
| | | | | | | | | | | | | | | | | | Any power domain will require the HW to be in PCI D0 state, so just do the simple thing. Dear maintainer: since intel_display_power_put() and intel_display_power_get() are almost identical, git-am has failed apply the patch on my local machine once: it added both chunks to put(), instead of one chunk to get() and another to put(). When you apply this patch to your tree, please check if it is correct. v2: - Add the warning above. v3: - Rebase. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make PC8 be part of runtime PM suspend/resumePaulo Zanoni2014-03-197-53/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915: extract __hsw_do_{en, dis}able_package_c8Paulo Zanoni2014-03-191-26/+38
| | | | | | | | | | | | When we merge PC8 and runtime PM, these new functions are going to be called by the runtime suspend/resume functions, and their callers are going to be removed. v2: - Rebase Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'topic/dp-aux-rework' into drm-intel-next-queuedDaniel Vetter2014-03-19252-4231/+7837
|\ | | | | | | | | | | | | | | | | | | 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-182-169/+30
| | | | | | | | | | | | | | | | | | | | 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: move dp aux ch register init to aux initJani Nikula2014-03-181-20/+22
| | | | | | | | | | | | | | | | Do a slight rearrangement of the switch to prep for follow-up. 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-182-142/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/dp: move edp vdd enable/disable at a lower level in i2c-over-auxJani Nikula2014-03-181-3/+6
| | | | | | | | | | | | | | | | | | This is prep work for conversion to generic drm i2c-over-aux helpers where we won't have the function to do this at. 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: split edp_panel_vdd_on() for reuseJani Nikula2014-03-181-6/+16
| | | | | | | | | | | | | | | | | | | | Introduce _edp_panel_vdd_on() that returns true if the call enabled vdd, and a matching disable is needed. Keep edp_panel_vdd_on() as a helper for when it is expected the vdd is off. 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/dp: let drivers specify the name of the I2C-over-AUX adapterJani Nikula2014-03-182-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let the drivers specify the name of the I2C-over-AUX adapter to maintain backwards compatibility in the sysfs when converting to the new I2C-over-AUX helper infrastructure. The i915 driver currently uses DPDDC-A to DPDDC-D as names for the DP i2c adapters. These names show up in the i2c sysfs name attribute. We'd like to be able to maintain that when switching over to the new helpers. Due to i2c device and connector cleanup ordering issues we also recently made the drm device (instead of connector) the parent of the i2c adapters: commit 80f65de3c9b8101c1613fa82df500ba6a099a11c Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 11 17:12:49 2014 +0200 drm/i915: dp: fix order of dp aux i2c device cleanup With the name picked up from the adapter parent using dev_name(), it would be the same for all i2c adapters with the current I2C-over-AUX helpers. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Acked-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge branch 'topic/core-stuff' of git://git.freedesktop.org/git/drm-intel ↵Dave Airlie2014-03-183-10/+9
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Merge straggling core drm patches. * 'topic/core-stuff' of git://git.freedesktop.org/git/drm-intel: drm: Fix use-after-free in the shadow-attache exit code drm/fb-helper: Do the 'max_conn_count' zero check drm: Check if the allocation has succeeded before dereferencing newmode drm/fb-helper: Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par() drm/edid: request HDMI underscan by default
| | * drm: Fix use-after-free in the shadow-attache exit codeDaniel Vetter2014-03-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This regression has been introduced in commit b3f2333de8e81b089262b26d52272911523e605f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Dec 11 11:34:31 2013 +0100 drm: restrict the device list for shadow attached drivers Reported-by: Dave Jones <davej@redhat.com> Cc: Dave Jones <davej@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
| | * drm/fb-helper: Do the 'max_conn_count' zero checkXiubo Li2014-03-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we cannot make sure the 'max_conn_count' will always be none zero from the users, and then if max_conn_count equals to zero, the kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the 'max_conn_count' zero check in the front of drm_fb_helper_init(). Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com> CC: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud