Linux 2.6.39-rc3

* Alexandre Demers wrote: > On 11-04-15 10:27 AM, Joerg Roedel wrote: > > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: > >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of > >> the other patches? > > Yes, apply it just on -rc3 without any other patch.

[PATCH] Big endian support for RV730 (Gallium r600g)

eviewing of the patch would be greatly appreciated. Regards, Cedric -- next part -- A non-text attachment was scrubbed... Name: rv730_gallium_be_support.patch Type: text/x-patch Size: 14868 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/at

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: > Ok, but how did the allocation changes start triggering this error in > v2.6.39-rc1? There must still be some layout specific thing here, right? > Do we understand the details of that as well? Well, thinking again about this, the GPU

Linux 2.6.39-rc3

On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote: > On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel wrote: > > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote: > >> On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote: > >> > And this makes a difference, with this change on-

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: > Ok, but how did the allocation changes start triggering this error in > v2.6.39-rc1? There must still be some layout specific thing here, right? > Do we understand the details of that as well? No, I must admit that I lack enough knowl

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 04:04:45PM +0200, Andreas Herrmann wrote: > What about tagging this patch for stable/longterm releases? > > Potentially there are other cases where certain combinations of > hardware(GPUs)/drivers/whatsoever might trigger a GartTlbWlkErr. If > the BIOS doesn't follow the BK

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: > Ok, I'll test it today. Should I apply it on a clean rc3 without any of > the other patches? Yes, apply it just on -rc3 without any other patch. > > BTW, may I suggest adding the info under bug 33012 in kernel bugzilla? > This c

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 03:11:52PM +0200, Joerg Roedel wrote: > On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > > we definitely want to also understand the reason for things not > > working, even if we do revert.. > > Okay, here it is. > > After experimenting with different con

[PATCH] drm: parse color format support for digital displays

On 4/15/11 3:19 PM, Jesse Barnes wrote: > Or is there a CEA block extension that allows for more granularity? CEA has bits for the two YCbCr formats too, which we should also parse since there's plenty of 1.3+CEA blocks in the world thanks to HDMI. For CEA blocks version 2 and up (version numb

Linux 2.6.39-rc3

* Joerg Roedel wrote: > On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > > we definitely want to also understand the reason for things not > > working, even if we do revert.. > > Okay, here it is. > > After experimenting with different configurations for the north-bridge > it

[PATCH] drm: parse color format support for digital displays

On 4/15/11 2:40 PM, Jesse Barnes wrote: > @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid, > info->bpp = 0; > break; > } > + > + if (edid->features & DRM_EDID_FEATURE_RGB) > + info->color_formats = DRM_COLOR_FORMAT_RGB444;

Linux 2.6.39-rc3

On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > we definitely want to also understand the reason for things not > working, even if we do revert.. Okay, here it is. After experimenting with different configurations for the north-bridge it turned out that a GART related MCE fires

Linux 2.6.39-rc3

On 11-04-15 10:27 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of >> the other patches? > Yes, apply it just on -rc3 without any other patch. > >> BTW, may I suggest adding the inf

[PATCH] x86/amd: Disable GartTlbWlkErr when BIOS forgets it

This patch disables GartTlbWlk errors on AMD Fam10h CPUs if the BIOS forgets to do is (or is just too old). Letting these errors enabled can cause a sync-flood on the CPU causing a reboot. This patch is the fix for https://bugzilla.kernel.org/show_bug.cgi?id=33012 on my machine. Signed-

[RFC] drm: emit change events when mode config changes

On 4/14/11 1:42 PM, Jesse Barnes wrote: > We've already seen that apps want to monitor the display config, and > some (like upowerd) poll for changes since we don't provide a > notification for general mode config changes, just hotplug events. So > add a new drm event, with CHANGE=1 set in the eve

[PATCH] drm: add bit depth parsing

On 4/15/11 2:22 PM, Jesse Barnes wrote: > EDID 1.4 digital monitors report the bit depth supported in the input > field. Add support for parsing this out and storing the info in the > display_info structure for use by drivers. > > Signed-off-by: Jesse Barnes Very nice. Reviewed-by: Adam Jackson

[PATCH] drm: parse color format support for digital displays

EDID 1.4 digital displays report the color spaces they support in the features block. Add support for grabbing this data and stuffing it into the display_info struct for driver use. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c |6 ++ include/drm/drm_crtc.h |5 -

[PATCH] drm: parse color format support for digital displays

EDID 1.4 digital displays report the color spaces they support in the features block. Add support for grabbing this data and stuffing it into the display_info struct for driver use. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c |6 ++ include/drm/drm_crtc.h |5 -

Re: [PATCH 2/2] drm: parse color format support for digital displays

On Sat, 16 Apr 2011 06:42:44 +1000 Dave Airlie wrote: > On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes > wrote: > > On Sat, 16 Apr 2011 06:10:07 +1000 > > Dave Airlie wrote: > > > >> > - > >> > +#define DRM_COLOR_FORMAT_RGB444                (1<<0) > >> > +#define DRM_COLOR_FORMAT_YCRCB444    

[PATCH 2/2] drm: parse color format support for digital displays

On Sat, 16 Apr 2011 06:42:44 +1000 Dave Airlie wrote: > On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes > wrote: > > On Sat, 16 Apr 2011 06:10:07 +1000 > > Dave Airlie wrote: > > > >> > - > >> > +#define DRM_COLOR_FORMAT_RGB444 ? ? ? ? ? ? ? ?(1<<0) > >> > +#define DRM_COLOR_FORMAT_YCRCB444 ? ?

Re: [PATCH 2/2] drm: parse color format support for digital displays

On Sat, Apr 16, 2011 at 6:39 AM, Jesse Barnes wrote: > On Sat, 16 Apr 2011 06:10:07 +1000 > Dave Airlie wrote: > >> > - >> > +#define DRM_COLOR_FORMAT_RGB444                (1<<0) >> > +#define DRM_COLOR_FORMAT_YCRCB444      (1<<1) >> > +#define DRM_COLOR_FORMAT_YCRCB422      (1<<2) >> >  /* >> >

Re: [PATCH 2/2] drm: parse color format support for digital displays

On Sat, 16 Apr 2011 06:10:07 +1000 Dave Airlie wrote: > > - > > +#define DRM_COLOR_FORMAT_RGB444                (1<<0) > > +#define DRM_COLOR_FORMAT_YCRCB444      (1<<1) > > +#define DRM_COLOR_FORMAT_YCRCB422      (1<<2) > >  /* > >  * Describes a given display (e.g. CRT or flat panel) and its li

[PATCH 2/2] drm: parse color format support for digital displays

On Sat, 16 Apr 2011 06:10:07 +1000 Dave Airlie wrote: > > - > > +#define DRM_COLOR_FORMAT_RGB444 ? ? ? ? ? ? ? ?(1<<0) > > +#define DRM_COLOR_FORMAT_YCRCB444 ? ? ?(1<<1) > > +#define DRM_COLOR_FORMAT_YCRCB422 ? ? ?(1<<2) > > ?/* > > ?* Describes a given display (e.g. CRT or flat panel) and its li

[Bug 35367] RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes

https://bugs.freedesktop.org/show_bug.cgi?id=35367 --- Comment #2 from Marek Olšák 2011-04-15 13:27:28 PDT --- (In reply to comment #1) > (In reply to comment #0) > > rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. > > kernel d-r-t, git ddx with tiling enabled in xorg.con

[Bug 35367] RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes

https://bugs.freedesktop.org/show_bug.cgi?id=35367 --- Comment #2 from Marek Ol??k 2011-04-15 13:27:28 PDT --- (In reply to comment #1) > (In reply to comment #0) > > rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. > > kernel d-r-t, git ddx with tiling enabled in xorg.co

Re: Linux 2.6.39-rc3

On 04/15/2011 12:18 PM, Yinghai Lu wrote: > On 04/15/2011 12:06 PM, Ingo Molnar wrote: > >> >> Joerg, mind submitting it with a changelog that includes everything we >> learned >> about this bug and all the Tested-by's in place? >> >> Is anyone of the opinion that we should try to revert the all

Linux 2.6.39-rc3

On 04/15/2011 12:18 PM, Yinghai Lu wrote: > On 04/15/2011 12:06 PM, Ingo Molnar wrote: > >> >> Joerg, mind submitting it with a changelog that includes everything we >> learned >> about this bug and all the Tested-by's in place? >> >> Is anyone of the opinion that we should try to revert the all

Re: [PATCH 2/2] drm: parse color format support for digital displays

> - > +#define DRM_COLOR_FORMAT_RGB444                (1<<0) > +#define DRM_COLOR_FORMAT_YCRCB444      (1<<1) > +#define DRM_COLOR_FORMAT_YCRCB422      (1<<2) >  /* >  * Describes a given display (e.g. CRT or flat panel) and its limitations. >  */ > @@ -201,6 +203,7 @@ struct drm_display_info { >  

[PATCH 2/2] drm: parse color format support for digital displays

EDID 1.4 digital displays report the color spaces they support in the features block. Add support for grabbing this data and stuffing it into the display_info struct for driver use. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c |6 ++ include/drm/drm_crtc.h |5 -

[PATCH 1/2] drm: add bit depth parsing

EDID 1.4 digital monitors report the bit depth supported in the input field. Add support for parsing this out and storing the info in the display_info structure for use by drivers. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c | 55 ++- inc

[PATCH 2/2] drm: parse color format support for digital displays

EDID 1.4 digital displays report the color spaces they support in the features block. Add support for grabbing this data and stuffing it into the display_info struct for driver use. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c |6 ++ include/drm/drm_crtc.h |5 -

[PATCH 1/2] drm: add bit depth parsing

EDID 1.4 digital monitors report the bit depth supported in the input field. Add support for parsing this out and storing the info in the display_info structure for use by drivers. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c | 55 ++- inc

Re: [PATCH] drm: parse color format support for digital displays

On Fri, 15 Apr 2011 15:36:22 -0400 Adam Jackson wrote: > On 4/15/11 3:19 PM, Jesse Barnes wrote: > > > Or is there a CEA block extension that allows for more granularity? > > CEA has bits for the two YCbCr formats too, which we should also parse > since there's plenty of 1.3+CEA blocks in the

[PATCH] drm: parse color format support for digital displays

On Fri, 15 Apr 2011 15:36:22 -0400 Adam Jackson wrote: > On 4/15/11 3:19 PM, Jesse Barnes wrote: > > > Or is there a CEA block extension that allows for more granularity? > > CEA has bits for the two YCbCr formats too, which we should also parse > since there's plenty of 1.3+CEA blocks in the

Re: [PATCH] drm: parse color format support for digital displays

On 4/15/11 3:19 PM, Jesse Barnes wrote: Or is there a CEA block extension that allows for more granularity? CEA has bits for the two YCbCr formats too, which we should also parse since there's plenty of 1.3+CEA blocks in the world thanks to HDMI. For CEA blocks version 2 and up (version num

Re: [PATCH] drm: parse color format support for digital displays

On Fri, 15 Apr 2011 12:19:31 -0700 Jesse Barnes wrote: > On Fri, 15 Apr 2011 15:13:02 -0400 > Adam Jackson wrote: > > info->color_formats = DRM_COLOR_FORMAT_RGB444; > > if (edid->features & DRM_EDID_FEATURE_YCRCB444) > > info->color_formats |= DRM_COLOR_FORMAT_YCBCR444; > >

[PATCH] drm: parse color format support for digital displays

On Fri, 15 Apr 2011 12:19:31 -0700 Jesse Barnes wrote: > On Fri, 15 Apr 2011 15:13:02 -0400 > Adam Jackson wrote: > > info->color_formats = DRM_COLOR_FORMAT_RGB444; > > if (edid->features & DRM_EDID_FEATURE_YCRCB444) > > info->color_formats |= DRM_COLOR_FORMAT_YCBCR444; > >

Re: [PATCH] drm: add bit depth parsing

On Fri, 15 Apr 2011 14:29:50 -0400 Adam Jackson wrote: > On 4/15/11 2:22 PM, Jesse Barnes wrote: > > EDID 1.4 digital monitors report the bit depth supported in the input > > field. Add support for parsing this out and storing the info in the > > display_info structure for use by drivers. > > >

Re: Linux 2.6.39-rc3

On 04/15/2011 12:06 PM, Ingo Molnar wrote: > > Joerg, mind submitting it with a changelog that includes everything we > learned > about this bug and all the Tested-by's in place? > > Is anyone of the opinion that we should try to revert the allocation > order/alignment changes in addition to

Re: [PATCH] drm: parse color format support for digital displays

On Fri, 15 Apr 2011 15:13:02 -0400 Adam Jackson wrote: > On 4/15/11 2:40 PM, Jesse Barnes wrote: > > > @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid, > > info->bpp = 0; > > break; > > } > > + > > + if (edid->features & DRM_EDID_FEATURE_RG

[PATCH] drm: add bit depth parsing

On Fri, 15 Apr 2011 14:29:50 -0400 Adam Jackson wrote: > On 4/15/11 2:22 PM, Jesse Barnes wrote: > > EDID 1.4 digital monitors report the bit depth supported in the input > > field. Add support for parsing this out and storing the info in the > > display_info structure for use by drivers. > > >

[PATCH] drm: parse color format support for digital displays

On Fri, 15 Apr 2011 15:13:02 -0400 Adam Jackson wrote: > On 4/15/11 2:40 PM, Jesse Barnes wrote: > > > @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid, > > info->bpp = 0; > > break; > > } > > + > > + if (edid->features & DRM_EDID_FEATURE_RG

Linux 2.6.39-rc3

On 04/15/2011 12:06 PM, Ingo Molnar wrote: > > Joerg, mind submitting it with a changelog that includes everything we > learned > about this bug and all the Tested-by's in place? > > Is anyone of the opinion that we should try to revert the allocation > order/alignment changes in addition to

Re: [PATCH] drm: parse color format support for digital displays

On 4/15/11 2:40 PM, Jesse Barnes wrote: @@ -1461,6 +1462,15 @@ static void drm_add_display_info(struct edid *edid, info->bpp = 0; break; } + + if (edid->features & DRM_EDID_FEATURE_RGB) + info->color_formats = DRM_COLOR_FORMAT_RGB444; +

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 11:46 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: >> Ok, but how did the allocation changes start triggering this error in >> v2.6.39-rc1? There must still be some layout specific thing here, right? >> Do we understand the details

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 10:33 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: >> Ok, but how did the allocation changes start triggering this error in >> v2.6.39-rc1? There must still be some layout specific thing here, right? >> Do we understand the details

Re: Linux 2.6.39-rc3

* Alexandre Demers wrote: > On 11-04-15 10:27 AM, Joerg Roedel wrote: > > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: > >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of > >> the other patches? > > Yes, apply it just on -rc3 without any other patch.

[Bug 36270] New: [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used

https://bugs.freedesktop.org/show_bug.cgi?id=36270 Summary: [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used Product: Mesa Version: git Platform: x86 (IA32) URL: http://unigine.com/download/#sanc

[Bug 36270] New: [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used

https://bugs.freedesktop.org/show_bug.cgi?id=36270 Summary: [r300g] Light sources are checkered in Unigine Sanctuary when HDR is used Product: Mesa Version: git Platform: x86 (IA32) URL: http://unigine.com/download/#sanc

Re: Linux 2.6.39-rc3

On 11-04-15 10:27 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: >> Ok, I'll test it today. Should I apply it on a clean rc3 without any of >> the other patches? > Yes, apply it just on -rc3 without any other patch. > >> BTW, may I suggest adding the inf

[PATCH] drm: parse color format support for digital displays

EDID 1.4 digital displays report the color spaces they support in the features block. Add support for grabbing this data and stuffing it into the display_info struct for driver use. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c | 10 ++ include/drm/drm_crtc.h |6 +

[PATCH] drm: parse color format support for digital displays

EDID 1.4 digital displays report the color spaces they support in the features block. Add support for grabbing this data and stuffing it into the display_info struct for driver use. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c | 10 ++ include/drm/drm_crtc.h |6 +

Re: [RFC] drm: emit change events when mode config changes

On 4/14/11 1:42 PM, Jesse Barnes wrote: > We've already seen that apps want to monitor the display config, and > some (like upowerd) poll for changes since we don't provide a > notification for general mode config changes, just hotplug events. So > add a new drm event, with CHANGE=1 set in the eve

Re: [PATCH] drm: add bit depth parsing

On 4/15/11 2:22 PM, Jesse Barnes wrote: EDID 1.4 digital monitors report the bit depth supported in the input field. Add support for parsing this out and storing the info in the display_info structure for use by drivers. Signed-off-by: Jesse Barnes Very nice. Reviewed-by: Adam Jackson - aj

[PATCH] drm: add bit depth parsing

EDID 1.4 digital monitors report the bit depth supported in the input field. Add support for parsing this out and storing the info in the display_info structure for use by drivers. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c | 54 ++- inc

[Bug 36268] New: [r300g, bisected] minor flickering in Unigine Sanctuary

https://bugs.freedesktop.org/show_bug.cgi?id=36268 Summary: [r300g, bisected] minor flickering in Unigine Sanctuary Product: Mesa Version: git Platform: Other URL: http://unigine.com/download/#sanctuary OS/Versio

[Bug 36268] New: [r300g, bisected] minor flickering in Unigine Sanctuary

https://bugs.freedesktop.org/show_bug.cgi?id=36268 Summary: [r300g, bisected] minor flickering in Unigine Sanctuary Product: Mesa Version: git Platform: Other URL: http://unigine.com/download/#sanctuary OS/Versio

[PATCH] drm: add bit depth parsing

EDID 1.4 digital monitors report the bit depth supported in the input field. Add support for parsing this out and storing the info in the display_info structure for use by drivers. Signed-off-by: Jesse Barnes --- drivers/gpu/drm/drm_edid.c | 54 ++- inc

[PATCH] i2c-algo-bit: make sure to call pre/post_xfer for bit_test

Hi Alex, On Thu, 14 Apr 2011 19:47:06 -0400, Alex Deucher wrote: > Apparently some distros set i2c-algo-bit.bit_test to 1 by > default. In some cases this causes i2c_bit_add_bus > to fail and prevents the i2c bus from being added. In the > radeon case, we fail to add the ddc i2c buses which prev

Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 10:26:34AM +0200, Michel D?nzer wrote: > On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote: > > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote: > > > On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote: > > > > And this makes a difference, with this chang

Linux 2.6.39-rc3

On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote: > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote: > > On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote: > > > And this makes a difference, with this change on-top of -rc3 the box boots > > > fine. So there seems to be some de

[Bug 32982] Kernel locks up a few minutes after boot

https://bugzilla.kernel.org/show_bug.cgi?id=32982 Bart Van Assche changed: What|Removed |Added Component|Video(DRI - non Intel) |Block Layer Product|Drivers

Linux 2.6.39-rc3

On 11-04-15 09:11 AM, Joerg Roedel wrote: > On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: >> we definitely want to also understand the reason for things not >> working, even if we do revert.. > Okay, here it is. > > After experimenting with different configurations for the north-

[PATCH] Big endian support for RV730 (Gallium r600g)

Hi Here you are a patch that adds big endian support for rv730 in r600 gallium driver. I used the mesa-demos to test the driver status on big endian platform. Except with demos using accumulation buffer, the rendering is the same as on Intel platform. Albeit there are still some artefacts wi

Re: [RFC] drm: emit change events when mode config changes

On Fri, 15 Apr 2011 09:23:38 -0500 Chris Bandy wrote: > On 04/14/2011 12:42 PM, Jesse Barnes wrote: > > /** > > + * drm_sysfs_change_event - generate a DRM uevent indicating a display > > config change > > + * @dev: DRM device > > + * > > + * Send a uevent for the DRM device specified by @dev.

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #14 from Christoph Bumiller 2011-04-15 09:34:15 PDT --- Interesting, I have this with llvmpipe too, but it looks correct with nvc0, so I'd look for a driver specific issue. -- Configure bugmail: https://bugs.freedesktop.org/userpre

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #14 from Christoph Bumiller 2011-04-15 09:34:15 PDT --- Interesting, I have this with llvmpipe too, but it looks correct with nvc0, so I'd look for a driver specific issue. -- Configure bugmail: https://bugs.freedesktop.org/userpre

[RFC] drm: emit change events when mode config changes

On 04/14/2011 12:42 PM, Jesse Barnes wrote: > We've already seen that apps want to monitor the display config, and > some (like upowerd) poll for changes since we don't provide a > notification for general mode config changes, just hotplug events. So > add a new drm event, with CHANGE=1 set in the

Re: Linux 2.6.39-rc3

On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote: > On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel wrote: > > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote: > >> On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote: > >> > And this makes a difference, with this change on-

Re: Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 03:11:52PM +0200, Joerg Roedel wrote: > On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > > we definitely want to also understand the reason for things not > > working, even if we do revert.. > > Okay, here it is. > > After experimenting with different con

Re: Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 11:46 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: >> Ok, but how did the allocation changes start triggering this error in >> v2.6.39-rc1? There must still be some layout specific thing here, right? >> Do we understand the details

Re: Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 10:33 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: >> Ok, but how did the allocation changes start triggering this error in >> v2.6.39-rc1? There must still be some layout specific thing here, right? >> Do we understand the details

[RFC] drm: emit change events when mode config changes

On Fri, 15 Apr 2011 09:23:38 -0500 Chris Bandy wrote: > On 04/14/2011 12:42 PM, Jesse Barnes wrote: > > /** > > + * drm_sysfs_change_event - generate a DRM uevent indicating a display > > config change > > + * @dev: DRM device > > + * > > + * Send a uevent for the DRM device specified by @dev.

Linux 2.6.39-rc3

On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote: > On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel wrote: > > Actually, the nb gart is part of the cpu. It is part of the cpu north > > bridge and can translate io and cpu accesses. In fact, it is a remapper > > of physical memory address

Re: Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: > Ok, but how did the allocation changes start triggering this error in > v2.6.39-rc1? There must still be some layout specific thing here, right? > Do we understand the details of that as well? Well, thinking again about this, the GPU

2.6.39-rc1 nouveau regression (bisected)

On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > to everyone, but then chose to CC Maciej instead: Would you be so kind and > > add this

Re: Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote: > Ok, but how did the allocation changes start triggering this error in > v2.6.39-rc1? There must still be some layout specific thing here, right? > Do we understand the details of that as well? No, I must admit that I lack enough knowl

Re: Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 04:04:45PM +0200, Andreas Herrmann wrote: > What about tagging this patch for stable/longterm releases? > > Potentially there are other cases where certain combinations of > hardware(GPUs)/drivers/whatsoever might trigger a GartTlbWlkErr. If > the BIOS doesn't follow the BK

Re: Linux 2.6.39-rc3

On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote: > Ok, I'll test it today. Should I apply it on a clean rc3 without any of > the other patches? Yes, apply it just on -rc3 without any other patch. > > BTW, may I suggest adding the info under bug 33012 in kernel bugzilla? > This c

Re: Linux 2.6.39-rc3

On 11-04-15 09:11 AM, Joerg Roedel wrote: > On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: >> we definitely want to also understand the reason for things not >> working, even if we do revert.. > Okay, here it is. > > After experimenting with different configurations for the north-

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #13 from Fryderyk Dziarmagowski 2011-04-15 07:06:58 PDT --- I got exactly same problem on Intel G45/G43 (Mesa HEAD) like on the screenshot from #7 (using beta version) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cg

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #13 from Fryderyk Dziarmagowski 2011-04-15 07:06:58 PDT --- I got exactly same problem on Intel G45/G43 (Mesa HEAD) like on the screenshot from #7 (using beta version) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cg

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #12 from Krzysztof A. Sobiecki 2011-04-15 06:35:39 PDT --- Created an attachment (id=45667) --> (https://bugs.freedesktop.org/attachment.cgi?id=45667) RADEON_DEBUG=vp,tex without mesa patch -- Configure bugmail: https://bugs.freed

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #12 from Krzysztof A. Sobiecki 2011-04-15 06:35:39 PDT --- Created an attachment (id=45667) --> (https://bugs.freedesktop.org/attachment.cgi?id=45667) RADEON_DEBUG=vp,tex without mesa patch -- Configure bugmail: https://bugs.freed

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #11 from Krzysztof A. Sobiecki 2011-04-15 06:19:41 PDT --- Created an attachment (id=45666) --> (https://bugs.freedesktop.org/attachment.cgi?id=45666) RADEON_DEBUG=vp and patch on r300g I will post also log without patched mesa. -

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #11 from Krzysztof A. Sobiecki 2011-04-15 06:19:41 PDT --- Created an attachment (id=45666) --> (https://bugs.freedesktop.org/attachment.cgi?id=45666) RADEON_DEBUG=vp and patch on r300g I will post also log without patched mesa. -

Re: Linux 2.6.39-rc3

* Joerg Roedel wrote: > On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > > we definitely want to also understand the reason for things not > > working, even if we do revert.. > > Okay, here it is. > > After experimenting with different configurations for the north-bridge > it

Re: Linux 2.6.39-rc3

On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote: > we definitely want to also understand the reason for things not > working, even if we do revert.. Okay, here it is. After experimenting with different configurations for the north-bridge it turned out that a GART related MCE fires

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #10 from Sven Arvidsson 2011-04-15 05:57:58 PDT --- Created an attachment (id=45665) --> (https://bugs.freedesktop.org/attachment.cgi?id=45665) r300g with patch I have added logs from my system, both from the debug build of Trine (a

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #10 from Sven Arvidsson 2011-04-15 05:57:58 PDT --- Created an attachment (id=45665) --> (https://bugs.freedesktop.org/attachment.cgi?id=45665) r300g with patch I have added logs from my system, both from the debug build of Trine (a

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #9 from Sven Arvidsson 2011-04-15 05:56:05 PDT --- Created an attachment (id=45664) --> (https://bugs.freedesktop.org/attachment.cgi?id=45664) Trine debug log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=ema

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #9 from Sven Arvidsson 2011-04-15 05:56:05 PDT --- Created an attachment (id=45664) --> (https://bugs.freedesktop.org/attachment.cgi?id=45664) Trine debug log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=ema

No subject

logout is being done with libICE. I know it is not being done with Hal, Consolekit or the XKillClient Xlib function. I will update this bug report as soon as I know which function causes this and have a testcase ready. If you think it will lead to a fix I would be willing to use a pencil and paper

[Bug 35367] RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes

https://bugs.freedesktop.org/show_bug.cgi?id=35367 --- Comment #1 from Andy Furniss 2011-04-15 04:43:15 PDT --- (In reply to comment #0) > rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. > kernel d-r-t, git ddx with tiling enabled in xorg.conf. > Does not affect my PCIE

[Bug 35367] RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes

https://bugs.freedesktop.org/show_bug.cgi?id=35367 --- Comment #1 from Andy Furniss 2011-04-15 04:43:15 PDT --- (In reply to comment #0) > rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. > kernel d-r-t, git ddx with tiling enabled in xorg.conf. > Does not affect my PCIE

[Bug 35312] r600g: Automatic mipmap generation doesn't work properly

https://bugs.freedesktop.org/show_bug.cgi?id=35312 --- Comment #3 from Andy Furniss 2011-04-15 04:30:30 PDT --- (In reply to comment #1) > Created an attachment (id=45598) View: https://bugs.freedesktop.org/attachment.cgi?id=45598 Review: https://bugs.freedesktop.org/review?bug=35312&attachmen

[Bug 35312] r600g: Automatic mipmap generation doesn't work properly

https://bugs.freedesktop.org/show_bug.cgi?id=35312 --- Comment #3 from Andy Furniss 2011-04-15 04:30:30 PDT --- (In reply to comment #1) > Created an attachment (id=45598) View: https://bugs.freedesktop.org/attachment.cgi?id=45598 Review: https://bugs.freedesktop.org/review?bug=35312&attachmen

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #8 from Turo Lamminen 2011-04-15 03:37:30 PDT --- (In reply to comment #5) > Created an attachment (id=45654) --> (https://bugs.freedesktop.org/attachment.cgi?id=45654) > Log from beta game on r300g Get the mesa log too so we can s

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #8 from Turo Lamminen 2011-04-15 03:37:30 PDT --- (In reply to comment #5) > Created an attachment (id=45654) --> (https://bugs.freedesktop.org/attachment.cgi?id=45654) > Log from beta game on r300g Get the mesa log too so we can s

[Bug 36236] Problems with lights in Trine game from www.humblebundle.com

https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #7 from Krzysztof A. Sobiecki 2011-04-15 03:29:51 PDT --- Created an attachment (id=45659) --> (https://bugs.freedesktop.org/attachment.cgi?id=45659) Screenshot from beta game on r300g Game looks very similar on llvmpipe and r300g.

  1   2   >