[git pull] drm request 3
Fixes for default y + CONFIG_STAGING + CONFIG_DRM_NOUVEAU enabled. Dave. The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad: Linus Torvalds (1): Linux 2.6.33 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (34): drm/radeon/kms: add radeon i2c algo drm/radeon/kms: add support for hw i2c on r1xx-r5xx drm/radeon/kms: add workaround for rn50/rv100 servers drm/radeon/kms: add support for hardcoded edids in rom (v2) drm/radeon/kms: clean up some low-hanging magic numbers drm/radeon/kms: rework pll algo selection drm/radeon/kms: add pll quirk for toshiba laptop panel drm/radeon/kms/atom: clean up spread spectrum code drm/radeon/kms/atom: add a helper function to get the radeon connector priv drm/radeon/kms/r600: reduce gpu cache flushing drm/radeon/kms: consolidate crtc count in rdev drm/radeon/kms: add functions to get current pcie lanes drm/radeon/kms: pull power mode info from bios tables (v3) drm/radeon/kms: add a power state type based on power state flags drm/radeon/kms: add code to select power state drm/radeon/kms: use power states for dynamic reclocking drm/radeon/kms: dynclks fixes drm/radeon/kms: take the pm mutex when using hw i2c drm/radeon/kms: update atombios.h to latest upstream. drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx) drm/radeon/kms: fix prescale calculations drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE drm/radeon/kms/evergreen: fix multi-head drm/radeon/kms/evergreen: adapt to i2c changes drm/radeon/r600: fix warnings in CS checker drm/radeon/kms: add LVDS pll quirk for Dell Studio 15 drm/radeon/kms: remove HDP flushes from fence emit (v2) drm/radeon/kms: remove unused r600_gart_clear_page drm/radeon/rv740: fix backend setup drm/radeon: fixes for r6xx/r7xx gfx init drm/radeon/kms/evergreen: fix typo in cursor code drm/radeon/kms: update new pll algo drm/radeon/kms/atom: fix shr/shl ops drm/radeon: fix typo in Makefile Andy Shevchenko (1): drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi() Ben Skeggs (17): drm/nv50: switch to indirect push buffer controls drm/nouveau: remove PUSHBUF_CAL macro drm/nv50: make pushbuf dma object cover entire vm drm/nouveau: new gem pushbuf interface, bump to 0.0.16 drm/nouveau: allow retrieval of vbios image from debugfs drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table drm/nouveau: merge nvbios and nouveau_bios_info drm/nouveau: reorganise bios header, add dcb connector type enums drm/nouveau: parse dcb gpio/connector tables after encoders drm/nouveau: check for known dcb connector types drm/nouveau: construct a connector table for cards that lack a real one drm/nouveau: use dcb connector table for creating drm connectors drm/nv50: enable hpd on any connector we know the gpio line for drm/nouveau: use dcb connector types throughout the driver drm/nouveau: support version 0x20 displayport tables drm/nouveau: report unknown connector state if lid closed Chris Wilson (2): drm/i915: Replace open-coded eviction in i915_gem_idle() drm/i915: Record batch buffer following GPU error Daniel Vetter (11): drm/i915: overlay: nuke readback to flush wc caches drm/i915: overlay: drop superflous gpu flushes drm/i915: move a gtt flush to the correct place drm/i915: blow away userspace mappings before fence change drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code drm/i915: fixup active list locking in object_unbind drm/i915: extract fence stealing code drm/i915: ensure lru ordering of fence_list drm/i915: reuse i915_gpu_idle helper drm/i915: clean-up i915_gem_flush_gpu_write_domain drm/i915: check for multiple write domains in pin_and_relocate Dave Airlie (23): drm/radeon/kms: switch all KMS driver ioctls to unlocked. drm/radeon/kms: use udelay for short delays drm: switch all GEM/KMS ioctls to unlocked ioctl status. drm/kms: fix fb_changed = true else statement drm/radeon/kms: check for valid PCI bios and not OF rom drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page drm/radeon/kms: flush HDP cache on GART table updates. [rfc] drm/radeon/kms: pm debugging check for vbl. Merge remote branch 'korg/drm-core-next' into drm-next-stage Merge remote branch 'anholt/drm-intel-next' into drm-next-stage fb: for framebuffer handover don't exit the loop early. Merge remote branch 'korg/drm-radeon-testing' into drm-next
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Mon, Mar 1, 2010 at 7:18 PM, Michal Suchanek hramr...@centrum.cz wrote: On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. Now if a user runs fbset, I'm not sure what the right answer is, a) pick a head in advance via sysfs maybe and set it on that. b) try and set the mode on both heads cloned (what to do if there is no common mode is another issue). I would say it's time to support multihead with fbset properly. That is people would need new fbset which sees both (all) heads, and fbset can then choose the head itself (and people can make it do something different when they don't like the default). It should also support setting up rotation on each head. For old fbset setting something visible is probably good enough. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] agpgart: Reprobe VGA devices when a new GART device is added
On Sun, Feb 28, 2010 at 1:30 PM, Ben Hutchings b...@decadent.org.uk wrote: This addresses http://bugzilla.kernel.org/show_bug.cgi?id=15021. DRM drivers may fail to probe their devices when the associated AGP GART does not yet have a driver, so we reprobe unbound VGA devices when a GART device is added. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- This is intended to address the dependency problem highlighted in the above bug report. That specific bug can be fixed by adding a module dependency from i915 to intel_agp, but in general there is no fixed relationship betweem DRM and GART drivers. There is a narrow race between the check for a current driver binding and the call to device_reprobe(). This could be closed by adding a variant on device_attach() and device_reprobe() that is a no-op for bound devices. This isn't useful, generally there is no AGP binding, and most drivers if they can't find an AGP backend will still run fine without it. i.e. radeon, mga etc. Intel is a special case and I think we've already merged an explicit depend. Just build agp drivers into the kernel, I'm tempted to make them all non-modular. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vga_switcheroo: fix build on platforms with no ACPI
From: Dave Airlie airl...@ppcg5.localdomain
radeon was always including the atpx code unnecessarily, also core
switcheroo was including acpi headers.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/Makefile |3 ++-
drivers/gpu/drm/radeon/radeon_atpx_handler.c |1 -
drivers/gpu/drm/radeon/radeon_drv.h |6 ++
drivers/gpu/vga/vga_switcheroo.c |3 ---
include/linux/vga_switcheroo.h |1 -
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0a4d526..0adf49e 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -60,8 +60,9 @@ radeon-y += radeon_device.o radeon_kms.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit.o r600_blit_shaders.o \
r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
- evergreen.o radeon_atpx_handler.o
+ evergreen.o
radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
+radeon-$(CONFIG_VGA_SWITCHEROO) += radone_atpx_handler.o
obj-$(CONFIG_DRM_RADEON)+= radeon.o
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 0ae52f1..3f557c4 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -6,7 +6,6 @@
*
* ATPX support for both Intel/ATI
*/
-
#include linux/vga_switcheroo.h
#include acpi/acpi.h
#include acpi/acpi_bus.h
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index 4fe1646..ec55f2b 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -463,8 +463,14 @@ extern void r600_blit_swap(struct drm_device *dev,
int w, int h, int src_pitch, int dst_pitch, int cpp);
/* atpx handler */
+#if defined(CONFIG_VGA_SWITCHEROO)
void radeon_register_atpx_handler(void);
void radeon_unregister_atpx_handler(void);
+#else
+static inline void radeon_register_atpx_handler(void) {}
+static inline void radeon_unregister_atpx_handler(void) {}
+#endif
+
/* Flags for stats.boxes
*/
#define RADEON_BOX_DMA_IDLE 0x1
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index a3f587a..d6d1149 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -25,9 +25,6 @@
#include linux/debugfs.h
#include linux/fb.h
-#include acpi/acpi.h
-#include acpi/acpi_bus.h
-
#include linux/pci.h
#include linux/vga_switcheroo.h
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index 4b58ab1..ae9ab13 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -7,7 +7,6 @@
* vga_switcheroo.h - Support for laptop with dual GPU using one set of outputs
*/
-#include acpi/acpi.h
#include linux/fb.h
enum vga_switcheroo_state {
--
1.6.5.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm merge
It wouldn't be the drm unless it didn't build somewhere, two fixes on top of that tree: 8edb381d6705811b278527907a5ae2a9c4db8074 vga_switcheroo: fix build on platforms with no ACPI 55a5cb5d594c18b3147a2288b00ea359c1a38cf8 drm/radeon: Fix printf type warning in 64bit system. Dave.. On Mon, 1 Mar 2010, Dave Airlie wrote: Hi Linus, The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad: Linus Torvalds (1): Linux 2.6.33 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains a few patches outside the DRM/AGP trees, (a) Initial hybrid graphics support in drivers/gpu/vga/ - called the vga_switcheroo this is for dual-gpu laptops with a multiplexer on the outputs to swap LVDS/VGA between the two GPUs and the ability to powerdown the discrete GPU. This implements the ATI variant and starts the groundwork for the nvidia variant. It touches fb code also to add a call to move all consoles to the other fb device. (b) minor fb patch to fix an offb handover issue. Major drm highlights: core: switch to unlocked ioctls for KMS ioctls radeon-non-kms: fix ability to trash memory on r100/r200 fix problem trying to dynamically allocate 64k buffers at runtime radeon: AMD evergreen (R5xxx) modesetting support - no accel yet, unlocked KMS ioctls hw i2c engine support initial dynamic power management support r600 command stream checker + fixes. intel: Sandybridge GPU support unlocked KMS ioctls nouveau: new API - breaks userspace compatiblity - must upgrade libdrm_nouveau nv50 context program generator - gets rid of reliance on nvidia firmware *NOTE* in case you missed it: this will *break* your nvidia machine, its purely intentional. Rawhide should have the libdrm and driver updates necessary. Dave. Alex Deucher (33): drm/radeon/kms: add radeon i2c algo drm/radeon/kms: add support for hw i2c on r1xx-r5xx drm/radeon/kms: add workaround for rn50/rv100 servers drm/radeon/kms: add support for hardcoded edids in rom (v2) drm/radeon/kms: clean up some low-hanging magic numbers drm/radeon/kms: rework pll algo selection drm/radeon/kms: add pll quirk for toshiba laptop panel drm/radeon/kms/atom: clean up spread spectrum code drm/radeon/kms/atom: add a helper function to get the radeon connector priv drm/radeon/kms/r600: reduce gpu cache flushing drm/radeon/kms: consolidate crtc count in rdev drm/radeon/kms: add functions to get current pcie lanes drm/radeon/kms: pull power mode info from bios tables (v3) drm/radeon/kms: add a power state type based on power state flags drm/radeon/kms: add code to select power state drm/radeon/kms: use power states for dynamic reclocking drm/radeon/kms: dynclks fixes drm/radeon/kms: take the pm mutex when using hw i2c drm/radeon/kms: update atombios.h to latest upstream. drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx) drm/radeon/kms: fix prescale calculations drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE drm/radeon/kms/evergreen: fix multi-head drm/radeon/kms/evergreen: adapt to i2c changes drm/radeon/r600: fix warnings in CS checker drm/radeon/kms: add LVDS pll quirk for Dell Studio 15 drm/radeon/kms: remove HDP flushes from fence emit (v2) drm/radeon/kms: remove unused r600_gart_clear_page drm/radeon/rv740: fix backend setup drm/radeon: fixes for r6xx/r7xx gfx init drm/radeon/kms/evergreen: fix typo in cursor code drm/radeon/kms: update new pll algo drm/radeon/kms/atom: fix shr/shl ops Andy Shevchenko (1): drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi() Ben Skeggs (17): drm/nv50: switch to indirect push buffer controls drm/nouveau: remove PUSHBUF_CAL macro drm/nv50: make pushbuf dma object cover entire vm drm/nouveau: new gem pushbuf interface, bump to 0.0.16 drm/nouveau: allow retrieval of vbios image from debugfs drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table drm/nouveau: merge nvbios and nouveau_bios_info drm/nouveau: reorganise bios header, add dcb connector type enums drm/nouveau: parse dcb gpio/connector tables after encoders drm/nouveau: check for known dcb connector types drm/nouveau: construct a connector table for cards that lack a real one drm/nouveau: use dcb connector table for creating drm connectors drm/nv50: enable hpd on any connector we know the gpio line for drm/nouveau: use dcb connector types throughout the driver drm/nouveau: support version 0x20 displayport
[git pull] drm request 2
Same tree as yesterday with a warning + PPC build fix + fix for build on x86 after PPC (I think I just validated Ingo). The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad: Linus Torvalds (1): Linux 2.6.33 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (34): drm/radeon/kms: add radeon i2c algo drm/radeon/kms: add support for hw i2c on r1xx-r5xx drm/radeon/kms: add workaround for rn50/rv100 servers drm/radeon/kms: add support for hardcoded edids in rom (v2) drm/radeon/kms: clean up some low-hanging magic numbers drm/radeon/kms: rework pll algo selection drm/radeon/kms: add pll quirk for toshiba laptop panel drm/radeon/kms/atom: clean up spread spectrum code drm/radeon/kms/atom: add a helper function to get the radeon connector priv drm/radeon/kms/r600: reduce gpu cache flushing drm/radeon/kms: consolidate crtc count in rdev drm/radeon/kms: add functions to get current pcie lanes drm/radeon/kms: pull power mode info from bios tables (v3) drm/radeon/kms: add a power state type based on power state flags drm/radeon/kms: add code to select power state drm/radeon/kms: use power states for dynamic reclocking drm/radeon/kms: dynclks fixes drm/radeon/kms: take the pm mutex when using hw i2c drm/radeon/kms: update atombios.h to latest upstream. drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx) drm/radeon/kms: fix prescale calculations drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE drm/radeon/kms/evergreen: fix multi-head drm/radeon/kms/evergreen: adapt to i2c changes drm/radeon/r600: fix warnings in CS checker drm/radeon/kms: add LVDS pll quirk for Dell Studio 15 drm/radeon/kms: remove HDP flushes from fence emit (v2) drm/radeon/kms: remove unused r600_gart_clear_page drm/radeon/rv740: fix backend setup drm/radeon: fixes for r6xx/r7xx gfx init drm/radeon/kms/evergreen: fix typo in cursor code drm/radeon/kms: update new pll algo drm/radeon/kms/atom: fix shr/shl ops drm/radeon: fix typo in Makefile Andy Shevchenko (1): drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi() Ben Skeggs (17): drm/nv50: switch to indirect push buffer controls drm/nouveau: remove PUSHBUF_CAL macro drm/nv50: make pushbuf dma object cover entire vm drm/nouveau: new gem pushbuf interface, bump to 0.0.16 drm/nouveau: allow retrieval of vbios image from debugfs drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table drm/nouveau: merge nvbios and nouveau_bios_info drm/nouveau: reorganise bios header, add dcb connector type enums drm/nouveau: parse dcb gpio/connector tables after encoders drm/nouveau: check for known dcb connector types drm/nouveau: construct a connector table for cards that lack a real one drm/nouveau: use dcb connector table for creating drm connectors drm/nv50: enable hpd on any connector we know the gpio line for drm/nouveau: use dcb connector types throughout the driver drm/nouveau: support version 0x20 displayport tables drm/nouveau: report unknown connector state if lid closed Chris Wilson (2): drm/i915: Replace open-coded eviction in i915_gem_idle() drm/i915: Record batch buffer following GPU error Daniel Vetter (11): drm/i915: overlay: nuke readback to flush wc caches drm/i915: overlay: drop superflous gpu flushes drm/i915: move a gtt flush to the correct place drm/i915: blow away userspace mappings before fence change drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code drm/i915: fixup active list locking in object_unbind drm/i915: extract fence stealing code drm/i915: ensure lru ordering of fence_list drm/i915: reuse i915_gpu_idle helper drm/i915: clean-up i915_gem_flush_gpu_write_domain drm/i915: check for multiple write domains in pin_and_relocate Dave Airlie (21): drm/radeon/kms: switch all KMS driver ioctls to unlocked. drm/radeon/kms: use udelay for short delays drm: switch all GEM/KMS ioctls to unlocked ioctl status. drm/kms: fix fb_changed = true else statement drm/radeon/kms: check for valid PCI bios and not OF rom drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page drm/radeon/kms: flush HDP cache on GART table updates. [rfc] drm/radeon/kms: pm debugging check for vbl. Merge remote branch 'korg/drm-core-next' into drm-next-stage Merge remote branch 'anholt/drm-intel-next' into drm-next-stage fb: for framebuffer handover don't exit the loop early. Merge remote
Re: Unmappable VRAM patchset V4
On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse jgli...@redhat.com wrote: Updated patchset, to apply cleanly on top of TTM split no_wait argument. Compile tested for nouveau+vmwgfx, test in progress for radeon. So with the new change radeon won't wait for bo reserving other bo in fault path but will wait the GPU (hoping it doesn't lockup ;)) This should address concern about the wait/locking issue. Thomas any time for this yet? I'd like to pull this in obviously, but it would be nice to know if Jerome has addressed all concerns. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Convert DRM_INFO/DRM_ERROR to dev_info/dev_err
On Fri, Feb 26, 2010 at 4:56 AM, Jerome Glisse gli...@freedesktop.org wrote: Attached is conversion from DRM_INFO/DRM_ERROR to dev_info/dev_err to apply it copy all doconv* file into the radeon subfolder of the kernel run ./doconv.sh and then apply the 0001 patch which fix compilation after conversion (place where struct radeon_device is missing) then thing should compile I think it's worthwhile cleanup especialy on multi GPU configuration. Does this not remove the drm log levels? so we end up with everything in dmesg the whole time? that seems wrong, I'd rather pass a dev to DRM_ERROR/DRM_INFO or maybe defined DRM_DEV_ERROR, DRM_DEV_INFO. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection
On Mon, Mar 1, 2010 at 2:47 AM, Jerome Glisse jgli...@redhat.com wrote: On Sun, Feb 28, 2010 at 12:22:52PM +, Alan Swanson wrote: On Fri, 2010-02-26 at 15:49 +0100, Jerome Glisse wrote: This patch cleanup the fence code, it drops the timeout field of fence as the time to complete each IB is unpredictable and shouldn't be bound. The fence cleanup lead to GPU lockup detection improvement, this patch introduce a callback, allowing to do asic specific test for lockup detection. In this patch the CP is use as a first indicator of GPU lockup. If CP doesn't make progress during 1second we assume we are facing a GPU lockup. To avoid overhead of testing GPU lockup frequently due to fence taking time to be signaled we query the lockup callback every 100msec. There is plenty code comment explaining the design choise inside the code. Every 100msec? Is this running all the time? If so, that's not very good for CPU power saving to lower C-states in an idle system. We could at least use one of the round_jiffies. This run only when userspace call bo wait thus it only happen when userspace is waiting for something. Why not just test when the old timeout code used to test? every second or so? I'm not sure why with the old code instead of assuming a fence timeout implied a lockup you didn't just change it to test if it was a real lockup and continue waiting if the GPU was making progress. This seems simpler, though maybe the cleanups are worth it. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm merge
away userspace mappings before fence change drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code drm/i915: fixup active list locking in object_unbind drm/i915: extract fence stealing code drm/i915: ensure lru ordering of fence_list drm/i915: reuse i915_gpu_idle helper drm/i915: clean-up i915_gem_flush_gpu_write_domain drm/i915: check for multiple write domains in pin_and_relocate Dave Airlie (20): drm/radeon/kms: switch all KMS driver ioctls to unlocked. drm/radeon/kms: use udelay for short delays drm: switch all GEM/KMS ioctls to unlocked ioctl status. drm/kms: fix fb_changed = true else statement drm/radeon/kms: check for valid PCI bios and not OF rom drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page drm/radeon/kms: flush HDP cache on GART table updates. [rfc] drm/radeon/kms: pm debugging check for vbl. Merge remote branch 'korg/drm-core-next' into drm-next-stage Merge remote branch 'anholt/drm-intel-next' into drm-next-stage fb: for framebuffer handover don't exit the loop early. Merge remote branch 'korg/drm-radeon-testing' into drm-next-stage Merge remote branch 'korg/drm-core-next' into drm-next-stage Merge remote branch 'nouveau/for-airlied' into drm-next-stage Merge remote branch 'anholt/drm-intel-next' into drm-next-stage drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond Merge branch 'drm-radeon-testing' of /ssd/git/drm-radeon-next into drm-next-stage vga_switcheroo: initial implementation (v15) Merge branch 'gpu-switcher' of /ssd/git//linux-2.6 into drm-next-stage drm/radeon/kms: bump the KMS version number for square tiling support. Eric Anholt (13): drm/i915: Don't reserve compatibility fence regs in KMS mode. agp/intel: Add support for Sandybridge. drm/i915: Add initial bits for VGA modesetting bringup on Sandybridge. drm/i915: Set up fence registers on sandybridge. drm/i915: Fix sandybridge status page setup. agp/intel: Use a non-reserved value for the cache field of the PTEs. drm/i915: Disable the surface tile swizzling on Sandybridge. drm/i915: Correct locking in the modesetting failure path, fixing a BUG_ON. agp/intel: Add a new Sandybridge HB/IG PCI ID combo. drm/i915: Add a new mobile Sandybridge PCI ID. drm/i915: Disable the hangcheck reset on Sandybridge until we add support. drm/i915: Correct the Sandybridge chipset info structs. drm/i915: More s/IS_IRONLAKE/HAS_PCH_SPLIT for Sandybridge. Jerome Glisse (9): drm/radeon/kms: bogus cs recorder utilities drm/radeon/kms: r600/r700 command stream checker drm/radeon/kms: fix r600/r700 cs checker to avoid double kfree drm/radeon/kms: fix indirect buffer management V2 drm/radeon/kms: fix bo's fence association drm/radeon/kms: simplify memory controller setup V2 drm/radeon/kms: fix R3XX/R4XX memory controller initialization drm/radeon/kms: force pinning buffer into visible VRAM drm/radeon/kms: initialize set_surface_reg reg for rs600 asic Jesse Barnes (6): drm/i915: add dynamic performance control support for Ironlake drm/i915: fix drps disable so unload re-load works drm/i915: provide FBC status in debugfs drm/i915: provide self-refresh status in debugfs drm/i915: give up on 8xx lid status drm/i915: enable/disable LVDS port at DPMS time Li Peng (2): drm/i915: enable memory self refresh on 9xx drm/i915: Fix OGLC performance regression on 945 Luca Barbieri (3): drm: introduce drm_gem_object_[handle_]unreference_unlocked Use drm_gem_object_[handle_]unreference_unlocked where possible drm/nouveau: fix missing spin_unlock in failure path Maarten Maathuis (2): drm/ttm: handle OOM in ttm_tt_swapout drm/nouveau: protect channel create/destroy and irq handler with a spinlock Marcin Kościelnicki (2): drm/nv50: Implement ctxprog/state generation. drm/nouveau: Fix noaccel/nofbaccel option descriptions. Marcin Slusarz (3): drm/nouveau: fix pramdac_table range checking drm/nouveau: fix nouveau_i2c_find bounds checking drm/nouveau: fix i2ctable bounds checking Marek Olšák (1): drm/radeon/kms: add support for square microtiles on r3xx-r5xx Matt Turner (2): drm/nouveau: use ALIGN instead of open coding it drm/radeon: use ALIGN instead of open coding it Matthew Garrett (1): drm/i915: Deobfuscate the render p-state obfuscation Michel Dänzer (1): drm/radeon/kms: Test rdev-bios centrally in combios_get_table_offset(). Owain Ainsworth (1): drm/i915: reduce some of the duplication of tiling checking Pauli Nieminen (4): drm/radeon/kms: Create asic structure for r300 pcie cards. drm/radeon: Add asic hook for dma copy to r200 cards
Re: [PATCH 2/2] vga_switcheroo: initial implementation (v8)
Oh I should probably have dropped all the audio bits, I didn't even see this reply before I updated to v11. The r600 audio code is a bit of disaster area hopefully we can clean it up, like the timer was firing after the device was suspended. I'll repost with all that r600 audio ripped out and you can fix the mess. Don't mess with r600_audio_* there. You call if for all chipsets which is not needed and break nice SR layout, which is chipset specific. I guess you needed that because you didn't work on branch containing my patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=38fd2c6ff526e6a59edfa8e08f6f0724646784c4 (you commited it to drm-linus) This patch is now based on Linus tree, but yeah the original version predates your patches. -int radeon_audio = 1; +int radeon_audio = 0; Why?! What for we disable this feature by default?! If you see some reason for that, explain it to others please. I can change my mind, but for now I don't like this. It makes audio an option from just working-out-of-box. Oversights, the audio was just broken in the presence of suspend/resume when I wrote it. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vga_switcheroo: initial implementation (v11)
From: Dave Airlie airl...@linux.ie
Many new laptops now come with 2 gpus, one to be used for low power
modes and one for gaming/on-ac applications. These GPUs are typically
wired to the laptop panel and VGA ports via a multiplexer unit which
is controlled via ACPI methods.
4 combinations of systems typically exist - with 2 ACPI methods.
Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method
ATI/ATI - some ASUS - use ATPX ACPI Method
Intel/Nvidia - - use _DSM ACPI method
Nvidia/Nvidia - - use _DSM ACPI method.
TODO:
This patch adds support for the ATPX method and initial bits
for the _DSM methods that need to written by someone with
access to the hardware.
Add a proper non-debugfs interface - need to get some proper
testing first.
v2: add power up/down support for both devices
on W500 puts i915/radeon into D3 and cuts power to radeon.
v3: redo probing methods, no DMI list, drm devices call to
register with switcheroo, it tries to find an ATPX method on
any device and once there is two devices + ATPX it inits the
switcher.
v4: ATPX msg handling using buffers - should work on more machines
v5: rearchitect after more mjg59 discussion - move ATPX handling to
radeon driver.
v6: add file headers + initial nouveau bits (to be filled out).
v7: merge delayed switcher code.
v8: avoid suspend/resume of gpu that is off
v9: rearchitect - mjg59 is always right. - move all ATPX code to
radeon, should allow simpler DSM also proper ATRM handling
v10: add ATRM support for radeon BIOS, add mutex to lock vgasr_priv
v11: fix bug in resuming Intel for 2nd time.
mount debugfs
/sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected
+ 2 cards.
DIS - immediate change to discrete
IGD - immediate change to IGD
DDIS - delayed change to discrete
DIGD - delayed change to IGD
ON - turn on not in use
OFF - turn off not in use
Tested on W500 (Intel/ATI) and T500 (Intel/ATI)
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_dma.c | 33 ++
drivers/gpu/drm/i915/i915_drv.c |5 +-
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_fb.c |2 +
drivers/gpu/drm/nouveau/nouveau_acpi.c | 40 +++
drivers/gpu/drm/nouveau/nouveau_drv.c|4 +-
drivers/gpu/drm/nouveau/nouveau_drv.h|3 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c |2 +
drivers/gpu/drm/nouveau/nouveau_state.c | 27 ++
drivers/gpu/drm/radeon/Makefile |3 +-
drivers/gpu/drm/radeon/r600_audio.c |3 +
drivers/gpu/drm/radeon/radeon.h |8 +
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 258 +++
drivers/gpu/drm/radeon/radeon_bios.c | 45 +++-
drivers/gpu/drm/radeon/radeon_device.c | 42 +++
drivers/gpu/drm/radeon/radeon_drv.c |4 +-
drivers/gpu/drm/radeon/radeon_drv.h |3 +
drivers/gpu/drm/radeon/radeon_fb.c |3 +
drivers/gpu/drm/radeon/radeon_kms.c |3 +
drivers/gpu/vga/Kconfig | 11 +
drivers/gpu/vga/Makefile |1 +
drivers/gpu/vga/vga_switcheroo.c | 454 ++
drivers/video/console/fbcon.c| 18 +
include/linux/fb.h |2 +
include/linux/vga_switcheroo.h | 58
25 files changed, 1023 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/radeon_atpx_handler.c
create mode 100644 drivers/gpu/vga/vga_switcheroo.c
create mode 100644 include/linux/vga_switcheroo.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2307f98..e90ffe2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -35,6 +35,7 @@
#include i915_drv.h
#include i915_trace.h
#include linux/vgaarb.h
+#include linux/vga_switcheroo.h
/* Really want an OS-independent resettable timer. Would like to have
* this loop run for (eg) 3 sec, but have the timer reset every time
@@ -1199,6 +1200,30 @@ static unsigned int i915_vga_set_decode(void *cookie,
bool state)
return VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM;
}
+static void i915_switcheroo_set_state(struct pci_dev *pdev, enum
vga_switcheroo_state state)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
+ if (state == VGA_SWITCHEROO_ON) {
+ printk(KERN_ERR VGA switched i915 on\n);
+ i915_resume(dev);
+ } else {
+ printk(KERN_ERR VGA switched i915 off\n);
+ i915_suspend(dev, pmm);
+ }
+}
+
+static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ bool can_switch;
+
+ spin_lock(dev-count_lock);
+ can_switch = (dev-open_count == 0);
+ spin_unlock(dev-count_lock);
+ return can_switch
fb fix + laptop gpu switching support
The first patch is a trivial change to the fb handover code. The second adds initial support framework for laptops with GPU switching features, it has some changes to fb code, along with changes to dri drivers. I'm happy to deal with these patches via drm-2.6 for this merge window if nobody has any objections. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
fb + vga switcher patches (THE CORRECT ONES)
Oops send an old junk patch last time. Here we go again, fb patch + vga switcher patch affects fb as well I'm happy to put this all via drm-2.6 tree any objections? Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] vga_switcheroo: initial implementation (v8)
From: Dave Airlie airl...@linux.ie
Many new laptops now come with 2 gpus, one to be used for low power
modes and one for gaming/on-ac applications. These GPUs are typically
wired to the laptop panel and VGA ports via a multiplexer unit which
is controlled via ACPI methods.
4 combinations of systems typically exist - with 2 ACPI methods.
Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method
ATI/ATI - some ASUS - use ATPX ACPI Method
Intel/Nvidia - - use _DSM ACPI method
Nvidia/Nvidia - - use _DSM ACPI method.
TODO:
This patch adds support for the ATPX method and initial bits
for the _DSM methods that need to written by someone with
access to the hardware.
Add a proper non-debugfs interface - need to get some proper
testing first.
v2: add power up/down support for both devices
on W500 puts i915/radeon into D3 and cuts power to radeon.
v3: redo probing methods, no DMI list, drm devices call to
register with switcheroo, it tries to find an ATPX method on
any device and once there is two devices + ATPX it inits the
switcher.
v4: ATPX msg handling using buffers - should work on more machines
v5: rearchitect after more mjg59 discussion - move ATPX handling to
radeon driver.
v6: add file headers + initial nouveau bits (to be filled out).
v7: merge delayed switcher code.
v8: avoid suspend/resume of gpu that is off
mount debugfs
/sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected
+ 2 cards.
DIS - immediate change to discrete
IGD - immediate change to IGD
DDIS - delayed change to discrete
DIGD - delayed change to IGD
ON - turn on not in use
OFF - turn off not in use
Tested on W500 (Intel/ATI) and T500 (Intel/ATI)
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_dma.c | 32 ++
drivers/gpu/drm/i915/i915_drv.c |4 +-
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_fb.c |3 +
drivers/gpu/drm/nouveau/nouveau_acpi.c | 31 ++
drivers/gpu/drm/nouveau/nouveau_drv.c|4 +-
drivers/gpu/drm/nouveau/nouveau_drv.h|3 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c |3 +
drivers/gpu/drm/nouveau/nouveau_state.c | 27 ++
drivers/gpu/drm/radeon/Makefile |3 +-
drivers/gpu/drm/radeon/r600_audio.c |3 +
drivers/gpu/drm/radeon/radeon.h |4 +
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 132 +++
drivers/gpu/drm/radeon/radeon_bios.c | 10 +-
drivers/gpu/drm/radeon/radeon_device.c | 41 +++
drivers/gpu/drm/radeon/radeon_drv.c |4 +-
drivers/gpu/drm/radeon/radeon_drv.h |3 +
drivers/gpu/drm/radeon/radeon_fb.c |3 +
drivers/gpu/drm/radeon/radeon_kms.c |3 +
drivers/gpu/vga/Kconfig | 11 +
drivers/gpu/vga/Makefile |1 +
drivers/gpu/vga/vga_switcheroo.c | 472 ++
drivers/video/console/fbcon.c| 18 +
include/linux/fb.h |2 +
include/linux/vga_switcheroo.h | 65
25 files changed, 872 insertions(+), 12 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/radeon_atpx_handler.c
create mode 100644 drivers/gpu/vga/vga_switcheroo.c
create mode 100644 include/linux/vga_switcheroo.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2307f98..fb91532 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -35,6 +35,7 @@
#include i915_drv.h
#include i915_trace.h
#include linux/vgaarb.h
+#include linux/vga_switcheroo.h
/* Really want an OS-independent resettable timer. Would like to have
* this loop run for (eg) 3 sec, but have the timer reset every time
@@ -1199,6 +1200,30 @@ static unsigned int i915_vga_set_decode(void *cookie,
bool state)
return VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM;
}
+static void i915_switcheroo_set_state(struct pci_dev *pdev, enum
vga_switcheroo_state state)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
+ if (state == VGA_SWITCHEROO_ON) {
+ printk(KERN_ERR VGA switched i915 on\n);
+ i915_resume(dev);
+ } else {
+ printk(KERN_ERR VGA switched i915 off\n);
+ i915_suspend(dev, pmm);
+ }
+}
+
+static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ bool can_switch;
+
+ spin_lock(dev-count_lock);
+ can_switch = (dev-open_count == 0);
+ spin_unlock(dev-count_lock);
+ return can_switch;
+}
+
static int i915_load_modeset_init(struct drm_device *dev,
unsigned long prealloc_start,
unsigned long prealloc_size,
@@ -1260,6 +1285,12 @@ static int i915_load_modeset_init(struct
Re: [PATCH] drm/ttm: handle OOM in ttm_tt_swapout
On Sat, Feb 20, 2010 at 12:22 PM, Maarten Maathuis madman2...@gmail.com wrote:
- Without this change I get a general protection fault.
- Also use PTR_ERR where applicable.
I just want to make sure I understand, but really the only bit of this
patch that matters is:
@@ -556,9 +559,10 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file
*persistant_swap_storage)
if (unlikely(from_page == NULL))
continue;
to_page = read_mapping_page(swap_space, i, NULL);
- if (unlikely(to_page == NULL))
+ if (unlikely(IS_ERR(to_page))) {
^^ these two lines where we are testing for NULL but should be
checking for an error?
+ ret = PTR_ERR(to_page);
goto out_err;
-
+ }
If that is true and the rest is just nice cleanups then I'm okay with it,.
Reviewed-by: Dave Airlie airl...@redhat.com
I'll need Thomas's ack on this also.
Dave.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm staging driver fixes.
Just nouveau/vmwgfx changes, the nouveau ones fix nouveau to work
on a range of IGP chipsets, mostly seen as ION or in Apple laptops,
Without these changes there is a chance of memory corruption on the low
pages since the GPU tables are setup different to every other nvidia in
history.
Dave.
The following changes since commit 635f1a31292087a2e99568bf4451c10ee287adaa:
Dave Airlie (1):
drm/radeon: bump the UMS driver version number to indicate rv740 fix
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
Ben Skeggs (5):
drm/nv50: make nv50_mem_vm_{bind,unbind} operate only on vram
drm/nv50: more efficient clearing of gpu page table entries
drm/nv50: improve vram page table construction
drm/nv50: fix instmem binding on IGPs to point at stolen system memory
drm/nv50: fix vram ptes on IGPs to point at stolen system memory
Dave Airlie (1):
Merge remote branch 'nouveau/for-airlied' of ../drm-nouveau-next into
drm-linus
Francisco Jerez (1):
drm/nouveau: Fix up pre-nv17 analog load detection.
Thomas Hellstrom (1):
drm/vmwgfx: Fix queries if no dma buffer thrashing is occuring.
drivers/gpu/drm/nouveau/nouveau_drv.h |1 +
drivers/gpu/drm/nouveau/nouveau_mem.c | 113 ---
drivers/gpu/drm/nouveau/nv04_dac.c |6 ++-
drivers/gpu/drm/nouveau/nv50_instmem.c | 58 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 108 +-
5 files changed, 210 insertions(+), 76 deletions(-)
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm regression final fixes
Hi Linus hope you get this before release, if not stable life, the main fix is a major regression on AGP/no-pat systems where pages ended up in uncached, a further fix to the vgaarb fix, and a fix to make rv740 gpus just work for now (they have some tile/backend quirk that AMD haven't tracked down yet, so we'll do the proper fix in .34, this is a minimal workaround for now). Dave. The following changes since commit 6b15835282f9c6a023e2625455bfdb822bb9cc64: Dave Airlie (1): Merge branch 'for-airlied' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-linus are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (3): drm/radeon/kms/rs600: add connector quirk drm/radeon/kms: fix shared ddc detection drm/radeon/rv740: fix backend setup Francisco Jerez (1): drm/ttm: fix caching problem on non-PAT systems. Jerome Glisse (1): drm/radeon/kms: free fence IB if it wasn't emited at IB free time Kyle McMartin (1): vgaarb: fix target=default passing drivers/gpu/drm/radeon/r600_cp.c |9 ++--- drivers/gpu/drm/radeon/radeon_atombios.c |9 + drivers/gpu/drm/radeon/radeon_connectors.c |5 ++--- drivers/gpu/drm/radeon/radeon_ring.c |2 ++ drivers/gpu/drm/radeon/rv770.c |9 ++--- drivers/gpu/drm/ttm/ttm_tt.c | 18 +++--- drivers/gpu/vga/vgaarb.c |2 +- 7 files changed, 37 insertions(+), 17 deletions(-) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm regression final fixes
Hi Linus hope you get this before release, if not stable life, the main fix is a major regression on AGP/no-pat systems where pages ended up in uncached, a further fix to the vgaarb fix, and a fix to make rv740 gpus just work for now (they have some tile/backend quirk that AMD haven't tracked down yet, so we'll do the proper fix in .34, this is a minimal workaround for now). Alex suggested we bump UMS version number for the rv740 fix. 635f1a31292087a2e99568bf4451c10ee287adaa drm/radeon: bump the UMS driver version number to indicate rv740 fix This lets UMS userspace know the rv740 fix is in. For KMS we can consider the kernel release to be the v2.0.0 release so we don't need the bump there. Signed-off-by: Dave Airlie airl...@redhat.com Is on to of the tree now. Dave. Dave. The following changes since commit 6b15835282f9c6a023e2625455bfdb822bb9cc64: Dave Airlie (1): Merge branch 'for-airlied' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-linus are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Alex Deucher (3): drm/radeon/kms/rs600: add connector quirk drm/radeon/kms: fix shared ddc detection drm/radeon/rv740: fix backend setup Francisco Jerez (1): drm/ttm: fix caching problem on non-PAT systems. Jerome Glisse (1): drm/radeon/kms: free fence IB if it wasn't emited at IB free time Kyle McMartin (1): vgaarb: fix target=default passing drivers/gpu/drm/radeon/r600_cp.c | 9 ++--- drivers/gpu/drm/radeon/radeon_atombios.c | 9 + drivers/gpu/drm/radeon/radeon_connectors.c | 5 ++--- drivers/gpu/drm/radeon/radeon_ring.c | 2 ++ drivers/gpu/drm/radeon/rv770.c | 9 ++--- drivers/gpu/drm/ttm/ttm_tt.c | 18 +++--- drivers/gpu/vga/vgaarb.c | 2 +- 7 files changed, 37 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Rafał Miłecki zaj...@gmail.com: 2010/2/18 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This patch adds a check on avivo chips to see if we are in the VBL region for the active crtcs when we trigger the engine change. I appear to have glitches locally on pm transistion (not sure all fixes are in yet) and this at least seems to be correct here, maybe others can test on systems with no glitches. Because we are totally out of sync with VBLANK. If we correctly sync with it, it's just a lucky case. Please check my [PATCH] drm/radeon/kms: really wait for VBLANK in PM code and reply in thread where I posted it. Yeah I'll put this in when I've ran it here, it looks sane. It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some #ifdef RADEON_PM_DEBUG I don't think it'll be a major overhead, though doing it under a debug would be fine, but it would be nice to make it into a WARN_ON so we could track where this actually happens for ppl with something like kerneloops. Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie airl...@gmail.com napisał: It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Yeah, maybe that's right. While your idea of testing being in VBLANK is sane :) it could happen we start reclocking in VBLANK (first test will pass), we reclock out of VBLANK (not wanted, possible corruption), and we hit next VBLANK in second test. In such situation (machine) I'm sure we will hit false in test anyway (sooner or later) but maybe we could improve in anyway somehow? To make sure it's sill the same VBLANK? That could be possible, though if a reclock takes a full scanout to operate we've got other issues as it would never be possible by the sounds of it. The check on the way out could be toned down alright, its probably not as important, btw I've still got problems even with that other patch applied, I get reclocking in the middle of the frame, Reverting 73a6d3fc104827db574e4bd206a025299fef0bb1 drm/radeon/kms: use wait queue (events) for VBLANK sync still fixes it for me here. Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Create asic structure for r300 pcie cards.
On Fri, Feb 12, 2010 at 3:55 AM, Pauli Nieminen suok...@gmail.com wrote:
Setting global asic structure to point to different function
would cause problem in system where is multiple r300 cards
with different bus type.
This contains a typo which I fixed locally please make sure it
compiles before sending to me ;-)
hint: rv370_pci_set_gart_flush
Dave.
r300_asic_pcie is just copy from r300_asic with gart tlb
functions replaced with pcie versions.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
drivers/gpu/drm/radeon/radeon_asic.h | 38
drivers/gpu/drm/radeon/radeon_device.c | 9 +++
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 0971e7e..af18ffe 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -221,6 +221,44 @@ static struct radeon_asic r300_asic = {
.ioctl_wait_idle = NULL,
};
+
+static struct radeon_asic r300_asic_pcie = {
+ .init = r300_init,
+ .fini = r300_fini,
+ .suspend = r300_suspend,
+ .resume = r300_resume,
+ .vga_set_state = r100_vga_set_state,
+ .gpu_reset = r300_gpu_reset,
+ .gart_tlb_flush = rv370_pci_gart_tlb_flush,
+ .gart_set_page = rv370_pci_gart_set_page,
+ .cp_commit = r100_cp_commit,
+ .ring_start = r300_ring_start,
+ .ring_test = r100_ring_test,
+ .ring_ib_execute = r100_ring_ib_execute,
+ .irq_set = r100_irq_set,
+ .irq_process = r100_irq_process,
+ .get_vblank_counter = r100_get_vblank_counter,
+ .fence_ring_emit = r300_fence_ring_emit,
+ .cs_parse = r300_cs_parse,
+ .copy_blit = r100_copy_blit,
+ .copy_dma = r200_copy_dma,
+ .copy = r100_copy_blit,
+ .get_engine_clock = radeon_legacy_get_engine_clock,
+ .set_engine_clock = radeon_legacy_set_engine_clock,
+ .get_memory_clock = radeon_legacy_get_memory_clock,
+ .set_memory_clock = NULL,
+ .set_pcie_lanes = rv370_set_pcie_lanes,
+ .set_clock_gating = radeon_legacy_set_clock_gating,
+ .set_surface_reg = r100_set_surface_reg,
+ .clear_surface_reg = r100_clear_surface_reg,
+ .bandwidth_update = r100_bandwidth_update,
+ .hpd_init = r100_hpd_init,
+ .hpd_fini = r100_hpd_fini,
+ .hpd_sense = r100_hpd_sense,
+ .hpd_set_polarity = r100_hpd_set_polarity,
+ .ioctl_wait_idle = NULL,
+};
+
/*
* r420,r423,rv410
*/
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index b5c9d38..767aed8 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -341,11 +341,10 @@ int radeon_asic_init(struct radeon_device *rdev)
case CHIP_R350:
case CHIP_RV350:
case CHIP_RV380:
- rdev-asic = r300_asic;
- if (rdev-flags RADEON_IS_PCIE) {
- rdev-asic-gart_tlb_flush =
rv370_pcie_gart_tlb_flush;
- rdev-asic-gart_set_page = rv370_pcie_gart_set_page;
- }
+ if (rdev-flags RADEON_IS_PCIE)
+ rdev-asic = r300_asic_pcie;
+ else
+ rdev-asic = r300_asic;
break;
case CHIP_R420:
case CHIP_R423:
--
1.6.3.3
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Download Intelreg; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: implement reading PCIE lanes on R600+
2010/2/18 Rafał Miłecki zaj...@gmail.com: Ported from DDX The PCIE regs on r600 are the same offsets at the ones on rv370 from what I can see probably don't need to add a new PCIE_P struct at all I think the rv370 functions should work. Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, one edid fix from X.org parser, some more drm regression fixes, one 33 second pause at boot bug solved, two nouveau issues, one vmwgfx staging fix to use proper mechanism to do framebuffer handover, For 2.6.34 we've lined up a command stream checker for r600, however it already found two issues and we've backported the patches from Jerome to solve some r600 lockups we've been seeing a lot off in the field but funnily not on any of my or Jerome's systems. Dave. The following changes since commit e803e8b2628f3e9a42f45c5b7bb1f9821b08352c: Dave Airlie (1): drm/radeon/kms: make sure retry count increases. are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Adam Jackson (1): drm/edid: Fix interlaced detailed timings to be frame size, not field. Ben Skeggs (1): drm/nouveau: use mutex for vbios lock Dave Airlie (2): drm/radeon/kms: use udelay for short delays Merge branch 'for-airlied' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-linus Francisco Jerez (1): drm/nouveau: Force TV encoder DPMS reinit after resume. Jerome Glisse (2): drm/radeon/kms: fix indirect buffer management V2 drm/radeon/kms: fix bo's fence association Thomas Hellstrom (1): drm/vmwgfx: Use fb handover mechanism instead of stealth mode. drivers/gpu/drm/drm_edid.c | 47 ++- drivers/gpu/drm/nouveau/nouveau_bios.c |7 +- drivers/gpu/drm/nouveau/nouveau_bios.h |2 +- drivers/gpu/drm/nouveau/nv17_tv.c |2 + drivers/gpu/drm/radeon/atom.c |2 +- drivers/gpu/drm/radeon/r600_blit_kms.c |3 - drivers/gpu/drm/radeon/radeon.h|9 ++- drivers/gpu/drm/radeon/radeon_cs.c | 10 +-- drivers/gpu/drm/radeon/radeon_object.c | 36 +-- drivers/gpu/drm/radeon/radeon_object.h |4 +- drivers/gpu/drm/radeon/radeon_ring.c | 105 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 49 +-- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |3 + 13 files changed, 137 insertions(+), 142 deletions(-) -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
From: Dave Airlie airl...@redhat.com
This patch adds a check on avivo chips to see if we are in the VBL
region for the active crtcs when we trigger the engine change.
I appear to have glitches locally on pm transistion (not sure all
fixes are in yet) and this at least seems to be correct here,
maybe others can test on systems with no glitches.
---
drivers/gpu/drm/radeon/avivod.h|2 ++
drivers/gpu/drm/radeon/radeon_pm.c | 27 +++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/avivod.h b/drivers/gpu/drm/radeon/avivod.h
index d4e6e6e..3c391e7 100644
--- a/drivers/gpu/drm/radeon/avivod.h
+++ b/drivers/gpu/drm/radeon/avivod.h
@@ -30,11 +30,13 @@
#defineD1CRTC_CONTROL 0x6080
#defineCRTC_EN (1 0)
+#defineD1CRTC_STATUS 0x609c
#defineD1CRTC_UPDATE_LOCK 0x60E8
#defineD1GRPH_PRIMARY_SURFACE_ADDRESS 0x6110
#defineD1GRPH_SECONDARY_SURFACE_ADDRESS0x6118
#defineD2CRTC_CONTROL 0x6880
+#defineD2CRTC_STATUS 0x689c
#defineD2CRTC_UPDATE_LOCK 0x68E8
#defineD2GRPH_PRIMARY_SURFACE_ADDRESS 0x6910
#defineD2GRPH_SECONDARY_SURFACE_ADDRESS0x6918
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index b138618..f46d574 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -22,6 +22,7 @@
*/
#include drmP.h
#include radeon.h
+#include avivod.h
#define RADEON_IDLE_LOOP_MS 100
#define RADEON_RECLOCK_DELAY_MS 200
@@ -293,6 +294,28 @@ void radeon_pm_compute_clocks(struct radeon_device *rdev)
mutex_unlock(rdev-pm.mutex);
}
+static bool radeon_pm_debug_check_in_vbl(struct radeon_device *rdev, bool
finish)
+{
+ u32 stat_crtc1 = 0, stat_crtc2 = 0;
+ bool in_vbl = true;
+
+ if (ASIC_IS_AVIVO(rdev)) {
+ if (rdev-pm.active_crtcs (1 0)) {
+ stat_crtc1 = RREG32(D1CRTC_STATUS);
+ if (!(stat_crtc1 1))
+ in_vbl = false;
+ }
+ if (rdev-pm.active_crtcs (1 1)) {
+ stat_crtc2 = RREG32(D2CRTC_STATUS);
+ if (!(stat_crtc2 1))
+ in_vbl = false;
+ }
+ }
+ if (in_vbl == false)
+ DRM_INFO(not in vbl for pm change %08x %08x at %s\n,
stat_crtc1,
+stat_crtc2, finish ? exit : entry);
+ return in_vbl;
+}
static void radeon_pm_set_clocks_locked(struct radeon_device *rdev)
{
/*radeon_fence_wait_last(rdev);*/
@@ -309,7 +332,11 @@ static void radeon_pm_set_clocks_locked(struct
radeon_device *rdev)
DRM_ERROR(%s: PM_ACTION_NONE\n, __func__);
break;
}
+
+ /* check if we are in vblank */
+ radeon_pm_debug_check_in_vbl(rdev, false);
radeon_set_power_state(rdev);
+ radeon_pm_debug_check_in_vbl(rdev, true);
rdev-pm.planned_action = PM_ACTION_NONE;
}
--
1.6.6
--
Download Intelreg; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vesafb handover
On Mon, Feb 15, 2010 at 8:04 PM, Thomas Hellstrom tho...@shipmail.org wrote: Hi, Dave! Could you point me to what's needed in drm fb setup to utilize the vesafb handover mechanism? In intel_fb.c /* setup aperture base/size for vesafb takeover */ info-aperture_base = dev-mode_config.fb_base; if (IS_I9XX(dev)) info-aperture_size = pci_resource_len(dev-pdev, 2); else info-aperture_size = pci_resource_len(dev-pdev, 0); The fb code then compare the aperture base/size against where vesafb has setup its linear frame buffer and removes it on conflict. Dave. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Two ttm regression fixes from Thomas, and one alpha unaligned issue in the
atom parser for radeon KMS.
The following changes since commit 724e6d3fe8003c3f60bf404bf22e4e331327c596:
Linus Torvalds (1):
Linux 2.6.33-rc8
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
Matt Turner (1):
drm/radeon/kms/atom: use get_unaligned_le32() for ctx-ps
Thomas Hellstrom (2):
drm: Fix a bug in the range manager.
drm/ttm: Fix a bug occuring when validating a buffer object in a range.
drivers/gpu/drm/drm_mm.c |3 ++-
drivers/gpu/drm/radeon/atom.c |5 -
drivers/gpu/drm/ttm/ttm_bo.c |6 ++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index cdec329..2ac074c 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -405,7 +405,8 @@ struct drm_mm_node *drm_mm_search_free_in_range(const
struct drm_mm *mm,
wasted += alignment - tmp;
}
- if (entry-size = size + wasted) {
+ if (entry-size = size + wasted
+ (entry-start + wasted + size) = end) {
if (!best_match)
return entry;
if (entry-size best_size) {
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index e3b4456..2a3df55 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -24,6 +24,7 @@
#include linux/module.h
#include linux/sched.h
+#include asm/unaligned.h
#define ATOM_DEBUG
@@ -212,7 +213,9 @@ static uint32_t atom_get_src_int(atom_exec_context *ctx,
uint8_t attr,
case ATOM_ARG_PS:
idx = U8(*ptr);
(*ptr)++;
- val = le32_to_cpu(ctx-ps[idx]);
+ /* get_unaligned_le32 avoids unaligned accesses from atombios
+* tables, noticed on a DEC Alpha. */
+ val = get_unaligned_le32((u32 *)ctx-ps[idx]);
if (print)
DEBUG(PS[0x%02X,0x%04X], idx, val);
break;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1a3e909..c7320ce 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1020,6 +1020,12 @@ static int ttm_bo_mem_compat(struct ttm_placement
*placement,
struct ttm_mem_reg *mem)
{
int i;
+ struct drm_mm_node *node = mem-mm_node;
+
+ if (node placement-lpfn != 0
+ (node-start placement-fpfn ||
+node-start + node-size placement-lpfn))
+ return -1;
for (i = 0; i placement-num_placement; i++) {
if ((placement-placement[i] mem-placement
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm fixes
Two ttm regression fixes from Thomas, and one alpha unaligned issue in the atom parser for radeon KMS. And as usual I read my TODO list after I send the push req out. One more commit on top of this tree now just a fix to the DP retry logic: e803e8b2628f3e9a42f45c5b7bb1f9821b08352c drm/radeon/kms: make sure retry count increases. In testing I've never seen it go past 1 retry anyways but better safe than sorry. Reported by Droste on irc. Signed-off-by: Dave Airlie airl...@redhat.com Dave. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm
Hi Linus,
vmware + nouveau staging fixes are the bulk of this.
one vgaarb patch that I found in mmtom but can't find in my inbox for some
reason ah well better late than never.
radeon: fix the Kconfig msg to be more explicit, and some oops crashers
in the presence of bad bioses, along with a get rid of stupid white
borders on fbcon patch.
The following changes since commit e28cab42f384745c8a947a9ccd51e4aae52f5d51:
Linus Torvalds (1):
Merge branch 'i2c-for-linus' of
git://git.kernel.org/.../jdelvare/staging
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
Andy Getzendanner (1):
vgaarb: fix incorrect dereference of userspace pointer.
Ben Skeggs (5):
drm/nouveau: fix non-vram notifier blocks
drm/nv40: make INIT_COMPUTE_MEM a NOP, just like nv50
drm/nouveau: make dp auxch xfer len check for reads only
drm/nv50: prevent multiple init tables being parsed at the same time
drm/nv50: disregard dac outputs in nv50_sor_dpms()
Dave Airlie (7):
drm/radeon/kms: change Kconfig text to reflect the new option.
drm/radeon/kms: don't crash if no DDC bus on VGA/DVI connector.
drm/radeon/kms: add quirk for VGA without DDC on rv730 XFX card.
drm/radeon/kms: fix screen clearing before fbcon.
Merge remote branch 'nouveau/for-airlied' of nouveau-2.6
drm/radeon/kms: retry auxch on 0x20 timeout value.
Merge branch 'drm-radeon-linus' of ../drm-next
Francisco Jerez (1):
drm/nouveau: Fixup semaphores on pre-nv50 cards.
Jakob Bornecrantz (2):
drm/vmwgfx: Report propper framebuffer_{max|min}_{width|height}
drm/vmwgfx: Drop scanout flag compat and add execbuf ioctl parameter
members. Bumps major.
Julia Lawall (1):
drivers/gpu/drm/nouveau/nouveau_grctx.c: correct NULL test
Luca Barbieri (1):
drm/nouveau: call ttm_bo_wait with the bo lock held to prevent hang
Maarten Maathuis (4):
drm/nv50: align size of buffer object to the right boundaries.
drm/nv50: avoid unloading pgraph context when ctxprog is running
drm/nv50: delete ramfc object after disabling fifo, not before
drm/nv50: make the pgraph irq handler loop like the pre-nv50 version
Marcin Kościelnicki (4):
drm/nouveau: Add module options to disable acceleration.
drm/nouveau: Add getparam to get available PGRAPH units.
drm/nouveau: Fix fbcon on mixed pre-NV50 + NV50 multicard.
drm/nouveau: Add proper vgaarb support.
Marcin Slusarz (1):
drm/nouveau: move dereferences after null checks
Matthew Garrett (1):
nouveau: fix state detection with switchable graphics
Pauli Nieminen (1):
drm/radeon: Skip dma copy test in benchmark if card doesn't have dma
engine.
Rafał Miłecki (1):
drm/radeon/kms: suspend and resume audio stuff
Thomas Hellstrom (2):
drm/vmwgfx: Update the user-space interface.
drm/vmwgfx: Fix a circular locking dependency bug.
drivers/gpu/drm/nouveau/nouveau_acpi.c | 12 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 19 ++--
drivers/gpu/drm/nouveau/nouveau_bios.h |2 +
drivers/gpu/drm/nouveau/nouveau_bo.c| 10 +-
drivers/gpu/drm/nouveau/nouveau_channel.c |7 +-
drivers/gpu/drm/nouveau/nouveau_connector.c |7 +-
drivers/gpu/drm/nouveau/nouveau_dp.c| 10 +-
drivers/gpu/drm/nouveau/nouveau_drv.c | 10 ++-
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 40 +++-
drivers/gpu/drm/nouveau/nouveau_fbcon.h |6 +
drivers/gpu/drm/nouveau/nouveau_gem.c |2 +
drivers/gpu/drm/nouveau/nouveau_grctx.c |4 +-
drivers/gpu/drm/nouveau/nouveau_irq.c | 155 ---
drivers/gpu/drm/nouveau/nouveau_notifier.c | 13 ++-
drivers/gpu/drm/nouveau/nouveau_object.c|3 +-
drivers/gpu/drm/nouveau/nouveau_reg.h |1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c |7 +-
drivers/gpu/drm/nouveau/nouveau_state.c | 49 +++--
drivers/gpu/drm/nouveau/nv04_fbcon.c|9 +-
drivers/gpu/drm/nouveau/nv50_crtc.c | 11 ++-
drivers/gpu/drm/nouveau/nv50_fbcon.c|9 +-
drivers/gpu/drm/nouveau/nv50_fifo.c |9 +-
drivers/gpu/drm/nouveau/nv50_graph.c| 10 ++-
drivers/gpu/drm/nouveau/nv50_sor.c |1 +
drivers/gpu/drm/radeon/Kconfig | 12 ++-
drivers/gpu/drm/radeon/atombios_dp.c| 10 ++-
drivers/gpu/drm/radeon/r600.c |8 ++
drivers/gpu/drm/radeon/r600_audio.c |3 +-
drivers/gpu/drm/radeon/radeon_atombios.c|9 ++
drivers/gpu/drm/radeon/radeon_benchmark.c | 55 ++
drivers/gpu/drm/radeon/radeon_connectors.c | 20 ++--
drivers/gpu/drm/radeon/radeon_display.c | 11 ++-
drivers/gpu/drm/radeon/radeon_fb.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 11 +-
drivers/gpu/drm
Re: Radeon hwmon driver
On Mon, Feb 8, 2010 at 6:48 PM, Domenico Andreoli ca...@dandreoli.com wrote: [i'm subscribed to this list, thanks] On Mon, Feb 08, 2010 at 01:32:33AM -0500, Alex Deucher wrote: On Sun, Feb 7, 2010 at 6:12 PM, Domenico Andreoli ca...@dandreoli.com wrote: I'd like to write a hwmon driver for the Radeon GPUs. I made a quick search in the M56 and M76 register references on AMD's site but didn't find anything. I then wrote to gpudriverdevsupp...@amd.com and now I'm waiting for some response. In the meanwhile, has anybody of you seen anything related to this task while working at the graphic drivers? The thermal and fan chips are generally 3rd party chips connected via i2c. I think most of the chips used have hwmon drivers already. You can look up the chip and i2c address in the power tables in the bios. See the PowerPlayInfo table definitions in atombios.h. I've started work on cleaning up the radeon i2c buses for external use in the drm-radeon-testing branch of Dave's drm tree: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary how this tree is managed? reset or rebased at every release? That branch isn't managed that well, its pretty much rebased when I want, its just all the patches that are in flux for 2.6.34. Though nearly everything in there will end up in a form close to that in 2.6.34. I may squash some commits together to make bisection useful. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: add quirk for VGA without DDC on rv730 XFX card.
From: Dave Airlie airl...@redhat.com
Reported on irc by nirbheek.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index fa82ca7..2dcda61 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -287,6 +287,15 @@ static bool radeon_atom_apply_quirks(struct drm_device
*dev,
*connector_type = DRM_MODE_CONNECTOR_DVID;
}
+ /* XFX Pine Group device rv730 reports no VGA DDC lines
+* even though they are wired up to record 0x93
+*/
+ if ((dev-pdev-device == 0x9498)
+ (dev-pdev-subsystem_vendor == 0x1682)
+ (dev-pdev-subsystem_device == 0x2452)) {
+ struct radeon_device *rdev = dev-dev_private;
+ *i2c_bus = radeon_lookup_i2c_gpio(rdev, 0x93);
+ }
return true;
}
--
1.6.5.2
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: don't crash if no DDC bus on VGA/DVI connector.
From: Dave Airlie airl...@redhat.com
This is strange - like really really strange, twilight zone of strange.
VGA ports have DDC buses, but sometimes for some reasons the BIOS
says we don't and we oops - AMD mentioned bios bugs so we'll have
to add quirks.
reported on irc by nirbheek and
https://bugzilla.redhat.com/show_bug.cgi?id=554323
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_connectors.c | 20
drivers/gpu/drm/radeon/radeon_display.c| 11 ++-
2 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 2d8e5a7..2381885 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -580,16 +580,18 @@ static enum drm_connector_status radeon_vga_detect(struct
drm_connector *connect
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
struct drm_encoder *encoder;
struct drm_encoder_helper_funcs *encoder_funcs;
- bool dret;
+ bool dret = false;
enum drm_connector_status ret = connector_status_disconnected;
encoder = radeon_best_single_encoder(connector);
if (!encoder)
ret = connector_status_disconnected;
- radeon_i2c_do_lock(radeon_connector-ddc_bus, 1);
- dret = radeon_ddc_probe(radeon_connector);
- radeon_i2c_do_lock(radeon_connector-ddc_bus, 0);
+ if (radeon_connector-ddc_bus) {
+ radeon_i2c_do_lock(radeon_connector-ddc_bus, 1);
+ dret = radeon_ddc_probe(radeon_connector);
+ radeon_i2c_do_lock(radeon_connector-ddc_bus, 0);
+ }
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
@@ -740,11 +742,13 @@ static enum drm_connector_status radeon_dvi_detect(struct
drm_connector *connect
struct drm_mode_object *obj;
int i;
enum drm_connector_status ret = connector_status_disconnected;
- bool dret;
+ bool dret = false;
- radeon_i2c_do_lock(radeon_connector-ddc_bus, 1);
- dret = radeon_ddc_probe(radeon_connector);
- radeon_i2c_do_lock(radeon_connector-ddc_bus, 0);
+ if (radeon_connector-ddc_bus) {
+ radeon_i2c_do_lock(radeon_connector-ddc_bus, 1);
+ dret = radeon_ddc_probe(radeon_connector);
+ radeon_i2c_do_lock(radeon_connector-ddc_bus, 0);
+ }
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 6a92f99..7e17a36 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -278,7 +278,7 @@ static void radeon_print_display_setup(struct drm_device
*dev)
DRM_INFO( %s\n, connector_names[connector-connector_type]);
if (radeon_connector-hpd.hpd != RADEON_HPD_NONE)
DRM_INFO( %s\n,
hpd_names[radeon_connector-hpd.hpd]);
- if (radeon_connector-ddc_bus)
+ if (radeon_connector-ddc_bus) {
DRM_INFO( DDC: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x
0x%x\n,
radeon_connector-ddc_bus-rec.mask_clk_reg,
radeon_connector-ddc_bus-rec.mask_data_reg,
@@ -288,6 +288,15 @@ static void radeon_print_display_setup(struct drm_device
*dev)
radeon_connector-ddc_bus-rec.en_data_reg,
radeon_connector-ddc_bus-rec.y_clk_reg,
radeon_connector-ddc_bus-rec.y_data_reg);
+ } else {
+ if (connector-connector_type == DRM_MODE_CONNECTOR_VGA
||
+ connector-connector_type ==
DRM_MODE_CONNECTOR_DVII ||
+ connector-connector_type ==
DRM_MODE_CONNECTOR_DVID ||
+ connector-connector_type ==
DRM_MODE_CONNECTOR_DVIA ||
+ connector-connector_type ==
DRM_MODE_CONNECTOR_HDMIA ||
+ connector-connector_type ==
DRM_MODE_CONNECTOR_HDMIB)
+ DRM_INFO( DDC: no ddc bus - possible BIOS bug
- please report to xorg-driver-...@lists.x.org\n);
+ }
DRM_INFO( Encoders:\n);
list_for_each_entry(encoder, dev-mode_config.encoder_list,
head) {
radeon_encoder = to_radeon_encoder(encoder);
--
1.6.5.2
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long
[PATCH] drm/radeon/kms: fix screen clearing before fbcon.
From: Dave Airlie airl...@redhat.com This memset_io was added to debug something way back and got left behind, memset the fb to black so the borders don't be all white. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/radeon_fb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index 105c678..0284031 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -243,7 +243,7 @@ int radeonfb_create(struct drm_device *dev, if (ret) goto out_unref; - memset_io(fbptr, 0xff, aligned_size); + memset_io(fbptr, 0x0, aligned_size); strcpy(info-fix.id, radeondrmfb); -- 1.6.5.2 -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Removal of mach64
Except for mach64 :-) Unless I'm mistaken, that never made it into the linux kernel. If someone wants to add mach64 to staging it would be possible, it would be nice if clean patches that pass checkpatch.pl could be constructed for it. Since I think all the security issues were resolved its just a matter of making the code clean. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: add support for hardcoded edids in rom (v2)
From: Alex Deucher alexdeuc...@gmail.com
Some servers hardcode an edid in rom so that they will
work properly with KVMs. This is a port of the relevant
code from the ddx.
[airlied: reworked to validate edid at boot stage - and
remove special quirk, if there is a valid EDID in the BIOS rom
we'll just try and use it.]
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 30 ++--
drivers/gpu/drm/radeon/radeon_combios.c | 33 +++
drivers/gpu/drm/radeon/radeon_display.c | 14 -
drivers/gpu/drm/radeon/radeon_mode.h|6 -
include/drm/drm_crtc.h |2 +
include/drm/drm_edid.h |3 ++
6 files changed, 71 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f665b05..f41e91c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -60,8 +60,7 @@
#define EDID_QUIRK_FIRST_DETAILED_PREFERRED(1 5)
/* use +hsync +vsync for detailed mode */
#define EDID_QUIRK_DETAILED_SYNC_PP(1 6)
-/* define the number of Extension EDID block */
-#define MAX_EDID_EXT_NUM 4
+
#define LEVEL_DMT 0
#define LEVEL_GTF 1
@@ -114,14 +113,14 @@ static const u8 edid_header[] = {
};
/**
- * edid_is_valid - sanity check EDID data
+ * drm_edid_is_valid - sanity check EDID data
* @edid: EDID data
*
* Sanity check the EDID block by looking at the header, the version number
* and the checksum. Return 0 if the EDID doesn't check out, or 1 if it's
* valid.
*/
-static bool edid_is_valid(struct edid *edid)
+bool drm_edid_is_valid(struct edid *edid)
{
int i, score = 0;
u8 csum = 0;
@@ -163,6 +162,7 @@ bad:
}
return 0;
}
+EXPORT_SYMBOL(drm_edid_is_valid);
/**
* edid_vendor - match a string against EDID's obfuscated vendor field
@@ -1069,8 +1069,8 @@ static int add_detailed_info_eedid(struct drm_connector
*connector,
}
/* Chose real EDID extension number */
- edid_ext_num = edid-extensions MAX_EDID_EXT_NUM ?
- MAX_EDID_EXT_NUM : edid-extensions;
+ edid_ext_num = edid-extensions DRM_MAX_EDID_EXT_NUM ?
+ DRM_MAX_EDID_EXT_NUM : edid-extensions;
/* Find CEA extension */
for (i = 0; i edid_ext_num; i++) {
@@ -1152,7 +1152,7 @@ static int drm_ddc_read_edid(struct drm_connector
*connector,
for (i = 0; i 4; i++) {
if (drm_do_probe_ddc_edid(adapter, buf, len))
return -1;
- if (edid_is_valid((struct edid *)buf))
+ if (drm_edid_is_valid((struct edid *)buf))
return 0;
}
@@ -1177,7 +1177,7 @@ struct edid *drm_get_edid(struct drm_connector *connector,
int ret;
struct edid *edid;
- edid = kmalloc(EDID_LENGTH * (MAX_EDID_EXT_NUM + 1),
+ edid = kmalloc(EDID_LENGTH * (DRM_MAX_EDID_EXT_NUM + 1),
GFP_KERNEL);
if (edid == NULL) {
dev_warn(connector-dev-pdev-dev,
@@ -1195,14 +1195,14 @@ struct edid *drm_get_edid(struct drm_connector
*connector,
if (edid-extensions != 0) {
int edid_ext_num = edid-extensions;
- if (edid_ext_num MAX_EDID_EXT_NUM) {
+ if (edid_ext_num DRM_MAX_EDID_EXT_NUM) {
dev_warn(connector-dev-pdev-dev,
The number of extension(%d) is
over max (%d), actually read number (%d)\n,
-edid_ext_num, MAX_EDID_EXT_NUM,
-MAX_EDID_EXT_NUM);
+edid_ext_num, DRM_MAX_EDID_EXT_NUM,
+DRM_MAX_EDID_EXT_NUM);
/* Reset EDID extension number to be read */
- edid_ext_num = MAX_EDID_EXT_NUM;
+ edid_ext_num = DRM_MAX_EDID_EXT_NUM;
}
/* Read EDID including extensions too */
ret = drm_ddc_read_edid(connector, adapter, (char *)edid,
@@ -1245,8 +1245,8 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
goto end;
/* Chose real EDID extension number */
- edid_ext_num = edid-extensions MAX_EDID_EXT_NUM ?
- MAX_EDID_EXT_NUM : edid-extensions;
+ edid_ext_num = edid-extensions DRM_MAX_EDID_EXT_NUM ?
+ DRM_MAX_EDID_EXT_NUM : edid-extensions;
/* Find CEA extension */
for (i = 0; i edid_ext_num; i++) {
@@ -1303,7 +1303,7 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
if (edid == NULL) {
return 0;
}
- if (!edid_is_valid(edid)) {
+ if (!drm_edid_is_valid(edid)) {
dev_warn(connector-dev-pdev
[PATCH] drm/radeon/kms: don't crash is no DDC bus on VGA connector.
From: Dave Airlie airl...@redhat.com
This is strange - like really really strange, twilight zone of strange.
VGA ports have DDC buses, but sometimes for some reasons the BIOS
says we don't and we oops.
reported on irc by nirbheek
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_connectors.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 2d8e5a7..a013ff5 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -580,16 +580,18 @@ static enum drm_connector_status radeon_vga_detect(struct
drm_connector *connect
struct radeon_connector *radeon_connector =
to_radeon_connector(connector);
struct drm_encoder *encoder;
struct drm_encoder_helper_funcs *encoder_funcs;
- bool dret;
+ bool dret = false;
enum drm_connector_status ret = connector_status_disconnected;
encoder = radeon_best_single_encoder(connector);
if (!encoder)
ret = connector_status_disconnected;
- radeon_i2c_do_lock(radeon_connector-ddc_bus, 1);
- dret = radeon_ddc_probe(radeon_connector);
- radeon_i2c_do_lock(radeon_connector-ddc_bus, 0);
+ if (radeon_connector-ddc_bus) {
+ radeon_i2c_do_lock(radeon_connector-ddc_bus, 1);
+ dret = radeon_ddc_probe(radeon_connector);
+ radeon_i2c_do_lock(radeon_connector-ddc_bus, 0);
+ }
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
--
1.6.5.2
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D OpenGL applications eat CPU ressources
Anyway, I don't know whether this is due to PCI mode or not, but OpenGL performances, although there's no more GPU lockup, are poor. And serious OpenGL applications, as simulated by the SPECviewperf test suite, have very irregular frame rates. If I'm not mistaken, the BusType option is specific to the radeon driver (or maybe other drivers too)? I mean, it's not a X.org wide configuration option, isn't it? This would thus narrow my investigation path to the AGP code of the radeon driver, right? No it narrows it down the to the AGP hardware in your machine along with the probable lack of info on it, and maybe some tweaks that we know nothing about. If it was as simple as a codepath in the radeon driver I think we'd have fixed it by now. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
If it now does not boot up if all its sub-options are enabled, even of some of those sub-options are new, does that count as a driver regression? Sure it does to me ... But it doesn't to anyone else under any reasonable meaning of the word regression. The config option states Choose this option if you want kernel modesetting enabled by default, and you have a new enough userspace to support this. Running old userspaces with this enabled will cause pain. Will cause pain sounds painful to me, I can make it seem much worse if you'd like. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Fri, Feb 5, 2010 at 7:00 PM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: If it now does not boot up if all its sub-options are enabled, even of some of those sub-options are new, does that count as a driver regression? Sure it does to me ... But it doesn't to anyone else under any reasonable meaning of the word regression. There are reactions in this thread that contradict your 'anyone else' point. The config option states Choose this option if you want kernel modesetting enabled by default, and you have a new enough userspace to support this. Running old userspaces with this enabled will cause pain. Will cause pain sounds painful to me, I can make it seem much worse if you'd like. Except you are missing that the hang (and the first crash as well) happens on brand-new user-space just as much - not just on 'old userspaces'. The bugs i've triggered are independent of any user-space component - it happens with a fresh distro just as much. As i suggested before, at least the text should be updated to include what has been written about CONFIG_DRM_RADEON_KMS in this thread before: This is a completely new driver. It's only part of the existing drm for compatibility reasons. It requires an entirely different graphics stack above it and works very differently from the old drm stack. Okay I've attached a patch with a revised Kconfig in it. Does this sound more like reality? Dave. 0001-drm-radeon-kms-change-Kconfig-text-to-reflect-the-ne.patch Description: Binary data -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [2.6.33-rc6-git regression] idr fix breaks Xorg
On Thu, Feb 4, 2010 at 6:16 PM, Tejun Heo t...@kernel.org wrote: Hello, On 02/04/2010 04:56 PM, Andy Isaacson wrote: 1265267921.568269 ioctl(8, 0xc020645e, 0x7fffe2196980) = -1 EBADF (Bad file descriptor) Hmm... -EBADF? I suppose it doesn't mean that the fd is invalid in this case but that the mapped object can't be found for some reason? Can anyone more familiar with the subsystem explain what's going on? 1265267921.568649 write(2, ../../../libdrm/intel/intel_bufmgr_gem.c:637: Error mapping buffer 1073741824 (gen4 WM state): Bad file descriptor .\n, 117) = 117 1265267921.569039 --- SIGSEGV (Segmentation fault) @ 0 (0) --- I'll forward the fore mentioned fix as it at least fixes one reported failure. Hmm at this late stage, maybe revert first? since the old idr code works fine with the subsystems in question. The drm idr code usage isn't anything crazy, the EBADF is the return code from the mmap ioctl when it calls the idr lookup function for a handle. The lookup function is just an idr_find inside a spinlock. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Fri, Feb 5, 2010 at 5:24 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Feb 2010, Alex Deucher wrote: And if it crashes, he'll report a bug and we'll fix it. Ok, you have a bug-report. See earlier in the thread: btw., i just found another bug activated via this same commit, a boot hang after DRM init: [ 9.858352] [drm] Connector 1: [ 9.861417] [drm] DVI-I [ 9.864031] [drm] HPD1 [ 9.866562] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [ 9.872579] [drm] Encoders: [ 9.875540] [drm] CRT2: INTERNAL_DAC2 [ 9.879541] [drm] DFP1: INTERNAL_TMDS1 [ 9.883646] [drm] Connector 2: [ 9.886695] [drm] S-video [ 9.889483] [drm] Encoders: [ 9.892463] [drm] TV1: INTERNAL_DAC2 [ 9.896392] i2c i2c-0: master_xfer[0] W, addr=0x50, len=1 [ 9.901796] i2c i2c-0: master_xfer[1] R, addr=0x50, len=128 [ 9.909246] i2c i2c-0: NAK from device addr 0x50 msg #0 [ 9.914564] i2c i2c-1: master_xfer[0] W, addr=0x50, len=1 [ 9.919957] i2c i2c-1: master_xfer[1] R, addr=0x50, len=128 [ 9.927413] i2c i2c-1: NAK from device addr 0x50 msg #0 So can we get it fixed, please? Ingo, got the full dmesg? and lspci -vvnn the bug reporting needs work, this snippet hasn't the useful info in it. Dave. Linus -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Wed, Feb 3, 2010 at 1:44 AM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: It's the moving of radeom KMS out of staging after -rc6 that causes it, because it brought it into the scope of my testing: f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging. So at least on this box it's clearly not ready for mainline enablement yet. I've attached the revert patch further below. Its not enabled by default so reverting this doesn't make much sense. I boot allyesconfig kernels regularly, which testing method works fine with another 2000+ upstream drivers. (including the dozens of drivers which match to active hardware components on that box) Okay this was something I wondered about, since these are *not* allyesconfig .configs, I've generated some and CONFIG_FB_RADEON is always on here, and you seem to not have that enabled (not that enabling it is a good idea it is in fact a really bad idea). So do you have something you are running after allyesconfig to fix things? or have you just got a config that is close enough to allyesconfig. I'm building kernels with your .config now and boot testing them on the full range of hardware I have/ Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Fri, Feb 5, 2010 at 6:46 AM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@gmail.com wrote: On Wed, Feb 3, 2010 at 1:44 AM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: It's the moving of radeom KMS out of staging after -rc6 that causes it, because it brought it into the scope of my testing: ?f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging. So at least on this box it's clearly not ready for mainline enablement yet. I've attached the revert patch further below. Its not enabled by default so reverting this doesn't make much sense. I boot allyesconfig kernels regularly, which testing method works fine with another 2000+ upstream drivers. (including the dozens of drivers which match to active hardware components on that box) Okay this was something I wondered about, since these are *not* allyesconfig .configs, I've generated some and CONFIG_FB_RADEON is always on here, and you seem to not have that enabled (not that enabling it is a good idea it is in fact a really bad idea). These were random configs - the size doesnt match an allyesconfig, those are way bigger. My above comment related to the first crash, and to my argument that all other drivers are fine during bootup - and there's a lot of them. So do you have something you are running after allyesconfig to fix things? or have you just got a config that is close enough to allyesconfig. I'm building kernels with your .config now and boot testing them on the full range of hardware I have/ Thanks. Is there something i can enable to get a better log for you to find out where (and why) it's hanging? It's still early during bootup so the box is not particularly debuggable - so i'm not sure i can get a task list dump, etc., unfortunately. Do you have NMI watchdog enabled? (does it work that early) a backtrace of where it hangs would be nice, Also a dmesg from booting with drm.debug=15 might help narrow it down also. Dave. Ingo -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Fri, Feb 5, 2010 at 7:23 AM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 4 Feb 2010 22:05:59 +0100 Ingo Molnar mi...@elte.hu wrote: * Matthew Garrett mj...@srcf.ucam.org wrote: On Thu, Feb 04, 2010 at 09:22:54PM +0100, Ingo Molnar wrote: Hey, -rc7 just hung on me after enabling this new .config option it offered for the radeon driver i am using, please add this to the list of regressions. If the same configuration options hang on both an old kernel and a new kernel, how is that in any plausible way a regression? What's regressed? Regressions are not limited to 'same config' kernels, last i checked. If that has changed (or if i'm misunderstanding it) then it would be nice to hear a clarification about that from Linus. The way i understand it is that there are narrow exceptions from the regression rules, such as completely new drivers for which there can be no prior expectation of stability by users. (but for even them we are generally on the safer side to list bugs in them as regressions as well - especially if we expect many users to enable it.) AFAIK there's no exception for new sub-features of existing facilities or drivers, even if it's default-disabled. This issue materially affects quite a few bugs i'm handling as a maintainer. Many of them are under default-off config options - most new aspects to existing code are introduced in such a way. It would remove quite a bit of urgent-workload from my workflow if i could strike them from Rafael's list and could deprioritize them as plain bugs, to be fixed as time permits. IMHO it would be rather counter-productive to kernel quality if we did that kind of regression-lawyering though. Yes, it's mainly semantics. From the user's point of view kernel N: boots, works, plays nethack kernel N+1: goes splat That kernel regressed for that user. He'll shrug and will go back to kernel N and we lost an N+1 tester. And the distros who ship N+1 get a lot of hack work to do. If they used the same .config and it breaks then its a regression if not its not. both then intel and radeon KMS enable is also quite clear on the fact that'll it break your userspace, so I'd hope ppl are reading it. If the feature is this buggy, it was wrong to make it accessible in Kconfig. The bug was identified after we enabled the option, we have no record of a similiar problem occuring in Fedora or Ubuntu bug trackers, and my future sight is broken. Anyway. The number of DRI regressions which have come in over the past few weeks is really quite extraordinary. We're now showing 31 open DRI regressions in bugzilla, but a lot of those are presumably defunct. It's been bad ever since the KMS stuff went in. That's understandable given the magnitude of the change, I guess, but the wheels really seem to have falled off in 2.6.32 and 2.6.33. Its not unsurprising, also Intel vs Radeon KMS is an big distinction, the core KMS code hasn't seen much in the way of problems its driver related. The problem is the kernel is now exposed to the sort of things for years we've had in userspace, graphics drivers are hard. Add the interactions with ACPI, crazy BIOS writers, SMMs, suspend/resume, power management and it just is really really messy. I know in the Intel driver we've been backing out a lot of the new features as soon as we can identify if the hw or sw is at fault and I've been pushing the Intel guys to keep on top of the regession list better, hopefully they are doing so. Also things like the idr change that just bounced in/out broke all of the GEM drivers along with AGP changes in the x86 tree that broke shit. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
These were random configs - the size doesnt match an allyesconfig, those are way bigger. My above comment related to the first crash, and to my argument that all other drivers are fine during bootup - and there's a lot of them. So do you have something you are running after allyesconfig to fix things? or have you just got a config that is close enough to allyesconfig. I'm building kernels with your .config now and boot testing them on the full range of hardware I have/ Thanks. Is there something i can enable to get a better log for you to find out where (and why) it's hanging? It's still early during bootup so the box is not particularly debuggable - so i'm not sure i can get a task list dump, etc., unfortunately. Do you have NMI watchdog enabled? (does it work that early) a backtrace of where it hangs would be nice, Also a dmesg from booting with drm.debug=15 might help narrow it down also. Okay I've booted this on the rv370 + rv380 machines I have, I've no old Athlon's though so I'm trying to get RHTS to give me access to one or two internally, Another question, that came to mind, what is there any monitors plugged in? or a KVM or something? if yes can you try without and if no can you try with? Also can you add CONFIG_FRAMEBUFFER_CONSOLE as well since I don't think we test often without it. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus All radeon related: 2 warning fixes 2 r600/700 regression fixes 1 r100/r200 rendering fix (always broken with KMS) 1 HDMI audio regression work around - turn off audioon that hw for now 1 oops fix seen on Ingo's machine in the failure path 2 rs480 fixes from my laptop - one fixes scary MC idling messages 1 r300 vram width calc fix. I'm sort of hoping the vram width fix will help on Ingo's machine Ingo, 5ff55717674470b96562f931f778c878080755b7 is the commit id if you want to try it out, its definitely wrong when I compared it to the docs. I'm still code-reviewing more of r300.c. Dave. drivers/gpu/drm/ati_pcigart.c |2 +- drivers/gpu/drm/radeon/r100.c | 14 +--- drivers/gpu/drm/radeon/r300.c | 16 + drivers/gpu/drm/radeon/r420.c |3 +- drivers/gpu/drm/radeon/r520.c |3 +- drivers/gpu/drm/radeon/r600.c | 48 +++ drivers/gpu/drm/radeon/r600_audio.c|2 +- drivers/gpu/drm/radeon/radeon.h|8 + drivers/gpu/drm/radeon/radeon_asic.h | 11 ++ drivers/gpu/drm/radeon/radeon_combios.c|3 +- drivers/gpu/drm/radeon/radeon_connectors.c |2 +- drivers/gpu/drm/radeon/radeon_gem.c|3 ++ drivers/gpu/drm/radeon/rs400.c | 28 drivers/gpu/drm/radeon/rs600.c |2 - drivers/gpu/drm/radeon/rs690.c |2 - drivers/gpu/drm/radeon/rv515.c |4 +-- drivers/gpu/drm/radeon/rv770.c | 24 +++--- 17 files changed, 114 insertions(+), 61 deletions(-) commit 5ff55717674470b96562f931f778c878080755b7 Author: Dave Airlie airl...@redhat.com Date: Fri Feb 5 13:57:03 2010 +1000 drm/radeon/kms: fix r300 vram width calculations This was incorrect according to the docs and the UMS driver does it like this. Signed-off-by: Dave Airlie airl...@redhat.com commit a17538f93c16f0e15e35dc31eedad87e2d9c5c26 Author: Dave Airlie airl...@redhat.com Date: Fri Feb 5 13:41:54 2010 +1000 drm/radeon/kms: rs400/480 MC setup is different than r300. Boot testing on my rs480 laptop found the MC idle never happened on startup, a quick check with AMD found the idle bit is in a different place on the rs4xx than r300. Implement a new rs400 mc idle function to fix this. Signed-off-by: Dave Airlie airl...@redhat.com commit 624ab4f87e99f10ea3b45e76039c477fd4d7a7e6 Author: Dave Airlie airl...@davers480.(none) Date: Wed Jan 27 16:07:15 2010 +1000 drm/radeon/kms: make initial state of load detect property correct. this was incorrect on my rs480. Signed-off-by: Dave Airlie airl...@redhat.com commit 23fff28a9b0529869bffef8aab0d3f350dd3b5a4 Author: Dave Airlie airl...@redhat.com Date: Fri Feb 5 11:57:42 2010 +1000 drm/radeon/kms: disable HDMI audio for now on rv710/rv730 Support isn't correct yet and we are getting green tinges on the displays. Signed-off-by: Dave Airlie airl...@redhat.com commit 655efd3dc92cd0d37292157178d33deb0430aeaa Author: Jerome Glisse jgli...@redhat.com Date: Tue Feb 2 11:51:45 2010 +0100 drm/radeon/kms: don't call suspend path before cleaning up GPU In suspend path we unmap the GART table while in cleaning up path we will unbind buffer and thus try to write to unmapped GART leading to oops. In order to avoid this we don't call the suspend path in cleanup path. Cleanup path is clever enough to desactive GPU like the suspend path is doing, thus this was redondant. Tested on: RV370, R420, RV515, RV570, RV610, RV770 (all PCIE) Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit 94cf6434a1bc5958d5da3be62f1272792dada2bf Author: Andrew Morton a...@linux-foundation.org Date: Tue Feb 2 14:40:29 2010 -0800 drivers/gpu/drm/radeon/radeon_combios.c: fix warning drivers/gpu/drm/radeon/radeon_combios.c: In function 'radeon_combios_get_lvds_info': drivers/gpu/drm/radeon/radeon_combios.c:893: warning: comparison is always false due to limited range of data type Cc: Dave Airlie airl...@linux.ie Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Dave Airlie airl...@redhat.com commit d7748bacbbee80b2cc4b690a74d5db2cd84acd7b Author: Randy Dunlap randy.dun...@oracle.com Date: Tue Feb 2 14:40:33 2010 -0800 ati_pcigart: fix printk format warning Fix ati_pcigart printk format warning: drivers/gpu/drm/ati_pcigart.c:115: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t' Signed-off-by: Randy Dunlap randy.dun...@oracle.com Cc: Zhenyu Wang zhen...@linux.intel.com Cc: Dave Airlie airl
[PATCH] drm/radeon/kms: set gart pages to invalid on unbind
From: Dave Airlie airl...@redhat.com
this uses a new entrypoint to invalidate gart entries instead of using 0.
I'm not 100% sure this is going to work, we probably need to allocate
a dummy page and point all the GTT entries at it similiar to what AGP does.
but we can test this first I suppose.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 10 ++
drivers/gpu/drm/radeon/r300.c | 14 ++
drivers/gpu/drm/radeon/radeon.h|3 +++
drivers/gpu/drm/radeon/radeon_asic.h | 14 ++
drivers/gpu/drm/radeon/radeon_device.c |3 +++
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu/drm/radeon/rs400.c | 10 ++
drivers/gpu/drm/radeon/rs600.c | 11 +++
8 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 9667c3e..302a2ba 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -181,6 +181,7 @@ int r100_pci_gart_init(struct radeon_device *rdev)
rdev-gart.table_size = rdev-gart.num_gpu_pages * 4;
rdev-asic-gart_tlb_flush = r100_pci_gart_tlb_flush;
rdev-asic-gart_set_page = r100_pci_gart_set_page;
+ rdev-asic-gart_clear_page = r100_pci_gart_clear_page;
return radeon_gart_table_ram_alloc(rdev);
}
@@ -233,6 +234,15 @@ int r100_pci_gart_set_page(struct radeon_device *rdev, int
i, uint64_t addr)
return 0;
}
+int r100_pci_gart_clear_page(struct radeon_device *rdev, int i)
+{
+ if (i 0 || i rdev-gart.num_gpu_pages) {
+ return -EINVAL;
+ }
+ rdev-gart.table.ram.ptr[i] = 0;
+ return 0;
+}
+
void r100_pci_gart_fini(struct radeon_device *rdev)
{
r100_pci_gart_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index ffada48..6bd9c5c 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -83,6 +83,19 @@ int rv370_pcie_gart_set_page(struct radeon_device *rdev, int
i, uint64_t addr)
return 0;
}
+
+int rv370_pcie_gart_clear_page(struct radeon_device *rdev, int i)
+{
+ void __iomem *ptr = (void *)rdev-gart.table.vram.ptr;
+
+ if (i 0 || i rdev-gart.num_gpu_pages) {
+ return -EINVAL;
+ }
+
+ writel(0, ((void __iomem *)ptr) + (i * 4));
+ return 0;
+}
+
int rv370_pcie_gart_init(struct radeon_device *rdev)
{
int r;
@@ -101,6 +114,7 @@ int rv370_pcie_gart_init(struct radeon_device *rdev)
rdev-gart.table_size = rdev-gart.num_gpu_pages * 4;
rdev-asic-gart_tlb_flush = rv370_pcie_gart_tlb_flush;
rdev-asic-gart_set_page = rv370_pcie_gart_set_page;
+ rdev-asic-gart_clear_page = rv370_pcie_gart_clear_page;
return radeon_gart_table_vram_alloc(rdev);
}
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d8b5c61..be111f6 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -723,6 +723,7 @@ struct radeon_asic {
int (*gpu_reset)(struct radeon_device *rdev);
void (*gart_tlb_flush)(struct radeon_device *rdev);
int (*gart_set_page)(struct radeon_device *rdev, int i, uint64_t addr);
+ int (*gart_clear_page)(struct radeon_device *rdev, int i);
int (*cp_init)(struct radeon_device *rdev, unsigned ring_size);
void (*cp_fini)(struct radeon_device *rdev);
void (*cp_disable)(struct radeon_device *rdev);
@@ -,6 +1112,7 @@ static inline void radeon_ring_write(struct radeon_device
*rdev, uint32_t v)
#define radeon_gpu_reset(rdev) (rdev)-asic-gpu_reset((rdev))
#define radeon_gart_tlb_flush(rdev) (rdev)-asic-gart_tlb_flush((rdev))
#define radeon_gart_set_page(rdev, i, p) (rdev)-asic-gart_set_page((rdev),
(i), (p))
+#define radeon_gart_clear_page(rdev, i) (rdev)-asic-gart_clear_page((rdev),
(i))
#define radeon_cp_commit(rdev) (rdev)-asic-cp_commit((rdev))
#define radeon_ring_start(rdev) (rdev)-asic-ring_start((rdev))
#define radeon_ring_test(rdev) (rdev)-asic-ring_test((rdev))
@@ -1173,6 +1175,7 @@ extern void r100_pci_gart_fini(struct radeon_device
*rdev);
extern int r100_pci_gart_enable(struct radeon_device *rdev);
extern void r100_pci_gart_disable(struct radeon_device *rdev);
extern int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t
addr);
+extern int r100_pci_gart_clear_page(struct radeon_device *rdev, int i);
extern int r100_debugfs_mc_info_init(struct radeon_device *rdev);
extern int r100_gui_wait_for_idle(struct radeon_device *rdev);
extern void r100_ib_fini(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index d758b1f..6077f0e 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -56,6 +56,7 @@ int r100_gpu_reset(struct radeon_device *rdev);
u32 r100_get_vblank_counter
[PATCH 2/2] drm/radeon/kms: switch all KMS driver ioctls to unlocked.
From: Dave Airlie airl...@redhat.com
Internal locking should be sufficent for all these cases.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_kms.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index f23b056..3c5002e 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -276,17 +276,17 @@ struct drm_ioctl_desc radeon_ioctls_kms[] = {
DRM_IOCTL_DEF(DRM_RADEON_SURF_ALLOC, radeon_surface_alloc_kms,
DRM_AUTH),
DRM_IOCTL_DEF(DRM_RADEON_SURF_FREE, radeon_surface_free_kms, DRM_AUTH),
/* KMS */
- DRM_IOCTL_DEF(DRM_RADEON_GEM_INFO, radeon_gem_info_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_CREATE, radeon_gem_create_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_MMAP, radeon_gem_mmap_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl,
DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_PREAD, radeon_gem_pread_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_PWRITE, radeon_gem_pwrite_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl,
DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_CS, radeon_cs_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_INFO, radeon_info_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl,
DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl,
DRM_AUTH),
- DRM_IOCTL_DEF(DRM_RADEON_GEM_BUSY, radeon_gem_busy_ioctl, DRM_AUTH),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_INFO, radeon_gem_info_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_CREATE, radeon_gem_create_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_MMAP, radeon_gem_mmap_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_SET_DOMAIN, radeon_gem_set_domain_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_PREAD, radeon_gem_pread_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_PWRITE, radeon_gem_pwrite_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_WAIT_IDLE, radeon_gem_wait_idle_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_CS, radeon_cs_ioctl, DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_INFO, radeon_info_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_SET_TILING, radeon_gem_set_tiling_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_GET_TILING, radeon_gem_get_tiling_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_RADEON_GEM_BUSY, radeon_gem_busy_ioctl,
DRM_AUTH|DRM_UNLOCKED),
};
int radeon_max_kms_ioctl = DRM_ARRAY_SIZE(radeon_ioctls_kms);
--
1.6.6
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm: switch all GEM/KMS ioctls to unlocked ioctl status.
From: Dave Airlie airl...@redhat.com
These ioctls are all protected by their own locking mechanisms so
should be fine to not bother locking around.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_drv.c | 44 ++--
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 766c468..f3c58e2 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -125,28 +125,28 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_UPDATE_DRAW, drm_update_drawable_info,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, 0),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl, DRM_AUTH),
- DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl, DRM_AUTH),
-
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl,
DRM_MASTER),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl,
DRM_MASTER),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl,
DRM_MASTER | DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY,
drm_mode_connector_property_set_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW),
- DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW)
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_CLOSE, drm_gem_close_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_FLINK, drm_gem_flink_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_GEM_OPEN, drm_gem_open_ioctl,
DRM_AUTH|DRM_UNLOCKED),
+
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl,
DRM_MASTER|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETGAMMA, drm_mode_gamma_set_ioctl,
DRM_MASTER|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETENCODER, drm_mode_getencoder,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl,
DRM_MASTER | DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY,
drm_mode_connector_property_set_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl,
DRM_MASTER
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@gmail.com wrote: On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I've also added an oops fix I seem to lose off my radar to this tree. commit 17aafccab4352b422aa01fa6ebf82daff693a5b3 Author: Michel D??nzer daen...@vmware.com Date: ? Fri Jan 22 09:20:00 2010 +0100 ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure. Wierd this suggests something else is wrong on that machine can you get me the whole dmesg? I'm guessing some iommu or swiotlb issue. This box has no known hardware or software problems, just this week it booted in excess of 1000 kernels so i'd exclude that angle for now. I have bisected the crash back to the DRM tree and the crash went away with the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted my config and i posted the relevant boot log as well. Find below the full bootlog as well with vanilla -git (ab65832) and the config. (i dont think it matters) I've asked Jerome to fix the oops, but really anyone with an old .config won't get hit by this, and we've booted this on quite a lot of machines at this point. I dont see the commit in yesterday's linux-next. It has very fresh timestamps: ?commit f71d0187987e691516cd10c2702f002c0e2f0edc ?Author: ? ? Dave Airlie airl...@redhat.com ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000 ?Commit: ? ? Dave Airlie airl...@redhat.com ?CommitDate: Mon Feb 1 11:35:47 2010 +1000 What kind of widespread testing could this commit have gotten in the less than 24 hours before it hit mainline? Its shipping in a major distro by default, its planned to be shipped in an even more major distro. Its been boot tested on 1000s of machines by 1000s of ppl. Well but that's not the precise tree you sent to Linus, is it? It pretty much is. If I could blame your crash on any of the recent patches I would but its something new and unfun. Most of the fixes in the Linus tree are directly from fixes to Fedora/Ubuntu bug reports. even after reviewing the dmesg I can't see why its failing on that system, If you could build 2.6.32 on that machine with the staging flag enabled and see if it works it would at least tell us if it is something in recent times or just something thats always been there. Unless some other option in make allyesconfig is conflicting and we've never hit it before. Fedora is close to allyesconfig but not pathalogical like allyesconfig is. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Thu, Feb 4, 2010 at 5:36 PM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@gmail.com wrote: On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@gmail.com wrote: On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I've also added an oops fix I seem to lose off my radar to this tree. commit 17aafccab4352b422aa01fa6ebf82daff693a5b3 Author: Michel D??nzer daen...@vmware.com Date: ? Fri Jan 22 09:20:00 2010 +0100 ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure. Wierd this suggests something else is wrong on that machine can you get me the whole dmesg? I'm guessing some iommu or swiotlb issue. This box has no known hardware or software problems, just this week it booted in excess of 1000 kernels so i'd exclude that angle for now. I have bisected the crash back to the DRM tree and the crash went away with the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted my config and i posted the relevant boot log as well. Find below the full bootlog as well with vanilla -git (ab65832) and the config. (i dont think it matters) I've asked Jerome to fix the oops, but really anyone with an old .config won't get hit by this, and we've booted this on quite a lot of machines at this point. I dont see the commit in yesterday's linux-next. It has very fresh timestamps: ?commit f71d0187987e691516cd10c2702f002c0e2f0edc ?Author: ? ? Dave Airlie airl...@redhat.com ?AuthorDate: Mon Feb 1 11:35:47 2010 +1000 ?Commit: ? ? Dave Airlie airl...@redhat.com ?CommitDate: Mon Feb 1 11:35:47 2010 +1000 What kind of widespread testing could this commit have gotten in the less than 24 hours before it hit mainline? Its shipping in a major distro by default, its planned to be shipped in an even more major distro. Its been boot tested on 1000s of machines by 1000s of ppl. Well but that's not the precise tree you sent to Linus, is it? It pretty much is. If I could blame your crash on any of the recent patches I would but its something new and unfun. [...] You dont seem to realize the plain and simple fact that the bug (and some other bug) was obscure before because this particular KMS aspect of the radeon driver was in drivers/staging/, and it became more prominent via this post-rc6 commit: | From f71d0187987e691516cd10c2702f002c0e2f0edc Mon Sep 17 00:00:00 2001 | From: Dave Airlie airl...@redhat.com | Date: Mon, 1 Feb 2010 11:35:47 +1000 | Subject: [PATCH] drm/radeon/kms: move radeon KMS on/off switch out of staging. | | We are happy enough that the KMS driver is stable enough for enough people | for the kms enable/disable to leave staging. Distros can now contemplate | turning this on. | | Signed-off-by: Dave Airlie airl...@redhat.com | --- | drivers/gpu/drm/Kconfig | 2 ++ | drivers/staging/Kconfig | 2 -- | 2 files changed, 2 insertions(+), 2 deletions(-) I never claimed (and still dont claim) that the bug is 'new' per se, so why do you keep beating down on that straw man argument? I said it in my very first mail that this bug got brought upon us by the Kconfig commit above: It's the moving of radeom KMS out of staging after -rc6 that causes it, because it brought it into the scope of my testing: f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging. So at least on this box it's clearly not ready for mainline enablement yet. I dont mind reporting bugs and testing patches (as i did), all i said is that from a QA angle it's somewhat late to do that in -rc7. (It's not even a completely new driver either, which people would know to stay away from - it's a new config option of an existing driver, so i'd expect many people to turn it on when they see it in the oldconfig - even though it's default-off.) You made the bug more prominent by moving it into the driver proper, after -rc6, and while i dont mind reporting and working on bugs, your constant denial is somewhat counter-productive, as (beyond the waste of time on these emails) it suggests that we might see repeat incidents of this kind in the future. Anyway, with two bugs in a row this commit is clearly too problematic for me so i have reverted f71d018 from -tip. I haven't denied anything, I'm merely stating one bug on one machine isn't the end of the known world. the Kconfig clearly states you need to review your userspace to use this code, so if people are turning things on blindly they are going to get problems. This is true for all KMS drivers and will remain true. allytesconfig isn't something
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
It's the moving of radeom KMS out of staging after -rc6 that causes it, because it brought it into the scope of my testing: f71d018: drm/radeon/kms: move radeon KMS on/off switch out of staging. So at least on this box it's clearly not ready for mainline enablement yet. I've attached the revert patch further below. Its not enabled by default so reverting this doesn't make much sense. We can just treat this as a normal driver bugreport. Dave. Ingo [6.864061] IOAPIC[0]: Set routing entry (2-5 - 0x35 - IRQ 5 Mode:1 Active:1) [6.871010] radeon :01:00.0: PCI-APIC IRQ transform: INT A - IRQ 5 [6.878014] radeon :01:00.0: setting latency timer to 64 [6.885950] device: 'controlD64': device_add [6.890221] device: 'card0': device_add [6.894100] [drm] radeon: Initializing kernel modesetting. [6.900042] radeon :01:00.0: using 40bit DMA mask [6.905018] [drm] register mmio base: 0xD900 [6.910004] [drm] register mmio size: 65536 [6.916147] [drm] GPU reset succeed (RBBM_STATUS=0x0140) [6.917049] [drm] Generation 2 PCI interface, using max accessible memory [6.918004] [drm] radeon: VRAM 128M [6.919003] [drm] radeon: VRAM from 0x to 0x07FF [6.920005] [drm] radeon: GTT 512M [6.921003] [drm] radeon: GTT from 0x2000 to 0x3FFF [6.922241] alloc irq_desc for 24 on node -1 [6.922999] alloc kstat_irqs on node -1 [6.923036] radeon :01:00.0: irq 24 for MSI/MSI-X [6.924028] [drm] radeon: using MSI. [6.925133] [drm] radeon: irq initialized. [6.926009] [drm] Detected VRAM RAM=128M, BAR=128M [6.927003] [drm] RAM width 64bits DDR [6.929249] [TTM] Zone kernel: Available graphics memory: 434560 kiB. [6.930010] [TTM] Zone highmem: Available graphics memory: 506212 kiB. [6.931200] [drm] radeon: 128M of VRAM memory ready [6.932005] [drm] radeon: 512M of GTT memory ready. [6.933094] [drm] GART: num cpu pages 131072, num gpu pages 131072 [6.935508] [drm] radeon: 1 quad pipes, 1 Z pipes initialized. [6.936033] [drm] PCIE GART of 512M enabled (table at 0x0004). [6.937068] [drm] radeon: cp idle (0x1C03) [6.938011] Registering platform device 'radeon_cp.0'. Parent at platform [6.939005] device: 'radeon_cp.0': device_add [6.940018] bus: 'platform': add device radeon_cp.0 [6.941122] [drm] Loading R300 Microcode [6.942009] platform radeon_cp.0: firmware: using built-in firmware radeon/R300_cp.bin [6.943023] bus: 'platform': remove device radeon_cp.0 [6.945161] [drm] radeon: ring at 0x2000 [7.108115] [drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD) [7.109004] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [7.110003] radeon :01:00.0: failled initializing CP (-22). [7.111003] radeon :01:00.0: Disabling GPU acceleration [7.273547] Failed to wait GUI idle while programming pipes. Bad things might happen. [7.436296] [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [7.598755] Failed to wait GUI idle while programming pipes. Bad things might happen. [7.599306] BUG: unable to handle kernel paging request at f838 [7.59] IP: [c149f0de] rv370_pcie_gart_set_page+0x2d/0x3c [7.59] *pde = 36d44067 *pte = [7.59] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC [7.59] last sysfs file: [7.59] [7.59] Pid: 1, comm: swapper Not tainted 2.6.33-rc6-00066-g9ce9290-dirty #14391 A8N-E/System Product Name [7.59] EIP: 0060:[c149f0de] EFLAGS: 00010206 CPU: 0 [7.59] EIP is at rv370_pcie_gart_set_page+0x2d/0x3c [7.59] EAX: 000c EBX: ECX: f838 EDX: f838 [7.59] ESI: EDI: 0001 EBP: f6c33d68 ESP: f6c33d60 [7.59] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [7.59] Process swapper (pid: 1, ti=f6c32000 task=f6c3 task.ti=f6c32000) [7.59] Stack: [7.59] f6a1f004 f6c33d90 c14899fb 0100 [7.59] 0 f6a06538 0002 f6c33d9c c1488467 f6a06500 f6c33da8 [7.59] 0 c14628ad f6a12af0 f6c33dd0 c146413a c20d0d00 f6a1f364 f6a1f364 [7.59] Call Trace: [7.59] [c14899fb] ? radeon_gart_unbind+0xb7/0xdf [7.59] [c1488467] ? radeon_ttm_backend_unbind+0x14/0x1d [7.59] [c14628ad] ? ttm_tt_unbind+0x15/0x27 [7.59] [c146413a] ? ttm_bo_cleanup_refs+0xe0/0x1e8 [7.59] [c1465717] ? ttm_bo_release+0x4c/0x65 [7.59] [c14656cb] ? ttm_bo_release+0x0/0x65 [7.59] [c13bbda5] ? kref_put+0x39/0x42 [7.59] [c1464357] ? ttm_bo_unref+0x27/0x32 [7.59] [c148947f] ? radeon_bo_unref+0x1d/0x2d [7.59] [c1495fd6] ? radeon_ring_fini+0x55/0x74 [
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I've also added an oops fix I seem to lose off my radar to this tree. commit 17aafccab4352b422aa01fa6ebf82daff693a5b3 Author: Michel D??nzer daen...@vmware.com Date: Fri Jan 22 09:20:00 2010 +0100 drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure. Wierd this suggests something else is wrong on that machine can you get me the whole dmesg? I'm guessing some iommu or swiotlb issue. I've asked Jerome to fix the oops, but really anyone with an old .config won't get hit by this, and we've booted this on quite a lot of machines at this point. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Tue, Feb 2, 2010 at 6:35 PM, Dave Airlie airl...@gmail.com wrote: On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I've also added an oops fix I seem to lose off my radar to this tree. commit 17aafccab4352b422aa01fa6ebf82daff693a5b3 Author: Michel D??nzer daen...@vmware.com Date: Fri Jan 22 09:20:00 2010 +0100 drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure. Wierd this suggests something else is wrong on that machine can you get me the whole dmesg? I'm guessing some iommu or swiotlb issue. I've asked Jerome to fix the oops, but really anyone with an old .config won't get hit by this, and we've booted this on quite a lot of machines at this point. Ideas keep flooding in here, did you softboot from the old UMS driver? or coldboot? does coldbooting help? Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [crash, PATCH] Revert drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Wed, Feb 3, 2010 at 1:46 AM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@gmail.com wrote: On Tue, Feb 2, 2010 at 6:17 PM, Ingo Molnar mi...@elte.hu wrote: * Dave Airlie airl...@linux.ie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I've also added an oops fix I seem to lose off my radar to this tree. commit 17aafccab4352b422aa01fa6ebf82daff693a5b3 Author: Michel D??nzer daen...@vmware.com Date: ? Fri Jan 22 09:20:00 2010 +0100 ? ? drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure. Wierd this suggests something else is wrong on that machine can you get me the whole dmesg? I'm guessing some iommu or swiotlb issue. This box has no known hardware or software problems, just this week it booted in excess of 1000 kernels so i'd exclude that angle for now. I have bisected the crash back to the DRM tree and the crash went away with the Kconfig revert i applied - and it got fixed by Jerome's patch. I posted my config and i posted the relevant boot log as well. Find below the full bootlog as well with vanilla -git (ab65832) and the config. (i dont think it matters) I've asked Jerome to fix the oops, but really anyone with an old .config won't get hit by this, and we've booted this on quite a lot of machines at this point. I dont see the commit in yesterday's linux-next. It has very fresh timestamps: commit f71d0187987e691516cd10c2702f002c0e2f0edc Author: Dave Airlie airl...@redhat.com AuthorDate: Mon Feb 1 11:35:47 2010 +1000 Commit: Dave Airlie airl...@redhat.com CommitDate: Mon Feb 1 11:35:47 2010 +1000 What kind of widespread testing could this commit have gotten in the less than 24 hours before it hit mainline? Its shipping in a major distro by default, its planned to be shipped in an even more major distro. Its been boot tested on 1000s of machines by 1000s of ppl. Your bug isn't anything to do with this commit, its a completely separate issue, that nobody else has reported before now and Jerome has provided a patch for. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm: Add generic multipart buffer.
On Tue, Feb 2, 2010 at 3:11 AM, Pauli Nieminen suok...@gmail.com wrote:
Allocating multiple pages of memory for data that is coming
from user space may fail. To fix memory allocation failures
the buffer object should be split to multiple independ pages.
Just some quick comments
radeon_cs.c already has something similiar to this but non-generic. It only
uses two pages on the kernel side and does the copy from user as needed.
Its less generic as we need to also copy the data to UC memory.
Is this generic enough to be in the kernel proper? like flex_array? flex_buffer?
I'll review it further later.
Dave.
drm buffer provides generic interface to copy and process
large data arrays from user space.
Interface includes allocation and free functions to allocate
the buffer object and data storage pages.
All access operations are performed relative to a internal
pointer which is advanced with drm_buffer_advance function.
The buffer can be accessed using drm_buffer_pointer_to_XXX
functions if it is known that requested object doesn't split
over a page boundary. These functions don't do any error
checking to maximize performance.
If there is large object which could be split there is special
drm_buffer_read_object function. drm_buffer_read_object takes
a pointer as argument which is used as temporary store for
data if it is split over boundary in the buffer.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_buffer.c | 184
++
include/drm/drm_buffer.h | 148 +
3 files changed, 333 insertions(+), 1 deletions(-)
create mode 100644 drivers/gpu/drm/drm_buffer.c
create mode 100644 include/drm/drm_buffer.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 39c5aa7..abe3f44 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -4,7 +4,7 @@
ccflags-y := -Iinclude/drm
-drm-y := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y := drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \
drm_context.o drm_dma.o drm_drawable.o \
drm_drv.o drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_buffer.c b/drivers/gpu/drm/drm_buffer.c
new file mode 100644
index 000..55d03ed
--- /dev/null
+++ b/drivers/gpu/drm/drm_buffer.c
@@ -0,0 +1,184 @@
+/**
+ *
+ * Copyright 2010 Pauli Nieminen.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY
CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ *
+ **/
+/*
+ * Multipart buffer for coping data which is larger than the page size.
+ *
+ * Authors:
+ * Pauli Nieminen suokkos-at-gmail-dot-com
+ */
+
+#include drm_buffer.h
+
+/**
+ * Allocate the drm buffer object.
+ *
+ * buf: Pointer to a pointer where the object is stored.
+ * size: The number of bytes to allocate.
+ */
+int drm_buffer_alloc(struct drm_buffer **buf, int size)
+{
+ int nr_pages = size / PAGE_SIZE + 1;
+ int idx;
+
+ /* Allocating pointer table to end of structure makes drm_buffer
+ * variable sized */
+ *buf = kzalloc(sizeof(struct drm_buffer) + nr_pages*sizeof(char *),
+ GFP_KERNEL);
+
+ if (*buf == NULL) {
+ DRM_ERROR(Failed to allocate drm buffer object to hold
+ %d bytes in %d pages.\n,
+ size, nr_pages);
+ return -ENOMEM;
+ }
+
+ (*buf)-size = size;
+
+ for (idx = 0; idx nr_pages; ++idx) {
+
+ (*buf)-data[idx] =
+
Re: [PATCH] libdrm/radeon: Fix section size mismatch to reset the section.
On Tue, Feb 2, 2010 at 4:24 AM, Pauli Nieminen suok...@gmail.com wrote:
If there is section size mismatch reusing the section object
makes section start fail.
Reseting the object before doing error checking prevents the
possible flood of errors.
That can't be right. did you read what your patch does?
of course it'll never call the printf now.
Dave.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
radeon/radeon_cs_gem.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index c2301ad..9bfcda0 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -255,6 +255,7 @@ static int cs_gem_end(struct radeon_cs_int *cs,
file, func, line);
return -EPIPE;
}
+ cs-section_ndw = 0;
if (cs-section_ndw != cs-section_cdw) {
fprintf(stderr, CS section size missmatch start at (%s,%s,%d) %d vs
%d\n,
cs-section_file, cs-section_func, cs-section_line,
cs-section_ndw, cs-section_cdw);
@@ -262,7 +263,6 @@ static int cs_gem_end(struct radeon_cs_int *cs,
file, func, line);
return -EPIPE;
}
- cs-section_ndw = 0;
return 0;
}
--
1.6.3.3
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Only try to preserve caching in moves in the same space
On Thu, Jan 28, 2010 at 7:26 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Currently TTM tries to preserve the previous caching even for moves
between unrelated memory spaces.
This results for instance in moves from VRAM to PCIE GART changing
system memory to WC state needlessly.
This patch changes TTM to only try to preserve caching if moving from
system/TT to system/TT.
In theory, we should also do that if moving between two device memory
spaces that are backend by the same physical memory area.
However, I'm not sure how to do that in the current TTM framework and
I suspect no card/driver uses memory spaces in that way.
Thomas or Jerome (since I think placement changes were you), any
chance of ack or review?
Dave.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2920f9a..27ee1be 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -876,6 +876,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
mem-mm_node = NULL;
for (i = 0; i placement-num_placement; ++i) {
+ int is_tt_move;
ret = ttm_mem_type_from_flags(placement-placement[i],
mem_type);
if (ret)
@@ -891,8 +892,12 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (!type_ok)
continue;
- cur_flags = ttm_bo_select_caching(man, bo-mem.placement,
- cur_flags);
+ is_tt_move = !(man-flags TTM_MEMTYPE_FLAG_FIXED)
+ !(bdev-man[bo-mem.mem_type].flags
TTM_MEMTYPE_FLAG_FIXED);
+
+ /* Only try to keep the current flags if we are in the same
memory space */
+ cur_flags = ttm_bo_select_caching(man, is_tt_move ?
bo-mem.placement : 0, cur_flags);
+
/*
* Use the access and other non-mapping-related flag bits from
* the memory placement flags to the current flags
@@ -927,6 +932,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
return -EINVAL;
for (i = 0; i placement-num_busy_placement; ++i) {
+ int is_tt_move;
ret = ttm_mem_type_from_flags(placement-busy_placement[i],
mem_type);
if (ret)
@@ -941,8 +947,12 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
cur_flags))
continue;
- cur_flags = ttm_bo_select_caching(man, bo-mem.placement,
- cur_flags);
+ is_tt_move = !(man-flags TTM_MEMTYPE_FLAG_FIXED)
+ !(bdev-man[bo-mem.mem_type].flags
TTM_MEMTYPE_FLAG_FIXED);
+
+ /* Only try to keep the current flags if we are in the same
memory space */
+ cur_flags = ttm_bo_select_caching(man, is_tt_move ?
bo-mem.placement : 0, cur_flags);
+
/*
* Use the access and other non-mapping-related flag bits from
* the memory placement flags to the current flags
--
1.6.6.1.476.g01ddb
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Major change is to move the radeon KMS enable out of staging and into normal Kconfig land, its not perfect but its as good as userspace was for most people. others: drm core: just a bogus comment removal ttm: a few changes one fixes an error printf in reserve_ram_pages_type, radeon: Displayport fixes, tested on all the displayport machines I own (i.e. 2) but they both now work, r600 blit mutex, AGP warning fix. vmwgfx: 3 patches for older version of vmware workstation, I think vmware have one more patch but since this driver is staging it can wait until merge window anyways. Dave. drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/radeon/atombios_dp.c | 27 ++--- drivers/gpu/drm/radeon/r600.c| 54 +- drivers/gpu/drm/radeon/r600_blit_kms.c |7 +- drivers/gpu/drm/radeon/radeon.h |1 + drivers/gpu/drm/radeon/radeon_agp.c | 18 ++-- drivers/gpu/drm/radeon/radeon_encoders.c | 165 - drivers/gpu/drm/radeon/radeon_mode.h |2 +- drivers/gpu/drm/radeon/rv770.c | 31 +++--- drivers/gpu/drm/ttm/ttm_bo_util.c|9 +-- drivers/gpu/drm/ttm/ttm_object.c |2 +- drivers/gpu/drm/ttm/ttm_tt.c | 23 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |3 + drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 19 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 ++ drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++- drivers/staging/Kconfig |2 - include/drm/drm_mode.h |2 +- 20 files changed, 244 insertions(+), 164 deletions(-) commit f71d0187987e691516cd10c2702f002c0e2f0edc Author: Dave Airlie airl...@redhat.com Date: Mon Feb 1 11:35:47 2010 +1000 drm/radeon/kms: move radeon KMS on/off switch out of staging. We are happy enough that the KMS driver is stable enough for enough people for the kms enable/disable to leave staging. Distros can now contemplate turning this on. Signed-off-by: Dave Airlie airl...@redhat.com commit ff82f052d2a187dd0fa0e431ba70eb457c71a40e Author: Jerome Glisse jgli...@redhat.com Date: Fri Jan 22 15:19:00 2010 +0100 drm/radeon/kms: Bailout of blit if error happen protect with mutex V3 If an error happen in r600_blit_prepare_copy report it rather than WARNING and keeping execution. For instance if ib allocation failed we did just warn about but then latter tried to access NULL ib ptr causing oops. This patch also protect r600_copy_blit with a mutex as otherwise one process might overwrite blit temporary data with new one possibly leading to GPU lockup. Should partialy or totaly fix: https://bugzilla.redhat.com/show_bug.cgi?id=553279 V2 failing blit initialization is not fatal, fallback to memcpy when this happen V3 init blit before startup as we pin in startup, remove duplicate code (this one was actualy tested unlike V2) Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit 5ffdb658f605cbc420944e7c7eeec9fbb8a73772 Author: Jakob Bornecrantz ja...@vmware.com Date: Sat Jan 30 03:38:08 2010 + drm/vmwgfx: Don't send bad flags to the host Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit c188660f6dbb0df9febe1b841a16c66c28353c15 Author: Peter Hanzel hanzelpe...@gmail.com Date: Sat Jan 30 03:38:07 2010 + drm/vmwgfx: Request SVGA version 2 and bail if not found This fixes the driver not loading on older versions of VMware. Signed-off-by: Peter Hanzel hanzelpe...@gmail.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit 8e19a951774a16cf2626292ae06fd2b62630e67e Author: Jakob Bornecrantz ja...@vmware.com Date: Sat Jan 30 03:38:06 2010 + drm/vmwgfx: Correctly detect 3D Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit 110b20c3ddcfa98cc932aef3af2d59b4e0841f08 Author: Austin Yuan shengquan.y...@gmail.com Date: Thu Jan 21 13:45:40 2010 +0800 drm/ttm: remove unnecessary save_flags and ttm_flag_masked in ttm_bo_util.c Signed-off-by: Austin Yuan shengquan.y...@gmail.com Acked-by: Thomas Hellstrom thellst...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit fa5829b36539067f3c675f5d437531dedcfc4ad8 Author: Marcin Kościelnicki koria...@0x04.net Date: Sat Jan 23 10:25:28 2010 +1000 drm/kms: Remove incorrect comment in struct drm_mode_modeinfo Signed-off-by: Dave Airlie airl...@redhat.com commit
Re: [git pull] drm fixes
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I've also added an oops fix I seem to lose off my radar to this tree. commit 17aafccab4352b422aa01fa6ebf82daff693a5b3 Author: Michel Dänzer daen...@vmware.com Date: Fri Jan 22 09:20:00 2010 +0100 drm/radeon/kms: Fix oops after radeon_cs_parser_init() failure. If radeon_cs_parser_init() fails, radeon_cs_ioctl() calls radeon_cs_parser_fini() with the non-zero error value. The latter dereferenc parser-ib which hasn't been initialized yet - boom. Add a test for parser- being non-NULL before dereferencing it. Signed-off-by: Michel Dänzer daen...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com Major change is to move the radeon KMS enable out of staging and into normal Kconfig land, its not perfect but its as good as userspace was for most people. others: drm core: just a bogus comment removal ttm: a few changes one fixes an error printf in reserve_ram_pages_type, radeon: Displayport fixes, tested on all the displayport machines I own (i.e. 2) but they both now work, r600 blit mutex, AGP warning fix. vmwgfx: 3 patches for older version of vmware workstation, I think vmware have one more patch but since this driver is staging it can wait until merge window anyways. Dave. drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/radeon/atombios_dp.c | 27 ++--- drivers/gpu/drm/radeon/r600.c| 54 +- drivers/gpu/drm/radeon/r600_blit_kms.c |7 +- drivers/gpu/drm/radeon/radeon.h |1 + drivers/gpu/drm/radeon/radeon_agp.c | 18 ++-- drivers/gpu/drm/radeon/radeon_encoders.c | 165 - drivers/gpu/drm/radeon/radeon_mode.h |2 +- drivers/gpu/drm/radeon/rv770.c | 31 +++--- drivers/gpu/drm/ttm/ttm_bo_util.c|9 +-- drivers/gpu/drm/ttm/ttm_object.c |2 +- drivers/gpu/drm/ttm/ttm_tt.c | 23 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |3 + drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 19 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c|2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 10 ++ drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +++- drivers/staging/Kconfig |2 - include/drm/drm_mode.h |2 +- 20 files changed, 244 insertions(+), 164 deletions(-) commit f71d0187987e691516cd10c2702f002c0e2f0edc Author: Dave Airlie airl...@redhat.com Date: Mon Feb 1 11:35:47 2010 +1000 drm/radeon/kms: move radeon KMS on/off switch out of staging. We are happy enough that the KMS driver is stable enough for enough people for the kms enable/disable to leave staging. Distros can now contemplate turning this on. Signed-off-by: Dave Airlie airl...@redhat.com commit ff82f052d2a187dd0fa0e431ba70eb457c71a40e Author: Jerome Glisse jgli...@redhat.com Date: Fri Jan 22 15:19:00 2010 +0100 drm/radeon/kms: Bailout of blit if error happen protect with mutex V3 If an error happen in r600_blit_prepare_copy report it rather than WARNING and keeping execution. For instance if ib allocation failed we did just warn about but then latter tried to access NULL ib ptr causing oops. This patch also protect r600_copy_blit with a mutex as otherwise one process might overwrite blit temporary data with new one possibly leading to GPU lockup. Should partialy or totaly fix: https://bugzilla.redhat.com/show_bug.cgi?id=553279 V2 failing blit initialization is not fatal, fallback to memcpy when this happen V3 init blit before startup as we pin in startup, remove duplicate code (this one was actualy tested unlike V2) Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit 5ffdb658f605cbc420944e7c7eeec9fbb8a73772 Author: Jakob Bornecrantz ja...@vmware.com Date: Sat Jan 30 03:38:08 2010 + drm/vmwgfx: Don't send bad flags to the host Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit c188660f6dbb0df9febe1b841a16c66c28353c15 Author: Peter Hanzel hanzelpe...@gmail.com Date: Sat Jan 30 03:38:07 2010 + drm/vmwgfx: Request SVGA version 2 and bail if not found This fixes the driver not loading on older versions of VMware. Signed-off-by: Peter Hanzel hanzelpe...@gmail.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit 8e19a951774a16cf2626292ae06fd2b62630e67e Author: Jakob Bornecrantz ja...@vmware.com Date: Sat Jan 30 03:38:06 2010 + drm/vmwgfx: Correctly detect 3D Signed-off
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/24 Rafał Miłecki zaj...@gmail.com: I applied patches from http://www.botchco.com/alex/xorg/pm/ and now engine reclocks between 110MHz and 680MHz. The problem is I see ~10 black horizontal lines for a one frame time on almost every reclock. I tried to fix this or at least understand it somehow but without success. 1) Putting 500ms delay after every reclock doesn't improve anything 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve 3) Calling atombios_crtc_set_pll after reclocking doesn't improve 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve I tested 4th as SetEngineClock seems to play mostly with 0x0180 and ClockSource seems to be the only reading that register. Effects were horrible, don't ever call this AtomBIOS cammand ;) Do you have any other ideas? On top of whats in drm-radeon-testing this avoids reclocking artifacts on my rv530 laptop, I timed the atom calls and they were taking 20ms which is waaay too long, I decoded the tables and it looks like they use udelays. Though I suspect if we want to reclock other things like memory we need to do it across a few frames instead of all in one vblank. Dave. 0001-drm-radeon-kms-use-udelay-for-short-delays.patch Description: Binary data -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/kms/radeon: pick digitial encoders smarter. (v2)
From: Dave Airlie airl...@redhat.com
booting a Lenovo W500 with LVDS + DP outputs showed up a TODO we had
on our list, to pick a correct digital encoder block. The LVTMA
encoder requires the second digital encoder, all others can use any
encoder at all.
This fixes the digital encoder selection logic to enable LVDS/DP combos
to work okay.
V2: fix silly addition of connector dig_block and cleanup the other
places in the code that pick the encoder.
TODO: test on W500 hw.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_encoders.c | 147 --
1 files changed, 80 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 18decfa..a639caa 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -156,6 +156,26 @@ radeon_get_encoder_id(struct drm_device *dev, uint32_t
supported_device, uint8_t
return ret;
}
+static inline bool radeon_encoder_is_digital(struct drm_encoder *encoder)
+{
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ switch (radeon_encoder-encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+ case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+ case ENCODER_OBJECT_ID_INTERNAL_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_DDI:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ return true;
+ default:
+ return false;
+ }
+}
void
radeon_link_encoder_connector(struct drm_device *dev)
{
@@ -679,31 +699,11 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder,
int action)
memset(args, 0, sizeof(args));
- if (ASIC_IS_DCE32(rdev)) {
- if (dig-dig_block)
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- else
- index = GetIndexIntoMasterTable(COMMAND,
DIG1EncoderControl);
- num = dig-dig_block + 1;
- } else {
- switch (radeon_encoder-encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- /* XXX doesn't really matter which dig encoder we pick
as long as it's
-* not already in use
-*/
- if (dig_connector-linkb)
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- else
- index = GetIndexIntoMasterTable(COMMAND,
DIG1EncoderControl);
- num = 1;
- break;
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- /* Only dig2 encoder can drive LVTMA */
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- num = 2;
- break;
- }
- }
+ if (dig-dig_block)
+ index = GetIndexIntoMasterTable(COMMAND, DIG2EncoderControl);
+ else
+ index = GetIndexIntoMasterTable(COMMAND, DIG1EncoderControl);
+ num = dig-dig_block + 1;
atom_parse_cmd_header(rdev-mode_info.atom_context, index, frev,
crev);
@@ -852,17 +852,16 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
args.v2.acConfig.fCoherentMode = 1;
}
} else {
+
args.v1.ucConfig = ATOM_TRANSMITTER_CONFIG_CLKSRC_PPLL;
+ if (dig-dig_block)
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
+ else
+ args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
+
switch (radeon_encoder-encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- /* XXX doesn't really matter which dig encoder we pick
as long as it's
-* not already in use
-*/
- if (dig_connector-linkb)
- args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
- else
- args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
if (rdev-flags RADEON_IS_IGP) {
if (radeon_encoder-pixel_clock 165000) {
if (dig_connector-igp_lane_info 0x3)
@@ -881,10 +880,6 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
[PATCH] drm/radeon/kms: fix incorrect logic in DP vs eDP connector checking.
From: Dave Airlie airl...@redhat.com This makes displayport work again here. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/atombios_dp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c index 3eb0ca5..9c023d2 100644 --- a/drivers/gpu/drm/radeon/atombios_dp.c +++ b/drivers/gpu/drm/radeon/atombios_dp.c @@ -468,7 +468,7 @@ void radeon_dp_set_link_config(struct drm_connector *connector, struct radeon_connector *radeon_connector; struct radeon_connector_atom_dig *dig_connector; - if ((connector-connector_type != DRM_MODE_CONNECTOR_DisplayPort) || + if ((connector-connector_type != DRM_MODE_CONNECTOR_DisplayPort) (connector-connector_type != DRM_MODE_CONNECTOR_eDP)) return; @@ -583,7 +583,7 @@ void dp_link_train(struct drm_encoder *encoder, u8 train_set[4]; int i; - if ((connector-connector_type != DRM_MODE_CONNECTOR_DisplayPort) || + if ((connector-connector_type != DRM_MODE_CONNECTOR_DisplayPort) (connector-connector_type != DRM_MODE_CONNECTOR_eDP)) return; -- 1.6.5.2 -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: use active device to pick connector for encoder
From: Dave Airlie airl...@linux.ie
On the W500 we have UNIPHY routed to both DVI and DP, this seems
to always pick the DVI connector which means link training fails.
Switch to using active device to pick the connector, this seems
like it should be safe from a code review, and it fixes things
a bit more here.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_encoders.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 82eb551..10746c9 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -202,7 +202,7 @@ radeon_get_connector_for_encoder(struct drm_encoder
*encoder)
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
radeon_connector = to_radeon_connector(connector);
- if (radeon_encoder-devices radeon_connector-devices)
+ if (radeon_encoder-active_device radeon_connector-devices)
return connector;
}
return NULL;
--
1.6.5.2
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/kms/radeon: pick digitial encoders smarter. (v3)
From: Dave Airlie airl...@redhat.com
booting a Lenovo W500 with LVDS + DP outputs showed up a TODO we had
on our list, to pick a correct digital encoder block. The LVTMA
encoder requires the second digital encoder, all others can use any
encoder at all.
This fixes the digital encoder selection logic to enable LVDS/DP combos
to work okay.
V2: fix silly addition of connector dig_block and cleanup the other
places in the code that pick the encoder.
V3: rename to dig_encoder and clean up further - also fix
the picking algorithm.
tested on Lenovo W500 + desktop 3650 cards.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/atombios_dp.c | 23 ++---
drivers/gpu/drm/radeon/radeon_encoders.c | 163 -
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
3 files changed, 99 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 9c023d2..7106011 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -596,21 +596,14 @@ void dp_link_train(struct drm_encoder *encoder,
return;
dig_connector = radeon_connector-con_priv;
- if (ASIC_IS_DCE32(rdev)) {
- if (dig-dig_block)
- enc_id |= ATOM_DP_CONFIG_DIG2_ENCODER;
- else
- enc_id |= ATOM_DP_CONFIG_DIG1_ENCODER;
- if (dig_connector-linkb)
- enc_id |= ATOM_DP_CONFIG_LINK_B;
- else
- enc_id |= ATOM_DP_CONFIG_LINK_A;
- } else {
- if (dig_connector-linkb)
- enc_id |= ATOM_DP_CONFIG_DIG2_ENCODER |
ATOM_DP_CONFIG_LINK_B;
- else
- enc_id |= ATOM_DP_CONFIG_DIG1_ENCODER |
ATOM_DP_CONFIG_LINK_A;
- }
+ if (dig-dig_encoder)
+ enc_id |= ATOM_DP_CONFIG_DIG2_ENCODER;
+ else
+ enc_id |= ATOM_DP_CONFIG_DIG1_ENCODER;
+ if (dig_connector-linkb)
+ enc_id |= ATOM_DP_CONFIG_LINK_B;
+ else
+ enc_id |= ATOM_DP_CONFIG_LINK_A;
memset(link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
if (dig_connector-dp_clock == 27)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 10746c9..f4b2f99 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -156,6 +156,26 @@ radeon_get_encoder_id(struct drm_device *dev, uint32_t
supported_device, uint8_t
return ret;
}
+static inline bool radeon_encoder_is_digital(struct drm_encoder *encoder)
+{
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ switch (radeon_encoder-encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+ case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+ case ENCODER_OBJECT_ID_INTERNAL_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_DDI:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ return true;
+ default:
+ return false;
+ }
+}
void
radeon_link_encoder_connector(struct drm_device *dev)
{
@@ -676,31 +696,11 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder,
int action)
memset(args, 0, sizeof(args));
- if (ASIC_IS_DCE32(rdev)) {
- if (dig-dig_block)
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- else
- index = GetIndexIntoMasterTable(COMMAND,
DIG1EncoderControl);
- num = dig-dig_block + 1;
- } else {
- switch (radeon_encoder-encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- /* XXX doesn't really matter which dig encoder we pick
as long as it's
-* not already in use
-*/
- if (dig_connector-linkb)
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- else
- index = GetIndexIntoMasterTable(COMMAND,
DIG1EncoderControl);
- num = 1;
- break;
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- /* Only dig2 encoder can drive LVTMA */
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- num = 2;
- break;
- }
- }
+ if (dig-dig_encoder)
+ index = GetIndexIntoMasterTable(COMMAND
Re: [PATCH] drm: Add a generic function to change connector type/id of connector dynamically
On Wed, 2010-01-27 at 15:16 +0800, yakui.z...@intel.com wrote: From: Zhao Yakui yakui.z...@intel.com Sometimes one connector can support more than one connector type. And it will switch the connector type/id dynamically according to the external connected device. Connectors cannot change they physical plugs that users plug stuff into. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Add a generic function to change connector type/id of connector dynamically
Only one plug is used for this encoder. But it can be detected as different type when the different adaptor is used. For one multi-function SDVO card, it can be detected as LVDS, VGA, SDVO-TV(composite/S-video). Before the external device is connected, we can't know the exact connector type. What I want is to report the correct type according to the external connected device. When the user changes the external connected device, we can reflect their changes. Just report the plug. We don't change the DVI connector to VGA when you plug in a DVI-VGA convertor its the physical thing the user sees on their machine we want to call it. Dave. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/kms/radeon: pick digitial encoders smarter.
From: Dave Airlie airl...@redhat.com
booting a Lenovo W500 with LVDS + DP outputs showed up a TODO we had
on our list, to pick a correct digital encoder block. The LVTMA
encoder requires the second digital encoder, all others can use any
encoder at all.
This fixes the digital encoder selection logic to enable LVDS/DP combos
to work okay.
TODO:
test on W500 hw.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_encoders.c | 103 --
drivers/gpu/drm/radeon/radeon_mode.h |1 +
2 files changed, 70 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 18decfa..9074ad9 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -156,6 +156,26 @@ radeon_get_encoder_id(struct drm_device *dev, uint32_t
supported_device, uint8_t
return ret;
}
+static inline bool radeon_encoder_is_digital(struct drm_encoder *encoder)
+{
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ switch (radeon_encoder-encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_LVDS:
+ case ENCODER_OBJECT_ID_INTERNAL_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+ case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+ case ENCODER_OBJECT_ID_INTERNAL_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1:
+ case ENCODER_OBJECT_ID_INTERNAL_DDI:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
+ case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
+ return true;
+ default:
+ return false;
+ }
+}
void
radeon_link_encoder_connector(struct drm_device *dev)
{
@@ -679,31 +699,11 @@ atombios_dig_encoder_setup(struct drm_encoder *encoder,
int action)
memset(args, 0, sizeof(args));
- if (ASIC_IS_DCE32(rdev)) {
- if (dig-dig_block)
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- else
- index = GetIndexIntoMasterTable(COMMAND,
DIG1EncoderControl);
- num = dig-dig_block + 1;
- } else {
- switch (radeon_encoder-encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- /* XXX doesn't really matter which dig encoder we pick
as long as it's
-* not already in use
-*/
- if (dig_connector-linkb)
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- else
- index = GetIndexIntoMasterTable(COMMAND,
DIG1EncoderControl);
- num = 1;
- break;
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- /* Only dig2 encoder can drive LVTMA */
- index = GetIndexIntoMasterTable(COMMAND,
DIG2EncoderControl);
- num = 2;
- break;
- }
- }
+ if (dig-dig_block)
+ index = GetIndexIntoMasterTable(COMMAND, DIG2EncoderControl);
+ else
+ index = GetIndexIntoMasterTable(COMMAND, DIG1EncoderControl);
+ num = dig-dig_block + 1;
atom_parse_cmd_header(rdev-mode_info.atom_context, index, frev,
crev);
@@ -856,10 +856,7 @@ atombios_dig_transmitter_setup(struct drm_encoder
*encoder, int action, uint8_t
switch (radeon_encoder-encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- /* XXX doesn't really matter which dig encoder we pick
as long as it's
-* not already in use
-*/
- if (dig_connector-linkb)
+ if (dig_connector-dig_block)
args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG2_ENCODER;
else
args.v1.ucConfig |=
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
@@ -1133,10 +1130,7 @@ atombios_set_encoder_crtc_source(struct drm_encoder
*encoder)
return;
dig_connector =
radeon_connector-con_priv;
- /* XXX doesn't really matter which dig
encoder we pick as long as it's
-* not already in use
-*/
- if (dig_connector-linkb)
+ if (dig_connector-dig_block)
args.v2.ucEncoderID =
ASIC_INT_DIG2_ENCODER_ID;
else
Re: [PATCH] drm/radeon/kms: Bailout of blit if error happen protect with mutex V2
On Sat, Jan 23, 2010 at 1:56 AM, Jerome Glisse jgli...@redhat.com wrote: If an error happen in r600_blit_prepare_copy report it rather than WARNING and keeping execution. For instance if ib allocation failed we did just warn about but then latter tried to access NULL ib ptr causing oops. This patch also protect r600_copy_blit with a mutex as otherwise one process might overwrite blit temporary data with new one possibly leading to GPU lockup. Did you boot this to X on any relevant hw? it totally fails to start gdm here on my r600 card. I'm assuming because you now never pin the shader object at all from what I can see, since _startup gets called before blit_init. Please no more crap like this unless you are doing serious boot testing on it. radeon_bo_unref(rdev-r600_blit.shader_obj); + rdev-r600_blit.shader_obj = NULL; } And WTF? ^^^ you wrote radeon_bo_unref you should know what it does. Dave. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: fix regression in fb blank handling
On Thu, 2010-01-21 at 09:09 +0800, Zhenyu Wang wrote: On 2010.01.20 13:14:23 +, James Simmons wrote: It's just adding the backlight api to the intel driver. In fact it gives the user the ablity to control the brightness of the backlight which I see is lacking in the intel driver. Wait, this regression has nothing to do with backlight control. We already have backlight drivers for platform specific or ACPI interface, the reason intel driver doesn't hook up one is because if we provide native interface which would be much possible to have state conflict with platform or ACPI way. This problem is just the wrong DPMS state is used for FB blank request. Dave, does my patch look sane? This regression isn't in 2.6.32, but only for .33-rc kernel. We should revisit this for 2.6.34, but for now I've applied Zhenyu's patch until we can figure out where the problems are, as it breaks a few too many laptops at this stage for 2.6.33. Dave. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes queue
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus I was out last week for sick kid + LCA dash so stuff queued up behind me, I've booted this across a few radeons. core drm changes: one EDID parser fix - one slighty controversial revert a previous fix for FB blanking although correct, uncovered other bugs in Intel/radeon KMS drivers, so until fixes for them are available revert the part of the change the broke stuff. nouveau: upstream fixes from F12 testing. radeon: fixes all over the place from F12 bugs and upstream AMD changes. DVI-DP convertors work again IRQ fixes that fix kexec regression atombios parser updates from AMD should fix s/r bugs on newer cards minor r100/r200 command stream parser fixes Possible r600 local priv escalation fix, the r600 could be used to access system memory if someone was (a) really sneaky, (b) had a lot of time, however the commit msg covers it all. TTM: fix race condition in object deletion handling vmware/staging: bunch of fixes from VMware for the staging driver Dave. drivers/gpu/drm/drm_edid.c |3 +- drivers/gpu/drm/drm_fb_helper.c |2 +- drivers/gpu/drm/nouveau/nouveau_bios.c | 187 --- drivers/gpu/drm/nouveau/nouveau_bo.c|2 + drivers/gpu/drm/nouveau/nouveau_connector.c | 31 +++- drivers/gpu/drm/nouveau/nouveau_dma.c | 76 +--- drivers/gpu/drm/nouveau/nouveau_dp.c|8 +- drivers/gpu/drm/nouveau/nouveau_drv.c |4 + drivers/gpu/drm/nouveau/nouveau_drv.h |3 + drivers/gpu/drm/nouveau/nouveau_gem.c | 20 ++- drivers/gpu/drm/nouveau/nouveau_irq.c |7 + drivers/gpu/drm/nouveau/nouveau_mem.c | 15 ++- drivers/gpu/drm/nouveau/nouveau_state.c |1 + drivers/gpu/drm/nouveau/nv04_instmem.c |2 +- drivers/gpu/drm/nouveau/nv50_crtc.c | 22 +++- drivers/gpu/drm/nouveau/nv50_fifo.c |2 +- drivers/gpu/drm/nouveau/nv50_graph.c|3 +- drivers/gpu/drm/nouveau/nv50_sor.c | 13 ++ drivers/gpu/drm/radeon/atom.c | 102 +-- drivers/gpu/drm/radeon/atom.h |1 + drivers/gpu/drm/radeon/atombios_crtc.c | 259 +- drivers/gpu/drm/radeon/r100.c |5 +- drivers/gpu/drm/radeon/r200.c |7 +- drivers/gpu/drm/radeon/r420.c |4 +- drivers/gpu/drm/radeon/r600.c | 82 + drivers/gpu/drm/radeon/r600_blit_kms.c | 14 +- drivers/gpu/drm/radeon/r600_cs.c| 83 + drivers/gpu/drm/radeon/r600d.h | 25 +++ drivers/gpu/drm/radeon/radeon.h | 11 +- drivers/gpu/drm/radeon/radeon_agp.c |7 + drivers/gpu/drm/radeon/radeon_clocks.c |4 +- drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_device.c |1 + drivers/gpu/drm/radeon/radeon_display.c | 45 +++-- drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 77 +--- drivers/gpu/drm/radeon/radeon_mode.h| 28 ++- drivers/gpu/drm/radeon/radeon_object.c |3 +- drivers/gpu/drm/radeon/reg_srcs/r200|2 + drivers/gpu/drm/radeon/rv770.c | 33 ++-- drivers/gpu/drm/ttm/ttm_bo.c| 69 drivers/gpu/drm/ttm/ttm_lock.c |2 + drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 25 +++- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 63 +++- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |4 + drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 19 ++ drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |8 - drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|3 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |9 - drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 64 --- include/drm/ttm/ttm_bo_driver.h |5 + 51 files changed, 958 insertions(+), 520 deletions(-) commit 7087e16286913b41ba9a5186360645b57b8508dd Author: Dave Airlie airl...@redhat.com Date: Mon Jan 25 16:13:55 2010 +1000 drm/radeon/kms: preface warning printk with driver name This just adds a little more info to the warning for old -ati/mesa userspaces. Signed-off-by: Dave Airlie airl...@redhat.com commit f2ab3a13d2cbe19426c27c35a014c98212e914a5 Author: Dave Airlie airl...@redhat.com Date: Mon Jan 25 16:13:12 2010 +1000 drm/radeon/kms: drop unnecessary printks. These printks aren't required anymore. Signed-off-by: Dave Airlie airl...@redhat.com commit 5fd4df4d475a7fee96fff54f6341192f547984e0 Author: Zhenyu Wang zhen...@linux.intel.com Date: Mon Jan 18 16:47:04 2010 +0800 drm: fix regression in fb blank handling commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e Author: James Simmons
[PATCH] drm/radeon/kms: fix displayport-dvi connector DDC.
From: Dave Airlie airl...@redhat.com
It appears that attempting AUXCH DDC breaks the subsequent attempt
to do DDC over the i2c lines, so use the sink type to determine
if we should be doing AUXCH or i2c DDC.
This fixes my DVI monitor plugged into DP-DVI convertor.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_display.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 0ec491e..47ceae9 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -357,7 +357,8 @@ int radeon_ddc_get_modes(struct radeon_connector
*radeon_connector)
if ((radeon_connector-base.connector_type ==
DRM_MODE_CONNECTOR_DisplayPort) ||
(radeon_connector-base.connector_type == DRM_MODE_CONNECTOR_eDP)) {
struct radeon_connector_atom_dig *dig =
radeon_connector-con_priv;
- if (dig-dp_i2c_bus)
+ if ((dig-dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT ||
+dig-dp_sink_type == CONNECTOR_OBJECT_ID_eDP)
dig-dp_i2c_bus)
radeon_connector-edid =
drm_get_edid(radeon_connector-base, dig-dp_i2c_bus-adapter);
}
if (!radeon_connector-ddc_bus)
--
1.6.5.2
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: only evict to GTT if CP is ready
From: Dave Airlie airl...@redhat.com
Testing GTT ready might be more correct but cp.ready
works fine and has been tested on irc by 2-3 ppl.
fixes bug k.org 15035 and fd.o 25733
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/radeon_ttm.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a004507..db820ae 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -215,7 +215,10 @@ static void radeon_evict_flags(struct ttm_buffer_object
*bo,
rbo = container_of(bo, struct radeon_bo, tbo);
switch (bo-mem.mem_type) {
case TTM_PL_VRAM:
- radeon_ttm_placement_from_domain(rbo, RADEON_GEM_DOMAIN_GTT);
+ if (rbo-rdev-cp.ready == false)
+ radeon_ttm_placement_from_domain(rbo,
RADEON_GEM_DOMAIN_CPU);
+ else
+ radeon_ttm_placement_from_domain(rbo,
RADEON_GEM_DOMAIN_GTT);
break;
case TTM_PL_TT:
default:
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus Small set of fixes, one brown paper bagger where I switched from warn to printk but lost the conditional, dropped the mode set msg which spams on intel a lot, and some random radeon kms fixes one for a s/r regression. Dave. drivers/gpu/drm/drm_crtc_helper.c |5 +++-- drivers/gpu/drm/radeon/r600.c |8 drivers/gpu/drm/radeon/radeon_combios.c |3 +++ drivers/gpu/drm/radeon/radeon_connectors.c |8 drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 21 - drivers/gpu/drm/radeon/radeon_ttm.c |5 - 6 files changed, 42 insertions(+), 8 deletions(-) commit 194fda0dd83623f7927d505e39008c73fbc1c141 Merge: ef14587 9270eb1 Author: Dave Airlie airl...@redhat.com Date: Wed Jan 13 16:17:38 2010 +1000 Merge remote branch 'korg/drm-radeon-next' into drm-linus * korg/drm-radeon-next drm/radeon/kms: only evict to GTT if CP is ready drm/radeon/kms: Fix crash getting TV info with no BIOS. drm/radeon/kms/rv100: reject modes 135 Mhz on DVI (v2) drm/radeon/kms/r6xx+: make irq handler less verbose drm/radeon/kms: fix up LVDS handling on macs (v2) commit ef14587706521287f1c7ea3326e732f7d86dd096 Author: Dave Young hidave.darks...@gmail.com Date: Wed Jan 13 13:38:59 2010 +0800 drm: change drm set mode messages as DRM_DEBUG Following drm info repeat 207 times during one hour, it's quite annoying [ 1266.286747] [drm] TV-19: set mode NTSC 480i 0 Change from DRM_INFO to DRM_DEBUG Signed-off-by: Dave Young hidave.darks...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 70a94d6a35072b62f808155f117f00485a395f03 Author: Dave Airlie airl...@redhat.com Date: Wed Jan 13 16:15:11 2010 +1000 drm: fix crtc no modes printf + typo Toralf Förster pointed out the typo, the fact I forget the if statement is purely personal fail. Signed-off-by: Dave Airlie airl...@redhat.com commit 9270eb1b496cb002d75f49ef82c9ef4cbd22a5a0 Author: Dave Airlie airl...@redhat.com Date: Wed Jan 13 09:21:49 2010 +1000 drm/radeon/kms: only evict to GTT if CP is ready Testing GTT ready might be more correct but cp.ready works fine and has been tested on irc by 2-3 ppl. fixes bug k.org 15035 and fd.o 25733 Signed-off-by: Dave Airlie airl...@redhat.com commit 11f3b59e3654c66c4e8ef2c48f8138b78bf440da Author: Michel Dänzer daen...@vmware.com Date: Mon Jan 11 08:58:38 2010 +0100 drm/radeon/kms: Fix crash getting TV info with no BIOS. Signed-off-by: Michel Dänzer daen...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit 1b24203e51072b6e76aff8c74bdd67eb3b34a724 Author: Alex Deucher alexdeuc...@gmail.com Date: Mon Jan 11 15:02:31 2010 -0500 drm/radeon/kms/rv100: reject modes 135 Mhz on DVI (v2) Due to heat issues. Fixes fdo bug 25992 v2: fix typo noticed by Maarten Maathuis Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit b042589ca038e647fa1e2bb4e7ac3963688479b8 Author: Alex Deucher alexdeuc...@gmail.com Date: Mon Jan 11 19:47:38 2010 -0500 drm/radeon/kms/r6xx+: make irq handler less verbose Unhandled vectors can be safely ignored, no need to spam the kernel log by default. Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 3890ddf56dbc0f804953198e65a7e406ed654576 Author: Alex Deucher alexdeuc...@gmail.com Date: Tue Jan 12 11:16:57 2010 -0500 drm/radeon/kms: fix up LVDS handling on macs (v2) Based on radeonfb code and recent ddx fix. v2: minor formatting fix from Michel Dänzer Signed-off-by: Alex Deucher alexdeuc...@gmail.com Reviewed-by: Michel Dänzer mic...@daenzer.net Tested-by: Michel Dänzer mic...@daenzer.net Signed-off-by: Dave Airlie airl...@redhat.com-- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Tue, Jan 12, 2010 at 2:38 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Sun, 10 Jan 2010 07:32:30 +1000 Dave Airlie airl...@gmail.com wrote: I'm in the 2-3 years at a minimum, with at least one kernel with no serious regressions in Intel KMS, which we haven't gotten close to yet. I'm not even sure the Intel guys are taking stable seriously enough yet. So far I don't think there is one kernel release (even stable) that works on all Intel chipsets without backporting patches. 2.6.32 needs the changes to remove the messed up render clock hacks which should really have been reverted a lot earlier since we had a lot of regression reports. The number of users using powersave=0 to get anything approaching useable is growing etc. But you could apply that argument to the existing DRM code (not just Intel) as well; lots of things are broken or unimplemented and never get fixed. I'd say the right metric isn't whether regressions are introduced (usually due to new features) but whether the driver is better than the old userspace code. For Intel at least, I think we're already there. The quality of the kernel driver is higher and it has many more features than the userspace implementation ever did. That's just my subjective opinion, but I've done a *lot* of work on our bugs both in userspace and in the kernel, so I think it's an accurate statement. The problem is at any single point in time I'm not sure a kms kernel exists that works across all the Intel hw, which from a distro POV is a real pain in the ass, a regression gets fixed on one piece of hw just as another on a different piece gets introduced. I'd really like if Intel devs could either slow it down and do more testing before pushing to Linus, or be a lot quicker with the reverts when stuff is identified. The main thing is the render reclocking lately, thats been a nightmare and as far as I can see 2.6.32.3 still has all the issues, It doesn't have to happen anytime soon, I was just thinking that removing the old, pre-KMS code would make it easier to avoid introducing regressions since we'd have one less config (a bit one atthat) to worry about. Maybe in 3-4 years. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Tue, Jan 12, 2010 at 8:22 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Monday 11 January 2010, Julien Cristau wrote: On Mon, Jan 11, 2010 at 22:04:36 +0100, Rafael J. Wysocki wrote: Hmm, are you trying to say radeon is better at that? My experience is quite the opposite to be honest. radeon kms is in staging, doesn't pretend to be stable and force all users to the experimental paths. So yes, I would say radeon is better at that. I guess I should have been more precise. All of my test boxes with ATI/AMD graphics hardware regressed after upgrading from openSUSE 11.1 to openSUSE 11.2, in different ways, because of the user space part of the radeon driver. Of course, you can argue that the dristro picked up particularly bad release of the driver, but from the user's point of view it actually doesn't matter whether the breakage is in the kernel part or in the user space part of the driver. The difference is, however, that the breakage in the kernel is fixed _way_ faster than the breakage in the user space, so I very much prefer the Intel people pushing new features aggressively and fixing bugs related to that, then the situation where I need to deal with the broken user space driver, while the KMS radeon is still not reliable enough. IOW, if your user space driver worked 100% of the time, I'd totally agree, but that's not the case, at least as far as I see it. Are you using the Novell radeonhd driver? (I think SuSE default to this for all cards r500). This isn't the driver that is developed by the opensource community and really your distro is where you complain about that sort of regression. The wierd thing is we see distro picking up fixes for userspace drivers *much* quicker if their teams are the on the ball since they are only a small component to upgrade, with the kernel you find most distro fire and forget, so if 2.6.31 doesn't work on your hw you'll wait 6 months to find out that 2.634 doesn't work either. Since ppl aren't targetting stable properly distros are left to fend for themselves when it comes to backporting large amounts of changes, and you find most distros just don't bother. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains 3 trees: core: two KMS fixes, one for a regression I found with Fedora's plymouth on my r100 laptop with an 8-bpp console, the other for unwanted outputs lighting up on resume. radeon kms: a regression fix since we added host data flushing support some users reported r300s dying under load, this change fixes that, along with better s/r support for gpus with sideport RAM, along with eDP support (needed for new imacs to display anything). Also we sync'ed the whitespace in ObjectID.h with all the other copies to make syncing them with AMD's master copy easier, its not kernel compliant but it is a lot easier to work with for AMD. nouveau: scattering of fixes from the nouveau upstream tree. Dave. drivers/gpu/drm/drm_crtc.c |1 + drivers/gpu/drm/drm_crtc_helper.c | 26 +- drivers/gpu/drm/drm_fb_helper.c|9 +- drivers/gpu/drm/drm_irq.c |5 +- drivers/gpu/drm/nouveau/Kconfig|5 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 243 ++--- drivers/gpu/drm/nouveau/nouveau_channel.c | 47 +-- drivers/gpu/drm/nouveau/nouveau_dma.c | 34 +- drivers/gpu/drm/nouveau/nouveau_dma.h | 10 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 72 ++- drivers/gpu/drm/nouveau/nouveau_fbcon.c| 19 +- drivers/gpu/drm/nouveau/nouveau_fbcon.h|1 + drivers/gpu/drm/nouveau/nouveau_fence.c|2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 33 +- drivers/gpu/drm/nouveau/nouveau_irq.c |1 + drivers/gpu/drm/nouveau/nouveau_mem.c | 87 +++ drivers/gpu/drm/nouveau/nouveau_object.c |2 +- drivers/gpu/drm/nouveau/nouveau_reg.h | 16 +- drivers/gpu/drm/nouveau/nouveau_state.c| 27 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 30 +- drivers/gpu/drm/nouveau/nv04_dac.c | 35 +- drivers/gpu/drm/nouveau/nv04_fbcon.c | 41 +- drivers/gpu/drm/nouveau/nv04_fifo.c| 34 ++ drivers/gpu/drm/nouveau/nv04_graph.c | 159 +++--- drivers/gpu/drm/nouveau/nv10_fb.c | 32 +- drivers/gpu/drm/nouveau/nv10_graph.c | 28 +- drivers/gpu/drm/nouveau/nv17_tv.c | 115 - drivers/gpu/drm/nouveau/nv20_graph.c | 61 +-- drivers/gpu/drm/nouveau/nv40_fb.c | 53 ++- drivers/gpu/drm/nouveau/nv40_graph.c | 116 ++--- drivers/gpu/drm/nouveau/nv50_display.c | 17 + drivers/gpu/drm/nouveau/nv50_fbcon.c | 23 +- drivers/gpu/drm/nouveau/nv50_fifo.c|6 +- drivers/gpu/drm/radeon/Makefile|5 + drivers/gpu/drm/radeon/ObjectID.h | 801 +++- drivers/gpu/drm/radeon/atombios_dp.c |6 +- drivers/gpu/drm/radeon/mkregtable.c|4 +- drivers/gpu/drm/radeon/r100.c | 23 +- drivers/gpu/drm/radeon/r300.c | 17 +- drivers/gpu/drm/radeon/r420.c | 41 ++- drivers/gpu/drm/radeon/r520.c |1 + drivers/gpu/drm/radeon/r600.c | 21 +- drivers/gpu/drm/radeon/r600_blit_kms.c |4 +- drivers/gpu/drm/radeon/radeon.h|9 +- drivers/gpu/drm/radeon/radeon_agp.c|6 +- drivers/gpu/drm/radeon/radeon_asic.h | 12 - drivers/gpu/drm/radeon/radeon_atombios.c | 41 ++- drivers/gpu/drm/radeon/radeon_combios.c| 14 + drivers/gpu/drm/radeon/radeon_connectors.c | 23 +- drivers/gpu/drm/radeon/radeon_display.c|7 +- drivers/gpu/drm/radeon/radeon_encoders.c | 14 +- drivers/gpu/drm/radeon/radeon_gem.c|2 - drivers/gpu/drm/radeon/radeon_irq_kms.c| 10 +- drivers/gpu/drm/radeon/radeon_legacy_tv.c | 14 +- drivers/gpu/drm/radeon/radeon_mode.h | 26 - drivers/gpu/drm/radeon/radeon_object.c |5 +- drivers/gpu/drm/radeon/reg_srcs/r420 | 795 +++ drivers/gpu/drm/radeon/reg_srcs/rs600 | 68 +++- drivers/gpu/drm/radeon/reg_srcs/rv515 |6 + drivers/gpu/drm/radeon/rs400.c |2 + drivers/gpu/drm/radeon/rs600.c | 10 +- drivers/gpu/drm/radeon/rs690.c |2 + drivers/gpu/drm/radeon/rv515.c |1 + drivers/gpu/drm/radeon/rv770.c |3 +- include/drm/drm_mode.h |1 + 65 files changed, 2411 insertions(+), 973 deletions(-) create mode 100644 drivers/gpu/drm/radeon/reg_srcs/r420 commit f22d6ddaeb8126623d62c828a4d4a96dfc4cbc5c Merge: 0c9d2c4 40c2298 Author: Dave Airlie airl...@redhat.com Date: Mon Jan 11 14:43:16 2010 +1000 Merge branch 'for-airlied' of /ssd/git/drm-nouveau-next into drm-linus * 'for-airlied' of /ssd/git/drm-nouveau-next: (28 commits) drm/nv04: Fix set_operation software method. drm/nouveau: initialise DMA tracking parameters earlier drm/nouveau: use dma.max rather than pushbuf size
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Sun, Jan 10, 2010 at 4:17 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Sat, 9 Jan 2010, Jerome Glisse wrote: On Fri, Jan 08, 2010 at 06:50:41PM -0800, Jesse Barnes wrote: Linus, can we ever drop those old paths? Maybe after the new bits have been around for awhile? Users of really old userspace stacks would lose 3D support, but they'd still have 2D, so it wouldn't be a complete break. The non-KMS paths sometimes break like this anyway without us noticing (especially some of the weirder 3D paths)... Just thinking out loud, we could really kill a lot of really bad code... I among those who would love such things to happen :) I don't want to drop it _yet_, but ever? Sure. When people are sure that KMS actually handles all the cases that old X does (maybe that's true now), and we've had more than just a couple of kernel releases of _stable_ Intel KMS, I suspect we can start thinking about ok, nobody seriously uses 3D on Intel integrated graphics _and_ updates the kernel. The fact that they'd still have a working X setup would make it generally much more palatable, I think. But we definitely need more than just a couple of kernel releases. So we're talking timescales of more than a year of stable code. Whether that is six months from now or two years from now, I can't judge. And people can try to convince me to be more or less aggressive about it, so take the above as a more of a personal opinion that is open to change than anything definite and final. I'm in the 2-3 years at a minimum, with at least one kernel with no serious regressions in Intel KMS, which we haven't gotten close to yet. I'm not even sure the Intel guys are taking stable seriously enough yet. So far I don't think there is one kernel release (even stable) that works on all Intel chipsets without backporting patches. 2.6.32 needs the changes to remove the messed up render clock hacks which should really have been reverted a lot earlier since we had a lot of regression reports. The number of users using powersave=0 to get anything approaching useable is growing etc. We do have ppl who run latest kernels on RHEL5 userspace and I'd rather not have that break badly, I'm guessing more than 3D will break if we remove this, since we need the DRM to allocate memory for 2D stuff, and will probably find the fallback to AGP is broken. Again Intel ppl would have to do a lot of testing on the fallback before removing anything, which is time I don't see anyone willing to spend. Dave. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: Always register as a PCI driver (was: Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS)
On Sat, Jan 9, 2010 at 11:35 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Saturday 09 January 2010, Jesse Barnes wrote: On Fri, 8 Jan 2010 16:50:57 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Sat, 9 Jan 2010, Rafael J. Wysocki wrote: Which is functionally equivalent to my patch, because i915_suspend/resume() won't be called by drm_class_suspend/resume() in the KMS case anyway. Ahh, right you are - that class suspend function does a check for DRIVER_MODESET, and only does the suspend/resume if it's not a MODESET driver. Ok, so I withdraw my objections to your original patch - it's confusing, but that's just because DRM is such a horrible mess with subtle things. Yeah the non-KMS paths just suck. Acked-by: Jesse Barnes jbar...@virtuousgeek.org Though hopefully you can get the PCI driver registration working w/o too much trouble; that would be even better. Actually, I have a working patch, with one tiny detail I'm not sure of. Namely, I need to call pci_set_drvdata(pdev, dev) unconditionally in drm_stub.c for the things to work, but I _think_ it won't hurt even if we're not going to use the pdev's private data. The benefit of this is having just one code path for suspend/resume instead of two different code paths depending on whether the driver is using the KMS or not, which is well worth it IMO. The patch is appended. NAK for the reasons I explained in the previous email. This conflicts with systems where intelfb and intel drm are used together, this is something that ppl do use prior to KMS happening. We just need to document in the headers why the hooks are needed, and maybe a bit of patch review to make sure nobody removes them again. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
From: Rafael J. Wysocki r...@sisk.pl Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement new pm ops for i915), among other things, removed the .suspend and .resume pointers from the struct drm_driver object in i915_drv.c, which broke resume without KMS on my MSI Wind U100. Fix this by reverting that part of commit cbda12d77ea59. Hmm. I get the feeling that perhaps the of the drm_driver callbacks was very muchintentional, and that the code presumably wants to be called purely through the PCI layer, and not through the drm class logic at all? Your patch seems like it would always execute the silly class suspend even though we explicitly don't want to. And a much nicer fix would seem to register the thing properly as a PCI driver even if you don't then use KMS. So it looks to me like the problem is that drm_init() will register the driver as a real PCI driver only if driver-driver_features DRIVER_MODESET and otherwise it does that very odd stealth mode manual scanning thing which doesn't register it as a proper PCI driver. So could we instead make that disable KSM _just_ disable the mode setting part, not disable the I'm a real driver part? This was mainly due to pre-existing fb drivers binding to the device, and the drm drivers having to work around that, with KMS since we have fb in the drm driver its correct to bind, pre-kms its just a mess I'd rather stay away from. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/kms/fb: check for depth changes from userspace for resizing.
From: Dave Airlie airl...@redhat.com
If userspace (plymouth in this case) asks for a deeper depth,
refuse it as well due to lack of resizing.
This fixes an issue since 32MB cards went to 8bpp and plymouth
crashes on startup.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fb_helper.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1b49fa0..c9fa8d7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -606,11 +606,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
/* Need to resize the fb object !!! */
- if (var-xres fb-width || var-yres fb-height) {
- DRM_ERROR(Requested width/height is greater than current fb
- object %dx%d %dx%d\n, var-xres, var-yres,
- fb-width, fb-height);
- DRM_ERROR(Need resizing code.\n);
+ if (var-bits_per_pixel fb-bits_per_pixel || var-xres fb-width
|| var-yres fb-height) {
+ DRM_DEBUG(fb userspace requested width/height/bpp is greater
than current fb
+ object %dx%d-%d %dx%d-%d\n, var-xres, var-yres,
var-bits_per_pixel,
+ fb-width, fb-height, fb-bits_per_pixel);
return -EINVAL;
}
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/r100.c: check for invalid family
On Wed, Dec 30, 2009 at 11:24 AM, Darren Jenkins
darrenrjenk...@gmail.com wrote:
If there is an invalid family the fw_name is NULL and causes an
NULL pointer dereference.
This just adds a check for something unexpected.
NAK.
This can't happen, only gpus with those families set can call this function,
so we can't get in here without the correct family, and if we did it would be
due to developer error, so oopsing is very appropriate.
Dave.
Coverity CID: 13251
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/r100.c drivers/gpu/drm/radeon/r100.c
index 7172746..e4b9770 100644
--- drivers/gpu/drm/radeon/r100.c
+++ drivers/gpu/drm/radeon/r100.c
@@ -584,6 +584,8 @@ static int r100_cp_init_microcode(struct radeon_device
*rdev)
(rdev-family == CHIP_RV570)) {
DRM_INFO(Loading R500 Microcode\n);
fw_name = FIRMWARE_R520;
+ } else {
+ return -EINVAL;
}
err = request_firmware(rdev-me_fw, fw_name, pdev-dev);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/radeon_cp.c: fix resource leak on error
On Wed, Dec 30, 2009 at 11:25 AM, Darren Jenkins darrenrjenk...@gmail.com wrote: If drm_addmap() fails master_priv is leaked. I got a patch from Roel Kluin to fix this already, will push it out soon. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/radeon_cp.c: check for invalid radeon family
On Wed, Dec 30, 2009 at 11:23 AM, Darren Jenkins darrenrjenk...@gmail.com wrote: If there is an invalid radeon family the fw_name is NULL and causes an NULL pointer dereference. This just adds a check for something unexpected. Same as for last one, unless a developer explicity writes code wrong, this cannot happen, and I'd prefer a developer would see an oops. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix a couple of array index errors
On Wed, Dec 30, 2009 at 11:21 AM, Darren Jenkins
darrenrjenk...@gmail.com wrote:
There are a couple of array overruns, and some associated confusion in
the code.
This is just a wild guess at what the code should actually look like.
Alex can you take a look at this, though I suspect its mostly stuff
that is wrong in the GATOS
code in userspace as well.
Might need to fix it there as well, the ARRAY_SIZE change is sane, the
flicker removal
is plausible, the array sizings also totally wierd.
Dave.
Coverity CID: 13305 13306
Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com
diff --git drivers/gpu/drm/radeon/radeon_legacy_tv.c
drivers/gpu/drm/radeon/radeon_legacy_tv.c
index 3a12bb0..c37535a 100644
--- drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -112,6 +112,8 @@ static const uint16_t vert_timing_NTSC[] = {
0x1817,
0x21d4,
0x0002,
+ 0x,
+ 0x,
0
};
@@ -623,9 +625,9 @@ void radeon_legacy_tv_mode_set(struct drm_encoder
*encoder,
}
flicker_removal = (tmp + 500) / 1000;
- if (flicker_removal 3)
- flicker_removal = 3;
- for (i = 0; i 6; ++i) {
+ if (flicker_removal 2)
+ flicker_removal = 2;
+ for (i = 0; i ARRAY_SIZE(SLOPE_limit); ++i) {
if (flicker_removal == SLOPE_limit[i])
break;
}
diff --git drivers/gpu/drm/radeon/radeon_mode.h
drivers/gpu/drm/radeon/radeon_mode.h
index 402369d..abee9a9 100644
--- drivers/gpu/drm/radeon/radeon_mode.h
+++ drivers/gpu/drm/radeon/radeon_mode.h
@@ -218,8 +218,8 @@ struct radeon_mode_info {
};
-#define MAX_H_CODE_TIMING_LEN 32
-#define MAX_V_CODE_TIMING_LEN 32
+#define MAX_H_CODE_TIMING_LEN 16
+#define MAX_V_CODE_TIMING_LEN 16
/* need to store these as reading
back code tables is excessive */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains some EDID parser fixups, a patch to make the drm_pci_alloc sane (follow up from Eric to fix Intel driver bug that required this fix), along with some kernel bug fixes for radeon kms and some coverity fixes. Dave. drivers/gpu/drm/ati_pcigart.c | 10 - drivers/gpu/drm/drm_bufs.c |4 +- drivers/gpu/drm/drm_edid.c | 14 +--- drivers/gpu/drm/drm_fb_helper.c|2 +- drivers/gpu/drm/drm_pci.c |8 + drivers/gpu/drm/i915/i915_dma.c|2 +- drivers/gpu/drm/i915/i915_gem.c|2 +- drivers/gpu/drm/radeon/radeon_atombios.c |2 + drivers/gpu/drm/radeon/radeon_combios.c| 50 +++- drivers/gpu/drm/radeon/radeon_connectors.c |2 +- drivers/gpu/drm/radeon/radeon_cp.c |1 + drivers/gpu/drm/radeon/radeon_device.c |6 ++- drivers/gpu/drm/radeon/radeon_display.c|5 ++- drivers/gpu/drm/radeon/radeon_fence.c |9 ++--- drivers/gpu/drm/radeon/radeon_irq.c| 10 +++--- drivers/gpu/drm/radeon/rs600.c |2 +- include/drm/drmP.h |2 +- 17 files changed, 87 insertions(+), 44 deletions(-) commit a81406b4143ff07e586bbe03c50f089da94eefe1 Merge: 90520b7 43b19f1 Author: Dave Airlie airl...@redhat.com Date: Thu Jan 7 14:00:29 2010 +1000 Merge remote branch 'korg/drm-radeon-next' into drm-linus * korg/drm-radeon-next: drm/radeon/kms: rs600: use correct mask for SW interrupt gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test drm/radeon/radeon_device.c: move a dereference below a NULL test drm/radeon/radeon_fence.c: move a dereference below the NULL test drm/radeon/radeon_connectors.c: add a NULL test before dereference drm/radeon/kms: fix memory leak drm/radeon/kms: add missing breaks in i2c and ss lookups drm/radeon/kms: add primary dac adj values table drm/radeon/kms: fallback to default connector table commit 43b19f161c7a9941e3aa7db0e3ee19b93980e3d7 Author: Luca Tettamanti kronos...@gmail.com Date: Mon Dec 28 22:53:05 2009 +0100 drm/radeon/kms: rs600: use correct mask for SW interrupt The mask happens to be the same, but the IH is reading the status, not the not the control register. Signed-off-by: Luca Tettamanti kronos...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 65aa2f4e8d85b6145ef4834f440a63ab68bd7443 Author: Darren Jenkins darrenrjenk...@gmail.com Date: Wed Dec 30 12:16:35 2009 +1100 gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13338 Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 875c186620e017e62b773c93e46af21bb704fe6b Author: Darren Jenkins darrenrjenk...@gmail.com Date: Wed Dec 30 12:18:30 2009 +1100 drm/radeon/radeon_device.c: move a dereference below a NULL test If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13335 Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 3655d54af8dd85788c3e5088387469703a0f8f12 Author: Darren Jenkins darrenrjenk...@gmail.com Date: Wed Dec 30 12:20:05 2009 +1100 drm/radeon/radeon_fence.c: move a dereference below the NULL test If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13334 Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit d8a7f79246a447722bd90c2c4ba3ca068b2aa4c0 Author: Darren Jenkins darrenrjenk...@gmail.com Date: Wed Dec 30 12:22:55 2009 +1100 drm/radeon/radeon_connectors.c: add a NULL test before dereference The encoder variable can be NULL in this function so I believe it should be checked before dereference. Coverity CID: 13253 [airlied: extremely unlikely to happen] Signed-off-by: Darren Jenkins darrenrjenk...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 5eb226132f53d5ec36ce4e7ff9d6b49cceb50f3d Author: Jiri Slaby jsl...@suse.cz Date: Wed Jan 6 17:39:31 2010 +0100 drm/radeon/kms: fix memory leak Stanse found a memory leak in radeon_master_create. master_priv is not freed/assigned on all paths. Fix that. Signed-off-by: Jiri Slaby jsl...@suse.cz Signed-off-by: Dave Airlie airl...@redhat.com commit 90520b78a4f8ba1faef75961eddd8192077e0ac2 Merge: d94a510 e89a8c9 Author: Dave Airlie airl...@redhat.com Date: Thu Jan 7 13:36:00 2010 +1000
[PATCH] drm/radeon/kms: detect sideport enabled on rs690/740/780/880.
From: Dave Airlie airl...@redhat.com
This detects if the sideport memory is enabled on these IGPs, and if
it is VRAM is evicted on suspend/resume.
This should fix s/r issues on some IGPs.
TODO:
check rs880 is same as rs780
add rs480 support if possible.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r600.c |7 +++
drivers/gpu/drm/radeon/r600d.h |3 +++
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_object.c |6 --
drivers/gpu/drm/radeon/rs690.c |5 +
drivers/gpu/drm/radeon/rs690d.h|2 ++
6 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 5c6058c..35ff64b 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -726,6 +726,13 @@ int r600_mc_init(struct radeon_device *rdev)
a.full = rfixed_const(100);
rdev-pm.sclk.full = rfixed_const(rdev-clock.default_sclk);
rdev-pm.sclk.full = rfixed_div(rdev-pm.sclk, a);
+
+ if ((rdev-family == CHIP_RS780) ||
+ (rdev-family == CHIP_RS880)) {
+ tmp = RREG32_MC(R_12_MC_MISC_UMA_CNTL);
+ if (G_12_MC_SIDE_PORT_PRESENT(tmp))
+ rdev-mc.igp_sideport_enabled = true;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index 05894ed..8020a98 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -882,4 +882,7 @@
#defineS_000E60_SOFT_RESET_VMC(x) (((x) 1)
17)
#define R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL 0x5480
+
+#define R_12_MC_MISC_UMA_CNTL 0x12
+#define G_12_MC_SIDE_PORT_PRESENT(x) (((x) 31) 0x1)
#endif
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 53b5560..0b00b41 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -319,6 +319,7 @@ struct radeon_mc {
u64 real_vram_size;
int vram_mtrr;
boolvram_is_ddr;
+ booligp_sideport_enabled;
};
int radeon_mc_setup(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d9ffe1f..1c70d95 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -221,8 +221,10 @@ int radeon_bo_unpin(struct radeon_bo *bo)
int radeon_bo_evict_vram(struct radeon_device *rdev)
{
if (rdev-flags RADEON_IS_IGP) {
- /* Useless to evict on IGP chips */
- return 0;
+ if (rdev-mc.igp_sideport_enabled == false)
+ /* Useless to evict on IGP chips
+ unless sideport is in use */
+ return 0;
}
return ttm_bo_evict_mm(rdev-mman.bdev, TTM_PL_VRAM);
}
diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
index 1e22f52..74cc57c 100644
--- a/drivers/gpu/drm/radeon/rs690.c
+++ b/drivers/gpu/drm/radeon/rs690.c
@@ -132,6 +132,7 @@ void rs690_pm_info(struct radeon_device *rdev)
void rs690_vram_info(struct radeon_device *rdev)
{
fixed20_12 a;
+ u32 tmp;
rs400_gart_adjust_size(rdev);
@@ -160,6 +161,10 @@ void rs690_vram_info(struct radeon_device *rdev)
a.full = rfixed_const(16);
/* core_bandwidth = sclk(Mhz) * 16 */
rdev-pm.core_bandwidth.full = rfixed_div(rdev-pm.sclk, a);
+
+ tmp = RREG32_MC(R_5F_MC_MISC_UMA_CNTL);
+ if (G_5F_MC_SIDE_PORT_PRESENT(tmp))
+ rdev-mc.igp_sideport_enabled = true;
}
static int rs690_mc_init(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rs690d.h b/drivers/gpu/drm/radeon/rs690d.h
index 62d31e7..e74071e 100644
--- a/drivers/gpu/drm/radeon/rs690d.h
+++ b/drivers/gpu/drm/radeon/rs690d.h
@@ -233,6 +233,8 @@
#define G_006D58_LB_D2_MAX_REQ_OUTSTANDING(x)(((x) 16) 0xF)
#define C_006D58_LB_D2_MAX_REQ_OUTSTANDING 0xFFF0
+#define R_5F_MC_MISC_UMA_CNTL0x5F
+#define G_5F_MC_SIDE_PORT_PRESENT(x) (((x) 31) 0x1)
#define R_90_MC_SYSTEM_STATUS0x90
#define S_90_MC_SYSTEM_IDLE(x) (((x) 0x1) 0)
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel
Re: Recommendations for distributions?
We want to ship packages with all new features wherever possible. But
we have to make sure, that at least 2D is always working and 3D should
be stable and fast. We know we will often run into bugs first but our
community likes it - see us as a big testing group for you :)
Unless you have a large amount of time of ppl with experience of graphics
I'd recommned the following (below)..
That's why we ask for your recommendations what is already usable and
worth packing.
1) kernel drm modules:
Is it enough to ship the latest stable kernel? Or do you recommend
drm-next or any other branch replacing the the default kernel modules
in /lib/modules/${_kernver}/updates/ ? We are thinking about such
additional packages we can update more often if needed (we did so in
the past for nouveau-drm).
Do you recommend to enable kms now by default for all chips?
Ship Linus kernel, when things leave staging, you can generally turn them
on, not before unless you can provide the support to users and upstream
feedback cycles for bugs. Its worse for us when ppl have a load of binary
packages that the distro has just picked in the middle of a dev cycle and
never upgrade. We generally provide experimental features so we can get
feedback and debug them, shipping these without a supporting person in the
distro keeping the feedback cycle alive is actually a drain on our end. We
get bug reports for sutff 2-3 mths after we've fixed it because of some
distros.
2) libdrm
What configuration is recommended? Is enable eperimental api code
needed and recommended for for certain chips?
Same, leave it alone, --enable-udev is probably all oyu want.
3) mesa
Do you still recommend 7.6.1? When will it make sense to package 7.7?
When Xorg 1.8 is out or when will the driver make use of 7.7 features?
7.7 is out, probably best to ship it now. since it contains all 7.6.1
fixes
4) Driver packages should be announced clearly on what they depend.
Maybe better or more clear branching is needed.
Generally if there is experimental APIs then you need to do the research
with normal packages on a Linux distro, the latest released everything
should be the best option.
Dave.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm-linus
/radeon_legacy_encoders.c |2 + drivers/gpu/drm/radeon/radeon_mode.h|6 + drivers/gpu/drm/radeon/radeon_test.c|4 +- drivers/gpu/drm/radeon/radeon_ttm.c |4 + drivers/gpu/drm/savage/savage_drv.c |2 +- drivers/gpu/drm/sis/sis_drv.c |2 +- drivers/gpu/drm/tdfx/tdfx_drv.c |2 +- drivers/gpu/drm/via/via_drv.c |2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 47 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 157 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|6 +- drivers/gpu/drm/vmwgfx/vmwgfx_irq.c |6 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |8 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 149 +++--- include/drm/drmP.h |5 +- 83 files changed, 2502 insertions(+), 1066 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nouveau_grctx.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_grctx.h create mode 100644 drivers/gpu/drm/nouveau/nv40_grctx.c commit d94a5108f716bbd524358eb5a440d63991744a62 Merge: 44f9e6c 0786201 Author: Dave Airlie airl...@redhat.com Date: Wed Dec 23 11:18:33 2009 +1000 Merge remote branch 'korg/drm-radeon-next' into drm-linus * korg/drm-radeon-next: drm/radeon/kms: add definitions for v4 power tables drm/radeon/kms: never combine LVDS with another encoder drm/radeon/kms: Check module arguments to be valid V2 drm/radeon/kms: Avoid crash when trying to cleanup uninitialized structure drm/radeon/kms: add cvt mode if we only have lvds w/h and no edid (v4) drm/radeon/kms: add 3DC compression support drm/radeon/kms: allow rendering while no colorbuffer is set on r300 drm/radeon/kms: enable memory clock reading on legacy (V2) drm/radeon/kms: prevent parallel AtomBIOS calls drm/radeon/kms: set proper default tv standard drm/radeon/kms: fix legacy rmx drm/radeon/kms/atom: fill in proper defines for digital setup commit 0786201d8cd0730e72b0e087484dd47cc5f58409 Author: Alex Deucher alexdeuc...@gmail.com Date: Sat Dec 19 12:45:12 2009 -0500 drm/radeon/kms: add definitions for v4 power tables [airlied: just adding this for completeness to avoid drift between public atombios.h files] Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit f56cd64f5f713a3013c4d980a5695c198d839671 Author: Alex Deucher alexdeuc...@gmail.com Date: Fri Dec 18 11:28:22 2009 -0500 drm/radeon/kms: never combine LVDS with another encoder When linking multiple encoders to a connector, make sure to not link LVDS with another connector. Some bioses have the same i2c line for LVDS and VGA. Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 3642133816f9f25065e3ca310f0720574bcdcc52 Author: Jerome Glisse jgli...@redhat.com Date: Fri Dec 11 21:18:34 2009 +0100 drm/radeon/kms: Check module arguments to be valid V2 This patch add a function which check module argument to be valid. On invalid argument it prints a warning and setback the default value. V2: Allow 0 for vram limit agp mode which are the default value Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit 0a0c7596c643239e8d4c3eaaba43b74a96f2411e Author: Jerome Glisse jgli...@redhat.com Date: Fri Dec 11 20:36:19 2009 +0100 drm/radeon/kms: Avoid crash when trying to cleanup uninitialized structure Add boolean to record if some part of the driver are initialized or not this allow to avoid a crash when trying to cleanup uninitialized structure members. Signed-off-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Dave Airlie airl...@redhat.com commit d2efdf6d6f425950a61fa5cc3aa22e6718e7f3c8 Author: Alex Deucher alexdeuc...@gmail.com Date: Tue Dec 22 10:06:49 2009 -0500 drm/radeon/kms: add cvt mode if we only have lvds w/h and no edid (v4) This fixes LVDS on some mac laptops without a panel edid. v2 - Set proper mode type flags v3 - Note that this is not neceesarily the exact panel mode, but an approximation based on the cvt formula. For these systems we should ideally read the mode info out of the registers or add a mode table, but this works and is much simpler. v4 - Update comments and debug message. Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit 512889f450c1851d9e3628f1894b9b64b0701eac Author: Marek Olšák mar...@gmail.com Date: Sat Dec 19 00:23:00 2009 +0100 drm/radeon/kms: add 3DC compression support There are 2 formats: ATI1N: 64 bits per 4x4 block, one
Re: [patch 2/2] drm: fix build error in include/drm/ttm/ttm_memory.h
On Tue, Dec 22, 2009 at 10:21 AM, a...@linux-foundation.org wrote: From: Ralf Baechle r...@linux-mips.org include/drm/ttm/ttm_memory.h uses struct page * without having included the required headers or a forward declaration resulting in the following build error for mtx1_defconfig on Linus' master branch, possibly others: This should already be fixed upstream we added an include instead of forward decl. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm unlocked ioctl + vmwgfx fix.
I've reworked Arnd's two patches to we have all the core changes in one patch, this in theory should change no behaviour in any of the current drivers. Patch 2: updates the vmwgfx unlocked ioctl code, to use the new interface as this work conflicts with its current interface. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/3] drm/vmwgfx: fixup unlocked ioctl code on top of Arnd's work.
From: Dave Airlie airl...@redhat.com
For some reason these ioctls have no DRM flags, which just seems wrong,
so I guess that needs reviewing also before staging exit.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 69 ---
1 files changed, 16 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 7b48bb3..8da66d8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -103,37 +103,37 @@
*/
static struct drm_ioctl_desc vmw_ioctls[] = {
- VMW_IOCTL_DEF(DRM_IOCTL_VMW_GET_PARAM, vmw_getparam_ioctl, 0),
+ VMW_IOCTL_DEF(DRM_IOCTL_VMW_GET_PARAM, vmw_getparam_ioctl,
DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_ALLOC_DMABUF, vmw_dmabuf_alloc_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_DMABUF, vmw_dmabuf_unref_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CURSOR_BYPASS,
- vmw_kms_cursor_bypass_ioctl, 0),
+ vmw_kms_cursor_bypass_ioctl, DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CONTROL_STREAM, vmw_overlay_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CLAIM_STREAM, vmw_stream_claim_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_STREAM, vmw_stream_unref_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CREATE_CONTEXT, vmw_context_define_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_CONTEXT, vmw_context_destroy_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_CREATE_SURFACE, vmw_surface_define_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_UNREF_SURFACE, vmw_surface_destroy_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_REF_SURFACE, vmw_surface_reference_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_EXECBUF, vmw_execbuf_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_FIFO_DEBUG, vmw_fifo_debug_ioctl,
- 0),
+ DRM_AUTH|DRM_UNLOCKED),
VMW_IOCTL_DEF(DRM_IOCTL_VMW_FENCE_WAIT, vmw_fence_wait_ioctl,
- 0)
+ DRM_AUTH|DRM_UNLOCKED)
};
static struct pci_device_id vmw_pci_id_list[] = {
@@ -454,43 +454,6 @@ out_no_tfile:
return ret;
}
-static long vmw_unlocked_ioctl(struct file *filp, unsigned int cmd,
- unsigned long arg)
-{
- struct drm_file *file_priv = filp-private_data;
- struct drm_device *dev = file_priv-minor-dev;
- unsigned int nr = DRM_IOCTL_NR(cmd);
- long ret;
-
- /*
-* The driver private ioctls and TTM ioctls should be
-* thread-safe.
-*/
-
- if ((nr = DRM_COMMAND_BASE) (nr DRM_COMMAND_END)
-(nr DRM_COMMAND_BASE + dev-driver-num_ioctls)) {
- struct drm_ioctl_desc *ioctl =
- vmw_ioctls[nr - DRM_COMMAND_BASE];
-
- if (unlikely(ioctl-cmd != cmd)) {
- DRM_ERROR(Invalid command format, ioctl %d\n,
- nr - DRM_COMMAND_BASE);
- return -EINVAL;
- }
- return drm_ioctl(filp-f_path.dentry-d_inode,
-filp, cmd, arg);
- }
-
- /*
-* Not all old drm ioctls are thread-safe.
-*/
-
- lock_kernel();
- ret = drm_ioctl(filp-f_path.dentry-d_inode, filp, cmd, arg);
- unlock_kernel();
- return ret;
-}
-
static int vmw_firstopen(struct drm_device *dev)
{
struct vmw_private *dev_priv = vmw_priv(dev);
@@ -686,7 +649,7 @@ static struct drm_driver driver = {
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
-.unlocked_ioctl = vmw_unlocked_ioctl,
+.unlocked_ioctl = drm_ioctl,
.mmap = vmw_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join
[PATCH 1/3] drm: convert drm_ioctl to unlocked_ioctl
From: Arnd Bergmann a...@arndb.de
drm_ioctl is called with the Big Kernel Lock held,
which shows up very high in statistics on vfs_ioctl.
Moving the lock into the drm_ioctl function itself
makes sure we blame the right subsystem and it gets
us one step closer to eliminating the locked version
of fops-ioctl.
Since drm_ioctl does not require the lock itself,
we only need to hold it while calling the specific
handler. The 32 bit conversion handlers do not
interact with any other code, so they don't need
the BKL here either and can just call drm_ioctl.
As a bonus, this cleans up all the other users
of drm_ioctl which now no longer have to find
the inode or call lock_kernel.
[airlied: squashed the non-driver bits
of the second patch in here, this provides
the flag for drivers to use to select unlocked
ioctls - but doesn't modify any drivers].
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.sourceforge.net
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_drv.c | 13 -
drivers/gpu/drm/drm_ioc32.c | 89 ++
drivers/gpu/drm/i810/i810_dma.c |2 +-
drivers/gpu/drm/i810/i810_drv.c |2 +-
drivers/gpu/drm/i830/i830_dma.c |2 +-
drivers/gpu/drm/i830/i830_drv.c |2 +-
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/i915_ioc32.c | 23 -
drivers/gpu/drm/mga/mga_drv.c |2 +-
drivers/gpu/drm/mga/mga_ioc32.c | 13 ++---
drivers/gpu/drm/nouveau/nouveau_drv.c |2 +-
drivers/gpu/drm/nouveau/nouveau_ioc32.c |4 +-
drivers/gpu/drm/r128/r128_drv.c |2 +-
drivers/gpu/drm/r128/r128_ioc32.c | 16 ++
drivers/gpu/drm/radeon/radeon_drv.c |4 +-
drivers/gpu/drm/radeon/radeon_ioc32.c | 38 -
drivers/gpu/drm/savage/savage_drv.c |2 +-
drivers/gpu/drm/sis/sis_drv.c |2 +-
drivers/gpu/drm/tdfx/tdfx_drv.c |2 +-
drivers/gpu/drm/via/via_drv.c |2 +-
include/drm/drmP.h |5 +-
21 files changed, 89 insertions(+), 140 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index ff2f104..766c468 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -434,11 +434,11 @@ static int drm_version(struct drm_device *dev, void *data,
* Looks up the ioctl function in the ::ioctls table, checking for root
* previleges if so required, and dispatches to the respective function.
*/
-int drm_ioctl(struct inode *inode, struct file *filp,
+long drm_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp-private_data;
- struct drm_device *dev = file_priv-minor-dev;
+ struct drm_device *dev;
struct drm_ioctl_desc *ioctl;
drm_ioctl_t *func;
unsigned int nr = DRM_IOCTL_NR(cmd);
@@ -446,6 +446,7 @@ int drm_ioctl(struct inode *inode, struct file *filp,
char stack_kdata[128];
char *kdata = NULL;
+ dev = file_priv-minor-dev;
atomic_inc(dev-ioctl_count);
atomic_inc(dev-counts[_DRM_STAT_IOCTLS]);
++file_priv-ioctl_count;
@@ -501,7 +502,13 @@ int drm_ioctl(struct inode *inode, struct file *filp,
goto err_i1;
}
}
- retcode = func(dev, kdata, file_priv);
+ if (ioctl-flags DRM_UNLOCKED)
+ retcode = func(dev, kdata, file_priv);
+ else {
+ lock_kernel();
+ retcode = func(dev, kdata, file_priv);
+ unlock_kernel();
+ }
if (cmd IOC_OUT) {
if (copy_to_user((void __user *)arg, kdata,
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 282d9fd..d61d185 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -104,7 +104,7 @@ static int compat_drm_version(struct file *file, unsigned
int cmd,
version-desc))
return -EFAULT;
- err = drm_ioctl(file-f_path.dentry-d_inode, file,
+ err = drm_ioctl(file,
DRM_IOCTL_VERSION, (unsigned long)version);
if (err)
return err;
@@ -145,8 +145,7 @@ static int compat_drm_getunique(struct file *file, unsigned
int cmd,
u-unique))
return -EFAULT;
- err = drm_ioctl(file-f_path.dentry-d_inode, file,
- DRM_IOCTL_GET_UNIQUE, (unsigned long)u);
+ err = drm_ioctl(file, DRM_IOCTL_GET_UNIQUE, (unsigned long)u);
if (err)
return err;
@@ -174,8 +173,7 @@ static int compat_drm_setunique(struct file *file, unsigned
[PATCH] drm/mm: fix logic for selection of best fit block
From: Bob Gleitsmann rjgle...@bellsouth.net
This is from bug 25728.
[airlied: I'm just forwarding the patch for review, Thomas, ickle?]
---
drivers/gpu/drm/drm_mm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index d7d7eac..cdec329 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -358,7 +358,7 @@ struct drm_mm_node *drm_mm_search_free(const struct drm_mm
*mm,
if (entry-size = size + wasted) {
if (!best_match)
return entry;
- if (size best_size) {
+ if (entry-size best_size) {
best = entry;
best_size = entry-size;
}
@@ -408,7 +408,7 @@ struct drm_mm_node *drm_mm_search_free_in_range(const
struct drm_mm *mm,
if (entry-size = size + wasted) {
if (!best_match)
return entry;
- if (size best_size) {
+ if (entry-size best_size) {
best = entry;
best_size = entry-size;
}
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] stable - drm/radeon/kms: fix crtc vblank update for r600
From: Dave Airlie airl...@redhat.com In 2.6.32.2 r600 had no IRQ support, however the patch in 500b758725314ab1b5316eb0caa5b0fa26740e6b to fix vblanks on avivo cards, needs irqs. So check for an R600 card and avoid this path if so. This is a stable only patch for 2.6.32.2 as 2.6.33 has IRQs for r600. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/atombios_crtc.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index c6777cb..19f93f2 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -249,13 +249,15 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode) if (ASIC_IS_DCE3(rdev)) atombios_enable_crtc_memreq(crtc, 1); atombios_blank_crtc(crtc, 0); - drm_vblank_post_modeset(dev, radeon_crtc-crtc_id); + if (rdev-family CHIP_R600) + drm_vblank_post_modeset(dev, radeon_crtc-crtc_id); radeon_crtc_load_lut(crtc); break; case DRM_MODE_DPMS_STANDBY: case DRM_MODE_DPMS_SUSPEND: case DRM_MODE_DPMS_OFF: - drm_vblank_pre_modeset(dev, radeon_crtc-crtc_id); + if (rdev-family CHIP_R600) + drm_vblank_pre_modeset(dev, radeon_crtc-crtc_id); atombios_blank_crtc(crtc, 1); if (ASIC_IS_DCE3(rdev)) atombios_enable_crtc_memreq(crtc, 0); -- 1.6.5.2 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: [ANNOUNCE] libdrm 2.4.17 To: xorg-annou...@lists.freedesktop.org CC: dri-de...@lists.freedesktop.org The experimental radeon API changed a lot, still experimental, but I don't think it'll break incompatability again after this. This also adds the dirty interface for vmwgfx that is upstream now. Ben Skeggs (3): nouveau: move reloc code down, nothing to see here nouveau: Use drmIoctl so we restart ioctl on EINTR or EAGAIN nouveau: remove delayed kernel bo creation Chris Wilson (2): intel: Expect caller to guarantee thread-safety of bo during reloc intel: Clear virtual after failing to mmap_gtt. Dave Airlie (3): radeon: straighten out the API insanity. radeon: fix BO null check, should be in higher level fn libdrm 2.4.17 Jakob Bornecrantz (4): Bring dirty code from old branch Change the dirty ioctl a bit and comment it Change the number on the dirty ioctl to match upstream Ignore config.h.in Jerome Glisse (1): radeon: Use drmIoctl so we restart ioctl on EINTR or EAGAIN Jesse Barnes (4): drm/i915: add GETPARAM request for page flipping Bump libdrm version to 2.4.16 for page flipping Bump event context structure version for page flipping modetest: fix build error due to page_flip_handler name change Kristian Høgsberg (5): libdrm: add libdrm support for page flip ioctl modetest: add pageflip test case to modetest Add RELEASING to document the release process modetest: Error out if pageflipping is requested but not available Be less chatty in drmSetMaster/drmDropMaster git tag: 2.4.17 http://dri.freedesktop.org/libdrm/libdrm-2.4.17.tar.bz2 MD5: 667d81f993f7fd8a1b1b1b830a28a748 libdrm-2.4.17.tar.bz2 SHA1: 52f12fc75ecf3d0c2e89579b7454f040ac515aa6 libdrm-2.4.17.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.17.tar.gz MD5: 6eeeb332ca9d296663bb5b38ab362013 libdrm-2.4.17.tar.gz SHA1: 567415a179ece2f20fd946853dd0b5432c24f01b libdrm-2.4.17.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAksvApcACgkQ6acWQe8Wxxq+4gCfWzMYJ9NCjXASSxmyvQFYg6DW w90AnAyhE0i9AtMMGKntF+0yVQaaNnA5 =BHkU -END PGP SIGNATURE- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2] drm/radeon/kms: add support for depth-only rendering and 3DC texture compression on R3xx-R5xx
I'd like to propose two patches for kernel DRM. Both these sounds sane to me, I'll push them into a testing tree early next week, Dave. Currently the R300 CS checker doesn't allow rendering with no color buffer set. This is needed for depth-only rendering which is required for rendering into depth textures to generate shadow maps. The first attached patch removes this restriction by skipping checking the colorbuffer if both ZB_BW_CNTL.FAST_FILL and RB3D_BLENDCNTL.READ_ENABLE are disabled, and RB3D_COLOR_CHANNEL_MASK is 0. When these bits are set, the hardware won't touch the colorbuffer at all. The second attached patch adds support for the 3DC texture compression (formats ATI1N and ATI2N). The former has 64 bits per 4x4 pixel block (same as DXT1) and is available on R4xx and up, and the latter has 128 bits per 4x4 pixel block (same as DXT3/5) and is available on R5xx. This functionality can be exposed in OpenGL by GL_EXT_texture_compression_latc and GL_ARB_texture_compression_rgtc, which is part of OpenGL 3.0 and will most probably be implemented in Mesa in future. Frankly ATI1N can already be used as it occupies the same format bits as TX_FMT_3_3_2 with the addition that TX_FORMAT2_n.TXFORMAT_MSB must be set. The CS parser doesn't read the TXFORMAT_MSB bit at all, so it always interprets the format as 3_3_2. If the MSB bit is set with the second patch, the CS parser interprets any format as ATI1N, because the other extended formats won't be used anyway as they are not exposed by any graphics API. Let me know if you agree with this behavior. Please review. Best regards Marek Olšák -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: convert drm_ioctl to unlocked_ioctl
On Thu, Dec 17, 2009 at 8:17 AM, Arnd Bergmann a...@arndb.de wrote: drm_ioctl is called with the Big Kernel Lock held, which shows up very high in statistics on vfs_ioctl. Moving the lock into the drm_ioctl function itself makes sure we blame the right subsystem and it gets us one step closer to eliminating the locked version of fops-ioctl. Since drm_ioctl does not require the lock itself, we only need to hold it while calling the specific handler. The 32 bit conversion handlers do not interact with any other code, so they don't need the BKL here either and can just call drm_ioctl. As a bonus, this cleans up all the other users of drm_ioctl which now no longer have to find the inode or call lock_kernel. This looks good, I've taken this and I've squashed the generic pieces of your RFC into this (i.e. I haven't modified the drivers, but just added the flag to allow the ioctls to be unlocked if the driver selects them). Do you think we should try and get this in soon, its seems like it shouldn't have any regressions unless we start switching drivers over. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] vmware drm/kms driver under staging
Hi Linus, Please pull the 'drm-vmware-staging' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-vmware-staging ping? Greg is fine with this going in, and its a pretty standalone driver for a very popular virtual GPU. Dave. This adds the VMware KMS driver for their virtual GPU, the Kconfig is under staging until they are happy with the ioctl interface to the 3D driver, which may be quite soon. We now have 4 KMS drivers, hopefully it'll quieten down for a while, while we fix them all up. Dave. drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/vmwgfx/Kconfig | 13 + drivers/gpu/drm/vmwgfx/Makefile | 9 + drivers/gpu/drm/vmwgfx/svga3d_reg.h | 1793 ++ drivers/gpu/drm/vmwgfx/svga_escape.h | 89 ++ drivers/gpu/drm/vmwgfx/svga_overlay.h | 201 drivers/gpu/drm/vmwgfx/svga_reg.h | 1346 ++ drivers/gpu/drm/vmwgfx/svga_types.h | 45 + drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 229 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 735 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 511 + drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 516 + drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 742 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 521 + drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 213 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 81 ++ drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 295 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 872 +++ drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 102 ++ drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 516 + drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 634 +++ drivers/gpu/drm/vmwgfx/vmwgfx_reg.h | 57 + drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 1192 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 99 ++ drivers/staging/Kconfig | 2 + include/drm/Kbuild | 1 + include/drm/ttm/ttm_object.h | 6 +- include/drm/vmwgfx_drm.h | 574 ++ 28 files changed, 11394 insertions(+), 1 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/Kconfig create mode 100644 drivers/gpu/drm/vmwgfx/Makefile create mode 100644 drivers/gpu/drm/vmwgfx/svga3d_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_escape.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_overlay.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_types.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c create mode 100644 include/drm/vmwgfx_drm.h commit fb1d9738ca053ea8afa5e86af6463155f983b01c Author: Jakob Bornecrantz ja...@vmware.com Date: Thu Dec 10 00:19:58 2009 + drm/vmwgfx: Add DRM driver for VMware Virtual GPU This commit adds the vmwgfx driver for the VWware Virtual GPU aka SVGA. The driver is under staging the same as Nouveau and Radeon KMS. Hopefully the 2D ioctls are bug free and don't need changing, so that part of the API should be stable. But there there is a pretty big chance that the 3D API will change in the future. Signed-off-by: Thomas Hellström thellst...@vmware.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit 632f61178d0473861ba77e774bb654b37bc7eccc Author: Jakob Bornecrantz ja...@vmware.com Date: Thu Dec 10 00:19:10 2009 + drm/vmwgfx: Add svga headers for vmwgfx driver These headers are shared between multiple place where different coding standards apply. They will be fixed up at a later time. Signed-off-by: Thomas Hellström thellst...@vmware.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit be1cb8689c480228ffd2e4bfccc0dab7156cd9ea Author: Jakob Bornecrantz ja...@vmware.com Date: Mon Dec 14 22:07:45 2009 + drm/ttm: Add more driver type enums Signed-off
