- 03 May, 2012 20 commits
-
-
Chris Wilson authored
Simplify object tracking by removing the inactive but pinned list. The only place where this was used is for counting the available memory, which is just as easy performed by checking all objects on the rare occasions it is required (application startup). For ease of debugging, we keep the reporting of pinned objects through the error-state and debugfs. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
This was only used by one external caller who would just be as happy with evict-everything, so perform the replacement and make the function private. In the process we note that unbinding the inactive list should not fail, and make it a warning instead. Signed-off-by:
-
Chris Wilson authored
Currently, we only bump the inactive LRU of an object when we bind into the GTT for a page-fault. As the object may be used many times before its mapping is zapped, we do not mark it as active as frequently as we should. Userspace should be calling set-to-GTT-domain before each pointer deference (for synchronous access) and so is a good place to mark the buffer as active. Marking the buffer as recently used places it at the end of the inactive eviction queue, though still before anything with outstanding rendering. This reduces the likelihood of evicting a buffer that is going to be used again by the CPU in the near future. This way we can hopefully avoid to kick out upload buffers right before we use them on the gpu. Note that we need to check that the object is not active or pinned, for otherwise we create havoc on the active/pinned lists, which also use obj->mm_list. The active lists are sorted by and evicted in last GPU rendering order, access by the CPU to a still active buffer therefore does not affect its eviction ordering. Pinned objects are currently excluded from eviction, therefore the only list that we need to bump for GTT access by the CPU is the inactive list. Signed-off-by:
-
Chris Wilson authored
Enabling the plane before we have assigned valid address means that it will access random PTE (often with conflicting memory types) and cause GPU lockups. However, enabling the plane too early appears to workaround a number of bugs in our modesetting code. Cc: Franz Melchior <melchior.franz@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=39947 References: https://bugs.freedesktop.org/show_bug.cgi?id=41091 References: https://bugs.freedesktop.org/show_bug.cgi?id=49041Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Chris Wilson authored
We were attempting to use a per-ring spinlock whilst modifying global IRQ flags. A recipe for rare missed interrupts. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Daniel Vetter authored
Copy&pasted from the vlv setup code. According to docs, we need that on ivb, too. v2: Use new masked bit handling macros. Reviewed-by:
-
Daniel Vetter authored
... and put them to so good use. Note that there's functional change in vlv clock gating code, we now no longer spuriously read back the current value of the bit. According to Bspec the high bits should always read zero, so ORing this in should have no effect. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
-
Jesse Barnes authored
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just treat them as part of the pipe. So split the code out and manage PCH PLLs separately, allocating them when needed or trying to re-use existing PCH PLL setups when the timings match. v2: add num_pch_pll field to dev_priv (Daniel) don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse) put register offsets in pll struct (Chris) v3: Decouple enable/disable of PLLs from get/put. v4: Track temporary PLL disabling during modeset v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni) v6: Avoid mishandling allocation failure by embedding the small array of PLLs into the device struct Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3+) Reviewed-by: -
Chris Wilson authored
gen2 hardware has some significant differences from the other interrupt routines that were glossed over and then forgotten about in the transition to KMS. Such as - 16bit IIR - PendingFlip status bit This patch reintroduces a handler specifically for gen2 for the purpose of handling pageflips correctly, simplifying code in the process. v2: Also fixup ring get/put irq to only access 16bit registers (Daniel) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24202 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41793Signed-off-by:
-
Chris Wilson authored
If we fail to unbind and so abort the change in tiling, we will have removed the VMA for the object for no reason. The likelihood of unbind failing is slim (other than ERESTARTSYS which will cause userspace to try again), so the change is mostly for the principle. Also improve the slightly stale comment. Signed-off-by:
-
Chris Wilson authored
Rename obj->tiling_changed to obj->fence_dirty so that it is clear that it flags when the parameters for an active fence (including the no-fence) register are changed. Also, do not set this flag when the object does not have a fence register allocated currently and the gpu does not depend upon the unfence. This case works exactly like when a tiled object lost its fence and hence does not need additional handling for the tiling change in the code. v2: Use fence_dirty to better express what the flag tracks and add a few more details to the comments to serve as a reminder of how the GPU also uses the unfenced register slot. Signed-off-by:
-
Daniel Vetter authored
When fixing up the crt load detect code I've failed to notice the same problem in the tv load detect code. Again, unconditionally use the load detect pipe infrastructure, it gets things right. Reviewed-by:
-
Daniel Vetter authored
This got lost in the intel_pm.c move. Signed-off-by: -
Ben Widawsky authored
As with one of the earlier patches in the series, we're forced to cast for copy_[to|from]_user. Again because of the nature of the GEN x86 exclusivity, this should be safe. Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> [danvet: Added some bikeshed.] Signed-off-by:
-
Daniel Vetter authored
These were mostly straight forward. No forced casting needed. Signed-off-by:
-
Ben Widawsky authored
With the exception of a forced cast for phys_obj stuff (a problem in other patches as well) all of these are fairly simple __iomem compliance fixes. As with other patches, yank/paste errors may exist. Signed-off-by:
-
Ben Widawsky authored
Almost all of the errors related __iomem problems. Most of the changes here are trivial, however there is plenty of chance for yank/paste errors. Signed-off-by:
-
Chris Wilson authored
This was originally used as an attempt to diagnose GPU hangs, but was never very reliable and superseded by the i915_error_state capture on hangcheck. It now lies languishing unused and unwanted. Signed-off-by:
-
Chris Wilson authored
IvyBridge requires an extra frame between disabling the low power watermarks and enabling scaling on the sprite plane. If the scaling is already enabled, then we have already disabled the low power watermarks and need not incur an extra wait. Similarly, as we disable the scaling when turning off the sprite plane, we can update the scaling enabled flag and restore the low power watermarks. Signed-off-by:
-
Daniel Vetter authored
Pretty useful to debug our DP bandwidth woes. v2: Also print out the required and available link bandwidth, suggested by Chris Wilson. v3: Also print out the input parameters so that diagnosing failures to find a valid dp link configuration is possible. v4: s/Display port/DP/ to shorten the output. Reviewed-by:
-
- 02 May, 2012 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-2012-04-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next Daniel Vetter writes: A new drm-intel-next pull. Highlights: - More gmbus patches from Daniel Kurtz, I think gmbus is now ready, all known issues fixed. - Fencing cleanup and pipelined fencing removal from Chris. - rc6 residency interface from Ben, useful for powertop. - Cleanups and code reorg around the ringbuffer code (Ben&me). - Use hw semaphores in the pageflip code from Ben. - More vlv stuff from Jesse, unfortunately his vlv cpu is doa, so less merged than I've hoped for - we still have the unused function warning :( - More hsw patches from Eugeni, again, not yet enabled fully. - intel_pm.c refactoring from Eugeni. - Ironlake sprite support from Chris. - And various smaller improvements/fixes all over the place. Note that this pull request also contains a backmerge of -rc3 to sort out a few things in -next. I've also had to frob the shortlog a bit to exclude anything that -rc3 brings in with this pull. Regression wise we have a few strange bugs going on, but for all of them closer inspection revealed that they've been pre-existing, just now slightly more likely to be hit. And for most of them we have a patch already. Otherwise QA has not reported any regressions, and I'm also not aware of anything bad happening in 3.4. * tag 'drm-intel-next-2012-04-23' of git://people.freedesktop.org/~danvet/drm-intel: (420 commits) drm/i915: rc6 residency (fix the fix) drm/i915/tv: fix open-coded ARRAY_SIZE. drm/i915: invalidate render cache on gen2 drm/i915: Silence the change of LVDS sync polarity drm/i915: add generic power management initialization drm/i915: move clock gating functionality into intel_pm module drm/i915: move emon functionality into intel_pm module drm/i915: move drps, rps and rc6-related functions to intel_pm drm/i915: fix line breaks in intel_pm drm/i915: move watermarks settings into intel_pm module drm/i915: move fbc-related functionality into intel_pm module drm/i915: Refactor get_fence() to use the common fence writing routine drm/i915: Refactor fence clearing to use the common fence writing routine drm/i915: Refactor put_fence() to use the common fence writing routine drm/i915: Prepare to consolidate fence writing drm/i915: Remove the unsightly "optimisation" from flush_fence() drm/i915: Simplify fence finding drm/i915: Discard the unused obj->last_fenced_ring drm/i915: Remove unused ring->setup_seqno drm/i915: Remove fence pipelining ...
-
- 01 May, 2012 5 commits
-
-
Rafał Miłecki authored
Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Tested-by:
Christian König <deathsimple@vodafone.de> Reviewed-by:
Dave Airlie <airlied@redhat.com>
-
Rafał Miłecki authored
If we want hdmi_offset to be relative to the first block, zero value can be used also for enabled block. Signed-off-by:
-
Rafał Miłecki authored
R6xx has routable blocks, but there's nothing wrong in assignment based on dig_encoder. We didn't really need that algorithm. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Tested-by:
-
- 30 Apr, 2012 1 commit
-
-
Dave Airlie authored
this fixes a report that the new load code needed to be updated for ajax's validity changes. Signed-off-by:
-
- 27 Apr, 2012 13 commits
-
-
Robert Morell authored
This helper macro retrieves the fractional part of a fixed20_12 20.12 fixed-point number. Signed-off-by:
Robert Morell <rmorell@nvidia.com> Signed-off-by:
Olof Johansson <olofj@chromium.org> Signed-off-by:
Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by:
-
Alan Cox authored
Some boards such as the Intel D2700MUD allow you to have over 4GB of RAM. The GTT on the PVR based devices is 32bit however. Hugh Dickins points out that we should therefore be setting the mapping gfp mask. This is not the whole fix for the problem. Some further shmem patches will be needed to deal with the corner cases. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
This provides the needed callback hooks to add hotplug display support to the GMA36x0 devices. Signed-off-by:
-
Alan Cox authored
In particular clean up the errata handling and correct the crtc masks. We do this a bit differently using our device abstraction for neatness. This doesn't address the ACPI opregion and hotplug plumbing, nor the IRQ related changes that will need. It touches on backlight init but the full backlight support is not in this change set. Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
The problem in console mode is lack of linear memory. We can solve that by dropping to 16bpp. The mode setting X server will allocate its own GEM framebuffer in 32bpp and all will be well. We could just do 16bpp anyway but that would be a regression on the lower modes as many distributions don't yet ship the generic mode setting KMS drivers. Signed-off-by:
-
Alan Cox authored
Introduce a panel presence check for Cedartrail. Non netbook devices don't necessarily have a panel attached. Signed-off-by:
-
Alan Cox authored
Pull in various i915 bits that we will need to begin tackling the LVDS detect and ACPI events. We try and drift towards the i915 version of the code with the long term goal that at least some of it can one day be unified. Signed-off-by:
-
Alan Cox authored
We don't want them uncached, combining will do nicely and fixes the performance problem with the generic modesetting X server. Signed-off-by:
-
Alan Cox authored
Signed-off-by: -
Alan Cox authored
We need to pull more stuff from the VBT in order to configure the clocking correctly in all cases. Add the relevant bits from the other CDV driver work. Signed-off-by:
-
Alan Cox authored
This was reported a long time ago (and I apologize to whoever it was that reported it as I've lost the original report). Signed-off-by:
-
