summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: slightly improve gt enable/disable routinesEugeni Dodonov2012-07-051-4/+2
| | | | | | | | Just a cosmetic change to simplify the if statement. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add RPS configuration for HaswellEugeni Dodonov2012-07-052-12/+26
| | | | | | | | | | | | | | | | | | | | | Most of the RPS and RC6 enabling functionality is similar to what we had on Gen6/Gen7, so we preserve most of the registers. Note that Haswell only has RC6, so account for that as well. As suggested by Daniel Vetter, to reduce the amount of changes in the patch, we still write the RC6p/RC6pp thresholds, but those are ignored on Haswell. Note: Some discussion about the nature of the new tuning constants popped up in review - the answer is that we don't know why they've changed, but the guide from VPG with the magic numbers simply has different values now. v2: Squash fix for ?: vs | operation precende bug into this patch. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Added note to commit message. Squashed fix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: support Haswell force wakingEugeni Dodonov2012-07-032-4/+19
| | | | | | | | | There is a different ACK register for force wake on Haswell, so account for that. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement w/a for sporadic read failures on waking from rc6Chris Wilson2012-07-032-0/+26
| | | | | | | | | | | | | | | | | As a w/a to prevent reads sporadically returning 0, we need to wait for the GT thread to return to TC0 before proceeding to read the registers. v2: adapt for Haswell changes (Eugeni). v3: use wait_for_atomic_us for thread status polling. v3: *really* use wait_for_atomic for polling. References: https://bugs.freedesktop.org/show_bug.cgi?id=50243 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Group the GT routines together in both code and vtableChris Wilson2012-07-035-80/+73
| | | | | | | | | | | | | | | Tidy up the routines for interacting with the GT (in particular the forcewake dance) which are scattered throughout the code in a single structure. v2: use wait_for_atomic for polling. v3: *really* use wait_for_atomic for polling. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: linuxify create_hw_context()Ben Widawsky2012-06-291-26/+24
| | | | | | | | | | | Daniel complained about this on initial review, but he graciously moved the patches forward. As promised, I am delivering the desired cleanup now. Hopefully I didn't screw the trivial patch up ;-) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix PIPE_WM_LINETIME definitionPaulo Zanoni2012-06-281-1/+1
| | | | | | | | Looks like a copy/paste error. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: "Flush Me Harder" required on gen6+Daniel Vetter2012-06-281-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The prep to remove the flushing list in commit cc889e0f6ce6a63c62db17d702ecfed86d58083f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 13 20:45:19 2012 +0200 drm/i915: disable flushing_list/gpu_write_list causes quite some decent regressions. We can fix this by setting the CS_STALL bit to ensure that the following seqno write happens only after the cache flush has completed. But only do that when the caller actually wants the flush (and not also when we invalidate caches before starting the next batch). I've looked through all our ancient scrolls about gen6+ pipe control workarounds, and this seems to be indeed a legal combination: We're allowed to set the CS_STALL bit when we flush the render cache (which we do). While yelling at this code, also pass back the return value from intel_emit_post_sync_nonzero_flush properly. v2: Instead of emitting more pipe controls, set the CS_STALL bit on the write flush as suggested by Chris Wilson. It seems to work, too. Cc: Eric Anholt <eric@anholt.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51436 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51429 Tested-by: Lu Hua <huax.lu@intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/sprite: Fix mem leak in intel_plane_init()Jesper Juhl2012-06-271-1/+1
| | | | | | | | | | | | | If we ever hit the default case in the switch statement we'll return from the function without freeing the memory we just allocated to 'intel_plane' (but that has not been used). This patch gets rid of the leak by freeing the memory just before we return. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: correct IVB default sprite formatJesse Barnes2012-06-271-1/+1
| | | | | | | | We shouldn't hit this path anyway, but make it use the IVB sprite format definition to avoid confusion. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: mask tiled bit when updating IVB spritesJesse Barnes2012-06-271-0/+1
| | | | | | | Or going from tiled to untiled may break. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: disable drm agp support for !gen3 with kms enabledDaniel Vetter2012-06-251-6/+15
| | | | | | | | | | | | | | | | | | | | | This is the quick&dirty way Dave Airlie suggested to workaround the midlayer drm agp brain-damange. Note that i915_probe is only called when the driver has ksm enabled, so no need to check for that. We also need to move the intel_agp_enabled check at the right place. Note that the only thing this does is enforce the correct module load order (by using a symbol from intel-agp.ko) to ensure that the fake agp driver is ready before the drm core tries to set up the agp stuff. v2: Add a comment to explain why gen3 needs all this legacy fake agp stuff - we've shipped an XvMC library with a kms-enabled ddx that requires it (but only on gen3). v3: Make it clear that this is only a gen3 issue in the comment. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't use dev->agpDaniel Vetter2012-06-251-1/+1
| | | | | | | | | This single leftover use is due to a patch that went into 3.5 through -fixes. With the fake agp stuff on demise, at least for gen6+ we can't use this any more. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make enable/disable_gt_powersave locking consistentDaniel Vetter2012-06-252-19/+15
| | | | | | | | | | | | | | The enable functions grabbed dev->struct_mutex themselves, whereas the disable functions expected dev->struct_mutex to be held by the caller. Move the locking out to the (currently only) callsite of intel_enable_gt_powersave to make this more consistent. Originally this was prep work for future patches, but I've chased down a totally wrong alley. Still, I think this is a sensible clarification. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: wrap up gt powersave enabling functionsDaniel Vetter2012-06-254-37/+35
| | | | | | | | | | | | ... instead of calling each one for each generation indiviudally. Notice that we've already managed to be inconsistent, the resume path is missing an IS_VLV check. As a nice benefit we can mark all the platform specific enable/disable functions as static and hide them in intel_pm.c Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.5-rc4' into drm-intel-next-queuedDaniel Vetter2012-06-2551-1472/+998
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want to merge the "no more fake agp on gen6+" patches into drm-intel-next (well, the last pieces). But a patch in 3.5-rc4 also adds a new use of dev->agp. Hence the backmarge to sort this out, for otherwise drm-intel-next merged into Linus' tree would conflict in the relevant code, things would compile but nicely OOPS at driver load :( Conflicts in this merge are just simple cases of "both branches changed/added lines at the same place". The only tricky part is to keep the order correct wrt the unwind code in case of errors in intel_ringbuffer.c (and the MI_DISPLAY_FLIP #defines in i915_reg.h together, obviously). Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_ringbuffer.c Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/edid: don't return stack garbage from supports_rbDaniel Vetter2012-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We need to initialize this to false, because the is_rb callback only ever sets it to true. Noticed while reading through the code. Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon: SI tiling fixes for displayAlex Deucher2012-06-202-1/+81
| | | | | | | | | | | | | | | | | | - Use the correct union for getting the tiling info - Properly init the PIPE_CONFIG field for SI Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-06-162-8/+54
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: cache the EDID for eDP panels Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere" drm/i915: eDP aux needs vdd drm/i915: don't enumerate HDMID if an eDP panel is already active on the port
| | * drm/i915: cache the EDID for eDP panelsJesse Barnes2012-06-161-6/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They aren't going anywhere, and probing on DDC can cause the panel to blank briefly, so read them up front and cache them for later queries. v2: fix potential NULL derefs in intel_dp_get_edid_modes and intel_dp_get_edid (Jani) copy full EDID length, including extension blocks (Takashi) free EDID on teardown (Takashi) v3: malloc a new EDID buffer that's big enough for the memcpy (Chris) v4: change handling of NULL EDIDs, just preserve the NULL behavior across detects and mode list fetches rather than trying to re-fetch the EDID (Chris) v5: be glad that Chris is around to remind me to hit C-x C-s before committing. References: https://bugs.freedesktop.org/show_bug.cgi?id=46856 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"Daniel Vetter2012-06-161-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 092945e11c5b84f66dd08f0b87fb729715d377bc. This commit prevents a DP screen from properly training the link. Oddly enough it works, once the machine has been warm-booted with an older kernel. According to DP docs this _should_ have been the right precharge time. Also, the commit that originally introduces this was just general snb DP enabling and didn't mention any specific reason for this special value. Whatever, trust the reporter that this makes things worse and let's just revert it. v2: Less spelling fail. Cc: Adam Jackson <ajax@redhat.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reported-by: "Wouter M. Koolen" <W.M.Koolen-Wijkstra@cwi.nl> Buglink: https://lkml.org/lkml/2012/6/14/301 Cc: stable@vger.kernel.org (only for 3.4) Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: eDP aux needs vddDaniel Vetter2012-06-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new oui probe has been missing these. This issue has been introduce in commit 0d198328538276c4459ef5de081e68ae60e6c4c2 Author: Adam Jackson <ajax@redhat.com> Date: Mon May 14 16:05:47 2012 -0400 drm/i915/dp: Probe branch/sink OUIs v2: Do the eDP vdd dance of simply not probing the OUI on eDP panels as suggested by Chris Wilson. v3: Fix up the error path fail - I suck. Cc: Adam Jackson <ajax@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50808 Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Bugreport: http://permalink.gmane.org/gmane.comp.video.dri.devel/69695 Tested-by: Yang Guang <guang.a.yang@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: don't enumerate HDMID if an eDP panel is already active on the portJesse Barnes2012-06-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This prevents the HDMI detect functions from poking at an eDP connected panel, which can lead to trouble. [danvet: Note that we have some other reports of DP vs. HDMI fighting, but the general case is a much bigger fish to fry.] References: https://bugs.freedesktop.org/show_bug.cgi?id=42278 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/radeon: add support for STRMOUT_BASE_UPDATE on 7xxAlex Deucher2012-06-163-1/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Required for streamout. Bump drm minor. Marek v2: fix pkt->count check Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: add some additional 6xx/7xx/EG register initAlex Deucher2012-06-166-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - SMX_SAR_CTL0 needs to be programmed correctly to prevent problems with memory exports in certain cases. - VC_ENHANCE needs to be initialized on 6xx/7xx. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: enable HDMI on DCE5 (AKA NI excluding Aruba)Rafał Miłecki2012-06-165-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After recent changes HDMI code is ready to be enabled on DCE5. This patch just changes conditions to execute already present code on DCE5. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Christian König <christian.koenig@amd.com> Tested-by: Andre Heider <a.heider@gmail.com> Tested-by: Zoltán Böszörményi <zboszor@pr.hu> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm sis: initialize object_idrMárton Németh2012-06-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The filed object_idr of struct drm_sis_private was introduced with commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6de8a748881f1cd9d795454da2b6db616d5ca3d7 . The idr_init(&dev->object_name_idr) is called instead of idr_init(&dev_priv->object_idr) by mistake, leaving object_idr uninitialized. Correct this. This patch was not tested because of lack of hardware. Signed-off-by: Márton Németh <nm127@freemail.hu> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm via: initialize object_idrMárton Németh2012-06-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The field obejct_idr of struct drm_via_private was introduced with the commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=77ee8f3825054f23b17e9c8f728f061defd86cdc . In that patch idr_init(&dev->object_name_idr) was called instead of idr_init(&dev_priv->object_idr) by mistake, leaving the dev_priv->object_idr uninitialized. To be more exact, the object_idr buffer is filled with zeros because of kzalloc(), but the dev_priv->object_idr.lock spinlock can cause system freeze at lib/idr.c:move_to_free_list() when spin_lock_irqsave() is called on this spinlock. The patch was tested on Clevo D4J, model D410J laptop, on the following hardware, without AGP kernel module loaded: # lspci -s 01:00.0 -n 01:00.0 0300: 1106:3108 (rev 01) # lspci -s 01:00.0 -v 01:00.0 VGA compatible controller: VIA Technologies, Inc. K8M800/K8N800/K8N800A [S3 UniChrome Pro] (rev 01) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device 4702 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at f0000000 (32-bit, prefetchable) [size=64M] Memory at d1000000 (32-bit, non-prefetchable) [size=16M] Expansion ROM at <unassigned> [disabled] Capabilities: [60] Power Management version 2 Capabilities: [70] AGP version 3.0 Signed-off-by: Márton Németh <nm127@freemail.hu> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon/prime: reserve/unreserve around pinDave Airlie2012-06-161-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | I finally got to test this code a bit more and hit the ttm no reserved assert, so add the reservations around the pinning. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: fix regression in dynpm due to multi-ring reworkAlex Deucher2012-06-161-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not all asics have all rings, so make sure the ring is ready before attempting to check it in the dynpm work handler. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43367 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/udl: only bind to the video devices on the hub.Dave Airlie2012-06-161-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | This is ported from udlfb. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=832188 Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/ttm: Fix buffer object metadata accounting regression v2Thomas Hellstrom2012-06-121-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A regression was introduced in the 3.3 rc series, commit "drm/ttm: simplify memory accounting for ttm user v2", causing the metadata of buffer objects created using the ttm_bo_create() function to be accounted twice. That causes massive leaks with the vmwgfx driver running for example SpecViewperf Catia-03 test 2, eventually killing the app. Furthermore, the same commit introduces a regression where metadata accounting is leaked if a buffer object is initialized with an illegal size. This is also fixed with this commit. v2: Fixed an error path and removed an unused variable. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/radeon: fix tiling and command stream checking on evergreen v3Jerome Glisse2012-06-102-5/+47
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix regresson since the introduction of command stream checking on evergreen (thread referenced below). Issue is cause by ddx allocating bo with formula width*height*bpp while programming the GPU command stream with ALIGN(height, 8). In some case (where page alignment does not hide the extra size bo should be according to height alignment) the kernel will reject the command stream. This patch reprogram the command stream to slice - 1 (slice is a derivative value from height) which avoid rejecting the command stream while keeping the value of command stream checking from a security point of view. This patch also fix wrong computation of layer size for 2D tiled surface. Which should fix issue when 2D color tiling is enabled. This dump the radeon KMS_DRIVER_MINOR so userspace can know if they are on a fixed kernel or not. https://lkml.org/lkml/2012/6/3/80 https://bugs.freedesktop.org/show_bug.cgi?id=50892 https://bugs.freedesktop.org/show_bug.cgi?id=50857 !!! STABLE need a custom version of this patch for 3.4 !!! v2: actually bump the minor version and add comment about stable v3: do compute the height the ddx was trying to use [airlied: drop left over debug] Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Revert "drm/i915/crt: Do not rely upon the HPD presence pin"Linus Torvalds2012-06-081-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 9e612a008fa7fe493a473454def56aa321479495. It incorrectly finds VGA connectors where none are attached, apparently not noticing that nothing replied to the EDID queries, and happily using the default EDID modes that have nothing to do with actual hardware. That in turn then causes X to fall down to the lowest common denominator, which is usually the default 1024x768 mode that is in the default EDID and pretty much anything supports). I'd suggest that if not relying on the HDP pin, the code should at least check whether it gets valid EDID data back, rather than just assume there's something on the VGA connector. Cc: Dave Airlie <airlied@linux.ie> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * Merge branch 'exynos-drm-fixes' of ↵Dave Airlie2012-06-086-27/+28
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.infradead.org/users/kmpark/linux-samsung into drm-fixes * 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung: drm/exynos: fixed blending for hdmi graphic layer drm/exynos: Remove dummy encoder get_crtc operation implementation drm/exynos: Keep a reference to frame buffer GEM objects drm/exynos: Don't cast GEM object to Exynos GEM object when not needed drm/exynos: DRIVER_BUS_PLATFORM is not a driver feature drm/exynos: fixed size type. drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}
| | * drm/exynos: fixed blending for hdmi graphic layerSeung-Woo Kim2012-06-051-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Blending for graphic layer 0 of hdmi mixer was not set so video layer cannot be showed if graphic layer 0 is enabled. This patch fixes blending values to support blending between graphic layer 0 and video layer. Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| | * drm/exynos: Remove dummy encoder get_crtc operation implementationLaurent Pinchart2012-06-051-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The encoder get_crtc operation is called to retrieve a pointer to the CRTC the encoder is currenctly connected to, right after setting the encoder::crtc field to the new CRTC. The implementation of this operation returns the pointer to the new CRTC, which is then pointlessly compared to itself. As the operation is not mandatory, don't implement it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
| | * drm/exynos: Keep a reference to frame buffer GEM objectsLaurent Pinchart2012-06-051-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GEM objects used by frame buffers must be referenced for the whole life of the frame buffer. Release the references in the frame buffer destructor instead of its constructor. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
| | * drm/exynos: Don't cast GEM object to Exynos GEM object when not neededLaurent Pinchart2012-06-051-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The exynos_drm_gem_dumb_map_offset() doesn't need to access any Exynos-specific GEM object fields, don't cast the GEM object. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
| | * drm/exynos: DRIVER_BUS_PLATFORM is not a driver featureLaurent Pinchart2012-06-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | DRIVER_BUS_PLATFORM is a bus type used internally in the DRM core, not a flag for the drm_driver::driver_features field. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
| | * drm/exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}Ville Syrjälä2012-06-052-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The NV12M/YUV420M formats are identical to the already existing standard NV12/YUV420 formats. The M variants will be removed, so convert the driver to use the standard names. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
| * | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-06-087-17/+128
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler char/agp: add another Ironlake host bridge drm/i915: fix up ivb plane 3 pageflips drm/i915: hold forcewake around ring hw init drm/i915: Mark the ringbuffers as being in the GTT domain drm/i915/crt: Do not rely upon the HPD presence pin drm/i915: Reset last_retired_head when resetting ring
| | * | drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handlerAdam Jackson2012-06-062-6/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cougar/Panther Point redefine the bits in SDEIIR pretty completely. This function is just debugging, but if we're debugging we probably want to be told accurate things instead of lies. I'm told Lynx Point changes this yet more, but I have no idea how... Note from Eugeni's review: "For the record and for future enabling efforts, for LPT, bits 28-31 and 1-14 are gone since CPT/PPT (e.g., those must be zero). And there is the bit 15 as a new addition, but we are not using it yet and probably won't be using in foreseeable future." Signed-off-by: Adam Jackson <ajax@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35103 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: fix up ivb plane 3 pageflipsDaniel Vetter2012-06-052-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Or at least plug another gapping hole. Apparrently hw desingers only moved the bit field, but did not bother ot re-enumerate the planes when adding support for a 3rd pipe. Discovered by i-g-t/flip_test. This may or may not fix the reference bugzilla, because that one smells like we have still larger fish to fry. v2: Fixup the impossible case to catch programming errors, noticed by Chris Wilson. References: https://bugs.freedesktop.org/show_bug.cgi?id=50069 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: hold forcewake around ring hw initDaniel Vetter2012-06-043-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Empirical evidence suggests that we need to: On at least one ivb machine when running the hangman i-g-t test, the rings don't properly initialize properly - the RING_START registers seems to be stuck at all zeros. Holding forcewake around this register init sequences makes chip reset reliable again. Note that this is not the first such issue: commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 Author: Sean Paul <seanpaul@chromium.org> Date: Fri Mar 16 12:43:22 2012 -0400 drm/i915: Add wait_for in init_ring_common added delay loops to make RING_START and RING_CTL initialization reliable on the blt ring at boot-up. So I guess it won't hurt if we do this unconditionally for all force_wake needing gpus. To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new intel_info bit for that. v2: Fixup missing commas in static struct and properly handling the error case in init_ring_common, both noticed by Jani Nikula. Cc: stable@vger.kernel.org Reported-and-tested-by: Yang Guang <guang.a.yang@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Mark the ringbuffers as being in the GTT domainChris Wilson2012-06-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By correctly describing the rinbuffers as being in the GTT domain, it appears that we are more careful with the management of the CPU cache upon resume and so prevent some coherency issue when submitting commands to the GPU later. A secondary effect is that the debug logs are then consistent with the actual usage (i.e. they no longer describe the ringbuffers as being in the CPU write domain when we are accessing them through an wc iomapping.) Reported-and-tested-by: Daniel Gnoutcheff <daniel@gnoutcheff.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41092 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/crt: Do not rely upon the HPD presence pinChris Wilson2012-05-311-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whilst most monitors do wire up the HPD presence pin, it seems quite a few KVM do not. Therefore if we simply rely on the HPD pin being asserted to indicate a connected monitor we fail miserable, so fall back to performing a DCC query for the EDID. Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Reset last_retired_head when resetting ringChris Wilson2012-05-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we reset the ring control registers, including the HEAD and TAIL of the ring, we also need to reset associated state. In this instance, we were failing to reset the cached value of ring->last_retired_head and so upon the first request for more space following a resume would potentially (depending on a narrow race window) believe that the HEAD had advanced much further than reality. This is a regression from: commit a71d8d94525e8fd855c0466fb586ae1cb008f3a2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Feb 15 11:25:36 2012 +0000 drm/i915: Record the tail at each request and use it to estimate the head Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/radeon/kms: add new Trinity PCI idsAlex Deucher2012-06-051-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: fix vm deadlocks on caymanChristian König2012-06-051-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Locking mutex in different orders just screams for deadlocks, and some testing showed that it is actually quite easy to trigger them. Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
OpenPOWER on IntegriCloud