summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
* drm/nouveau/i2c: resume use of i2c-algo-bit, rather than custom stackBen Skeggs2012-05-072-178/+22
| | | | | | | | | | | | | Previous issues with i2c-algo-bit have now been resolved. This is a revert of f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d mostly, due to fixes in the i2c core repairing the original issue, this code isn't required and was causing regressions. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reported-by: Nick Bowler <nbowler@elliptictech.com> Tested-by: Nick Bowler <nbowler@elliptictech.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+Daniel Vetter2012-05-071-3/+6
| | | | | | | | | | | I've flagged this while reviewing the first version and Ken Graunke fixed it up in v2, but unfortunately Dave Airlie picked up the wrong version. Cc: Dave Airlie <airlied@redhat.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: stable@kernel.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: disable sdvo hotplug on i945g/gmDaniel Vetter2012-05-071-0/+6
| | | | | | | | | | | | | | | | | | | | | | | Chris Wilson dug out a hw erratum saying that there's noise on the interrupt line on i945G chips. We also have a bug report from a i945GM chip with an sdvo hotplug interrupt storm (and no apparent cause). Play it safe and disable sdvo hotplug on all i945 variants. Note that this is a regression that has been introduced in 3.1, when we've enabled sdvo hotplug support with commit cc68c81aed7d892deaf12d720d5455208e94cd0a Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Date: Wed Sep 21 17:13:30 2011 +0100 drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI Cc: stable@kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442 Reported-and-tested-by: Dominik Köppl <dominik@devwork.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/radeon: clarify and extend wb setup on APUs and NI+ asicsAlex Deucher2012-05-041-2/+2
| | | | | | | | | Use family rather than DCE check for clarity, also always use wb on APUs, there will never be AGP variants. 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-05-035-12/+21
|\ | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: enable dip before writing data on gen4 fixing dmi match for hp t5745 and hp st5747 thin client drm/i915: Only enable IPS polling for gen5 drm/i915: Do not read non-existent DPLL registers on PCH hardware
| * drm/i915: enable dip before writing data on gen4Paulo Zanoni2012-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While testing with the intel_infoframes tool on gen4, I see that when video DIP is disabled, what we write to the DATA memory is not exactly what we read back later. This regression has been introduce in commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 22 11:16:00 2011 +0530 drm/i915: fix ILK+ infoframe support That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Cc: stable@kernel.org Tested-by: Yang Guang <guang.a.yang@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> [danvet: Pimped commit message by using the usual commit citation layout.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * fixing dmi match for hp t5745 and hp st5747 thin clientMarc Gariepy2012-05-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Match the correct information which is DMI_PRODUCT_NAME instead of DMI_BOARD_NAME See dmidecode information on launchpad for both thin client: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916 Signed-off-by: Marc Gariepy <mgariepy@ubuntu.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Only enable IPS polling for gen5Chris Wilson2012-05-022-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On SandyBridge IPS was entirely implemented in hardware and not reliant on the driver monitoring power consumption and feeding back desired run states, so the hardware is able to adapt quicker and more flexibly. Which is a huge relief for us as we no longer have to carry empirically derived magic algorithms. Yet despite the advance in technology, the driver was still doing its IPS polling on all machines. Restrict it to the only supported hardware, Clarkdale/Arrandale. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Do not read non-existent DPLL registers on PCH hardwareChris Wilson2012-05-021-4/+5
| | | | | | | | | | | | | | | | | | | | | | We only execute intel_decrease_pllclock for pre-PCH hardware, typically gen4 mobiles. However, in the variable declaration we did read from the non-PCH DPLL register, quite naughty and detected by SandyBridge. Reported-and-tested-by: Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | nouveau: initialise has_optimus variable.Dave Airlie2012-05-031-1/+1
| | | | | | | | | | | | | | We should initialise this to 0 really to avoid getting false positives. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/nv10/gpio: fix thinko in mask for gpio lines 2-9Ben Skeggs2012-04-301-1/+1
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | nvc0/fb: shut up PMFB interrupt after the first occurrenceChristoph Bumiller2012-04-301-0/+5
| | | | | | | | | | Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/hdmi: use correct hdmi regs for nvaa/nvacBen Skeggs2012-04-301-1/+3
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/bios: fix regression on some nv4x boardBen Skeggs2012-04-301-3/+7
|/ | | | | | | | | | We started using the connector table on nv4x a while back, and this VBIOS has bad connector indices which causes the wrong encoders to get paired with connectors. Add a quirk to fix this... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.Kenneth Graunke2012-04-282-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when using separate stencil buffers. Without it, the GPU tries to use the LRA eviction policy, which isn't supported. This was supposed to be off by default, but seems to be on for many machines. This cannot be done in gen6_init_clock_gating with most of the other workaround bits; the render ring needs to exist. Otherwise, the register write gets dropped on the floor (one printk will show it changed, but a second printk immediately following shows the value reverts to the old one). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535 Cc: stable@vger.kernel.org Cc: Rob Castle <futuredub@gmail.com> Cc: Eric Appleman <erappleman@gmail.com> Cc: aaron667@gmx.net Cc: Keith Packard <keithp@keithp.com> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: need to set up ss on DP bridges as wellAlex Deucher2012-04-281-2/+2
| | | | | | | | | | | | | Makes Nutmeg DP to VGA bridges work for me. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=42490 Noticed by Jerome Glisse (after weeks of debugging). Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: use frac fb div on APUsAlex Deucher2012-04-271-0/+3
| | | | | | | | | | | Seems to be more stable on certain monitors. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=48880 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: add a missing entry to encoder_namesIlija Hadzic2012-04-271-1/+2
| | | | | | | | An entry for INTERNAL_VCE encoder was missing. Add it. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-04-273-35/+36
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes From Daniel Vetter - VGA load-detect fix. This bug seems to be as old as the load-detect code (2.6.30), but needs stupid userspace (upowerd trying to detect connectors on dpms-off outputs) to actually kill the machine. And obviously a machine without VGA-hotplug, otherwise we don't do load detect. - 2 interger overflow fixes for unpriviledged ioctls from Xi Wang. - Fix SDVO regression for low-res (pixelclock < 100MHz) digital outputs, introduce in 2.6.36. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: handle input/output sdvo timings separately in mode_set drm/i915: fix integer overflow in i915_gem_do_execbuffer() drm/i915: fix integer overflow in i915_gem_execbuffer2() drm/i915: fixup load-detect on enabled, but not active pipe
| * drm/i915: handle input/output sdvo timings separately in mode_setDaniel Vetter2012-04-261-16/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We seem to have a decent confusion between the output timings and the input timings of the sdvo encoder. If I understand the code correctly, we use the original mode unchanged for the output timings, safe for the lvds case. And we should use the adjusted mode for input timings. Clarify the situation by adding an explicit output_dtd to the sdvo mode_set function and streamline the code-flow by moving the input and output mode setting in the sdvo encode together. Furthermore testing showed that the sdvo input timing needs the unadjusted dotclock, the sdvo chip will automatically compute the required pixel multiplier to get a dotclock above 100 MHz. Fix this up when converting a drm mode to an sdvo dtd. This regression was introduced in commit c74696b9c890074c1e1ee3d7496fc71eb3680ced Author: Pavel Roskin <proski@gnu.org> Date: Thu Sep 2 14:46:34 2010 -0400 i915: revert some checks added by commit 32aad86f particularly the following hunk: diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 093e914..62d22ae 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1122,11 +1123,9 @@ static void intel_sdvo_mode_set(struct drm_encoder *encoder, /* We have tried to get input timing in mode_fixup, and filled into adjusted_mode */ - if (intel_sdvo->is_tv || intel_sdvo->is_lvds) { - intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); + intel_sdvo_get_dtd_from_mode(&input_dtd, adjusted_mode); + if (intel_sdvo->is_tv || intel_sdvo->is_lvds) input_dtd.part2.sdvo_flags = intel_sdvo->sdvo_flags; - } else - intel_sdvo_get_dtd_from_mode(&input_dtd, mode); /* If it's a TV, we already set the output timing in mode_fixup. * Otherwise, the output timing is equal to the input timing. Due to questions raised in review, below a more elaborate analysis of the bug at hand: Sdvo seems to have two timings, one is the output timing which will be sent over whatever is connected on the other side of the sdvo chip (panel, hdmi screen, tv), the other is the input timing which will be generated by the gmch pipe. It looks like sdvo is expected to scale between the two. To make things slightly more complicated, we have a bunch of special cases: - For lvds panel we always use a fixed output timing, namely intel_sdvo->sdvo_lvds_fixed_mode, hence that special case. - Sdvo has an interface to generate a preferred input timing for a given output timing. This is the confusing thing that I've tried to clear up with the follow-on patches. - A special requirement is that the input pixel clock needs to be between 100MHz and 200MHz (likely to keep it within the electromechanical design range of PCIe), 270MHz on later gen4+. Lower pixel clocks are doubled/quadrupled. The thing this patch tries to fix is that the pipe needs to be explicitly instructed to double/quadruple the pixels and needs the correspondingly higher pixel clock, whereas the sdvo adaptor seems to do that itself and needs the unadjusted pixel clock. For the sdvo encode side we already set the pixel mutliplier with a different command (0x21). This patch tries to fix this mess by: - Keeping the output mode timing in the unadjusted plain mode, safe for the lvds case. - Storing the input timing in the adjusted_mode with the adjusted pixel clock. This way we don't need to frob around with the core crtc mode set code. - Fixing up the pixelclock when constructing the sdvo dtd timing struct. This is why the first hunk of the patch is an integral part of the series. - Dropping the is_tv special case because input_dtd is equivalent to adjusted_mode after these changes. Follow-up patches clear this up further (by simply ripping out intel_sdvo->input_dtd because it's not needed). v2: Extend commit message with an in-depth bug analysis. Reported-and-Tested-by: Bernard Blackham <b-linuxgit@largestprime.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48157 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: fix integer overflow in i915_gem_do_execbuffer()Xi Wang2012-04-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | On 32-bit systems, a large args->num_cliprects from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid allocation for execbuffer object list"). Signed-off-by: Xi Wang <xi.wang@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: fix integer overflow in i915_gem_execbuffer2()Xi Wang2012-04-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | On 32-bit systems, a large args->buffer_count from userspace via ioctl may overflow the allocation size, leading to out-of-bounds access. This vulnerability was introduced in commit 8408c282 ("drm/i915: First try a normal large kmalloc for the temporary exec buffers"). Signed-off-by: Xi Wang <xi.wang@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: fixup load-detect on enabled, but not active pipeDaniel Vetter2012-04-221-18/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somehow we have a fast-path that tries to avoid going through the load-detect code when the encode already has a crtc associated. But this fails horribly when the crtc is off. The load detect pipe itself manages this case well (and also does not forget to restore the dpms state), so just rip out this special case. The issue seems to go back all the way to the commit that originally introduced load-detection on the vga output: commit e4a5d54f924ea5ce2913d9d0687d034004816465 Author: Ma Ling <ling.ma@intel.com> Date: Tue May 26 11:31:00 2009 +0800 drm/i915: Add support for VGA load detection (pre-945). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43020 Reported-by: Jean Delvare <khali@linux-fr.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'exynos-drm-fixes' of ↵Dave Airlie2012-04-271-25/+5
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | git://git.infradead.org/users/kmpark/linux-2.6-samsung into drm-fixes From Inki Dae: this patch set fixes gem allocation and mapping issue between user space and physical memory region. * 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-2.6-samsung: drm/exynos: added missed vm area region mapping type. drm/exynos: fixed exynos_drm_gem_map_pages bug. drm/exynos: fixed duplicatd memory allocation bug.
| * drm/exynos: added missed vm area region mapping type.Inki Dae2012-04-231-0/+2
| | | | | | | | | | | | | | | | | | with this patch, if the memory region is physically non-continuous then VM_MIXEDMAP is set to vm->vm_flags otherwise VM_PFNMAP. we had missed this flag setting. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
| * drm/exynos: fixed exynos_drm_gem_map_pages bug.Inki Dae2012-04-231-13/+3
| | | | | | | | | | | | | | | | | | this patch fixes the problem that the physical memory region to be mapped to user space could be exceeded. if page fault address was placed at between buffer start and end then memory region to be mapped would be exceeded. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
| * drm/exynos: fixed duplicatd memory allocation bug.Inki Dae2012-04-231-12/+0
| | | | | | | | | | | | | | | | | | the gem was already allocated at gem allocation time but is allocated at page fault handler so this patch fixes the problem that gem was allocated one more time. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
* | kill mm argument of vm_munmap()Al Viro2012-04-211-2/+1
| | | | | | | | | | | | it's always current->mm Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | VM: add "vm_mmap()" helper functionLinus Torvalds2012-04-204-14/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This continues the theme started with vm_brk() and vm_munmap(): vm_mmap() does the same thing as do_mmap(), but additionally does the required VM locking. This uninlines (and rewrites it to be clearer) do_mmap(), which sadly duplicates it in mm/mmap.c and mm/nommu.c. But that way we don't have to export our internal do_mmap_pgoff() function. Some day we hopefully don't have to export do_mmap() either, if all modular users can become the simpler vm_mmap() instead. We're actually very close to that already, with the notable exception of the (broken) use in i810, and a couple of stragglers in binfmt_elf. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | VM: add "vm_munmap()" helper functionLinus Torvalds2012-04-201-3/+1
|/ | | | | | | Like the vm_brk() function, this is the same as "do_munmap()", except it does the VM locking for the caller. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* nouveau: Set special lane map for the right chipsetHenrik Rydberg2012-04-191-1/+1
| | | | | | | | | | | The refactoring of the nv50 logic, introduced in 8663bc7c, modified the test for the special lane map used on some Apple computers with Nvidia chipsets. The tested MBA3,1 would still boot, but resume from suspend stopped working. This patch restores the old test, which fixes the problem. Signed-off-by: Henrik Rydberg <rydberg@euromail.se> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: fix load detect on rn50 with hardcoded EDIDs.Dave Airlie2012-04-191-1/+1
| | | | | | | | | | | | | | When the force changes went in back in 3.3.0, we ended up returning disconnected in the !force case, and the connected in when forced, as it hit the hardcoded check. Fix it so all exits go via the hardcoded check and stop spurious modesets on platforms with hardcoded EDIDs. Reported-by: Evan McNabb (Red Hat) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Releasing FBs before releasing GEM objects during drm_releasePrathyush2012-04-191-3/+3
| | | | | | | | | | | | | During DRM release, all the FBs and gem objects are released. If a gem object is being used as a FB and set to a crtc, it must not be freed before releasing the framebuffer first. If FBs are released first, the crtc using the FB is disabled first so now the GEM object can be freed safely. The CRTC will be enabled again when the driver restores fbdev mode. Signed-off-by: Prathyush K <prathyush.k@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau/pm: don't read/write beyond end of stack bufferJim Meyering2012-04-191-0/+1
| | | | | | | | | | | | | NUL-terminate after strncpy. If the parameter "profile" has length 16 or more, then strncpy leaves "string" with no NUL terminator, so the following search for '\n' may read beyond the end of that 16-byte buffer. If it finds a newline there, then it will also write beyond the end of that stack buffer. Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drivers: gpu: drm: gma500: mdfld_dsi_output.h: Remove not unneeded include ↵Marcos Paulo de Souza2012-04-191-1/+0
| | | | | | | | | | | | | | | | of version.h The output of "make versioncheck" points a incorrect include of version.h in the drivers/gpu/drm/gma500/mdfld_dsi_output.h: drivers/gpu/drm/gma500/mdfld_dsi_output.h: 32 linux/version.h not needed. If we take a look in the file, we can agree to remove it. Cc: David Airlie <airlied@linux.ie> Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* radeon: fix r600/agp when vram is after AGP (v3)Jerome Glisse2012-04-192-4/+4
| | | | | | | | | | | | | If AGP is placed in the middle, the size_af is off-by-one, it results in VRAM being placed at 0x7fffffff instead of 0x8000000. v2: fix the vram_start setup. v3: also fix r7xx & newer ASIC Reported-by: russiane39 on #radeon Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: fix page_flip error handlingJoonyoung Shim2012-04-191-4/+6
| | | | | | | | | | Free event and restore event_space only when page_flip->flags has DRM_MODE_PAGE_FLIP_EVENT if page_flip() is failed. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.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-04-195-5/+26
|\ | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Do not set "Enable Panel Fitter" on SNB pageflips drm/i915: Hold mode_config lock whilst changing mode for lastclose() drm/i915: don't clobber the special upscaling lvds timings
| * drm/i915: Do not set "Enable Panel Fitter" on SNB pageflipsChris Wilson2012-04-181-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | Not only do the pageflip work without it at non-native modes (i.e. with the panel fitter enabled), it also causes normal (non-pageflipped) modesets to fail. Reported-by: Adam Jackson <ajax@redhat.com> Tested-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Wanted-by-for-fixes: Dave Airlie <airlied@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Hold mode_config lock whilst changing mode for lastclose()Chris Wilson2012-04-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Upon lastclose(), we switch back to the fbcon configuration. This requires taking the mode_config lock in order to serialise the change with output probing elsewhere. Reported-by: Oleksij Rempel <bug-track@fisher-privat.net> References: https://bugs.freedesktop.org/show_bug.cgi?id=48652 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: don't clobber the special upscaling lvds timingsDaniel Vetter2012-04-164-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This regression has been introduced in commit ca9bfa7eed20ea34e862804e62aae10eb159edbb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 14:49:20 2012 +0100 drm/i915: fixup interlaced vertical timings confusion, part 1 Unfortunately that commit failed to take into account that the lvds code does some special adjustements to the crtc timings for upscaling an centering. Fix this by explicitly computing crtc timings in the lvds mode fixup function and setting a special flag in mode->private_flags if the crtc timings have been adjusted. v2: Add a comment to explain the new mode driver private flag, suggested by Eugeni Dodonov. v3: Kill the confusing and now redundant set_crtcinfo call in intel_fixed_panel_mode, noticed by Chris Wilson. Reported-and-Tested-by: Hans de Bruin <jmdebruin@xmsnet.nl> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43071 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/radeon/kms: fix the regression of DVI connector checkTakashi Iwai2012-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The check of the encoder type in the commit [e00e8b5e: drm/radeon/kms: fix analog load detection on DVI-I connectors] is obviously wrong, and it's the culprit of the regression on my workstation with DVI-analog connection resulting in the blank output. Fixed the typo now. Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: <stable@vger.kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/usb: fix module license on drm/usb layer.Dave Airlie2012-04-191-1/+5
| | | | | | | | | | | | | | Allows this module to load correctly with certain debugging options on. Reported on irc by scientes Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/radeon/si: add missing radeon_bo_unreserve in si_rlc_init() v2Alex Deucher2012-04-161-3/+2
| | | | | | | | | | | | | | | | | | | | | | Forget to unreserve after pinning. This can lead to problems in soft reset and resume. v2: rework patch as per Michel's suggestion. 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>
* | drm/radeon: disable MSI on RV515Dave Airlie2012-04-161-0/+6
|/ | | | | | | | | My rv515 card is very flaky with msi enabled. Every so often it loses a rearm and never comes back, manually banging the rearm brings it back. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'exynos-drm-fixes' of ↵Dave Airlie2012-04-1212-185/+189
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.infradead.org/users/kmpark/linux-samsung into drm-intel-fixes * 'exynos-drm-fixes' of git://git.infradead.org/users/kmpark/linux-samsung: drm/exynos: fixed exynos broken ioctl drm/exynos: fix to pointer manager member of struct exynos_drm_subdrv drm/exynos: fix struct for operation callback functions to driver name drm/exynos: use define instead of default_win member in struct mixer_context drm/exynos: rename s/HDMI_OVERLAY_NUMBER/MIXER_WIN_NR drm/exynos: remove unused codes in hdmi and mixer drm/exynos: remove unnecessary type conversion of hdmi and mixer drm/exynos: add format list of plane drm/exynos: fixed duplicated page allocation bug. drm/exynos: fixed page align and code clean.
| * drm/exynos: fix to pointer manager member of struct exynos_drm_subdrvJoonyoung Shim2012-04-125-33/+46
| | | | | | | | | | | | | | | | | | | | | | The struct exynos_drm_manager has to exist for exynos drm sub driver using encoder and connector. If it isn't NULL to member of struct exynos_drm_subdrv, will create encoder and connector else will not. And the is_local member also doesn't need. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * drm/exynos: fix struct for operation callback functions to driver nameJoonyoung Shim2012-04-124-79/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | The mixer driver and hdmi driver have each operation callback functions and they is registered to hdmi common driver. Their struct names in hdmi common driver include display, manager and overlay. It confuses to appear whose operation and two driver cannot register same operation callback functions at the same time. Use their struct names to driver name. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * drm/exynos: use define instead of default_win member in struct mixer_contextJoonyoung Shim2012-04-121-4/+4
| | | | | | | | | | | | | | | | | | The default_win member in struct mixer_context isn't change its value after initialized to 0, so it's better using to define. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
| * drm/exynos: rename s/HDMI_OVERLAY_NUMBER/MIXER_WIN_NRJoonyoung Shim2012-04-121-5/+5
| | | | | | | | | | | | | | | | | | HDMI_OVERLAY_NUMBER is specific of mixer driver and be used "windows layer" term in exynos user manaual, so rename it. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
OpenPOWER on IntegriCloud