summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2013-12-18drm: Kill DRM_HZDaniel Vetter1-1/+1
We don't have any userspace interfaces that use HZ as a time unit, so having our own DRM define is useless. Remove this remnant from the shared drm core days. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm: kill DRIVER_REQUIRE_AGPDaniel Vetter2-2/+6
Only the two intel drivers need this and they can easily check for working agp support in their driver ->load callbacks. This is the only reason why agp initialization could fail, so allows us to rip out a bit of error handling code in the next patch. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18drm/dp: Use AUX constants from specificationThierry Reding1-18/+19
The current values seem to be defined in a format that's specific to the i915, gma500 and radeon drivers. To make this more generally useful, use the values as defined in the specification. While at it, prefix the constants with DP_ for improved namespacing. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-12-18Merge tag 'drm-intel-next-2013-11-29' of ↵Dave Airlie34-1177/+2044
git://people.freedesktop.org/~danvet/drm-intel into drm-next - some more ppgtt prep patches from Ben - a few fbc fixes from Ville - power well rework from Imre - vlv forcewake improvements from Deepak S, Ville and Jesse - a few smaller things all over [airlied: fixup forwcewake conflict] * tag 'drm-intel-next-2013-11-29' of git://people.freedesktop.org/~danvet/drm-intel: (97 commits) drm/i915: Fix port name in vlv_wait_port_ready() timeout warning drm/i915: Return a drm_mode_status enum in the mode_valid vfuncs drm/i915: add intel_display_power_enabled_sw() for use in atomic ctx drm/i915: drop DRM_ERROR in intel_fbdev init drm/i915/vlv: use parallel context restore when coming out of RC6 drm/i915/vlv: use a lower RC6 timeout on VLV drm/i915/sdvo: Fix up debug output to not split lines drm/i915: make sparse happy for the new vlv mmio read function drm/i915: drop the right force-wake engine in the vlv mmio funcs drm/i915: Fix GT wake FIFO free entries for VLV drm/i915: Report all GTFIFODBG errors drm/i915: Enabling DebugFS for valleyview forcewake counts drm/i915/vlv: Valleyview support for forcewake Individual power wells. drm/i915: Add power well arguments to force wake routines. drm/i915: Do not attempt to re-enable an unconnected primary plane drm/i915: add a debugfs entry for power domain info drm/i915: add a default always-on power well drm/i915: don't do BDW/HSW specific powerdomains init on other platforms drm/i915: protect HSW power well check with IS_HASWELL in redisable_vga drm/i915: use IS_HASWELL/BROADWELL instead of HAS_POWER_WELL ... Conflicts: drivers/gpu/drm/i915/intel_display.c
2013-12-05Merge tag 'drm-intel-fixes-2013-12-02' of ↵Dave Airlie11-77/+82
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Just flushing out my pile of bugfixes, most of them for regressions/cc: stable. Nothing really serious going on. For outstanding issues we still have the S4 fun due to the hsw S4 duct-tape pending (seems like I need to switch into angry maintainer mode on that one). And there's the mode merging revert to make my g33 work again still pending for drm core. For that one I don't have any more clue (and it looks like no one else has a good idea either). And apparently the locking WARN fix in here also needs to be replicated for boot, still confirming that one though. * tag 'drm-intel-fixes-2013-12-02' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Pin pages whilst allocating for dma-buf vmap() drm/i915: MI_PREDICATE_RESULT_2 is HSW only drm/i915: Make the DERRMR SRM target global GTT drm/i915: use the correct force_wake function at the PC8 code drm/i915: Fix pipe CSC post offset calculation drm/i915: Simplify DP vs. eDP detection drm/i915: Check VBT for eDP ports on VLV drm/i915: use crtc_htotal in watermark calculations to match fastboot v2 drm/i915: Pin relocations for the duration of constructing the execbuffer drm/i915: take mode config lock around crtc disable at suspend drm/i915: Prefer setting PTE cache age to 3 drm/i915/ddi: set sink to power down mode on dp disable
2013-11-29drm/i915: Pin pages whilst allocating for dma-buf vmap()Chris Wilson1-5/+8
During the vmap() routine for the dma-buf, we first grab the pages and then try to allocate a temporary array to pass to the vmap(). However, the shrinker can and will reap any object that is unbound if the allocation for the array first fails. This includes the object which we are attempting to vmap(). The solution is to mark the object's pages as pinned whilst we try the allocation to prevent the use-after-free introduced by the potential shrinkage. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29drm/i915: Fix port name in vlv_wait_port_ready() timeout warningVille Syrjälä1-1/+1
We're currently misprinting the port name when vlv_wait_port_ready() times out. Fix it by using port_name(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29drm/i915: MI_PREDICATE_RESULT_2 is HSW onlyVille Syrjälä1-4/+3
The MI_PREDICATE_RESULT_2 register exits only on HSW. On other platforms the same offset is either reserved, or contains some other register. So write the register only on HSW. This regression has been introduced in commit 9435373ef8870e0a84b6fec0ad89b952bf3097fa Author: Rodrigo Vivi <rodrigo.vivi@gmail.com> Date: Wed Aug 28 16:45:46 2013 -0300 drm/i915: Report enabled slices on Haswell GT3 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Add regression notice.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29drm/i915: Make the DERRMR SRM target global GTTVille Syrjälä2-1/+3
The ring scratch pages don't have a PPGTT mapping, so the DERRM SRM should target the global GTT instead. v2: Add MI_SRM_LRM_GLOBAL_GTT define for -fixes Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-29drm/i915: use the correct force_wake function at the PC8 codePaulo Zanoni1-2/+2
When I submitted the first patch adding these force wake functions, Chris Wilson observed that I was using the wrong functions, so I sent a second version of the patch to correct this problem. The problem is that v1 was merged instead of v2. I was able to notice the problem when running the debugfs-forcewake-user subtest of pm_pc8 from intel-gpu-tools. Cc: stable@vger.kernel.org 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>
2013-11-28drm/i915: Fix pipe CSC post offset calculationVille Syrjälä1-1/+1
We were miscalculating the pipe CSC post offset for the full->limited range conversion. The resulting post offset was double what it was supposed to be, which caused blacks to come out grey when using limited range output on HSW+. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769 Cc: stable@vger.kernel.org Tested-by: Lauri Mylläri <lauri.myllari@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Return a drm_mode_status enum in the mode_valid vfuncsDamien Lespiau7-13/+19
We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: add intel_display_power_enabled_sw() for use in atomic ctxImre Deak4-13/+30
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>
2013-11-28drm/i915: drop DRM_ERROR in intel_fbdev initJesse Barnes1-1/+2
This should just be a debug. Add another debug msg to the inherit path while we're at it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72098 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Simplify DP vs. eDP detectionVille Syrjälä1-20/+6
Reduce the eDP detection to just checking if it's port A, or if the VBT tells us that the port is eDP for the other ports. Suggested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Check VBT for eDP ports on VLVVille Syrjälä4-9/+14
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>
2013-11-28drm/i915/vlv: use parallel context restore when coming out of RC6Jesse Barnes2-1/+2
Setting this bit restores all ring contexts in parallel rather than serially. Matches current BWG recommendations. Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Deepak S <deepak.s@inel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915/vlv: use a lower RC6 timeout on VLVJesse Barnes1-1/+1
We use timeout mode, and we need to lower the timeout to get good RC6 residency when loads are running. This gets me from 0% residency during glxgears to 77%, which is a pretty good improvement. This value also matches the current BWG recommentations. Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Deepak S <deepak.s@inel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915/sdvo: Fix up debug output to not split linesDaniel Vetter1-18/+37
It leads to a big mess when stuff interleaves. Especially with the new patch I've submitted for the drm core to no longer artificially split up debug messages. v2: The size parameter to snprintf includes the terminating 0, but the return value does not. Adjust the logic accordingly. Spotted by Mika. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: make sparse happy for the new vlv mmio read functionDaniel Vetter1-1/+1
It doesn't like that we assign 0 to a pointer, it wants the real NULL. On closer look that initialization is actually bogus, and the compiler can easily see that we never use it unitialized. So let's just drop this. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: drop the right force-wake engine in the vlv mmio funcsDaniel Vetter1-1/+1
This was fumbled in the conversion to per-engine forcewake. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Fix GT wake FIFO free entries for VLVVille Syrjälä2-4/+5
On VLV the GTFIFOCTL register has other bits besides the number of free entries in the GT wake FIFO. Apply a mask when we read th register to make sure we don't misinterpret the number of free FIFO entries. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: There's some unclarity about hsw, but brushed off as todays' Bspec just acting up a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Report all GTFIFODBG errorsVille Syrjälä2-4/+6
On VLV GTFIFODBG has more bits. Just report them all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Enabling DebugFS for valleyview forcewake countsDeepak S1-3/+11
Forcewake counts for valleyview are not exposed throgh DebugFS. Exposing with this change. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915/vlv: Valleyview support for forcewake Individual power wells.Deepak S3-31/+176
Split vlv force wake routines to help individually control Media/Render well based on the register access. We've seen power savings in the lower sub-1W range on workloads that only need on of the power wells, e.g. glbenchmark, media playback Note: The same split isn't there for the forcewake queue, only the forcwake domains are split. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Rebase on top of the removed forcewake hack in the ring irq get/put code and add a note to add Deepak's answer to Chris question.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Add power well arguments to force wake routines.Deepak S6-38/+56
Added power well arguments to all the force wake routines to help us individually control power well based on the scenario. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict with the removed forcewake hack and drop one spurious hunk Jesse noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-27drm/i915: use crtc_htotal in watermark calculations to match fastboot v2Jesse Barnes1-7/+8
This value is more correct, and matches what we read out in the fastboot code. Without this, the watermark code will panic after the first mode setting activity after a fastboot. v2: fix up HSW ->clock usage too (Ville) 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>
2013-11-27drm/i915: Do not attempt to re-enable an unconnected primary planeChris Wilson1-1/+6
Due to user fudging (for instance using video=VGA-1:e with FBDEV=n) we can attempt to reset an inconsistent CRTC that is marked as active but has no assigned fb. It would be wise to fix this earlier, but the long term plan is to have primary and secondary planes associated with a CRTC, in which crtc->fb being NULL will be expected. So for a quick short term fix with pretensions of grandeur, just check for a NULL fb during GPU reset and ignore the plane restoration. This fixes a potential hard hang (a panic in the panic handler) following a GPU hang. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Add a corresponding fixme comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-27drm/i915: Pin relocations for the duration of constructing the execbufferChris Wilson1-28/+32
As the execbuffer dispatch grows ever more complex and involves multiple stages of moving objects into the aperture, we need to take greater care that we do not evict our execbuffer objects prior to dispatch. This is relatively simple as we can just keep the objects pinned for not just the relocation but until we are finished. One such example is the possibility of the context switch causing an eviction or hitting the shrinker in order to fit its object into the aperture. Link: http://lists.freedesktop.org/archives/intel-gfx/2013-November/036166.html Reported-by: "Siluvery, Arun" <arun.siluvery@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Acked-by: Ben Widawsky <ben@bwidawsk.net> Tested-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add the additional explanations from Chris to the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: add a debugfs entry for power domain infoImre Deak3-0/+86
Add a debugfs entry showing the use-count for all power domains of each power well. v3: address comments from Paulo: - simplify power_domain_str() by using a switch table - move power_well::domain_count to power_domains - WARN_ON decrementing a 0 refcount Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: add a default always-on power wellImre Deak3-31/+16
So far we distinguished platforms without a dynamic power well with the HAS_POWER_WELL macro and for such platforms we didn't call any power domain functions. Instead of doing this check we can add an always-on power well for these platforms and call the power domain functions unconditionally. For always-on power wells we only increase/decrease their refcounts, otherwise they are nop. This makes high level driver code more readable and as a bonus provides some idea of the current power domains state for all platforms (once the relevant debugfs entry is added). v3: rename intel_power_wells to i9xx_always_on_power_well (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: don't do BDW/HSW specific powerdomains init on other platformsImre Deak1-0/+3
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: protect HSW power well check with IS_HASWELL in redisable_vgaJesse Barnes1-1/+1
This may need work if other platforms do the same thing, but in the meantime we should avoid looking at HSW specific bits in this generic function. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [added IS_BROADWELL too as that needs the same handling (Imre)] Signed-off-by: Imre Deak <imre.deak@intel.com> [danvet: Add Imre's missing sob.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: use IS_HASWELL/BROADWELL instead of HAS_POWER_WELLImre Deak1-2/+2
In intel_display_capture_error_state we use HAS_POWER_WELL to check if we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER which is specific to these platforms. Future platforms with power wells don't have this register, so HAS_POWER_WELL won't work there any more. Use IS_HASWELL/IS_BROADWELL instead. v3: fix using logical || instead of bitwise | (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: add always-on power wells instead of special casing themImre Deak2-28/+14
Instead of using a separate function to check whether a power domain is is always on, add an always-on power well covering all these power domains and do the usual get/put on these unconditionally. Since we don't assign a .set handler for these the get/put won't have any effect besides the adjusted refcount. This makes the code more readable and provides debug info also on the use of always-on power wells (once the relevant debugfs entry is added.) v3: make is_always_on to be bool instead of a bit field (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: support for multiple power wellsImre Deak2-20/+108
HW generations so far had only one always-on power well and optionally one dynamic power well. Upcoming HW gens may have multiple dynamic power wells, so add some infrastructure to support them. The idea is to keep the existing power domain API used by the rest of the driver and create a mapping between these power domains and the underlying power wells. This mapping can differ from one HW to another but high level driver code doesn't need to know about this. Through the existing get/put API it would just ask for a given power domain and the power domain framework would make sure the relevant power wells get enabled in the right order. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: add audio power domainImre Deak2-8/+3
This way the code is simpler and can also be used for other platforms where the audio power domain->power well mapping is different. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: take mode config lock around crtc disable at suspendJesse Barnes1-0/+2
This is just a theoretical issue, but we need to do this to prevent the WARN in pipe_from_connector at suspend time. This regression has been introduce in commit 7bd688cd66db93f6430f6e2b3145ee5686daa315 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Nov 8 16:48:56 2013 +0200 drm/i915: handle backlight through chip specific functions https://bugs.freedesktop.org/show_bug.cgi?id=71978 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: split fb allocation and initialization v2Jesse Barnes1-16/+46
If we use a stolen buffer, our probe callback shouldn't allocate a new buffer; we should re-use the one from the BIOS instead if possible. v2: fix locking (Jesse) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Drop forcewake w/a for missed interrupts/seqno on SandybridgeChris Wilson1-7/+0
I believe, and an evening of i-g-t, that our original workaround for the missed interrupts on Sandybridge, that of holding forcewake whilst we wait for an interrupts, is no longer required. This leaves us dependent on the second workaround of forcing an UC read of the ACTHD before reading back the seqno from the snooped HWS. Dropping the forcewake should allow us to conserve a little power, not much as the GPU is meant to be busy whilst we wait for it! Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Move the gtt mm takedown to cleanupBen Widawsky2-1/+2
Our VM code already has a cleanup function, and this is a nice place to put the drm_mm_takedown. This should have no functional impact, it just leaves the unload function a bit cleaer, and is more logical IMO Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Missed dropped VMA conversionBen Widawsky1-1/+1
This belonged in commit 07fe0b12800d4752d729d4122c01f41f80a5ba5a Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:10 2013 -0700 drm/i915: plumb VM into bind/unbind code But it was somehow missed along the way. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Remove defunct ctx switch commentsBen Widawsky1-2/+0
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Removed unused vm argsBen Widawsky1-5/+4
i915_gem_execbuffer_relocate became defunct in: commit 27173f1f95db5e74ceb35fe9a2f2f348ea11bac9 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Aug 14 11:38:36 2013 +0200 drm/i915: Convert execbuf code to use vmas eb_create: never used? Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: The lingering vm parameter to eb_create might have been back from the days where we didn't yet keep both vmas and obj lists in the eb struct. But I didn't check really.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Demote drop_caches_set printBen Widawsky1-1/+1
Many tests call this ad naseum now (in an infinite loop, very often). It clutters the logs. Actually, I'd rather drop it completely... Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Disallow dynamic ppgtt param modificationBen Widawsky1-1/+1
This would have never worked. 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>
2013-11-26drm/i915: Add a few missed bits to the mmBen Widawsky1-0/+6
This should really have been added in BDW integration, as well as: commit 93bd8649dba3155d1a0ba2a902d9c49f1c75a1da Author: Ben Widawsky <ben@bwidawsk.net> Date: Tue Jul 16 16:50:06 2013 -0700 drm/i915: Put the mm in the parent address space It didn't really matter before, but it will in the future. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-26drm/i915: Fix BDW PPGTT error pathBen Widawsky1-1/+7
When we fail for some reason on loading the PDPs, it would be wise to disable the PPGTT in the ring registers. If we do not do this, we have undefined results. 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>
2013-11-25drm/i915: Prefer setting PTE cache age to 3Chris Wilson1-2/+4
We have conflicting benchmark data that suggest either age 0 or age 3 is better. However, the earlier benchmark on which we based the switch to age 0 (commit 0d8ff15e9a15f2b393e53337a107b7a1e5919b6d Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Thu Jul 4 11:02:03 2013 -0700 drm/i915/hsw: Set correct Haswell PTE encodings) actually seems to prefer the default PTE encoding as age 3. Presumably, this is in part due to the use of MOCS to override the PTE encodings when appropriate. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69870 Tested-by: mengmeng.meng@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Eric Anholt <eric@anholt.net Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-25drm/i915: Don't set the fence number in DPFC_CTL on SNBVille Syrjälä1-1/+3
SNB has another register where the actual FBC CPU fence number is stored. The documenation explicitly states that the fence number in DPFC_CTL must be 0 on SNB. And in fact when it's not zero, the GTT tracking simply doesn't work. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-17 00:11:14 +0000