[Bug 28125] DRI2 prevents indirect glx
https://bugs.freedesktop.org/show_bug.cgi?id=28125 Christopher James Halse Rogers changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Christopher James Halse Rogers 2011-08-10 21:10:59 PDT --- Fixed in fbc2fcf685d22ec9bc9465e1f731529979497eaa -- 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 28125] DRI2 prevents indirect glx
https://bugs.freedesktop.org/show_bug.cgi?id=28125 Christopher James Halse Rogers changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Christopher James Halse Rogers 2011-08-10 21:10:59 PDT --- Fixed in fbc2fcf685d22ec9bc9465e1f731529979497eaa -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark
https://bugs.freedesktop.org/show_bug.cgi?id=39882 --- Comment #6 from gottfried.hai...@gmail.com 2011-08-10 17:03:12 PDT --- Regarding VT switching: When I press Ctrl+Alt+F1 after plugging in I do get a picture again on the internal LCD.. when I then press Ctrl+Alt+F7 I am even properly back in X. Thanks -- 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 39882] Regression: Plugging in a HDMI connector makes the LCD of X120e go dark
https://bugs.freedesktop.org/show_bug.cgi?id=39882 --- Comment #6 from gottfried.haider at gmail.com 2011-08-10 17:03:12 PDT --- Regarding VT switching: When I press Ctrl+Alt+F1 after plugging in I do get a picture again on the internal LCD.. when I then press Ctrl+Alt+F7 I am even properly back in X. Thanks -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Wed, Aug 10, 2011 at 10:41:44AM +0100, Alan Cox wrote: > > Sorry, I won't submit a patch. If there is a need to find/fix/cleanup > > obvious things after company's developers, I have better things to do, > > and a todo item to re-evaluate hardware for my next project. > > You seem confused. If you have a support contract of some form with a > Linux supplier or Intel please contact your support. This mailing list > isn't for support services. Thanks for clarifying.
[PATCH 2.6.38-10-generic] device driver: fix oops in radeon driver due to incorrect value from hardware
On 08/10/2011 02:54 PM, Michel D?nzer wrote: > On Die, 2011-08-09 at 23:52 +0530, Mayank Rungta wrote: >> Added a check for the radeon ring buffer write index in r600.c which >> reads 0x on resume. This results in an Oops during >> radeon_ring_write. Masking the value averts this. >> >> This problem is not seen to be fixed in 3.0 r600.c as well. >> >> Detailed analysis of the problem can be found at - >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ >> >> --- >> >> BUG: unable to handle kernel paging request at fa501ffc - Oops at >> r600_cp_start+0x48/0x380 in r600_cp_resume+0x345/0x580 [radeon] >> >> drivers/gpu/drm/radeon/r600.c >> >> >> >> --- linux-2.6.38/drivers/gpu/drm/radeon/r600.c.orig2011-08-05 >> 15:39:40.824612700 +0530 >> +++ linux-2.6.38/drivers/gpu/drm/radeon/r600.c2011-08-08 >> 05:29:21.744417857 +0530 >> @@ -2218,6 +2218,8 @@ int r600_cp_resume(struct radeon_device >> >>rdev->cp.rptr = RREG32(CP_RB_RPTR); >>rdev->cp.wptr = RREG32(CP_RB_WPTR); >> +/* protect against crazy HW on resume */ >> +rdev->cp.wptr&= rdev->cp.ptr_mask; > > The indentation of the lines you're adding doesn't match the surrounding > lines. Sorry. This looked fine in the mail I sent. I shall be careful in future. > > > Although the same workaround is already in r100.c, I wonder if we > shouldn't rather try and eliminate all reads from the CP_RB_WPTR > register, at least other than for debugging purposes. Alex, what do you > think? > > Otherwise, this should probably be added in evergreen.c as well. > > >> Developer's Certificate of Origin 1.1 >> >> [...] > > No need to include all this text, just the *-by: tags are enough. > Point taken.
Re: [PATCH -next] drm: fix kconfig unmet dependency warning
On Wed, 10 Aug 2011 14:24:01 -0700 Randy Dunlap wrote: Sorry, this applies to mainline, not linux-next. > From: Randy Dunlap > > Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on > BACKLIGHT_LCD_SUPPORT, so select the latter along with the former. > > warning: (DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT && > PANEL_SHARP_LS037V7DW01 && PANEL_ACX565AKM && USB_APPLEDISPLAY && > FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP > && ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > > Signed-off-by: Randy Dunlap > --- > drivers/gpu/drm/Kconfig |1 + > 1 file changed, 1 insertion(+) > > --- lnx-31-rc1.orig/drivers/gpu/drm/Kconfig > +++ lnx-31-rc1/drivers/gpu/drm/Kconfig > @@ -96,6 +96,7 @@ config DRM_I915 > select FB_CFB_IMAGEBLIT > # i915 depends on ACPI_VIDEO when ACPI is enabled > # but for select to work, need to select ACPI_VIDEO's dependencies, ick > + select BACKLIGHT_LCD_SUPPORT if ACPI > select BACKLIGHT_CLASS_DEVICE if ACPI > select VIDEO_OUTPUT_CONTROL if ACPI > select INPUT if ACPI > -- --- ~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 -next] drm: fix kconfig unmet dependency warning
On Wed, 10 Aug 2011 14:24:01 -0700 Randy Dunlap wrote: Sorry, this applies to mainline, not linux-next. > From: Randy Dunlap > > Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on > BACKLIGHT_LCD_SUPPORT, so select the latter along with the former. > > warning: (DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT && > PANEL_SHARP_LS037V7DW01 && PANEL_ACX565AKM && USB_APPLEDISPLAY && > FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP > && ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > > Signed-off-by: Randy Dunlap > --- > drivers/gpu/drm/Kconfig |1 + > 1 file changed, 1 insertion(+) > > --- lnx-31-rc1.orig/drivers/gpu/drm/Kconfig > +++ lnx-31-rc1/drivers/gpu/drm/Kconfig > @@ -96,6 +96,7 @@ config DRM_I915 > select FB_CFB_IMAGEBLIT > # i915 depends on ACPI_VIDEO when ACPI is enabled > # but for select to work, need to select ACPI_VIDEO's dependencies, ick > + select BACKLIGHT_LCD_SUPPORT if ACPI > select BACKLIGHT_CLASS_DEVICE if ACPI > select VIDEO_OUTPUT_CONTROL if ACPI > select INPUT if ACPI > -- --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code ***
[PATCH -next] drm: fix kconfig unmet dependency warning
From: Randy Dunlap Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_LCD_SUPPORT, so select the latter along with the former. warning: (DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT && PANEL_SHARP_LS037V7DW01 && PANEL_ACX565AKM && USB_APPLEDISPLAY && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP && ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) Signed-off-by: Randy Dunlap --- drivers/gpu/drm/Kconfig |1 + 1 file changed, 1 insertion(+) --- lnx-31-rc1.orig/drivers/gpu/drm/Kconfig +++ lnx-31-rc1/drivers/gpu/drm/Kconfig @@ -96,6 +96,7 @@ config DRM_I915 select FB_CFB_IMAGEBLIT # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick + select BACKLIGHT_LCD_SUPPORT if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI select VIDEO_OUTPUT_CONTROL if ACPI select INPUT if ACPI ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm: fix kconfig unmet dependency warning
From: Randy Dunlap Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on BACKLIGHT_LCD_SUPPORT, so select the latter along with the former. warning: (DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT && PANEL_SHARP_LS037V7DW01 && PANEL_ACX565AKM && USB_APPLEDISPLAY && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP && ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) Signed-off-by: Randy Dunlap --- drivers/gpu/drm/Kconfig |1 + 1 file changed, 1 insertion(+) --- lnx-31-rc1.orig/drivers/gpu/drm/Kconfig +++ lnx-31-rc1/drivers/gpu/drm/Kconfig @@ -96,6 +96,7 @@ config DRM_I915 select FB_CFB_IMAGEBLIT # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick + select BACKLIGHT_LCD_SUPPORT if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI select VIDEO_OUTPUT_CONTROL if ACPI select INPUT if ACPI
[PATCH 3/9] drm/gma500: use common functions for mmap offset creation
On Thu, 4 Aug 2011 12:07:40 -0500 Rob Clark wrote: I'm happy with these but it will need contributing with your Signed-off-by: to progress upstream of course
KMS resume sequence
After my system sit idle for a while, my driver gets the following calls to turn off display: encoder_dpms crtc_dpms I then use the keyboard to resume. Upon resuming, I can see two calls: crtc_set_config, and crtc_load_lut. The display remains turned off because I am not getting calls to encoder_dpms or connector_dpms. As an extra data point, currently I am using drm_helper_crtc_set_config(), and I've noticed that both mode_changed and fb_changed are FALSE, which means set_config is not going to try and set a mode or update the mode base. Regardless of what set_config is doing, since KMS used dpms functions to turn off the display, I'd expect it to use them to turn them back on. If this is not the case, then can someone let me know where the expected place to turn the display(s) back on may be? Thanks, Sinclair
[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Tue, Aug 09, 2011 at 10:43:08AM -0700, Ray Lee wrote: > On Tue, Aug 9, 2011 at 10:40 AM, Kirill Smelkov wrote: > >> If you like, submit a patch. You may now be more up-to-date on those > >> particular code paths than most of the intel-gfx developers. > > > > Ray, I'd agree with you if the topic was about cleanups. > > At this point it is about cleanups unless Keith's patch upthread does > not work for you. Does it or not? I've already wrote two weeks ago it does, but if this needs to be restated one more time here it is: Keith's patch fixes the problem in a sense that X now starts and seemingly works (thanks), but several issues remain to be there imho. I've got the message, if it's ok for intel-gfx to leave them as is - it's ok for me. Peace, Kirill
[PULL] drm-intel-next
On 08/03/2011 11:14 PM, Keith Packard wrote: > > Here's a pile of fixes on top of the stuff already in drm-core-next. > > * Pile of mode setting fixes which eliminate a selection of bugs and > other annoyances. Eliminates the 'stripey' effect when going from > two to one monitor, makes hot-plug work after suspend/resume, turns > off the pipe/plane in DPMS off. Can you ack at least this one: >Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP" (i.e. d2b996ac698aebb28557355857927b8b934bb4f9) for -stable? It fixes an annoying regression in 3.0. Thanks, Andy
KMS resume sequence
After my system sit idle for a while, my driver gets the following calls to turn off display: encoder_dpms crtc_dpms I then use the keyboard to resume. Upon resuming, I can see two calls: crtc_set_config, and crtc_load_lut. The display remains turned off because I am not getting calls to encoder_dpms or connector_dpms. As an extra data point, currently I am using drm_helper_crtc_set_config(), and I've noticed that both mode_changed and fb_changed are FALSE, which means set_config is not going to try and set a mode or update the mode base. Regardless of what set_config is doing, since KMS used dpms functions to turn off the display, I'd expect it to use them to turn them back on. If this is not the case, then can someone let me know where the expected place to turn the display(s) back on may be? Thanks, Sinclair ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: add missing header file
? 2011?08?09? 21:32, Alex Deucher ??:
> On Mon, Aug 8, 2011 at 3:22 AM, Amerigo Wang wrote:
>> This patch fixes the following 'make headers_check' errors:
>>
>> linux-2.6/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type
>> without #include
>> linux-2.6/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type
>> without #include
>> linux-2.6/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type
>> without #include
>> linux-2.6/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type
>> without #include
>> linux-2.6/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type
>> without #include
>>
>
> These files are shared with BSD, and they get the linux/types.h from drm.h.
>
Thanks, then these warnings should be bogus.
[PATCH 2.6.38-10-generic] device driver: fix oops in radeon driver due to incorrect value from hardware
On Die, 2011-08-09 at 23:52 +0530, Mayank Rungta wrote: > Added a check for the radeon ring buffer write index in r600.c which > reads 0x on resume. This results in an Oops during > radeon_ring_write. Masking the value averts this. > > This problem is not seen to be fixed in 3.0 r600.c as well. > > Detailed analysis of the problem can be found at - > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ > > --- > > BUG: unable to handle kernel paging request at fa501ffc - Oops at > r600_cp_start+0x48/0x380 in r600_cp_resume+0x345/0x580 [radeon] > > drivers/gpu/drm/radeon/r600.c > > > > --- linux-2.6.38/drivers/gpu/drm/radeon/r600.c.orig2011-08-05 > 15:39:40.824612700 +0530 > +++ linux-2.6.38/drivers/gpu/drm/radeon/r600.c2011-08-08 > 05:29:21.744417857 +0530 > @@ -2218,6 +2218,8 @@ int r600_cp_resume(struct radeon_device > > rdev->cp.rptr = RREG32(CP_RB_RPTR); > rdev->cp.wptr = RREG32(CP_RB_WPTR); > +/* protect against crazy HW on resume */ > +rdev->cp.wptr &= rdev->cp.ptr_mask; The indentation of the lines you're adding doesn't match the surrounding lines. Although the same workaround is already in r100.c, I wonder if we shouldn't rather try and eliminate all reads from the CP_RB_WPTR register, at least other than for debugging purposes. Alex, what do you think? Otherwise, this should probably be added in evergreen.c as well. > Developer's Certificate of Origin 1.1 > > [...] No need to include all this text, just the *-by: tags are enough. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
> Sorry, I won't submit a patch. If there is a need to find/fix/cleanup > obvious things after company's developers, I have better things to do, > and a todo item to re-evaluate hardware for my next project. You seem confused. If you have a support contract of some form with a Linux supplier or Intel please contact your support. This mailing list isn't for support services. Alan
Re: [PULL] drm-intel-next
On Wed, 10 Aug 2011 12:20:14 -0400, Andy Lutomirski wrote: > Can you ack at least this one: > > >Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP" > (i.e. d2b996ac698aebb28557355857927b8b934bb4f9) > > for -stable? It fixes an annoying regression in 3.0. I'm working on a set of patches for -stable; we've found a number of small patches that fix some fairly serious regressions. -- keith.pack...@intel.com pgpGyMjuOrpj5.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
On Wed, 10 Aug 2011 12:20:14 -0400, Andy Lutomirski wrote: > Can you ack at least this one: > > >Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP" > (i.e. d2b996ac698aebb28557355857927b8b934bb4f9) > > for -stable? It fixes an annoying regression in 3.0. I'm working on a set of patches for -stable; we've found a number of small patches that fix some fairly serious regressions. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110810/a1f9f637/attachment.pgp>
[PATCH 2.6.38-10-generic] device driver: fix oops in radeon driver due to incorrect value from hardware
2011/8/10 Michel D?nzer : > On Die, 2011-08-09 at 23:52 +0530, Mayank Rungta wrote: >> Added a check for the radeon ring buffer write index in r600.c which >> reads 0x on resume. This results in an Oops during >> radeon_ring_write. Masking the value averts this. >> >> This problem is not seen to be fixed in 3.0 r600.c as well. >> >> Detailed analysis of the problem can be found at - >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ >> >> --- >> >> BUG: unable to handle kernel paging request at fa501ffc - Oops at >> r600_cp_start+0x48/0x380 in r600_cp_resume+0x345/0x580 [radeon] >> >> drivers/gpu/drm/radeon/r600.c >> >> >> >> --- linux-2.6.38/drivers/gpu/drm/radeon/r600.c.orig ? ?2011-08-05 >> 15:39:40.824612700 +0530 >> +++ linux-2.6.38/drivers/gpu/drm/radeon/r600.c ? ?2011-08-08 >> 05:29:21.744417857 +0530 >> @@ -2218,6 +2218,8 @@ int r600_cp_resume(struct radeon_device >> >> ? ? ? rdev->cp.rptr = RREG32(CP_RB_RPTR); >> ? ? ? rdev->cp.wptr = RREG32(CP_RB_WPTR); >> + ? ?/* protect against crazy HW on resume */ >> + ? ?rdev->cp.wptr &= rdev->cp.ptr_mask; > > The indentation of the lines you're adding doesn't match the surrounding > lines. > > > Although the same workaround is already in r100.c, I wonder if we > shouldn't rather try and eliminate all reads from the CP_RB_WPTR > register, at least other than for debugging purposes. Alex, what do you > think? Either this or reset the registers to 0 or a saved value on resume rather than reading from them. > > Otherwise, this should probably be added in evergreen.c as well. > Yes, and ni.c as well. Alex > >> ? ? ? ? ?Developer's Certificate of Origin 1.1 >> >> ? ? ? ? ?[...] > > No need to include all this text, just the *-by: tags are enough. > > > -- > Earthling Michel D?nzer ? ? ? ? ? | ? ? ? ? ? ? ? ? ? http://www.amd.com > Libre software enthusiast ? ? ? ? | ? ? ? ? ?Debian, X and DRI developer > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
Re: [PULL] drm-intel-next
On 08/03/2011 11:14 PM, Keith Packard wrote: Here's a pile of fixes on top of the stuff already in drm-core-next. * Pile of mode setting fixes which eliminate a selection of bugs and other annoyances. Eliminates the 'stripey' effect when going from two to one monitor, makes hot-plug work after suspend/resume, turns off the pipe/plane in DPMS off. Can you ack at least this one: Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP" (i.e. d2b996ac698aebb28557355857927b8b934bb4f9) for -stable? It fixes an annoying regression in 3.0. Thanks, Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Michel Dänzer 2011-08-10 09:23:08 PDT --- (In reply to comment #12) > But your patch was radeon-only. I think > * all platforms should behave the same, It's up to each driver. > * and if they do, this behaviour should be documented somewhere. I updated the radeon manpage paragraph about XV_CRTC. -- 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 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Michel D?nzer 2011-08-10 09:23:08 PDT --- (In reply to comment #12) > But your patch was radeon-only. I think > * all platforms should behave the same, It's up to each driver. > * and if they do, this behaviour should be documented somewhere. I updated the radeon manpage paragraph about XV_CRTC. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=39202 --- Comment #12 from Siganderson 2011-08-10 08:59:56 PDT --- (In reply to comment #11) > I don't really see how the frame rate could have been higher than the refresh > rate if vsync was enabled unless there was a bug in the vsync code in older > kernels. I'm not an expert like you, but I think that the fps is going from 120 to 60 and that should be possible as 120 is multiple of 60 (my refresh rate). Is this correct? If you need, I can bisect in some days. -- 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 39202] FPS - KDE desktop effects with 3.0 rc6 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=39202 --- Comment #12 from Siganderson 2011-08-10 08:59:56 PDT --- (In reply to comment #11) > I don't really see how the frame rate could have been higher than the refresh > rate if vsync was enabled unless there was a bug in the vsync code in older > kernels. I'm not an expert like you, but I think that the fps is going from 120 to 60 and that should be possible as 120 is multiple of 60 (my refresh rate). Is this correct? If you need, I can bisect in some days. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 3/3] drm/gma500: use common functions for mmap offset creation
Signed-off-by: Rob Clark
Signed-off-by: Alan Cox
---
drivers/staging/gma500/psb_gem.c | 63 +
1 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/gma500/psb_gem.c b/drivers/staging/gma500/psb_gem.c
index 76ff7ba..3a397f5 100644
--- a/drivers/staging/gma500/psb_gem.c
+++ b/drivers/staging/gma500/psb_gem.c
@@ -42,13 +42,7 @@ 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;
- struct drm_map_list *list = &obj->map_list;
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
+ drm_gem_free_mmap_offset(obj);
}
drm_gem_object_release(obj);
}
@@ -60,59 +54,6 @@ int psb_gem_get_aperture(struct drm_device *dev, void *data,
}
/**
- * psb_gem_create_mmap_offset - invent an mmap offset
- * @obj: our object
- *
- * This is basically doing by hand a pile of ugly crap which should
- * be done automatically by the GEM library code but isn't
- */
-static int psb_gem_create_mmap_offset(struct drm_gem_object *obj)
-{
- struct drm_device *dev = obj->dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret;
-
- list = &obj->map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (list->map == NULL)
- return -ENOMEM;
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->size;
- map->handle =obj;
-
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->size / PAGE_SIZE, 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
- ret = -ENOSPC;
- goto free_it;
- }
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->size / PAGE_SIZE, 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto free_it;
- }
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto free_mm;
- }
- return 0;
-
-free_mm:
- drm_mm_put_block(list->file_offset_node);
-free_it:
- kfree(list->map);
- list->map = NULL;
- return ret;
-}
-
-/**
* psb_gem_dumb_map_gtt- buffer mapping for dumb interface
* @file: our drm client file
* @dev: drm device
@@ -142,7 +83,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct
drm_device *dev,
/* Make it mmapable */
if (!obj->map_list.map) {
- ret = psb_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
--
1.7.5.4
[PATCH 2/3] drm/i915: use common functions for mmap offset creation
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_gem.c | 85 +--
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5c0d124..5676eaa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1265,74 +1265,6 @@ out:
}
/**
- * i915_gem_create_mmap_offset - create a fake mmap offset for an object
- * @obj: obj in question
- *
- * GEM memory mapping works by handing back to userspace a fake mmap offset
- * it can use in a subsequent mmap(2) call. The DRM core code then looks
- * up the object based on the offset and sets up the various memory mapping
- * structures.
- *
- * This routine allocates and attaches a fake offset for @obj.
- */
-static int
-i915_gem_create_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret = 0;
-
- /* Set the object up for mmap'ing */
- list = &obj->base.map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (!list->map)
- return -ENOMEM;
-
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->base.size;
- map->handle = obj;
-
- /* Get a DRM GEM mmap offset allocated... */
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->base.size / PAGE_SIZE,
- 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n",
- obj->base.name);
- ret = -ENOSPC;
- goto out_free_list;
- }
-
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->base.size / PAGE_SIZE,
- 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto out_free_list;
- }
-
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto out_free_mm;
- }
-
- return 0;
-
-out_free_mm:
- drm_mm_put_block(list->file_offset_node);
-out_free_list:
- kfree(list->map);
- list->map = NULL;
-
- return ret;
-}
-
-/**
* i915_gem_release_mmap - remove physical page mappings
* @obj: obj in question
*
@@ -1360,19 +1292,6 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
obj->fault_mappable = false;
}
-static void
-i915_gem_free_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list = &obj->base.map_list;
-
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
-}
-
static uint32_t
i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
{
@@ -1493,7 +1412,7 @@ i915_gem_mmap_gtt(struct drm_file *file,
}
if (!obj->base.map_list.map) {
- ret = i915_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(&obj->base);
if (ret)
goto out;
}
@@ -3614,7 +3533,7 @@ static void i915_gem_free_object_tail(struct
drm_i915_gem_object *obj)
trace_i915_gem_object_destroy(obj);
if (obj->base.map_list.map)
- i915_gem_free_mmap_offset(obj);
+ drm_gem_free_mmap_offset(&obj->base);
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(dev_priv, obj->base.size);
--
1.7.5.4
[PATCH 1/3] drm/gem: add functions for mmap offset creation
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 88 +
include/drm/drmP.h|3 ++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 2b997d2..809358a 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -273,6 +273,94 @@ again:
}
EXPORT_SYMBOL(drm_gem_handle_create);
+
+/**
+ * drm_gem_free_mmap_offset - release a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ */
+void
+drm_gem_free_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list = &obj->map_list;
+
+ drm_ht_remove_item(&mm->offset_hash, &list->hash);
+ drm_mm_put_block(list->file_offset_node);
+ kfree(list->map);
+ list->map = NULL;
+}
+EXPORT_SYMBOL(drm_gem_free_mmap_offset);
+
+/**
+ * drm_gem_create_mmap_offset - create a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * GEM memory mapping works by handing back to userspace a fake mmap offset
+ * it can use in a subsequent mmap(2) call. The DRM core code then looks
+ * up the object based on the offset and sets up the various memory mapping
+ * structures.
+ *
+ * This routine allocates and attaches a fake offset for @obj.
+ */
+int
+drm_gem_create_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list;
+ struct drm_local_map *map;
+ int ret = 0;
+
+ /* Set the object up for mmap'ing */
+ list = &obj->map_list;
+ list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
+ if (!list->map)
+ return -ENOMEM;
+
+ map = list->map;
+ map->type = _DRM_GEM;
+ map->size = obj->size;
+ map->handle = obj;
+
+ /* Get a DRM GEM mmap offset allocated... */
+ list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
+ obj->size / PAGE_SIZE, 0, 0);
+
+ if (!list->file_offset_node) {
+ DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
+ ret = -ENOSPC;
+ goto out_free_list;
+ }
+
+ list->file_offset_node = drm_mm_get_block(list->file_offset_node,
+ obj->size / PAGE_SIZE, 0);
+ if (!list->file_offset_node) {
+ ret = -ENOMEM;
+ goto out_free_list;
+ }
+
+ list->hash.key = list->file_offset_node->start;
+ ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
+ if (ret) {
+ DRM_ERROR("failed to add to map hash\n");
+ goto out_free_mm;
+ }
+
+ return 0;
+
+out_free_mm:
+ drm_mm_put_block(list->file_offset_node);
+out_free_list:
+ kfree(list->map);
+ list->map = NULL;
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_create_mmap_offset);
+
/** Returns a reference to the object named by the handle. */
struct drm_gem_object *
drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 111e98f..ec156c3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1622,6 +1622,9 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
}
+void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
+int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
+
struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
struct drm_file *filp,
u32 handle);
--
1.7.5.4
[Bug 39714] Slow and choppy 3D performace on evergreen after pm-suspend
https://bugs.freedesktop.org/show_bug.cgi?id=39714 --- Comment #3 from Michel Dänzer 2011-08-10 07:51:01 PDT --- Here's my theory on what's happening: On suspend, all BOs located in VRAM are evicted to GTT using radeon_bo_evict_vram() -> ttm_bo_evict_mm(). There's no mechanism to explicitly try and move these back to VRAM after resume, so some of them probably stay in GTT indefinitely. Not sure offhand how to address this... -- 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 39714] Slow and choppy 3D performace on evergreen after pm-suspend
https://bugs.freedesktop.org/show_bug.cgi?id=39714 --- Comment #3 from Michel D?nzer 2011-08-10 07:51:01 PDT --- Here's my theory on what's happening: On suspend, all BOs located in VRAM are evicted to GTT using radeon_bo_evict_vram() -> ttm_bo_evict_mm(). There's no mechanism to explicitly try and move these back to VRAM after resume, so some of them probably stay in GTT indefinitely. Not sure offhand how to address this... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Wed, Aug 10, 2011 at 10:41:44AM +0100, Alan Cox wrote: > > Sorry, I won't submit a patch. If there is a need to find/fix/cleanup > > obvious things after company's developers, I have better things to do, > > and a todo item to re-evaluate hardware for my next project. > > You seem confused. If you have a support contract of some form with a > Linux supplier or Intel please contact your support. This mailing list > isn't for support services. Thanks for clarifying. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2.6.38-10-generic] device driver: fix oops in radeon driver due to incorrect value from hardware
On 08/10/2011 02:54 PM, Michel Dänzer wrote: On Die, 2011-08-09 at 23:52 +0530, Mayank Rungta wrote: Added a check for the radeon ring buffer write index in r600.c which reads 0x on resume. This results in an Oops during radeon_ring_write. Masking the value averts this. This problem is not seen to be fixed in 3.0 r600.c as well. Detailed analysis of the problem can be found at - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ --- BUG: unable to handle kernel paging request at fa501ffc - Oops at r600_cp_start+0x48/0x380 in r600_cp_resume+0x345/0x580 [radeon] drivers/gpu/drm/radeon/r600.c --- linux-2.6.38/drivers/gpu/drm/radeon/r600.c.orig2011-08-05 15:39:40.824612700 +0530 +++ linux-2.6.38/drivers/gpu/drm/radeon/r600.c2011-08-08 05:29:21.744417857 +0530 @@ -2218,6 +2218,8 @@ int r600_cp_resume(struct radeon_device rdev->cp.rptr = RREG32(CP_RB_RPTR); rdev->cp.wptr = RREG32(CP_RB_WPTR); +/* protect against crazy HW on resume */ +rdev->cp.wptr&= rdev->cp.ptr_mask; The indentation of the lines you're adding doesn't match the surrounding lines. Sorry. This looked fine in the mail I sent. I shall be careful in future. Although the same workaround is already in r100.c, I wonder if we shouldn't rather try and eliminate all reads from the CP_RB_WPTR register, at least other than for debugging purposes. Alex, what do you think? Otherwise, this should probably be added in evergreen.c as well. Developer's Certificate of Origin 1.1 [...] No need to include all this text, just the *-by: tags are enough. Point taken. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 --- Comment #13 from Alex Deucher 2011-08-10 06:45:40 PDT --- (In reply to comment #12) > Well, as it seems to be impossible (at least for my combination of LVDS and > DP) > to have two (or even more) outputs in sync at the same time, Unfortunately this is a hw limitation. It can really only work in some very limited situations. You would have to use identical monitors with identical modelines being driven by the same encoder types. Even in your setup, if you could have used the same crtc, each monitor has different timing for the display so it likely wouldn't have worked as one of the displays may not have synced properly. LVDS: Modeline "1920x1200"x60.0 164.80 1920 2020 2052 2224 1200 1202 1208 1235 (74.1 kHz) DP: Modeline "1920x1200"x60.0 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync (74.0 kHz) -- 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 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 --- Comment #13 from Alex Deucher 2011-08-10 06:45:40 PDT --- (In reply to comment #12) > Well, as it seems to be impossible (at least for my combination of LVDS and > DP) > to have two (or even more) outputs in sync at the same time, Unfortunately this is a hw limitation. It can really only work in some very limited situations. You would have to use identical monitors with identical modelines being driven by the same encoder types. Even in your setup, if you could have used the same crtc, each monitor has different timing for the display so it likely wouldn't have worked as one of the displays may not have synced properly. LVDS: Modeline "1920x1200"x60.0 164.80 1920 2020 2052 2224 1200 1202 1208 1235 (74.1 kHz) DP: Modeline "1920x1200"x60.0 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync (74.0 kHz) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=39202 --- Comment #11 from Alex Deucher 2011-08-10 06:31:28 PDT --- I don't really see how the frame rate could have been higher than the refresh rate if vsync was enabled unless there was a bug in the vsync code in older kernels. -- 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 39202] FPS - KDE desktop effects with 3.0 rc6 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=39202 --- Comment #11 from Alex Deucher 2011-08-10 06:31:28 PDT --- I don't really see how the frame rate could have been higher than the refresh rate if vsync was enabled unless there was a bug in the vsync code in older kernels. -- 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 2.6.38-10-generic] device driver: fix oops in radeon driver due to incorrect value from hardware
2011/8/10 Michel Dänzer : > On Die, 2011-08-09 at 23:52 +0530, Mayank Rungta wrote: >> Added a check for the radeon ring buffer write index in r600.c which >> reads 0x on resume. This results in an Oops during >> radeon_ring_write. Masking the value averts this. >> >> This problem is not seen to be fixed in 3.0 r600.c as well. >> >> Detailed analysis of the problem can be found at - >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ >> >> --- >> >> BUG: unable to handle kernel paging request at fa501ffc - Oops at >> r600_cp_start+0x48/0x380 in r600_cp_resume+0x345/0x580 [radeon] >> >> drivers/gpu/drm/radeon/r600.c >> >> >> >> --- linux-2.6.38/drivers/gpu/drm/radeon/r600.c.orig 2011-08-05 >> 15:39:40.824612700 +0530 >> +++ linux-2.6.38/drivers/gpu/drm/radeon/r600.c 2011-08-08 >> 05:29:21.744417857 +0530 >> @@ -2218,6 +2218,8 @@ int r600_cp_resume(struct radeon_device >> >> rdev->cp.rptr = RREG32(CP_RB_RPTR); >> rdev->cp.wptr = RREG32(CP_RB_WPTR); >> + /* protect against crazy HW on resume */ >> + rdev->cp.wptr &= rdev->cp.ptr_mask; > > The indentation of the lines you're adding doesn't match the surrounding > lines. > > > Although the same workaround is already in r100.c, I wonder if we > shouldn't rather try and eliminate all reads from the CP_RB_WPTR > register, at least other than for debugging purposes. Alex, what do you > think? Either this or reset the registers to 0 or a saved value on resume rather than reading from them. > > Otherwise, this should probably be added in evergreen.c as well. > Yes, and ni.c as well. Alex > >> Developer's Certificate of Origin 1.1 >> >> [...] > > No need to include all this text, just the *-by: tags are enough. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Debian, X and DRI developer > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/gma500: use common functions for mmap offset creation
Signed-off-by: Rob Clark
Signed-off-by: Alan Cox
---
drivers/staging/gma500/psb_gem.c | 63 +
1 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/gma500/psb_gem.c b/drivers/staging/gma500/psb_gem.c
index 76ff7ba..3a397f5 100644
--- a/drivers/staging/gma500/psb_gem.c
+++ b/drivers/staging/gma500/psb_gem.c
@@ -42,13 +42,7 @@ 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;
- struct drm_map_list *list = &obj->map_list;
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
+ drm_gem_free_mmap_offset(obj);
}
drm_gem_object_release(obj);
}
@@ -60,59 +54,6 @@ int psb_gem_get_aperture(struct drm_device *dev, void *data,
}
/**
- * psb_gem_create_mmap_offset - invent an mmap offset
- * @obj: our object
- *
- * This is basically doing by hand a pile of ugly crap which should
- * be done automatically by the GEM library code but isn't
- */
-static int psb_gem_create_mmap_offset(struct drm_gem_object *obj)
-{
- struct drm_device *dev = obj->dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret;
-
- list = &obj->map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (list->map == NULL)
- return -ENOMEM;
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->size;
- map->handle =obj;
-
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->size / PAGE_SIZE, 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
- ret = -ENOSPC;
- goto free_it;
- }
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->size / PAGE_SIZE, 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto free_it;
- }
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto free_mm;
- }
- return 0;
-
-free_mm:
- drm_mm_put_block(list->file_offset_node);
-free_it:
- kfree(list->map);
- list->map = NULL;
- return ret;
-}
-
-/**
* psb_gem_dumb_map_gtt- buffer mapping for dumb interface
* @file: our drm client file
* @dev: drm device
@@ -142,7 +83,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct
drm_device *dev,
/* Make it mmapable */
if (!obj->map_list.map) {
- ret = psb_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/i915: use common functions for mmap offset creation
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_gem.c | 85 +--
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5c0d124..5676eaa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1265,74 +1265,6 @@ out:
}
/**
- * i915_gem_create_mmap_offset - create a fake mmap offset for an object
- * @obj: obj in question
- *
- * GEM memory mapping works by handing back to userspace a fake mmap offset
- * it can use in a subsequent mmap(2) call. The DRM core code then looks
- * up the object based on the offset and sets up the various memory mapping
- * structures.
- *
- * This routine allocates and attaches a fake offset for @obj.
- */
-static int
-i915_gem_create_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret = 0;
-
- /* Set the object up for mmap'ing */
- list = &obj->base.map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (!list->map)
- return -ENOMEM;
-
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->base.size;
- map->handle = obj;
-
- /* Get a DRM GEM mmap offset allocated... */
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->base.size / PAGE_SIZE,
- 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n",
- obj->base.name);
- ret = -ENOSPC;
- goto out_free_list;
- }
-
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->base.size / PAGE_SIZE,
- 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto out_free_list;
- }
-
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto out_free_mm;
- }
-
- return 0;
-
-out_free_mm:
- drm_mm_put_block(list->file_offset_node);
-out_free_list:
- kfree(list->map);
- list->map = NULL;
-
- return ret;
-}
-
-/**
* i915_gem_release_mmap - remove physical page mappings
* @obj: obj in question
*
@@ -1360,19 +1292,6 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
obj->fault_mappable = false;
}
-static void
-i915_gem_free_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list = &obj->base.map_list;
-
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
-}
-
static uint32_t
i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
{
@@ -1493,7 +1412,7 @@ i915_gem_mmap_gtt(struct drm_file *file,
}
if (!obj->base.map_list.map) {
- ret = i915_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(&obj->base);
if (ret)
goto out;
}
@@ -3614,7 +3533,7 @@ static void i915_gem_free_object_tail(struct
drm_i915_gem_object *obj)
trace_i915_gem_object_destroy(obj);
if (obj->base.map_list.map)
- i915_gem_free_mmap_offset(obj);
+ drm_gem_free_mmap_offset(&obj->base);
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(dev_priv, obj->base.size);
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/gem: add functions for mmap offset creation
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 88 +
include/drm/drmP.h|3 ++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 2b997d2..809358a 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -273,6 +273,94 @@ again:
}
EXPORT_SYMBOL(drm_gem_handle_create);
+
+/**
+ * drm_gem_free_mmap_offset - release a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ */
+void
+drm_gem_free_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list = &obj->map_list;
+
+ drm_ht_remove_item(&mm->offset_hash, &list->hash);
+ drm_mm_put_block(list->file_offset_node);
+ kfree(list->map);
+ list->map = NULL;
+}
+EXPORT_SYMBOL(drm_gem_free_mmap_offset);
+
+/**
+ * drm_gem_create_mmap_offset - create a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * GEM memory mapping works by handing back to userspace a fake mmap offset
+ * it can use in a subsequent mmap(2) call. The DRM core code then looks
+ * up the object based on the offset and sets up the various memory mapping
+ * structures.
+ *
+ * This routine allocates and attaches a fake offset for @obj.
+ */
+int
+drm_gem_create_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list;
+ struct drm_local_map *map;
+ int ret = 0;
+
+ /* Set the object up for mmap'ing */
+ list = &obj->map_list;
+ list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
+ if (!list->map)
+ return -ENOMEM;
+
+ map = list->map;
+ map->type = _DRM_GEM;
+ map->size = obj->size;
+ map->handle = obj;
+
+ /* Get a DRM GEM mmap offset allocated... */
+ list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
+ obj->size / PAGE_SIZE, 0, 0);
+
+ if (!list->file_offset_node) {
+ DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
+ ret = -ENOSPC;
+ goto out_free_list;
+ }
+
+ list->file_offset_node = drm_mm_get_block(list->file_offset_node,
+ obj->size / PAGE_SIZE, 0);
+ if (!list->file_offset_node) {
+ ret = -ENOMEM;
+ goto out_free_list;
+ }
+
+ list->hash.key = list->file_offset_node->start;
+ ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
+ if (ret) {
+ DRM_ERROR("failed to add to map hash\n");
+ goto out_free_mm;
+ }
+
+ return 0;
+
+out_free_mm:
+ drm_mm_put_block(list->file_offset_node);
+out_free_list:
+ kfree(list->map);
+ list->map = NULL;
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_create_mmap_offset);
+
/** Returns a reference to the object named by the handle. */
struct drm_gem_object *
drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 111e98f..ec156c3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1622,6 +1622,9 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
}
+void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
+int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
+
struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
struct drm_file *filp,
u32 handle);
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/gma500: use common functions for mmap offset creation
On Thu, 4 Aug 2011 12:07:40 -0500 Rob Clark wrote: I'm happy with these but it will need contributing with your Signed-off-by: to progress upstream of course ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 --- Comment #12 from Klaus Kusche 2011-08-10 03:45:07 PDT --- (In reply to comment #11) > Great. Would this be a satisfactory resolution for this report? Well, as it seems to be impossible (at least for my combination of LVDS and DP) to have two (or even more) outputs in sync at the same time, and as there is no way for the software to find out automagically which output to sync, syncing to the primary output and depending on the user to set the output he wants to have in sync using xrandr is the best we can get. So: Yes. But your patch was radeon-only. I think * all platforms should behave the same, * and if they do, this behaviour should be documented somewhere. -- 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 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 --- Comment #12 from Klaus Kusche 2011-08-10 03:45:07 PDT --- (In reply to comment #11) > Great. Would this be a satisfactory resolution for this report? Well, as it seems to be impossible (at least for my combination of LVDS and DP) to have two (or even more) outputs in sync at the same time, and as there is no way for the software to find out automagically which output to sync, syncing to the primary output and depending on the user to set the output he wants to have in sync using xrandr is the best we can get. So: Yes. But your patch was radeon-only. I think * all platforms should behave the same, * and if they do, this behaviour should be documented somewhere. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39902] R600g Evergreen: GPU lockup after launch of Bioshock
https://bugs.freedesktop.org/show_bug.cgi?id=39902 --- Comment #4 from Sven Arvidsson 2011-08-10 03:27:07 PDT --- Bioshock has been working for me in the past (on Evergreen), so this could be a regression. Specifically I was using git 2fe39b46e73aea37152777fe11d489e0b1bc3f92 and Wine 1.3.22. I will try it again when I have more time. Keep in mind that to get the game running you need to revert commit 6a35cbb656e0f8a2479a63eadefb1ab85f42d490 to work around bug 38501. Also, I think developers prefer if you file new and separate bug reports for issues with different games. It could be that the GPU hangs you describe all come from the same bug, but it could also be different problems all showing up in the same way. -- 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 39902] R600g Evergreen: GPU lockup after launch of Bioshock
https://bugs.freedesktop.org/show_bug.cgi?id=39902 --- Comment #4 from Sven Arvidsson 2011-08-10 03:27:07 PDT --- Bioshock has been working for me in the past (on Evergreen), so this could be a regression. Specifically I was using git 2fe39b46e73aea37152777fe11d489e0b1bc3f92 and Wine 1.3.22. I will try it again when I have more time. Keep in mind that to get the game running you need to revert commit 6a35cbb656e0f8a2479a63eadefb1ab85f42d490 to work around bug 38501. Also, I think developers prefer if you file new and separate bug reports for issues with different games. It could be that the GPU hangs you describe all come from the same bug, but it could also be different problems all showing up in the same way. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 --- Comment #11 from Michel Dänzer 2011-08-10 02:50:46 PDT --- Great. Would this be a satisfactory resolution for this report? -- 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 39696] dual head: different vert refresh freq, applications sync to the wrong one
https://bugs.freedesktop.org/show_bug.cgi?id=39696 --- Comment #11 from Michel D?nzer 2011-08-10 02:50:46 PDT --- Great. Would this be a satisfactory resolution for this report? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
> Sorry, I won't submit a patch. If there is a need to find/fix/cleanup > obvious things after company's developers, I have better things to do, > and a todo item to re-evaluate hardware for my next project. You seem confused. If you have a support contract of some form with a Linux supplier or Intel please contact your support. This mailing list isn't for support services. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2.6.38-10-generic] device driver: fix oops in radeon driver due to incorrect value from hardware
On Die, 2011-08-09 at 23:52 +0530, Mayank Rungta wrote: > Added a check for the radeon ring buffer write index in r600.c which > reads 0x on resume. This results in an Oops during > radeon_ring_write. Masking the value averts this. > > This problem is not seen to be fixed in 3.0 r600.c as well. > > Detailed analysis of the problem can be found at - > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/ > > --- > > BUG: unable to handle kernel paging request at fa501ffc - Oops at > r600_cp_start+0x48/0x380 in r600_cp_resume+0x345/0x580 [radeon] > > drivers/gpu/drm/radeon/r600.c > > > > --- linux-2.6.38/drivers/gpu/drm/radeon/r600.c.orig2011-08-05 > 15:39:40.824612700 +0530 > +++ linux-2.6.38/drivers/gpu/drm/radeon/r600.c2011-08-08 > 05:29:21.744417857 +0530 > @@ -2218,6 +2218,8 @@ int r600_cp_resume(struct radeon_device > > rdev->cp.rptr = RREG32(CP_RB_RPTR); > rdev->cp.wptr = RREG32(CP_RB_WPTR); > +/* protect against crazy HW on resume */ > +rdev->cp.wptr &= rdev->cp.ptr_mask; The indentation of the lines you're adding doesn't match the surrounding lines. Although the same workaround is already in r100.c, I wonder if we shouldn't rather try and eliminate all reads from the CP_RB_WPTR register, at least other than for debugging purposes. Alex, what do you think? Otherwise, this should probably be added in evergreen.c as well. > Developer's Certificate of Origin 1.1 > > [...] No need to include all this text, just the *-by: tags are enough. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Tue, Aug 09, 2011 at 10:43:08AM -0700, Ray Lee wrote: > On Tue, Aug 9, 2011 at 10:40 AM, Kirill Smelkov wrote: > >> If you like, submit a patch. You may now be more up-to-date on those > >> particular code paths than most of the intel-gfx developers. > > > > Ray, I'd agree with you if the topic was about cleanups. > > At this point it is about cleanups unless Keith's patch upthread does > not work for you. Does it or not? I've already wrote two weeks ago it does, but if this needs to be restated one more time here it is: Keith's patch fixes the problem in a sense that X now starts and seemingly works (thanks), but several issues remain to be there imho. I've got the message, if it's ok for intel-gfx to leave them as is - it's ok for me. Peace, Kirill ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39902] R600g Evergreen: GPU lockup after launch of Bioshock
https://bugs.freedesktop.org/show_bug.cgi?id=39902 Michel Dänzer changed: What|Removed |Added Attachment #50086|application/octet-stream|text/plain mime type|| -- 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 39902] R600g Evergreen: GPU lockup after launch of Bioshock
https://bugs.freedesktop.org/show_bug.cgi?id=39902 Michel D?nzer changed: What|Removed |Added Attachment #50086|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39202] FPS - KDE desktop effects with 3.0 rc6 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=39202 --- Comment #10 from Michel Dänzer 2011-08-10 00:49:08 PDT --- Other than bisecting the kernel, I don't have any more good ideas for figuring out what caused this. -- 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 39202] FPS - KDE desktop effects with 3.0 rc6 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=39202 --- Comment #10 from Michel D?nzer 2011-08-10 00:49:08 PDT --- Other than bisecting the kernel, I don't have any more good ideas for figuring out what caused this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
