[PATCH 4/8] drivers/gpu/drm/i915: use ARRAY_SIZE macro in intel_tv.c

[Nikitas Angelinas]

Replace sizeof(tv_modes) / sizeof (tv_modes[0]) with
ARRAY_SIZE(tv_modes) in drivers/gpu/drm/i915/intel_tv.c

Signed-off-by: Nikitas Angelinas 
---
 drivers/gpu/drm/i915/intel_tv.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index d2029ef..6dc19f6 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -30,6 +30,7 @@
  * Integrated TV-out support for the 915GM and 945GM.
  */

+#include 
 #include "drmP.h"
 #include "drm.h"
 #include "drm_crtc.h"
@@ -926,7 +927,7 @@ intel_tv_mode_lookup (char *tv_format)
 {
int i;

-   for (i = 0; i < sizeof(tv_modes) / sizeof (tv_modes[0]); i++) {
+   for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
const struct tv_mode *tv_mode = _modes[i];

if (!strcmp(tv_format, tv_mode->name))
-- 
1.7.2.3

[PATCH 3/8] drivers/gpu/drm: use ARRAY_SIZE macro in drm_edid_modes.h

[Nikitas Angelinas]

Replace sizeof(est3_modes) / sizeof(est3_modes[0]) with
ARRAY_SIZE(est3_modes) in drivers/gpu/drm/drm_edid_modes.h

Signed-off-by: Nikitas Angelinas 
---
 drivers/gpu/drm/drm_edid_modes.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 6eb7592..7601284 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -377,4 +377,4 @@ static const struct {
{ 1920, 1440, 60, 0 },
{ 1920, 1440, 75, 0 },
 };
-static const int num_est3_modes = sizeof(est3_modes) / sizeof(est3_modes[0]);
+static const int num_est3_modes = ARRAY_SIZE(est3_modes);
-- 
1.7.2.3

[patch] i915: snprintf returns large values

[Dan Carpenter]

snprintf() returns the number of bytes which would have been used if
there was enough space.  It can be larger than the size of the buffer.
Obviously in this case the buffer is large enough but everyone just
copy and pastes this code so it's better to limit it and set a good
example.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5e43d70..1cb29ec 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -741,6 +741,9 @@ i915_wedged_read(struct file *filp,
   "wedged :  %d\n",
   atomic_read(_priv->mm.wedged));

+   if (len > sizeof (buf))
+   len = sizeof (buf);
+
return simple_read_from_buffer(ubuf, max, ppos, buf, len);
 }

[patch] i915: snprintf returns large values

[Chris Wilson]

On Wed, 8 Sep 2010 21:44:47 +0200, Dan Carpenter  wrote:
> snprintf() returns the number of bytes which would have been used if
> there was enough space.  It can be larger than the size of the buffer.
> Obviously in this case the buffer is large enough but everyone just
> copy and pastes this code so it's better to limit it and set a good
> example.

Applied to drm-intel-next as it is just a pedagogical fix.
Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/radeon/kms: r600 CS parser fixes

[Alex Deucher]

On Fri, Aug 13, 2010 at 6:38 AM, Andy Furniss  wrote:
> Jon Sturm wrote:
>
>> ut2004 has been having issues for a while so I wouldn't blame this
>> patch 100%, Then again my issues seem to be similar to
>> https://bugs.freedesktop.org/show_bug.cgi?id=27443 which may or may
>> not be related.
>
> Only having the demo and not seriously playing all levels (or much at all) I
> haven't hit that one.
>
> This one does seem to be down to the patch. If you have the full game it
> could be things are different, as it's actually the nvidia ad that the demo
> starts with the provokes this. Doom3 demo I can get into a saved game, but
> it dies with the same error after about 10 secs.
>
> Both work with the same d-r-t without the patch.

Does this patch help?

diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index d886494..e83fc88 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -1046,7 +1046,6 @@ static void r600_texture_size(unsigned nfaces,
unsigned blevel, unsigned nlevels
rowstride = ALIGN((width * bpe), pitch_align);
size = height * rowstride * depth;
offset += size;
-   offset = (offset + 0x1f) & ~0x1f;
}
}
*l0_size = ALIGN((w0 * bpe), pitch_align) * h0 * d0;


Alex

> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 30095] New: [r300g] Fullscreen OpenGL game now has occasional flicker (bisected)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30095

   Summary: [r300g] Fullscreen OpenGL game now has occasional
flicker (bisected)
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: rankincj at googlemail.com


Playing World of Warcraft fullscreen with my RV350, and the screen is now
occasionally turning pitch black for a fraction of a second. No other
side-effects noticed, but the "flicker" is annoying.

The pitch black screen isn't completely blank - it looks like the minimap is
being rendered (briefly!) in the bottom LH corner of the screen.

My limited git-fu has narrowed the problem down to this commit:

16887d042a917fa4773e4d853f50051b54e9948c is the first bad commit
commit 16887d042a917fa4773e4d853f50051b54e9948c
Author: Kristian H?gsberg 
Date:   Fri Aug 27 12:40:11 2010 -0400

glx: Drop broken drawable garbage collection

Doesn't work for pixmaps, was looking up the GLX XID and was never thread
safe.  Instead, just destroy the client side structures when the
drawable is no long current for a context.

:04 04 2500fd85901fe387ae1cedc6a0819ca9ffe003b7
7b1e3579557f00281007e0f05df4e7a7e0f1cba5 Msrc

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] radeon: Expose backlight class device for legacy LVDS encoder

[Matthew Garrett]

On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:

> The only problem with this is that not all oems use the internal
> backlight controller; systems that don't need to use the acpi methods.

That's why we expose the backlight type. Userspace should use the acpi 
or platform mechanism when available, with this being a last-ditch 
fallback.

>  On atombios systems there is a bit in the
> ATOM_FIRMWARE_CAPABILITY_ACCESS struct in the FirmwareInfo data table
> to determine whether the backlight is controlled by the GPU or some
> external mechanism.  Combios may have something similar.  If the
> backlight is controlled via the GPU, it can be adjusting using the
> atom OutputControl and TransmitterControl control tables depending on
> the GPU family.  However, if the driver chooses to control the
> backlight itself, it needs to set the appropriate bit in the bios
> scratch regs to tell the firmware not to attempt to change the
> backlight itself.

If there's support for probing this more reliably then I'm all for that, 
but I'm not keen on taking over control if the BIOS has previous 
asserted it.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org

drm: fix building on non-PCI platforms

[Arnd Bergmann]

BenH's fix to correct building on multi-domain systems broke
building DRM for platforms without PCI support. This makes
the call to pci_domain_nr conditional in order to fix compilation.

Signed-off-by: Arnd Bergmann 

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 7809d23..5ff5819 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1099,7 +1099,11 @@ static inline int drm_get_pci_domain(struct drm_device 
*dev)
return 0;
 #endif /* __alpha__ */

+#ifdef CONFIG_PCI
return pci_domain_nr(dev->pdev->bus);
+#else
+   return 0;
+#endif
 }

 #if __OS_HAS_AGP

Backlight: Add backlight type

[Matthew Garrett]

There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.

Signed-off-by: Matthew Garrett 
Cc: Richard Purdie 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org

v2: drivers/platform/x86/asus-laptop.c: Refreshed to fit linux-next 
(next-20101027)
---
Documentation/ABI/stable/sysfs-class-backlight  |   20 
 drivers/acpi/video.c|1 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c |2 ++
 drivers/hid/hid-picolcd.c   |1 +
 drivers/macintosh/via-pmu-backlight.c   |1 +
 drivers/platform/x86/acer-wmi.c |1 +
 drivers/platform/x86/asus-laptop.c  |1 +
 drivers/platform/x86/asus_acpi.c|1 +
 drivers/platform/x86/classmate-laptop.c |1 +
 drivers/platform/x86/compal-laptop.c|1 +
 drivers/platform/x86/dell-laptop.c  |1 +
 drivers/platform/x86/eeepc-laptop.c |1 +
 drivers/platform/x86/fujitsu-laptop.c   |1 +
 drivers/platform/x86/msi-laptop.c   |1 +
 drivers/platform/x86/msi-wmi.c  |1 +
 drivers/platform/x86/panasonic-laptop.c |1 +
 drivers/platform/x86/sony-laptop.c  |1 +
 drivers/platform/x86/thinkpad_acpi.c|1 +
 drivers/platform/x86/toshiba_acpi.c |1 +
 drivers/staging/samsung-laptop/samsung-laptop.c |1 +
 drivers/usb/misc/appledisplay.c |1 +
 drivers/video/atmel_lcdfb.c |1 +
 drivers/video/aty/aty128fb.c|1 +
 drivers/video/aty/atyfb_base.c  |1 +
 drivers/video/aty/radeon_backlight.c|1 +
 drivers/video/backlight/88pm860x_bl.c   |1 +
 drivers/video/backlight/adp5520_bl.c|1 +
 drivers/video/backlight/adp8860_bl.c|1 +
 drivers/video/backlight/adx_bl.c|1 +
 drivers/video/backlight/atmel-pwm-bl.c  |1 +
 drivers/video/backlight/backlight.c |   15 +++
 drivers/video/backlight/corgi_lcd.c |1 +
 drivers/video/backlight/cr_bllcd.c  |1 +
 drivers/video/backlight/da903x_bl.c |1 +
 drivers/video/backlight/ep93xx_bl.c |1 +
 drivers/video/backlight/generic_bl.c|1 +
 drivers/video/backlight/hp680_bl.c  |1 +
 drivers/video/backlight/jornada720_bl.c |1 +
 drivers/video/backlight/kb3886_bl.c |1 +
 drivers/video/backlight/locomolcd.c |1 +
 drivers/video/backlight/max8925_bl.c|1 +
 drivers/video/backlight/mbp_nvidia_bl.c |1 +
 drivers/video/backlight/omap1_bl.c  |1 +
 drivers/video/backlight/pcf50633-backlight.c|1 +
 drivers/video/backlight/progear_bl.c|1 +
 drivers/video/backlight/pwm_bl.c|1 +
 drivers/video/backlight/tosa_bl.c   |1 +
 drivers/video/backlight/wm831x_bl.c |1 +
 drivers/video/bf54x-lq043fb.c   |1 +
 drivers/video/bfin-t350mcqb-fb.c|1 +
 drivers/video/nvidia/nv_backlight.c |1 +
 drivers/video/omap2/displays/panel-acx565akm.c  |1 +
 drivers/video/omap2/displays/panel-taal.c   |2 ++
 drivers/video/riva/fbdev.c  |1 +
 include/linux/backlight.h   |8 
 55 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-class-backlight 
b/Documentation/ABI/stable/sysfs-class-backlight
index 4d637e1..70302f3 100644
--- a/Documentation/ABI/stable/sysfs-class-backlight
+++ b/Documentation/ABI/stable/sysfs-class-backlight
@@ -34,3 +34,23 @@ Contact: Richard Purdie 
 Description:
Maximum brightness for .
 Users: HAL
+
+What:  /sys/class/backlight//type
+Date:  September 2010
+KernelVersion: 2.6.37
+Contact:   Matthew Garrett 
+Description:
+   The type of interface controlled by .
+   "firmware": The driver uses a standard firmware interface
+   "platform": The driver uses a platform-specific interface
+   "raw": The driver controls hardware registers directly
+
+   In the general case, when multiple backlight
+   interfaces are available for a single device, firmware
+   control should be preferred to platform control should
+   be preferred to raw control. Using a firmware
+   interface reduces the probability of confusion with
+   the hardware and the OS independently updating the
+   backlight state. Platform interfaces are mostly a
+   holdover 

[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #25 from Rub?n Fern?ndez  2010-09-08 
15:58:39 PDT ---
Created an attachment (id=38570)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38570)
38569: Log generated with "presub" branch and RADEON_DEBUG=fp, part 2

join with part 1 to get yofrankie-presub.txt.bz2

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #24 from Rub?n Fern?ndez  2010-09-08 
15:57:15 PDT ---
Created an attachment (id=38569)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38569)
Log generated with RADEON_DEBUG=fp, part 1

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #23 from Rub?n Fern?ndez  2010-09-08 
15:56:04 PDT ---
Created an attachment (id=38568)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38568)
Screenshot with the "presub" branch

Your branch seems to improve some things (the tree trunk now looks OK) and
break others (the water and the main character look wrong); in any case, I'll
keep your branch on speed dial if you need me to test anything.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #55 from Martin Steigerwald  2010-09-08 
14:45:15 PDT ---
Looks very good so far. I will reboot this kernel several times tomorrow - as a
freeze so far only every happened *before* the first hibernation / snapshot
cycle - but I looked some Startrek Voyager without a freeze with:

martin at shambhala:~/Computer/Shambhala/Kernel/2.6.36> cat /proc/version 
Linux version 2.6.36-rc3-tp42-toi-3.2-rc1-vmembase-0-05032-g60140c1-dirty
(martin at shambhala) (gcc version 4.4.5 20100728 (prerelease) (Debian 4.4.4-8) 
)
#2 PREEMPT Wed Sep 8 21:36:34 CEST 2010

Thanks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] radeon: Expose backlight class device for legacy LVDS encoder

[Alex Deucher]

On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett  wrote:
> On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
>
>> The only problem with this is that not all oems use the internal
>> backlight controller; systems that don't need to use the acpi methods.
>
> That's why we expose the backlight type. Userspace should use the acpi
> or platform mechanism when available, with this being a last-ditch
> fallback.

Ah, gotcha.

>
>> ?On atombios systems there is a bit in the
>> ATOM_FIRMWARE_CAPABILITY_ACCESS struct in the FirmwareInfo data table
>> to determine whether the backlight is controlled by the GPU or some
>> external mechanism. ?Combios may have something similar. ?If the
>> backlight is controlled via the GPU, it can be adjusting using the
>> atom OutputControl and TransmitterControl control tables depending on
>> the GPU family. ?However, if the driver chooses to control the
>> backlight itself, it needs to set the appropriate bit in the bios
>> scratch regs to tell the firmware not to attempt to change the
>> backlight itself.
>
> If there's support for probing this more reliably then I'm all for that,
> but I'm not keen on taking over control if the BIOS has previous
> asserted it.

Agreed.

Alex

[PATCH] radeon: Expose backlight class device for legacy LVDS encoder

[Alex Deucher]

On Wed, Sep 8, 2010 at 12:32 PM, Matthew Garrett  wrote:
> From: Michel D?nzer 
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>

The only problem with this is that not all oems use the internal
backlight controller; systems that don't need to use the acpi methods.
 On atombios systems there is a bit in the
ATOM_FIRMWARE_CAPABILITY_ACCESS struct in the FirmwareInfo data table
to determine whether the backlight is controlled by the GPU or some
external mechanism.  Combios may have something similar.  If the
backlight is controlled via the GPU, it can be adjusting using the
atom OutputControl and TransmitterControl control tables depending on
the GPU family.  However, if the driver chooses to control the
backlight itself, it needs to set the appropriate bit in the bios
scratch regs to tell the firmware not to attempt to change the
backlight itself.

Alex

> (Updated to add backlight type and make the connector the parent device - mjg)
>
> Signed-off-by: Michel D?nzer 
> Signed-off-by: Matthew Garrett 
> Cc: dri-devel at lists.freedesktop.org
> ---
> ?drivers/gpu/drm/radeon/Kconfig ? ? ? ? ? ? ? ? ?| ? ?1 +
> ?drivers/gpu/drm/radeon/radeon_legacy_encoders.c | ?257 
> ++-
> ?drivers/gpu/drm/radeon/radeon_mode.h ? ? ? ? ? ?| ? 10 +
> ?3 files changed, 262 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
> index 1c02d23..9746fee 100644
> --- a/drivers/gpu/drm/radeon/Kconfig
> +++ b/drivers/gpu/drm/radeon/Kconfig
> @@ -1,6 +1,7 @@
> ?config DRM_RADEON_KMS
> ? ? ? ?bool "Enable modesetting on radeon by default - NEW DRIVER"
> ? ? ? ?depends on DRM_RADEON
> + ? ? ? select BACKLIGHT_CLASS_DEVICE
> ? ? ? ?help
> ? ? ? ? ?Choose this option if you want kernel modesetting enabled by default.
>
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 0b83970..e873935 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -28,6 +28,7 @@
> ?#include "radeon_drm.h"
> ?#include "radeon.h"
> ?#include "atom.h"
> +#include 
>
> ?static void radeon_legacy_encoder_disable(struct drm_encoder *encoder)
> ?{
> @@ -39,7 +40,7 @@ static void radeon_legacy_encoder_disable(struct 
> drm_encoder *encoder)
> ? ? ? ?radeon_encoder->active_device = 0;
> ?}
>
> -static void radeon_legacy_lvds_dpms(struct drm_encoder *encoder, int mode)
> +static void radeon_legacy_lvds_update(struct drm_encoder *encoder, int mode)
> ?{
> ? ? ? ?struct drm_device *dev = encoder->dev;
> ? ? ? ?struct radeon_device *rdev = dev->dev_private;
> @@ -47,15 +48,23 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
> *encoder, int mode)
> ? ? ? ?uint32_t lvds_gen_cntl, lvds_pll_cntl, pixclks_cntl, disp_pwr_man;
> ? ? ? ?int panel_pwr_delay = 2000;
> ? ? ? ?bool is_mac = false;
> + ? ? ? uint8_t backlight_level;
> ? ? ? ?DRM_DEBUG_KMS("\n");
>
> + ? ? ? lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
> + ? ? ? backlight_level = (lvds_gen_cntl >> RADEON_LVDS_BL_MOD_LEVEL_SHIFT) & 
> 0xff;
> +
> ? ? ? ?if (radeon_encoder->enc_priv) {
> ? ? ? ? ? ? ? ?if (rdev->is_atom_bios) {
> ? ? ? ? ? ? ? ? ? ? ? ?struct radeon_encoder_atom_dig *lvds = 
> radeon_encoder->enc_priv;
> ? ? ? ? ? ? ? ? ? ? ? ?panel_pwr_delay = lvds->panel_pwr_delay;
> + ? ? ? ? ? ? ? ? ? ? ? if (lvds->bl_dev)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? backlight_level = lvds->backlight_level;
> ? ? ? ? ? ? ? ?} else {
> ? ? ? ? ? ? ? ? ? ? ? ?struct radeon_encoder_lvds *lvds = 
> radeon_encoder->enc_priv;
> ? ? ? ? ? ? ? ? ? ? ? ?panel_pwr_delay = lvds->panel_pwr_delay;
> + ? ? ? ? ? ? ? ? ? ? ? if (lvds->bl_dev)
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? backlight_level = lvds->backlight_level;
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> @@ -82,11 +91,13 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
> *encoder, int mode)
> ? ? ? ? ? ? ? ?lvds_pll_cntl &= ~RADEON_LVDS_PLL_RESET;
> ? ? ? ? ? ? ? ?WREG32(RADEON_LVDS_PLL_CNTL, lvds_pll_cntl);
>
> - ? ? ? ? ? ? ? lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
> - ? ? ? ? ? ? ? lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN | 
> RADEON_LVDS_DIGON | RADEON_LVDS_BLON);
> + ? ? ? ? ? ? ? lvds_gen_cntl &= ~(RADEON_LVDS_DISPLAY_DIS |
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?RADEON_LVDS_BL_MOD_LEVEL_MASK);
> + ? ? ? ? ? ? ? lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN |
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? RADEON_LVDS_DIGON | RADEON_LVDS_BLON |
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (backlight_level << 
> RADEON_LVDS_BL_MOD_LEVEL_SHIFT));
> ? ? ? ? ? ? ? ?if (is_mac)
> ? ? ? ? ? ? ? ? ? ? ? ?lvds_gen_cntl |= RADEON_LVDS_BL_MOD_EN;
> - ? ? ? ? ? ? ? lvds_gen_cntl &= ~(RADEON_LVDS_DISPLAY_DIS);
> ? ? ? ? ? ? ? ?udelay(panel_pwr_delay * 1000);
> ? ? ? ? ? ? ? ?WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
> ? ? ? ? ? ? ? ?break;
> @@ -95,7 +106,6 @@ static void 

[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

Martin Steigerwald  changed:

   What|Removed |Added

Summary|Kernel 2.6.34 freezes   |random radeon/kms/drm
   |randomly|related freezes with kernel
   ||2.6.34

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #54 from Martin Steigerwald  2010-09-08 
12:42:45 PDT ---
Created an attachment (id=38564)
 View: https://bugs.freedesktop.org/attachment.cgi?id=38564
 Review: https://bugs.freedesktop.org/review?bug=28402=38564

vram align patch does not seem to work, now trying this vmembase at 0 patch

Alex, your patch from comment #47 does not work. Kernel froze a few seconds
after Plasma from KDE 4.4.5 build up the OpenGL compositing desktop.

Now testing with the vmem-base-0 patch from Dave from comment #44. I am
attaching it here, since cut and paste it from the comment gives a malformed
patch.

I am using 60140c143b5cd04d85fec8085d56a1430a109846 from Nigel's tuxonice-head
branch, since I am now pretty sure, the freeze is unrelated to TuxOnIce and
when this vmem base 0 thing works, I also have a TuxOnIce kernel without
compiling another time. Its 2.6.36-rc3 and seems to contain all the other
patches from comment #44 and comment #48 already.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] radeon: Expose backlight class device for legacy LVDS encoder

[Matthew Garrett]

From: Michel D?nzer 

Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.

(Updated to add backlight type and make the connector the parent device - mjg)

Signed-off-by: Michel D?nzer 
Signed-off-by: Matthew Garrett 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/radeon/Kconfig  |1 +
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  257 ++-
 drivers/gpu/drm/radeon/radeon_mode.h|   10 +
 3 files changed, 262 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 1c02d23..9746fee 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -1,6 +1,7 @@
 config DRM_RADEON_KMS
bool "Enable modesetting on radeon by default - NEW DRIVER"
depends on DRM_RADEON
+   select BACKLIGHT_CLASS_DEVICE
help
  Choose this option if you want kernel modesetting enabled by default.

diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 0b83970..e873935 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -28,6 +28,7 @@
 #include "radeon_drm.h"
 #include "radeon.h"
 #include "atom.h"
+#include 

 static void radeon_legacy_encoder_disable(struct drm_encoder *encoder)
 {
@@ -39,7 +40,7 @@ static void radeon_legacy_encoder_disable(struct drm_encoder 
*encoder)
radeon_encoder->active_device = 0;
 }

-static void radeon_legacy_lvds_dpms(struct drm_encoder *encoder, int mode)
+static void radeon_legacy_lvds_update(struct drm_encoder *encoder, int mode)
 {
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
@@ -47,15 +48,23 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
*encoder, int mode)
uint32_t lvds_gen_cntl, lvds_pll_cntl, pixclks_cntl, disp_pwr_man;
int panel_pwr_delay = 2000;
bool is_mac = false;
+   uint8_t backlight_level;
DRM_DEBUG_KMS("\n");

+   lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
+   backlight_level = (lvds_gen_cntl >> RADEON_LVDS_BL_MOD_LEVEL_SHIFT) & 
0xff;
+
if (radeon_encoder->enc_priv) {
if (rdev->is_atom_bios) {
struct radeon_encoder_atom_dig *lvds = 
radeon_encoder->enc_priv;
panel_pwr_delay = lvds->panel_pwr_delay;
+   if (lvds->bl_dev)
+   backlight_level = lvds->backlight_level;
} else {
struct radeon_encoder_lvds *lvds = 
radeon_encoder->enc_priv;
panel_pwr_delay = lvds->panel_pwr_delay;
+   if (lvds->bl_dev)
+   backlight_level = lvds->backlight_level;
}
}

@@ -82,11 +91,13 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
*encoder, int mode)
lvds_pll_cntl &= ~RADEON_LVDS_PLL_RESET;
WREG32(RADEON_LVDS_PLL_CNTL, lvds_pll_cntl);

-   lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
-   lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN | 
RADEON_LVDS_DIGON | RADEON_LVDS_BLON);
+   lvds_gen_cntl &= ~(RADEON_LVDS_DISPLAY_DIS |
+  RADEON_LVDS_BL_MOD_LEVEL_MASK);
+   lvds_gen_cntl |= (RADEON_LVDS_ON | RADEON_LVDS_EN |
+ RADEON_LVDS_DIGON | RADEON_LVDS_BLON |
+ (backlight_level << 
RADEON_LVDS_BL_MOD_LEVEL_SHIFT));
if (is_mac)
lvds_gen_cntl |= RADEON_LVDS_BL_MOD_EN;
-   lvds_gen_cntl &= ~(RADEON_LVDS_DISPLAY_DIS);
udelay(panel_pwr_delay * 1000);
WREG32(RADEON_LVDS_GEN_CNTL, lvds_gen_cntl);
break;
@@ -95,7 +106,6 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
*encoder, int mode)
case DRM_MODE_DPMS_OFF:
pixclks_cntl = RREG32_PLL(RADEON_PIXCLKS_CNTL);
WREG32_PLL_P(RADEON_PIXCLKS_CNTL, 0, 
~RADEON_PIXCLK_LVDS_ALWAYS_ONb);
-   lvds_gen_cntl = RREG32(RADEON_LVDS_GEN_CNTL);
lvds_gen_cntl |= RADEON_LVDS_DISPLAY_DIS;
if (is_mac) {
lvds_gen_cntl &= ~RADEON_LVDS_BL_MOD_EN;
@@ -119,6 +129,25 @@ static void radeon_legacy_lvds_dpms(struct drm_encoder 
*encoder, int mode)

 }

+static void radeon_legacy_lvds_dpms(struct drm_encoder *encoder, int mode)
+{
+   struct radeon_device *rdev = encoder->dev->dev_private;
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   DRM_DEBUG("\n");
+
+   if (radeon_encoder->enc_priv) {
+   if (rdev->is_atom_bios) {
+   struct radeon_encoder_atom_dig *lvds = 

[PATCH] Backlight: Add backlight type

[Matthew Garrett]

There may be multiple ways of controlling the backlight on a given machine.
Allow drivers to expose the type of interface they are providing, making
it possible for userspace to make appropriate policy decisions.

Signed-off-by: Matthew Garrett 
Cc: Richard Purdie 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
---
 Documentation/ABI/stable/sysfs-class-backlight  |   20 
 drivers/acpi/video.c|1 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c |2 ++
 drivers/hid/hid-picolcd.c   |1 +
 drivers/macintosh/via-pmu-backlight.c   |1 +
 drivers/platform/x86/acer-wmi.c |1 +
 drivers/platform/x86/asus-laptop.c  |1 +
 drivers/platform/x86/asus_acpi.c|1 +
 drivers/platform/x86/classmate-laptop.c |1 +
 drivers/platform/x86/compal-laptop.c|1 +
 drivers/platform/x86/dell-laptop.c  |1 +
 drivers/platform/x86/eeepc-laptop.c |1 +
 drivers/platform/x86/fujitsu-laptop.c   |1 +
 drivers/platform/x86/msi-laptop.c   |1 +
 drivers/platform/x86/msi-wmi.c  |1 +
 drivers/platform/x86/panasonic-laptop.c |1 +
 drivers/platform/x86/sony-laptop.c  |1 +
 drivers/platform/x86/thinkpad_acpi.c|1 +
 drivers/platform/x86/toshiba_acpi.c |1 +
 drivers/staging/samsung-laptop/samsung-laptop.c |1 +
 drivers/usb/misc/appledisplay.c |1 +
 drivers/video/atmel_lcdfb.c |1 +
 drivers/video/aty/aty128fb.c|1 +
 drivers/video/aty/atyfb_base.c  |1 +
 drivers/video/aty/radeon_backlight.c|1 +
 drivers/video/backlight/88pm860x_bl.c   |1 +
 drivers/video/backlight/adp5520_bl.c|1 +
 drivers/video/backlight/adp8860_bl.c|1 +
 drivers/video/backlight/adx_bl.c|1 +
 drivers/video/backlight/atmel-pwm-bl.c  |1 +
 drivers/video/backlight/backlight.c |   15 +++
 drivers/video/backlight/corgi_lcd.c |1 +
 drivers/video/backlight/cr_bllcd.c  |1 +
 drivers/video/backlight/da903x_bl.c |1 +
 drivers/video/backlight/ep93xx_bl.c |1 +
 drivers/video/backlight/generic_bl.c|1 +
 drivers/video/backlight/hp680_bl.c  |1 +
 drivers/video/backlight/jornada720_bl.c |1 +
 drivers/video/backlight/kb3886_bl.c |1 +
 drivers/video/backlight/locomolcd.c |1 +
 drivers/video/backlight/max8925_bl.c|1 +
 drivers/video/backlight/mbp_nvidia_bl.c |1 +
 drivers/video/backlight/omap1_bl.c  |1 +
 drivers/video/backlight/pcf50633-backlight.c|1 +
 drivers/video/backlight/progear_bl.c|1 +
 drivers/video/backlight/pwm_bl.c|1 +
 drivers/video/backlight/tosa_bl.c   |1 +
 drivers/video/backlight/wm831x_bl.c |1 +
 drivers/video/bf54x-lq043fb.c   |1 +
 drivers/video/bfin-t350mcqb-fb.c|1 +
 drivers/video/nvidia/nv_backlight.c |1 +
 drivers/video/omap2/displays/panel-acx565akm.c  |1 +
 drivers/video/omap2/displays/panel-taal.c   |2 ++
 drivers/video/riva/fbdev.c  |1 +
 include/linux/backlight.h   |8 
 55 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-class-backlight 
b/Documentation/ABI/stable/sysfs-class-backlight
index 4d637e1..70302f3 100644
--- a/Documentation/ABI/stable/sysfs-class-backlight
+++ b/Documentation/ABI/stable/sysfs-class-backlight
@@ -34,3 +34,23 @@ Contact: Richard Purdie 
 Description:
Maximum brightness for .
 Users: HAL
+
+What:  /sys/class/backlight//type
+Date:  September 2010
+KernelVersion: 2.6.37
+Contact:   Matthew Garrett 
+Description:
+   The type of interface controlled by .
+   "firmware": The driver uses a standard firmware interface
+   "platform": The driver uses a platform-specific interface
+   "raw": The driver controls hardware registers directly
+
+   In the general case, when multiple backlight
+   interfaces are available for a single device, firmware
+   control should be preferred to platform control should
+   be preferred to raw control. Using a firmware
+   interface reduces the probability of confusion with
+   the hardware and the OS independently updating the
+   backlight state. Platform interfaces are mostly a
+   holdover from pre-standardisation of firmware
+   interfaces.
diff --git 

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #53 from Da Fox  2010-09-08 10:42:06 
PDT ---
(In reply to comment #52)
> I am having those freezes on a ThinkPad T42 with
I have the same laptop, I'm glad to someone else still using an old ThinkPad :)

> Da Fox, are d594e46ace22afa1621254f6f669e65430048153 +
> 8e36113082821980c60ce89a6c5d45fc9492fc26 in some drm related development
> branch? Can I apply these with git cherry-pick as well?
Yes, they're from airlied's tree, in the drm-next branch. I think they are in
Linus' tree too, which is what Lukas Schneiderbauer uses.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 30076] Corrupted 3D window with Tiling enabled.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30076

Mathieu Belanger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #6 from Mathieu Belanger  2010-09-08 10:14:54 
PDT ---


*** This bug has been marked as a duplicate of bug 30044 ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 30044] [R600c] Corruption in Penumbra Overture demo when color tiling is enabled

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30044

Mathieu Belanger  changed:

   What|Removed |Added

 CC||b747xx at gmail.com

--- Comment #5 from Mathieu Belanger  2010-09-08 10:14:54 
PDT ---
*** Bug 30076 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #52 from Martin Steigerwald  2010-09-08 
09:43:03 PDT ---
random - possibly Radeon DRM KMS related - freezes
https://bugzilla.kernel.org/show_bug.cgi?id=16376

which I reported seems to be a duplicate of this one.

I am having those freezes on a ThinkPad T42 with

shambhala:~> lspci -nn | grep -i vga
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility
Radeon 9600 M10] [1002:4e50]

As per suggestion from Alex I will now test patch from comment #47. Then I will
try the patches mentioned in comment #44. Da Fox, are
d594e46ace22afa1621254f6f669e65430048153 +
8e36113082821980c60ce89a6c5d45fc9492fc26 in some drm related development
branch? Can I apply these with git cherry-pick as well?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #51 from Lukas Schneiderbauer  
2010-09-08 09:09:41 PDT ---
(In reply to comment #45)
> I'm testing the 2.6.36-rc3 kernel with airlied's patch at the moment. Looks
> promising for me as well. But I still need some hours to really confirm it.
1.5 days uptime and no freeze. So definitely confirmed.


(In reply to comment #48)
> I'm sorry to report that it does not. I've tried with
> 96576a9e1a0cdb8a43d3af5846be0948f52b4460 (current drm-next in airlied's tree).
> This freezes without any patches, seems stable with airlied's patch to put 
> vmem
> at address 0, but freezes still with your patch.
>
> Lukas, can you confirm that this patch still freezes?
2.6.36-rc3 with alex' patch up for > 3 hours and waiting.. :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

drm: fix building on non-PCI platforms

[Jesse Barnes]

On Wed, 8 Sep 2010 17:15:02 +0200
Arnd Bergmann  wrote:

> BenH's fix to correct building on multi-domain systems broke
> building DRM for platforms without PCI support. This makes
> the call to pci_domain_nr conditional in order to fix compilation.
> 
> Signed-off-by: Arnd Bergmann 
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 7809d23..5ff5819 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1099,7 +1099,11 @@ static inline int drm_get_pci_domain(struct drm_device 
> *dev)
>   return 0;
>  #endif /* __alpha__ */
>  
> +#ifdef CONFIG_PCI
>   return pci_domain_nr(dev->pdev->bus);
> +#else
> + return 0;
> +#endif
>  }
>  
>  #if __OS_HAS_AGP

I think we fixed this, but I guess Linus hasn't pulled my tree yet...

-- 
Jesse Barnes, Intel Open Source Technology Center

Interlace modes with r600 KMS

[Marius Gröger]

Am 08.09.2010 00:00, wrote Alex Deucher:
> What card do you have?  Can you dump the registers with both kms and
> ums with an interlaced mode set and send them to me?  Use avivotool

I have a GA-MA78GM-UD2H mainboard with an onboard RS780 chipset.

I sent the requested dumps in a PM.

While typing this I realize that I don't use a pristine d-r-t. I did 
fiddle with the HDMI underscan settings a bit to make my 1280x720p mode 
fit better. That fiddling went so far that I broke the original ratio a 
little bit. Just to let you know.

Thanks
Marius

[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #22 from Sven Arvidsson  2010-09-08 06:58:31 PDT ---
Created an attachment (id=38549)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38549)
Screenshot with presub

(In reply to comment #21)
> Can you try again with the presub-rebase-v2 branch from
> git://anongit.freedesktop.org/~tstellar/mesa and post the output of
> RADEON_DEBUG=fp and a screenshot.
> 

I'm attaching a new screenshot, log is too big to attach so it's available
here:
http://www.whiz.se/temp/log.gz

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #50 from Da Fox  2010-09-08 05:02:14 
PDT ---
(In reply to comment #49)
> I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
> tried to wake the PCs from "DPMS OFF", only to find them completely
> unresponsive and needing a reboot instead. However, only one of those PCs has
> an RV350 card. The other two have rv280 and rv100 cards instead, so Dave
> Airlie's patch to r300.c cannot possibly help them.

Chris: these freezes do occur during normal operation, i.e. while working with
the computer, not only during DMPS. It happens during all kinds of activities,
e.g. it may happen while browsing, typing a letter, chatting, alt-tabbing, or
even not doing anything. However almost always it seems to be triggered by some
activity. For me for example, for me starting firefox after a fresh boot has a
99% chance of causing a freeze during the 'restore tabs from last time' phase. 
Although it is quite possible that the freeze will also occur during DPMS
sleep, I have not experienced it yet (mostly because the freeze will occur
while working, so the computer didn't get a chance to go into DPMS sleep).

So the first thing to do would be to verify that you indeed are experiencing
the same issue (and not an unrelated DPMS problem) is to keep using your
computer and wait for a freeze to occur during usage. Your best bet would be to
try the rv350 card, I have mostly only seen people with r300 and/or rv350
describe this problem, and both me and lukas have an rv350 card (we both have a
Mobility Radeon 9600 M10).
Once you have confirmed that the freeze occurs during normal working operations
also, you should proceed to verify our git-bisect results and test the patches
provided by Dave Airlie and Alex Deucher. Best of luck!

p.s.
Is the rv350 card a PC or a laptop? I noticed both lukas and I have a laptop
with an rv350 card, so perhaps it has something to do with mobility editions?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 29978] r600c, bisected: GPU lockup loading savefile in vegastrike

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29978

--- Comment #6 from Nicolas Kaiser  2010-09-08 01:55:05 PDT 
---
Created an attachment (id=38540)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=38540)
working output of MESA_GLSL=dump

For comparison purposes, this is the same output with mesa-git
a09a8ec12d76e1fb1583fa99cf9f48246c108d7b and reverting
acd7c21541110d7ae6b9e63647391f65946e5c5d and
6c0ba32fd1466e8c1700acab3003dc1fe1deb337.

Working nicely. Apparently, there's not much output after the final
initialisation messages.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #49 from Chris Rankin  2010-09-08 
01:45:45 PDT ---
I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
tried to wake the PCs from "DPMS OFF", only to find them completely
unresponsive and needing a reboot instead. However, only one of those PCs has
an RV350 card. The other two have rv280 and rv100 cards instead, so Dave
Airlie's patch to r300.c cannot possibly help them.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: Interlace modes with r600 KMS

[Marius Gröger]

Am 08.09.2010 00:00, wrote Alex Deucher:

What card do you have?  Can you dump the registers with both kms and
ums with an interlaced mode set and send them to me?  Use avivotool


I have a GA-MA78GM-UD2H mainboard with an onboard RS780 chipset.

I sent the requested dumps in a PM.

While typing this I realize that I don't use a pristine d-r-t. I did 
fiddle with the HDMI underscan settings a bit to make my 1280x720p mode 
fit better. That fiddling went so far that I broke the original ratio a 
little bit. Just to let you know.


Thanks
Marius
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #49 from Chris Rankin ranki...@googlemail.com 2010-09-08 01:45:45 
PDT ---
I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
tried to wake the PCs from DPMS OFF, only to find them completely
unresponsive and needing a reboot instead. However, only one of those PCs has
an RV350 card. The other two have rv280 and rv100 cards instead, so Dave
Airlie's patch to r300.c cannot possibly help 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

[Bug 28402] Kernel 2.6.34 freezes randomly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #50 from Da Fox da_...@mad.scientist.com 2010-09-08 05:02:14 PDT 
---
(In reply to comment #49)
 I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've
 tried to wake the PCs from DPMS OFF, only to find them completely
 unresponsive and needing a reboot instead. However, only one of those PCs has
 an RV350 card. The other two have rv280 and rv100 cards instead, so Dave
 Airlie's patch to r300.c cannot possibly help them.

Chris: these freezes do occur during normal operation, i.e. while working with
the computer, not only during DMPS. It happens during all kinds of activities,
e.g. it may happen while browsing, typing a letter, chatting, alt-tabbing, or
even not doing anything. However almost always it seems to be triggered by some
activity. For me for example, for me starting firefox after a fresh boot has a
99% chance of causing a freeze during the 'restore tabs from last time' phase. 
Although it is quite possible that the freeze will also occur during DPMS
sleep, I have not experienced it yet (mostly because the freeze will occur
while working, so the computer didn't get a chance to go into DPMS sleep).

So the first thing to do would be to verify that you indeed are experiencing
the same issue (and not an unrelated DPMS problem) is to keep using your
computer and wait for a freeze to occur during usage. Your best bet would be to
try the rv350 card, I have mostly only seen people with r300 and/or rv350
describe this problem, and both me and lukas have an rv350 card (we both have a
Mobility Radeon 9600 M10).
Once you have confirmed that the freeze occurs during normal working operations
also, you should proceed to verify our git-bisect results and test the patches
provided by Dave Airlie and Alex Deucher. Best of luck!

p.s.
Is the rv350 card a PC or a laptop? I noticed both lukas and I have a laptop
with an rv350 card, so perhaps it has something to do with mobility editions?

-- 
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 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #22 from Sven Arvidsson s...@whiz.se 2010-09-08 06:58:31 PDT ---
Created an attachment (id=38549)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=38549)
Screenshot with presub

(In reply to comment #21)
 Can you try again with the presub-rebase-v2 branch from
 git://anongit.freedesktop.org/~tstellar/mesa and post the output of
 RADEON_DEBUG=fp and a screenshot.
 

I'm attaching a new screenshot, log is too big to attach so it's available
here:
http://www.whiz.se/temp/log.gz

-- 
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 28402] Kernel 2.6.34 freezes randomly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #51 from Lukas Schneiderbauer lukas.schneiderba...@gmail.com 
2010-09-08 09:09:41 PDT ---
(In reply to comment #45)
 I'm testing the 2.6.36-rc3 kernel with airlied's patch at the moment. Looks
 promising for me as well. But I still need some hours to really confirm it.
1.5 days uptime and no freeze. So definitely confirmed.


(In reply to comment #48)
 I'm sorry to report that it does not. I've tried with
 96576a9e1a0cdb8a43d3af5846be0948f52b4460 (current drm-next in airlied's tree).
 This freezes without any patches, seems stable with airlied's patch to put 
 vmem
 at address 0, but freezes still with your patch.

 Lukas, can you confirm that this patch still freezes?
2.6.36-rc3 with alex' patch up for  3 hours and waiting.. :)

-- 
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] radeon: Expose backlight class device for legacy LVDS encoder

[Alex Deucher]

On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
 On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:

 The only problem with this is that not all oems use the internal
 backlight controller; systems that don't need to use the acpi methods.

 That's why we expose the backlight type. Userspace should use the acpi
 or platform mechanism when available, with this being a last-ditch
 fallback.

Ah, gotcha.


  On atombios systems there is a bit in the
 ATOM_FIRMWARE_CAPABILITY_ACCESS struct in the FirmwareInfo data table
 to determine whether the backlight is controlled by the GPU or some
 external mechanism.  Combios may have something similar.  If the
 backlight is controlled via the GPU, it can be adjusting using the
 atom OutputControl and TransmitterControl control tables depending on
 the GPU family.  However, if the driver chooses to control the
 backlight itself, it needs to set the appropriate bit in the bios
 scratch regs to tell the firmware not to attempt to change the
 backlight itself.

 If there's support for probing this more reliably then I'm all for that,
 but I'm not keen on taking over control if the BIOS has previous
 asserted it.

Agreed.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30076] Corrupted 3D window with Tiling enabled.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30076

Mathieu Belanger b74...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #6 from Mathieu Belanger b74...@gmail.com 2010-09-08 10:14:54 PDT 
---


*** This bug has been marked as a duplicate of bug 30044 ***

-- 
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 30044] [R600c] Corruption in Penumbra Overture demo when color tiling is enabled

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30044

Mathieu Belanger b74...@gmail.com changed:

   What|Removed |Added

 CC||b74...@gmail.com

--- Comment #5 from Mathieu Belanger b74...@gmail.com 2010-09-08 10:14:54 PDT 
---
*** Bug 30076 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] drivers/gpu/drm/i915: use ARRAY_SIZE macro in intel_tv.c

[Nikitas Angelinas]

Replace sizeof(tv_modes) / sizeof (tv_modes[0]) with
ARRAY_SIZE(tv_modes) in drivers/gpu/drm/i915/intel_tv.c

Signed-off-by: Nikitas Angelinas nikitasangeli...@gmail.com
---
 drivers/gpu/drm/i915/intel_tv.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index d2029ef..6dc19f6 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -30,6 +30,7 @@
  * Integrated TV-out support for the 915GM and 945GM.
  */
 
+#include linux/kernel.h
 #include drmP.h
 #include drm.h
 #include drm_crtc.h
@@ -926,7 +927,7 @@ intel_tv_mode_lookup (char *tv_format)
 {
int i;
 
-   for (i = 0; i  sizeof(tv_modes) / sizeof (tv_modes[0]); i++) {
+   for (i = 0; i  ARRAY_SIZE(tv_modes); i++) {
const struct tv_mode *tv_mode = tv_modes[i];
 
if (!strcmp(tv_format, tv_mode-name))
-- 
1.7.2.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #55 from Martin Steigerwald mar...@lichtvoll.de 2010-09-08 
14:45:15 PDT ---
Looks very good so far. I will reboot this kernel several times tomorrow - as a
freeze so far only every happened *before* the first hibernation / snapshot
cycle - but I looked some Startrek Voyager without a freeze with:

mar...@shambhala:~/Computer/Shambhala/Kernel/2.6.36 cat /proc/version 
Linux version 2.6.36-rc3-tp42-toi-3.2-rc1-vmembase-0-05032-g60140c1-dirty
(mar...@shambhala) (gcc version 4.4.5 20100728 (prerelease) (Debian 4.4.4-8) )
#2 PREEMPT Wed Sep 8 21:36:34 CEST 2010

Thanks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #24 from Rubén Fernández rubenf3...@gmail.com 2010-09-08 15:57:15 
PDT ---
Created an attachment (id=38569)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=38569)
Log generated with RADEON_DEBUG=fp, part 1

-- 
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 28860] [r300g] Yo Frankie - shaders not working: Too many instructions

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28860

--- Comment #25 from Rubén Fernández rubenf3...@gmail.com 2010-09-08 15:58:39 
PDT ---
Created an attachment (id=38570)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=38570)
38569: Log generated with presub branch and RADEON_DEBUG=fp, part 2

join with part 1 to get yofrankie-presub.txt.bz2

-- 
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