[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Harald Judt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Harald Judt 2011-06-08 23:44:05 PDT --- Unfortunately, I have to reopen this bug, as the corruption returned as soon as I tried to start a 3d game (naev: http://code.google.com/p/naev/). - some fonts in the menu were corrupted and unreadable - exiting back to the desktop shows the same corruption mentioned before (window decorations, icons) However, it's a bit better now, as it did not happen during normal desktop usage (till now). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Harald Judt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Harald Judt 2011-06-08 23:44:05 PDT --- Unfortunately, I have to reopen this bug, as the corruption returned as soon as I tried to start a 3d game (naev: http://code.google.com/p/naev/). - some fonts in the menu were corrupted and unreadable - exiting back to the desktop shows the same corruption mentioned before (window decorations, icons) However, it's a bit better now, as it did not happen during normal desktop usage (till now). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: Honour O_NONBLOCK on the device for reading events
On Wed, 8 Jun 2011 20:14:01 +0100 Chris Wilson wrote: > Otherwise drmHandleEvent will block if accidentally read too often... > > Signed-off-by: Chris Wilson > Cc: Phillip Haddad > --- > drivers/gpu/drm/drm_fops.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c > index 2ec7d48..279aa95 100644 > --- a/drivers/gpu/drm/drm_fops.c > +++ b/drivers/gpu/drm/drm_fops.c > @@ -617,6 +617,9 @@ ssize_t drm_read(struct file *filp, char __user *buffer, > size_t total; > ssize_t ret; > > + if (filp->f_flags & O_NONBLOCK && list_empty(&file_priv->event_list)) > + return -EAGAIN; > + > ret = wait_event_interruptible(file_priv->event_wait, > !list_empty(&file_priv->event_list)); > if (ret < 0) What happens if someone else empties the list between the test and the wait_event_interruptible ?
[Bug 37032] DRM_RADEON=m with CONFIG_FB=y fails
https://bugzilla.kernel.org/show_bug.cgi?id=37032 Andrew Morton changed: What|Removed |Added CC||a...@linux-foundation.org Component|Configuration |Video(DRI - non Intel) AssignedTo|other_configuration@kernel- |drivers_video-dri@kernel-bu |bugs.osdl.org |gs.osdl.org Product|Other |Drivers -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher 2011-06-08 22:55:47 PDT --- fixed: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=805c22168da76a65c978017d0fe0d59cd048e995 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher 2011-06-08 22:55:47 PDT --- fixed: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=805c22168da76a65c978017d0fe0d59cd048e995 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #11 from Sérgio M. Basto 2011-06-08 22:53:22 PDT --- hl2 ep2 crashes a lot with nvidia and ati even in windows , what episode are you trying to run ? and the fixes also for what HL2 is ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #11 from S?rgio M. Basto 2011-06-08 22:53:22 PDT --- hl2 ep2 crashes a lot with nvidia and ati even in windows , what episode are you trying to run ? and the fixes also for what HL2 is ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
On Fri, 2011-06-03 at 12:54 +0200, Sascha Hauer wrote: > The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers. > That is because the framebuffers for each file are in the filp_head > member of struct drm_framebuffer, not in the head member. > > Signed-off-by: Sascha Hauer > --- Looks good, commited to drm-fixes tree. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
On Tue, 2011-06-07 at 13:07 -0700, Jesse Barnes wrote: > To properly support the various plane formats supported by different > hardware, the kernel must know the pixel format of a framebuffer object. > So add a new ioctl taking a format argument corresponding to a fourcc > name from videodev2.h. I'd rather we don't directly tie things like that, either create a fourcc header that isn't V4L2 or DRM related and use that or generate two headers one with DRM_ and one with V4L2 prefixes. Mainly so we can keep the DRM interface in some way OS agnostic. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Honour O_NONBLOCK on the device for reading events
Otherwise drmHandleEvent will block if accidentally read too often... Signed-off-by: Chris Wilson Cc: Phillip Haddad --- drivers/gpu/drm/drm_fops.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 2ec7d48..279aa95 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -617,6 +617,9 @@ ssize_t drm_read(struct file *filp, char __user *buffer, size_t total; ssize_t ret; + if (filp->f_flags & O_NONBLOCK && list_empty(&file_priv->event_list)) + return -EAGAIN; + ret = wait_event_interruptible(file_priv->event_wait, !list_empty(&file_priv->event_list)); if (ret < 0) -- 1.7.5.3
[Bug 36962] [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled
https://bugzilla.kernel.org/show_bug.cgi?id=36962 Maciej Rutecki changed: What|Removed |Added Blocks||32012 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36962] New: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled
https://bugzilla.kernel.org/show_bug.cgi?id=36962 Summary: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled Product: Drivers Version: 2.5 Kernel Version: 2.6.39 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: maciej.rutecki at gmail.com CC: kaffeemonster at googlemail.com, rjw at sisk.pl, maciej.rutecki at gmail.com Regression: Yes Subject: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled Submitter : Jan Seiffert Date : 2011-05-25 2:32 Message-ID : BANLkTimd6nvXTbn2hM+cKDNKFpxzsQLHog at mail.gmail.com References : http://marc.info/?l=linux-kernel&m=130629073407685&w=2 This entry is being used for tracking a regression from 2.6.38. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] bugfix and cleanup patches in the TTM code for 3.1.
Hi Konrad, 2011/6/8 Konrad Rzeszutek Wilk : > The bug-fix "ttm: Do not increment the amount of pages in a pool by the > current amount" > I never observed, but found while looking at the code. The cleanup patch: > "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier > and Randy > Dunlap graciously added some extra cleanups - which I have rolled in. This is safe to put comments to the patch in the following place: Signed-off-by: (...) --- RIGHT HERE --- drivers/(...) When applying such a patch comments will not be visible in git log. You may find this easier method of commenting your patches. -- Rafa?
[Bug 29953] [r300g] Heroes of Newerth: texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=29953 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #17 from Marek Olšák 2011-06-08 19:26:46 PDT --- Fixed by da8b4c07986e202b0596b729a5eec31c9aec5fcc. The S2 logo and the main menu is rendered correctly now. I haven't tried to enter the game though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29953] [r300g] Heroes of Newerth: texture problems
https://bugs.freedesktop.org/show_bug.cgi?id=29953 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #17 from Marek Ol??k 2011-06-08 19:26:46 PDT --- Fixed by da8b4c07986e202b0596b729a5eec31c9aec5fcc. The S2 logo and the main menu is rendered correctly now. I haven't tried to enter the game though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Modeline problem with Radeon KMS
> > I have LG Flatron F900P CRT monitor. X drivers work fine, nouveau KMS > > works fine but Radeon KMS selects a videomode that is out of spec for > > monitor. This is not a regression - this hardware combination has never > > worked for me yet with radeon KMS. The result is same for Radeon 7000 > > (RV100, currently installed) and Radeon 9200 series card. Umm, I guess I forgot one important aspect. When X comes up, it finds a good video mode and gets a picture. It's just the text consoles that have no picture. In the console, it tells it's using 352x132 console. This translates with 8x16 font to 2816x2112 and 9x16 font to 3168x2112 if I calculated the right thing. Running fbset remotely verifies this: # fbset -s Is it just 2048x1536 that's causing problems? Do any other modes > work? 1600x1200 for example? X uses 2048x1536 successfully. 1600x1200, 1920x1440, 1280x1024 all work fine, just tested with xrandr. > > [ ? ?36.111] (II) RADEON(0): Output VGA-0 using monitor section CM771 > > I notice you have a monitor section defined in your xorg.conf. Does > that monitor section perhaps have any old modelines from an old > monitor that may be causing problems? X without configuration also gets a working 2048x1536. X conf seems to be quite irrelevant - scree-related things here, and my list of resolutions is ignored anyway for some reason not important righh now. Section "Device" Identifier "AGP kaart" Driver "ati" Option "AGPMode" "2" EndSection Section "Monitor" Identifier "CM771" Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "AGP kaart" Monitor "CM771" DefaultDepth24 SubSection "Display" Depth 1 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 15 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection EndSection -- Meelis Roos (mroos at linux.ee)
[Bug 30166] [wine] Shader issues in rthdribl 1.2
https://bugs.freedesktop.org/show_bug.cgi?id=30166 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Marek Olšák 2011-06-08 17:35:13 PDT --- It works well with float textures and doesn't work without them, so I am closing this bug. It's kinda blocky though, but that's because R300 cannot filter float textures. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30166] [wine] Shader issues in rthdribl 1.2
https://bugs.freedesktop.org/show_bug.cgi?id=30166 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Marek Ol??k 2011-06-08 17:35:13 PDT --- It works well with float textures and doesn't work without them, so I am closing this bug. It's kinda blocky though, but that's because R300 cannot filter float textures. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/gem: add hooks to notify driver when object handle is created/destroyed
From: Ben Skeggs Nouveau is going to use these hooks to map/unmap objects from a client's private GPU address space. Signed-off-by: Ben Skeggs --- drivers/gpu/drm/drm_gem.c | 21 +++-- include/drm/drmP.h|2 ++ 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 74e4ff5..59d2417 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -207,6 +207,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) dev = obj->dev; /* Release reference and decrement refcount. */ + if (dev->driver->gem_close_object) + dev->driver->gem_close_object(obj, filp); idr_remove(&filp->object_idr, handle); spin_unlock(&filp->table_lock); @@ -226,7 +228,8 @@ drm_gem_handle_create(struct drm_file *file_priv, struct drm_gem_object *obj, u32 *handlep) { - int ret; + struct drm_device *dev = obj->dev; + int ret; /* * Get the user-visible handle using idr. @@ -247,6 +250,15 @@ again: return ret; drm_gem_object_handle_reference(obj); + + if (dev->driver->gem_open_object) { + ret = dev->driver->gem_open_object(obj, file_priv); + if (ret) { + drm_gem_handle_delete(file_priv, *handlep); + return ret; + } + } + return 0; } EXPORT_SYMBOL(drm_gem_handle_create); @@ -401,7 +413,12 @@ drm_gem_open(struct drm_device *dev, struct drm_file *file_private) static int drm_gem_object_release_handle(int id, void *ptr, void *data) { + struct drm_file *file_priv = data; struct drm_gem_object *obj = ptr; + struct drm_device *dev = obj->dev; + + if (dev->driver->gem_close_object) + dev->driver->gem_close_object(obj, file_priv); drm_gem_object_handle_unreference_unlocked(obj); @@ -417,7 +434,7 @@ void drm_gem_release(struct drm_device *dev, struct drm_file *file_private) { idr_for_each(&file_private->object_idr, -&drm_gem_object_release_handle, NULL); +&drm_gem_object_release_handle, file_private); idr_remove_all(&file_private->object_idr); idr_destroy(&file_private->object_idr); diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 738b3a5..4912cb7 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -886,6 +886,8 @@ struct drm_driver { */ int (*gem_init_object) (struct drm_gem_object *obj); void (*gem_free_object) (struct drm_gem_object *obj); + int (*gem_open_object) (struct drm_gem_object *, struct drm_file *); + void (*gem_close_object) (struct drm_gem_object *, struct drm_file *); /* vga arb irq handler */ void (*vgaarb_irq)(struct drm_device *dev, bool state); -- 1.7.5.2
Re: [PATCH] drm/gem: add hooks to notify driver when object handle is created/destroyed
On Thu, 2011-06-09 at 10:24 +1000, skeg...@gmail.com wrote: > From: Ben Skeggs > > Nouveau is going to use these hooks to map/unmap objects from a client's > private GPU address space. Forgot the v2 notes.. inlined below.. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/drm_gem.c | 21 +++-- > include/drm/drmP.h|2 ++ > 2 files changed, 21 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 74e4ff5..bad3359 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -210,6 +210,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) > idr_remove(&filp->object_idr, handle); > spin_unlock(&filp->table_lock); > > + if (dev->driver->gem_close_object) > + dev->driver->gem_close_object(obj, filp); > drm_gem_object_handle_unreference_unlocked(obj); This is the only change, moved the call to the driver hook outside of the spinlock. Ben. > > return 0; > @@ -226,7 +228,8 @@ drm_gem_handle_create(struct drm_file *file_priv, > struct drm_gem_object *obj, > u32 *handlep) > { > - int ret; > + struct drm_device *dev = obj->dev; > + int ret; > > /* >* Get the user-visible handle using idr. > @@ -247,6 +250,15 @@ again: > return ret; > > drm_gem_object_handle_reference(obj); > + > + if (dev->driver->gem_open_object) { > + ret = dev->driver->gem_open_object(obj, file_priv); > + if (ret) { > + drm_gem_handle_delete(file_priv, *handlep); > + return ret; > + } > + } > + > return 0; > } > EXPORT_SYMBOL(drm_gem_handle_create); > @@ -401,7 +413,12 @@ drm_gem_open(struct drm_device *dev, struct drm_file > *file_private) > static int > drm_gem_object_release_handle(int id, void *ptr, void *data) > { > + struct drm_file *file_priv = data; > struct drm_gem_object *obj = ptr; > + struct drm_device *dev = obj->dev; > + > + if (dev->driver->gem_close_object) > + dev->driver->gem_close_object(obj, file_priv); > > drm_gem_object_handle_unreference_unlocked(obj); > > @@ -417,7 +434,7 @@ void > drm_gem_release(struct drm_device *dev, struct drm_file *file_private) > { > idr_for_each(&file_private->object_idr, > - &drm_gem_object_release_handle, NULL); > + &drm_gem_object_release_handle, file_private); > > idr_remove_all(&file_private->object_idr); > idr_destroy(&file_private->object_idr); > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > index 738b3a5..4912cb7 100644 > --- a/include/drm/drmP.h > +++ b/include/drm/drmP.h > @@ -886,6 +886,8 @@ struct drm_driver { >*/ > int (*gem_init_object) (struct drm_gem_object *obj); > void (*gem_free_object) (struct drm_gem_object *obj); > + int (*gem_open_object) (struct drm_gem_object *, struct drm_file *); > + void (*gem_close_object) (struct drm_gem_object *, struct drm_file *); > > /* vga arb irq handler */ > void (*vgaarb_irq)(struct drm_device *dev, bool state); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gem: add hooks to notify driver when object handle is created/destroyed
From: Ben Skeggs Nouveau is going to use these hooks to map/unmap objects from a client's private GPU address space. Signed-off-by: Ben Skeggs --- drivers/gpu/drm/drm_gem.c | 21 +++-- include/drm/drmP.h|2 ++ 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 74e4ff5..bad3359 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -210,6 +210,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) idr_remove(&filp->object_idr, handle); spin_unlock(&filp->table_lock); + if (dev->driver->gem_close_object) + dev->driver->gem_close_object(obj, filp); drm_gem_object_handle_unreference_unlocked(obj); return 0; @@ -226,7 +228,8 @@ drm_gem_handle_create(struct drm_file *file_priv, struct drm_gem_object *obj, u32 *handlep) { - int ret; + struct drm_device *dev = obj->dev; + int ret; /* * Get the user-visible handle using idr. @@ -247,6 +250,15 @@ again: return ret; drm_gem_object_handle_reference(obj); + + if (dev->driver->gem_open_object) { + ret = dev->driver->gem_open_object(obj, file_priv); + if (ret) { + drm_gem_handle_delete(file_priv, *handlep); + return ret; + } + } + return 0; } EXPORT_SYMBOL(drm_gem_handle_create); @@ -401,7 +413,12 @@ drm_gem_open(struct drm_device *dev, struct drm_file *file_private) static int drm_gem_object_release_handle(int id, void *ptr, void *data) { + struct drm_file *file_priv = data; struct drm_gem_object *obj = ptr; + struct drm_device *dev = obj->dev; + + if (dev->driver->gem_close_object) + dev->driver->gem_close_object(obj, file_priv); drm_gem_object_handle_unreference_unlocked(obj); @@ -417,7 +434,7 @@ void drm_gem_release(struct drm_device *dev, struct drm_file *file_private) { idr_for_each(&file_private->object_idr, -&drm_gem_object_release_handle, NULL); +&drm_gem_object_release_handle, file_private); idr_remove_all(&file_private->object_idr); idr_destroy(&file_private->object_idr); diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 738b3a5..4912cb7 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -886,6 +886,8 @@ struct drm_driver { */ int (*gem_init_object) (struct drm_gem_object *obj); void (*gem_free_object) (struct drm_gem_object *obj); + int (*gem_open_object) (struct drm_gem_object *, struct drm_file *); + void (*gem_close_object) (struct drm_gem_object *, struct drm_file *); /* vga arb irq handler */ void (*vgaarb_irq)(struct drm_device *dev, bool state); -- 1.7.5.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34929] [r300g] slowdown with r300g threading
https://bugs.freedesktop.org/show_bug.cgi?id=34929 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #10 from Marek Olšák 2011-06-08 17:20:48 PDT --- (In reply to comment #8) > - openarena without gdb is still a bit slower (~100 vs ~103 fps); Because that was the only remaining slowdown and now I can't see any difference between threading enabled and disabled in openarena (if I enable hyperz, there is a slowdown 153->152 fps with threading off->on, respectively, which I don't consider significant, given the improvement in other apps), I am closing this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34929] [r300g] slowdown with r300g threading
https://bugs.freedesktop.org/show_bug.cgi?id=34929 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #10 from Marek Ol??k 2011-06-08 17:20:48 PDT --- (In reply to comment #8) > - openarena without gdb is still a bit slower (~100 vs ~103 fps); Because that was the only remaining slowdown and now I can't see any difference between threading enabled and disabled in openarena (if I enable hyperz, there is a slowdown 153->152 fps with threading off->on, respectively, which I don't consider significant, given the improvement in other apps), I am closing this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Modeline problem with Radeon KMS
lt_switch" [41.257] (II) config/udev: Adding input device ImExPS/2 Logitech Explorer Mouse (/dev/input/event1) [41.257] (**) ImExPS/2 Logitech Explorer Mouse: Applying InputClass "evdev pointer catchall" [41.257] (II) Using input driver 'evdev' for 'ImExPS/2 Logitech Explorer Mouse' [41.257] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [41.257] (**) ImExPS/2 Logitech Explorer Mouse: always reports core events [41.257] (**) ImExPS/2 Logitech Explorer Mouse: Device: "/dev/input/event1" [41.257] (--) ImExPS/2 Logitech Explorer Mouse: Found 9 mouse buttons [41.257] (--) ImExPS/2 Logitech Explorer Mouse: Found scroll wheel(s) [41.257] (--) ImExPS/2 Logitech Explorer Mouse: Found relative axes [41.257] (--) ImExPS/2 Logitech Explorer Mouse: Found x and y relative axes [41.257] (II) ImExPS/2 Logitech Explorer Mouse: Configuring as mouse [41.257] (II) ImExPS/2 Logitech Explorer Mouse: Adding scrollwheel support [41.258] (**) ImExPS/2 Logitech Explorer Mouse: YAxisMapping: buttons 4 and 5 [41.258] (**) ImExPS/2 Logitech Explorer Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [41.258] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio1/input/input1/event1" [41.258] (II) XINPUT: Adding extended input device "ImExPS/2 Logitech Explorer Mouse" (type: MOUSE) [41.258] (II) ImExPS/2 Logitech Explorer Mouse: initialized for relative axes. [41.258] (**) ImExPS/2 Logitech Explorer Mouse: (accel) keeping acceleration scheme 1 [41.258] (**) ImExPS/2 Logitech Explorer Mouse: (accel) acceleration profile 0 [41.258] (**) ImExPS/2 Logitech Explorer Mouse: (accel) acceleration factor: 2.000 [41.258] (**) ImExPS/2 Logitech Explorer Mouse: (accel) acceleration threshold: 4 [41.259] (II) config/udev: Adding input device ImExPS/2 Logitech Explorer Mouse (/dev/input/mouse0) [41.259] (II) No input driver/identifier specified (ignoring) [41.271] (II) config/udev: Adding input device ACPI Virtual Keyboard Device (/dev/input/event4) [41.271] (**) ACPI Virtual Keyboard Device: Applying InputClass "evdev keyboard catchall" [41.271] (II) Using input driver 'evdev' for 'ACPI Virtual Keyboard Device' [41.271] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [41.271] (**) ACPI Virtual Keyboard Device: always reports core events [41.276] (**) ACPI Virtual Keyboard Device: Device: "/dev/input/event4" [41.276] (--) ACPI Virtual Keyboard Device: Found keys [41.276] (II) ACPI Virtual Keyboard Device: Configuring as keyboard [41.276] (**) Option "config_info" "udev:/sys/devices/virtual/input/input4/event4" [41.276] (II) XINPUT: Adding extended input device "ACPI Virtual Keyboard Device" (type: KEYBOARD) [41.276] (**) Option "xkb_rules" "evdev" [41.276] (**) Option "xkb_model" "pc105" [41.276] (**) Option "xkb_layout" "ee" [41.276] (**) Option "xkb_options" "lv3:ralt_switch" -- Meelis Roos (mroos at linux.ee) -- next part -- A non-text attachment was scrubbed... Name: edid Type: application/octet-stream Size: 128 bytes Desc: URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110608/fde7ed52/attachment-0001.obj>
[Bug 36270] [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used
https://bugs.freedesktop.org/show_bug.cgi?id=36270 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Marek Olšák 2011-06-08 17:04:53 PDT --- The reason it's not smooth is that R500 cannot filter float textures. There is nothing I can do about it, it's a hardware limitation. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36270] [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used
https://bugs.freedesktop.org/show_bug.cgi?id=36270 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Marek Ol??k 2011-06-08 17:04:53 PDT --- The reason it's not smooth is that R500 cannot filter float textures. There is nothing I can do about it, it's a hardware limitation. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g
https://bugs.freedesktop.org/show_bug.cgi?id=36609 --- Comment #5 from Marek Olšák 2011-06-08 16:47:19 PDT --- almos, does 578d4539ba72a9f52e0cb3f615bb04bf9407b574 fix it? If not, please attach a screenshot demontrating the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g
https://bugs.freedesktop.org/show_bug.cgi?id=36609 --- Comment #5 from Marek Ol??k 2011-06-08 16:47:19 PDT --- almos, does 578d4539ba72a9f52e0cb3f615bb04bf9407b574 fix it? If not, please attach a screenshot demontrating the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36611] [wine] The Witcher: Crash in u_vbuf_mgr_draw_begin
https://bugs.freedesktop.org/show_bug.cgi?id=36611 --- Comment #1 from Marek Olšák 2011-06-08 16:44:43 PDT --- Is this still an issue with current Mesa git? If yes, could you please make a GL trace using apitrace? (basic info about tracing: https://bugs.freedesktop.org/show_bug.cgi?id=36745#c15 ) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36611] [wine] The Witcher: Crash in u_vbuf_mgr_draw_begin
https://bugs.freedesktop.org/show_bug.cgi?id=36611 --- Comment #1 from Marek Ol??k 2011-06-08 16:44:43 PDT --- Is this still an issue with current Mesa git? If yes, could you please make a GL trace using apitrace? (basic info about tracing: https://bugs.freedesktop.org/show_bug.cgi?id=36745#c15 ) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Marek Olšák 2011-06-08 16:31:35 PDT --- Good point. We do split rendering commands with too many vertices into smaller ones, but the splitting was broken. Fixed by 578d4539ba72a9f52e0cb3f615bb04bf9407b574. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Marek Ol??k 2011-06-08 16:31:35 PDT --- Good point. We do split rendering commands with too many vertices into smaller ones, but the splitting was broken. Fixed by 578d4539ba72a9f52e0cb3f615bb04bf9407b574. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #10 from Marek Olšák 2011-06-08 16:13:30 PDT --- The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 error messages seem to be unfixable hardware limitations. Is there a way to disable the shader model 3.0 in Wine/DX9? The shader model 2.0, which the hardware was designed for, doesn't have loops, and HL2 must support that (otherwise it wouldn't work on Windows either). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #10 from Marek Ol??k 2011-06-08 16:13:30 PDT --- The log clearly says HL2 uses loops, which r3xx-r4xx can't do. All the r300 error messages seem to be unfixable hardware limitations. Is there a way to disable the shader model 3.0 in Wine/DX9? The shader model 2.0, which the hardware was designed for, doesn't have loops, and HL2 must support that (otherwise it wouldn't work on Windows either). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm: Honour O_NONBLOCK on the device for reading events
On Wed, 8 Jun 2011 20:14:01 +0100 Chris Wilson wrote: > Otherwise drmHandleEvent will block if accidentally read too often... > > Signed-off-by: Chris Wilson > Cc: Phillip Haddad > --- > drivers/gpu/drm/drm_fops.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c > index 2ec7d48..279aa95 100644 > --- a/drivers/gpu/drm/drm_fops.c > +++ b/drivers/gpu/drm/drm_fops.c > @@ -617,6 +617,9 @@ ssize_t drm_read(struct file *filp, char __user *buffer, > size_t total; > ssize_t ret; > > + if (filp->f_flags & O_NONBLOCK && list_empty(&file_priv->event_list)) > + return -EAGAIN; > + > ret = wait_event_interruptible(file_priv->event_wait, > !list_empty(&file_priv->event_list)); > if (ret < 0) What happens if someone else empties the list between the test and the wait_event_interruptible ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add initial CS checker support for compute
- Add some new compute regs - Add new dispatch packets for evergreen/cayman Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/evergreen_cs.c | 57 - drivers/gpu/drm/radeon/evergreend.h |2 + drivers/gpu/drm/radeon/r600_cs.c |9 + drivers/gpu/drm/radeon/radeon_drv.c |2 +- drivers/gpu/drm/radeon/reg_srcs/cayman|2 + drivers/gpu/drm/radeon/reg_srcs/evergreen |3 ++ drivers/gpu/drm/radeon/reg_srcs/r600 |1 + 7 files changed, 74 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index 7bdaf41..f69599e 100644 --- a/drivers/gpu/drm/radeon/evergreen_cs.c +++ b/drivers/gpu/drm/radeon/evergreen_cs.c @@ -871,7 +871,6 @@ static inline int evergreen_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u3 case SQ_PGM_START_PS: case SQ_PGM_START_HS: case SQ_PGM_START_LS: - case GDS_ADDR_BASE: case SQ_CONST_MEM_BASE: case SQ_ALU_CONST_CACHE_GS_0: case SQ_ALU_CONST_CACHE_GS_1: @@ -961,6 +960,34 @@ static inline int evergreen_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u3 } ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x); break; + case SX_MEMORY_EXPORT_BASE: + if (p->rdev->family >= CHIP_CAYMAN) { + dev_warn(p->dev, "bad SET_CONFIG_REG " +"0x%04X\n", reg); + return -EINVAL; + } + r = evergreen_cs_packet_next_reloc(p, &reloc); + if (r) { + dev_warn(p->dev, "bad SET_CONFIG_REG " + "0x%04X\n", reg); + return -EINVAL; + } + ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x); + break; + case CAYMAN_SX_SCATTER_EXPORT_BASE: + if (p->rdev->family < CHIP_CAYMAN) { + dev_warn(p->dev, "bad SET_CONTEXT_REG " +"0x%04X\n", reg); + return -EINVAL; + } + r = evergreen_cs_packet_next_reloc(p, &reloc); + if (r) { + dev_warn(p->dev, "bad SET_CONTEXT_REG " + "0x%04X\n", reg); + return -EINVAL; + } + ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x); + break; default: dev_warn(p->dev, "forbidden register 0x%08x at %d\n", reg, idx); return -EINVAL; @@ -1168,6 +1195,34 @@ static int evergreen_packet3_check(struct radeon_cs_parser *p, return r; } break; + case PACKET3_DISPATCH_DIRECT: + if (pkt->count != 3) { + DRM_ERROR("bad DISPATCH_DIRECT\n"); + return -EINVAL; + } + r = evergreen_cs_track_check(p); + if (r) { + dev_warn(p->dev, "%s:%d invalid cmd stream %d\n", __func__, __LINE__, idx); + return r; + } + break; + case PACKET3_DISPATCH_INDIRECT: + if (pkt->count != 1) { + DRM_ERROR("bad DISPATCH_INDIRECT\n"); + return -EINVAL; + } + r = evergreen_cs_packet_next_reloc(p, &reloc); + if (r) { + DRM_ERROR("bad DISPATCH_INDIRECT\n"); + return -EINVAL; + } + ib[idx+0] = idx_value + (u32)(reloc->lobj.gpu_offset & 0x); + r = evergreen_cs_track_check(p); + if (r) { + dev_warn(p->dev, "%s:%d invalid cmd stream\n", __func__, __LINE__); + return r; + } + break; case PACKET3_WAIT_REG_MEM: if (pkt->count != 5) { DRM_ERROR("bad WAIT_REG_MEM\n"); diff --git a/drivers/gpu/drm/radeon/evergreend.h b/drivers/gpu/drm/radeon/evergreend.h index dfef8bf..4f2e02a 100644 --- a/drivers/gpu/drm/radeon/evergreend.h +++ b/drivers/gpu/drm/radeon/evergreend.h @@ -351,6 +351,7 @@ #defineCOLOR_BUFFER_SIZE(x)((x) << 0) #definePOSITION_BUFFER_SIZE(x) ((x) << 8) #defineSMX_BUFFER_SIZE(x) ((x) << 16) +#defineSX_MEMORY_EXPORT_BASE 0x9010 #defineSX_MISC 0x28350 #define CB_PERF_CTR0_SEL_0 0x9A20 @@ -1124,6 +1125,7 @@ #define CAYMAN_PA_SC_AA_CONFIG 0x28BE0 #define CAYMAN_MSAA_NUM_SAMPLES
[Bug 38089] New: Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)
https://bugs.freedesktop.org/show_bug.cgi?id=38089 Summary: Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920) Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: alexandre.f.dem...@gmail.com When playing Diablo 2 under Wine, I receive the following error in console: Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38089] New: Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920)
https://bugs.freedesktop.org/show_bug.cgi?id=38089 Summary: Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920) Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: alexandre.f.demers at gmail.com When playing Diablo 2 under Wine, I receive the following error in console: Mesa: User error: GL_INVALID_ENUM in glDisable(0x8920) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Harald Judt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Harald Judt 2011-06-08 14:38:32 PDT --- > can you disable page flipping and try again? It did not help, though it delayed the problems. However, I've upgraded to 3.0-rc2 and this solved all my problems. I'm not sure about this, but I think the problem was me pulling from drm-radeon-testing instead of only cherry-picking the latest commits. If this is really the case, I apologize for wasting your time. > /me hasn't run compiz on cayman yet too much. It works really great! Thanks for providing a better experience with the open-source drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Harald Judt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Harald Judt 2011-06-08 14:38:32 PDT --- > can you disable page flipping and try again? It did not help, though it delayed the problems. However, I've upgraded to 3.0-rc2 and this solved all my problems. I'm not sure about this, but I think the problem was me pulling from drm-radeon-testing instead of only cherry-picking the latest commits. If this is really the case, I apologize for wasting your time. > /me hasn't run compiz on cayman yet too much. It works really great! Thanks for providing a better experience with the open-source drivers. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Radeon drm: Hang with posting GPU when PCI card is primary
I have a PC for testing different addon cards & drivers. I recently set BIOS to use PCI graphics as primary to test PCI cards, and afterwards left it like this. However, it does not work when loading radeon DRM driver for AGP Radeon 7000 (RV100) card. The card is detected, DRM loaded and KMS initiated. Then DRM/KMS finds the card is not POSTed, decides to POST it and the whole computer hangs with [drm] GPU not posted. posting now... Full netconsole output below. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.0.0-rc2-00108-gcb0a02e (mroos at rhn) (gcc version 4.6.1 20110526 (prerelease) (Debian 4.6.0-10) ) #378 PREEMPT Wed Jun 8 13:43:58 EEST 2011 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ffc (usable) [0.00] BIOS-e820: 1ffc - 1fff8000 (ACPI data) [0.00] BIOS-e820: 1fff8000 - 2000 (ACPI NVS) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff0 - 0001 (reserved) [0.00] debug: ignoring loglevel setting. [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: /D815EEA2 , BIOS EA81520A.86A.0039.P21.0211061753 11/06/2002 [0.00] e820 update range: - 0001 (usable) ==> (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x1ffc0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-D uncachable [0.00] E-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask FE000 write-back [0.00] 1 base 02000 mask 0 write-back [0.00] 2 base 02000 mask 0 uncachable [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT not supported by CPU. [0.00] original variable MTRRs [0.00] reg 0, base: 0GB, range: 512MB, type WB [0.00] reg 1, base: 512MB, range: 1MB, type WB [0.00] reg 2, base: 512MB, range: 1MB, type UC [0.00] total RAM covered: 512M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 64K num_reg: 1 lose cover RAM: 0G [0.00] New variable MTRRs [0.00] reg 0, base: 0GB, range: 512MB, type WB [0.00] initial memory mapped : 0 - 0180 [0.00] Base memory trampoline at [c009e000] 9e000 size 4096 [0.00] init_memory_mapping: -1ffc [0.00] 00 - 40 page 4k [0.00] 40 - 001fc0 page 2M [0.00] 001fc0 - 001ffc page 4k [0.00] kernel direct mapping tables up to 1ffc @ 17fb000-180 [0.00] ACPI: RSDP 000ff980 00014 (v00 AMI ) [0.00] ACPI: RSDT 1fff 0002C (v01 D815EA D815EEA2 20021106 MSFT 1011) [0.00] ACPI: FACP 1fff1000 00074 (v01 D815EA EA81510A 20021106 MSFT 1011) [0.00] ACPI: DSDT 1ffe 030E4 (v01 D815E2 EA81520A 0023 MSFT 010B) [0.00] ACPI: FACS 1fff8000 00040 [0.00] ACPI: SSDT 1ffe30e4 00035 (v01 D815EA EA81510A 0015 MSFT 010B) [0.00] 511MB LOWMEM available. [0.00] mapped low ram: 0 - 1ffc [0.00] low ram: 0 - 1ffc [0.00] Zone PFN ranges: [0.00] DMA 0x0010 -> 0x1000 [0.00] Normal 0x1000 -> 0x0001ffc0 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0: 0x0010 -> 0x009f [0.00] 0: 0x0100 -> 0x0001ffc0 [0.00] On node 0 totalpages: 130895 [0.00] free_area_init_node: node 0, pgdat c139a4d0, node_mem_map dfbc0200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3951 pages, LIFO batch:0 [0.00] Normal zone: 992 pages used for memmap [0.00] Normal zone: 125920 pages, LIFO batch:31 [0.00] Using APIC driver default [0.00] ACPI: PM-Timer IO Port: 0x408 [0.00] Found and enabled local APIC! [0.00] Allocating PCI resources starting at 2000 (gap: 2000:dfb8) [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.0
[PATCH] bugfix and cleanup patches in the TTM code for 3.1.
> > > The bug-fix "ttm: Do not increment the amount of pages in a pool by the > > > current amount" > > > I never observed, but found while looking at the code. The cleanup patch: > > > "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted > > > earlier and Randy > > > Dunlap graciously added some extra cleanups - which I have rolled in. > > > > This is safe to put comments to the patch in the following place: Ok. Thanks will do.
[Bug 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 --- Comment #6 from almos 2011-06-08 13:45:53 PDT --- Maybe it's a hw limitation on r3xx? Perhaps large vertex buffers should be broken down into smaller ones. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 --- Comment #6 from almos 2011-06-08 13:45:53 PDT --- Maybe it's a hw limitation on r3xx? Perhaps large vertex buffers should be broken down into smaller ones. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #9 from almos 2011-06-08 13:36:35 PDT --- Created an attachment (id=47733) --> (https://bugs.freedesktop.org/attachment.cgi?id=47733) new_console.txt.gz (In reply to comment #8) > Created an attachment (id=47694) View: https://bugs.freedesktop.org/attachment.cgi?id=47694 Review: https://bugs.freedesktop.org/review?bug=37171&attachment=47694 > patch > > Could you post the log again with the patch applied? Also, does it fix > anything? New log attached. The patch doesn't seem to fix anything. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #9 from almos 2011-06-08 13:36:35 PDT --- Created an attachment (id=47733) --> (https://bugs.freedesktop.org/attachment.cgi?id=47733) new_console.txt.gz (In reply to comment #8) > Created an attachment (id=47694) View: https://bugs.freedesktop.org/attachment.cgi?id=47694 Review: https://bugs.freedesktop.org/review?bug=37171&attachment=47694 > patch > > Could you post the log again with the patch applied? Also, does it fix > anything? New log attached. The patch doesn't seem to fix anything. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] ttm: Fix spelling mistakes and remove unused #ifdef
. and some comments to make it easier to understand. Ackedby: Randy Dunlap [v2: Added some more updates from Randy Dunlap] Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 16 include/drm/ttm/ttm_bo_api.h |3 --- include/drm/ttm/ttm_bo_driver.h |6 +++--- include/drm/ttm/ttm_memory.h |2 +- include/drm/ttm/ttm_object.h |4 ++-- include/drm/ttm/ttm_page_alloc.h |2 +- 6 files changed, 15 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index 9d9d929..4db6fc7 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -355,7 +355,7 @@ restart: if (nr_free) goto restart; - /* Not allowed to fall tough or break because + /* Not allowed to fall through or break because * following context is inside spinlock while we are * outside here. */ @@ -554,7 +554,7 @@ out: } /** - * Fill the given pool if there isn't enough pages and requested number of + * Fill the given pool if there aren't enough pages and the requested number of * pages is small. */ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, @@ -574,8 +574,8 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, pool->fill_lock = true; - /* If allocation request is small and there is not enough -* pages in pool we fill the pool first */ + /* If allocation request is small and there are not enough +* pages in a pool we fill the pool up first. */ if (count < _manager->options.small && count > pool->npages) { struct list_head new_pages; @@ -612,9 +612,9 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, } /** - * Cut count nubmer of pages from the pool and put them to return list + * Cut 'count' number of pages from the pool and put them on the return list. * - * @return count of pages still to allocate to fill the request. + * @return count of pages still required to fulfill the request. */ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool, struct list_head *pages, int ttm_flags, @@ -635,7 +635,7 @@ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool, goto out; } /* find the last pages to include for requested number of pages. Split -* pool to begin and halves to reduce search space. */ +* pool to begin and halve it to reduce search space. */ if (count <= pool->npages/2) { i = 0; list_for_each(p, &pool->list) { @@ -649,7 +649,7 @@ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool, break; } } - /* Cut count number of pages from pool */ + /* Cut 'count' number of pages from the pool */ list_cut_position(pages, &pool->list, p); pool->npages -= count; count = 0; diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index 62a0e4c..42e3469 100644 --- a/include/drm/ttm/ttm_bo_api.h +++ b/include/drm/ttm/ttm_bo_api.h @@ -662,9 +662,6 @@ extern int ttm_bo_kmap(struct ttm_buffer_object *bo, unsigned long start_page, extern void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map); -#if 0 -#endif - /** * ttm_fbdev_mmap - mmap fbdev memory backed by a ttm buffer object. * diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 09af2d7..94eb143 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -78,7 +78,7 @@ struct ttm_backend_func { * * Bind the backend pages into the aperture in the location * indicated by @bo_mem. This function should be able to handle -* differences between aperture- and system page sizes. +* differences between aperture and system page sizes. */ int (*bind) (struct ttm_backend *backend, struct ttm_mem_reg *bo_mem); @@ -88,7 +88,7 @@ struct ttm_backend_func { * @backend: Pointer to a struct ttm_backend. * * Unbind previously bound backend pages. This function should be -* able to handle differences between aperture- and system page sizes. +* able to handle differences between aperture and system page sizes. */ int (*unbind) (struct ttm_backend *backend); @@ -786,7 +786,7 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); * ttm_bo_device_init * * @bdev: A pointer to a struct ttm_bo_device to initialize. - * @mem_global: A pointer to an initialized struct ttm_mem_global. + * @glob: A pointer to an initialized struct ttm_bo_global. * @driver: A pointer to a struct t
[PATCH] ttm: Do not increment the amount of pages in a pool by the current amount
.instead increment it by the count of pages that we want to splice into the pool list. In other words we were incrementing the pool->npages by the wrong amount. This bug was observed from code inspection. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_page_alloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index d948575..002b414 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -602,7 +602,7 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, printk(KERN_ERR TTM_PFX "Failed to fill pool (%p).", pool); /* If we have any pages left put them to the pool. */ - list_for_each_entry(p, &pool->list, lru) { + list_for_each_entry(p, &new_pages, lru) { ++cpages; } list_splice(&new_pages, &pool->list); -- 1.7.4.1
[PATCH] bugfix and cleanup patches in the TTM code for 3.1.
The bug-fix "ttm: Do not increment the amount of pages in a pool by the current amount" I never observed, but found while looking at the code. The cleanup patch: "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier and Randy Dunlap graciously added some extra cleanups - which I have rolled in.
[PATCH] drm/radeon/kms: check modes against max pixel clock
Filter out modes that are higher than the max pixel clock. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h|1 + drivers/gpu/drm/radeon/radeon_atombios.c |4 drivers/gpu/drm/radeon/radeon_clocks.c |8 +--- drivers/gpu/drm/radeon/radeon_combios.c|5 + drivers/gpu/drm/radeon/radeon_connectors.c | 13 - 5 files changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 625f1af..bbcb00a 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -165,6 +165,7 @@ struct radeon_clock { uint32_t default_sclk; uint32_t default_dispclk; uint32_t dp_extclk; + uint32_t max_pixel_clock; }; /* diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index 90dfb2b..fa62a50 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1246,6 +1246,10 @@ bool radeon_atom_get_clock_info(struct drm_device *dev) } *dcpll = *p1pll; + rdev->clock.max_pixel_clock = le16_to_cpu(firmware_info->info.usMaxPixelClock); + if (rdev->clock.max_pixel_clock == 0) + rdev->clock.max_pixel_clock = 4; + return true; } diff --git a/drivers/gpu/drm/radeon/radeon_clocks.c b/drivers/gpu/drm/radeon/radeon_clocks.c index 5249af8..2d48e7a 100644 --- a/drivers/gpu/drm/radeon/radeon_clocks.c +++ b/drivers/gpu/drm/radeon/radeon_clocks.c @@ -117,7 +117,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) p1pll->reference_div = RREG32_PLL(RADEON_PPLL_REF_DIV) & 0x3ff; if (p1pll->reference_div < 2) p1pll->reference_div = 12; - p2pll->reference_div = p1pll->reference_div; + p2pll->reference_div = p1pll->reference_div; /* These aren't in the device-tree */ if (rdev->family >= CHIP_R420) { @@ -139,6 +139,8 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) p2pll->pll_out_min = 12500; p2pll->pll_out_max = 35000; } + /* not sure what the max should be in all cases */ + rdev->clock.max_pixel_clock = 35000; spll->reference_freq = mpll->reference_freq = p1pll->reference_freq; spll->reference_div = mpll->reference_div = @@ -151,7 +153,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) else rdev->clock.default_sclk = radeon_legacy_get_engine_clock(rdev); - + val = of_get_property(dp, "ATY,MCLK", NULL); if (val && *val) rdev->clock.default_mclk = (*val) / 10; @@ -160,7 +162,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) radeon_legacy_get_memory_clock(rdev); DRM_INFO("Using device-tree clock info\n"); - + return true; } #else diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index 19b10cf..797c8bc 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -866,6 +866,11 @@ bool radeon_combios_get_clock_info(struct drm_device *dev) rdev->clock.default_sclk = sclk; rdev->clock.default_mclk = mclk; + if (RBIOS32(pll_info + 0x16)) + rdev->clock.max_pixel_clock = RBIOS32(pll_info + 0x16); + else + rdev->clock.max_pixel_clock = 35000; /* might need something asic specific */ + return true; } return false; diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 9dc8684..1d1504b 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -628,8 +628,14 @@ static int radeon_vga_get_modes(struct drm_connector *connector) static int radeon_vga_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) { + struct drm_device *dev = connector->dev; + struct radeon_device *rdev = dev->dev_private; + /* XXX check mode bandwidth */ - /* XXX verify against max DAC output frequency */ + + if ((mode->clock / 10) > rdev->clock.max_pixel_clock) + return MODE_CLOCK_HIGH; + return MODE_OK; } @@ -1017,6 +1023,11 @@ static int radeon_dvi_mode_valid(struct drm_connector *connector, } else return MODE_CLOCK_HIGH; } + + /* check against the max pixel clock */ + if ((mode->clock / 10) > rdev->clock.max_pixel_clock) + return MODE_CLOCK_HIGH; + return MODE_OK; } -- 1.7.1.1
Modeline problem with Radeon KMS
On Wed, Jun 8, 2011 at 11:31 AM, Meelis Roos wrote: >> > I have LG Flatron F900P CRT monitor. X drivers work fine, nouveau KMS >> > works fine but Radeon KMS selects a videomode that is out of spec for >> > monitor. This is not a regression - this hardware combination has never >> > worked for me yet with radeon KMS. The result is same for Radeon 7000 >> > (RV100, currently installed) and Radeon 9200 series card. > > Umm, I guess I forgot one important aspect. When X comes up, it finds a > good video mode and gets a picture. It's just the text consoles that > have no picture. > > In the console, it tells it's using 352x132 console. This translates > with 8x16 font to 2816x2112 and 9x16 font to 3168x2112 if I calculated > the right thing. > > Running fbset remotely verifies this: > > # fbset -s > mode "2816x2114" > ? ?geometry 2816 2114 2816 2114 8 > ? ?timings 0 0 0 0 0 0 0 > ? ?accel true > ? ?rgba 8/0,8/0,8/0,0/0 > endmode > > So it decides this modeline is usable for the console while it is not. > Ah, ok. yeah, that mode has a much higher clock than those chips can handle. Where is that mode even coming from? I don't see it in the EDID. The attached patch should filter out that mode. Alex -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-kms-check-modes-against-max-pixel-clock.patch Type: text/x-patch Size: 4592 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110608/2c5f781d/attachment.bin>
[Bug 36962] [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled
https://bugzilla.kernel.org/show_bug.cgi?id=36962 Maciej Rutecki changed: What|Removed |Added Blocks||32012 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36962] New: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled
https://bugzilla.kernel.org/show_bug.cgi?id=36962 Summary: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled Product: Drivers Version: 2.5 Kernel Version: 2.6.39 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: maciej.rute...@gmail.com CC: kaffeemons...@googlemail.com, r...@sisk.pl, maciej.rute...@gmail.com Regression: Yes Subject: [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled Submitter : Jan Seiffert Date : 2011-05-25 2:32 Message-ID : banlktimd6nvxtbn2hm+ckdnkfpxzsql...@mail.gmail.com References : http://marc.info/?l=linux-kernel&m=130629073407685&w=2 This entry is being used for tracking a regression from 2.6.38. Please don't close it until the problem is fixed in the mainline. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add initial CS checker support for compute
- Add some new compute regs - Add new dispatch packets for evergreen/cayman Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/evergreen_cs.c | 57 - drivers/gpu/drm/radeon/evergreend.h |2 + drivers/gpu/drm/radeon/r600_cs.c |9 + drivers/gpu/drm/radeon/radeon_drv.c |2 +- drivers/gpu/drm/radeon/reg_srcs/cayman|2 + drivers/gpu/drm/radeon/reg_srcs/evergreen |3 ++ drivers/gpu/drm/radeon/reg_srcs/r600 |1 + 7 files changed, 74 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index 7bdaf41..f69599e 100644 --- a/drivers/gpu/drm/radeon/evergreen_cs.c +++ b/drivers/gpu/drm/radeon/evergreen_cs.c @@ -871,7 +871,6 @@ static inline int evergreen_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u3 case SQ_PGM_START_PS: case SQ_PGM_START_HS: case SQ_PGM_START_LS: - case GDS_ADDR_BASE: case SQ_CONST_MEM_BASE: case SQ_ALU_CONST_CACHE_GS_0: case SQ_ALU_CONST_CACHE_GS_1: @@ -961,6 +960,34 @@ static inline int evergreen_cs_check_reg(struct radeon_cs_parser *p, u32 reg, u3 } ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x); break; + case SX_MEMORY_EXPORT_BASE: + if (p->rdev->family >= CHIP_CAYMAN) { + dev_warn(p->dev, "bad SET_CONFIG_REG " +"0x%04X\n", reg); + return -EINVAL; + } + r = evergreen_cs_packet_next_reloc(p, &reloc); + if (r) { + dev_warn(p->dev, "bad SET_CONFIG_REG " + "0x%04X\n", reg); + return -EINVAL; + } + ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x); + break; + case CAYMAN_SX_SCATTER_EXPORT_BASE: + if (p->rdev->family < CHIP_CAYMAN) { + dev_warn(p->dev, "bad SET_CONTEXT_REG " +"0x%04X\n", reg); + return -EINVAL; + } + r = evergreen_cs_packet_next_reloc(p, &reloc); + if (r) { + dev_warn(p->dev, "bad SET_CONTEXT_REG " + "0x%04X\n", reg); + return -EINVAL; + } + ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x); + break; default: dev_warn(p->dev, "forbidden register 0x%08x at %d\n", reg, idx); return -EINVAL; @@ -1168,6 +1195,34 @@ static int evergreen_packet3_check(struct radeon_cs_parser *p, return r; } break; + case PACKET3_DISPATCH_DIRECT: + if (pkt->count != 3) { + DRM_ERROR("bad DISPATCH_DIRECT\n"); + return -EINVAL; + } + r = evergreen_cs_track_check(p); + if (r) { + dev_warn(p->dev, "%s:%d invalid cmd stream %d\n", __func__, __LINE__, idx); + return r; + } + break; + case PACKET3_DISPATCH_INDIRECT: + if (pkt->count != 1) { + DRM_ERROR("bad DISPATCH_INDIRECT\n"); + return -EINVAL; + } + r = evergreen_cs_packet_next_reloc(p, &reloc); + if (r) { + DRM_ERROR("bad DISPATCH_INDIRECT\n"); + return -EINVAL; + } + ib[idx+0] = idx_value + (u32)(reloc->lobj.gpu_offset & 0x); + r = evergreen_cs_track_check(p); + if (r) { + dev_warn(p->dev, "%s:%d invalid cmd stream\n", __func__, __LINE__); + return r; + } + break; case PACKET3_WAIT_REG_MEM: if (pkt->count != 5) { DRM_ERROR("bad WAIT_REG_MEM\n"); diff --git a/drivers/gpu/drm/radeon/evergreend.h b/drivers/gpu/drm/radeon/evergreend.h index dfef8bf..4f2e02a 100644 --- a/drivers/gpu/drm/radeon/evergreend.h +++ b/drivers/gpu/drm/radeon/evergreend.h @@ -351,6 +351,7 @@ #defineCOLOR_BUFFER_SIZE(x)((x) << 0) #definePOSITION_BUFFER_SIZE(x) ((x) << 8) #defineSMX_BUFFER_SIZE(x) ((x) << 16) +#defineSX_MEMORY_EXPORT_BASE 0x9010 #defineSX_MISC 0x28350 #define CB_PERF_CTR0_SEL_0 0x9A20 @@ -1124,6 +1125,7 @@ #define CAYMAN_PA_SC_AA_CONFIG 0x28BE0 #define CAYMAN_MSAA_NUM_SAMPLE
[PATCH] drm: Honour O_NONBLOCK on the device for reading events
Otherwise drmHandleEvent will block if accidentally read too often... Signed-off-by: Chris Wilson Cc: Phillip Haddad --- drivers/gpu/drm/drm_fops.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 2ec7d48..279aa95 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -617,6 +617,9 @@ ssize_t drm_read(struct file *filp, char __user *buffer, size_t total; ssize_t ret; + if (filp->f_flags & O_NONBLOCK && list_empty(&file_priv->event_list)) + return -EAGAIN; + ret = wait_event_interruptible(file_priv->event_wait, !list_empty(&file_priv->event_list)); if (ret < 0) -- 1.7.5.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: add plane support
On Wed, 8 Jun 2011 11:41:17 +0200 Marcus Lorentzon wrote: > On 06/07/2011 11:01 PM, Jesse Barnes wrote: > > On Tue, 7 Jun 2011 13:07:39 -0700 > > Jesse Barnes wrote: > > > > > >> +/* Planes blend with or override other bits on the CRTC */ > >> +struct drm_mode_set_plane { > >> + __u32 plane_id; > >> + __u32 crtc_id; > >> + __u32 fb_id; /* contains surface format type */ > >> + > >> + __u32 crtc_x, crtc_y; > >> + __u32 x, y; > >> + > >> + /* FIXME: color key/mask, scaling, z-order, other? */ > >> +}; > >> > > Forgot to add the scaling factors to this. Would: > >__u32 scaling_x; /* fixed 16.16 format */ > >__u32 scaling_y; > > work for people? > > > > If you want to pan around in zoomed in video/viewfinder/snapshots it > might be better to have a fixed 16.16 source rectangle and a integer > destination rectangle. That way you can move around the zoomed in source > rectangle in small increments and upscale it to destination rectangle > (and skip fractions if HW don't support it). For example, if you zoom 4x > and have only fixed 16.16 scaling factor, you still get the the integer > fb (x, y) position in the top left corner (crtc_x, crtc_y) of the > overlay. And when you pan in the overlay, you will have to move source > rectangle in 4 destination pixel increments. So what about this instead: > > __u32 x, y, src_w, src_h; /* fixed 16.16 */ > __u32 crtc_x, crtc_y, crtc_w, crtc_h; > > Maybe rename x, y to src_x, src_y? crtc_w/h is needed to define zoom > factor (scaling_[wh] = crtc_[wh] / src_[wh]). > > So the "zoom transform" would be defined by (src_x, src_y, src_w, src_h) > => (crtc_x, crtc_y, crtc_w, crtc_h) > > It also gets rid of how to handle corner cases where scaling factor > defines a source area outside source fb. Now you can just say both rect > has to be inside crtc/fb. And you can also animate/move/clip a zoomed > overlay off screen without picture jumping (fb and display coords don't > align when zoomed). > > Summary, rectangles allow more precise representation of zoom factor, > and 16.16 source coords for stable image when moving overlay off screen > (clipping) or panning overlay content. > > BTW. Why not just add "__s32 z;" too? drm_mode_set_plane seems to be > plane position setup. Yeah, all good points. I was thinking the source info could be mostly gleaned from the associated fb, but if you have hw that can source just a rect and scale it, passing rects around makes the most sense. And z-order is a trivial addition, so I have no problem with that. But communicating plane blending restrictions (including z-order) still has to be done with a separate ioctl. But that should probably be added by someone who has crazy hardware and the ability to test it! Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: add plane support
On Wed, 8 Jun 2011 11:41:17 +0200 Marcus Lorentzon wrote: > On 06/07/2011 11:01 PM, Jesse Barnes wrote: > > On Tue, 7 Jun 2011 13:07:39 -0700 > > Jesse Barnes wrote: > > > > > >> +/* Planes blend with or override other bits on the CRTC */ > >> +struct drm_mode_set_plane { > >> + __u32 plane_id; > >> + __u32 crtc_id; > >> + __u32 fb_id; /* contains surface format type */ > >> + > >> + __u32 crtc_x, crtc_y; > >> + __u32 x, y; > >> + > >> + /* FIXME: color key/mask, scaling, z-order, other? */ > >> +}; > >> > > Forgot to add the scaling factors to this. Would: > >__u32 scaling_x; /* fixed 16.16 format */ > >__u32 scaling_y; > > work for people? > > > > If you want to pan around in zoomed in video/viewfinder/snapshots it > might be better to have a fixed 16.16 source rectangle and a integer > destination rectangle. That way you can move around the zoomed in source > rectangle in small increments and upscale it to destination rectangle > (and skip fractions if HW don't support it). For example, if you zoom 4x > and have only fixed 16.16 scaling factor, you still get the the integer > fb (x, y) position in the top left corner (crtc_x, crtc_y) of the > overlay. And when you pan in the overlay, you will have to move source > rectangle in 4 destination pixel increments. So what about this instead: > > __u32 x, y, src_w, src_h; /* fixed 16.16 */ > __u32 crtc_x, crtc_y, crtc_w, crtc_h; > > Maybe rename x, y to src_x, src_y? crtc_w/h is needed to define zoom > factor (scaling_[wh] = crtc_[wh] / src_[wh]). > > So the "zoom transform" would be defined by (src_x, src_y, src_w, src_h) > => (crtc_x, crtc_y, crtc_w, crtc_h) > > It also gets rid of how to handle corner cases where scaling factor > defines a source area outside source fb. Now you can just say both rect > has to be inside crtc/fb. And you can also animate/move/clip a zoomed > overlay off screen without picture jumping (fb and display coords don't > align when zoomed). > > Summary, rectangles allow more precise representation of zoom factor, > and 16.16 source coords for stable image when moving overlay off screen > (clipping) or panning overlay content. > > BTW. Why not just add "__s32 z;" too? drm_mode_set_plane seems to be > plane position setup. Yeah, all good points. I was thinking the source info could be mostly gleaned from the associated fb, but if you have hw that can source just a rect and scale it, passing rects around makes the most sense. And z-order is a trivial addition, so I have no problem with that. But communicating plane blending restrictions (including z-order) still has to be done with a separate ioctl. But that should probably be added by someone who has crazy hardware and the ability to test it! Thanks, -- Jesse Barnes, Intel Open Source Technology Center
[PATCH 1/4] drm: add plane support
On 06/07/2011 11:01 PM, Jesse Barnes wrote: > On Tue, 7 Jun 2011 13:07:39 -0700 > Jesse Barnes wrote: > > >> +/* Planes blend with or override other bits on the CRTC */ >> +struct drm_mode_set_plane { >> +__u32 plane_id; >> +__u32 crtc_id; >> +__u32 fb_id; /* contains surface format type */ >> + >> +__u32 crtc_x, crtc_y; >> +__u32 x, y; >> + >> +/* FIXME: color key/mask, scaling, z-order, other? */ >> +}; >> > Forgot to add the scaling factors to this. Would: >__u32 scaling_x; /* fixed 16.16 format */ >__u32 scaling_y; > work for people? > If you want to pan around in zoomed in video/viewfinder/snapshots it might be better to have a fixed 16.16 source rectangle and a integer destination rectangle. That way you can move around the zoomed in source rectangle in small increments and upscale it to destination rectangle (and skip fractions if HW don't support it). For example, if you zoom 4x and have only fixed 16.16 scaling factor, you still get the the integer fb (x, y) position in the top left corner (crtc_x, crtc_y) of the overlay. And when you pan in the overlay, you will have to move source rectangle in 4 destination pixel increments. So what about this instead: __u32 x, y, src_w, src_h; /* fixed 16.16 */ __u32 crtc_x, crtc_y, crtc_w, crtc_h; Maybe rename x, y to src_x, src_y? crtc_w/h is needed to define zoom factor (scaling_[wh] = crtc_[wh] / src_[wh]). So the "zoom transform" would be defined by (src_x, src_y, src_w, src_h) => (crtc_x, crtc_y, crtc_w, crtc_h) It also gets rid of how to handle corner cases where scaling factor defines a source area outside source fb. Now you can just say both rect has to be inside crtc/fb. And you can also animate/move/clip a zoomed overlay off screen without picture jumping (fb and display coords don't align when zoomed). Summary, rectangles allow more precise representation of zoom factor, and 16.16 source coords for stable image when moving overlay off screen (clipping) or panning overlay content. BTW. Why not just add "__s32 z;" too? drm_mode_set_plane seems to be plane position setup. /BR /Marcus
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #6 from Pascal Billery-Schneider 2011-06-08 11:25:03 PDT --- Created an attachment (id=47729) --> (https://bugs.freedesktop.org/attachment.cgi?id=47729) Blender screenshots portions after mesa git -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #6 from Pascal Billery-Schneider 2011-06-08 11:25:03 PDT --- Created an attachment (id=47729) --> (https://bugs.freedesktop.org/attachment.cgi?id=47729) Blender screenshots portions after mesa git -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm radeon urgent fixes
> > Hi Linus, > > I'm blaming 3.0 for me not seeing this breakage, I'm having trouble > persuading my USB disk to boot 3.0, on an F15 userspace looks like LVM or > something systemd related. > > 1 is really urgent but the other two fixes some machines + blank screens. correctly attributed patches and changelog below (lost Daniel's author line). > > Dave. > The following changes since commit cb0a02ecf95e5f47d92e7d4c513cc1f7aeb40cda: Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2011-06-07 19:21:11 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-urgent Alex Deucher (1): drm/radeon/kms: disable hdmi audio by default Daniel Haid (1): drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu Dave Airlie (1): drm/radeon/kms: set family for use in parser. drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_device.c |1 + drivers/gpu/drm/radeon/radeon_drv.c|4 ++-- 3 files changed, 4 insertions(+), 2 deletions(-)
Re: [PATCH] bugfix and cleanup patches in the TTM code for 3.1.
> > > The bug-fix "ttm: Do not increment the amount of pages in a pool by the > > > current amount" > > > I never observed, but found while looking at the code. The cleanup patch: > > > "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted > > > earlier and Randy > > > Dunlap graciously added some extra cleanups - which I have rolled in. > > > > This is safe to put comments to the patch in the following place: Ok. Thanks will do. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm radeon urgent fixes
Hi Linus, I'm blaming 3.0 for me not seeing this breakage, I'm having trouble persuading my USB disk to boot 3.0, on an F15 userspace looks like LVM or something systemd related. 1 is really urgent but the other two fixes some machines + blank screens. Dave. The following changes since commit cb0a02ecf95e5f47d92e7d4c513cc1f7aeb40cda: Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip (2011-06-07 19:21:11 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-radeon-urgent Alex Deucher (1): drm/radeon/kms: disable hdmi audio by default Dave Airlie (2): drm/radeon/kms: set family for use in parser. drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu drivers/gpu/drm/radeon/radeon_cs.c |1 + drivers/gpu/drm/radeon/radeon_device.c |1 + drivers/gpu/drm/radeon/radeon_drv.c|4 ++-- 3 files changed, 4 insertions(+), 2 deletions(-)
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #5 from Pascal Billery-Schneider 2011-06-08 11:17:10 PDT --- So. It seems much better with git mesa. I've made a small try therefore. No need to specify a GL variable to display the fonts, no crash when opening dialogbox. But there are still little artefacts when mouse cursor is "hovering" menus or buttons. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #5 from Pascal Billery-Schneider 2011-06-08 11:17:10 PDT --- So. It seems much better with git mesa. I've made a small try therefore. No need to specify a GL variable to display the fonts, no crash when opening dialogbox. But there are still little artefacts when mouse cursor is "hovering" menus or buttons. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 15/15] gma500: Kill spare kref
From: Alan Cox We are using the underlying kref in the GEM object so we don't need our own Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_fb.c |1 - drivers/staging/gma500/psb_gtt.c | 41 ++ drivers/staging/gma500/psb_gtt.h |1 - 3 files changed, 6 insertions(+), 37 deletions(-) diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c index 988f4db..fb75aba 100644 --- a/drivers/staging/gma500/psb_fb.c +++ b/drivers/staging/gma500/psb_fb.c @@ -231,7 +231,6 @@ static int psbfb_mmap(struct fb_info *info, struct vm_area_struct *vma) struct psb_fbdev *fbdev = info->par; struct psb_framebuffer *psbfb = &fbdev->pfb; char *fb_screen_base = NULL; - struct drm_device *dev = psbfb->base.dev; if (vma->vm_pgoff != 0) return -EINVAL; diff --git a/drivers/staging/gma500/psb_gtt.c b/drivers/staging/gma500/psb_gtt.c index 54a9308..9da1375 100644 --- a/drivers/staging/gma500/psb_gtt.c +++ b/drivers/staging/gma500/psb_gtt.c @@ -303,8 +303,6 @@ struct gtt_range *psb_gtt_alloc_range(struct drm_device *dev, int len, gt->in_gart = backed; /* Ensure this is set for non GEM objects */ gt->gem.dev = dev; - kref_init(>->kref); - ret = allocate_resource(dev_priv->gtt_mem, >->resource, len, start, end, PAGE_SIZE, NULL, NULL); if (ret == 0) { @@ -316,18 +314,15 @@ struct gtt_range *psb_gtt_alloc_range(struct drm_device *dev, int len, } /** - * psb_gtt_destroy - final free up of a gtt - * @kref: the kref of the gtt - * - * Called from the kernel kref put when the final reference to our - * GTT object is dropped. At that point we can free up the resources. + * psb_gtt_free_range - release GTT address space + * @dev: our DRM device + * @gt: a mapping created with psb_gtt_alloc_range * - * For now we handle mmap clean up here to work around limits in GEM + * Release a resource that was allocated with psb_gtt_alloc_range. If the object + * has been pinned by mmap users we clean this up here currently. */ -static void psb_gtt_destroy(struct kref *kref) +void psb_gtt_free_range(struct drm_device *dev, struct gtt_range *gt) { - struct gtt_range *gt = container_of(kref, struct gtt_range, kref); - /* Undo the mmap pin if we are destroying the object */ if (gt->mmapping) { psb_gtt_unpin(gt); @@ -338,30 +333,6 @@ static void psb_gtt_destroy(struct kref *kref) kfree(gt); } -/** - * psb_gtt_kref_put- drop reference to a GTT object - * @gt: the GT being dropped - * - * Drop a reference to a psb gtt - */ -void psb_gtt_kref_put(struct gtt_range *gt) -{ - kref_put(>->kref, psb_gtt_destroy); -} - -/** - * psb_gtt_free_range - release GTT address space - * @dev: our DRM device - * @gt: a mapping created with psb_gtt_alloc_range - * - * Release a resource that was allocated with psb_gtt_alloc_range - */ -void psb_gtt_free_range(struct drm_device *dev, struct gtt_range *gt) -{ - psb_gtt_kref_put(gt); -} - - struct psb_gtt *psb_gtt_alloc(struct drm_device *dev) { struct psb_gtt *tmp = kzalloc(sizeof(*tmp), GFP_KERNEL); diff --git a/drivers/staging/gma500/psb_gtt.h b/drivers/staging/gma500/psb_gtt.h index 7e1f21e..4d6dc5f 100644 --- a/drivers/staging/gma500/psb_gtt.h +++ b/drivers/staging/gma500/psb_gtt.h @@ -44,7 +44,6 @@ extern void psb_gtt_takedown(struct drm_device *dev); struct gtt_range { struct resource resource; /* Resource for our allocation */ u32 offset; /* GTT offset of our object */ - struct kref kref; /* Can probably go FIXME - GEM kref will do */ struct drm_gem_object gem; /* GEM high level stuff */ int in_gart;/* Currently in the GART (ref ct) */ bool stolen;/* Backed from stolen RAM */
[PATCH 14/15] gma500: nuke the PSB debug stuff
From: Alan Cox Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal drivers if and when we need debug on stuff. Signed-off-by: Alan Cox --- drivers/staging/gma500/mrst_crtc.c | 23 ++ drivers/staging/gma500/mrst_lvds.c | 12 +-- drivers/staging/gma500/psb_bl.c |8 -- drivers/staging/gma500/psb_drv.c| 33 +++-- drivers/staging/gma500/psb_drv.h| 96 +++--- drivers/staging/gma500/psb_fb.c | 34 + drivers/staging/gma500/psb_gem.c|6 +- drivers/staging/gma500/psb_gtt.c|6 +- drivers/staging/gma500/psb_intel_bios.c | 17 + drivers/staging/gma500/psb_intel_display.c | 99 +++ drivers/staging/gma500/psb_intel_lvds.c | 53 ++ drivers/staging/gma500/psb_intel_opregion.c |7 -- drivers/staging/gma500/psb_intel_sdvo.c | 34 - drivers/staging/gma500/psb_irq.c| 33 ++--- 14 files changed, 87 insertions(+), 374 deletions(-) diff --git a/drivers/staging/gma500/mrst_crtc.c b/drivers/staging/gma500/mrst_crtc.c index fd97c80..fb9f2a2 100644 --- a/drivers/staging/gma500/mrst_crtc.c +++ b/drivers/staging/gma500/mrst_crtc.c @@ -103,7 +103,7 @@ static const struct mrst_limit_t *mrst_limit(struct drm_crtc *crtc) } } else { limit = NULL; - PSB_DEBUG_ENTRY("mrst_limit Wrong display type.\n"); + dev_err(dev->dev, "mrst_limit Wrong display type.\n"); } return limit; @@ -117,7 +117,7 @@ static void mrst_clock(int refclk, struct mrst_clock_t *clock) void mrstPrintPll(char *prefix, struct mrst_clock_t *clock) { - PSB_DEBUG_ENTRY("%s: dotclock = %d, m = %d, p1 = %d.\n", + pr_debug("%s: dotclock = %d, m = %d, p1 = %d.\n", prefix, clock->dot, clock->m, clock->p1); } @@ -149,8 +149,7 @@ mrstFindBestPLL(struct drm_crtc *crtc, int target, int refclk, } } } - DRM_DEBUG("mrstFindBestPLL err = %d.\n", err); - + dev_dbg(crtc->dev->dev, "mrstFindBestPLL err = %d.\n", err); return err != target; } @@ -172,8 +171,6 @@ static void mrst_crtc_dpms(struct drm_crtc *crtc, int mode) u32 temp; bool enabled; - PSB_DEBUG_ENTRY("mode = %d, pipe = %d\n", mode, pipe); - if (!gma_power_begin(dev, true)) return; @@ -320,8 +317,6 @@ static int mrst_crtc_mode_set(struct drm_crtc *crtc, uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN; struct drm_encoder *encoder; - PSB_DEBUG_ENTRY("pipe = 0x%x\n", pipe); - if (!gma_power_begin(dev, true)) return 0; @@ -446,10 +441,9 @@ static int mrst_crtc_mode_set(struct drm_crtc *crtc, ok = mrstFindBestPLL(crtc, adjusted_mode->clock, refclk, &clock); if (!ok) { - PSB_DEBUG_ENTRY( - "mrstFindBestPLL fail in mrst_crtc_mode_set.\n"); + dev_dbg(dev->dev, "mrstFindBestPLL fail in mrst_crtc_mode_set.\n"); } else { - PSB_DEBUG_ENTRY("mrst_crtc_mode_set pixel clock = %d," + dev_dbg(dev->dev, "mrst_crtc_mode_set pixel clock = %d," "m = %x, p1 = %x.\n", clock.dot, clock.m, clock.p1); } @@ -540,11 +534,9 @@ int mrst_pipe_set_base(struct drm_crtc *crtc, u32 dspcntr; int ret = 0; - PSB_DEBUG_ENTRY("\n"); - /* no fb bound */ if (!crtc->fb) { - DRM_DEBUG("No FB bound\n"); + dev_dbg(dev->dev, "No FB bound\n"); return 0; } @@ -574,13 +566,12 @@ int mrst_pipe_set_base(struct drm_crtc *crtc, dspcntr |= DISPPLANE_32BPP_NO_ALPHA; break; default: - DRM_ERROR("Unknown color depth\n"); + dev_err(dev->dev, "Unknown color depth\n"); ret = -EINVAL; goto pipe_set_base_exit; } REG_WRITE(dspcntr_reg, dspcntr); - DRM_DEBUG("Writing base %08lX %08lX %d %d\n", start, offset, x, y); if (0 /* FIXMEAC - check what PSB needs */) { REG_WRITE(dspbase, offset); REG_READ(dspbase); diff --git a/drivers/staging/gma500/mrst_lvds.c b/drivers/staging/gma500/mrst_lvds.c index 22ea00e..aac80cc 100644 --- a/drivers/staging/gma500/mrst_lvds.c +++ b/drivers/staging/gma500/mrst_lvds.c @@ -47,7 +47,6 @@ static void mrst_lvds_set_power(struct drm_device *dev, { u32 pp_status; struct drm_psb_private *dev_priv = dev->dev_private; - PSB_DEBUG_ENTRY("\n"); if (!gma_power_begin(dev, true)) return; @@ -77,8 +76,6 @@ static void mrst_lvds_dpms(struct drm_encoder *encoder, int mode) struct drm_device *dev = encoder->dev; struct psb_intel_output *output = enc_to_psb_intel_o
[PATCH 13/15] gma500: nuke the last bits of TTM code
From: Alan Cox We don't seem to need this for our task. Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_drv.c |6 drivers/staging/gma500/psb_gtt.c | 62 -- 2 files changed, 19 insertions(+), 49 deletions(-) diff --git a/drivers/staging/gma500/psb_drv.c b/drivers/staging/gma500/psb_drv.c index 9bd0a5d..ab1da30 100644 --- a/drivers/staging/gma500/psb_drv.c +++ b/drivers/staging/gma500/psb_drv.c @@ -409,8 +409,6 @@ static int psb_do_init(struct drm_device *dev) struct psb_gtt *pg = dev_priv->pg; uint32_t stolen_gtt; - uint32_t tt_start; - uint32_t tt_pages; int ret = -ENOMEM; @@ -449,10 +447,6 @@ static int psb_do_init(struct drm_device *dev) spin_lock_init(&dev_priv->irqmask_lock); - tt_pages = (pg->gatt_pages < PSB_TT_PRIV0_PLIMIT) ? - pg->gatt_pages : PSB_TT_PRIV0_PLIMIT; - tt_start = dev_priv->gatt_free_offset - pg->mmu_gatt_start; - tt_pages -= tt_start >> PAGE_SHIFT; /* FIXME: can we kill ta_mem_size ? */ dev_priv->sizes.ta_mem_size = 0; diff --git a/drivers/staging/gma500/psb_gtt.c b/drivers/staging/gma500/psb_gtt.c index 5a296e1..8fcb833 100644 --- a/drivers/staging/gma500/psb_gtt.c +++ b/drivers/staging/gma500/psb_gtt.c @@ -138,8 +138,6 @@ static void psb_gtt_remove(struct drm_device *dev, struct gtt_range *r) * * Pin and build an in kernel list of the pages that back our GEM object. * While we hold this the pages cannot be swapped out - * - * FIXME: Do we need to cache flush when we update the GTT */ static int psb_gtt_attach_pages(struct gtt_range *gt) { @@ -185,8 +183,6 @@ err: * Undo the effect of psb_gtt_attach_pages. At this point the pages * must have been removed from the GTT as they could now be paged out * and move bus address. - * - * FIXME: Do we need to cache flush when we update the GTT */ static void psb_gtt_detach_pages(struct gtt_range *gt) { @@ -194,7 +190,6 @@ static void psb_gtt_detach_pages(struct gtt_range *gt) for (i = 0; i < gt->npage; i++) { /* FIXME: do we need to force dirty */ set_page_dirty(gt->pages[i]); - /* Undo the reference we took when populating the table */ page_cache_release(gt->pages[i]); } kfree(gt->pages); @@ -384,7 +379,6 @@ void psb_gtt_takedown(struct drm_device *dev) { struct drm_psb_private *dev_priv = dev->dev_private; - /* FIXME: iounmap dev_priv->vram_addr etc */ if (dev_priv->gtt_map) { iounmap(dev_priv->gtt_map); dev_priv->gtt_map = NULL; @@ -395,6 +389,8 @@ void psb_gtt_takedown(struct drm_device *dev) PSB_WVDC32(dev_priv->pge_ctl, PSB_PGETBL_CTL); (void) PSB_RVDC32(PSB_PGETBL_CTL); } + if (dev_priv->vram_addr) + iounmap(dev_priv->gtt_map); kfree(dev_priv->pg); dev_priv->pg = NULL; } @@ -407,8 +403,6 @@ int psb_gtt_init(struct drm_device *dev, int resume) unsigned i, num_pages; unsigned pfn_base; uint32_t vram_pages; - uint32_t tt_pages; - uint32_t *ttm_gtt_map; uint32_t dvmt_mode = 0; struct psb_gtt *pg; @@ -421,6 +415,7 @@ int psb_gtt_init(struct drm_device *dev, int resume) if (pg == NULL) return -ENOMEM; +/* Enable the GTT */ pci_read_config_word(dev->pdev, PSB_GMCH_CTRL, &dev_priv->gmch_ctrl); pci_write_config_word(dev->pdev, PSB_GMCH_CTRL, dev_priv->gmch_ctrl | _PSB_GMCH_ENABLED); @@ -431,30 +426,26 @@ int psb_gtt_init(struct drm_device *dev, int resume) /* The root resource we allocate address space from */ dev_priv->gtt_mem = &dev->pdev->resource[PSB_GATT_RESOURCE]; - dev_priv->gtt_initialized = 1; pg->gtt_phys_start = dev_priv->pge_ctl & PAGE_MASK; pg->gatt_start = pci_resource_start(dev->pdev, PSB_GATT_RESOURCE); - /* fix me: video mmu has hw bug to access 0x0D000, -* then make gatt start at 0x0e000, */ + /* +* FIXME: video mmu has hw bug to access 0x0D000, +* then make gatt start at 0x0e000, +*/ pg->mmu_gatt_start = 0xE000; + pg->gtt_start = pci_resource_start(dev->pdev, PSB_GTT_RESOURCE); - gtt_pages = - pci_resource_len(dev->pdev, PSB_GTT_RESOURCE) >> PAGE_SHIFT; - pg->gatt_pages = pci_resource_len(dev->pdev, PSB_GATT_RESOURCE) - >> PAGE_SHIFT; + gtt_pages = pci_resource_len(dev->pdev, PSB_GTT_RESOURCE) >> PAGE_SHIFT; + pg->gatt_pages = pci_resource_len(dev->pdev, PSB_GATT_RESOURCE) >> PAGE_SHIFT; pci_read_config_dword(dev->pdev, PSB_BSM, &dev_priv->stolen_base); vram_stolen_size = pg->gtt_phys_start - dev_priv->stolen_base - PAGE_SIZE; stolen_size = vram_stolen_size; - printk(KERN_I
[PATCH 12/15] gma500: 2D acceleration tidying
From: Alan Cox We have a FIXME to do the power management for which the framework now exists, and we also need to deal with an erratum. Some operations exactly 8 pixels wide or high fail. The work around is to do two smaller ones (see the Intel released X driver bits) but for console quite frankly if it's 8bits wide and/or high its not worth it so fall back. Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_2d.c | 19 +-- 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/staging/gma500/psb_2d.c b/drivers/staging/gma500/psb_2d.c index c3d7085..494bad5 100644 --- a/drivers/staging/gma500/psb_2d.c +++ b/drivers/staging/gma500/psb_2d.c @@ -183,10 +183,14 @@ static void psbfb_fillrect_accel(struct fb_info *info, cfb_fillrect(info, r); return; } - + if (!gma_power_begin(dev, false)) { + cfb_fillrect(info, r); + return; + } psb_accel_2d_fillrect(dev_priv, offset, stride, format, r->dx, r->dy, r->width, r->height, r->color); + gma_power_end(dev); } void psbfb_fillrect(struct fb_info *info, @@ -198,9 +202,7 @@ void psbfb_fillrect(struct fb_info *info, if (1 || (info->flags & FBINFO_HWACCEL_DISABLED)) return cfb_fillrect(info, rect); - /*psb_check_power_state(dev, PSB_DEVICE_SGX); */ psbfb_fillrect_accel(info, rect); - /* Drop power again here on MRST FIXMEAC */ } static u32 psb_accel_2d_copy_direction(int xdir, int ydir) @@ -331,10 +333,15 @@ static void psbfb_copyarea_accel(struct fb_info *info, return; } + if (!gma_power_begin(dev, false)) { + cfb_copyarea(info, a); + return; + } psb_accel_2d_copy(dev_priv, offset, stride, src_format, offset, stride, dst_format, a->sx, a->sy, a->dx, a->dy, a->width, a->height); + gma_power_end(dev); } void psbfb_copyarea(struct fb_info *info, @@ -343,12 +350,12 @@ void psbfb_copyarea(struct fb_info *info, if (unlikely(info->state != FBINFO_STATE_RUNNING)) return; - if (info->flags & FBINFO_HWACCEL_DISABLED) +/* Avoid the 8 pixel erratum */ + if (region->width == 8 || region->height == 8 || + (info->flags & FBINFO_HWACCEL_DISABLED)) return cfb_copyarea(info, region); - /* psb_check_power_state(dev, PSB_DEVICE_SGX); */ psbfb_copyarea_accel(info, region); - /* Need to power back off here for MRST FIXMEAC */ } void psbfb_imageblit(struct fb_info *info, const struct fb_image *image)
[PATCH 11/15] gma500: polish for completion of this phase
From: Alan Cox Give the driver its own proper DRM name, clean up copyright headers and so forth Signed-off-by: Alan Cox --- drivers/staging/gma500/mrst_crtc.c |4 + drivers/staging/gma500/mrst_lvds.c |2 - drivers/staging/gma500/psb_2d.c|7 -- drivers/staging/gma500/psb_bl.c|4 + drivers/staging/gma500/psb_drm.h | 90 +--- drivers/staging/gma500/psb_drv.c |4 + drivers/staging/gma500/psb_drv.h | 85 +++--- drivers/staging/gma500/psb_fb.c|3 - drivers/staging/gma500/psb_fb.h|3 - drivers/staging/gma500/psb_gtt.h |7 +- drivers/staging/gma500/psb_intel_drv.h | 19 +-- drivers/staging/gma500/psb_irq.h |8 +-- drivers/staging/gma500/psb_powermgmt.c |4 + drivers/staging/gma500/psb_powermgmt.h |2 - drivers/staging/gma500/psb_reg.h |2 - 15 files changed, 67 insertions(+), 177 deletions(-) diff --git a/drivers/staging/gma500/mrst_crtc.c b/drivers/staging/gma500/mrst_crtc.c index e4a0c03..fd97c80 100644 --- a/drivers/staging/gma500/mrst_crtc.c +++ b/drivers/staging/gma500/mrst_crtc.c @@ -86,7 +86,7 @@ static const struct mrst_limit_t *mrst_limit(struct drm_crtc *crtc) { const struct mrst_limit_t *limit = NULL; struct drm_device *dev = crtc->dev; - DRM_DRIVER_PRIVATE_T *dev_priv = dev->dev_private; + struct drm_psb_private *dev_priv = dev->dev_private; if (psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) || psb_intel_pipe_has_type(crtc, INTEL_OUTPUT_MIPI)) { @@ -296,7 +296,7 @@ static int mrst_crtc_mode_set(struct drm_crtc *crtc, { struct drm_device *dev = crtc->dev; struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc); - DRM_DRIVER_PRIVATE_T *dev_priv = dev->dev_private; + struct drm_psb_private *dev_priv = dev->dev_private; int pipe = psb_intel_crtc->pipe; int fp_reg = (pipe == 0) ? MRST_FPA0 : FPB0; int dpll_reg = (pipe == 0) ? MRST_DPLL_A : DPLL_B; diff --git a/drivers/staging/gma500/mrst_lvds.c b/drivers/staging/gma500/mrst_lvds.c index 4a08b74..22ea00e 100644 --- a/drivers/staging/gma500/mrst_lvds.c +++ b/drivers/staging/gma500/mrst_lvds.c @@ -46,7 +46,7 @@ static void mrst_lvds_set_power(struct drm_device *dev, struct psb_intel_output *output, bool on) { u32 pp_status; - DRM_DRIVER_PRIVATE_T *dev_priv = dev->dev_private; + struct drm_psb_private *dev_priv = dev->dev_private; PSB_DEBUG_ENTRY("\n"); if (!gma_power_begin(dev, true)) diff --git a/drivers/staging/gma500/psb_2d.c b/drivers/staging/gma500/psb_2d.c index 060eeaf..c3d7085 100644 --- a/drivers/staging/gma500/psb_2d.c +++ b/drivers/staging/gma500/psb_2d.c @@ -1,5 +1,5 @@ /** - * Copyright (c) 2007, Intel Corporation. + * Copyright (c) 2007-2011, Intel Corporation. * All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it @@ -396,8 +396,3 @@ int psbfb_sync(struct fb_info *info) out: return (busy) ? -EBUSY : 0; } - -/* - info->fix.accel = FB_ACCEL_I830; - info->flags = FBINFO_DEFAULT; -*/ diff --git a/drivers/staging/gma500/psb_bl.c b/drivers/staging/gma500/psb_bl.c index 5dffc71..2f9674d 100644 --- a/drivers/staging/gma500/psb_bl.c +++ b/drivers/staging/gma500/psb_bl.c @@ -1,7 +1,7 @@ /* - * psb backlight interface + * GMA500 Backlight Interface * - * Copyright (c) 2009, Intel Corporation. + * Copyright (c) 2009-2011, Intel Corporation. * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, diff --git a/drivers/staging/gma500/psb_drm.h b/drivers/staging/gma500/psb_drm.h index 49ffdd5..b005293 100644 --- a/drivers/staging/gma500/psb_drm.h +++ b/drivers/staging/gma500/psb_drm.h @@ -1,5 +1,5 @@ /** - * Copyright (c) 2007, Intel Corporation. + * Copyright (c) 2007-2011, Intel Corporation. * All Rights Reserved. * Copyright (c) 2008, Tungsten Graphics Inc. Cedar Park, TX., USA. * All Rights Reserved. @@ -22,84 +22,8 @@ #ifndef _PSB_DRM_H_ #define _PSB_DRM_H_ -#if defined(__linux__) && !defined(__KERNEL__) -#include -#include -#include "drm_mode.h" -#endif - -#define DRM_PSB_SAREA_MAJOR 0 -#define DRM_PSB_SAREA_MINOR 2 -#define PSB_FIXED_SHIFT 16 - #define PSB_NUM_PIPE 3 -/* - * Public memory types. - */ - -typedef s32 psb_fixed; -typedef u32 psb_ufixed; - -static inline s32 psb_int_to_fixed(int a) -{ - return a * (1 << PSB_FIXED_SHIFT); -} - -static inline u32 psb_unsigned_to_ufixed(unsigned int a) -{ - return a << PSB_FIXED_SHIFT; -} - -/*Status of the command sent to the gfx device.*/ -typedef enum { - DRM_CMD_SUCCESS, - DRM_CMD_FAILED,
[PATCH 10/15] gma500: trim some of the debug
From: Alan Cox Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_fb.c |6 +- drivers/staging/gma500/psb_gem.c | 11 --- drivers/staging/gma500/psb_gtt.c |2 -- 3 files changed, 1 insertions(+), 18 deletions(-) diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c index d005025..156f8ad 100644 --- a/drivers/staging/gma500/psb_fb.c +++ b/drivers/staging/gma500/psb_fb.c @@ -727,17 +727,13 @@ static void psb_user_framebuffer_destroy(struct drm_framebuffer *fb) /* Should never get stolen memory for a user fb */ WARN_ON(r->stolen); - pr_err("user framebuffer destroy %p, fbdev %p\n", - psbfb, psbfb->fbdev); + /* Check if we are erroneously live */ list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) if (crtc->fb == fb) reset = 1; if (reset) - pr_err("DRM: gma500, forcing reset\n"); - - if (reset) /* * Now force a sane response before we permit the DRM crc layer to * do stupid things like blank the display. Instead we reset this diff --git a/drivers/staging/gma500/psb_gem.c b/drivers/staging/gma500/psb_gem.c index b24b964..125ea6b 100644 --- a/drivers/staging/gma500/psb_gem.c +++ b/drivers/staging/gma500/psb_gem.c @@ -51,7 +51,6 @@ void psb_gem_free_object(struct drm_gem_object *obj) } drm_gem_object_release(obj); /* This must occur last as it frees up the memory of the GEM object */ - pr_err("GEM destroyed %p, %p\n", gtt, obj); psb_gtt_free_range(obj->dev, gtt); } @@ -177,8 +176,6 @@ static int psb_gem_create(struct drm_file *file, size = roundup(size, PAGE_SIZE); - dev_err(dev->dev, "GEM creating %lld\n", size); - /* Allocate our object - for now a direct gtt range which is not stolen memory backed */ r = psb_gtt_alloc_range(dev, size, "gem", 0); @@ -206,8 +203,6 @@ static int psb_gem_create(struct drm_file *file, /* We have the initial and handle reference but need only one now */ drm_gem_object_unreference(&r->gem); *handlep = handle; - dev_err(dev->dev, "GEM handle %x for %p OK\n", - handle, &r->gem); return 0; } @@ -283,12 +278,9 @@ int psb_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf) something from beneath our feet */ mutex_lock(&dev->struct_mutex); - dev_err(dev->dev, "Fault on GTT %p\n", r); - /* For now the mmap pins the object and it stays pinned. As things stand that will do us no harm */ if (r->mmapping == 0) { - dev_err(dev->dev, "Need to pin %p\n", r); ret = psb_gtt_pin(r); if (ret < 0) { DRM_ERROR("gma500: pin failed: %d\n", ret); @@ -302,13 +294,10 @@ int psb_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf) page_offset = ((unsigned long) vmf->virtual_address - vma->vm_start) >> PAGE_SHIFT; - dev_err(dev->dev, "Page offset %p %d\n", r, (int)page_offset); /* CPU view of the page, don't go via the GART for CPU writes */ pfn = page_to_phys(r->pages[page_offset]) >> PAGE_SHIFT; ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn); - dev_err(dev->dev, "PFN %ld for VA %p = %d\n", pfn, vmf->virtual_address, ret); - fail: mutex_unlock(&dev->struct_mutex); switch (ret) { diff --git a/drivers/staging/gma500/psb_gtt.c b/drivers/staging/gma500/psb_gtt.c index c6a7492..5a296e1 100644 --- a/drivers/staging/gma500/psb_gtt.c +++ b/drivers/staging/gma500/psb_gtt.c @@ -314,7 +314,6 @@ struct gtt_range *psb_gtt_alloc_range(struct drm_device *dev, int len, len, start, end, PAGE_SIZE, NULL, NULL); if (ret == 0) { gt->offset = gt->resource.start - r->start; - dev_err(dev->dev, "GTT new %p, %d\n", gt, gt->stolen); return gt; } kfree(gt); @@ -341,7 +340,6 @@ static void psb_gtt_destroy(struct kref *kref) } WARN_ON(gt->in_gart && !gt->stolen); release_resource(>->resource); - pr_err("GTT destroyed %p, %d\n", gt, gt->stolen); kfree(gt); }
[PATCH 09/15] gma500: Do sane FB cleanup
From: Alan Cox If we get a user frame buffer destroyed which is being displayed then clean up the mess nicely. We can now run a slightly modified modetest including setting modes, and handling crashes. Modetest still blows up but this is because libdrm 2.4.25 is busted. Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_fb.c| 24 +++- drivers/staging/gma500/psb_intel_display.c | 22 +- 2 files changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c index 5977add..d005025 100644 --- a/drivers/staging/gma500/psb_fb.c +++ b/drivers/staging/gma500/psb_fb.c @@ -719,16 +719,38 @@ static void psb_user_framebuffer_destroy(struct drm_framebuffer *fb) { struct psb_framebuffer *psbfb = to_psb_fb(fb); struct gtt_range *r = psbfb->gtt; + struct drm_device *dev = fb->dev; + struct drm_psb_private *dev_priv = dev->dev_private; + struct psb_fbdev *fbdev = dev_priv->fbdev; + struct drm_crtc *crtc; + int reset = 0; /* Should never get stolen memory for a user fb */ WARN_ON(r->stolen); pr_err("user framebuffer destroy %p, fbdev %p\n", psbfb, psbfb->fbdev); + /* Check if we are erroneously live */ + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) + if (crtc->fb == fb) + reset = 1; + + if (reset) + pr_err("DRM: gma500, forcing reset\n"); + + if (reset) + /* +* Now force a sane response before we permit the DRM crc layer to +* do stupid things like blank the display. Instead we reset this +* framebuffer as if the user had forced a reset. We must do this +* before the cleanup so that the DRM layer doesn't get a chance +* to stick its oar in where it isn't wanted. +*/ + drm_fb_helper_restore_fbdev_mode(&fbdev->psb_fb_helper); + /* Let DRM do its clean up */ drm_framebuffer_cleanup(fb); /* We are no longer using the resource in GEM */ drm_gem_object_unreference_unlocked(&r->gem); - kfree(fb); } diff --git a/drivers/staging/gma500/psb_intel_display.c b/drivers/staging/gma500/psb_intel_display.c index a99271d..c7c55b1 100644 --- a/drivers/staging/gma500/psb_intel_display.c +++ b/drivers/staging/gma500/psb_intel_display.c @@ -352,15 +352,15 @@ int psb_intel_pipe_set_base(struct drm_crtc *crtc, PSB_DEBUG_ENTRY("\n"); + if (!gma_power_begin(dev, true)) + return 0; + /* no fb bound */ if (!crtc->fb) { DRM_DEBUG("No FB bound\n"); - return 0; + goto psb_intel_pipe_cleaner; } - if (!gma_power_begin(dev, true)) - return 0; - /* We are displaying this buffer, make sure it is actually loaded into the GTT */ ret = psb_gtt_pin(psbfb->gtt); @@ -409,6 +409,7 @@ int psb_intel_pipe_set_base(struct drm_crtc *crtc, REG_READ(dspbase); } +psb_intel_pipe_cleaner: /* If there was a previous display we can now unpin it */ if (old_fb) psb_gtt_unpin(to_psb_fb(old_fb)->gtt); @@ -588,6 +589,7 @@ static int psb_intel_crtc_mode_set(struct drm_crtc *crtc, { struct drm_device *dev = crtc->dev; struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc); + struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private; int pipe = psb_intel_crtc->pipe; int fp_reg = (pipe == 0) ? FPA0 : FPB0; int dpll_reg = (pipe == 0) ? DPLL_A : DPLL_B; @@ -610,6 +612,12 @@ static int psb_intel_crtc_mode_set(struct drm_crtc *crtc, struct drm_mode_config *mode_config = &dev->mode_config; struct drm_connector *connector; + /* No scan out no play */ + if (crtc->fb == NULL) { + crtc_funcs->mode_set_base(crtc, x, y, old_fb); +return 0; +} + list_for_each_entry(connector, &mode_config->connector_list, head) { struct psb_intel_output *psb_intel_output = to_psb_intel_output(connector); @@ -786,11 +794,7 @@ static int psb_intel_crtc_mode_set(struct drm_crtc *crtc, REG_WRITE(dspcntr_reg, dspcntr); /* Flush the plane changes */ - { - struct drm_crtc_helper_funcs *crtc_funcs = - crtc->helper_private; - crtc_funcs->mode_set_base(crtc, x, y, old_fb); - } + crtc_funcs->mode_set_base(crtc, x, y, old_fb); psb_intel_wait_for_vblank(dev);
[PATCH 08/15] gma500: revamp frame buffer creation and handling
From: Alan Cox Restructure this to work the same way as the i915 frame buffer does. That cleans up various chunks of code. We can now set a mode in modetest but mode restore is a bit iffy Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_2d.c | 13 +-- drivers/staging/gma500/psb_fb.c | 195 +- drivers/staging/gma500/psb_fb.h |2 drivers/staging/gma500/psb_gem.c | 18 +++- drivers/staging/gma500/psb_gtt.c |2 5 files changed, 133 insertions(+), 97 deletions(-) diff --git a/drivers/staging/gma500/psb_2d.c b/drivers/staging/gma500/psb_2d.c index 0bd834c..060eeaf 100644 --- a/drivers/staging/gma500/psb_2d.c +++ b/drivers/staging/gma500/psb_2d.c @@ -148,7 +148,7 @@ static void psbfb_fillrect_accel(struct fb_info *info, const struct fb_fillrect *r) { struct psb_fbdev *fbdev = info->par; - struct psb_framebuffer *psbfb = fbdev->pfb; + struct psb_framebuffer *psbfb = &fbdev->pfb; struct drm_device *dev = psbfb->base.dev; struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb; struct drm_psb_private *dev_priv = dev->dev_private; @@ -291,7 +291,7 @@ static void psbfb_copyarea_accel(struct fb_info *info, const struct fb_copyarea *a) { struct psb_fbdev *fbdev = info->par; - struct psb_framebuffer *psbfb = fbdev->pfb; + struct psb_framebuffer *psbfb = &fbdev->pfb; struct drm_device *dev = psbfb->base.dev; struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb; struct drm_psb_private *dev_priv = dev->dev_private; @@ -360,19 +360,12 @@ void psbfb_imageblit(struct fb_info *info, const struct fb_image *image) int psbfb_sync(struct fb_info *info) { struct psb_fbdev *fbdev = info->par; - struct psb_framebuffer *psbfb = fbdev->pfb; + struct psb_framebuffer *psbfb = &fbdev->pfb; struct drm_device *dev = psbfb->base.dev; struct drm_psb_private *dev_priv = dev->dev_private; unsigned long _end = jiffies + DRM_HZ; int busy = 0; -#if 0 -/* Just a way to quickly test if cmd issue explodes */ - u32 test[2] = { - PSB_2D_FENCE_BH, -}; - psbfb_2d_submit(dev_priv, test, 1); -#endif /* * First idle the 2D engine. */ diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c index 4b05cdc..5977add 100644 --- a/drivers/staging/gma500/psb_fb.c +++ b/drivers/staging/gma500/psb_fb.c @@ -235,7 +235,7 @@ static struct vm_operations_struct psbfb_vm_ops = { static int psbfb_mmap(struct fb_info *info, struct vm_area_struct *vma) { struct psb_fbdev *fbdev = info->par; - struct psb_framebuffer *psbfb = fbdev->pfb; + struct psb_framebuffer *psbfb = &fbdev->pfb; char *fb_screen_base = NULL; struct drm_device *dev = psbfb->base.dev; struct drm_psb_private *dev_priv = dev->dev_private; @@ -267,7 +267,7 @@ static int psbfb_mmap(struct fb_info *info, struct vm_area_struct *vma) static int psbfb_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) { struct psb_fbdev *fbdev = info->par; - struct psb_framebuffer *psbfb = fbdev->pfb; + struct psb_framebuffer *psbfb = &fbdev->pfb; struct drm_device *dev = psbfb->base.dev; struct drm_psb_private *dev_priv = dev->dev_private; u32 __user *p = (u32 __user *)arg; @@ -304,8 +304,58 @@ static struct fb_ops psbfb_ops = { .fb_ioctl = psbfb_ioctl, }; +/** + * psb_framebuffer_init- initialize a framebuffer + * @dev: our DRM device + * @fb: framebuffer to set up + * @mode_cmd: mode description + * @gt: backing object + * + * Configure and fill in the boilerplate for our frame buffer. Return + * 0 on success or an error code if we fail. + */ +static int psb_framebuffer_init(struct drm_device *dev, +struct psb_framebuffer *fb, +struct drm_mode_fb_cmd *mode_cmd, +struct gtt_range *gt) +{ +int ret; + +if (mode_cmd->pitch & 63) +return -EINVAL; +switch (mode_cmd->bpp) { +case 8: +case 16: +case 24: +case 32: +break; +default: +return -EINVAL; +} +ret = drm_framebuffer_init(dev, &fb->base, &psb_fb_funcs); +if (ret) { +dev_err(dev->dev, "framebuffer init failed: %d\n", ret); +return ret; +} +drm_helper_mode_fill_fb_struct(&fb->base, mode_cmd); +fb->gtt = gt; +return 0; +} + +/** + * psb_framebuffer_create - create a framebuffer backed by gt + * @dev: our DRM device + * @mode_cmd: the description of the requested mode + * @gt: the backing object + * + * Create a framebuffer object backed by
[PATCH 07/15] gma500: Fix uninitialized variable and style issues
From: Andre Bartke The return variable of psb_gtt_pin() may be used uninitialized. Also fixed some coding style issues. Signed-off-by: Andre Bartke [Reapplied by hand due to other changes] Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_gtt.c | 36 ++-- 1 files changed, 18 insertions(+), 18 deletions(-) diff --git a/drivers/staging/gma500/psb_gtt.c b/drivers/staging/gma500/psb_gtt.c index 6a24246..5a296e1 100644 --- a/drivers/staging/gma500/psb_gtt.c +++ b/drivers/staging/gma500/psb_gtt.c @@ -58,7 +58,7 @@ static inline uint32_t psb_gtt_mask_pte(uint32_t pfn, int type) */ u32 *psb_gtt_entry(struct drm_device *dev, struct gtt_range *r) { -struct drm_psb_private *dev_priv = dev->dev_private; + struct drm_psb_private *dev_priv = dev->dev_private; unsigned long offset; offset = r->resource.start - dev_priv->gtt_mem->start; @@ -124,7 +124,7 @@ static void psb_gtt_remove(struct drm_device *dev, struct gtt_range *r) WARN_ON(r->stolen); gtt_slot = psb_gtt_entry(dev, r); - pte = psb_gtt_mask_pte(page_to_pfn(dev_priv->scratch_page), 0);; + pte = psb_gtt_mask_pte(page_to_pfn(dev_priv->scratch_page), 0); for (i = 0; i < r->npage; i++) iowrite32(pte, gtt_slot++); @@ -213,7 +213,7 @@ static void psb_gtt_detach_pages(struct gtt_range *gt) */ int psb_gtt_pin(struct gtt_range *gt) { - int ret; + int ret = 0; struct drm_device *dev = gt->gem.dev; struct drm_psb_private *dev_priv = dev->dev_private; @@ -289,33 +289,33 @@ struct gtt_range *psb_gtt_alloc_range(struct drm_device *dev, int len, struct resource *r = dev_priv->gtt_mem; int ret; unsigned long start, end; - + if (backed) { - /* The start of the GTT is the stolen pages */ - start = r->start; - end = r->start + dev_priv->pg->stolen_size - 1; + /* The start of the GTT is the stolen pages */ + start = r->start; + end = r->start + dev_priv->pg->stolen_size - 1; } else { -/* The rest we will use for GEM backed objects */ -start = r->start + dev_priv->pg->stolen_size; -end = r->end; + /* The rest we will use for GEM backed objects */ + start = r->start + dev_priv->pg->stolen_size; + end = r->end; } gt = kzalloc(sizeof(struct gtt_range), GFP_KERNEL); if (gt == NULL) return NULL; -gt->resource.name = name; -gt->stolen = backed; -gt->in_gart = backed; -/* Ensure this is set for non GEM objects */ -gt->gem.dev = dev; + gt->resource.name = name; + gt->stolen = backed; + gt->in_gart = backed; + /* Ensure this is set for non GEM objects */ + gt->gem.dev = dev; kref_init(>->kref); ret = allocate_resource(dev_priv->gtt_mem, >->resource, len, start, end, PAGE_SIZE, NULL, NULL); if (ret == 0) { - gt->offset = gt->resource.start - r->start; + gt->offset = gt->resource.start - r->start; return gt; -} + } kfree(gt); return NULL; } @@ -419,7 +419,7 @@ int psb_gtt_init(struct drm_device *dev, int resume) dev_priv->pg = pg = psb_gtt_alloc(dev); if (pg == NULL) - return -ENOMEM; + return -ENOMEM; pci_read_config_word(dev->pdev, PSB_GMCH_CTRL, &dev_priv->gmch_ctrl); pci_write_config_word(dev->pdev, PSB_GMCH_CTRL,
[PATCH 06/15] staging/gma500: get control from firmware framebuffer if conflicts
From: Michael Chang Many Linux distributions would enable vesafb in order to display early stage boot splash. In this case, we will get garbled X Window screen if running X fbdev on psbfb. This is because fb0 is occupied by vesafb while psbfb is on fb1. They tried to drive the same pieces of hardware at the same time. With unmodified X start-up, it would try to use default fb0 framebuffer device and unfortunately it is now broken becaues fb1 supersedes it. We should let psbfb takeover framebuffer control from vesafb to get around this problem. See also commit : 4410f3910947dcea8672280b3adecd53cec4e85e Signed-off-by: Michael Chang Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_fb.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c index 4e6294c..4b05cdc 100644 --- a/drivers/staging/gma500/psb_fb.c +++ b/drivers/staging/gma500/psb_fb.c @@ -452,6 +452,16 @@ static int psbfb_create(struct psb_fbdev *fbdev, info->screen_size = size; memset(info->screen_base, 0, size); + if (dev_priv->pg->stolen_size) { + info->apertures = alloc_apertures(1); + if (!info->apertures) { + ret = -ENOMEM; + goto out_err0; + } + info->apertures->ranges[0].base = dev->mode_config.fb_base; + info->apertures->ranges[0].size = dev_priv->pg->stolen_size; + } + drm_fb_helper_fill_fix(info, fb->pitch, fb->depth); drm_fb_helper_fill_var(info, &fbdev->psb_fb_helper, sizes->fb_width, sizes->fb_height);
[PATCH 05/15] gma500: Set the correct bits according to the pipe
From: Alan Cox Squash a hardcoded assumption we shouldn't really make Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_intel_display.c | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/staging/gma500/psb_intel_display.c b/drivers/staging/gma500/psb_intel_display.c index 4f47d09..a99271d 100644 --- a/drivers/staging/gma500/psb_intel_display.c +++ b/drivers/staging/gma500/psb_intel_display.c @@ -723,17 +723,18 @@ static int psb_intel_crtc_mode_set(struct drm_crtc *crtc, if (is_lvds) { u32 lvds = REG_READ(LVDS); - lvds |= - LVDS_PORT_EN | LVDS_A0A2_CLKA_POWER_UP | - LVDS_PIPEB_SELECT; + lvds &= ~LVDS_PIPEB_SELECT; +if (pipe == 1) +lvds |= LVDS_PIPEB_SELECT; + + lvds |= LVDS_PORT_EN | LVDS_A0A2_CLKA_POWER_UP; /* Set the B0-B3 data pairs corresponding to * whether we're going to * set the DPLLs for dual-channel mode or not. */ + lvds &= ~(LVDS_B0B3_POWER_UP | LVDS_CLKB_POWER_UP); if (clock.p2 == 7) lvds |= LVDS_B0B3_POWER_UP | LVDS_CLKB_POWER_UP; - else - lvds &= ~(LVDS_B0B3_POWER_UP | LVDS_CLKB_POWER_UP); /* It would be nice to set 24 vs 18-bit mode (LVDS_A3_POWER_UP) * appropriately here, but we need to look more
[PATCH 04/15] gma500: Ensure the frame buffer has a linear virtual mapping
From: Alan Cox We need this for the framebuffer in order to ensure that the kernel framebuffer layer can handle it when using KMS. Except for the base framebuffer this isn't a concern. Add an npage field to the gtt as too many copies of the page calculation are getting spread around the code. Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_fb.c | 47 -- drivers/staging/gma500/psb_fb.h |1 + drivers/staging/gma500/psb_gtt.c | 18 ++- drivers/staging/gma500/psb_gtt.h |5 ++-- 4 files changed, 42 insertions(+), 29 deletions(-) diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c index f578ca8..4e6294c 100644 --- a/drivers/staging/gma500/psb_fb.c +++ b/drivers/staging/gma500/psb_fb.c @@ -254,17 +254,13 @@ static int psbfb_mmap(struct fb_info *info, struct vm_area_struct *vma) vma->vm_pgoff, fb_screen_base, dev_priv->vram_addr); -/* FIXME: ultimately this needs to become 'if entirely stolen memory' */ - if (1 || fb_screen_base == dev_priv->vram_addr) { - vma->vm_ops = &psbfb_vm_ops; - vma->vm_private_data = (void *)psbfb; - vma->vm_flags |= VM_RESERVED | VM_IO | - VM_MIXEDMAP | VM_DONTEXPAND; - } else { - /* GTT memory backed by kernel/user pages, needs a different - approach ? - GEM ? */ - } - +/* If this is a GEM object then info->screen_base is the virtual + kernel remapping of the object. FIXME: Review if this is + suitable for our mmap work */ + vma->vm_ops = &psbfb_vm_ops; + vma->vm_private_data = (void *)psbfb; + vma->vm_flags |= VM_RESERVED | VM_IO | + VM_MIXEDMAP | VM_DONTEXPAND; return 0; } @@ -349,8 +345,6 @@ err: * * FIXME: console speed up - allocate twice the space if room and use * hardware scrolling for acceleration. - * FIXME: we need to vm_map_ram a linear mapping if the object has to - * be GEM host mapped, otherwise the cfb layer's brain will fall out. */ static struct gtt_range *psbfb_alloc(struct drm_device *dev, int aligned_size) { @@ -439,10 +433,22 @@ static int psbfb_create(struct psb_fbdev *fbdev, info->fix.smem_start = dev->mode_config.fb_base; info->fix.smem_len = size; - /* Accessed via stolen memory directly, This only works for stolem - memory however. Need to address this once we start using gtt - pages we allocate. FIXME: vm_map_ram for that case */ - info->screen_base = (char *)dev_priv->vram_addr + backing->offset; + if (backing->stolen) { + /* Accessed stolen memory directly */ + info->screen_base = (char *)dev_priv->vram_addr + + backing->offset; + } else { + /* Pin the pages into the GTT and create a mapping to them */ + psb_gtt_pin(backing); + info->screen_base = vm_map_ram(backing->pages, backing->npage, + -1, PAGE_KERNEL); + if (info->screen_base == NULL) { + psb_gtt_unpin(backing); + ret = -ENOMEM; + goto out_err0; + } + psbfb->vm_map = 1; + } info->screen_size = size; memset(info->screen_base, 0, size); @@ -560,6 +566,13 @@ int psb_fbdev_destroy(struct drm_device *dev, struct psb_fbdev *fbdev) if (fbdev->psb_fb_helper.fbdev) { info = fbdev->psb_fb_helper.fbdev; + + /* If this is our base framebuffer then kill any virtual map + for the framebuffer layer and unpin it */ + if (psbfb->vm_map) { + vm_unmap_ram(info->screen_base, psbfb->gtt->npage); + psb_gtt_unpin(psbfb->gtt); + } /* FIXME: this is a bit more inside knowledge than I'd like but I don't see how to make a fake GEM object of the stolen space nicely */ diff --git a/drivers/staging/gma500/psb_fb.h b/drivers/staging/gma500/psb_fb.h index c8ec0d6..2153c74 100644 --- a/drivers/staging/gma500/psb_fb.h +++ b/drivers/staging/gma500/psb_fb.h @@ -33,6 +33,7 @@ struct psb_framebuffer { struct address_space *addr_space; struct fb_info *fbdev; struct gtt_range *gtt; + bool vm_map;/* True if we must undo a vm_map_ram */ }; struct psb_fbdev { diff --git a/drivers/staging/gma500/psb_gtt.c b/drivers/staging/gma500/psb_gtt.c index d76037f..6a24246 100644 --- a/drivers/staging/gma500/psb_gtt.c +++ b/drivers/staging/gma500/psb_gtt.c @@ -79,7 +79,6 @@ u32 *psb_gtt_entry(struct drm_device *dev, struct gtt_range *r) static int psb_gtt_insert
[PATCH 03/15] gma500: Make GTT pages uncached
From: Alan Cox Clean up the GTT code a bit, make the pages uncached and go via the proper interfaces. This avoids any aliasing problems. On the CPU side we need to access the pages via their true addresses not via the GTT. This is fine for GEM created fb objects for X. For the kernel fb when not in stolen RAM we are going to need to use vm_map_ram() and hope we have enough virtual address space to steal. Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_fb.c |9 - drivers/staging/gma500/psb_gem.c | 26 +++--- drivers/staging/gma500/psb_gtt.c | 27 ++- 3 files changed, 29 insertions(+), 33 deletions(-) diff --git a/drivers/staging/gma500/psb_fb.c b/drivers/staging/gma500/psb_fb.c index 99c03a2..f578ca8 100644 --- a/drivers/staging/gma500/psb_fb.c +++ b/drivers/staging/gma500/psb_fb.c @@ -346,6 +346,11 @@ err: * and back it with a GEM object. * * In this case the GEM object has no handle. + * + * FIXME: console speed up - allocate twice the space if room and use + * hardware scrolling for acceleration. + * FIXME: we need to vm_map_ram a linear mapping if the object has to + * be GEM host mapped, otherwise the cfb layer's brain will fall out. */ static struct gtt_range *psbfb_alloc(struct drm_device *dev, int aligned_size) { @@ -436,7 +441,7 @@ static int psbfb_create(struct psb_fbdev *fbdev, /* Accessed via stolen memory directly, This only works for stolem memory however. Need to address this once we start using gtt - pages we allocate */ + pages we allocate. FIXME: vm_map_ram for that case */ info->screen_base = (char *)dev_priv->vram_addr + backing->offset; info->screen_size = size; memset(info->screen_base, 0, size); @@ -666,6 +671,8 @@ static void psb_user_framebuffer_destroy(struct drm_framebuffer *fb) struct psb_framebuffer *psbfb = to_psb_fb(fb); struct gtt_range *r = psbfb->gtt; + pr_err("user framebuffer destroy %p, fbdev %p\n", + psbfb, psbfb->fbdev); if (psbfb->fbdev) psbfb_remove(dev, fb); diff --git a/drivers/staging/gma500/psb_gem.c b/drivers/staging/gma500/psb_gem.c index 76ff7ba..98d8ab3 100644 --- a/drivers/staging/gma500/psb_gem.c +++ b/drivers/staging/gma500/psb_gem.c @@ -40,7 +40,6 @@ int psb_gem_init_object(struct drm_gem_object *obj) void psb_gem_free_object(struct drm_gem_object *obj) { struct gtt_range *gtt = container_of(obj, struct gtt_range, gem); - psb_gtt_free_range(obj->dev, gtt); if (obj->map_list.map) { /* Do things GEM should do for us */ struct drm_gem_mm *mm = obj->dev->mm_private; @@ -51,6 +50,8 @@ void psb_gem_free_object(struct drm_gem_object *obj) list->map = NULL; } drm_gem_object_release(obj); + /* This must occur last as it frees up the memory of the GEM object */ + psb_gtt_free_range(obj->dev, gtt); } int psb_gem_get_aperture(struct drm_device *dev, void *data, @@ -245,19 +246,13 @@ int psb_gem_dumb_destroy(struct drm_file *file, struct drm_device *dev, * but we need to do the actual page work. * * This code eventually needs to handle faulting objects in and out - * of the GART and repacking it when we run out of space. We can put + * of the GTT and repacking it when we run out of space. We can put * that off for now and for our simple uses * * The VMA was set up by GEM. In doing so it also ensured that the * vma->vm_private_data points to the GEM object that is backing this * mapping. * - * To avoid aliasing and cache funnies we want to map the object - * through the GART. For the moment this is slightly hackish. It would - * be nicer if GEM provided mmap opened/closed hooks for us giving - * the object so that we could track things nicely. That needs changes - * to the core GEM code so must be tackled post staging - * * FIXME */ int psb_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf) @@ -289,20 +284,13 @@ int psb_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf) r->mmapping = 1; } - /* FIXME: Locking. We may also need to repack the GART sometimes */ - - /* Page relative to the VMA start */ + /* Page relative to the VMA start - we must calculate this ourselves + because vmf->pgoff is the fake GEM offset */ page_offset = ((unsigned long) vmf->virtual_address - vma->vm_start) >> PAGE_SHIFT; - /* Bus address of the page is gart + object offset + page offset */ - /* Assumes gtt allocations are page aligned */ - pfn = (r->resource.start >> PAGE_SHIFT) + page_offset; - - pr_debug("Object GTT base at %p\n", (void *)(r->resource.start)); - pr_debug("Inserting %p pfn %lx, pa %lx\n", vmf->
Modeline problem with Radeon KMS
On Wed, Jun 8, 2011 at 10:06 AM, Meelis Roos wrote: > I have LG Flatron F900P CRT monitor. X drivers work fine, nouveau KMS > works fine but Radeon KMS selects a videomode that is out of spec for > monitor. This is not a regression - this hardware combination has never > worked for me yet with radeon KMS. The result is same for Radeon 7000 > (RV100, currently installed) and Radeon 9200 series card. > Is it just 2048x1536 that's causing problems? Do any other modes work? 1600x1200 for example? > [ ? ?36.111] (II) RADEON(0): Output VGA-0 using monitor section CM771 I notice you have a monitor section defined in your xorg.conf. Does that monitor section perhaps have any old modelines from an old monitor that may be causing problems? Alex
[PATCH 02/15] gma500: Skip bogus LVDS VBT mode and check for LVDS before adding backlight
From: Patrik Jakobsson On the Fit-PC2 the VBT reports an invalid fixed panel mode for LVDS, this gets in the way for SDVO. This patch makes VBT parsing skip the invalid mode. When there is no LVDS output the backlight support crashes so the patch also checks for this before enabling it. Signed-off-by: Patrik Jakobsson Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_drv.c| 15 ++- drivers/staging/gma500/psb_intel_bios.c | 13 + 2 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/staging/gma500/psb_drv.c b/drivers/staging/gma500/psb_drv.c index 1c45c11..aa87b1b 100644 --- a/drivers/staging/gma500/psb_drv.c +++ b/drivers/staging/gma500/psb_drv.c @@ -542,6 +542,8 @@ static int psb_driver_load(struct drm_device *dev, unsigned long chipset) unsigned long irqflags; int ret = -ENOMEM; uint32_t tt_pages; + struct drm_connector *connector; + struct psb_intel_output *psb_intel_output; dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL); if (dev_priv == NULL) @@ -663,7 +665,18 @@ static int psb_driver_load(struct drm_device *dev, unsigned long chipset) drm_kms_helper_poll_init(dev); } - ret = psb_backlight_init(dev); + /* Only add backlight support if we have LVDS output */ + list_for_each_entry(connector, &dev->mode_config.connector_list, + head) { + psb_intel_output = to_psb_intel_output(connector); + + switch (psb_intel_output->type) { + case INTEL_OUTPUT_LVDS: + ret = psb_backlight_init(dev); + break; + } + } + if (ret) return ret; #if 0 diff --git a/drivers/staging/gma500/psb_intel_bios.c b/drivers/staging/gma500/psb_intel_bios.c index 48ac8ba..417965d 100644 --- a/drivers/staging/gma500/psb_intel_bios.c +++ b/drivers/staging/gma500/psb_intel_bios.c @@ -154,10 +154,15 @@ static void parse_lfp_panel_data(struct drm_psb_private *dev_priv, fill_detail_timing_data(panel_fixed_mode, dvo_timing); - dev_priv->lfp_lvds_vbt_mode = panel_fixed_mode; - - DRM_DEBUG("Found panel mode in BIOS VBT tables:\n"); - drm_mode_debug_printmodeline(panel_fixed_mode); + if (panel_fixed_mode->htotal > 0 && panel_fixed_mode->vtotal > 0) { + dev_priv->lfp_lvds_vbt_mode = panel_fixed_mode; + DRM_DEBUG("Found panel mode in BIOS VBT tables:\n"); + drm_mode_debug_printmodeline(panel_fixed_mode); + } else { + DRM_DEBUG("Ignoring bogus LVDS VBT mode.\n"); + dev_priv->lvds_vbt = 0; + kfree(panel_fixed_mode); + } return; }
[PATCH 01/15] gma500: fix warnings
From: Alan Cox Signed-off-by: Alan Cox --- drivers/staging/gma500/psb_gtt.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/staging/gma500/psb_gtt.c b/drivers/staging/gma500/psb_gtt.c index 74c5a65..1d0e242 100644 --- a/drivers/staging/gma500/psb_gtt.c +++ b/drivers/staging/gma500/psb_gtt.c @@ -78,7 +78,6 @@ u32 *psb_gtt_entry(struct drm_device *dev, struct gtt_range *r) */ static int psb_gtt_insert(struct drm_device *dev, struct gtt_range *r) { -struct drm_psb_private *dev_priv = dev->dev_private; u32 *gtt_slot, pte; int numpages = (r->resource.end + 1 - r->resource.start) >> PAGE_SHIFT; struct page **pages; @@ -490,7 +489,7 @@ int psb_gtt_init(struct drm_device *dev, int resume) goto out_err; } - DRM_DEBUG("%s: vram kernel virtual address %p\n", dev_priv->vram_addr); + DRM_DEBUG("gma500: vram kernel virtual address %p\n", dev_priv->vram_addr); tt_pages = (pg->gatt_pages < PSB_TT_PRIV0_PLIMIT) ? (pg->gatt_pages) : PSB_TT_PRIV0_PLIMIT;
[PATCH 00/15] GMA500 KMS and GEM
This patch series versus linux-next 2011/06/08 fixes various bugs including a nasty pinning bug found by Andre Bartke. With these patches applied the driver passes the various GEM tests and you can use the KMS tools and test sets to set modes and display stuff from GEM buffers including those mapped from main memory via the GTT. You can't yet take a GEM handle of the system frame buffer. That requires a trivial patch to drm_gem and a similar trivial patch to this driver. The two main remaining tasks now are to provide a 2D command interface for the X server including support for blitting between GEM objects (so we need relocs) and to clean the code up. Vblank support is also possible but doesn't seem terribly useful. --- Alan Cox (12): gma500: Kill spare kref gma500: nuke the PSB debug stuff gma500: nuke the last bits of TTM code gma500: 2D acceleration tidying gma500: polish for completion of this phase gma500: trim some of the debug gma500: Do sane FB cleanup gma500: revamp frame buffer creation and handling gma500: Set the correct bits according to the pipe gma500: Ensure the frame buffer has a linear virtual mapping gma500: Make GTT pages uncached gma500: fix warnings Andre Bartke (1): gma500: Fix uninitialized variable and style issues Michael Chang (1): staging/gma500: get control from firmware framebuffer if conflicts Patrik Jakobsson (1): gma500: Skip bogus LVDS VBT mode and check for LVDS before adding backlight drivers/staging/gma500/mrst_crtc.c | 27 +- drivers/staging/gma500/mrst_lvds.c | 14 - drivers/staging/gma500/psb_2d.c | 39 +-- drivers/staging/gma500/psb_bl.c | 12 - drivers/staging/gma500/psb_drm.h| 90 drivers/staging/gma500/psb_drv.c| 58 ++--- drivers/staging/gma500/psb_drv.h| 181 drivers/staging/gma500/psb_fb.c | 309 +++ drivers/staging/gma500/psb_fb.h |6 - drivers/staging/gma500/psb_gem.c| 39 +-- drivers/staging/gma500/psb_gtt.c| 187 ++-- drivers/staging/gma500/psb_gtt.h| 11 + drivers/staging/gma500/psb_intel_bios.c | 26 +- drivers/staging/gma500/psb_intel_display.c | 130 +++ drivers/staging/gma500/psb_intel_drv.h | 19 -- drivers/staging/gma500/psb_intel_lvds.c | 53 + drivers/staging/gma500/psb_intel_opregion.c |7 - drivers/staging/gma500/psb_intel_sdvo.c | 34 +-- drivers/staging/gma500/psb_irq.c| 33 +-- drivers/staging/gma500/psb_irq.h|8 - drivers/staging/gma500/psb_powermgmt.c |4 drivers/staging/gma500/psb_powermgmt.h |2 drivers/staging/gma500/psb_reg.h|2 23 files changed, 461 insertions(+), 830 deletions(-) -- Signature
[RFC PATCH] KMS support for i.MX51/53
On Tue, Jun 07, 2011 at 08:59:28PM +0100, Alan Cox wrote: > > I'm not sure I understand you correctly. I have no address space on the > > card side since my 'card' just uses main memory. The memory I need must > > be a physically contiguous portion of sdram. I'm afraid shmem backing > > memory is not of much use for me. > > I hadn't realised you had that underlying limit. If you are limited to a > specific chunk of SDRAM and it must be physically linear rather than any > of memory then indeed it's not. > > I'd been tweaking GEM so you can borrow the abstraction and handles but > back them with your own allocator but in my case it makes sense because I > can use either main memory or a chunk of linear preallocated memory > reserved by the firmware so I wanted the commonality and single set of > handles for GEM, IOCTL_MODE_CREATE_DUMB etc. Your patch looks like it would do the trick. I'll see what I can do. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH] bugfix and cleanup patches in the TTM code for 3.1.
On Wed, 8 Jun 2011 19:30:22 +0200 Rafał Miłecki wrote: > Hi Konrad, > > 2011/6/8 Konrad Rzeszutek Wilk : > > The bug-fix "ttm: Do not increment the amount of pages in a pool by the > > current amount" > > I never observed, but found while looking at the code. The cleanup patch: > > "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier > > and Randy > > Dunlap graciously added some extra cleanups - which I have rolled in. > > This is safe to put comments to the patch in the following place: > > > Signed-off-by: (...) > --- > RIGHT HERE > --- > drivers/(...) > > > When applying such a patch comments will not be visible in git log. > You may find this easier method of commenting your patches. Yes, it would remove the temptation to make a patch 0/ that several people are (sadly) using recently. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] bugfix and cleanup patches in the TTM code for 3.1.
On Wed, 8 Jun 2011 19:30:22 +0200 Rafa? Mi?ecki wrote: > Hi Konrad, > > 2011/6/8 Konrad Rzeszutek Wilk : > > The bug-fix "ttm: Do not increment the amount of pages in a pool by the > > current amount" > > I never observed, but found while looking at the code. The cleanup patch: > > "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier > > and Randy > > Dunlap graciously added some extra cleanups - which I have rolled in. > > This is safe to put comments to the patch in the following place: > > > Signed-off-by: (...) > --- > RIGHT HERE > --- > drivers/(...) > > > When applying such a patch comments will not be visible in git log. > You may find this easier method of commenting your patches. Yes, it would remove the temptation to make a patch 0/ that several people are (sadly) using recently. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
Re: [PATCH] bugfix and cleanup patches in the TTM code for 3.1.
Hi Konrad, 2011/6/8 Konrad Rzeszutek Wilk : > The bug-fix "ttm: Do not increment the amount of pages in a pool by the > current amount" > I never observed, but found while looking at the code. The cleanup patch: > "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier > and Randy > Dunlap graciously added some extra cleanups - which I have rolled in. This is safe to put comments to the patch in the following place: Signed-off-by: (...) --- RIGHT HERE --- drivers/(...) When applying such a patch comments will not be visible in git log. You may find this easier method of commenting your patches. -- Rafał ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #4 from Pascal Billery-Schneider 2011-06-08 10:12:51 PDT --- I managed to compile mesa git according to: http://www.x.org/wiki/radeonBuildHowTo with these options: DRI_DRIVERS="radeon,r200,r300,r600,swrast" && ./autogen.sh --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --disable-gallium --enable-glx-tls --with-dri-driverdir=/opt/xorg/lib/dri/ So I get now: ldconfig -p | grep libGL.so libGL.so.1 (libc6,x86-64, Système d'exploitation ABI : Linux 2.4.20) => /opt/xorg/lib/libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/libGL.so.1 libGL.so (libc6,x86-64, Système d'exploitation ABI : Linux 2.4.20) => /opt/xorg/lib/libGL.so libGL.so (libc6,x86-64) => /usr/lib64/libGL.so I'am going to reboot and see. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #4 from Pascal Billery-Schneider 2011-06-08 10:12:51 PDT --- I managed to compile mesa git according to: http://www.x.org/wiki/radeonBuildHowTo with these options: DRI_DRIVERS="radeon,r200,r300,r600,swrast" && ./autogen.sh --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --disable-gallium --enable-glx-tls --with-dri-driverdir=/opt/xorg/lib/dri/ So I get now: ldconfig -p | grep libGL.so libGL.so.1 (libc6,x86-64, Syst?me d'exploitation ABI : Linux 2.4.20) => /opt/xorg/lib/libGL.so.1 libGL.so.1 (libc6,x86-64) => /usr/lib64/libGL.so.1 libGL.so.1 (libc6) => /usr/lib/libGL.so.1 libGL.so (libc6,x86-64, Syst?me d'exploitation ABI : Linux 2.4.20) => /opt/xorg/lib/libGL.so libGL.so (libc6,x86-64) => /usr/lib64/libGL.so I'am going to reboot and see. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] ttm: Fix spelling mistakes and remove unused #ifdef
. and some comments to make it easier to understand. Ackedby: Randy Dunlap [v2: Added some more updates from Randy Dunlap] Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_page_alloc.c | 16 include/drm/ttm/ttm_bo_api.h |3 --- include/drm/ttm/ttm_bo_driver.h |6 +++--- include/drm/ttm/ttm_memory.h |2 +- include/drm/ttm/ttm_object.h |4 ++-- include/drm/ttm/ttm_page_alloc.h |2 +- 6 files changed, 15 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index 9d9d929..4db6fc7 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -355,7 +355,7 @@ restart: if (nr_free) goto restart; - /* Not allowed to fall tough or break because + /* Not allowed to fall through or break because * following context is inside spinlock while we are * outside here. */ @@ -554,7 +554,7 @@ out: } /** - * Fill the given pool if there isn't enough pages and requested number of + * Fill the given pool if there aren't enough pages and the requested number of * pages is small. */ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, @@ -574,8 +574,8 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, pool->fill_lock = true; - /* If allocation request is small and there is not enough -* pages in pool we fill the pool first */ + /* If allocation request is small and there are not enough +* pages in a pool we fill the pool up first. */ if (count < _manager->options.small && count > pool->npages) { struct list_head new_pages; @@ -612,9 +612,9 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, } /** - * Cut count nubmer of pages from the pool and put them to return list + * Cut 'count' number of pages from the pool and put them on the return list. * - * @return count of pages still to allocate to fill the request. + * @return count of pages still required to fulfill the request. */ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool, struct list_head *pages, int ttm_flags, @@ -635,7 +635,7 @@ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool, goto out; } /* find the last pages to include for requested number of pages. Split -* pool to begin and halves to reduce search space. */ +* pool to begin and halve it to reduce search space. */ if (count <= pool->npages/2) { i = 0; list_for_each(p, &pool->list) { @@ -649,7 +649,7 @@ static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool, break; } } - /* Cut count number of pages from pool */ + /* Cut 'count' number of pages from the pool */ list_cut_position(pages, &pool->list, p); pool->npages -= count; count = 0; diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index 62a0e4c..42e3469 100644 --- a/include/drm/ttm/ttm_bo_api.h +++ b/include/drm/ttm/ttm_bo_api.h @@ -662,9 +662,6 @@ extern int ttm_bo_kmap(struct ttm_buffer_object *bo, unsigned long start_page, extern void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map); -#if 0 -#endif - /** * ttm_fbdev_mmap - mmap fbdev memory backed by a ttm buffer object. * diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h index 09af2d7..94eb143 100644 --- a/include/drm/ttm/ttm_bo_driver.h +++ b/include/drm/ttm/ttm_bo_driver.h @@ -78,7 +78,7 @@ struct ttm_backend_func { * * Bind the backend pages into the aperture in the location * indicated by @bo_mem. This function should be able to handle -* differences between aperture- and system page sizes. +* differences between aperture and system page sizes. */ int (*bind) (struct ttm_backend *backend, struct ttm_mem_reg *bo_mem); @@ -88,7 +88,7 @@ struct ttm_backend_func { * @backend: Pointer to a struct ttm_backend. * * Unbind previously bound backend pages. This function should be -* able to handle differences between aperture- and system page sizes. +* able to handle differences between aperture and system page sizes. */ int (*unbind) (struct ttm_backend *backend); @@ -786,7 +786,7 @@ extern int ttm_bo_device_release(struct ttm_bo_device *bdev); * ttm_bo_device_init * * @bdev: A pointer to a struct ttm_bo_device to initialize. - * @mem_global: A pointer to an initialized struct ttm_mem_global. + * @glob: A pointer to an initialized struct ttm_bo_global. * @driver: A pointer to a
[PATCH] bugfix and cleanup patches in the TTM code for 3.1.
The bug-fix "ttm: Do not increment the amount of pages in a pool by the current amount" I never observed, but found while looking at the code. The cleanup patch: "ttm: Fix spelling mistakes and remove unused #ifdef", I had posted earlier and Randy Dunlap graciously added some extra cleanups - which I have rolled in. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] ttm: Do not increment the amount of pages in a pool by the current amount
.instead increment it by the count of pages that we want to splice into the pool list. In other words we were incrementing the pool->npages by the wrong amount. This bug was observed from code inspection. Signed-off-by: Konrad Rzeszutek Wilk --- drivers/gpu/drm/ttm/ttm_page_alloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c index d948575..002b414 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c @@ -602,7 +602,7 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool, printk(KERN_ERR TTM_PFX "Failed to fill pool (%p).", pool); /* If we have any pages left put them to the pool. */ - list_for_each_entry(p, &pool->list, lru) { + list_for_each_entry(p, &new_pages, lru) { ++cpages; } list_splice(&new_pages, &pool->list); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: check modes against max pixel clock
Filter out modes that are higher than the max pixel clock. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h|1 + drivers/gpu/drm/radeon/radeon_atombios.c |4 drivers/gpu/drm/radeon/radeon_clocks.c |8 +--- drivers/gpu/drm/radeon/radeon_combios.c|5 + drivers/gpu/drm/radeon/radeon_connectors.c | 13 - 5 files changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 625f1af..bbcb00a 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -165,6 +165,7 @@ struct radeon_clock { uint32_t default_sclk; uint32_t default_dispclk; uint32_t dp_extclk; + uint32_t max_pixel_clock; }; /* diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index 90dfb2b..fa62a50 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1246,6 +1246,10 @@ bool radeon_atom_get_clock_info(struct drm_device *dev) } *dcpll = *p1pll; + rdev->clock.max_pixel_clock = le16_to_cpu(firmware_info->info.usMaxPixelClock); + if (rdev->clock.max_pixel_clock == 0) + rdev->clock.max_pixel_clock = 4; + return true; } diff --git a/drivers/gpu/drm/radeon/radeon_clocks.c b/drivers/gpu/drm/radeon/radeon_clocks.c index 5249af8..2d48e7a 100644 --- a/drivers/gpu/drm/radeon/radeon_clocks.c +++ b/drivers/gpu/drm/radeon/radeon_clocks.c @@ -117,7 +117,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) p1pll->reference_div = RREG32_PLL(RADEON_PPLL_REF_DIV) & 0x3ff; if (p1pll->reference_div < 2) p1pll->reference_div = 12; - p2pll->reference_div = p1pll->reference_div; + p2pll->reference_div = p1pll->reference_div; /* These aren't in the device-tree */ if (rdev->family >= CHIP_R420) { @@ -139,6 +139,8 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) p2pll->pll_out_min = 12500; p2pll->pll_out_max = 35000; } + /* not sure what the max should be in all cases */ + rdev->clock.max_pixel_clock = 35000; spll->reference_freq = mpll->reference_freq = p1pll->reference_freq; spll->reference_div = mpll->reference_div = @@ -151,7 +153,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) else rdev->clock.default_sclk = radeon_legacy_get_engine_clock(rdev); - + val = of_get_property(dp, "ATY,MCLK", NULL); if (val && *val) rdev->clock.default_mclk = (*val) / 10; @@ -160,7 +162,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) radeon_legacy_get_memory_clock(rdev); DRM_INFO("Using device-tree clock info\n"); - + return true; } #else diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index 19b10cf..797c8bc 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -866,6 +866,11 @@ bool radeon_combios_get_clock_info(struct drm_device *dev) rdev->clock.default_sclk = sclk; rdev->clock.default_mclk = mclk; + if (RBIOS32(pll_info + 0x16)) + rdev->clock.max_pixel_clock = RBIOS32(pll_info + 0x16); + else + rdev->clock.max_pixel_clock = 35000; /* might need something asic specific */ + return true; } return false; diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 9dc8684..1d1504b 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -628,8 +628,14 @@ static int radeon_vga_get_modes(struct drm_connector *connector) static int radeon_vga_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) { + struct drm_device *dev = connector->dev; + struct radeon_device *rdev = dev->dev_private; + /* XXX check mode bandwidth */ - /* XXX verify against max DAC output frequency */ + + if ((mode->clock / 10) > rdev->clock.max_pixel_clock) + return MODE_CLOCK_HIGH; + return MODE_OK; } @@ -1017,6 +1023,11 @@ static int radeon_dvi_mode_valid(struct drm_connector *connector, } else return MODE_CLOCK_HIGH; } + + /* check against the max pixel clock */ + if ((mode->clock / 10) > rdev->clock.max_pixel_clock) + return MODE_CLOCK_HIGH; + return MODE_OK; } -- 1.7.1.1 __
Re: Modeline problem with Radeon KMS
On Wed, Jun 8, 2011 at 11:31 AM, Meelis Roos wrote: >> > I have LG Flatron F900P CRT monitor. X drivers work fine, nouveau KMS >> > works fine but Radeon KMS selects a videomode that is out of spec for >> > monitor. This is not a regression - this hardware combination has never >> > worked for me yet with radeon KMS. The result is same for Radeon 7000 >> > (RV100, currently installed) and Radeon 9200 series card. > > Umm, I guess I forgot one important aspect. When X comes up, it finds a > good video mode and gets a picture. It's just the text consoles that > have no picture. > > In the console, it tells it's using 352x132 console. This translates > with 8x16 font to 2816x2112 and 9x16 font to 3168x2112 if I calculated > the right thing. > > Running fbset remotely verifies this: > > # fbset -s > mode "2816x2114" > geometry 2816 2114 2816 2114 8 > timings 0 0 0 0 0 0 0 > accel true > rgba 8/0,8/0,8/0,0/0 > endmode > > So it decides this modeline is usable for the console while it is not. > Ah, ok. yeah, that mode has a much higher clock than those chips can handle. Where is that mode even coming from? I don't see it in the EDID. The attached patch should filter out that mode. Alex From 890626ca18f9dec7ed49a4122153894a08689b4a Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Wed, 8 Jun 2011 12:53:53 -0400 Subject: [PATCH] drm/radeon/kms: check modes against max pixel clock Filter out modes that are higher than the max pixel clock. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon.h|1 + drivers/gpu/drm/radeon/radeon_atombios.c |4 drivers/gpu/drm/radeon/radeon_clocks.c |8 +--- drivers/gpu/drm/radeon/radeon_combios.c|5 + drivers/gpu/drm/radeon/radeon_connectors.c | 13 - 5 files changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 625f1af..bbcb00a 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -165,6 +165,7 @@ struct radeon_clock { uint32_t default_sclk; uint32_t default_dispclk; uint32_t dp_extclk; + uint32_t max_pixel_clock; }; /* diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c index 90dfb2b..fa62a50 100644 --- a/drivers/gpu/drm/radeon/radeon_atombios.c +++ b/drivers/gpu/drm/radeon/radeon_atombios.c @@ -1246,6 +1246,10 @@ bool radeon_atom_get_clock_info(struct drm_device *dev) } *dcpll = *p1pll; + rdev->clock.max_pixel_clock = le16_to_cpu(firmware_info->info.usMaxPixelClock); + if (rdev->clock.max_pixel_clock == 0) + rdev->clock.max_pixel_clock = 4; + return true; } diff --git a/drivers/gpu/drm/radeon/radeon_clocks.c b/drivers/gpu/drm/radeon/radeon_clocks.c index 5249af8..2d48e7a 100644 --- a/drivers/gpu/drm/radeon/radeon_clocks.c +++ b/drivers/gpu/drm/radeon/radeon_clocks.c @@ -117,7 +117,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) p1pll->reference_div = RREG32_PLL(RADEON_PPLL_REF_DIV) & 0x3ff; if (p1pll->reference_div < 2) p1pll->reference_div = 12; - p2pll->reference_div = p1pll->reference_div; + p2pll->reference_div = p1pll->reference_div; /* These aren't in the device-tree */ if (rdev->family >= CHIP_R420) { @@ -139,6 +139,8 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) p2pll->pll_out_min = 12500; p2pll->pll_out_max = 35000; } + /* not sure what the max should be in all cases */ + rdev->clock.max_pixel_clock = 35000; spll->reference_freq = mpll->reference_freq = p1pll->reference_freq; spll->reference_div = mpll->reference_div = @@ -151,7 +153,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) else rdev->clock.default_sclk = radeon_legacy_get_engine_clock(rdev); - + val = of_get_property(dp, "ATY,MCLK", NULL); if (val && *val) rdev->clock.default_mclk = (*val) / 10; @@ -160,7 +162,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) radeon_legacy_get_memory_clock(rdev); DRM_INFO("Using device-tree clock info\n"); - + return true; } #else diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index 19b10cf..797c8bc 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -866,6 +866,11 @@ bool radeon_combios_get_clock_info(struct drm_device *dev) rdev->clock.default_sclk = sclk; rdev->clock.default_mclk = mclk; + if (RBIOS32(pll_info + 0x16)) + rdev->clock.max_pixel_clock = RBIOS32(pll_info + 0x16); + else + rdev->clock.max_pixel_clock = 35000; /* might need something asic specific */ + return true; } return false; diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 9dc8684..1d1504b 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -628,8 +6
Re: Modeline problem with Radeon KMS
> > I have LG Flatron F900P CRT monitor. X drivers work fine, nouveau KMS > > works fine but Radeon KMS selects a videomode that is out of spec for > > monitor. This is not a regression - this hardware combination has never > > worked for me yet with radeon KMS. The result is same for Radeon 7000 > > (RV100, currently installed) and Radeon 9200 series card. Umm, I guess I forgot one important aspect. When X comes up, it finds a good video mode and gets a picture. It's just the text consoles that have no picture. In the console, it tells it's using 352x132 console. This translates with 8x16 font to 2816x2112 and 9x16 font to 3168x2112 if I calculated the right thing. Running fbset remotely verifies this: # fbset -s Is it just 2048x1536 that's causing problems? Do any other modes > work? 1600x1200 for example? X uses 2048x1536 successfully. 1600x1200, 1920x1440, 1280x1024 all work fine, just tested with xrandr. > > [ 36.111] (II) RADEON(0): Output VGA-0 using monitor section CM771 > > I notice you have a monitor section defined in your xorg.conf. Does > that monitor section perhaps have any old modelines from an old > monitor that may be causing problems? X without configuration also gets a working 2048x1536. X conf seems to be quite irrelevant - scree-related things here, and my list of resolutions is ignored anyway for some reason not important righh now. Section "Device" Identifier "AGP kaart" Driver "ati" Option "AGPMode" "2" EndSection Section "Monitor" Identifier "CM771" Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "AGP kaart" Monitor "CM771" DefaultDepth24 SubSection "Display" Depth 1 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 15 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1280x960" "1024x768" "832x624" "800x600" "720x400" "640x480" EndSubSection EndSection -- Meelis Roos (mr...@linux.ee) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Modeline problem with Radeon KMS
I have LG Flatron F900P CRT monitor. X drivers work fine, nouveau KMS works fine but Radeon KMS selects a videomode that is out of spec for monitor. This is not a regression - this hardware combination has never worked for me yet with radeon KMS. The result is same for Radeon 7000 (RV100, currently installed) and Radeon 9200 series card. When this happens, monitor tells this: Out of frequency HF: 89.2 kHz VF: 40.0 kHz Operating frequency HF: 30-111 kHz VF: 50-160 Hz When X comes up, it selects a working mode from the same EDID data. /sys/devices/pci:00/:00:01.0/:02:00.0/drm/card0/card0-VGA-1/edid is attached. [6.010622] [drm] radeon kernel modesetting enabled. [6.011178] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [6.011331] radeon :02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 [6.012456] [drm] initializing kernel modesetting (RV100 0x1002:0x5159). [6.012645] [drm] register mmio base: 0xFF9F [6.012784] [drm] register mmio size: 65536 [6.013432] agpgart-intel :00:00.0: AGP 2.0 bridge [6.013597] agpgart-intel :00:00.0: putting AGP V2 device into 4x mode [6.013767] radeon :02:00.0: putting AGP V2 device into 4x mode [6.013920] radeon :02:00.0: GTT: 64M 0xF800 - 0xFBFF [6.014071] radeon :02:00.0: VRAM: 128M 0xE800 - 0xEFFF (32M used) [6.014335] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [6.014477] [drm] Driver supports precise vblank timestamp query. [6.014664] [drm] radeon: irq initialized. [6.015030] [drm] Detected VRAM RAM=128M, BAR=128M [6.015182] [drm] RAM width 64bits DDR [6.015450] [TTM] Zone kernel: Available graphics memory: 257508 kiB. [6.015595] [TTM] Initializing pool allocator. [6.016176] [drm] radeon: 32M of VRAM memory ready [6.016319] [drm] radeon: 64M of GTT memory ready. [6.037624] radeon :02:00.0: WB disabled [6.040261] [drm] Loading R100 Microcode [6.266721] [drm] radeon: ring at 0xF8001000 [6.266894] [drm] ring test succeeded in 0 usecs [6.267455] [drm] radeon: ib pool ready. [6.267629] [drm] ib test succeeded in 0 usecs [6.271673] [drm] No TV DAC info found in BIOS [6.271957] [drm] Radeon Display Connectors [6.273402] [drm] Connector 0: [6.273551] [drm] VGA [6.273688] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [6.273826] [drm] Encoders: [6.273962] [drm] CRT1: INTERNAL_DAC1 [6.274099] [drm] Connector 1: [6.274232] [drm] DVI-I [6.274363] [drm] HPD1 [6.274500] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [6.274641] [drm] Encoders: [6.274776] [drm] CRT2: INTERNAL_DAC2 [6.274912] [drm] DFP1: INTERNAL_TMDS1 [6.275047] [drm] Connector 2: [6.275179] [drm] S-video [6.275313] [drm] Encoders: [6.275449] [drm] TV1: INTERNAL_DAC2 [6.563604] [drm] fb mappable at 0xE804 [6.563755] [drm] vram apper at 0xE800 [6.563892] [drm] size 5955584 [6.567854] [drm] fb depth is 8 [6.568074] [drm]pitch is 2816 [6.572969] fbcon: radeondrmfb (fb0) is primary device [6.786265] Console: switching to colour frame buffer device 352x132 [6.824320] fb0: radeondrmfb frame buffer device [6.824376] drm: registered panic notifier [6.824441] [drm] Initialized radeon 2.10.0 20080528 for :02:00.0 on minor 0 Full X log: [34.421] X.Org X Server 1.10.2 Release Date: 2011-05-28 [34.421] X Protocol Version 11, Revision 0 [34.421] Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian [34.421] Current Operating System: Linux rhn 3.0.0-rc2-00108-gcb0a02e #378 PREEMPT Wed Jun 8 13:43:58 EEST 2011 i686 [34.421] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.0.0-rc2-00108-gcb0a02e root=/dev/sda3 ro lapic petconsole=1980@192.168.74.17/eth0,1975@192.168.74.24/00:50:8d:91:d9:f0 [34.421] Build Date: 30 May 2011 12:03:58PM [34.421] xorg-server 2:1.10.2-1 (Cyril Brulebois ) [34.421] Current version of pixman: 0.21.8 [34.421]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [34.421] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [34.422] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 8 14:27:24 2011 [34.508] (==) Using config file: "/etc/X11/xorg.conf" [34.508] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [34.581] (==) ServerLayout "Default Layout" [34.581] (**) |-->Screen "Default Screen" (0) [34.581] (**) | |-->Monitor "CM771" [34.581] (**) | |-->Device "AGP kaart" [34.581] (**) |-->Input Device "Generic Keyboard" [34.582] (**) |-->Input Device "Configured Mouse" [34.582] (**) Option "BlankTime" "
Radeon drm: Hang with posting GPU when PCI card is primary
I have a PC for testing different addon cards & drivers. I recently set BIOS to use PCI graphics as primary to test PCI cards, and afterwards left it like this. However, it does not work when loading radeon DRM driver for AGP Radeon 7000 (RV100) card. The card is detected, DRM loaded and KMS initiated. Then DRM/KMS finds the card is not POSTed, decides to POST it and the whole computer hangs with [drm] GPU not posted. posting now... Full netconsole output below. [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.0.0-rc2-00108-gcb0a02e (mroos@rhn) (gcc version 4.6.1 20110526 (prerelease) (Debian 4.6.0-10) ) #378 PREEMPT Wed Jun 8 13:43:58 EEST 2011 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ffc (usable) [0.00] BIOS-e820: 1ffc - 1fff8000 (ACPI data) [0.00] BIOS-e820: 1fff8000 - 2000 (ACPI NVS) [0.00] BIOS-e820: ffb8 - ffc0 (reserved) [0.00] BIOS-e820: fff0 - 0001 (reserved) [0.00] debug: ignoring loglevel setting. [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI 2.3 present. [0.00] DMI: /D815EEA2 , BIOS EA81520A.86A.0039.P21.0211061753 11/06/2002 [0.00] e820 update range: - 0001 (usable) ==> (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x1ffc0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-D uncachable [0.00] E-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask FE000 write-back [0.00] 1 base 02000 mask 0 write-back [0.00] 2 base 02000 mask 0 uncachable [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT not supported by CPU. [0.00] original variable MTRRs [0.00] reg 0, base: 0GB, range: 512MB, type WB [0.00] reg 1, base: 512MB, range: 1MB, type WB [0.00] reg 2, base: 512MB, range: 1MB, type UC [0.00] total RAM covered: 512M [0.00] Found optimal setting for mtrr clean up [0.00] gran_size: 64K chunk_size: 64K num_reg: 1 lose cover RAM: 0G [0.00] New variable MTRRs [0.00] reg 0, base: 0GB, range: 512MB, type WB [0.00] initial memory mapped : 0 - 0180 [0.00] Base memory trampoline at [c009e000] 9e000 size 4096 [0.00] init_memory_mapping: -1ffc [0.00] 00 - 40 page 4k [0.00] 40 - 001fc0 page 2M [0.00] 001fc0 - 001ffc page 4k [0.00] kernel direct mapping tables up to 1ffc @ 17fb000-180 [0.00] ACPI: RSDP 000ff980 00014 (v00 AMI ) [0.00] ACPI: RSDT 1fff 0002C (v01 D815EA D815EEA2 20021106 MSFT 1011) [0.00] ACPI: FACP 1fff1000 00074 (v01 D815EA EA81510A 20021106 MSFT 1011) [0.00] ACPI: DSDT 1ffe 030E4 (v01 D815E2 EA81520A 0023 MSFT 010B) [0.00] ACPI: FACS 1fff8000 00040 [0.00] ACPI: SSDT 1ffe30e4 00035 (v01 D815EA EA81510A 0015 MSFT 010B) [0.00] 511MB LOWMEM available. [0.00] mapped low ram: 0 - 1ffc [0.00] low ram: 0 - 1ffc [0.00] Zone PFN ranges: [0.00] DMA 0x0010 -> 0x1000 [0.00] Normal 0x1000 -> 0x0001ffc0 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0: 0x0010 -> 0x009f [0.00] 0: 0x0100 -> 0x0001ffc0 [0.00] On node 0 totalpages: 130895 [0.00] free_area_init_node: node 0, pgdat c139a4d0, node_mem_map dfbc0200 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 3951 pages, LIFO batch:0 [0.00] Normal zone: 992 pages used for memmap [0.00] Normal zone: 125920 pages, LIFO batch:31 [0.00] Using APIC driver default [0.00] ACPI: PM-Timer IO Port: 0x408 [0.00] Found and enabled local APIC! [0.00] Allocating PCI resources starting at 2000 (gap: 2000:dfb8) [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #3 from Pascal Billery-Schneider 2011-06-08 08:42:05 PDT --- First thank you for your interest. Well, I did not try yet on this computer for this one is for my work. I shall look at http://www.mesa3d.org/install.html ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g
https://bugs.freedesktop.org/show_bug.cgi?id=36609 --- Comment #4 from Fabio Pedretti 2011-06-08 08:41:15 PDT --- (In reply to comment #3) > Unfortunately, commit 51095f74cf92d3cada7366ce898ade7693570b48 doesn't fix the > missing triangles in ut2004. Is this still an issue? If yes is 45920d2ecb38b14fdda5253fecce996570c22863 the first bad commit? Maybe this should be moved to a new bug since my original problem is fixed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38070] Blender fonts are blurry
https://bugs.freedesktop.org/show_bug.cgi?id=38070 --- Comment #3 from Pascal Billery-Schneider 2011-06-08 08:42:05 PDT --- First thank you for your interest. Well, I did not try yet on this computer for this one is for my work. I shall look at http://www.mesa3d.org/install.html ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.