aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAge
...
| | * drm/i915: provide more error output when mode sets failJesse Barnes2011-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a mode set fails we may get a message from drm_crtc_helper if we're lucky, but it won't tell us anything about *why* we failed to set a mode. So add a few DRM_ERRORs for the cases that shouldn't happen so we can debug things more easily. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: add GPU max frequency control fileJesse Barnes2011-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mainly for use in debugging and benchmarking, this file allows the user to control the max frequency used by the GPU. Frequency may still vary based on workload (if the frequency is set to higher than the minimum) but won't go over the newly set value. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * i915: add Dell OptiPlex FX170 to intel_no_lvdsPieterjan Camerlynck2011-07-29
| | | | | | | | | | | | | | | | | | | | | The Dell OptiPlex FX170 claims to have LVDS, but doesn't. Signed-off-by: Pieterjan Camerlynck <pieterjan.camerlynck@gmail.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: Ignore GPU wedged errors while pinning scanout buffersKeith Packard2011-07-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Failing to pin a scanout buffer will most likely lead to a black screen, so if the GPU is wedged, then just let the pin happen and hope that things work out OK. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
| | * drm/i915/hdmi: send AVI info frames on ILK+ as wellJesse Barnes2011-07-29
| | | | | | | | | | | | | | | | | | | | | | | | On Ironlake and above, we have per-transcoder DIP registers, so use them for sending DIPs like AVI infoframes on ILK and above. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: fix CB tuning check for ILK+Jesse Barnes2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CB tuning is needed to handle potential process variations that might cause clock jitter for certain PLL settings. However, we were setting it incorrectly since we were using the wrong M value as a check (M1 when we needed to use the whole M value). Fix it up, making my HDMI attached display a little prettier (used to have occasional dots crawl across the display). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-28
| |\|
| | * drm/i915: Flush other plane register writesKeith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Writes to the plane control register are buffered in the chip until a write to the DSPADDR (pre-965) or DSPSURF (post-965) register occurs. This patch adds flushes in: intel_enable_plane gen6_init_clock_gating ivybridge_init_clock_gating Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: flush plane control changes on ILK+ as wellJesse Barnes2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After writing to the plane control reg we need to write to the surface reg to trigger the double buffered register latch. On previous chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg that triggers the double buffer latch. v2: write DSPADDR too to cover pre-965 chipsets v3: use flush_display_plane instead, that's what it's for v4: send the right patch Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Keith Packard <keithp@keithp.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: apply timing generator bug workaround on CPT and PPTJesse Barnes2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On CougarPoint and PantherPoint PCH chips, the timing generator may fail to start after DP training completes. This is due to a bug in the FDI autotraining detect logic (which will stall the timing generator and re-enable it once training completes), so disable it to avoid silent DP mode setting failures. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: Set crtc DPMS mode to ON in intel_crtc_mode_setKeith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | This corrects the DPMS mode tracking so that the DPMS code will actually turn the CRTC off the next time the screen saves. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| | * Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP"Keith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 885a50147f00a8a80108904bf58a18af357717f3. We actually *do* need to track DPMS state so that on hotplug, we don't retrain the link until DPMS is disabled. However, that code had avery small bug -- it wouldn't set the dpms_mode at mode set time, and so link retraining would not actually occur on monitor hotplug until the monitor had gone through a DPMS off/DPMS on cycle. Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Andrew Lutomirski <luto@mit.edu>
| | * drm/i915: DP_PIPE_ENABLED must check transcoder on CPTKeith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Display port pipe selection on CPT is not done with a bit in the output register, rather it is controlled by a couple of bits in the separate transcoder register which indicate which display port output is connected to the transcoder. This patch replaces the simplistic macro DP_PIPE_ENABLED with the rather more complicated function dp_pipe_enabled which checks the output register to see if that is enabled, and then goes on to either check the output register pipe selection bit (on non-CPT) or the transcoder DP selection bits (on CPT). Before this patch, any time the mode of pipe A was changed, any display port outputs on pipe B would get disabled as intel_disable_pch_ports would ensure that the mode setting operation could occur on pipe A without interference from other outputs connected to that pch port Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcdKeith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | Eliminates an open-coded read and also gains the retry behaviour of intel_dp_get_dpcd, which seems like a good idea. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcdKeith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | This describes the function better, allowing it to be used where the DPCD value is relevant. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: Use dp_detect_common in hotplug helper functionKeith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses the common dpcd reading routine, i915_dp_detect_common, instead of open-coding a call to intel_dp_aux_native_read. Besides reducing duplicated code, this also gains the read retries which may be necessary when a cable is first plugged back in and the link needs to be retrained. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: Fixup for 'Hold mode_config->mutex during hotplug'Keith Packard2011-07-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | drm_helper_hpd_irq_event queues another work proc to go and deliver the user-space event, and that function also wants to hold the config mutex, so we shouldn't hold the mutex across the drm_helper_hpd_irq_event call. Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-25
| |\|
| | * drm/i915/dp: Don't turn CPT DP ports on too earlyAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The docs say the port has to come on in training pattern 1; at this point, though, ->DP is in normal mode. The intent here is to wait until the port is in fact sending data, but that doesn't happen since we've broken the sequence the hardware expects, and the vblank wait will time out and kvetch in the log. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Explicitly disable symbol scrambling while trainingAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DP spec says training patterns 1 and 2 are to be sent non-scrambled, and the GPU docs claim that happens (or at least, there's no explicit scrambling control). But the sink may be confused if we don't explicitly tell it what we're doing, so play it safe. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/pch: Fix integer math bugs in panel fittingAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect. The old math would give you: scaled_width = 1600 * 768; /* 1228800 */ scaled_height = 1360 * 900; /* 1224000 */ if (scaled_width > scaled_height) { /* pillarbox, and true */ width = 1224000 / 768; /* int(1593.75) = 1593 */ x = (1600 - 1593 + 1) / 2; /* 4 */ y = 0; height = 768; } /* ... */ This is broken. The total width of scanout would then be 1593 + 4 + 4, or 1601, which is wider than the panel itself. The hardware very dutifully implements this, and you end up with a black 45° diagonal from the top-left corner to the bottom edge of the screen. It's a cool effect and all, but not what you wanted. Similar things happen for the letterbox case. The problem is that you have an integer number of pixels, which means it's usually impossible to upscale equally on both axes. 1360/768 is 1.7708, 1600/900 is 1.7777. Since we're constrained on the one axis, the other one wants to come out as an even number of pixels (the panel is almost certainly even on both axes, and the x/y offsets will be applied on both sides). In the math above, if 'width' comes out even, rounding down is correct; if it's odd, you'd rather round up. So just increment width/height in those cases. Tested on a Lenovo T500 (Ironlake). Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-By: Daniel Manrique <daniel.manrique@canonical.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-25
| |\|
| | * drm/i915: Hold mode_config->mutex during hotplug processingKeith Packard2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hotplug detection is a mode setting operation and must hold the struct_mutex or risk colliding with other mode setting operations. In particular, the display port hotplug function attempts to re-train the link if the monitor is supposed to be running when plugged back in. If that happens while mode setting is underway, the link will get scrambled, leaving it in an inconsistent state. This is a special case -- usually the driver mode setting entry points are covered by the upper level DRM code, but in this case the function is invoked as a work function not under the control of DRM. Signed-off-by: Keith Packard <keithp@keithp.com> Cc: stable@kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| | * drm/i915/dp: Explicitly request 8/10 channel codingAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's not clear what a sink would do if you wrote zero to this register - which I guess would mean "I don't support any channel encodings, good luck" - but let's not find out. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Retry DPCD fetch on G4X tooAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Better hexdump of DPCDAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | %hx alone prints 0 as "0", not "00". Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Read more DPCD registers on connection probeAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | For parity with radeon and nouveau, and also because I suspect we're going to need it to get format-conversion dongles right. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Move DPCD dump to common code instead of PCH-onlyAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | No reason not to see this on g4x, after all. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Zero the DPCD data before connection probeAdam Jackson2011-07-25
| | | | | | | | | | | | | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-22
| |\|
| | * drm/i915: load the LUT before pipe enable on ILK+Jesse Barnes2011-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per the specs and to address https://bugs.freedesktop.org/show_bug.cgi?id=36888. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: Initialize RCS ring status page address in intel_render_ring_init_driKeith Packard2011-07-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring->status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by: Keith Packard <keithp@keithp.com> Cc: stable@kernel.org
| * | drm/i915: Skip GPU wait for scanout pin while wedgedKeith Packard2011-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Failing to pin a scanout buffer will most likely lead to a black screen, so if the GPU is wedged, then just let the pin happen and hope that things work out OK. v2: Just ignore any error from i915_gem_object_wait_rendering, as suggested by Chris Wilson Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915: provide more error output when mode sets failJesse Barnes2011-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a mode set fails we may get a message from drm_crtc_helper if we're lucky, but it won't tell us anything about *why* we failed to set a mode. So add a few DRM_ERRORs for the cases that shouldn't happen so we can debug things more easily. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
* | | drm/radeon/kms: add thermal chip quirk for asus 9600xtAlex Deucher2011-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The board has an lm63 compatible thermal chip, but no thermal chip entry in the vbios tables. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39513 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/radeon: off by one in check_reg() functionsDan Carpenter2011-08-04
| | | | | | | | | | | | | | | | | | | | | | | | This off by one range check was copy and pasted a couple places. It's not really harmful, but we should fix it anyway. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/radeon/kms: fix version comment due to merge timingAlex Deucher2011-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | Compute cs support was actually added in 2.11.0 rather than 2.10.0, but the patch was written prior. Update comment to match. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | atomic: use <linux/atomic.h>Arun Sharma2011-07-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows us to move duplicated code in <asm/atomic.h> (atomic_inc_not_zero() for now) to <linux/atomic.h> Signed-off-by: Arun Sharma <asharma@fb.com> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | | Merge branch 'drm-core-next' of ↵Linus Torvalds2011-07-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 * 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (135 commits) drm/radeon/kms: fix DP training for DPEncoderService revision bigger than 1.1 drm/radeon/kms: add missing vddci setting on NI+ drm/radeon: Add a rmb() in IH processing drm/radeon: ATOM Endian fix for atombios_crtc_program_pll() drm/radeon: Fix the definition of RADEON_BUF_SWAP_32BIT drm/radeon: Do an MMIO read on interrupts when not uisng MSIs drm/radeon: Writeback endian fixes drm/radeon: Remove a bunch of useless _iomem casts drm/gem: add support for private objects DRM: clean up and document parsing of video= parameter DRM: Radeon: Fix section mismatch. drm: really make debug levels match in edid failure code drm/radeon/kms: fix i2c map for rv250/280 drm/nouveau/gr: disable fifo access and idle before suspend ctx unload drm/nouveau: pass flag to engine fini() method on suspend drm/nouveau: replace nv04_graph_fifo_access() use with direct reg bashing drm/nv40/gr: rewrite/split context takedown functions drm/nouveau: detect disabled device in irq handler and return IRQ_NONE drm/nouveau: ignore connector type when deciding digital/analog on DVI-I drm/nouveau: Add a quirk for Gigabyte NX86T ...
| * | | drm/radeon/kms: fix DP training for DPEncoderService revision bigger than 1.1Jerome Glisse2011-07-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DPEncoderService newer than 1.1 can't properly program the DP (display port) link training. When facing such version use the DIGxEncoderControl method instead. Fix DP link training on some R7XX. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon/kms: add missing vddci setting on NI+Alex Deucher2011-07-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Need to add vddci setting to pm init as well as resume. Fixes hangs on load on some boards. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38754 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: Add a rmb() in IH processingBenjamin Herrenschmidt2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should have a read memory barrier between reading the WPTR from memory and reading ring entries based on that value (ie, we need to ensure both loads are done in order by the CPU). It could be argued that the MMIO reads in r600_ack_irq() might be enough to get that barrier but I prefer keeping an explicit one just in case. [airlied: fix evergreen + r/w mixup] Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: ATOM Endian fix for atombios_crtc_program_pll()Benjamin Herrenschmidt2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v6 of the structure was programmed incorrectly: args.v6.ulCrtcPclkFreq.ulPixelClock = cpu_to_le32(clock / 10); ulPixelClock is a 24-bit bitfield. This statement would thus do a 32-bit swap of (clock / 10) and drop the top 8 bits which are ... the LSB. Not what we want. Instead use masks & shifts. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: Fix the definition of RADEON_BUF_SWAP_32BITBenjamin Herrenschmidt2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Note that this is duplicated under various other names such as R600_BUF_SWAP_32BIT etc...). At least now all the definitions agree. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: Do an MMIO read on interrupts when not uisng MSIsBenjamin Herrenschmidt2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When not using MSIs, there is no guarantee that DMA from the device has been fully flushed to point where it's visible to the CPU when taking an interrupt. To get this guarantee, we need to perform an MMIO read from the device, which will flush all outstanding DMAs from bridges between the device and the system. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: Writeback endian fixesBenjamin Herrenschmidt2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The writeback ring pointer and IH ring pointer are read using le32_to_cpu so we do not want the chip to byteswap them on big-endian. We still want to byteswap the ring itself and the IBs, so we don't touch that but we remove setting of the byteswap bits in CP_RB_RPTR_ADDR and IH_CNTL. In general, for things like that where we control all the accessors easily, we are better off doing the swap in SW rather than HW. Paradoxally, it does keep the code closer to x86 and avoid using poorly tested HW features. I also changed the use of RADEON_ to R600_ in a couple of cases to be more consistent with the surrounding code. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Michel Dänzer <michel@daenzer.net> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/radeon: Remove a bunch of useless _iomem castsBenjamin Herrenschmidt2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just defining rdev->rmmio properly in the first place should do the trick. In some cases, the cast were also complete dups as the original variable was already of the right type. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | drm/gem: add support for private objectsAlan Cox2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These small changes should allow GEM to be used with non shmem objects as well as shmem objects. In the GMA500 case it allows the base framebuffer to appear as a GEM object and thus acquire a handle and work with KMS. For i915 it ought to be trivial to get back the wasted memory but putting the system fb back into stolen RAM and in general I can imagine it allowing the use of GEM and thus KMS with all the older cards that have their framebuffer firmly placed in video RAM. Signed-off-by: Alan Cox <alan@linux.intel.com> Tested-by: Rob Clark <rob@ti.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | DRM: clean up and document parsing of video= parameterRolf Eike Beer2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | DRM: Radeon: Fix section mismatch.Ralf Baechle2011-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WARNING: drivers/gpu/drm/radeon/radeon.o(.text+0x5d1fc): Section mismatch in reference from the function radeon_get_clock_info() to the function .devinit.text:radeon_read_clocks_OF() The function radeon_get_clock_info() references the function __devinit radeon_read_clocks_OF(). This is often because radeon_get_clock_info lacks a __devinit annotation or the annotation of radeon_read_clocks_OF is wrong. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-07-22 23:45:19 -0400