Re: [PATCH] savage: remove unecessary if statement
* Greg Dietsche : > the code always returns ret regardless, so if(ret) check is unecessary. /unecessary/unnecessary/ > > Signed-off-by: Greg Dietsche Reviewed-by: Nicolas Kaiser Best regards, Nicolas Kaiser > --- > drivers/gpu/drm/savage/savage_bci.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/savage/savage_bci.c > b/drivers/gpu/drm/savage/savage_bci.c > index bf5f83e..cb1ee4e 100644 > --- a/drivers/gpu/drm/savage/savage_bci.c > +++ b/drivers/gpu/drm/savage/savage_bci.c > @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) > ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, >_DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, >&dev_priv->aperture); > - if (ret) > - return ret; > - > return ret; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 --- Comment #14 from Michal Suchanek 2011-06-06 07:46:16 PDT --- Yes, this has been fixed in 7.11. A piglit test for this would be nice because it was a longstanding issue for which I did not find any test neither in piglit nor in mesa-demos. -- 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 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 Michal Suchanek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||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
[PATCH] drm/radeon/kms: fix mac g5 quirk
Apple uses the same subsystem pci ids for lots of
hardware much of which is wired up differently. In
this case, the G5 imac and the G5 tower.
Only apply the quirk configuration to G5 towers.
Reported-by: Joachim Henke
Signed-off-by: Alex Deucher
Cc: Joachim Henke
Cc: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 5b991f7..19b10cf 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1548,9 +1548,8 @@ bool radeon_get_legacy_connector_info_from_table(struct
drm_device *dev)
(rdev->pdev->subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev->mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev->pdev->device == 0x4150) &&
- (rdev->pdev->subsystem_vendor == 0x1002) &&
- (rdev->pdev->subsystem_device == 0x4150)) {
+ } else if (of_machine_is_compatible("PowerMac7,2") ||
+ of_machine_is_compatible("PowerMac7,3")) {
/* Mac G5 9600 */
rdev->mode_info.connector_table = CT_MAC_G5_9600;
} else
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
* Nick Bowler -- Monday 06 June 2011:
> After upgrading to 3.0-rc2, my second display is no longer working
> correctly on a desktop with an Intel G45 graphics chip.
[...]
> What I do know is that the problem was originally introduced by
> 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
That's apparently the bug that I've submitted a patch for on 2011/5/31:
https://lkml.org/lkml/2011/5/31/393
I assume/hope it's still in someone's queue.
m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Semantics of the 'dumb' interface
> I think the intel driver forces a reset to the system scanout on release. I've > actually never found a test to indicate it was completely necessary on > other GPUs I need to force this on the GMA500 because we want some kind of sane scanout left and the nice guys at Dell decided the Mini 10 didn't actually need a sysrq key so sysrq-V isn't going to help. On the bright side GEM and the dumb kms stuff now seem to work with a new device id added to libkms and a daft bug in libkms dumb.c fixed (if you report a 32bit fb type, you probably want to allocate a 32bit fb not a 16bit one) Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Regression: Borked display on second output with Intel G45 in 3.0-rc2
After upgrading to 3.0-rc2, my second display is no longer working
correctly on a desktop with an Intel G45 graphics chip. The system has
two displays, one connected by HDMI and the other by VGA.
Both displays work fine in the console; the troubles begin after
starting X. It *looks* as if one of the displays is still scanning out
from the old framebuffer: what I see on the VGA monitor after starting X
is a black screen with a console cursor at the top -- this is just like
an empty VT except that the cursor is not blinking. If I switch to VT 1
and then back to X, the display contains all the bootup text that was on
VT 1. In any case, the mouse cursor works properly on the display.
There are no unusual messages in dmesg or the Xorg log in any case.
If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1
--same-as HDMI1 && xrandr --output VGA1 --right-of VGA1) , it's possible
to get both displays showing the right thing. But then if I switch back
to the console, I end up with one display showing the console text and
the other is still showing my X session! (In this instance, the VGA was
working and the HDMI was showing the wrong thing).
This is a regression from 2.6.39, but that's not the whole story: this
problem appears to have been introduced very briefly late in the 2.6.39
-rc cycle and subsequently fixed on mainline. It then reappeared during
the 3.0 merge window. Unfortunately, this fact seems to make it
impossible to bisect to a specific commit.
What I do know is that the problem was originally introduced by
49183b2818de ("drm/i915: Only enable the plane after setting the fb
base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
"drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
Unfortunately, I cannot be more specific than that because it appears
that the entire drm side of that merge consists of 'bad' commits and git
bisect gets very confused.
Let me know if you need any more info,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On 2011-06-06 19:20 +0200, Melchior FRANZ wrote:
> * Nick Bowler -- Monday 06 June 2011:
> > After upgrading to 3.0-rc2, my second display is no longer working
> > correctly on a desktop with an Intel G45 graphics chip.
> [...]
> > What I do know is that the problem was originally introduced by
> > 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> > base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> > "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> > The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> > of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
>
> That's apparently the bug that I've submitted a patch for on 2011/5/31:
> https://lkml.org/lkml/2011/5/31/393
> I assume/hope it's still in someone's queue.
Yup, that fixes it right up, thanks.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit
Since printk_ratelimit() shouldn't be used anymore (see comment in include/linux/printk.h), replace it with printk_ratelimited. Signed-off-by: Christian Dietrich --- drivers/gpu/drm/drm_ioc32.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c index d61d185..4a058c7 100644 --- a/drivers/gpu/drm/drm_ioc32.c +++ b/drivers/gpu/drm/drm_ioc32.c @@ -28,6 +28,7 @@ * IN THE SOFTWARE. */ #include +#include #include "drmP.h" #include "drm_core.h" @@ -253,10 +254,10 @@ static int compat_drm_addmap(struct file *file, unsigned int cmd, return -EFAULT; m32.handle = (unsigned long)handle; - if (m32.handle != (unsigned long)handle && printk_ratelimit()) - printk(KERN_ERR "compat_drm_addmap truncated handle" - " %p for type %d offset %x\n", - handle, m32.type, m32.offset); + if (m32.handle != (unsigned long)handle) + printk_ratelimited(KERN_ERR "compat_drm_addmap truncated handle" + " %p for type %d offset %x\n", + handle, m32.type, m32.offset); if (copy_to_user(argp, &m32, sizeof(m32))) return -EFAULT; -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] Use printk_ratelimited instead of printk_ratelimit
Hi, since printk_ratelimit() shouldn't be used anymore, I replaced it at several points, where it was possible with printk_ratelimited(FMT,...). This shouldn't change the behaviour in most cases, except that the printk will use an local ratelimit instead of an global one shared with all other printk_ratelimit calls. I just must made patches for a few places where it is used. If you think that it is worth converting all printk_ratelimits, i will send more patches. The changes where done against v3.0-rc1-106-g4f1ba49. greetz chris Christian Dietrich (8): powerpc/rtas-rtc: remove sideeffects of printk_ratelimit drivers/octeon: use printk_ratelimited instead of printk_ratelimit scsi/sg: use printk_ratelimited instead of printk_ratelimit md/raid: use printk_ratelimited instead of printk_ratelimit drivers/char/rtc: use printk_ratelimited instead of printk_ratelimit drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit arch/powerpc: use printk_ratelimited instead of printk_ratelimit arch/x86: use printk_ratelimited instead of printk_ratelimit arch/powerpc/kernel/rtas-rtc.c | 29 +-- arch/powerpc/kernel/signal_32.c | 57 +-- arch/powerpc/kernel/signal_64.c | 17 + arch/powerpc/kernel/traps.c | 22 +-- arch/powerpc/mm/fault.c | 10 +++--- arch/powerpc/sysdev/mpic.c | 11 +++--- arch/x86/kernel/hpet.c |6 ++-- arch/x86/kernel/irq.c |9 ++--- arch/x86/kvm/i8259.c|7 ++-- arch/x86/lguest/boot.c |6 ++-- drivers/char/rtc.c |7 ++-- drivers/gpu/drm/drm_ioc32.c |9 +++-- drivers/md/raid1.c | 22 ++- drivers/md/raid10.c | 22 ++- drivers/md/raid5.c | 39 ++--- drivers/scsi/sg.c | 18 + drivers/staging/octeon/ethernet-mdio.c | 27 +++--- drivers/staging/octeon/ethernet-rgmii.c | 33 +- drivers/staging/octeon/ethernet-rx.c| 24 +++-- drivers/staging/octeon/ethernet-sgmii.c | 14 --- drivers/staging/octeon/ethernet-tx.c| 11 +++--- drivers/staging/octeon/ethernet-util.h |4 -- drivers/staging/octeon/ethernet-xaui.c | 22 ++- 23 files changed, 221 insertions(+), 205 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] savage: remove unecessary if statement
the code always returns ret regardless, so if(ret) check is unecessary. Signed-off-by: Greg Dietsche --- drivers/gpu/drm/savage/savage_bci.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/savage/savage_bci.c b/drivers/gpu/drm/savage/savage_bci.c index bf5f83e..cb1ee4e 100644 --- a/drivers/gpu/drm/savage/savage_bci.c +++ b/drivers/gpu/drm/savage/savage_bci.c @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, &dev_priv->aperture); - if (ret) - return ret; - return ret; } -- 1.7.2.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On Mon, 6 Jun 2011 19:20:06 +0200, Melchior FRANZ wrote: > That's apparently the bug that I've submitted a patch for on 2011/5/31: > https://lkml.org/lkml/2011/5/31/393 > I assume/hope it's still in someone's queue. Yeah, we "shouldn't" need to call intel_enable_plane from i9xx_crtc_mode_set as it is called immediately afterwards from i9xx_crtc_enable. In any case, there's a bogus call in ironlake_crtc_mode_set which clearly belongs in i9xx_crtc_mode_set: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 81a9059..aa43e7b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4687,6 +4687,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); + intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); @@ -5217,8 +5218,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); - if (!HAS_PCH_SPLIT(dev)) - intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); We need to figure out why this call (in i9xx_crtc_mode_set) is required, but that will require finding hardware that reproduces the bug and fixing it there. -- keith.pack...@intel.com pgp0Opa75FnW7.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #9 from Pierre-Eric Pelloux-Prayer 2011-06-06 13:28:16 PDT --- Created an attachment (id=47621) View: https://bugs.freedesktop.org/attachment.cgi?id=47621 Review: https://bugs.freedesktop.org/review?bug=37028&attachment=47621 proposed patch Could you please try this patch ? It should fix the issue. -- 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
Re: drivers/drm/i915 maintenance process
On Sat, 04 Jun 2011 23:05:23 -0700 "Keith Packard" wrote: > 1) drm-intel-next > > This contains work destined for the 'next' release, it may include > new functionality and performance enhancements. It may also cause > regressions on some hardware. The tip of this tree will be sent > to Dave Airlie for inclusion in the kernel during the next > merge window. I've already sent all of what is on this branch > to him for 3.0 > > This tree should be tested during the development process to try and > catch bugs and regressions before they are merged. The most critical > time for testing this is just *before* the release of the current RC > kernel version as that is when it should have most of the code > planned for the *next* release. > > 2) drm-intel-fixes > > This contains bug fixes after the merge window has closed. I will > fast-forwarded to each RC when possible so that we test the fully > integrated kernel for regressions. > > This tree should be tested during the stabilization process after RC1 > comes out as patches are applied. Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part? In PCI-land, this means re-basing my -next tree periodically before the merge window opens (though not right before the merge window unless something unexpected happens, like a patch needing to be dropped; in that case I'll delay the merge window push a bit to allow for more testing). Downstream PCI developers requested this since it makes feature development much easier (you get all the bug fixes destined for Linus while working on a new feature for the next window), and as a downstream gfx developer I'd like to see this on the Intel side as well, unless other developers have big objections... 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
[Bug 38010] New: DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 Summary: DVI output not working with radeon on RV610 Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: darkbas...@gmail.com Created an attachment (id=47622) --> (https://bugs.freedesktop.org/attachment.cgi?id=47622) dmesg Hi, I have an RV610 card attached to an LG 22LH2000. The LG 22LH2000 has a 1366x768 native resolution and does have VGA and HDMI but not DVI. The Radeon HD2400 does have VGA and DVI but not HDMI, so I'm using a DVI-HDMI converter. When I use the VGA output everything works fine, but I don't get a 1:1 pixel mapping because I have to set a 1360x768 or 1368x768 resolution and the monitor is not smart enough when using vga. Instead when I attach the monitor to my laptop's Intel GMA45 HDMI output I can get a 1:1 pixel mapping even using a 1360x768 resolution. Unfortunately when using the HD2400 DVI output the monitor does not show anything, at least after loading the radeon module. In fact when loading the bios or starting grub the DVI output works flawlessly. nomodeset does not help. I even tried setting another resolution with xrandr (it automatically set 1920x1080i, but I tried 1360x768, 1280x800, 1024x768 and 800x600 and it still does not work). Distro is Debian Unstable amd64 with kernel 2.6.39 and xorg-edgers ppa. It's the only monitor I will be able to use for a couple of months, it's critical for me to get it working. Thank you -- 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 --- Comment #1 from Alex Deucher 2011-06-06 14:13:06 PDT --- Does booting with radeon.audio=0 on the kernel command line in grub help? -- 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 --- Comment #2 from darkbasic 2011-06-06 14:13:48 PDT --- Created an attachment (id=47623) --> (https://bugs.freedesktop.org/attachment.cgi?id=47623) Xorg.0.log -- 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 --- Comment #3 from darkbasic 2011-06-06 14:18:41 PDT --- > Does booting with radeon.audio=0 on the kernel command line in grub help? OMG you had been faster than light, and it worked! Consider this card does not even have an HDMI output! Thank you very much P.S. Should I close 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
[PATCH] drm/radeon/kms: disable hdmi audio by default
The current RE'd code causes blank screens and display problems on a lot of systems. So disable it by default for now. It can still be enabled by setting the audio parameter to 1. E.g.: radeon.audio=1 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38010 https://bugs.freedesktop.org/show_bug.cgi?id=27731 https://bugs.freedesktop.org/show_bug.cgi?id=35970 https://bugs.freedesktop.org/show_bug.cgi?id=26195 and many other reported problems. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 1d33060..73dfbe8 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -113,7 +113,7 @@ int radeon_benchmarking = 0; int radeon_testing = 0; int radeon_connector_table = 0; int radeon_tv = 1; -int radeon_audio = 1; +int radeon_audio = 0; int radeon_disp_priority = 0; int radeon_hw_i2c = 0; int radeon_pcie_gen2 = 0; @@ -151,7 +151,7 @@ module_param_named(connector_table, radeon_connector_table, int, 0444); MODULE_PARM_DESC(tv, "TV enable (0 = disable)"); module_param_named(tv, radeon_tv, int, 0444); -MODULE_PARM_DESC(audio, "Audio enable (0 = disable)"); +MODULE_PARM_DESC(audio, "Audio enable (1 = enable)"); module_param_named(audio, radeon_audio, int, 0444); MODULE_PARM_DESC(disp_priority, "Display Priority (0 = auto, 1 = normal, 2 = high)"); -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Flat address space with gGTT / ppGTT
Hello all, I saw at some point that per-process GTT (ppGTT) may be (or is already) implemented to handle paging. Right now, I am investigating some flat space addressing (ab)using surface states. The idea is to create a surface state (raw buffer only, this is GPGPU stuff) as big enough to cover the entire address space such that I will only manipulate offsets as pointers in this surface instead of dealing with both offsets and surface IDs (in other words, segmented address space). My concern is relative to the way bo buffers are mapped. Basically, I must be sure that _all_ of them are either mapped using ppGTT or GTT. Otherwise, this will also bring another form of segmentation. If ppGTT is implemented or will be implemented, will there be anyway to know how a bo is mapped? Cheers, Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes wrote: > Can you keep drm-intel-next fairly up to date with respect to the fixes > branch? I.e. keep it a superset of drm-intel-fixes for the most part? Yes, I wanted to do that now, but -fixes is not a fast-forward from -next and I thought I shouldn't be doing rebases. > In PCI-land, this means re-basing my -next tree periodically before the > merge window opens (though not right before the merge window unless > something unexpected happens, like a patch needing to be dropped; in > that case I'll delay the merge window push a bit to allow for more > testing). If a rebase around -RC1 is reasonable, then I'll do that now and move changes over to that. -- keith.pack...@intel.com pgpy4bzryrDsu.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 06 Jun 2011 16:24:46 -0700 Keith Packard wrote: > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > wrote: > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > -next and I thought I shouldn't be doing rebases. You shouldn't if your downstream is using git trees and you're pulling from them, but it depends on your downstream. In my particular case, I'm ok with rebases if it means I get fixes. :) -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 16:30:25 -0700 Jesse Barnes wrote: > On Mon, 06 Jun 2011 16:24:46 -0700 > Keith Packard wrote: > > > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > > wrote: > > > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > > -next and I thought I shouldn't be doing rebases. > > You shouldn't if your downstream is using git trees and you're pulling > from them, but it depends on your downstream. In my particular case, > I'm ok with rebases if it means I get fixes. :) Oh and the other big reason is testing. rebase generally voids previous testing since you have new bits, so Linus really hates to see a rebase just before a pull request, and I think Dave does too. But rebasing for good reason (e.g. to make your -next branch a superset of your -fixes branch) on occasion is fine. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36812] New: Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Summary: Radeon fails to load firmware Product: Drivers Version: 2.5 Kernel Version: 3.0-rc2 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: cl...@jhcloos.com Regression: Yes This used to work, but I had been booting with radeon.modset=0 for a few weeks, so I do not know when it broke. With 3.0-rc2 (compiled from git master) I get (note this first two lines): [ 61.920296] r600_cp: Failed to load firmware "radeon/R600_rlc.bin" [ 61.920370] [drm:r600_startup] *ERROR* Failed to load firmware! [ 61.920442] radeon :01:05.0: disabling GPU acceleration [ 61.921543] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921615] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921697] [drm] Enabling audio support [ 61.921949] [drm] Radeon Display Connectors [ 61.922030] [drm] Connector 0: [ 61.922100] [drm] VGA [ 61.922170] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 61.922287] [drm] Encoders: [ 61.922357] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 61.922427] [drm] Connector 1: [ 61.922496] [drm] HDMI-A [ 61.922565] [drm] HPD1 [ 61.922634] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 61.922751] [drm] Encoders: [ 61.922820] [drm] DFP1: INTERNAL_KLDSCP_LVTMA [ 61.942202] [drm] radeon: power management initialized [ 61.958278] No connectors reported connected with modes [ 61.958351] [drm] Cannot find any crtc or sizes - going 1024x768 [ 61.965068] [drm] fb mappable at 0xD004 [ 61.965137] [drm] vram apper at 0xD000 [ 61.965206] [drm] size 3145728 [ 61.965274] [drm] fb depth is 24 [ 61.965342] [drm]pitch is 4096 [ 61.965460] fbcon: radeondrmfb (fb0) is primary device [ 61.979478] Console: switching to colour frame buffer device 128x48 [ 61.985634] fb0: radeondrmfb frame buffer device [ 61.985696] drm: registered panic notifier [ 61.985755] [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 and yet: :; ls -sl /lib/firmware/radeon/R600_rlc.bin 4 -rw-r--r-- 1 root root 3072 Jun 6 12:15 /lib/firmware/radeon/R600_rlc.bin (from a fresh update from http://people.freedesktop.org/~agd5f/radeon_ucode/ .) -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Andrew Morton changed: What|Removed |Added CC||a...@linux-foundation.org --- Comment #1 from Andrew Morton 2011-06-06 23:59:54 --- If it was Ok a couple of weeks ago then I assume that this is a psot-2.6.39 regression? -- 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 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #10 from Maggioni Marcello 2011-06-06 17:10:42 PDT --- Hi, after applying the patch the problem seems to be still there ... my card is a Radeon 5850. The lights have a white halo surrounding them flickering. Also , the white area at the bottom of the screen problem is still present in fullscreen mode. It was just scene dependent and I thought it was gone because I checked in a scene in which it wasn't present. -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 --- Comment #2 from James Cloos 2011-06-07 00:47:29 --- Longer than that. The box is usually headless; when I first got it the missing firmware prevented booting, so I added radeon.modeset=0 to the grub config and manually changed that for those occasions when I moved the box to the TV. Today I changed the grub config in honour of the upcoming 3.0. ☺ (That it boots now even though it fails to load that firmware is a nice progression.) My best guess, based on the timestamps of my .config archive, is that I last connected it to the TV during the 38-rc1 timeframe. -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 --- Comment #3 from James Cloos 2011-06-07 00:53:41 --- I forgot to add: I don’t see from git-grep(1)ing the tree where or how the kernel knows to find firmware in /lib/firmware. All I can see is /lib/firmware as the target to make firmware_install and several comments specifying /lib/firmware as the typical location. What am I missing? -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher 2011-06-07 02:17:36 --- Most likely you did not include the firmware in your initrd. -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 James Cloos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from James Cloos 2011-06-07 04:01:31 --- Ah. OK. The driver tries to load the firmware before / is mounted, then? As I do not use initrd there the answer seems to be: -CONFIG_EXTRA_FIRMWARE="" +CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin" +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" to the .config. Closing as invalid. Will reopen if the above .config change doesn’t fix it. (Last time I must have manually done what EXTRA_FIRMWARE does. I lost that clone in the meantime, though, so that is only a guess. (It was a clone of my local, pristine clone. And the .configs were backed up in their own git repo. So that loss didn’t seem like much of a nuisance. But I obviously forgot about this issue in the meantime. ☹) -- 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
[git pull] drm fixes
Hi Linus, this is just the Intel and nouveau fixes, this alongside the radeon fixes pull that is outstanding, it has one serious intel regression fix for 945 machines that got broken in the ivybridge support, along with a few fixes from nouveau. Dave. The following changes since commit 59c5f46fbe01a00eedf54a23789634438bb80603: Linux 3.0-rc2 (2011-06-06 18:06:33 +0900) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Ben Skeggs (5): drm/nvc0: recognise 0xdX chipsets as NV_C0 drm/nouveau: don't create accel engine objects when noaccel=1 drm/nouveau: fix vram page mapping when crossing page table boundaries drm/nouveau: fix leak of gart mm node drm/nv40: fall back to paged dma object for the moment Chris Wilson (5): drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/ drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0 drm/i915/crt: Explicitly return false if connected to a digital monitor drm/i915: Remove unused enum "chip_family" drm/i915: Share the common force-audio property between connectors Dan Carpenter (1): drm/i915: fix if statement in ivybridge irq handler Daniel Vetter (2): drm/i915: Only print out the actual number of fences for i915_error_state drm/915: fix relaxed tiling on gen2: tile height Dave Airlie (2): Merge remote branch 'keithp/drm-intel-fixes' of /ssd/git/drm-next into drm-fixes Merge remote branch 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next into drm-fixes Francisco Jerez (1): drm/nv17-nv40: Fix modesetting failure when pitch == 4096px (fdo bug 35901). Hans de Goede (1): drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007 Jason Stubbs (1): drm/i915: fix regression after clock gating init split Nicolas Kaiser (1): drm: i915: correct return status in intel_hdmi_mode_valid() drivers/gpu/drm/i915/i915_debugfs.c |2 +- drivers/gpu/drm/i915/i915_drv.h |8 +-- drivers/gpu/drm/i915/i915_gem.c | 26 drivers/gpu/drm/i915/i915_irq.c |2 +- drivers/gpu/drm/i915/intel_crt.c|4 + drivers/gpu/drm/i915/intel_display.c| 89 ++-- drivers/gpu/drm/i915/intel_dp.c | 15 + drivers/gpu/drm/i915/intel_drv.h|1 + drivers/gpu/drm/i915/intel_hdmi.c | 16 + drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_modes.c | 30 drivers/gpu/drm/i915/intel_sdvo.c | 14 +--- drivers/gpu/drm/nouveau/nouveau_hw.c|2 + drivers/gpu/drm/nouveau/nouveau_mem.c |4 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c |2 +- drivers/gpu/drm/nouveau/nouveau_state.c | 114 --- drivers/gpu/drm/nouveau/nouveau_vm.c|1 + drivers/gpu/drm/nouveau/nv04_crtc.c |8 ++- drivers/gpu/drm/nouveau/nvreg.h |2 + 19 files changed, 161 insertions(+), 187 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38018] New: Implementation error: bad format in _mesa_pack_rgba_span
https://bugs.freedesktop.org/show_bug.cgi?id=38018 Summary: Implementation error: bad format in _mesa_pack_rgba_span Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: gm.potato...@gmail.com Created an attachment (id=47634) --> (https://bugs.freedesktop.org/attachment.cgi?id=47634) dmesg and glxinfo catenated together When running the freeware OpenGL 2.1 title Savage 2, the following two lines of text show up on the console while the game is running. The two lines repeat exactly seven times. Only one functional anomaly was observed: when trying to quit the game, only a SIGKILL could terminate the process (SIGTERM / SIGINT were not enough). Performance is fairly good and there are no observable rendering errors, so I am marking this as MINOR. The message is: Please report at bugs.freedesktop.org Mesa 7.11-devel implementation error: bad format in _mesa_pack_rgba_span dmesg and glxinfo are attached. Summary: (1) Weird intel-iommu warnings on bootup (2) Hardware: Radeon HD5970 (3) Git version of mesa: git-c2e6590 (4) libdrm, DDX and linux from git (5) Xorg server from Ubuntu 11.04, version 1.10.1; pixman 0.20.2 Non-standard radeon DDX options: Option "SwapbuffersWait" "off" Option "ColorTiling" "on" Option "EnablePageFlip" "on" Option "EXAVSync" "off" Option "DynamicPM" "on" -- 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] New: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Summary: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: h.j...@gmx.at Created an attachment (id=47642) --> (https://bugs.freedesktop.org/attachment.cgi?id=47642) Xorg.0.log I don't know where this should go (drm, mesa?), but after a while, I notice corruption of textures / pixmaps. It can be reproduced quite easily by opening a few applications, or starting another X session. In particular, I could determine the following: - Corrupted areas resemble parts of the previous visible login screen - Icons, fonts and widgets like vertical gtk progressbars get corrupted, but only their lower half - Window (emerald) decoration seem to get corrupted completely. - It's not related to color tiling. - Pageflipping is enabled. - Restarting a corrupted application fixes it temporarily, while minimizing etc. doesn't. Restarting compiz doesn't fix it either. I believe this is specific to cayman, as the issue does not occur on a thinkpad t400 with ATI Mobility Radeon HD 3400 and similar configuration. Software configuration: - linux-3.0.0-rc1 with latest fixes from drm-2.6 git applied, up to 2a9e5862a38f7195931bd51788dc9ce68b28120c. - r600g from git mesa compiled on 12:44:56 03.06.2011 - xorg-server 1.10.2 - libdrm git 21:06:43 02.06.2011 - xf86-video-ati git 21:56:58 02.06.2011 lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Device 6719 (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Device 0b00 Flags: bus master, fast devsel, latency 0, IRQ 54 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at fe62 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at fe60 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon -- Apart from this, it works great, no crashes so far! -- 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 --- Comment #1 from Harald Judt 2011-06-06 23:21:19 PDT --- Created an attachment (id=47643) --> (https://bugs.freedesktop.org/attachment.cgi?id=47643) Screenshot of a corrupted icon. As you can see, only the lower half of the icon is corrupted. -- 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 --- Comment #2 from Harald Judt 2011-06-06 23:26:48 PDT --- Created an attachment (id=47644) --> (https://bugs.freedesktop.org/attachment.cgi?id=47644) Screenshot of corrupted xfce panel plugins. Here, parts of a previous screen (gdm login screen) shine through the lower half of the plugin widgets (gtk progress bar). I guess the gdm login screen was not active on any console at this time, so these are just remnants. Reloading the panel fixes it. -- 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 --- Comment #3 from Harald Judt 2011-06-06 23:36:06 PDT --- Created an attachment (id=47645) --> (https://bugs.freedesktop.org/attachment.cgi?id=47645) Screenshot of corrupted firefox toolbar Corruption can get quite nasty after a while. The ugly pink background once was a somewhat nicer image from some firefox persona theme. There are more of those corrupted icons too for those who got a taste of them ;-) -- 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
Re: [PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
Hi David,
Somehow my Cc got lost. Maybe you missed this. Any comments?
Thanks
Sascha
On Fri, Jun 03, 2011 at 12:54:14PM +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
> ---
> drivers/gpu/drm/drm_crtc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 872747c..21058e6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1113,7 +1113,7 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> if (card_res->count_fbs >= fb_count) {
> copied = 0;
> fb_id = (uint32_t __user *)(unsigned long)card_res->fb_id_ptr;
> - list_for_each_entry(fb, &file_priv->fbs, head) {
> + list_for_each_entry(fb, &file_priv->fbs, filp_head) {
> if (put_user(fb->base.id, fb_id + copied)) {
> ret = -EFAULT;
> goto out;
> --
> 1.7.5.3
>
> --
> 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- |
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] savage: remove unecessary if statement
* Greg Dietsche : > the code always returns ret regardless, so if(ret) check is unecessary. /unecessary/unnecessary/ > > Signed-off-by: Greg Dietsche Reviewed-by: Nicolas Kaiser Best regards, Nicolas Kaiser > --- > drivers/gpu/drm/savage/savage_bci.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/savage/savage_bci.c > b/drivers/gpu/drm/savage/savage_bci.c > index bf5f83e..cb1ee4e 100644 > --- a/drivers/gpu/drm/savage/savage_bci.c > +++ b/drivers/gpu/drm/savage/savage_bci.c > @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) > ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, >_DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, >&dev_priv->aperture); > - if (ret) > - return ret; > - > return ret; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 --- Comment #14 from Michal Suchanek 2011-06-06 07:46:16 PDT --- Yes, this has been fixed in 7.11. A piglit test for this would be nice because it was a longstanding issue for which I did not find any test neither in piglit nor in mesa-demos. -- 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 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 Michal Suchanek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||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
[PATCH] drm/radeon/kms: fix mac g5 quirk
Apple uses the same subsystem pci ids for lots of
hardware much of which is wired up differently. In
this case, the G5 imac and the G5 tower.
Only apply the quirk configuration to G5 towers.
Reported-by: Joachim Henke
Signed-off-by: Alex Deucher
Cc: Joachim Henke
Cc: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 5b991f7..19b10cf 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1548,9 +1548,8 @@ bool radeon_get_legacy_connector_info_from_table(struct
drm_device *dev)
(rdev->pdev->subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev->mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev->pdev->device == 0x4150) &&
- (rdev->pdev->subsystem_vendor == 0x1002) &&
- (rdev->pdev->subsystem_device == 0x4150)) {
+ } else if (of_machine_is_compatible("PowerMac7,2") ||
+ of_machine_is_compatible("PowerMac7,3")) {
/* Mac G5 9600 */
rdev->mode_info.connector_table = CT_MAC_G5_9600;
} else
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
* Nick Bowler -- Monday 06 June 2011:
> After upgrading to 3.0-rc2, my second display is no longer working
> correctly on a desktop with an Intel G45 graphics chip.
[...]
> What I do know is that the problem was originally introduced by
> 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
That's apparently the bug that I've submitted a patch for on 2011/5/31:
https://lkml.org/lkml/2011/5/31/393
I assume/hope it's still in someone's queue.
m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Semantics of the 'dumb' interface
> I think the intel driver forces a reset to the system scanout on release. I've > actually never found a test to indicate it was completely necessary on > other GPUs I need to force this on the GMA500 because we want some kind of sane scanout left and the nice guys at Dell decided the Mini 10 didn't actually need a sysrq key so sysrq-V isn't going to help. On the bright side GEM and the dumb kms stuff now seem to work with a new device id added to libkms and a daft bug in libkms dumb.c fixed (if you report a 32bit fb type, you probably want to allocate a 32bit fb not a 16bit one) Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Regression: Borked display on second output with Intel G45 in 3.0-rc2
After upgrading to 3.0-rc2, my second display is no longer working
correctly on a desktop with an Intel G45 graphics chip. The system has
two displays, one connected by HDMI and the other by VGA.
Both displays work fine in the console; the troubles begin after
starting X. It *looks* as if one of the displays is still scanning out
from the old framebuffer: what I see on the VGA monitor after starting X
is a black screen with a console cursor at the top -- this is just like
an empty VT except that the cursor is not blinking. If I switch to VT 1
and then back to X, the display contains all the bootup text that was on
VT 1. In any case, the mouse cursor works properly on the display.
There are no unusual messages in dmesg or the Xorg log in any case.
If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1
--same-as HDMI1 && xrandr --output VGA1 --right-of VGA1) , it's possible
to get both displays showing the right thing. But then if I switch back
to the console, I end up with one display showing the console text and
the other is still showing my X session! (In this instance, the VGA was
working and the HDMI was showing the wrong thing).
This is a regression from 2.6.39, but that's not the whole story: this
problem appears to have been introduced very briefly late in the 2.6.39
-rc cycle and subsequently fixed on mainline. It then reappeared during
the 3.0 merge window. Unfortunately, this fact seems to make it
impossible to bisect to a specific commit.
What I do know is that the problem was originally introduced by
49183b2818de ("drm/i915: Only enable the plane after setting the fb
base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
"drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
Unfortunately, I cannot be more specific than that because it appears
that the entire drm side of that merge consists of 'bad' commits and git
bisect gets very confused.
Let me know if you need any more info,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On 2011-06-06 19:20 +0200, Melchior FRANZ wrote:
> * Nick Bowler -- Monday 06 June 2011:
> > After upgrading to 3.0-rc2, my second display is no longer working
> > correctly on a desktop with an Intel G45 graphics chip.
> [...]
> > What I do know is that the problem was originally introduced by
> > 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> > base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> > "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> > The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> > of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
>
> That's apparently the bug that I've submitted a patch for on 2011/5/31:
> https://lkml.org/lkml/2011/5/31/393
> I assume/hope it's still in someone's queue.
Yup, that fixes it right up, thanks.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit
Since printk_ratelimit() shouldn't be used anymore (see comment in include/linux/printk.h), replace it with printk_ratelimited. Signed-off-by: Christian Dietrich --- drivers/gpu/drm/drm_ioc32.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c index d61d185..4a058c7 100644 --- a/drivers/gpu/drm/drm_ioc32.c +++ b/drivers/gpu/drm/drm_ioc32.c @@ -28,6 +28,7 @@ * IN THE SOFTWARE. */ #include +#include #include "drmP.h" #include "drm_core.h" @@ -253,10 +254,10 @@ static int compat_drm_addmap(struct file *file, unsigned int cmd, return -EFAULT; m32.handle = (unsigned long)handle; - if (m32.handle != (unsigned long)handle && printk_ratelimit()) - printk(KERN_ERR "compat_drm_addmap truncated handle" - " %p for type %d offset %x\n", - handle, m32.type, m32.offset); + if (m32.handle != (unsigned long)handle) + printk_ratelimited(KERN_ERR "compat_drm_addmap truncated handle" + " %p for type %d offset %x\n", + handle, m32.type, m32.offset); if (copy_to_user(argp, &m32, sizeof(m32))) return -EFAULT; -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] Use printk_ratelimited instead of printk_ratelimit
Hi, since printk_ratelimit() shouldn't be used anymore, I replaced it at several points, where it was possible with printk_ratelimited(FMT,...). This shouldn't change the behaviour in most cases, except that the printk will use an local ratelimit instead of an global one shared with all other printk_ratelimit calls. I just must made patches for a few places where it is used. If you think that it is worth converting all printk_ratelimits, i will send more patches. The changes where done against v3.0-rc1-106-g4f1ba49. greetz chris Christian Dietrich (8): powerpc/rtas-rtc: remove sideeffects of printk_ratelimit drivers/octeon: use printk_ratelimited instead of printk_ratelimit scsi/sg: use printk_ratelimited instead of printk_ratelimit md/raid: use printk_ratelimited instead of printk_ratelimit drivers/char/rtc: use printk_ratelimited instead of printk_ratelimit drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit arch/powerpc: use printk_ratelimited instead of printk_ratelimit arch/x86: use printk_ratelimited instead of printk_ratelimit arch/powerpc/kernel/rtas-rtc.c | 29 +-- arch/powerpc/kernel/signal_32.c | 57 +-- arch/powerpc/kernel/signal_64.c | 17 + arch/powerpc/kernel/traps.c | 22 +-- arch/powerpc/mm/fault.c | 10 +++--- arch/powerpc/sysdev/mpic.c | 11 +++--- arch/x86/kernel/hpet.c |6 ++-- arch/x86/kernel/irq.c |9 ++--- arch/x86/kvm/i8259.c|7 ++-- arch/x86/lguest/boot.c |6 ++-- drivers/char/rtc.c |7 ++-- drivers/gpu/drm/drm_ioc32.c |9 +++-- drivers/md/raid1.c | 22 ++- drivers/md/raid10.c | 22 ++- drivers/md/raid5.c | 39 ++--- drivers/scsi/sg.c | 18 + drivers/staging/octeon/ethernet-mdio.c | 27 +++--- drivers/staging/octeon/ethernet-rgmii.c | 33 +- drivers/staging/octeon/ethernet-rx.c| 24 +++-- drivers/staging/octeon/ethernet-sgmii.c | 14 --- drivers/staging/octeon/ethernet-tx.c| 11 +++--- drivers/staging/octeon/ethernet-util.h |4 -- drivers/staging/octeon/ethernet-xaui.c | 22 ++- 23 files changed, 221 insertions(+), 205 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] savage: remove unecessary if statement
the code always returns ret regardless, so if(ret) check is unecessary. Signed-off-by: Greg Dietsche --- drivers/gpu/drm/savage/savage_bci.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/savage/savage_bci.c b/drivers/gpu/drm/savage/savage_bci.c index bf5f83e..cb1ee4e 100644 --- a/drivers/gpu/drm/savage/savage_bci.c +++ b/drivers/gpu/drm/savage/savage_bci.c @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, &dev_priv->aperture); - if (ret) - return ret; - return ret; } -- 1.7.2.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On Mon, 6 Jun 2011 19:20:06 +0200, Melchior FRANZ wrote: > That's apparently the bug that I've submitted a patch for on 2011/5/31: > https://lkml.org/lkml/2011/5/31/393 > I assume/hope it's still in someone's queue. Yeah, we "shouldn't" need to call intel_enable_plane from i9xx_crtc_mode_set as it is called immediately afterwards from i9xx_crtc_enable. In any case, there's a bogus call in ironlake_crtc_mode_set which clearly belongs in i9xx_crtc_mode_set: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 81a9059..aa43e7b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4687,6 +4687,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); + intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); @@ -5217,8 +5218,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); - if (!HAS_PCH_SPLIT(dev)) - intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); We need to figure out why this call (in i9xx_crtc_mode_set) is required, but that will require finding hardware that reproduces the bug and fixing it there. -- keith.pack...@intel.com pgp0Opa75FnW7.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #9 from Pierre-Eric Pelloux-Prayer 2011-06-06 13:28:16 PDT --- Created an attachment (id=47621) View: https://bugs.freedesktop.org/attachment.cgi?id=47621 Review: https://bugs.freedesktop.org/review?bug=37028&attachment=47621 proposed patch Could you please try this patch ? It should fix the issue. -- 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
Re: drivers/drm/i915 maintenance process
On Sat, 04 Jun 2011 23:05:23 -0700 "Keith Packard" wrote: > 1) drm-intel-next > > This contains work destined for the 'next' release, it may include > new functionality and performance enhancements. It may also cause > regressions on some hardware. The tip of this tree will be sent > to Dave Airlie for inclusion in the kernel during the next > merge window. I've already sent all of what is on this branch > to him for 3.0 > > This tree should be tested during the development process to try and > catch bugs and regressions before they are merged. The most critical > time for testing this is just *before* the release of the current RC > kernel version as that is when it should have most of the code > planned for the *next* release. > > 2) drm-intel-fixes > > This contains bug fixes after the merge window has closed. I will > fast-forwarded to each RC when possible so that we test the fully > integrated kernel for regressions. > > This tree should be tested during the stabilization process after RC1 > comes out as patches are applied. Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part? In PCI-land, this means re-basing my -next tree periodically before the merge window opens (though not right before the merge window unless something unexpected happens, like a patch needing to be dropped; in that case I'll delay the merge window push a bit to allow for more testing). Downstream PCI developers requested this since it makes feature development much easier (you get all the bug fixes destined for Linus while working on a new feature for the next window), and as a downstream gfx developer I'd like to see this on the Intel side as well, unless other developers have big objections... 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
[Bug 38010] New: DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 Summary: DVI output not working with radeon on RV610 Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: darkbas...@gmail.com Created an attachment (id=47622) --> (https://bugs.freedesktop.org/attachment.cgi?id=47622) dmesg Hi, I have an RV610 card attached to an LG 22LH2000. The LG 22LH2000 has a 1366x768 native resolution and does have VGA and HDMI but not DVI. The Radeon HD2400 does have VGA and DVI but not HDMI, so I'm using a DVI-HDMI converter. When I use the VGA output everything works fine, but I don't get a 1:1 pixel mapping because I have to set a 1360x768 or 1368x768 resolution and the monitor is not smart enough when using vga. Instead when I attach the monitor to my laptop's Intel GMA45 HDMI output I can get a 1:1 pixel mapping even using a 1360x768 resolution. Unfortunately when using the HD2400 DVI output the monitor does not show anything, at least after loading the radeon module. In fact when loading the bios or starting grub the DVI output works flawlessly. nomodeset does not help. I even tried setting another resolution with xrandr (it automatically set 1920x1080i, but I tried 1360x768, 1280x800, 1024x768 and 800x600 and it still does not work). Distro is Debian Unstable amd64 with kernel 2.6.39 and xorg-edgers ppa. It's the only monitor I will be able to use for a couple of months, it's critical for me to get it working. Thank you -- 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 --- Comment #1 from Alex Deucher 2011-06-06 14:13:06 PDT --- Does booting with radeon.audio=0 on the kernel command line in grub help? -- 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 --- Comment #2 from darkbasic 2011-06-06 14:13:48 PDT --- Created an attachment (id=47623) --> (https://bugs.freedesktop.org/attachment.cgi?id=47623) Xorg.0.log -- 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 --- Comment #3 from darkbasic 2011-06-06 14:18:41 PDT --- > Does booting with radeon.audio=0 on the kernel command line in grub help? OMG you had been faster than light, and it worked! Consider this card does not even have an HDMI output! Thank you very much P.S. Should I close 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
[PATCH] drm/radeon/kms: disable hdmi audio by default
The current RE'd code causes blank screens and display problems on a lot of systems. So disable it by default for now. It can still be enabled by setting the audio parameter to 1. E.g.: radeon.audio=1 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38010 https://bugs.freedesktop.org/show_bug.cgi?id=27731 https://bugs.freedesktop.org/show_bug.cgi?id=35970 https://bugs.freedesktop.org/show_bug.cgi?id=26195 and many other reported problems. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 1d33060..73dfbe8 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -113,7 +113,7 @@ int radeon_benchmarking = 0; int radeon_testing = 0; int radeon_connector_table = 0; int radeon_tv = 1; -int radeon_audio = 1; +int radeon_audio = 0; int radeon_disp_priority = 0; int radeon_hw_i2c = 0; int radeon_pcie_gen2 = 0; @@ -151,7 +151,7 @@ module_param_named(connector_table, radeon_connector_table, int, 0444); MODULE_PARM_DESC(tv, "TV enable (0 = disable)"); module_param_named(tv, radeon_tv, int, 0444); -MODULE_PARM_DESC(audio, "Audio enable (0 = disable)"); +MODULE_PARM_DESC(audio, "Audio enable (1 = enable)"); module_param_named(audio, radeon_audio, int, 0444); MODULE_PARM_DESC(disp_priority, "Display Priority (0 = auto, 1 = normal, 2 = high)"); -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Flat address space with gGTT / ppGTT
Hello all, I saw at some point that per-process GTT (ppGTT) may be (or is already) implemented to handle paging. Right now, I am investigating some flat space addressing (ab)using surface states. The idea is to create a surface state (raw buffer only, this is GPGPU stuff) as big enough to cover the entire address space such that I will only manipulate offsets as pointers in this surface instead of dealing with both offsets and surface IDs (in other words, segmented address space). My concern is relative to the way bo buffers are mapped. Basically, I must be sure that _all_ of them are either mapped using ppGTT or GTT. Otherwise, this will also bring another form of segmentation. If ppGTT is implemented or will be implemented, will there be anyway to know how a bo is mapped? Cheers, Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes wrote: > Can you keep drm-intel-next fairly up to date with respect to the fixes > branch? I.e. keep it a superset of drm-intel-fixes for the most part? Yes, I wanted to do that now, but -fixes is not a fast-forward from -next and I thought I shouldn't be doing rebases. > In PCI-land, this means re-basing my -next tree periodically before the > merge window opens (though not right before the merge window unless > something unexpected happens, like a patch needing to be dropped; in > that case I'll delay the merge window push a bit to allow for more > testing). If a rebase around -RC1 is reasonable, then I'll do that now and move changes over to that. -- keith.pack...@intel.com pgpy4bzryrDsu.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 06 Jun 2011 16:24:46 -0700 Keith Packard wrote: > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > wrote: > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > -next and I thought I shouldn't be doing rebases. You shouldn't if your downstream is using git trees and you're pulling from them, but it depends on your downstream. In my particular case, I'm ok with rebases if it means I get fixes. :) -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 16:30:25 -0700 Jesse Barnes wrote: > On Mon, 06 Jun 2011 16:24:46 -0700 > Keith Packard wrote: > > > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > > wrote: > > > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > > -next and I thought I shouldn't be doing rebases. > > You shouldn't if your downstream is using git trees and you're pulling > from them, but it depends on your downstream. In my particular case, > I'm ok with rebases if it means I get fixes. :) Oh and the other big reason is testing. rebase generally voids previous testing since you have new bits, so Linus really hates to see a rebase just before a pull request, and I think Dave does too. But rebasing for good reason (e.g. to make your -next branch a superset of your -fixes branch) on occasion is fine. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36812] New: Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Summary: Radeon fails to load firmware Product: Drivers Version: 2.5 Kernel Version: 3.0-rc2 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: cl...@jhcloos.com Regression: Yes This used to work, but I had been booting with radeon.modset=0 for a few weeks, so I do not know when it broke. With 3.0-rc2 (compiled from git master) I get (note this first two lines): [ 61.920296] r600_cp: Failed to load firmware "radeon/R600_rlc.bin" [ 61.920370] [drm:r600_startup] *ERROR* Failed to load firmware! [ 61.920442] radeon :01:05.0: disabling GPU acceleration [ 61.921543] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921615] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921697] [drm] Enabling audio support [ 61.921949] [drm] Radeon Display Connectors [ 61.922030] [drm] Connector 0: [ 61.922100] [drm] VGA [ 61.922170] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 61.922287] [drm] Encoders: [ 61.922357] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 61.922427] [drm] Connector 1: [ 61.922496] [drm] HDMI-A [ 61.922565] [drm] HPD1 [ 61.922634] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 61.922751] [drm] Encoders: [ 61.922820] [drm] DFP1: INTERNAL_KLDSCP_LVTMA [ 61.942202] [drm] radeon: power management initialized [ 61.958278] No connectors reported connected with modes [ 61.958351] [drm] Cannot find any crtc or sizes - going 1024x768 [ 61.965068] [drm] fb mappable at 0xD004 [ 61.965137] [drm] vram apper at 0xD000 [ 61.965206] [drm] size 3145728 [ 61.965274] [drm] fb depth is 24 [ 61.965342] [drm]pitch is 4096 [ 61.965460] fbcon: radeondrmfb (fb0) is primary device [ 61.979478] Console: switching to colour frame buffer device 128x48 [ 61.985634] fb0: radeondrmfb frame buffer device [ 61.985696] drm: registered panic notifier [ 61.985755] [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 and yet: :; ls -sl /lib/firmware/radeon/R600_rlc.bin 4 -rw-r--r-- 1 root root 3072 Jun 6 12:15 /lib/firmware/radeon/R600_rlc.bin (from a fresh update from http://people.freedesktop.org/~agd5f/radeon_ucode/ .) -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Andrew Morton changed: What|Removed |Added CC||a...@linux-foundation.org --- Comment #1 from Andrew Morton 2011-06-06 23:59:54 --- If it was Ok a couple of weeks ago then I assume that this is a psot-2.6.39 regression? -- 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 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #10 from Maggioni Marcello 2011-06-06 17:10:42 PDT --- Hi, after applying the patch the problem seems to be still there ... my card is a Radeon 5850. The lights have a white halo surrounding them flickering. Also , the white area at the bottom of the screen problem is still present in fullscreen mode. It was just scene dependent and I thought it was gone because I checked in a scene in which it wasn't present. -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 --- Comment #2 from James Cloos 2011-06-07 00:47:29 --- Longer than that. The box is usually headless; when I first got it the missing firmware prevented booting, so I added radeon.modeset=0 to the grub config and manually changed that for those occasions when I moved the box to the TV. Today I changed the grub config in honour of the upcoming 3.0. ☺ (That it boots now even though it fails to load that firmware is a nice progression.) My best guess, based on the timestamps of my .config archive, is that I last connected it to the TV during the 38-rc1 timeframe. -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 --- Comment #3 from James Cloos 2011-06-07 00:53:41 --- I forgot to add: I don’t see from git-grep(1)ing the tree where or how the kernel knows to find firmware in /lib/firmware. All I can see is /lib/firmware as the target to make firmware_install and several comments specifying /lib/firmware as the typical location. What am I missing? -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher 2011-06-07 02:17:36 --- Most likely you did not include the firmware in your initrd. -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 James Cloos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from James Cloos 2011-06-07 04:01:31 --- Ah. OK. The driver tries to load the firmware before / is mounted, then? As I do not use initrd there the answer seems to be: -CONFIG_EXTRA_FIRMWARE="" +CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin" +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" to the .config. Closing as invalid. Will reopen if the above .config change doesn’t fix it. (Last time I must have manually done what EXTRA_FIRMWARE does. I lost that clone in the meantime, though, so that is only a guess. (It was a clone of my local, pristine clone. And the .configs were backed up in their own git repo. So that loss didn’t seem like much of a nuisance. But I obviously forgot about this issue in the meantime. ☹) -- 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
[git pull] drm fixes
Hi Linus, this is just the Intel and nouveau fixes, this alongside the radeon fixes pull that is outstanding, it has one serious intel regression fix for 945 machines that got broken in the ivybridge support, along with a few fixes from nouveau. Dave. The following changes since commit 59c5f46fbe01a00eedf54a23789634438bb80603: Linux 3.0-rc2 (2011-06-06 18:06:33 +0900) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Ben Skeggs (5): drm/nvc0: recognise 0xdX chipsets as NV_C0 drm/nouveau: don't create accel engine objects when noaccel=1 drm/nouveau: fix vram page mapping when crossing page table boundaries drm/nouveau: fix leak of gart mm node drm/nv40: fall back to paged dma object for the moment Chris Wilson (5): drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/ drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0 drm/i915/crt: Explicitly return false if connected to a digital monitor drm/i915: Remove unused enum "chip_family" drm/i915: Share the common force-audio property between connectors Dan Carpenter (1): drm/i915: fix if statement in ivybridge irq handler Daniel Vetter (2): drm/i915: Only print out the actual number of fences for i915_error_state drm/915: fix relaxed tiling on gen2: tile height Dave Airlie (2): Merge remote branch 'keithp/drm-intel-fixes' of /ssd/git/drm-next into drm-fixes Merge remote branch 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next into drm-fixes Francisco Jerez (1): drm/nv17-nv40: Fix modesetting failure when pitch == 4096px (fdo bug 35901). Hans de Goede (1): drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007 Jason Stubbs (1): drm/i915: fix regression after clock gating init split Nicolas Kaiser (1): drm: i915: correct return status in intel_hdmi_mode_valid() drivers/gpu/drm/i915/i915_debugfs.c |2 +- drivers/gpu/drm/i915/i915_drv.h |8 +-- drivers/gpu/drm/i915/i915_gem.c | 26 drivers/gpu/drm/i915/i915_irq.c |2 +- drivers/gpu/drm/i915/intel_crt.c|4 + drivers/gpu/drm/i915/intel_display.c| 89 ++-- drivers/gpu/drm/i915/intel_dp.c | 15 + drivers/gpu/drm/i915/intel_drv.h|1 + drivers/gpu/drm/i915/intel_hdmi.c | 16 + drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_modes.c | 30 drivers/gpu/drm/i915/intel_sdvo.c | 14 +--- drivers/gpu/drm/nouveau/nouveau_hw.c|2 + drivers/gpu/drm/nouveau/nouveau_mem.c |4 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c |2 +- drivers/gpu/drm/nouveau/nouveau_state.c | 114 --- drivers/gpu/drm/nouveau/nouveau_vm.c|1 + drivers/gpu/drm/nouveau/nv04_crtc.c |8 ++- drivers/gpu/drm/nouveau/nvreg.h |2 + 19 files changed, 161 insertions(+), 187 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38018] New: Implementation error: bad format in _mesa_pack_rgba_span
https://bugs.freedesktop.org/show_bug.cgi?id=38018 Summary: Implementation error: bad format in _mesa_pack_rgba_span Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: gm.potato...@gmail.com Created an attachment (id=47634) --> (https://bugs.freedesktop.org/attachment.cgi?id=47634) dmesg and glxinfo catenated together When running the freeware OpenGL 2.1 title Savage 2, the following two lines of text show up on the console while the game is running. The two lines repeat exactly seven times. Only one functional anomaly was observed: when trying to quit the game, only a SIGKILL could terminate the process (SIGTERM / SIGINT were not enough). Performance is fairly good and there are no observable rendering errors, so I am marking this as MINOR. The message is: Please report at bugs.freedesktop.org Mesa 7.11-devel implementation error: bad format in _mesa_pack_rgba_span dmesg and glxinfo are attached. Summary: (1) Weird intel-iommu warnings on bootup (2) Hardware: Radeon HD5970 (3) Git version of mesa: git-c2e6590 (4) libdrm, DDX and linux from git (5) Xorg server from Ubuntu 11.04, version 1.10.1; pixman 0.20.2 Non-standard radeon DDX options: Option "SwapbuffersWait" "off" Option "ColorTiling" "on" Option "EnablePageFlip" "on" Option "EXAVSync" "off" Option "DynamicPM" "on" -- 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] New: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Summary: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: h.j...@gmx.at Created an attachment (id=47642) --> (https://bugs.freedesktop.org/attachment.cgi?id=47642) Xorg.0.log I don't know where this should go (drm, mesa?), but after a while, I notice corruption of textures / pixmaps. It can be reproduced quite easily by opening a few applications, or starting another X session. In particular, I could determine the following: - Corrupted areas resemble parts of the previous visible login screen - Icons, fonts and widgets like vertical gtk progressbars get corrupted, but only their lower half - Window (emerald) decoration seem to get corrupted completely. - It's not related to color tiling. - Pageflipping is enabled. - Restarting a corrupted application fixes it temporarily, while minimizing etc. doesn't. Restarting compiz doesn't fix it either. I believe this is specific to cayman, as the issue does not occur on a thinkpad t400 with ATI Mobility Radeon HD 3400 and similar configuration. Software configuration: - linux-3.0.0-rc1 with latest fixes from drm-2.6 git applied, up to 2a9e5862a38f7195931bd51788dc9ce68b28120c. - r600g from git mesa compiled on 12:44:56 03.06.2011 - xorg-server 1.10.2 - libdrm git 21:06:43 02.06.2011 - xf86-video-ati git 21:56:58 02.06.2011 lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Device 6719 (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Device 0b00 Flags: bus master, fast devsel, latency 0, IRQ 54 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at fe62 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at fe60 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon -- Apart from this, it works great, no crashes so far! -- 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 --- Comment #1 from Harald Judt 2011-06-06 23:21:19 PDT --- Created an attachment (id=47643) --> (https://bugs.freedesktop.org/attachment.cgi?id=47643) Screenshot of a corrupted icon. As you can see, only the lower half of the icon is corrupted. -- 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 --- Comment #2 from Harald Judt 2011-06-06 23:26:48 PDT --- Created an attachment (id=47644) --> (https://bugs.freedesktop.org/attachment.cgi?id=47644) Screenshot of corrupted xfce panel plugins. Here, parts of a previous screen (gdm login screen) shine through the lower half of the plugin widgets (gtk progress bar). I guess the gdm login screen was not active on any console at this time, so these are just remnants. Reloading the panel fixes it. -- 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 --- Comment #3 from Harald Judt 2011-06-06 23:36:06 PDT --- Created an attachment (id=47645) --> (https://bugs.freedesktop.org/attachment.cgi?id=47645) Screenshot of corrupted firefox toolbar Corruption can get quite nasty after a while. The ugly pink background once was a somewhat nicer image from some firefox persona theme. There are more of those corrupted icons too for those who got a taste of them ;-) -- 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
Re: [PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
Hi David,
Somehow my Cc got lost. Maybe you missed this. Any comments?
Thanks
Sascha
On Fri, Jun 03, 2011 at 12:54:14PM +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
> ---
> drivers/gpu/drm/drm_crtc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 872747c..21058e6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1113,7 +1113,7 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> if (card_res->count_fbs >= fb_count) {
> copied = 0;
> fb_id = (uint32_t __user *)(unsigned long)card_res->fb_id_ptr;
> - list_for_each_entry(fb, &file_priv->fbs, head) {
> + list_for_each_entry(fb, &file_priv->fbs, filp_head) {
> if (put_user(fb->base.id, fb_id + copied)) {
> ret = -EFAULT;
> goto out;
> --
> 1.7.5.3
>
> --
> 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- |
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
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- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] savage: remove unecessary if statement
* Greg Dietsche : > the code always returns ret regardless, so if(ret) check is unecessary. /unecessary/unnecessary/ > > Signed-off-by: Greg Dietsche Reviewed-by: Nicolas Kaiser Best regards, Nicolas Kaiser > --- > drivers/gpu/drm/savage/savage_bci.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/savage/savage_bci.c > b/drivers/gpu/drm/savage/savage_bci.c > index bf5f83e..cb1ee4e 100644 > --- a/drivers/gpu/drm/savage/savage_bci.c > +++ b/drivers/gpu/drm/savage/savage_bci.c > @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) > ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, >_DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, >&dev_priv->aperture); > - if (ret) > - return ret; > - > return ret; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 --- Comment #14 from Michal Suchanek 2011-06-06 07:46:16 PDT --- Yes, this has been fixed in 7.11. A piglit test for this would be nice because it was a longstanding issue for which I did not find any test neither in piglit nor in mesa-demos. -- 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 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 Michal Suchanek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||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
[PATCH] drm/radeon/kms: fix mac g5 quirk
Apple uses the same subsystem pci ids for lots of
hardware much of which is wired up differently. In
this case, the G5 imac and the G5 tower.
Only apply the quirk configuration to G5 towers.
Reported-by: Joachim Henke
Signed-off-by: Alex Deucher
Cc: Joachim Henke
Cc: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 5b991f7..19b10cf 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1548,9 +1548,8 @@ bool radeon_get_legacy_connector_info_from_table(struct
drm_device *dev)
(rdev->pdev->subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev->mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev->pdev->device == 0x4150) &&
- (rdev->pdev->subsystem_vendor == 0x1002) &&
- (rdev->pdev->subsystem_device == 0x4150)) {
+ } else if (of_machine_is_compatible("PowerMac7,2") ||
+ of_machine_is_compatible("PowerMac7,3")) {
/* Mac G5 9600 */
rdev->mode_info.connector_table = CT_MAC_G5_9600;
} else
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
* Nick Bowler -- Monday 06 June 2011:
> After upgrading to 3.0-rc2, my second display is no longer working
> correctly on a desktop with an Intel G45 graphics chip.
[...]
> What I do know is that the problem was originally introduced by
> 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
That's apparently the bug that I've submitted a patch for on 2011/5/31:
https://lkml.org/lkml/2011/5/31/393
I assume/hope it's still in someone's queue.
m.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Semantics of the 'dumb' interface
> I think the intel driver forces a reset to the system scanout on release. I've > actually never found a test to indicate it was completely necessary on > other GPUs I need to force this on the GMA500 because we want some kind of sane scanout left and the nice guys at Dell decided the Mini 10 didn't actually need a sysrq key so sysrq-V isn't going to help. On the bright side GEM and the dumb kms stuff now seem to work with a new device id added to libkms and a daft bug in libkms dumb.c fixed (if you report a 32bit fb type, you probably want to allocate a 32bit fb not a 16bit one) Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Regression: Borked display on second output with Intel G45 in 3.0-rc2
After upgrading to 3.0-rc2, my second display is no longer working
correctly on a desktop with an Intel G45 graphics chip. The system has
two displays, one connected by HDMI and the other by VGA.
Both displays work fine in the console; the troubles begin after
starting X. It *looks* as if one of the displays is still scanning out
from the old framebuffer: what I see on the VGA monitor after starting X
is a black screen with a console cursor at the top -- this is just like
an empty VT except that the cursor is not blinking. If I switch to VT 1
and then back to X, the display contains all the bootup text that was on
VT 1. In any case, the mouse cursor works properly on the display.
There are no unusual messages in dmesg or the Xorg log in any case.
If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1
--same-as HDMI1 && xrandr --output VGA1 --right-of VGA1) , it's possible
to get both displays showing the right thing. But then if I switch back
to the console, I end up with one display showing the console text and
the other is still showing my X session! (In this instance, the VGA was
working and the HDMI was showing the wrong thing).
This is a regression from 2.6.39, but that's not the whole story: this
problem appears to have been introduced very briefly late in the 2.6.39
-rc cycle and subsequently fixed on mainline. It then reappeared during
the 3.0 merge window. Unfortunately, this fact seems to make it
impossible to bisect to a specific commit.
What I do know is that the problem was originally introduced by
49183b2818de ("drm/i915: Only enable the plane after setting the fb
base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
"drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
Unfortunately, I cannot be more specific than that because it appears
that the entire drm side of that merge consists of 'bad' commits and git
bisect gets very confused.
Let me know if you need any more info,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On 2011-06-06 19:20 +0200, Melchior FRANZ wrote:
> * Nick Bowler -- Monday 06 June 2011:
> > After upgrading to 3.0-rc2, my second display is no longer working
> > correctly on a desktop with an Intel G45 graphics chip.
> [...]
> > What I do know is that the problem was originally introduced by
> > 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> > base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> > "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> > The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> > of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
>
> That's apparently the bug that I've submitted a patch for on 2011/5/31:
> https://lkml.org/lkml/2011/5/31/393
> I assume/hope it's still in someone's queue.
Yup, that fixes it right up, thanks.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit
Since printk_ratelimit() shouldn't be used anymore (see comment in include/linux/printk.h), replace it with printk_ratelimited. Signed-off-by: Christian Dietrich --- drivers/gpu/drm/drm_ioc32.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c index d61d185..4a058c7 100644 --- a/drivers/gpu/drm/drm_ioc32.c +++ b/drivers/gpu/drm/drm_ioc32.c @@ -28,6 +28,7 @@ * IN THE SOFTWARE. */ #include +#include #include "drmP.h" #include "drm_core.h" @@ -253,10 +254,10 @@ static int compat_drm_addmap(struct file *file, unsigned int cmd, return -EFAULT; m32.handle = (unsigned long)handle; - if (m32.handle != (unsigned long)handle && printk_ratelimit()) - printk(KERN_ERR "compat_drm_addmap truncated handle" - " %p for type %d offset %x\n", - handle, m32.type, m32.offset); + if (m32.handle != (unsigned long)handle) + printk_ratelimited(KERN_ERR "compat_drm_addmap truncated handle" + " %p for type %d offset %x\n", + handle, m32.type, m32.offset); if (copy_to_user(argp, &m32, sizeof(m32))) return -EFAULT; -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] Use printk_ratelimited instead of printk_ratelimit
Hi, since printk_ratelimit() shouldn't be used anymore, I replaced it at several points, where it was possible with printk_ratelimited(FMT,...). This shouldn't change the behaviour in most cases, except that the printk will use an local ratelimit instead of an global one shared with all other printk_ratelimit calls. I just must made patches for a few places where it is used. If you think that it is worth converting all printk_ratelimits, i will send more patches. The changes where done against v3.0-rc1-106-g4f1ba49. greetz chris Christian Dietrich (8): powerpc/rtas-rtc: remove sideeffects of printk_ratelimit drivers/octeon: use printk_ratelimited instead of printk_ratelimit scsi/sg: use printk_ratelimited instead of printk_ratelimit md/raid: use printk_ratelimited instead of printk_ratelimit drivers/char/rtc: use printk_ratelimited instead of printk_ratelimit drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit arch/powerpc: use printk_ratelimited instead of printk_ratelimit arch/x86: use printk_ratelimited instead of printk_ratelimit arch/powerpc/kernel/rtas-rtc.c | 29 +-- arch/powerpc/kernel/signal_32.c | 57 +-- arch/powerpc/kernel/signal_64.c | 17 + arch/powerpc/kernel/traps.c | 22 +-- arch/powerpc/mm/fault.c | 10 +++--- arch/powerpc/sysdev/mpic.c | 11 +++--- arch/x86/kernel/hpet.c |6 ++-- arch/x86/kernel/irq.c |9 ++--- arch/x86/kvm/i8259.c|7 ++-- arch/x86/lguest/boot.c |6 ++-- drivers/char/rtc.c |7 ++-- drivers/gpu/drm/drm_ioc32.c |9 +++-- drivers/md/raid1.c | 22 ++- drivers/md/raid10.c | 22 ++- drivers/md/raid5.c | 39 ++--- drivers/scsi/sg.c | 18 + drivers/staging/octeon/ethernet-mdio.c | 27 +++--- drivers/staging/octeon/ethernet-rgmii.c | 33 +- drivers/staging/octeon/ethernet-rx.c| 24 +++-- drivers/staging/octeon/ethernet-sgmii.c | 14 --- drivers/staging/octeon/ethernet-tx.c| 11 +++--- drivers/staging/octeon/ethernet-util.h |4 -- drivers/staging/octeon/ethernet-xaui.c | 22 ++- 23 files changed, 221 insertions(+), 205 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] savage: remove unecessary if statement
the code always returns ret regardless, so if(ret) check is unecessary. Signed-off-by: Greg Dietsche --- drivers/gpu/drm/savage/savage_bci.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/savage/savage_bci.c b/drivers/gpu/drm/savage/savage_bci.c index bf5f83e..cb1ee4e 100644 --- a/drivers/gpu/drm/savage/savage_bci.c +++ b/drivers/gpu/drm/savage/savage_bci.c @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, &dev_priv->aperture); - if (ret) - return ret; - return ret; } -- 1.7.2.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On Mon, 6 Jun 2011 19:20:06 +0200, Melchior FRANZ wrote: > That's apparently the bug that I've submitted a patch for on 2011/5/31: > https://lkml.org/lkml/2011/5/31/393 > I assume/hope it's still in someone's queue. Yeah, we "shouldn't" need to call intel_enable_plane from i9xx_crtc_mode_set as it is called immediately afterwards from i9xx_crtc_enable. In any case, there's a bogus call in ironlake_crtc_mode_set which clearly belongs in i9xx_crtc_mode_set: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 81a9059..aa43e7b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4687,6 +4687,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); + intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); @@ -5217,8 +5218,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); - if (!HAS_PCH_SPLIT(dev)) - intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); We need to figure out why this call (in i9xx_crtc_mode_set) is required, but that will require finding hardware that reproduces the bug and fixing it there. -- keith.pack...@intel.com pgp0Opa75FnW7.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #9 from Pierre-Eric Pelloux-Prayer 2011-06-06 13:28:16 PDT --- Created an attachment (id=47621) View: https://bugs.freedesktop.org/attachment.cgi?id=47621 Review: https://bugs.freedesktop.org/review?bug=37028&attachment=47621 proposed patch Could you please try this patch ? It should fix the issue. -- 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
Re: drivers/drm/i915 maintenance process
On Sat, 04 Jun 2011 23:05:23 -0700 "Keith Packard" wrote: > 1) drm-intel-next > > This contains work destined for the 'next' release, it may include > new functionality and performance enhancements. It may also cause > regressions on some hardware. The tip of this tree will be sent > to Dave Airlie for inclusion in the kernel during the next > merge window. I've already sent all of what is on this branch > to him for 3.0 > > This tree should be tested during the development process to try and > catch bugs and regressions before they are merged. The most critical > time for testing this is just *before* the release of the current RC > kernel version as that is when it should have most of the code > planned for the *next* release. > > 2) drm-intel-fixes > > This contains bug fixes after the merge window has closed. I will > fast-forwarded to each RC when possible so that we test the fully > integrated kernel for regressions. > > This tree should be tested during the stabilization process after RC1 > comes out as patches are applied. Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part? In PCI-land, this means re-basing my -next tree periodically before the merge window opens (though not right before the merge window unless something unexpected happens, like a patch needing to be dropped; in that case I'll delay the merge window push a bit to allow for more testing). Downstream PCI developers requested this since it makes feature development much easier (you get all the bug fixes destined for Linus while working on a new feature for the next window), and as a downstream gfx developer I'd like to see this on the Intel side as well, unless other developers have big objections... 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
[Bug 38010] New: DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 Summary: DVI output not working with radeon on RV610 Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: darkbas...@gmail.com Created an attachment (id=47622) --> (https://bugs.freedesktop.org/attachment.cgi?id=47622) dmesg Hi, I have an RV610 card attached to an LG 22LH2000. The LG 22LH2000 has a 1366x768 native resolution and does have VGA and HDMI but not DVI. The Radeon HD2400 does have VGA and DVI but not HDMI, so I'm using a DVI-HDMI converter. When I use the VGA output everything works fine, but I don't get a 1:1 pixel mapping because I have to set a 1360x768 or 1368x768 resolution and the monitor is not smart enough when using vga. Instead when I attach the monitor to my laptop's Intel GMA45 HDMI output I can get a 1:1 pixel mapping even using a 1360x768 resolution. Unfortunately when using the HD2400 DVI output the monitor does not show anything, at least after loading the radeon module. In fact when loading the bios or starting grub the DVI output works flawlessly. nomodeset does not help. I even tried setting another resolution with xrandr (it automatically set 1920x1080i, but I tried 1360x768, 1280x800, 1024x768 and 800x600 and it still does not work). Distro is Debian Unstable amd64 with kernel 2.6.39 and xorg-edgers ppa. It's the only monitor I will be able to use for a couple of months, it's critical for me to get it working. Thank you -- 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 --- Comment #1 from Alex Deucher 2011-06-06 14:13:06 PDT --- Does booting with radeon.audio=0 on the kernel command line in grub help? -- 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 --- Comment #2 from darkbasic 2011-06-06 14:13:48 PDT --- Created an attachment (id=47623) --> (https://bugs.freedesktop.org/attachment.cgi?id=47623) Xorg.0.log -- 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 --- Comment #3 from darkbasic 2011-06-06 14:18:41 PDT --- > Does booting with radeon.audio=0 on the kernel command line in grub help? OMG you had been faster than light, and it worked! Consider this card does not even have an HDMI output! Thank you very much P.S. Should I close 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
[PATCH] drm/radeon/kms: disable hdmi audio by default
The current RE'd code causes blank screens and display problems on a lot of systems. So disable it by default for now. It can still be enabled by setting the audio parameter to 1. E.g.: radeon.audio=1 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38010 https://bugs.freedesktop.org/show_bug.cgi?id=27731 https://bugs.freedesktop.org/show_bug.cgi?id=35970 https://bugs.freedesktop.org/show_bug.cgi?id=26195 and many other reported problems. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 1d33060..73dfbe8 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -113,7 +113,7 @@ int radeon_benchmarking = 0; int radeon_testing = 0; int radeon_connector_table = 0; int radeon_tv = 1; -int radeon_audio = 1; +int radeon_audio = 0; int radeon_disp_priority = 0; int radeon_hw_i2c = 0; int radeon_pcie_gen2 = 0; @@ -151,7 +151,7 @@ module_param_named(connector_table, radeon_connector_table, int, 0444); MODULE_PARM_DESC(tv, "TV enable (0 = disable)"); module_param_named(tv, radeon_tv, int, 0444); -MODULE_PARM_DESC(audio, "Audio enable (0 = disable)"); +MODULE_PARM_DESC(audio, "Audio enable (1 = enable)"); module_param_named(audio, radeon_audio, int, 0444); MODULE_PARM_DESC(disp_priority, "Display Priority (0 = auto, 1 = normal, 2 = high)"); -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Flat address space with gGTT / ppGTT
Hello all, I saw at some point that per-process GTT (ppGTT) may be (or is already) implemented to handle paging. Right now, I am investigating some flat space addressing (ab)using surface states. The idea is to create a surface state (raw buffer only, this is GPGPU stuff) as big enough to cover the entire address space such that I will only manipulate offsets as pointers in this surface instead of dealing with both offsets and surface IDs (in other words, segmented address space). My concern is relative to the way bo buffers are mapped. Basically, I must be sure that _all_ of them are either mapped using ppGTT or GTT. Otherwise, this will also bring another form of segmentation. If ppGTT is implemented or will be implemented, will there be anyway to know how a bo is mapped? Cheers, Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes wrote: > Can you keep drm-intel-next fairly up to date with respect to the fixes > branch? I.e. keep it a superset of drm-intel-fixes for the most part? Yes, I wanted to do that now, but -fixes is not a fast-forward from -next and I thought I shouldn't be doing rebases. > In PCI-land, this means re-basing my -next tree periodically before the > merge window opens (though not right before the merge window unless > something unexpected happens, like a patch needing to be dropped; in > that case I'll delay the merge window push a bit to allow for more > testing). If a rebase around -RC1 is reasonable, then I'll do that now and move changes over to that. -- keith.pack...@intel.com pgpy4bzryrDsu.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 06 Jun 2011 16:24:46 -0700 Keith Packard wrote: > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > wrote: > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > -next and I thought I shouldn't be doing rebases. You shouldn't if your downstream is using git trees and you're pulling from them, but it depends on your downstream. In my particular case, I'm ok with rebases if it means I get fixes. :) -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 16:30:25 -0700 Jesse Barnes wrote: > On Mon, 06 Jun 2011 16:24:46 -0700 > Keith Packard wrote: > > > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > > wrote: > > > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > > -next and I thought I shouldn't be doing rebases. > > You shouldn't if your downstream is using git trees and you're pulling > from them, but it depends on your downstream. In my particular case, > I'm ok with rebases if it means I get fixes. :) Oh and the other big reason is testing. rebase generally voids previous testing since you have new bits, so Linus really hates to see a rebase just before a pull request, and I think Dave does too. But rebasing for good reason (e.g. to make your -next branch a superset of your -fixes branch) on occasion is fine. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36812] New: Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Summary: Radeon fails to load firmware Product: Drivers Version: 2.5 Kernel Version: 3.0-rc2 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: cl...@jhcloos.com Regression: Yes This used to work, but I had been booting with radeon.modset=0 for a few weeks, so I do not know when it broke. With 3.0-rc2 (compiled from git master) I get (note this first two lines): [ 61.920296] r600_cp: Failed to load firmware "radeon/R600_rlc.bin" [ 61.920370] [drm:r600_startup] *ERROR* Failed to load firmware! [ 61.920442] radeon :01:05.0: disabling GPU acceleration [ 61.921543] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921615] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921697] [drm] Enabling audio support [ 61.921949] [drm] Radeon Display Connectors [ 61.922030] [drm] Connector 0: [ 61.922100] [drm] VGA [ 61.922170] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 61.922287] [drm] Encoders: [ 61.922357] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 61.922427] [drm] Connector 1: [ 61.922496] [drm] HDMI-A [ 61.922565] [drm] HPD1 [ 61.922634] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 61.922751] [drm] Encoders: [ 61.922820] [drm] DFP1: INTERNAL_KLDSCP_LVTMA [ 61.942202] [drm] radeon: power management initialized [ 61.958278] No connectors reported connected with modes [ 61.958351] [drm] Cannot find any crtc or sizes - going 1024x768 [ 61.965068] [drm] fb mappable at 0xD004 [ 61.965137] [drm] vram apper at 0xD000 [ 61.965206] [drm] size 3145728 [ 61.965274] [drm] fb depth is 24 [ 61.965342] [drm]pitch is 4096 [ 61.965460] fbcon: radeondrmfb (fb0) is primary device [ 61.979478] Console: switching to colour frame buffer device 128x48 [ 61.985634] fb0: radeondrmfb frame buffer device [ 61.985696] drm: registered panic notifier [ 61.985755] [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 and yet: :; ls -sl /lib/firmware/radeon/R600_rlc.bin 4 -rw-r--r-- 1 root root 3072 Jun 6 12:15 /lib/firmware/radeon/R600_rlc.bin (from a fresh update from http://people.freedesktop.org/~agd5f/radeon_ucode/ .) -- 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 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Andrew Morton changed: What|Removed |Added CC||a...@linux-foundation.org --- Comment #1 from Andrew Morton 2011-06-06 23:59:54 --- If it was Ok a couple of weeks ago then I assume that this is a psot-2.6.39 regression? -- 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 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #10 from Maggioni Marcello 2011-06-06 17:10:42 PDT --- Hi, after applying the patch the problem seems to be still there ... my card is a Radeon 5850. The lights have a white halo surrounding them flickering. Also , the white area at the bottom of the screen problem is still present in fullscreen mode. It was just scene dependent and I thought it was gone because I checked in a scene in which it wasn't present. -- 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
